Category: Linux

Fix Music on Console (moc) on Arch Linux

Post author By chris
Post date April 22, 2022
No Comments on Fix Music on Console (moc) on Arch Linux

The Problem

In this quick article I’ll go over the process to fix moc (Music on Console) not starting properly on Arch Linux.

Firstly, at the time of writing this article the current <a href="https://wiki.archlinux.org/title/MOC" target="_blank" rel="noreferrer noopener">moc</a> version is moc-1:2.5.2-5. Future releases may fix the issue described below.

Usually, installing moc on Arch Linux should be a simple case of running the following command:

sudo pacman -S moc

And, in fact, installing moc with pacman will appear to succeed without any issues:

Installing moc using Pacman … looks good, right?

Unfortunately, when you now try to run mocp, the following exception is immediately thrown:

Immediate exception when running `mocp` for the first time

… what the hell?

The Fix

Due to a bug in glibc 2.35, a patch needs to be applied to the moc package build files, after which the package can be rebuilt and the resulting binaries + docs + libs copied over those installed by pacman.

Because this is an Arch Linux article, I’ll assume you already have git installed. Let’s go.

Firstly, grab the moc package build files

git clone -b packages/moc --single-branch https://github.com/archlinux/svntogit-packages

Enter the main source directory and open the PKGBUILD file for editing (use any editor that suits you)

vim PKGBUILD

Modify the source array as follows, making sure to keep the quotes intact:

source=(http://ftp.daper.net/pub/soft/moc/stable/${pkgname}-${pkgver}.tar.bz2{,.sig}
        moc-ffmpeg4.patch
        moc-https.patch
        "glibc-2.35.patch::https://bugs.archlinux.org/task/74041?getfile=21255")

Modify the prepare() function as follows:

prepare() {
  cd $pkgname-$pkgver
  patch -p0 -i ../moc-ffmpeg4.patch # Fix build with ffmpeg 4
  patch -p0 -i ../moc-https.patch  # Allow https for urls https://moc.daper.net/node/1872
  patch -p0 -i ../glibc-2.35.patch # FS74041
}

Save the PKGBUILD file and close the editor
Build the package, making sure to tell the process to skip integrity checks.

makepkg --skipinteg

The man page for the makepkg --skipinteg parameter is as follows:

Do not perform any integrity checks (checksum and PGP) on source files.
makepkg man page, –skipinteg parameter info

When an error occurs indicating the current file being patched can’t be found, it’s a simple case of entering utf8.c and pressing enter:

patching file files.c
can't find file to patch at input line 32
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
<TRIMMED>
File to patch: utf8.c

If the build process is successful, the output will end something like this:

`makepkg --skipinteg` completed, including entering `utf8.c` when prompted

Updating moc Installation

A successful build will result in a new moc package in the pkg directory. The contents of the package’s root directory are nothing more than a usr directory, as follows:

The last step is to copy those files into place, overwriting existing files. This assumes you’ve already changed to the pkg/moc directory.

cd usr
sudo cp -R * /usr

By default there’s no output after copying these files:

Copying newly built `moc` files into place

Test moc

So now there’s only one thing left to do … run mocp!

mocp

`mocp` running after being patched and rebuilt

Disclaimer

Thanks to the participants in the Arch Linux bug tracker for this info. Given the time I spent finding a process that actually worked (poor Google fu, maybe), I’m keeping a record of it here so I can refer back later, if required.

Hope it helps someone.

Tags arch, moc, mocp, patch

Linux

Pop OS/Ubuntu: Detecting USB Security Key Events

Post author By chris
Post date August 25, 2021
No Comments on Pop OS/Ubuntu: Detecting USB Security Key Events

Security keys such as the Yubikey from Yubico have become much more popular in recent times, showing an increased focus on security best practices. Many people are already aware of Multi-Factor Authentication or MFA, since many secure online services (e.g. banks, government portals) have mandated the use of a physical device or one-time access codes before using their services. To learn more about MFA, please check out the Wikipedia article on MFA.

Since you’re here, you know what MFA is so let’s look at what I needed to achieve. Simply:

Upon USB security key insertion or removal, detect that event and “do something” in response.
– My requirements 🙂

My environment:

Pop OS 21.04 Linux (based on Ubuntu)
Yubikey USB security key

What I’m not going to cover:

How to configure your Yubikey for use in Linux. To learn more, please see the official Yubico documentation
Which Linux distributions use or don’t use udev – that’s on you

Get Info About Security Key

