Linux

Docker, Arch Linux, and User Namespaces

Docker, Arch Linux, and User Namespaces

I recently tried to run Jess Frazelle's Chrome Docker image, she explains how to do that here. Whilst there is a little bit of understanding needed with what's going on (such as passing X11 through from the host to the container), it's pretty simple.

However, Chrome seemed to break for me every time. At first I couldn't work it out, but help in this Issue Thread showed that the lack of User Namespacing in my kernel was the problem.

The stock Arch Linux Kernel for some reason doesn't seem to have User Namespacing built in. Chrome needs this. The reason Chrome needs this is that the sandboxing security feature needs to utilise namespacing segregation to isolate web page processes. The idea being if they can't interact with anything outside the container, it minimises risk to the other processes on the system.

Unfortunately to enable User Namespacing, you have to enable the feature in a kernel config file and rebuild your Kernel. This isn't an easy process but the Arch Build System can help.

To test you've got User Namespacing enabled successfully, check zgrep CONFIG_USER_NS /proc/config.gz it should return CONFIG_USER_NS=y. Anything else means it is not enabled.

My config.gz for Kernel 4.2.5-1 is here

The image below shows I've got Chrome running in Docker fine now. You can also tell from Archey that I'm running the custom kernel.

Picture of Chrome Running

Using UFW on Fedora

Using UFW on Fedora

When switching to Fedora I was disappointed to find that there was no support for using Uncomplicated Firewall, something I enjoyed on Arch Linux. Although it is not in the Fedora repos, it can still be installed and used.

  • Download the UFW source code from Launchpad
  • Unpack and install the source code. Do this with the traditional 'Untar, Configure, Make'. If you are unfamiliar with compiling software from scratch, the README in the download explains, and a quick google will explain further.
  • Once installed, run systemctl stop iptables to stop the regular iptables firewall process. Do the same for any Fedora Firewall tools like FirewallD systemctl stop firewall.
  • Enable UFW! sudo ufw enable
  • Add your rules as usual! e.g ufw allow 22/tcp, ufw limit 22/tcp

Checking Ink Levels on Epson Printers in Arch and Ubuntu

Relevant to 2013 onwards involving udev and checking ink levels on older printers.

The standard GutenPrint libraries and drivers used by CUPS for printing can talk to Epson Printers well enough so that general printing can take place, test pages, change of print quality etc. However there is no decent means for returning current Ink levels.

There are two programs that allow you to do this – ‘ink’ and ‘escputil’.

These utilities were built when HAL was the dominant hardware-path-allocation tool. Now udev is used. However udev paths can seem convoluted, confusing and unecessarily long. Some guides say that in order to interface with older devices you need to go down /sys/devices/usb/0:0:0:1/1:0:0/-onwards-/

So when using commands like ‘ink’, you don’t know where to point it…

You need to point them at: /dev/usb/lp0 | lp1 | lp2 etc. Why people don’t know to go here, I’ve no idea, but here it is.

The exact commands needed for Ink and Escputil can be found on their websites. – I think ink’s is

sudo ink -d /dev/usb/lp0

Application Menu error in Ubuntu's LuckyBackup package causes various problems

The luckybackup program is a good rsync GUI for conducting backups if you are not comfortable or familiar with using rsync within the terminal. However, I noticed that it uses incorrect permissions when installed in Ubuntu.

When installed using…
<br></br>
sudo apt-get install luckybackup<br></br>

The package comes with a shortcut in Applications>System>luckyBackup (Super User). This means that when running luckybackup all of your configuration folders for the application under ~/.luckybackup get locked up, forcing you to always use Super User (sudo) privileges when running the application. Also, I found that if you have Network Shares currently mounted using gvfs (SAMBA), then the little shortcuts in your file-manager sidebar to these network-mounted locations do not appear. Even if you go the long winded way and visit their true path under /run/user/1000/gvfs, the gvfs symbolic link is greyed out and unavailable.

The reason for this is that the Network locations were bound under your regular 1000 user, but now you are running as a different user which has no idea what to do with the gvfs folder bound to your regular user. Especially irritating if you are trying to use luckybackup across Windows Shares.

To get around this, run the luckybackup command from the terminal or Run bar (Alt-F2) so that it can operate under your normal user, and thereby see and use your network mounts. These Network Mounts will be visible in the sidebar as other ‘currently mounted’ media usually are – convenient. When you click these shortcuts in Lucky Backup, the full path is resolved and placed wherever you wanted it to be in Lucky Backup (Source/Destination folder, probably).

Or, just alter the luckybackup shortcut in your Applications Menu and remove any commands that cause privilege escalation (sudo, su-to-root, etc.).

The Ubuntu maintainer of Lucky Backup should fix this, and it’s not really a bug, just user-error of the Ubuntu package maintainer for luckybackup:

Bug Report Filed – Click Here