I’ve been trying to build Blender from source on CentOS for many years, but never had any luck making it work. There was always one package missing, or something else that needed to be configured. Depressed and resentful, I gave up and never got a chance to try Blender on CentOS.
Every so often, a yum update brings unexpected results with it, like services no longer working due to spurious error messages that don’t tell you what’s actually wrong. This only very rarely happens though, and we may need to revert to the state of our system before such an update took place.
Thankfully, yum has a nice feature that helps us do this, namely yum history.
The command will bring up the latest 20 transactions by default, be those installs, updates or removals. There’s a transaction ID at the very front of each line, with which we can tell yum to undo said transaction. In my case, transaction 86 didn’t work out so well, so let’s undo whatever has happened there (in my case, a combination of installs, updates and overwrites).
Let’s revert those changes with yum history undo 86
The familiar text output comes up, eventually showing a list of packages that will be affected. Confirm those changes with y and let yum do it’s job.
After a few moments, our system has been restored to a state from before the update occurred, hopefully back into a running state.
There’s another interesting option called yum history rollback (ID). This will let us go back more than one step in our list, restoring the changes made by multiple transactions. Vivke’s article has more information on this.
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.