Charles Curley's Weblog

Following on to my last entry, 15 Power tools for Linux you can't afford to miss comes this list, New cool list of Linux must-have programs. It's a different list, aimed at a different audience. I wouldn't call any of them "must have", but they all seem to be pretty good, maybe best of breed. And most of the reviews come with tutorials.

I'm talking about some tools, which comes in very handy while you are in trouble or save you from future trouble or even help you to do things fast. Note that I'm not listing all the tools, neither I'm ranking those.. I have just picked few tools which I use regularly, and have good experience with them.

15 Power tools for Linux that you can't afford to miss.

Actually, I've been missing some of them for years. But it's a darn good list.

Monday I updated my laptop, including a new kernel. Per usual procedure, I rebooted. I was not able to log in to my regular account. The problem was that the password didn't match what the home directory encryption code was expecting. So no home directory access, so no log in. The problem, then, was to recover my data and rebuild my home encrypted directory.

Oh, yes, let me remind you once again: recover your wrapped password and store it someplace safe. You may not be able to get at it when the emergency hits. Do it now! I did it like so:

root@test2:~# ecryptfs-unwrap-passphrase /home/.ecryptfs/fred/.ecryptfs/wrapped-passphrase 
Passphrase: 
638ec71d18ba30df7bba343b1ee8e27e
root@test2:~# 

Note that I did it here as root, not as my regular user. This means that if you can log in as root, either at the terminal or via SSH, and have the password for your user account, you can recover your data.

I have since recovered the data in the user directory, using these instructions exactly. I've also printed out both sets instructions and added them to system documentation, just in case those sites should ever go away. Go, thou, and do likewise.

Once youve recovered your data, the problem becomes: restoring the data to an encrypted user directory. To do that, I followed these ancient instructions, with one exception. That exception being, I did not follow the last instruction, to use ecryptfs-setup-private. ecryptfs-setup-private sets up the older encryption setup, with a ~/Private directory. That has a number of hazards, not least that not all the data in your home directory is secured.

Instead, I removed the user, using deluser from the command line.

root@test2:/home# deluser --remove-all-files fred
Looking for files to backup/remove ...
Removing files ...
Removing user `fred' ...
Warning: group `fred' has no more members.
Done.
root@test2:/home# 

If necessary, rm -r /home/fred /home/.ecryptfs/fred/.

Now add the new user. The GUI tool, users-admin, has no provision for encrypting a user's home directory as it makes it. But the command line tool adduser does.

root@test2:~# adduser --encrypt fred
Adding user `fred' ...
Adding new group `fred' (1001) ...
Adding new user `fred' (1001) with group `fred' ...
Creating home directory `/home/fred' ...
Setting up encryption ...

************************************************************************
YOU SHOULD RECORD YOUR MOUNT PASSPHRASE AND STORE IT IN A SAFE LOCATION.
  ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase
THIS WILL BE REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME.
************************************************************************


Done configuring.

Copying files from `/etc/skel' ...
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
Changing the user information for fred
Enter the new value, or press ENTER for the default
        Full Name []: Fred Flintstone
        Room Number []: 
        Work Phone []: 
        Home Phone []: 
        Other []: 
Is the information correct? [Y/n] y
root@test2:~# 

You should now be able to log in as your regular user and start recovery.

But I have another problem. In the process of recovering from this, I found out that Amanda hasn't been backing up my home directory on the affect machine correctly. In fact, not all. Film at eleven!

I thought this writeup on telecommuting was worth a mention: Why we love remote work.

There are two more advantages to remote work they missed:

• No commute. OK, mine is the six feet from my kitchen to my office chair.
• No rush hour. OK, Thermopolis has a rush three minutes at its one signal when the hospital shift changes late in the afternoon. You might see five or six cars queued up at the signal. But that doesn't affect me.

Lightweight Portable Security (LPS) is a lightweight, portable version of Linux that allows the user to turn any unmanaged computer system into a trusted end-node by securely booting a trusted operating system. LPS has also been designed to allow users in untrusted environments to remotely access trusted computing resources. The trusted computing resources could include your personal financial institution, your workplace, or other sensitive network application/activity. LPS can also be used as a safe way to interact with untrusted web resources. LPS is designed to be read-only and does not provide access to local hard disk drives (though it does support saving documents to USB flash sticks). LPS is designed with the mobile or ad hoc telecommuting user in mind. LPS may include a few varieties of thin-client software, VPN clients, and a DoD CAC-enabled web browser.

Sounds like a typical Linux live CD, doesn't it. Maybe one with an emphasis on security and a light footprint so it will boot quickly. Maybe like ZooT aLLures' Wyoming Puppy Linux, a home brew "puplet" (respin) of Puppy Linux with an emphasis on security. Wyoming Puppy Linux is so low profile it doesn't even have a home page. But you can download it.

