I spend a fair amount of time troubleshooting issues on Linux and other Unix and Unix-like systems. While there are dozens of utilities I use for diagnosing and resolving issues, I consistently employ a small set of tools to do quick, high-level checks of system health. These checks are in the categories of disk utilization, memory and CPU utilization, and networking and connectivity. Triaging the health of the system in each of these categories allows me to quickly hone in on where a problem may exist. Read more on Linux Utilities for Diagnostics…
In certain situations, it is desirable to have a read-only root filesystem. This prevents any changes from occurring on the root filesystem that may alter system behavior, and it allows a simple reboot to restore a system to its pristine state. Examples of such applications include kiosks and embedded devices. Using overlayroot on Ubuntu makes creating a read-only root filesystem quick and easy. Read more on Protecting the Root Filesystem on Ubuntu with Overlayroot…
Security patches for libraries and tools come out quite frequently. Just subscribe to any Linux distribution security list, and you’ll find that security updates are released with astounding frequency, sometimes even daily. Even kernel security updates are fairly common, with two security patches being released for the kernel used by Ubuntu 12.04 LTS in June. To keep current with security fixes, I often find it useful to configure servers to perform automatic security updates. If properly configured, automatic updates can mitigate risk and keep any service interruptions to a minimum.
Are Automatic Upgrades a Good Choice?
Most servers I work with are good candidates for automatic security updates; they aren’t running applications sensitive to the minor changes introduced by security updates. Additionally, quick service interruptions at off-hours aren’t an issue. For example, a quick restart of Apache or MySQL at 2am will not be a problem. If a server is particularly sensitive, I will only setup notification of security updates, so that I can control the what and when of any update installation. Read more on Debian and Ubuntu Automatic Security Updates…
A great deal of the time, I work on the command line — usually logged into a remote system, doing some tasks or troubleshooting some problem. Quite often, this involves checking or manipulating something on the filesystem.
There are dozens of filesystem utilities. Most are well-known file manipulation utilities such as
mkdir, etc. However, there are several less familiar, but very powerful tools that I find myself using on a nearly daily basis. The following Linux filesystem utilities are ones I find particularly helpful for diagnosing issues and gathering information to solve problems.
Free Disk Space
Finding the amount of available free disk space is important — especially if a system has a low capacity hard drive or typically runs close to the margins. Whenever I start seeing strange failures on a system, one of the first things I check is disk utilization. The
df command allows me to quickly check if a system is running near disk capacity. Read more on 5 Linux Filesystem Utilities for Diagnostics…
I run Linux at work and at home. Sometimes I need to switch to Windows or Mac for a time, and when I do, I always find myself missing something from my usual environment.
Favorite Linux Desktop Features
Here are a few Linux desktop features that I’ve come to rely on. Read more on Why I Stick with the Linux Desktop…
I’ve been using *nix systems for quite a while. But there are a few commands that I somehow overlooked and I wish I’d discovered years earlier.
1. man ascii
This prints out the ascii tables in octal, hexadeciamal and decimal. I can’t believe I didn’t know about this one until a month ago. I’d always resorted to googling for the tables. This is much more convenient.
ASCII(7) BSD Miscellaneous Information Manual ASCII(7) NAME ascii -- octal, hexadecimal and decimal ASCII character sets DESCRIPTION The octal set: 000 nul 001 soh 002 stx 003 etx 004 eot 005 enq 006 ack 007 bel 010 bs 011 ht 012 nl 013 vt 014 np 015 cr 016 so 017 si 020 dle 021 dc1 022 dc2 023 dc3 024 dc4 025 nak 026 syn 027 etb 030 can 031 em 032 sub 033 esc 034 fs 035 gs 036 rs 037 us
For more information, see the ascii man page. Read more on 5 Unix Commands I Wish I’d Discovered Years Earlier…
When I bought my Macbook a few months ago, one of the hardware choices I made was to get a 128GB solid state drive with it. While I love the performance of my SSD, its small size has given me some problems when trying to manage my disk usage.
A few days ago, I opened the activity monitor and was shocked to see that my machine was reporting less than 4 Gigabytes of free space left on my disk! The worst part was that I had absolutely no idea what was taking up all of that space. Was it all the downloads I had saved from Chrome? My music library?
I recently needed to configure a machine with multiple installations of Ubuntu Server 12.10. One way to go about doing this is to create a separate, small boot partition to store the configuration for an initial Grub boot menu. Each installed OS gets its own partition with its own bootloader configuration. The initial menu stored on the boot partition is used to chainload the bootloader files for whichever OS is selected.
This technique involves using Grub Legacy on the small boot partition to chainload to the Grub2 configuration on each of the OS partitions. Instructions on how to do this can be found in the Ubuntu Lucid Multiple OS Installation guide. The instructions describe a couple of ways to go about getting Grub Legacy on the boot partition. I chose to go the route of installing Ubuntu (12.10 in my case) like normal, then removing Grub2, installing Grub Legacy temporarily, and finally reinstalling Grub2 again once the boot partition had been configured.
I ran into a couple of snags after getting to the Remove Grub 2 and install Grub Legacy part of the instructions, so I am going to duplicate the steps here and insert the couple of additional steps I ended up needing.
Recently, a hosting provider’s ‘upgrade’ dramatically changed the stolen CPU time on one of our systems. I investigated and found that our virtual machine’s CPU allocation had been deprioritized. The rest of the post describes “stolen CPU” and the behavior that we experienced on our virtual machine.
Anyone who runs operating systems (especially UNIX or GNU/Linux) in a virtualized environment has likely noticed the
%st metrics in monitoring and reporting utilities. This stolen CPU metric refers to CPU time “stolen” from the given virtual machine by the hypervisor for other operations. The “stolen” descriptor is unfortunate as the CPU time really isn’t stolen in the sense of misappropriation. The metric really should be named something like “shared” or “reallocated”.
What is “Stolen” CPU?
The “stolen CPU” metric measures how much CPU time was reclaimed by the hypervisor because the virtual machine exceeded its allocated CPU time. In a virtualized environment, various virtual machines (VM’s) are allocated different amounts of time or priorities on resources such as CPU time and RAM. In some cases (RAM allocation), the allocation is very clear because the VM is given exclusive control; in other cases (CPU allocation), it’s much more hazy as the resource is shared simultaneously among many VM’s.
Thinking through some security concerns recently, I found myself wondering if it was possible to achieve full system Linux encryption in the cloud — running GNU/Linux off of an encrypted root partition (using LUKS). I thought that it should have been possible — it was achieved easily running with a local virtualization platform (VirtualBox, VMWare Fusion, etc.).
Since we have used Linode for a few projects, I figured that I would try to setup Linux encryption on Linode, but a quick Google search for “linux encryption on linode” didn’t turn up anything regarding root partition encryption with LUKS. I decided to try and figure it out myself. It turned out to be a bit of a challenge, but one which I’m glad I undertook as I learned a tremendous amount about Linux disk encryption, and how Linode manages the Linux boot process.
In order to achieve this, I consulted several very different resources, iterated several times on my setup process, and learned a great deal about GRUB configuration. Since I think others might find this information useful, I’ve compiled my setup process. The process assumes a working understanding of GNU/Linux, GNU utilities, and dm-crypt (cryptsetup).