Migrating to PHP 7

PHP 7.0.0 has been released for a year now.  I wasn’t in a rush to migrate to it, but with all the cool features and performance optimization, it’s definitely something I wanted to look into rather sooner than later.

It turns out that I’ve done my first PHP 7 migration a week ago, when I upgraded my laptop to Fedora 25.  Yup, that’s right.  It’s a bit embarrassing, but I have been developing on PHP 7 for a week without even noticing it.

$ php --version
PHP 7.0.13 (cli) (built: Nov 9 2016 07:29:28) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Xdebug v2.4.1, Copyright (c) 2002-2016, by Derick Rethans

I think that was due to a few things:

  • It’s been quite a busy week, so my attention was all over the place.
  • PHP 7 backward compatibility is pretty awesome.  There are only a few things that need fixing in the older code bases, but if you haven’t been living under a rock for the last few years, you probably have nothing to change or worry about.
  • Most of the code I’m working on runs through TravisCI builds, which are executed on both PHP 5.6 and PHP 7.  Since we had this for a while now, most, if not all, of our code is PHP 7 compatible.

The absolute lack of any issues for the last week, related to this upgrade, is encouraging.  Now I will probably try to upgrade our servers sooner than later.

With that, I’ll go back to the wonderful and exciting world of PHP, leaving you to decide whether I’m very serious or very sarcastic…

 

EPEL : the effort behind the scenes

Catching up with recent news, I came across this blog post by Stephen John Smoogen in Fedora People, where he explains the reason for the recent disappearance of the Puppet package from the Extra Packages for Enterprise Linux (EPEL 6) repository:

This week various people using EPEL on RHEL and CentOS 6 have found that the puppet package is no longer provided by EPEL. The reason for this is due to the way EPEL packages are built and kept inside the repository. A package needs a sponsor so that we can hopefully get bug fixes and security updates to it. In the case of puppet this package is sponsored by the user kanarip. However, most packages aren’t whole pieces, they rely on other software.. in this case the package puppet relies on a lot of different ruby gems of which one of them was called ruby-shadow. This package was orphaned 30 weeks ago and while it did have other people watching it, none of them took over the package.

[…]

Last week a large cleanup was done to clean out orphaned packages from EPEL which removed ruby-shadow. Once that was removed, then all of the other packages depending on ruby-shadow were also removed. Today various people reinstalling systems found puppet wasn’t around and came onto #epel to ask.. which seems to have gotten the packages responsored and hopefully they will be back in the EPEL release in a day or so.

This problem has been happening a lot lately. I think it shows quite a few problems with how EPEL is set up and managed. For this, I take responsibility as I said I would try to clean it up after FOSDEM 2016 and it is still happening.

Unpleasant annoyance that shouldn’t have happened, right?  Well, yes, maybe.

Software is a complex matter, whether you are designing, developing, testing, or distributing it.  So things do go wrong sometimes.  And that was something I wanted to focus on for a second.

Forget the actual designing, developing, testing and documenting the software.  Forget all the infrastructure behind such a vital part of the Linux ecosystem as EPEL.  Just think of this single issue for a moment.  Once again:

A package needs a sponsor so that we can hopefully get bug fixes and security updates to it.

So what, I hear you say.  Well, let’s take a closer look.  EPEL provides packages for multiple versions of the distribution, hardware platforms and so on.  Let’s just look at the EPEL 6 for x86_64 (to keep things simple).  That looks like a lot of packages, doesn’t it?.  How many? At the time of this writing, from a random mirror that I got:

wget -q -O - http://download.fedoraproject.org/pub/epel/6/x86_64/ | grep -c 'unknown.gif'
12129

Yup. That’s 12,129 packages!  And each one of those has at least one developer behind it, to sponsor.  Some of those amazing people obviously maintain more than one package. Some packages are maintained by multiple people.  All of them are working hard behind the scenes for you and me to have an easy and stable access to a whole lot of software.  Here is a quote from the FAQ which is smoked and marinated in all that effort:

Software packages in EPEL are maintained on a voluntary basis. If you to want ensure that the packages you want remain available, get involved directly in the EPEL effort. More experienced maintainers help review your packages and you learn about packaging. If you can, get your packaging role included as part of your job description; EPEL has written a generic description that you can use as the basis for adding to a job description.

We do our best to make this a healthy project with many contributors who take care of the packages in the repository, and the repository as a whole, for all releases until RHEL closes support for the distribution version the packages were built for. That is ten years after release (currently) — a long time frame, and we know a lot can happen in ten years. Your participation is vital for the success of this project.

