ubuntu


Ubuntu 18.04 LTS: Setting up a symfony 4 skeleton project 1

Recently we decided to give it a go with Symfony PHP framework on an Ubuntu 18.04 LTS. Below you will find the commands we executed to install the skeleton project of symfony with some comments.

Composer

To install symfony, you need composer which is a dependency manager for PHP. The version of composer that was available in apt when this post was written was “very” old. Specifically, it had version Composer 1.6.3 2018-01-31 16:28:17. For this reason we decided to go with the version that is available in the official website of composer. The steps we followed were the ones below:

# Update our system
sudo apt update -y;
sudo apt upgrade -y;
# Install dependencies
sudo apt install curl php-cli php-mbstring git unzip php-xml -y;
# Get composer installer from the official site
curl -sS https://getcomposer.org/installer -o composer-setup.php;
# Verify the the download was not corrupt by checking the sha384 sum of the installer file
HASH=`curl https://composer.github.io/installer.sha384sum | cut -d' ' -f 1`;
# If this step fails, go back to the curl command and try again, it would mean that there was a problem when downloading the installer from the net
php -r "if (hash_file('SHA384', 'composer-setup.php') === '$HASH') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
# Upon successfully validating the install, we can proceed to the actual installation.
sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer;
source ~/.bashrc;

Symfony Skeleton Project

After the above steps are completed, we were able to proceed with the final step, which would be to create the symfony skeleton project via the composer with the following command in the folder named sandbox:

composer create-project symfony/skeleton sandbox '4.4.*';

To verify the installation of the skeleton project we started a web server with PHP in the installation folder of the project and thus verify it through the browser:

cd sandbox;
# We did not use the port 80 as it would require root access to start
php -S 127.0.0.1:8000 -t public;

From a browser visiting http://127.0.0.1:8000/ we got to see:


Ubuntu 18.04: Cannot mount Micro SD DC I Class 10

Recently we tried to mount a Micro SD card that was formatted using the exFat format. To do so we used the build in card reader of a laptop that was running Ubuntu 18.04. To our disappointment, the OS was able to “see” the device as ‘/dev/mmcblk0’ but it could not automatically mount it.

First step we did was of course to update the system using:

sudo apt update;

and then we made sure we had all the necessary packages installed:

sudo apt-get install exfat-fuse exfat-utils;

Unfortunately, we still could not automatically mount the device. So we decided to try and mount it manually which also failed:

sudo mount -t exfat /dev/mmcblk0 /mnt/vmfs;
FUSE exfat 1.2.8
ERROR: failed to read boot sector.

As we were not sure what was wrong we decided to do an experiment which turned out to be our solution: to use an external card reader and try again.. guess what? It worked!!

We will investigate further the issue with the build in card reader but for now we are able to work around the issue with the external card reader.


Compiling the latest version of YubiKey Personalization Tool on Ubuntu 18.04 LTS

Recently, we were got our hands on some YubiKeys, and we decided to use them to create a Two Factor Authentication System (2FA) for the fun of it! We had at our disposal an updated Ubuntu 18.04 LTS so we installed the personalization tools from the official repositories in order to modify the behavior and configure the YubiKeys.

To our disappointment, when we used ykpersonalize and yubikey-personalization-gui we would get an error that the firmware of the YubiKey was unknown…
At the time, the installation packages from the official Ubuntu repositories had version 3.1.24 for the application version and 1.18.0 for the library version.

We noticed that on the YubiKey Personalization Tools page there were newer versions of both the application and the library. Specifically at the time the Application version was 3.1.26 and the Library Version was 1.19.0. Since both were newer than the versions in the repositories we decided to build them and see if they work right with our YubiKeys.

The instructions in the respective installers, were not 100% complete and the installations failed by blindly following them. To actually make the installations work, we installed the following dependencies and tools before compiling:

sudo apt update -y;
sudo apt upgrade -y;
sudo apt install build-essential -y;
sudo apt-get install pkg-config git autoconf libtool asciidoc-base -y;

After installing the above packages the rest of the installation went smoothly.

Installing the command line tools and the library

cd ~; # or any other folder of your choice
sudo apt-get install libykpers-1-dev libyubikey-dev libusb-1.0-0-dev libjson-c-dev -y;
git clone https://github.com/Yubico/yubikey-personalization.git;
cd yubikey-personalization;
autoreconf --install;
./configure;
sudo make check install;

Installing the Qt based Cross-Platform YubiKey Personalization Tool

cd ~; # or any other folder of your choice
sudo apt-get install qt4-qmake libqt4-dev -y;
git clone https://github.com/Yubico/yubikey-personalization-gui.git;
cd yubikey-personalization-gui;
qmake && make;


Install Gnome Boxes on Kali Linux

Our solution in getting Gnome Boxes to work on Kali Linux (which is a Debian-derived Linux distribution just like Ubuntu) is the following:

First install Gnome Boxes along with all needed virtualization software:


sudo apt-get install -y gnome-boxes qemu-kvm libvirt0 virt-manager bridge-utils;

Then, edit the file /etc/libvirt/qemu.conf to uncomment the following line:

#user = "root"

Finally, restart the host machine and your Gnome Boxes will be ready to use.

Long story

Recently, we were setting up a Kali Linux machine and one of the requirements was to add virtualization support so that the user could execute virtual machines doing.. other stuff. We started by installing gnome-boxes only (hoping that would be enough)


sudo apt-get install -y gnome-boxes;

.. but we got an error:

Boxes cannot access the virtualization backend

Apparently, installing gnome-boxes only, the dependency system did not automatically assume we would need to install an engine to handle the virtual machines, so we had to install the following as well:


sudo apt-get install -y qemu-kvm libvirt0 virt-manager bridge-utils;

After the installation, we tried  to create a new virtual machine but it would fail when we tried to start it. After looking into the logs we found the following useful information:

State: GVIR_DOMAIN_STATE_SHUTOFF

It seems that our user (even if it was root) could not start the QEMU process. To fix this issue we had to modify the file /etc/libvirt/qemu.conf and uncomment the following line:

#user = "root"

from this section

# The user for QEMU processes run by the system instance. It can be
# specified as a user name or as a user id. The qemu driver will try to
# parse this value first as a name and then, if the name doesn't exist,
# as a user id.
#
# Since a sequence of digits is a valid user name, a leading plus sign
# can be used to ensure that a user id will not be interpreted as a user
# name.
#
# Some examples of valid values are:
#
# user = "qemu" # A user named "qemu"
# user = "+0" # Super user (uid=0)
# user = "100" # A user named "100" or a user with uid=100
#
#user = "root"

# The group for QEMU processes run by the system instance. It can be
# specified in a similar way to user.
#group = "root"

After doing this change and restarting the host machine we were able to start and use any virtual machine in Gnome Boxes.

Extra information

In this case, we were using Kali Linux, where people usually operate it using the root account only.
On other installations, like on an Ubuntu installation you would need to handle differently the last step that requires you to edit the /etc/libvirt/qemu.conf file.

Specifically, the best way to handle this issue on a multi-user environment (like Ubuntu) would be to replace the following line:

#group = "root"

with this

group = "kvm"

and then add yourself to the kvm group before restarting the host machine


sudo usermod -a -G kvm $USER;

Doing so, it allows you to enable access to the virtualization services to multiple users of you choice instead of limiting it to one account.