For all this to work, we’ll rely on udev. Using the built-in tools that are provided with various Linux distributions, we first need to get some info about your security key. Your output will vary greatly depending on events happening in your system and also on the model of security key you are using.

Disconnect/remove your security key from your system
Open a terminal and start monitoring udev events:

udevadm monitor --property

Successfully starting the monitor will show this:

~ ❯
~ ❯ udevadm monitor --property
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

Note: In the output below, I’ve removed some info and replaced it with [removed].

Insert your security key and note the extensive output shown in your terminal window. The specific section looks like this on my system:

UDEV  [52954.592536] add      /devices/pci0000:40/0000:40:01.1/0000:41:00.0/0000:42:08.0/0000:48:00.3/usb9/9-4/9-4:1.0/0003:1050:0407.001C/input/input40/event6 (input)
ACTION=add
DEVPATH=/devices/pci0000:40/0000:40:01.1/0000:41:00.0/0000:42:08.0/0000:48:00.3/usb9/9-4/9-4:1.0/0003:1050:0407.001C/input/input40/event6
SUBSYSTEM=input
DEVNAME=/dev/input/event6
SEQNUM=28039
USEC_INITIALIZED=52954592318
ID_INPUT=1
ID_INPUT_KEY=1
ID_INPUT_KEYBOARD=1
ID_VENDOR=Yubico
ID_VENDOR_ENC=Yubico
ID_VENDOR_ID=1050
ID_MODEL=[COPY_THIS_VALUE]
ID_MODEL_ENC=[removed]
ID_MODEL_ID=[removed]
ID_REVISION=[removed]
ID_SERIAL=[removed]
ID_TYPE=hid
ID_BUS=usb
ID_USB_INTERFACES=:030101:030000:0b0000:
ID_USB_INTERFACE_NUM=00
ID_USB_DRIVER=usbhid
.INPUT_CLASS=kbd
ID_PATH=pci-0000:48:00.3-usb-0:4:1.0
ID_PATH_TAG=pci-0000_48_00_3-usb-0_4_1_0
XKBLAYOUT=au
BACKSPACE=guess
XKBMODEL=pc105
XKBVARIANT=
XKBOPTIONS=
ID_SECURITY_TOKEN=1
ID_FOR_SEAT=input-pci-0000_48_00_3-usb-0_4_1_0
.LOCAL_ifNum=00
LIBINPUT_DEVICE_GROUP=3/1050/407:usb-0000:48:00.3-4
MAJOR=13
MINOR=70
DEVLINKS=[removed]
TAGS=:uaccess:power-switch:seat:
CURRENT_TAGS=:uaccess:power-switch:seat:

Three things are of particular interest here:
- ACTION is add
- SUBSYSTEM is input
- ID_MODEL is YubiKey_[some_stuff_here] – note down the value of this property now, as you’ll need it shortly
Remove your security key and again note the extensive output shown in the terminal. The relevant block looks similar to before but with one main difference:
- ACTION is remove
Hit Ctrl-C to stop the udev monitoring

Now that we have the necessary info about our security key, we can proceed.

The “Do Something” Part

The “do something” part of this article will be different for everyone, meaning the scripts below are examples only. Here are the components of this setup:

Script called yubikey, located in my home directory:

#!/bin/bash

if [ "$1" == "removed" ]
then
    echo "Oi, Yubikey has been removed!" > /home/me/yubikey_status.txt
else
    echo "K, Yubikey found.  Secure all the things!" > /home/me/yubikey_status.txt
fi

Text file named yubikey_status.txt in my home directory:

unknown

The watch command can be used to monitor file contents:

watch cat ~/yubikey_status.txt

Reacting to a security key removal event will likely be accompanied with an action such as locking the screen, sending an email or displaying a message. For now, this is what we’ll see:

Every 2.0s: cat /home/me/yubikey_status.txt

unknown

Detecting Security Key Insertion/Removal

udev will be used to handle the USB insertion/removal events, using custom udev rules stored in /etc/udev/rules.d.

Privilege escalation via sudo (or similar) will be required to create and edit these files.

To learn more about how these files are named, please see the official udev documentation.

Create a file named /etc/udev/rules.d/90-yubikey.rules, containing the following content:

ACTION=="add", SUBSYSTEM=="input", ENV{ID_MODEL}=="[ID_MODEL_COPIED_EARLIER_GOES_HERE]", RUN+="/home/me/yubikey inserted"
ACTION=="remove", SUBSYSTEM=="input", ENV{ID_MODEL}=="[ID_MODEL_COPIED_EARLIER_GOES_HERE]", RUN+="/home/me/yubikey removed"