I don’t know about you, but for me, this is absolutely mind-blowing.  So I just wanted to take this opportunity to say thank you to all the brilliant people behind the scenes, who are often invisible, yet indispensable for the continuous success of Open Source software in general, and Linux in particular.

You guys rock!

Fedora 25

I’ve just upgraded my laptop to Fedora 25.  The upgrade process was a breeze (as per instructions from this article):

sudo su -
dnf upgrade --refresh
dnf install dnf-plugin-system-upgrade
dnf system-upgrade download --releasever=25
dnf system-upgrade reboot

About 2,500 packages (1 GB and some) were downloaded in about 40 minutes (yeah, our Internet connection could use a boost). Then rebooted and the upgraded kicked in. It took about another 40 minutes to run the process (I should get myself an SSD-based laptop next time).

The only thing I had to fix after the upgrade was the kmod-wl package, which provides the drivers for my wireless interface. Another reboot later all was good.

There were no major visual changes (I’m using MATE Desktop), but something felt a bit different.  After focusing on the differences for a few minutes, I think it’s the fonts.  Something is better, sharper, more polished.

Other than that, all is pretty much the same.  I’ll need to use it for a while to see if I can spot any changes.  Hopefully, at least a flickering issue that I got after some upgrade during the Fedora 24 life span is fixed now.  It was weird.  A particular application window would start to flick and refresh until clicked again.  Never figured out what it was. :)

SQL Server in a Fedora Docker Container

MS SQL Server and Docker

It’s a well known fact that I am not the greatest fan of Microsoft and their technologies.  I’ve been bitten many a time through the years.  And not even them becoming a Platinum Partner in the Linux Foundation can change my attitude towards them.  It’s just been too much pain, and scars, and tears, and sweat.

But the way life is, once in a while, I just have to work with or around them.  Recently, for example, at work, we’ve done a project that just had to use MS SQL Server and there was no way to get around it.  Gladly, I managed to find just the right image on the Amazon AWS Marketplace, and spin a new EC2 instance for testing.  The local development was difficult, but at least we had a place to test stuff before sending it off to the customer.

If such a need arises in the future, I think I’ll give the MS SQL for Linux a try.  And that’s when this article from Fedora Magazine might come in handy.  MS SQL + Docker + Fedora.  Hmm.

Fedora 24 : the day of 64-bit has come

I’ve been using 64-bit Linux distributions on the servers for a while now, but was reluctant to put one on my laptop.  I’ve tried a couple of times many years ago, and found that there were all sorts of weird issues.

Yesterday, with a little push from my brother, Google, and Slashdot, I’ve decided to give it another go.  64-bit Fedora 24 is now on my laptop and I am carefully exploring it.  So far, so good.

I guess I won’t have to worry about Year 2038 Problem after all.

Ansible setup for Fedora project

Real life working examples are some of the most useful things when learning a new system.  The more – the better.  That’s why this git repository of the Ansible setup for the Fedora project is a pure gold mine.  It is large.  It is complex.  It covers a whole lot of things.  But most importantly, it is alive and well tested.

Fedora 23 and upgrade issues

 

fedora

Fedora 23 has been released yesterday, and as a big fan and a long time user I had to upgrade my laptop (from Fedora 22) immediately.  Or at least try.

Usually, the process is quite simple and doesn’t take much figuring out.  This time it was somewhat different though.  At first, the recommended upgrade command changed slightly from the nice and simple fedup to dnf system-upgrade.

The first attempt downloaded all packages, ended with a cryptic error along the lines of “No updates for kernel packages were found“.  Hmm, weird.  I thought maybe this was caused by me forgetting to run “dnf update” before the upgrade process.  So I did.  Some updates were installed, but there were no kernel packages among them.  I rebooted the laptop just in case.

The second attempt for some reason failed to find any of the previously downloaded packages, so I had to wait until the almost 2 GB get pulled down again.  Result – same error about missing kernel updates.  Hmm, again.

After poking around for a bit, I realized that I had previously configured yum to exclude some packages from updates (kernel, kmod-wl, kmod-VirtualBox, and VirtualBox).  These settings were picked up by dnf.  Editing both /etc/yum.conf and /etc/dnf/dnf.conf to disable the exclude fixed the issue.  “dnf update” now pulled some updates to the kernel.  Another reboot.

The third attempt once again lost all the downloaded packages and I had to wait some more.  This was annoying, especially at 1am now.  The process of downloading finished OK and this time there was no errors.  So “dnf system-upgrade reboot” should do the trick now, right?  Wrong!

Surprisingly, there was no boot menu for system upgrade upon reboot.  So I went with Fedora 22 boot option.  Which resulted in a brief screen saying “Preparing for upgrade“.  Which then disappeared and the system booted back into Fedora 22.  Now that was interesting.

