Robert Basic's blog

Posts tagged 'vagrant'

Issues with Vagrant after upgrading to Fedora 25

by Robert Basic on December 24, 2016.

Fedora 25 was released over a month ago, so I decided it was time to upgrade from 24.

Using the dnf plugin system-upgrade the entire process went smooth. The Fedora Magazine, as always, has a nice post on how to upgrade.

So far I ran into only a couple of minor issues with Vagrant.

The first one, which isn’t really a problem, is that Vagrant got downgroaded to version 1.8.x from 1.9.1 which I had installed in Fedora 24. The fix for that is easy, just install the new version again:

robert@odin ~$ sudo dnf install ~/Downloads/vagrant_1.9.1_x86_64.rpm

The second issue was that, well, vagrant didn’t really want to work. When trying to run vagrant up it would spit out the usual kernel module is not loaded error.

The provider 'virtualbox' that was requested to back the machine
'default' is reporting that it isn't usable on this system. The
reason is shown below:

VirtualBox is complaining that the kernel module is not loaded. Please
run `VBoxManage --version` or open the VirtualBox GUI to see the error
message which should contain instructions on how to fix this error.

Running VBoxManage --version provided a helpful message, for once:

robert@odin ~$ VBoxManage --version
WARNING: The vboxdrv kernel module is not loaded. Either there is no module
         available for the current kernel (4.8.15-300.fc25.x86_64) or it failed to
         load. Please try load the kernel module by executing as root

           dnf install akmod-VirtualBox kernel-devel-4.8.15-300.fc25.x86_64
           akmods --kernels 4.8.15-300.fc25.x86_64 && systemctl restart systemd-modules-load.service

         You will not be able to start VMs until this problem is fixed.
5.1.10r112026

Looking at the list of installed packages with dnf list installed I saw that both the akmod-VirtualBox and the kernel-devel packages are installed.

Running the next command fixed the issue:

robert@odin ~$ akmods --kernels 4.8.15-300.fc25.x86_64 && systemctl restart systemd-modules-load.service
Checking kmods exist for 4.8.15-300.fc25.x86_64            [  OK  ]

VBoxManage shows no warnings any more:

robert@odin ~$ VBoxManage --version
5.1.10r112026

and Vagrant works just fine again.

Happy hackin’!

Tags: akmod, fedora, vagrant, vboxmanage, virtualbox.
Categories: Development, Software.

Need help on your PHP projects? Let's talk!

Configure Fedora's firewall for Vagrant

by Robert Basic on December 09, 2016.

This one’s been in my drafts for a long time, might as well publish it.

FirewallD, Fedora’s firewall, has a set of zones, which basically enables to configure trusted network connections inside these zones. You can read more about FirewallD on it’s wiki page.

Whenever I bring up a Vagrant box for the first time, Fedora’s firewall blocks the NFS shares, because the new Vagrant network interface does not belong to any zone. The usual symptom of this is that Vagrant gets stuck on the mounting NFS shares step.

I have a zone called FedoraWorkstation that I use for all the Vagrant boxes I have on my laptop. This zone has a list of services that are allowed:

robert@odin ~$ sudo firewall-cmd --zone FedoraWorkstation --list-services
dhcpv6-client rpc-bind nfs mountd ssh samba-client

You can use any other zone you like, but you need to have the rpc-bind, nfs and mountd services allowed for that zone.

After bringing up the Vagrant box, we need to figure out what’s the name of the new Vagrant interface and add it to the firewall zone. Vagrant interfaces follow the naming schema of vboxnetX where X is a number:

robert@odin ~$ ip link show | grep "state UP" | grep "vbox"
7: vboxnet3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000

From this we can see that the name of the interface is vboxnet3.

Let’s add it to the FedoraWorkstation zone and reload:

robert@odin ~$ sudo firewall-cmd --zone FedoraWorkstation --add-interface vboxnet3 --permanent
success
robert@odin ~$ sudo firewall-cmd --reload
success

Finally let’s make sure that the interface was indeed added:

robert@odin ~$ sudo firewall-cmd --zone FedoraWorkstation --list-interfaces
vboxnet3 vboxnet2 vboxnet0

And that’s it. Happy hackin’!

Tags: configuration, fedora, firewall, vagrant.
Categories: Development, Software.

Need help on your PHP projects? Let's talk!

Installing Python2 with Ansible

by Robert Basic on June 29, 2016.

