The Apache web server has a convenient feature called Name-based Virtual Hosting. This function allows us to have a single LAMP Stack server configured on one IP address, but serve a different set of files depending on which domain is being requested.
This sounds more complicated than it is. Say we had example1.com and example2.com, both of which are to be separate websites, but both domains point to the same IP address. Apache’s Name-based Virtual hosting makes this possible. In fact, this feature forms the basis of 90% of this planet’s shared hosting business.
By default, CentOS 7 comes with support for PHP 5.4. Sadly that version has reached the end of its life in 2015and is no longer updated by the developers. If we want to stay up to date with the latest software, we may want to upgrade (if our applications are working with newer versions of PHP).
For CentOS users this either means to compile cutting edge versions from source and tweaking lots of scary system configurations – or dipping into the power of Software Collections. These are official pre-compiled packages by the software vendor, designed to run newer versions of software alongside those that are provided by default.
At the time of writing, PHP 7.2 is available but it’s not part of the software collections yet, so we’ll use PHP 7.1 with FPM support under Apache (as it’s the recommended way to do so).
I had an issue with one of my servers the other day: its power supply died unexpectedly during a scheduled restart. The poor thing never cam back up again.
Lucky for me, the data centre could simply swap out my hard disks and put them into another server. Although my data was save, the server wouldn’t connect to the network anymore – because it had a new MAC address. CentOS stores this value in two of its files, and when it changes (which is hardly ever the case), those files need to be updated.
From time to time, the yum package manager may encounter issues with duplicate packages that are erroneously installed on a system. This manifests in a yum update going awry, telling us something along the lines of this:
I have recently installed PHP 7 from source on a fresh minimal CentOS 7 box. No previous version of PHP was installed, and I thought I’d give 7 a spin. There were a few pitfalls I hadn’t come across before, so here’s what worked for me.
Downloading and extracting the source code
It sounds crazy, but this was the hardest part of the whole installation! There were two problems I’ve encountered here.
The first was that PHP offer downloads via a mirror. A direct link may look something like this: http://php.net/get/php-7.0.12.tar.bz2/from/this/mirror. This means that if we were to download this file using wget, it would be saved as “mirror”. Now what we want.
So instead we can ask wget to give the download a different name using the -O parameter, like so:
This will save our file as php7.tar.bz2 instead. So far so good. Unpacking this file seems to be impossible. From what the internet tells me, this should be the correct way of extracting a tar.bz2 file:
But that didn’t work, not matter how hard I tried. All I ever got was a “non-recoverable” error. Which sucks. In the end I extracted the file on my Mac, created a ZIP archive and downloaded that instead. Unnecessarily cumbersome and idiotic, but worked. Finally I had them on my CentOS box.
Building the source code
Jumping into the extracted directory, the configure command can prepare the build. At this stage I encountered an error:
configure: error: xml2-config not found. Please check your libxml2 installation.
This can be fixed by installing the libxml2-devel package (NOT libxml2 as the error would have you believe). Let’s do that and run configure again:
yum install libxml2-devel
Now we can run make, followed by make test to see if the installation is going to go well. This will take a few minutes.
Feel free to skip “make test” if you’re in a hurry. In my case, after over 10.000 tests, PHP told me this:
Youmay have foundaproblem inPHP.
Thisreport can be automatically sent to the PHPQAteam at
http://qa.php.net/reports and http://news.php.net/php.qa.reports
Thisgives usabetter understanding of PHP's behavior.
If you don'twant to send the report immediately you can choose
option"s"to save it.Youcan then email it to email@example.com later.
Perplexed yet unfazed, I continued on and installed PHP anyway:
And only moments later, PHP 7 was running on my CentOS system.
I was working on a CentOS 7 server the other day that had a LAMP stack installed. It was used to host only a single instance of WordPress.
Upgrading themes and plugins from the admin interface worked fine, but curiously, WordPress core upgrades did not. Instead, WordPress was asking for FTP details every time, which also prevented auto upgrades from being installed.
This didn’t make any sense because there was no FTP server installed on the box, nor had there ever been one. But it did indicate that WordPress had an issue with overwriting core files.
The first thing I checked was that the /var/www/html directory had the correct file and ownership permissions. It all looked correct, even though I did manually set them again just to make sure. Without success. WordPress was still asking for FTP credentials.
After some research, I found that there is a setting for how WordPress accesses the filesystem when it’s upgrade time. We can define it with a constant called FS_METHOD in wp-config.php. The ins and outs are explained in the codex, under Upgrade Constants:
FS_METHOD forces the filesystem method. It should only be “direct”, “ssh2”, “ftpext”, or “ftpsockets”. Generally, you should only change this if you are experiencing update problems. If you change it and it doesn’t help, change it back/remove it. Under most circumstances, setting it to ‘ftpsockets’ will work if the automatically chosen method does not. Note that your selection here has serious security implications. If you are not familiar with them, you should seek help before making a change.
(Primary Preference) “direct” forces it to use Direct File I/O requests from within PHP. It is the option chosen by default.
(Secondary Preference) “ssh2” is to force the usage of the SSH PHP Extension if installed
(3rd Preference) “ftpext” is to force the usage of the FTP PHP Extension for FTP Access, and finally
(4th Preference) “ftpsockets” utilises the PHP Sockets Class for FTP Access.
So on this particular server, for whatever reason, WordPress did not choose the first method (direct), even though it should have. Defining this constant manually did the trick, all I had to do was add this line to my wp-config.php file:
// explicitly use direct mode and stop asking for FTP details
Now updates are working as expected. I’ve never seen this problem on LAMP stacks before. Guess you learn something new every day.
I’ve recently come across a tarsal files that used xz compression (namely the Python source code).
This means that my usual way of extracting a tarsal via the command line using the following command did not work:
gzip: stdin: notingzip format
tar: Childreturned status1
tar: Erroris notrecoverable: exitingnow
That had me stumped! Turns out that files with a tar.gz ending can be extracted this way (because the use gzip compression, specified by the z parameter). If tar is instructed to use this format on a tar.xz file, it fails.
The solution: specify the xz compression, using the capital letter J, like this:
[massive list of files goes here]
Another Linux mystery solved – thanks to Justin Solver for this tip!
In CentOS 7 we can use the systemctl command to select which mode the OS boots into. If you have a GUI like Gnome or KDE installed, it’s easy to boot directly into your preferred environment.
To find out what mode CentOS is currently using, use this:
This will give you one of two “targets”, either
multi-user.target (the command line), or
graphical.target (the Windows-like GUI)
To change from one to the other, use one of these commands:
What happened to runlevels?
In previous versions of CentOS, switching boot modes was achieved through runlevels. Those were saved in /etc/inittab, but this file is no longer used by CentOS 7 and above. However, the file still exists and contains a little extra info this matter, including how to change boot modes: