Today, I detail how to get the "message of the day" on Ubuntu

Why "message of the day"?

A long-standing tradition on Unix and Linux servers is to emit a "message of the day" when somebody logs in to the server. Often these are setup to only display to the user the first time they login for the day (hence "of the day").

In the old days, this was generally found in /etc/motd, and would be manually updated by systems admins on the machine.

What's changed?

In today's world, the operating system will often have a way to aggregate messages, which simultaneously allows the OS to inject important information: OS and kernel version, uptime, whether or not security patches are available, and more.

On Ubuntu systems, these are pushed to the directory /etc/update-motd.d, and each is a script that can be run to emit information. By using this approach, a script can run commands and determine if anything needs to be communicated, ensuring that you only get up-to-date information.

However... this means you can't just run cat /etc/motd anymore in case you missed it, or your session is still active, or, if you use Linux on the desktop, you want to see it, but are in a graphical shell and never got to see the message.

So, how do you do it?

sudo run-parts /etc/update-motd.d`

Advent 2023: MOTD on Ubuntu was originally published 6 December 2023 on https://mwop.net by Matthew Weier O'Phinney.

Except this time, it wasn't. Due to updates I installed, I was getting errors first with compiling the GD extension, then with ext-intl:

• If you want Freetype support in ext-gd, you are expected to install the package libfreetype-dev. On Ubuntu, this now installs libfreetype6-dev, which no longer includes the freetype-config binary that PHP's configure script uses to determine what features it supports.

• Similarly, ext-intl depends on the package libicu-dev. Ubuntu's package now omits the icu-config binary used by PHP to determine feature support.

I searched for quite some time to find packages that would resolve these problems. I could have found the source code and compiled it and linked to that, but that would mean keeping that up-to-date on top of my PHP installs.

I even looked in the ondrej/php PPA, as that repository has multiple PHP versions already, including source packages.

And then I thought: why not try using those instead of phpbrew?

The rest of this post is how I made that work.

I use Ubuntu for my operating system. The instructions I present here should work on any Debian-based system, but your mileage may vary. If you are using an RPM-based system, yum will be your friend, but I have no idea how to add repositories in that system, nor if update-alternatives is available. As such, these instructions may or may not help you.

Which is okay. I mainly wrote them to help future me.

Register the PPA

First, I had to add the PPA to the system:

$ sudo add-apt-repository ppa:ondrej/php

Then the usual:

$ sudo apt update

Approach to installation

I first identified the extensions I typically install, matched them to packages in the PPA, and made a list. I knew I'd be installing the same extensions across all PHP versions I wanted, so I figured I could script it a bit.

From there, I executed the following from the CLI:

$ for VERSION in 5.6 7.0 7.1 7.2 7.3;do
for> for EXTENSION in {listed all extensions here};do
for for> sudo apt install php${VERSION}-${EXTENSION}
for for> done
for> done

This grabbed and installed each PHP I needed along with all extensions I wanted.

Switching between versions

To switch between versions, you have two options:

• Use the version-specific binaries: /usr/bin/php5.6, /usr/bin/php7.0, etc.

• Set a default via update-alternatives:

  $ sudo update-alternatives --set php /usr/bin/php5.6
  

  If you're not sure what you have installed, use:

  $ sudo update-alternatives --config php
  

  which will give you a listing, and an ability to select the one to use.

Rootless alternatives

What if you'd rather not be root to switch the default version, though? Fortunately, update-alternatives allows specifying alternate config and admin directories.

Define the following alias in your shell's configuration:

alias update-my-alternatives='update-alternatives \
 --altdir ~/.local/etc/alternatives \
 --admindir ~/.local/var/lib/alternatives'

Additionally, make sure you add $HOME/.local/bin to your $PATH; since defining $PATH varies based on the shell you use, I'll leave that for you to accomplish.

If you open a new shell, the alias will now be available; alternately, source the file in which you defined it to have it take effect immediately.

Once you've done that, you can run the following, based on the PHP versions you've installed:

$ for VERSION in 5.6 7.0 7.1 7.2 7.3;do
for> update-my-alternatives --install $HOME/.local/bin/php php /usr/bin/php${VERSION} ${VERSION//./0}
for> done

This will create alternatives entries local to your own user, prioritizing them by version; as a result, the default, auto-selected version will be the most recently installed.

You can verify this by running update-my-alternatives --config php:

There are 5 choices for the alternative php (providing $HOME/.local/bin/php).

  Selection    Path             Priority   Status
------------------------------------------------------------
* 0            /usr/bin/php7.3   703       auto mode
  1            /usr/bin/php5.6   506       manual mode
  2            /usr/bin/php7.0   700       manual mode
  3            /usr/bin/php7.1   701       manual mode
  4            /usr/bin/php7.2   702       manual mode
  5            /usr/bin/php7.3   703       manual mode

Press <enter> to keep the current choice[*], or type selection number:

To switch between versions using the alias:

• Switch to a specific, known version:

  $ update-my-alternatives --set php /usr/bin/php{VERSION}
  

• Switch back to the default version (version with highest priority):

  $ update-my-alternatives --auto php
  

• List available versions:

  $ update-my-alternatives --list php
  

• Interactively choose a version when you're not sure what's available:

  $ update-my-alternatives --config php
  

The above was cobbled together from:

• https://serverfault.com/a/811377
• https://williamdemeo.github.io/linux/update-alternatives.html

PECL

Compiling and installing your own extensions turns out to be a bit of a pain when you have multiple PHP versions installed, mainly because there is exactly one PECL binary installed.

First, you need to install a few packages, including the one containing PEAR (PECL uses the PEAR installer), and the development packages for each PHP version you use (as those contain the tools necessary to compile extensions, including phpize and php-config):

$ sudo apt install php-pear
$ for VERSION in 5.6 7.0 7.1 7.2 7.3;do
for> sudo apt install php${VERSION}-dev
for> done

Compiling extensions

From there, you need to:

1. Ensure the correct phpize and php-config are selected.
2. Install the extension.
3. Tell PECL to deregister the extension in its own registry.

Normally, you would accomplish the first point by doing the following:

$ sudo update-alternatives --set php /usr/bin/php7.3
$ sudo update-alternatives --set php-config /usr/bin/php-config7.3
$ sudo update-alternatives --set phpize /usr/bin/phpize7.3

Note that the above is not using the update-my-alternatives alias detailed in the previous section. This is because extensions must be installed at the system level.

That said, the above won't be necessary, as I detail below.

However, PECL now has a really nice configuration flag, php_suffix, that allows specifying a string to append to each of the php, phpize, and php-config binary names. So, for example, if I specify pecl -d php_suffix=7.3, the string 7.3 will be appended to those, so that they become php7.3, phpize7.3, and php-config7.3, respectively. This ensures that the correct scripts are called during the build process, and that the extension is installed to the correct location.

As for the last point in that numbered list, it's key to being able to install an extension in multiple PHP versions; otherwise, each subsequent attempt, even when using a different PHP version, will result in PECL indicating it's already installed. The -r switch tells PECL to remove the package from its own registry, but not to remove any build artifacts.

As a complete example:

$ sudo pecl -d install php_suffix=7.3 swoole && sudo pecl uninstall -r swoole

Registering extensions

From there, you still have to register, and optionally configure, the extension. To do this, drop a file named after the extension in /etc/php/${PHP_VERSION}/mods-available/${EXTENSION}.ini, with the following contents:

; configuration for php ${EXTENSION} module
; priority=20
extension=${EXTENSION}.so

Now that this is in place, enable it:

$ sudo phpenmod -v ${PHP_VERSION} -s cli ${EXTENSION}

(To disable it, use phpdismod instead.)

Thoughts

When thinking in terms of phpbrew:

• Like phpbrew, you can temporarily choose an alternative PHP binary by simply referring to its path. With phpbrew, this would be something like ~/.phpbrew/php/php-{PHP_VERSION}/bin/php. With the ondrej PPA, it becomes /usr/bin/php{PHP_MINOR_VERSION}. (E.g. ~/.phpbrew/php/php-7.2.36/bin/php would become just /usr/bin/php7.2.)

• There is no equivalent to phpbrew use. That feature would change the symlink only for the duration of the current terminal session. Opening a new terminal session would revert to the previous selection. With update-alternatives, it's all or nothing. I mainly used phpbrew use to ensure my default PHP did not change in case I forgot to call it again.

• Usage of update-alternatives is more like phpbrew switch, as it affects both the current and all later terminal sessions. Once switched, that selection is in use until you switch it again. This means I have to remember to switch to my default version. However, it's relatively easy to add a line to my shell profile to call update-my-alternatives --auto php.

Basically, if you can use the binary directly, but don't want to use that one as your default, refer to it by absolute path. If you are using a command that will use the current environment's PHP, use update-my-alternatives to switch PHP versions first.

The other issue I see is that if I want to test against a specific PHP version, I'll still need to compile it myself — which leads me back to the original problem that led me here in the first place. I'll cross that bridge when I get to it. Until then, I have a workable solution — and finally a single document I can refer to when I need to remember again at a later date, instead of cobbling it together from multiple sources!

Updates

• 2020-04-16: fixes reference to PPA in command that adds it to system.
• 2019-05-01: added breakpoint so that full post is not presented in lists.

Managing Multiple PHP versions via the ondrej/php PPA was originally published 30 April 2019 on https://mwop.net by Matthew Weier O'Phinney.

That said, just as with any desktop environment, I've still run into problems now and again. One that's been plaguing me since at least the 18.04 release is with display of app indicators, specifically those using legacy system tray APIs.

Normally, gnome-shell ignores these, which is suboptimal as a number of popular programs still use them (including Dropbox, Nextcloud, Keybase, Shutter, and many others). To integrate them into Gnome, Ubuntu provides the gnome-shell extension "kstatusnotifieritem/appindicator support" (via the package gnome-shell-extension-appindicator). When enabled, they show up in your gnome-shell panel. Problem solved!

Except that if you suspend your system or lock your screen, they disappear when you wake it up.

Now, you can get them back by hitting Alt-F2, and entering r (for "restart") at the prompt. But having to do that after every time you suspend or lock is tedious.

Fortunately, I recently came across this gem:

$ sudo apt purge indicator-common

This removes some packages specific to Ubuntu's legacy Unity interface that interfere with how appindicators are propagated to the desktop. Once I did this, my appindicators persisted after all suspend/lock operations!

Fixing gnome-shell app indicators in Ubuntu was originally published 2 April 2019 on https://mwop.net by Matthew Weier O'Phinney.

Fortunately, I could switch over to a TTY prompt (using Alt+F1), so I had some capacity to try and fix the situation. The question was: what did I need to do?

Go Back To Basics

While the Linux kernel was recognizing my Radeon 6750, and even the X server had no problems detecting it and setting it up, I still faced a display issue. Fortunately, there's a fix for that: remove the proprietary drivers.

The steps for removing the proprietary drivers are as follows:

$ sudo apt-get purge 'fglrx*'
$ sudo update-alternatives --remove-all x86_64-linux-gnu_gl_conf
$ sudo apt-get install --reinstall libgl1-mesa-dri libgl1-mesa-glx

Some people will tell you then to reinstall the fglrx drivers Ubuntu ships, or even the "fglrx-updates" set, but I found it best to go all the way back to basics.

After executing the above steps, reboot so that they drivers are present in the kernel.

Once you do, you can try your luck with the proprietary drivers, using the "Additional Drivers" tool built into Ubuntu. I personally found that neither the proprietary fglrx drivers, fglrx-updates, nor the official AMD Catalyst sources worked — and, after each failed attempt, I'd run the above to get back to a working state.

My conclusion is that the proprietary drivers are likely not yet tested with the kernel sources currently in use by 14.10. Fortunately, the OSS variants with which Ubuntu ships appear to be quite stable, and cover all the features that the proprietary versions covered previously.

As always with a post like this: your mileage may vary. Hopefully the steps above will help at least a few of you; they worked for me on both my workstation and laptop.

Fixing AMD Radeon Display Issues in Ubuntu 14.10 was originally published 3 November 2014 on https://mwop.net by Matthew Weier O'Phinney.

I'll say this: the setup is much faster! However, we had a few gotchas that surprised us — it didn't setup our RAID array out-of-the-box, which led to a good hour of frustration as we tried to verify that the install wouldn't wipe it, and then to verify that we could re-assemble it. (We succeeded.) Additionally, we second-guessed a few things we shouldn't have, which led to needing to back out and reconfigure. But what was over a 12 hour install with Gentoo we accomplished in a matter of a few hours with Ubuntu server — so it was a huge success that way.

Unfortunately, our mysqldump of all databases… wasn't, a fact we discovered only after importing it into the new system. I ended up losing my blog database and PEAR channel database. Fortunately, the PEAR channel has not changed at all in the past year, so we had an old backup that worked, and I had a snapshot of my blog database from three weeks ago I was able to use. As a result, there are a few missing entries, but for the most part, all works. If you commented on one of those missing entries, my apologies.

Now that the install is done, I'm also finalizing some design changes to my blog — it's time to leave the black and white for more colorful grounds. Look for a revamp in the coming weeks!

Server Upgrades... lost entries... was originally published 16 May 2008 on https://mwop.net by Matthew Weier O'Phinney.

I'd been having some issues with fonts following a session at ZendCon where I hooked my laptop up to a widescreen display, and the updates fixed all those issues. Most things that worked before continued to work, and often in an improved way. The various new themes available — from GDM to GTK to window manager themes — make for some pretty displays, and I've found a new look for my desktop that I really like.

Among the improvements, it installed trackerd, a desktop search tool. I'd tried installing this on my own before, but ran into a ton of dependency issues I couldn't fix. Prior to this, I'd used beagle, which worked okay, but tended to overlook a lot of files. Trackerd, on the other hand, indexed my entire box overnight, and stays on top of new files easily. Couple this with the 'deskbar', and I now have the type of desktop search I've only seen in Macs.

Last night, I stumbled upon a forum thread detailing how to get X compositing working with ATI cards. This was something I've been continually disappointed with; my card supposedly supports it, but every time I've tried using it, I find it unusable — lots of wierd screen artifacts, and a huge slowdown in responsiveness. After following the directions in the linked article, however, I now have compositing going — window drop shadows, translucency for inactive windows, etc. It looks really nice, and doesn't seem to be slowing down the machine at all.

No review would be complete without a gripe though, right? And I've got a big one. In the past, one of the strengths of ubuntu for me has been that suspend and hibernate have just worked. With this upgrade, however, they no longer work for me. Evidently, a new kernel option was enabled that is supposed to speed up these operations… However, the available ATI drivers do not support this option, which leads, in my case, to a complete inability to suspend or hibernate, and for others, lockup on resume. Supposedly ATI will be releasing new drivers that will fix the issue, but there's no published time frame for when that will happen. Additionally, ubuntu made no announcements about the issue, and provides no workarounds. To me, this is a huge BC break, and should have been addressed prior to the release, particularly as there were many, many complaints about it in the weeks prior to the release.

Gripes aside, I find the new functionality fantastic, and look forward to ATI's release of new drivers for its Radeon series cards. Perhaps this release will keep me happy enough that I won't keep lusting for a shiny new Macbook too much.

Updates

• 2016-07-04: Updated the link to the forum thread to point to an archived version on the Wayback Machine.

Gutsy Gibbon review was originally published 20 October 2007 on https://mwop.net by Matthew Weier O'Phinney.