Ubuntu 20.04, Nginx, Redmine, Ruby, and Passenger-Phusion confusion

by

Redmine, Ruby, Passenger-Phusion, and Nginx makes for an extremely confusing situation with dependencies, installation “instructions”, and “mismatching” package versions.

Redmine wants Ruby x, your Linux distribution has Ruby y, Passenger-Phusion only works with Ruby z, and you quite often end up in a loop somewhere. This article will not do anything to help that confusion I’m afraid.

On Passenger-Phusion’s website, there’s an interesting explanation as to why you need to let Passenger-Phusion build Nginx for you, unless you can actually use everything pre-packaged, which you cannot if you want to use Ubuntu 20.04.LTS and Redmine 4.1.

Before you begin, you should know that installing Passenger in its Nginx integration mode involves extending Nginx with code from Passenger. However, Nginx does not support loadable modules. This means that in order to install Passenger’s Nginx integration mode, it is necessary to recompile Nginx from source. And that is exactly what we will do in this installation guide.

Now, if you head on over to the Nginx blog, you can read:

NGINX Open Source 1.11.5 and NGINX Plus Release R11 introduced binary compatibility for dynamic modules. This article explains how to compile third‑party modules for use with NGINX Open Source and NGINX Plus in a development environment.

That statement was made for Nginx 1.11. They are, at the time of this writing, at 1.19.

So basically, if you want to run Redmine 4.1 on Ubuntu 20.04.LTS, which ships with Ruby 2.7, and a Passenger-Phusion module that requires Ruby 2.7, you’re on your own since Redmine 4.1 does not support Ruby 2.7. If you use RVM to installed Ruby 2.6.x, you need to manually handle Passenger-Phusion, which eventually requires re-compiling Nginx, regardless of it supporting “dynamic modules”.

There is one small glimmer of hope:
Installing Passenger as a normal or dynamic Nginx module

Using Ubuntu 18.04.LTS, the included Passenger, Nginx, and Ruby all work with Redmine 4.1.x, so that may be a smoother path to take before this is all “fixed”, if it gets fixed.

Checking LSI RAID storage status in Linux

by

Flying blind is no fun and many hardware manufacturers are notoriously bad at providing info tools form their hardware for Linux. If you have an LSI-chipped RAID controller, this may come in handy. The `storcli`utility replaces the MegaCLI utility and is provided by Broadcom.

You can get `storcli`here:
docs.broadcom.com/docs/007.1506.0000.0000_Unified_StorCLI-PUL.zip

(For Debian/Ubuntu distributions, you may need to install `alien` to convert the .rpm to .deb.)

The following script is what I use and it works for me:

#!/bin/bash
#
# Check LSI RAID storage status
#
# This will trigger on the output NOT being "Optl" (Optimal). This works for me,
# your mileage may vary. One problem in using more "verbose output" from the
# storcli64 binary is that it always (?) outputs some sort of legend with all
# the various status types explained, so it always contains the text "Degraded"
# for example. This minor script will simply search for what we want, which is
# a RAID in optimal state, and if NOT found, perform a full status scan and send
# it as an e-mail message to wherever it needs to be sent.
#
# Joaquim Homrighausen <joho@webbplatsen.se>
# 2020-12-15
#

STATUS=`/usr/local/bin/storcli64 /c0 /v0 show nolog |egrep "RAID6 Optl"`;
EGREP=$?

if [ "$EGREP" -ne 0 ]
then
    TO=my.email@address.ext
    STATUS=`/usr/local/bin/storcli64 /c0 show`;
    /usr/sbin/sendmail -i $TO <<MAIL_END
From: root@my.monitored.server
To: $TO
Subject: RAID WARNING @ `hostname`

$STATUS
MAIL_END
fi

Cloudbridge Mattermost

by

Cloudbridge Mattermost is a WordPress plugin that provides integration between WordPress and Mattermost. In the initial release, we focus on login notifications (successful, failed, unknown) from the various WordPress user roles.

We will, of course, be adding more functionality in the future.

You can download it from the official WordPress repository:
wordpress.org/plugins/cloudbridge-mattermost

You can also get it from GitHub, should you prefer that source:
github.com/joho1968/cloudbridge-mattermost

This is the initial release of this plugin.

NCweb 0.0.5, your Nextcloud Web Server

by

NCweb 0.0.5 has been released, yay 🙂

You can grab a copy here if you’re curious about the changes, if not, carry on.

If you want to read more about NCweb, check out the GitHub repository

The initial announcement can be found here

Spoiler alert: This is possibly a completely useless application if you do not run Nextcloud, don’t have PHP or don’t know what PHP is, or don’t run Nginx or Apache. And even if you do meet the criteria, it may still disappoint you as well as being useless to you.

Displaying WordPress roles in the current language

by

While writing a WordPress plugin that displays the available user roles, I came across a snag: the user roles that I had fetched from WordPress weren’t translated into the site’s current language.

I’m not quite sure I understand the reasoning behind this since WordPress offers functions to return an array with the actual role as the key, and the display string as the array value, like:

array( 'administrator' => 'Administrator' );

So why can’t WordPress return the “correct” (i18n) language string for the array value … anyway, there’s a solution.

Looking at how WordPress does it under “Settings > General” in the WordPress Admin, I eventually found a call to translate_user_role(), which requires one parameter, the role array name value, e.g. “Administrator”. The function will then return the correct (language context aware) display string.

So to put it into a functional context, it may look something like this:

function i18n_get_wp_roles() {
    $wp_roles = wp_roles();
    if ( is_object( $wp_roles ) ) {
        $roles = array_keys( $wp_roles->roles );
        $role_names = $wp_roles->get_names();
    } else {
        $roles = false;
        $role_names = array();
    }
    $return_roles = array();
    if ( is_array( $roles ) ) {
        foreach( $roles as $role_k => $role_v ) {
            if ( ! empty( $role_names[$role_v] ) ) {
                $return_roles[$role_v] = translate_user_role( $role_names[$role_v] );
            } else {
                $return_roles[$role_v] = 'Unknown role (' . $role_v . ')';
            }
        }
    } else {
        error_log( basename(__FILE__) . ' (' . __FUNCTION__ . '): wp_roles() returned empty' );
    }
    return( $return_roles );
}

 

Where did my Emacs color-theme go in Ubuntu 20.04.LTS?!

by

Having recently upgraded a small VPS from Ubuntu 18.04.LTS to Ubuntu 20.04.LTS, I ran into a little snag with Emacs and its color-theme (from the emacs-goodies-el package).

After some digging, it seems this is now done somewhat differently in Ubuntu 20.04.LTS.

This is what my .emacs file used to contain:

(require 'color-theme) 
(color-theme-initialize) 
(color-theme-charcoal-black)

This is what I changed it to:

(add-to-list 'custom-theme-load-path 
(file-name-as-directory "/usr/share/emacs/site-lisp/elpa/color-theme-modern-0.0.2"))
(load-theme 'charcoal-black t t) 
(enable-theme 'charcoal-black)

In addition, I also had to install the elpa-color-theme-modern package (from the Ubuntu 20.04.LTS distribution).