Emphasis on security, yes. Typical home brew, hardly. For one thing, notice the milspeak in that announcement. Lightweight Portable Security is a US Air Force project. One thing conspicuously absent from the LSP web site is a downloads page.

I do like the idea that some guy in Boondocks, Wyoming (or is he?) can distribute a secure live CD on an even footing with the US Air Force. Now, that's cool!

Is Microsoft dead? Paul Graham has an interesting essay with the title Microsoft is Dead.

Well, certainly not in the sense that a T. Rex that's been out of action for the last 65 million years is dead.

I went from HP to Microsoft late in the 1990s. The two corporate cultures were very different.

At HP, I worked on a project that required close contact with HP engineers all over the world. I had a Unix work station on my desk. I installed Apache, wrote some web pages, announced the web page to the people I was working with, and I was in business. Internally, that is. This was not visible outside the HP network, but that's all I needed. Key: I just did it. I didn't ask permission, I didn't have to ask some sysadmin to do it for me. I just did it. Because of that web page, with the help of email and phone calls, I could bypass HP's horrendous corporate bureaucracy and communicate directly, engineer to engineer. We got things done.

At Microsoft, I wanted to do the same thing. Nope. I had to have the department web person do the work. OK. I asked politely. More than once. I forget now, ten years on, what the response was when I got one, but I do remember that it was a lame excuse to cover up sloth or incompetence or both. I never did get my internal web server. I got things done. But the web server would have made some of them a lot easier, and other things possible.

HP "got" the Internet, informally if not officially. Microsoft didn't.

If Microsoft is dead, it is it dead in the sense that an apatosaurus may be bleeding its life blood out into the sand, and it's too stupid to know it. And the bigger they are, the harder they fall. It may kill off a few of its smaller, nimbler competitors as it thrashes about. But as long as you stay out of range of that thrashing, it's no longer to be feared.

I wanted a virtual private network (VPN) connection I could use between my laptop and my home system wherever I might be. A bit of research showed that VPNs can be tricky and messy, as well as leaving your home network wide open if you didn't do it right. I could do it with SSH tunneling, but experimentation showed that to be a bit clunky, and required me to write some custom scripts. Why not let experts write the scripts? Which brings us to OpenVPN, available on many Linux disties.

After much googling and fiddling around, I came across this set of instructions for a simple one client, one server setup. Let's look at the writeup's advantages and disadvantages.

Static Key advantages

1. Simple Setup
2. No X509 PKI (Public Key Infrastructure) to maintain

Static Key disadvantages

1. Limited scalability -- one client, one server
2. Lack of perfect forward secrecy -- key compromise results in total disclosure of previous sessions
3. Secret key must exist in plaintext form on each VPN peer
4. Secret key must be exchanged using a pre-existing secure channel

The two advantages are great. Simple setup is always good. I'm not sure what a Public Key Infrastructure is, but if I don't have to maintain one, that's fine by me.

Disadvantage one is actually an advantage for me. I only need one of each, and any more would be unnecessary, and so a potential security problem. Disadvantage four is a non-issue. I set up the laptop and tested the VPN from inside my home network, and scp does just fine. Disadvantage two could be serious, see disadvantage three. Disadvantage three could be serious if the laptop is ever compromised. So make sure the laptop is never compromised.

For a first go at a VPN, this is acceptable. I may later try a less vulnerable form of VPN; we'll see.

With that analysis done, it's time to implement the VPN. I followed the instructions with suitable changes for my situation.

It isn't clear in the writeup where the client and server configuration files live. They live in client.conf and server.conf, respectively, in /etc/openvpn. For Ubuntu, and possibly other operating systems, you can use any name you want so long as it ends in .conf. The startup script for OpenVPN will pick it up and attempt to open a VPN connection for you at boot.

After testing the simple configuration, I added compression and enabled the failure resisting features. I also set the two ends to run as daemons. This requires adding the user and group nobody to an Ubuntu system.

Now for the fun part: firewalling. The writeup says, "Bear in mind that 90% of all connection problems encountered by new OpenVPN users are firewall-related." I did all my testing so far inside my private network. So I could drop my firewalls. That's fine for testing but useless in the real world. Since I use Firestarter on my machines, I had to integrate the OpenVPN devices into Firestarter.

After much googling, I came across ngarret's writeup, Firestarter and OpenVPN, VMware, which refers to this page. The first page shows what to do for both OpenVPN and VMware. Since I also use my desktop as a virtualization host, I modified the lines for the latter for KVM, as follows:

root@dzur:~# cat /etc/firestarter/user-pre
# Allow traffic on the OpenVPN interface
$IPT -A INPUT -i tun+ -j ACCEPT
$IPT -A OUTPUT -o tun+ -j ACCEPT

