Ubuntu Freezes When Booting with Degraded Raid

I tried testing my software raid (mdadm) setup by removing one of the disks. When I tried to boot the degraded system, the system hanged displaying a purple screen. If I try booting the system in recovery mode, I get the following error:

** WARNING: There appears to be one or more degraded RAID devices ** The system my have suffered a hardware fault, such as a disk drive failure. The root device may depend on the RAID devices being online. Do you wish to start the degraded RAID? [y/N]:
** WARNING: There appears to be one or more degraded RAID devices **
The system my have suffered a hardware fault, such as a disk drive failure. The root device may depend on the RAID devices being online.
Do you wish to start the degraded RAID? [y/N]:
Continue reading Ubuntu Freezes When Booting with Degraded Raid

Securing Access to phpMyAdmin on Lighttpd via SSH

phpMyAdmin lets easily manage your MySQL databases, as such it also presents a security risk. Logging in to phpMyAdmin is done using a username and password for the database. Hence, if someone is able to either eavesdrop or guess by brute-force the username and password could wreak havoc of your server.

A possible solution to the eavesdropping problem, is to use SSL to secure the communication to the phpMyAdmin. However, SSL certificates don’t present any method to stop brute-forcing. To prevent brute-forcing attempts, you could limit access to your IP address. However, most of us don’t have static IPs at home. The solution I came up with, kinds of combines both approaches.

Instead of using SSL to encrypt the data sent, I’m using SSH and instead of limiting access to my IP address, I’ll limit access to the server’s IP address. How will it work? First we start by editing the phpMyAdmin configuration for lighttpd. This usually resides in /etc/lighttpd/conf-enabled/50-phpmyadmin.conf. At the top of the file you’ll find the following lines:

alias.url += (
        "/phpmyadmin" => "/usr/share/phpmyadmin",
)

These lines define the mapping to the phpmyadmin installation, without it the phpMyAdmin wouldn’t be accessible. We use lighttpd’s conditional configuration to limit who is able to use that mapping by changing the above lines to:

$HTTP["remoteip"] == "85.25.120.32" {
        alias.url += (
                "/phpmyadmin" => "/usr/share/phpmyadmin",
        )
}

This limit access to the phpMyAdmin only to clients whose IP is the server’s IP (of course you’ll need to change that IP to your server’s IP). This stops curtails any brute-forcing attempts, as only someone trying to access the phpMyAdmin from the server itself will succeed.

But how can we “impersonate” the server’s IP when we connect from home? The easiest solution would be to use to the SOCKS proxy provided by SSH.

ssh user@server.com -D 1080

This will setup a SOCKS proxy on port 1080 (locally) that will tunnel traffic through your server. The next step is to instruct your browser of OS to use that proxy (in Firefox it can be done via Preferences->Advanced->Network->Connection Settings, it can also be defined globally via Network Settings->Network Proxy under Gnome). This achieves both of our goals. We are now able to connect to the server while using its own IP and our connection to the server is encrypted using SSH.

This method can be used to secure all kinds of sensitive applications. We could have achieved the same thing by using a VPN, but it’s more hassle to setup compared to SSH which is available on any server.

Sending Desktop Notification from Cron

Usually when one wants to keep track of one’s cron jobs, one tells the cron daemon to email the output of the commands. While this is probably the best solution for servers, on desktop machines is problematic. Many ISPs block outgoing traffic on port 25 (SMTP), and if you want to send the emails via external SMTP server (such as GMail) this requires you to store authentication details in plain text. A better solution for the desktop would be to harness the desktop notifications available in Ubuntu.

There is a useful tool called notify-send which is able to send desktop notifications directly from the command line. However, there are few caveats:

  • notify-send expects its input on the command line, it can’t read from stdin.
  • If you run from cron you must tell it which display to use.

The first issue can be worked around by using cat to pick up the input. The second issue is handled by adding a DISPLAY environment variable to the crontab. So your crontab will look something like this:

DISPLAY=:0
10 1 * * sun some_cool_command | notify-send "Backup Documents" "$(cat)"

The first argument to notify-send is the title of the notification. The second is the actual text to appear in it, in our case it’s whatever comes in the stdin. If you want to store the output in a log file as well as displaying it in a desktop notification, you can use tee, which basically saves its input to a given file and also pipes it again to stdout.

DISPLAY=:0
10 1 * * sun some_cool_command | tee -a ~/some_log.log | notify-send "Backup Documents" "$(cat)"

Auto-Detect Dependencies when Building .debs Using CMake

CMake (via CPack) as a great feature that allows you to automatically generate Debian/Ubuntu (.deb) packages. One of the annoying things to do when you create a package is listing its dependencies. CMake asks you do it via the CPACK_DEBIAN_PACKAGE_DEPENDS variable. For example:

set (CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>=2.7-18)")

But what happens when you work on a more complex project? Keeping track of all the dependencies by hand is a tedious task. Debian provides a tool named dpkg-shlibdeps which makes this task easier by updating the debian/control file with dependencies extracted from the dynamic libraries needed by a given executable. Luckily since CMake 2.8.3, CMake also supports running this tool automatically to figure out the required dependencies. The documentation is sparse, and I had hard time finding how to do so (I actually found it via a bug report and a commit message, but afterwards I’ve seen it the official documentation too). To enable it, you need to add the following line to your CMakeLists.txt file:

# autogenerate dependency information
set (CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON)

A Note About Open Sound System (OSS)

