Posts Tagged 'aptitude'

Eight tips for a robust Ubuntu Hardy installation

It’s been a while since I wrote stuff here – ironically I thought it was cool to get my own domain name, and then I ended up having too much fun on the GNU/Linux blog I also started. This should actually also go on the other blog, but I really wanted to write something here :)

Besides, the more Ubuntu buzz on blogs, the better, right? With the release of Ubuntu 8.04 this week, it couldn’t be a better time.

About these tips

If you’re new to the GNU/Linux operating system, this may not be for you. Nothing I’m mentioning here is complicated in any way, but it sort of assumes you’re reasonably comfortable finding your way around in Ubuntu. Instead, you may want to check out the Ubuntu website and, if you’re looking for help, the Ubuntu Forums.

The tips I’m listing here are a personal collection of things that I think might make your Ubuntu system that little bit more robust. That’s not only in a security or stability sense: I’m also thinking about protecting my system from my own tweaking and fiddling around (which you’ll inevitably do if you want to learn new things).

The tips here are most simple to act on at installation time, so I’ve sort of turned this into an installation advice list. Quite a few pointers here point back to my own writing of this week, for which I apologise. My middle name is not Narcissus, but those pieces needed a good overview to connect them, and this is it.


1. Check hardware compatibility before you start – this is still a big problem for all free-software operating systems. By now, it’s no longer a problem the developers can really help: all hardware could be made compatible if some manufacturers weren’t so secretive about the devices they make. As a sad result, the Ubuntu Forums are full of reports on (mostly) hardware compatibility problems.

No general recommendations here, but you’ll want to be prepared. If your wifi chip vendor is an ***, it’s helpful to know which packages and other files you need to have at hand. A few pointers: HardwareSupport on the Ubuntu wiki pages, TuxMobil,

2. Download a disc image using BitTorrent – it takes some persistence to find the page with the torrent links for Hardy if you start from the Ubuntu frontpage. I presume they don’t want to confuse new users. Of course, using the torrents takes some load off the main servers, helps some people, and (best of all) it’s likely faster too (especially now, just after the release date).

If you’re interested in the tips in the next section, you’ll want the alternate installer disc image.


Almost all choices you make during installation are revertible later on. I mean, you can always change your username, clock settings (local or UTC time?), which packages you want. One thing is a bit more tricky to change later, and that’s partitioning your disk(s). The alternate installer gives you some neat extra partitioning options which I want to highlight here.

3. Logical Volume Management – creating your file systems as LVM logical volumes gives you a lot more flexibility. The LVM HOWTO has a section “Benefits of Logical Volume Management on a Small System” which however doesn’t mention one of its cooler features: snapshots. LVM snapshots allow you to keep an image of your file system frozen at some point in time.

That will be useful for at least one thing: six months from now, you can take a snapshot of your root file system, upgrade to Ubuntu 8.10, and if it didn’t work well (proprietary video and wifi drivers seem to have regressions to no end), you still have a working 8.04 snapshot you can boot to use until you fixed the upgrade.

The other useful application for the home user: it’s easier to create consistent backups from a snapshot. Now, while you’re at it, I’d combine LVM with…

4. Disk encryption – reusing the rationale from this post: “if someone steals your laptop, you’ll worry a lot less about them getting access to your email and other important accounts (think browser cookies…). In case you’re wondering why the user login won’t protect you: anyone with physical access to the machine – like a thief – can just reboot and start in single-user mode, thereby getting root user privileges. Not so with an encrypted disk”.

Be sure to make frequent backups though – recovering data from an encrypted disk can be hard.


5. Set up version control on your configuration files – before you stroll off to your favourite geek forum and take advice from everyone and their dog to alter all kinds of stuff in configuration files under /etc, you might want to ensure that you can always get back what it said originally. Don’t get me wrong, I also try risky stuff people I’ve never met recommend to me, but I really like to keep track of those actions, too. So here you go: version control on /etc using Bazaar. As explained there, version control gives you some cool flexibility that a simple backup wouldn’t.

6. Installing additional packages: use aptitude – actually that’s not really what I want to recommend. There are quite a few APT front-ends and it’s worth checking out several, especially if you’ve never looked beyond Synaptic. So check out a few, and then decide that you like aptitude :)