Ansible uses Python2 to run the provisioning commands on the host machines. At this time it does not support Python3, which is the default python version in Fedora releases for quite some time now.

So to be able to manage Fedora machines with Ansible, I need to install Python2, but how to install it when all the Ansible modules depend on Python2 being installed? Turns out it’s quite simple, by turning of the gathering of facts in Ansible and using the raw module to install the required packages:

- hosts: all
  gather_facts: no
  become: yes
  tasks:
    - name: Install python2 and python2-dnf
      raw: dnf -y install python2 python2-dnf
    - name: Gather facts
      setup:

Just remember this needs to be the very first thing that happens on all your Fedora hosts. After python2 is installed, gather the facts for all the hosts by running the setup module.

Happy hackin’!

Tags: ansible, fedora, provisioning, python, vagrant.
Categories: Development, Software.

Need help on your PHP projects? Let's talk!

Creating a PostgreSQL user in Vagrant with Ansible

by Robert Basic on June 28, 2016.

Lately I’ve been playing around with provisioning a PostgreSQL server with Ansible in a local Vagrant machine that runs a Fedora 23 image.

The first task after installing and starting the PostgreSQL server is to create a database user and a database. So far I have found an ugly way, a really ugly way and a nice way to do this.

How it should be done

The proper way to do this would be to use the postgresql_user Ansible module and the become, become_user and become_method directives, like so:

- name: Create a PostgreSQL database user
  postgresql_user: name=project password=project role_attr_flags=CREATEDB state=present
  become: yes
  become_user: postgres
  become_method: sudo

But this fails because sudo expects us to enter the password:

TASK [postgresql : Create user] ************************************************
fatal: [default]: FAILED! => {"changed": false, "failed": true, "module_stderr": "", "module_stdout": "sudo: a password is required\r\n", "msg": "MODULE FAILURE", "parsed": false}

You can read more about privilege escalation in Ansible in their documentation.

The really ugly way

This solution is so bad I’m not even sure I should write it down. It depends on changing the default identification method for local connections from peer to the trust method, so we can use the default vagrant user to create new users without any checks, based only on, well, trust.

- name: Change peer identification to trust
  shell: /bin/sed -i '/^local/s/peer/trust/' /var/lib/pgsql/data/pg_hba.conf
  notify: restart dbserver

- meta: flush_handlers

- name: Create a PostgreSQL database user
  postgresql_user: name=project password=project role_attr_flags=CREATEDB state=present

- name: Change trust identification back to peer
  shell: /bin/sed -i '/^local/s/trust/peer/' /var/lib/pgsql/data/pg_hba.conf
  notify: restart dbserver

- meta: flush_handlers

This is just bad, there must be a better way.

The less ugly way

But still ugly. This is based on running a psql command using the shell Ansible module.

- name: Create a PostgreSQL database user
  shell: sudo -u postgres bash -c "psql -c \"CREATE USER project WITH CREATEDB PASSWORD 'project';\""

This one has an additional problem of that it only works when we run it for the first time, because we can’t create the same user twice. A possible solution would be to wrap the CREATE USER ... in an additional IF NOT EXISTS (SELECT * FROM pg_catalog.pg_user ... query, but that’s just… Ugh. No.

Back to square one

Let’s go back to the way how it should be done, by using the become and become_user directives. But how do we handle the sudo password? We tell sudo to not ask for a password by editing the /etc/sudoers files. The line to add is:

vagrant ALL=(postgres) NOPASSWD:/bin/sh

This tells sudo that the user vagrant on ALL hosts can run the /bin/sh program with NOPASSWD as the user postgres. I’m explicitly limiting the possible commands to /bin/sh as that is the only command we need to be able to run to make things work. I don’t want to add more if I don’t need to.

The Ansible tasks are now:

- name: Enable passwordless sudo
  lineinfile: dest=/etc/sudoers regexp=^vagrant line="vagrant ALL=(postgres) NOPASSWD:/bin/sh"

- name: Create a PostgreSQL database user
  postgresql_user: name=project password=project role_attr_flags=CREATEDB state=present
  become: yes
  become_user: postgres
  become_method: sudo

For added bonus we can cleanup the sudoers file after we are done by removing the line we added.

Happy hackin’!

P.S.: If you want to use a good quality Ansible role for PostgreSQL take a look at this one. Thanks to Gilles Cornu for pointing it out!

Tags: ansible, postgresql, provisioning, vagrant.
Categories: Development, Programming, Software.

Need help on your PHP projects? Let's talk!