Per-user Editor Selection in Ubuntu Intrepid

From the Ubuntu Server Team...

When a program in Ubuntu such as crontab -e or dch -i, is used to edit a file, it uses a helper program called sensible-editor (provided by the debianutils package).

sensible-editor attempts to intelligently find an editor on your system based on a few simple rules. Basically, if you haven't already defined $EDITOR, it will use one of {nano, nano-tiny, vi}, in that order.

Now, it's well understood that nano is easier to use than vi to a new Ubuntu user. And it's assumed that if you are sophisticated enough to want a different editor, then you likely already know how to change that setting.

Traditionally, this can be done in one of two ways.

1. You can edit your ~/.bashrc file to export an EDITOR value of your choosing. Of course, that requires that you have a usable editor with which you can modify that file!
   
2. Or if you are an administrator of the system, you can set the default editor for the entire system:
3. sudo update-alternatives --config editor
   

So I recently created a new utility, /usr/bin/select-editor, which uses update-alternatives --list to display a list of editors present on the system and prompt the user to select one. The selection is written to ~/.selected_editor. I also patched /usr/bin/sensible-editor to read and use this value, if present.

The default selection remains nano, but for those of us installing dozens of Ubuntu systems every week and looking for a more powerful editor, we now have a really convenient, friendly mechanism for each user on an Ubuntu system to interactively choose an editor preference the first time they need one!

:-Dustin

Encrypted Private Directories in Ubuntu Intrepid

From the Ubuntu Server Team...

Do you have sensitive data on your computer? Perhaps a file containing all of your passwords? Financial spreadsheets or GPG/SSH keys? Are you concerned about someone reading these files should your PC or laptop be stolen?

In Ubuntu's Intrepid Ibex development cycle, the Ubuntu Server Team is implementing support for an encrypted private directory in each user's home.

Getting Started

Install the 'ecryptfs-utils' package:

sudo apt-get install ecryptfs-utils

Run ecryptfs-setup-private as your non-root user:

ecryptfs-setup-private

After that, it's a matter of logging in/out, and reading/writing data in ~/Private. Personally, I have moved my ~/.ssh, ~/.gnupg, and ~/.mozilla directories into ~/Private, and symlinked them to their traditional locations.

• Do NOT move your ~/.ecryptfs directory in ~/Private!!!
  

How does it work?

The underlying technology is a cryptographic virtual filesystem in the Linux kernel called eCryptfs, authored by Michael Halcrow of IBM.

When a user logs into an Ubuntu Intrepid system, their login passphrase is automatically used to decrypt a randomly generated mount passphrase. This mount passphrase will then cryptographically mount ~/.Private onto ~/Private. As long as ~/Private is mounted, the user can read and write sensitive data to files and directories under the virtual filesystem on ~/Private. The actual files stored in the underlying filesystem are encrypted, and located in ~/.Private. The only passphrase required is obtained when logging in (via console, ssh, gdm, etc). And the only files encrypted are those that the user consciously places in ~/Private. The user can then incrementally backup the encrypted ~/.Private directory to off-site storage.

A more complete discussion of the design details are available as a specification in the wiki:

• https://wiki.ubuntu.com/EncryptedPrivateDirectory
  

Testers wanted!

Most of the integration of Encrypted Private Directories has been completed in Intrepid, and now we're looking for some proactive Ubuntu users to test this functionality before the legions of Ubuntu users begin trusting this technology with their personal data. With your help, hopefully we can shake out any remaining functionality or usability issues.

Please follow the complete, step-by-step, up-to-date instructions in the wiki:

• https://wiki.ubuntu.com/EncryptedPrivateDirectory#head-4a2aa7460fdca18bfe78bb1283becff406bbc13c
  

And file relevant bugs in Launchpad against ecryptfs-utils:

• https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils

:-Dustin

Booting Degraded RAID in Ubuntu Intrepid

From the Ubuntu Server Team...

Traditionally, booting an Ubuntu installation with the root filesystem on a degraded RAID drops the system into a busybox prompt in the initramfs.

This is a very conservative approach, allowing the system administrator to consciously recognize that the system has lost a RAID disk, and preventing the system from booting into an unprotected situation.

This can be problematic on Ubuntu server machines which are expected to boot unattended. Some administrators may wish to configure a system to boot automatically, even if in a degraded state. We have recently added support for this to Intrepid's mdadm and initramfs-tools packages.

A system administrator can now statically configure this in Intrepid with:
echo "BOOT_DEGRADED=true" | sudo tee -a /etc/initramfs-tools/conf.d/mdadm

Additionally, this can be specified (overridden, actually) on the kernel boot line with the bootdegraded=[true|false] parameter.

More details on this specification, and full instructions on how you can help test this functionality can be found in the wiki at:

• https://wiki.ubuntu.com/BootDegradedRaid
  

Stay tuned, as related patches are under development for grub, and the installer...

:-Dustin

Adding a status action to init scripts

Surely if you have administered a Linux server, you have used the scripts in /etc/init.d/ to start, stop, and restart system services. What about the status action to determine if a given service is up and running?

The Ubuntu Server team has initiated a concentrated effort to add status actions to the most commonly used init scripts. We’re recruiting current and aspiring Ubuntu developers to help patch these init scripts. Some Unix shell programming and basic Debian packaging skills are all that is required.

Basically, you need to do:

1. grab the source
   
2. add two lines to the service’s init script
   
3. add a dependency in the control file
   
4. create a changelog entry
   
5. post a debdiff to a Launchpad bug.
   

There is detailed step-by-step checklist for creating and submitting such packages on the wiki page.

The Linux Standard Base 3.1 has a specification for init scripts actions. A simple function has been added to the LSB base library /lib/lsb/init-functions. This shell function, status_of_proc(), can be used in most init scripts to report status.

The list of init scripts that need work is also maintained in the wiki page. Join us in IRC at #ubuntu-server if you are interested in helping!

:-Dustin