It took me a while to find the issue.  The problem was that my Fedora 22 laptop wasn’t a clean install, but an upgrade from Fedora 21.  That shouldn’t be a problem, but it is, due to this bug.  My /etc/os-release file didn’t have the VARIANT and VARIANT_ID variables (thanks to this blog).  So after adding these lines:

VARIANT="Workstation Edition"
VARIANT_ID=workstation

I’ve rebooted once again, and started the fourth attempt.  Downloaded packages were gone once again, so I had to wait a bit more.  This time the faster office Internet connection helped to save some time.  Download finished OK. Another reboot.  Once again, there is no option to upgrade Fedora, so I’m going into Fedora 22 boot.  Finally, now there is the upgrade screen!  After some preparation time, the packages were installed, the machine rebooted, and now I’m Fedora 23 user.

Checking my /etc/os-release file I see that both variant variables are gone now.  This feels weird, but hopefully won’t cause issues in the future.  If it will, I’ll probably Google for three hours before finding this very blog post.

6 great monospaced fonts for code and terminal in Fedora

hack

Fedora Magazine covers “6 great monospaced fonts for code and terminal in Fedora“.  Their choices are:

  • Hack
  • Inconsolata
  • Source Code Pro
  • Fira Mono
  • Droid Sans Mono
  • DejaVu Sans Mono

It’s been a while since I considered a change to the monospaced fonts that I’m using.  The top three fonts in my list from a while back are Fixedsys Excelsior, Monaco, and Microsoft Consolas.  I used Fixedsys Excelsior almost exclusively in all my terminal windows.

Vagrant adventures on Fedora 21

I spent a large chunk of yesterday experimenting with Vagrant on my Fedora 21 laptop.  I’ve used it before of course, but a friend asked for help with something I was planning to play with for a long time, so it unexpectedly lead me into a journey.

Let’s start simple.  If you want the least possible amount of hassle with running Vagrant on Fedora, you should use it with Oracle VirtualBox provider (sometimes also called hypervisor).   It works great!  The only troubles with this approach is that VirtualBox relies on a kernel module (kmod-VirtualBox RPM), which has to match your current running kernel version to a digit.  This kernel module is NOT part of the official Fedora repositories, and, instead, can be found in the RPM Fusion yum repository (rpmfusion-free-updates).  This means that sometimes, when Fedora releases a kernel update, it might take a few days for the RPM Fusion repository to catch up with the kmod-VirtualBox updates.  And this, of course, might result in your Vagrant setup being broken.

The easiest way to protect against that is to disable automatic kernel, kernel module and VirtualBox updates.  To do so, add the following line to the [main] section of your /etc/yum.conf file, right after your VirtualBox/vagrant setup started to work:

exclude=kernel* kmod-* VirtualBox*

Now, if you forgot to do that a few times got pissed off with this situation (or don’t like Oracle for some reason), you might consider alternatives.  Which are a few.  Vagrant supports a variety of hypervisors.   One of the common alternatives is to use libvirt, which is shipped with Fedora distribution.

Installing libvirt is simple (thanks to this blog post).  Here’s pretty much all you have to do:

yum install libvirt libvirt-daemon libvirt-daemon-qemu virt-manager
service libvirtd restart

The problem that you might realize now is that libvirt is not the most popular provider for boxes in the Vagrant world.  Most people seem to prefer VirtualBox.  But if your choices are satisfied, I’m glad for you.  If they are not, however, there is a work around that you might go for – vagrant mutate plugin.  This plugin converts vagrant boxes from one hypervisor to another.

In order to install this plugin on Fedora 21 you’ll need a few development tools first (this StackOverflow thread definitely helped with the weird g++ error):

yum install ruby-devel gcc-c++ make

Once you have those, install the vagrant plugin with your regular user (the one who will run vagrant VMs):

vagrant plugin install vagrant-mutate

Now you can mutate Vagrant boxes.  Unfortunately, you might find that mutate plugin doesn’t like boxes with slash in their names (like chef/centos-6.5).  The suggested workaround is to either use box names without slashes, or to provide mutate plugin with the box URLs, rather than names.  The official boxes directory doesn’t give you URLs though, so you might be stack with random GitHub repositories or with an alternative directory, like Vagrantbox.es.

My adventures with this aren’t over yet.   Feel free to send suggestions my way.  From my side, here are a couple of other useful links on this subject:

One last bit of advise from me is that until you are absolutely sure that your Vagrant setup works perfectly, stick to 32-bit box images.  There’s nothing like ripping your hair out for three hours only to learn that your host hardware is 32-bit while you are trying to boot into a 64-bit operating system.