loc2log

To make Ansible execute a local task, just add corresponding value to hosts directive: Then, playbook can be executed simply by calling More flexible approach is And execute with

Installing GUI on CentOS 7 and maybe CentOS 8 running on VMWare Player or Virtual Box

1. Download full ISO of your OS
2. Mount the ISO to your VM
3. Increase video memory to 128 MB, you may also increase CPU quota to 4 and RAM size to 16MB as well
4. Start-up your VM as-is
5. Mount the CD to your Linux file system where you expects a local repo:
   mount -r -t iso9660 /dev/sr0 /media/cdrom
6. Install GUI X Window system
   sudo yum groupinstall "X Window System"
7. Install the GUI "shell":
   a. Gnome (appeared somewhat unstable)
   sudo yum install gnome-classic-session gnome-terminal nautilus-open-terminal control-center liberation-mono-fonts
   
   b. Install Xfce (appeared to be more stable than gnome to me):
   sudo yum groupinstall "Xfce" -y
   If Xfce group is not available, then install epel-release repo
   sudo yum install epel-release -y
   and re-try the step
8. Make the GUI available at startup
   unlink /etc/systemd/system/default.target
   ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target
9. Restart the system
10. In gdm screen select your GUI "shell" of choice

References:

1. https://owlhowto.com/how-to-install-xfce-on-centos-7/

So we want our feature branch to have all the latest and greatest changes from the master (main).

If our feature branch is cloned like this:

Then one shot rebase would be:

If you used checkout, then try without the origin keyword.

So you are trying to execute a task escalating to a user and getting "This account is currently not available." error in your Ansible log. Chances are that user is set to /sbin/nologin. You can check that with

On Ansible 2.4+ that "This account is currently not available." error is considered a "feature", meaning it behaves just as a remote terminal would do. There is an example in Ansible become docs with become_flags: '-s /bin/bash', but that did not work in my case calling command: some_script.pl. The root cause is in Ansible's default sudo trying to establish home for the user we are escalating to. That is Ansible calling sudo with become_flags: set as -H -S -n. And man sudo reveals that -H "requests that the security policy set the HOME environment variable to the home directory of the target user (root by default) as specified by the password database. Depending on the policy, this may be the default behavior.". So all we really need is to drop that -H in the sudo call. Here how we can do it:

Before the real take off of deployment automation tools like Chef and Ansible, deployment and management of executables on Linux was mostly done with packages. On RedHat-like Linux we widely used practice with clear separation of "executables" and configs, with pretty much everything being deployed in a form of rpm. In the rpm %files list we were marking configuration files with %config, and then those configs were updated, created, or managed with whatever necessary and fitting the bill: in certain occasions it was a separate rpm, or Chef, or Ansible automation, or a bootsrap script on the target itself.

When faced with automation of MS Windows install and configs with Ansible we swayed from that route and we attempted to include configurable parts into Ansible and Jinja2 templates. On a surface it looked quite neat:

1. Less items to manage

2. simplified source control - just 1 single item to manage and already in playbook.

3. no need for separate steps to deploy and call an installer

4. no need to code config parsing in the script - just put that value from Ansible directly!

Yet, it came with the price. Here are not so good sides of such practice:

1. If you change a script on a target box as part of normal development process, copy-paste becomes dangerous, - it is too easy to miss a template inclusion, or you have to transfer changes one by one

2. If you track integrity of executables with md5 sums - it means you've just got extra work to do, or worse - not possible to verify your scripts' integrity at all. That's because files will be inevitably different from what you have in templates and if you have to include something different on each system, e.g. its hostname - you'll get different md5s all the way.

So choose what is more important to you and re-examine your security requirements. It can be quite painful to learn you can't guarantee integrity of your executables once the security audit comes ;-)

It is easy to detect if a user is registered on a Linux system with Ansible getent module.

Example:

- name: Check if user exists
  getent:
    database: passwd
    key: "{{ user_name }}"
    fail_key: False
- debug: var=getent_password

Here we simply use user_name variable with whatever user we need to find. And the result goes to an auto-registered variable "getent_password". If the user we are looking for is not there, we get dictionary with null value. E.g. we were looking for user_name: super, then the debug output will look like this:

getent_passwd:
  super: null

See Microsoft article KB 2040065 https://kb.vmware.com/s/article/2040065