# Allow virtual machine traffic
$IPT -A INPUT -i virbr+ -j ACCEPT
$IPT -A OUTPUT -o virbr+ -j ACCEPT
root@dzur:~# 

Note that these two stanzas allow traffic from the VPN and virtual machines indiscriminately, which may not be what you want.

(The first stanza is in the Firestarter documentation, but I didn't find that until I started on this writeup. Sigh.)

You can specify which VPNs OpenVPN will try to start when you fire it up. On Ubuntu, this and other options are set in /etc/default/openvpn. Since I have two profiles, and only one will work at a time, for remote access I set AUTOSTART="remote".

Since I don't use the laptop outside my own network very often, I have the OpenVPN daemon set to not run at boot. So I have to run it manually when I want it. This is acceptable, at least for now.

Field testing consisted of taking my laptop to the home of a friend who doesn't have the same ISP I do. The requirement is because my ISP, probably like a lot of them, does not allow traffic between two customers. So I can't SSH or VPN in to my home from my favorite local espresso stand/bookstore. Drat.

Field testing worked perfectly. I plugged the laptop in to my friend's cable modem. I had to hand configure the network (yet more Komic Koala Keystone Koppery?) but OpenVPN is independent of that. Once on the Internet, all I had to do was:

service openvpn start

I was able to access an internal web server and other services via my virtual device. Et viola! Proof of concept!

On conclusion of the testing:

service openvpn stop

To make life easier, it would be nice to have name resolution for the home network. I run bind 9 on the laptop, as a spare DNS server for the home network. So all that should be necessary is to make sure it's running, and then hack a localhost IP address into /etc/resolv.conf. That's next.

It's usually good advice to wait a while before jumping into a new version of a Linux distribution. I should have taken it. I've had a number of problems on my laptop related to Emacs, and X. Even Sudoku has a regression, for Murphy's sake.

I solved one display problem related to OpenOffice.org and Network Manager by enabling display effects, and that brought on a whole new, but somewhat less obnoxious problem.

Apparently I'm not the only person to have problems upgrading to Ubuntu 9.10. Finally, this morning I had problems with the Launchpad servers apparently overloaded.

It would be comic if it weren't so pitiful.

My advice: stay away from Komic Koala for a while.

Ubuntu 9.10 has just been released. As usual, this has provoked a plethora of pundit puffery, not least this review in the Register.

Also as usual, the comments are loaded with complaints about how some operating system or other (not necessarily the one under review) doesn't work with the whinger's hardware. Therefore, the complainers gave up on that OS forever, and it's an utter pile of fertilizer.

Well, Ms. complainer, what did you do to remedy this situation? I've had problems with Linux and have either gotten help with them or helped to solve them. I don't have much sympathy for folks who make no effort to solve the problem, and this is true regardless of the OS or the license of the software at issue.

One problem is that often hardware is designed, not to meet the relevant standard, but to work under Windows. If Windows doesn't use everything the standard provides, the vendor only provides the hardware necessary to work under Windows. Result 1) the hardware may be broken under Linux or Mac OS. Result 2) the next upgrade of Windows may also break your hardware. But most people will blame the operating system, not the hardware.

For years I've observed that it usually isn't a good idea to shift people from one OS to another all at once. Do it gradually, I say. First use cross platform applications like OpenOffice.org or CADEMIA on your present OS. In fact you can get a whole DVD loaded with cherry picked open source programs that run on Windows, just the thing if you plan to move from Windows to Linux. Then when folks are comfortable with those, transition to the new OS.

I'm going to add something to that. Between the time you decide to make the change to Linux and the time you actually do, you will probably buy hardware. A new laptop. A new printer. Et cetera. OK, when you do, make sure you buy hardware known to be compatible with Linux.

Case in point: I've had excellent results with HP printers on Linux because HP takes the time to make sure HP printers work under Linux. This is not to say the software is perfect. I found a bug, reported it, and I got satisfaction.

I've been very happy with my Lenovo R51 laptop. Again, I also had problems with it initially, as documented above. I've also had some incredible successes with it.

In both cases, I went out of my way to research and buy Linux friendly hardware. This is not just a good way to get hardware you know will work with Linux. It's also a good way to reward vendors who make their products play well with Linux.

This also applies to Linux friendly software. Cross platform software is great. But there are some products that aren't cross platform and never will be. You can still find Linux friendly vendors in that category. For example, Dave McAllister, Director, Standards and Open Source, Adobe Systems Incorporated, gave a keynote address at the recent Utah Open Source Conference. Adobe? Open? Yeah. They've released the PDF standard to open standards bodies. And, according to McAllister, they co-operate closely with the WINE folks, so that some Adobe products now run on WINE, which is to say, now run on Linux.

OK, it's all very nice in theory to say, let's buy from Linux friendly vendors. The problem is: who are they and how do you find 'em and track 'em? I have some thoughts on that, but first, I'd welcome your ideas.