A while ago I wrote about creating random numbers out of noise gathered from audio device and also created a password generator based on the idea. The implementation was based on Open Sound System (commonly known as OSS). OSS was the defacto way to access audio device couple of years ago, when it hit licensing issues and subsequently replaced by ALSA. As Ubuntu no longer supports OSS (and even the ALSA wrapper for it is in Universe), I’ve decided to re-write the code in some modern alternative.
Continue reading A Note About Open Sound System (OSS)

Creating a Deb for an Updated Version

Say you’ve an existing package like gitg and you want to use the new version of gitg or even apply your own patches. You could directly make install but you will probably regret it as soon as you’ll want to upgrade/uninstall, and you want to create a better package than the one created by checkinstall. Apperantly, creating a deb package for a new version of already packaged deb isn’t complicated.

Getting Started

Start by pulling the sources for the already available package. I’ll by using gitg as an example throughout this tutorial.

$ apt-get source gitg

This will create a folder according to the version of the package, something like gitg-0.2.4. Extract the new version besides it and cd into its directory. The next step is to copy the debian/ directory from the old source package the code you’ve just extracted.

$ cp -R ../gitg-0.2.4/debian/ .

Dependencies

There are some dependencies you’ll need:

$ sudo apt-get install devscripts
$ sudo apt-get install dpkg-dev

You’ll probably want to do:

$ sudo apt-get build-dep gitg

in order to make sure you’ve all the relevant build time dependencies.

Update debian/ Files

The next step is to update the files under the debian/ sub-directory.

$ DEBEMAIL="Guy Rutenberg <myemail@domain.com>" debchange --nmu

This will update the debian/changelog and set the new version. --nmu will create a new “non maintainer upload” version, meaning if the current version was 0.2.4-0ubuntu1, it will change it to 0.2.4-0ubuntu1.1. This will make sure that there won’t be any collision between your package and an official one. If you update to a new upstream version. It might be more suitable to use something like this:

$ debchange --newversion 0.2.5+20111211.git.20391c4

If necessary, update the Build-Depends and Depends sections of debian/control.

Building the Package

If your building a package directly from version control and not part of an official release, you may need to run

$ ./autogen

at this point.

Now to the actual building:

$ debuild -us -uc -i -I -b

-us -uc tells the script not to sign the .dsc and .changes files accordingly. -i and -I makes the script ignore common version control files. -b tells debuild to only create binary packages. You can also pass -j followed by the number of simultaneous jobs you wish to allow (e.g. -j3, like in make) which an significantly speed things up.

Installing the Package

The package will reside in the parent directory, for example:

../gitg_0.2.5+20111211.git.20391c4_amd64.deb

At this point you’re basically done. If you want to install the package you can use

sudo debi

while you’re still inside the build directory.

Creating Source Packages

If you want to go the extra mile and create source packages, it will make things easier for others to build their own packages based on yours.

You’ll need to create a an “orig” tarball

../gitg_0.2.5+20111211.git.20391c4.orig.tar.bz2

(note the underscore between the package-name and the version). The “orig” tarball should contain the original source-code without the debian specific patches.

Now you can run the debuild command like before but without the -b flag.
This will create the following files:

../gitg_0.2.5+20111211.git.20391c4.debian.tar.gz
../gitg_0.2.5+20111211.git.20391c4.dsc

References

  • UpdatingADeb
  • Man pages for debuild, dpgk-genchanges, dpgk-buildpackage.

Check if a server is about to run fsck

Couple of weeks ago I installed some updates to my server. And when I restarted it, it didn’t came up. To make things worse, the IPMI console decided to go on strike so I couldn’t see what’s really going on. I presumed that the system isn’t responding because of some kernel panic. After a while, I gave up for that night in hope the in the morning the IPMI would be sorted out. To my surprise, the IPMI was still out of work, but the server was up again. Apparently, the system wasn’t stuck on kernel panic, but on fsck‘ing the harddisks. So in order to avoid such problems in the future I looked for a way to tell when the system is going to run fsck after the next reboot (I also had the IPMI fixed).

 $ sudo tune2fs -l /dev/sda6

In the output you will find the following lines:

Mount count:              2
Maximum mount count:      36
Last checked:             Tue Jul 26 04:49:18 2011
Check interval:           15552000 (6 months)

“Maximum mount count” is the number of mounts after which the filesystem will be checked by fsck. “Check interval” is the maximal time between two filesystem checks. The command also lets you see the actual mount count since the last check and when it took place.

search_for_updates 0.2

This is a small update to my search_for_updates script which have been laying around. The script allows to search for updates from portage without resolving dependencies. Thus, it’s much faster than

emerge -pvu world

The new version lists the best version available for each package which can be updated using the --verbose flag. You can download the new version from here: search_for_updates-0.2.

iproute2 Cheatsheet

The iproute2 package offers the ip utility, which is a modern replacments for tools such as ifconfig, route, arp and more. It allows to configure addresses, links route and arp tables. The only problem is that its documentation can be quite confusing. This post is intended to be a task-oriented guide to this utility, it’s far from complete and I intend to update it from time to time.
Continue reading iproute2 Cheatsheet

Kernel Configuration and nvidia-drivers

This is more of a note to myself, as I keep forgetting this. The propriety NVIDIA drivers, provided by the x11-drivers/nvidia-drivers dislikes alternatives. It will refuse to build against a kernel with the rivafb (CONFIG_FB_RIVA) and nvidiafb (CONFIG_FB_NVIDIA) built in or built as modules. Both can be found (and unset) under:

Device Drivers
-> Graphics support
   -> nVidia Framebuffer Support
   -> nVidia Riva support