These udev rules complete the following actions:

Watches for both add and remove events
Matching events must occur in the INPUT subsystem
The matching events must occur for devices matching the specified ID_MODEL
When a matching event occurs, the ~/yubikey script executes
- inserted command-line parameter if the device was added
- removed command-line parameter if the device was removed
The ~/yubikey script will write content to the ~/yubikey_status.txt file depending on the value of the $1 parameter i.e. the first parameter on the command line

Reloading `udev` Configuration

We can dynamically reload the udev rules by running the following command:

sudo udevadm control --reload

Testing

Run the watch command above if it’s not already running
Insert your security key
If everything has been configured correctly and your udev rules have been reloaded, you’ll see the watch command output change as follows:

Every 2.0s: cat /home/me/yubikey_status.txt

K, Yubikey found.  Secure all the things!

Conversely, removing the security key will run the script again, causing the output to change as follows, as the contents of the ~/yubikey_status.txt file changes:

Every 2.0s: cat /home/me/yubikey_status.txt

Oi, Yubikey has been removed!

Wrapping Up

That’s all there is to it. Hopefully this was useful for someone.

Tags ubuntu, udev, yubikey

Archived Linux Mac & OS X Uncategorized

A couple more BASH prompt examples

Post author By chris
Post date May 9, 2011
No Comments on A couple more BASH prompt examples

Yesterday I published an article called "Pimp My Prompt … like Paul Irish" in which I showed how to make your BASH prompt similar to the one used by Paul Irish.

I also included a couple of sample prompts that you could use for reference so I figured I’d write a follow-up article that shows what they look like. So, without any further ado, here they are.

Example 1 – Green username, blue host, magenta working directory, white git branch:

PS1='${GREEN}u${BLACK}@${CYAN}h:${MAGENTA}w${WHITE}`__git_ps1 " (%s)"`$ ‘

The example above uses the short colour codes outlined in the original article and looks like the screenshot below.

Green username, blue host, magenta working directory

Example 2 – Blue user and host, magenta working directory, white git branch:

PS1='[33[0;36m]u@h[33[01m]:[33[0;35m]w[33[00m][33[1;30m][33[0;37m]`__git_ps1 " (%s)"`[33[00m][33[0;37m]$ '

The example above uses the built-in colour codes but can be harder to read. It looks like the screenshot below.

Blue user and host, magenta working directory, white git branch

Don’t forget to read the original article, "Pimp My Prompt … like Paul Irish", if you’re unsure about how to enable the __git_ps1 and short colour code commands.

Archived Linux Mac & OS X Uncategorized

Pimp My Prompt … like Paul Irish

Post author By chris
Post date May 8, 2011
1 Comment on Pimp My Prompt … like Paul Irish

There’s been a lot of talk lately about those cool colours that Paul Irish uses in his videos. If you don’t know who Paul Irish is and you dabble in a bit of web design … well … shame on you! 😉 The things referenced in this article, including the prompt, can be found in Paul’s YouTube video entitled "The Build Script of HTML5 Boilerplate: An Introduction". Anyway, I think the prompt colours are pretty useful, especially if you’re speedy at navigating your way around the CLI/shell in Linux or OS X and want to see where you are very quickly.. They help identify where you are in the file system, whether or not your current working directory is a git branch and, depending on what options you set, whether or not there are untracked files present etc.

Here’s what Paul’s prompt looks like (screenshot from the video linked above).

I believe Paul is using iTerm, as am I. Combined with the stuff below, my iTerm configuration looks like this:

Pimp my prompt!

Ok, so you want your prompt to look like that? It’s not that hard, actually. You have to grant me a little latitude, though, as I’m guessing what Paul uses the various CLI prefix symbols for. In this example I’m using an "o" to indicate a working outside a git branch and a + to indicate that the current working directory is a git branch.

This only works if you’re running an OS X or Linux shell – I’m sure you can do it with Windows but I’m not going to cover that here.

Step 1

If you haven’t got one already, open or create a file called .bash_profile in your home (~) folder. You might be asking why not use .bashrc? We want the command we’re adding to apply to interactive login shells – .bashrc only applies to interactive non-login shells. There is an exception to this if you’re using OS X (like me) – .bash_profile is run for each new Terminal.app window, by default.

If a file with that name already exists, make sure you don’t remove anything from it that you want to keep. From here I’m going to explain what each part of my .bash_profile does. The complete file will be shown at the end, including a couple of extra bits.

Note: If you’re going to include the git parts, you’ll need to download the git source and put the file .git-completion somewhere (mine is in my home directory).