Aptitude runs in a console, and has both a direct command line mode and an interactive mode. Its killer feature for me: it tracks which packages were only installed as dependencies of a package you really chose. So if you ever tell it to remove that package, it will remove its dependencies, too.

Here’s a more elaborate discussion of the tool’s merits.

7. Keep non-repo software under /usr/local – just one more quote of my own writing (promised!): “To ensure that the package manager doesn’t interfere with software you installed “manually” (i.e. not through dpkg, apt-get, aptitude, synaptic, …), there’s an article in the Filesystem Hierarchy Standard that says everything you install manually should go into /usr/local (or /opt, actually) and not directly into /usr.”

If you want to make it easier for yourself to enforce that policy, without reading every line of every install script you use, you might like to check out that post. It’s about installing software on /usr/local without full root privileges.

8. Secure your web browser – with properly set user permissions, should you now bother with such things as a firewall and a virus scanner on your desktop (laptop) machine? Probably not. (Although I wonder if everybody is sudoing all the time, won’t somebody exploit that at some point? How high are the chances that a malicious script that’s trying to use sudo hits you while a sudo session that you started is still open? Not sure how that would work, but then I’m not a seasoned malware designer).

A lot of executable code that you rake in as a normal user is stuff coming through your web browser: scripts on web pages, but also (Firefox) browser plug-ins. Malicious code in those can only destroy stuff that you have write permission for, and can only collect information that you have read permission for (which is typically most of other users’ data!), so decide if you think that’s still worrying. A good start for securing Firefox is this overview at Ubuntu Forums.

Wrap up

That’s all I could produce in my spare time this week… hope it’s useful. I’d love to hear if it is. Commenting here does not require you to leave any contact details (hint!). Thanks for reading.


Backports, and why you shouldn’t just follow my directions

I got hooked on Bazaar (or bzr – which is the package name) shortly after I started working in Ubuntu. It’s a great version control system written in Python, and I’ll show a nice example of its use here soon. But that’s not what this post is to be about.

Looking for bzr in the Etch repository, I found that a plain aptitude install bzr would provide me with version 0.11 of the software. Now, that is a lot of versions away from the current stable version, 1.1. So I decided I couldn’t do without a newer version, and since I trust the package to work well and it doesn’t provide any network services (so security risks are limited), I thought I might as well get the newest version from the developer site.

At that point I remembered backports. A quick look around the site told me bzr 1.0 for Etch was available from there. Now, there are a few advantages to using a back-ported deb package over a manual installation. One of them is the ease of installation (after adding to your trusted sources as explained here, the back-ported packages are available in your package manager), but in fact installing bzr by hand is also really simple: unpack the tarball in a suitable place and put a link to bzr in your path.

The real reason I opted for backports is that using the package manager makes the package management system aware of the presence of a version of bzr on your system. This gives you lots of benefits: you get warned when you try to install an incompatible package, when you install another version, or when you remove a package that bzr depends on.

Well then, I added backports to the trusted sources as described in the given link, and used aptitude to select the 1.0 version. You need to explicitly select the newer version, otherwise the system defaults to installing the official repository version (you can use pinning to alter this behaviour, but that’s a topic I’ll have to skip for now). I chose not to install the recommended packages bzrtools and python-paramiko (for sftp support), which you would also have to manually set to the right versions if you have a need for them. That’s all!

Almost all. There’s one essential remark I usually don’t see in blog posts like this one: there is of course a reason why backports are not enabled by default on your Etch system. If, like many people, you’ve come to Debian for its reputation of good security, you need to realise that it is only as secure as you keep it. You are the only person who can assess the implications of adding a repository to your trusted sources, and it’s not a decision to take too lightly. I trust backports as a source, and I trust bzr 1.0 to be stable enough to belong in an Etch system, but you shouldn’t just jump off that cliff with me…

The coolest feature?

In the last post, I sort of suggested I’d be just as happy to use MS Windows. That’s not entirely true, though. The one thing I’d really, really miss is a good package manager. Ian Murdock put it very well, so I won’t try rephrasing it here.

And, while we’re on the topic: aptitude is my tool of choice. I might sing in its praise more elaborately at some point.