Posts Tagged 'hardy heron'

Playing with Windows 7 beta in Ubuntu Hardy

…using kvm, that is. But wait, you say, why come from freedom and subject ourselves to this:

Wait, what??

Wait, what??

The thing is, after reading that the SABDFL himself seems to like the recently released Windows 7 beta 1, I somehow felt compelled to try it out, too. Like Shuttleworth points out, it’s nice to have some competition, and of course it doesn’t make sense not to be aware of what that competition looks like.

While I won’t have time in the next few weeks to play with this beta a lot, now was the time to download it, because MS are taking it offline on 10 February. You’re provided with an activation key for the installer, and the installed system remains accessible until sometime in August. In case you’re getting curious too, the download page is here – note that the iso to download is rather substantial at 2.5GB. To avoid too complicated issues, I opted for the 32-bit version.

On the Guest Support Status page on the kvm wiki I found an entry stating that Windows 7 has been tested on the amd64 architecture, with kvm-62. Guess what? That happens to be exactly the version of kvm that’s in the Hardy repositories. It’s actually been a while since I installed kvm (note that kvm needs hardware support in your CPU and your BIOS by the way, otherwise look up qemu, but I’m not sure if you want to run something big like this in that case), but off the top of my head you can install it in Hardy (please correct me if I’m forgetting anything crucial) by a simple

sudo aptitude install kvm
sudo adduser username kvm #replace username

and then a reboot (well, you could go without rebooting and then modprobing etc, but this is the brief version…). The adduser line allows you to use kvm as a normal user. As always, I’d like to add that you should know what you’re doing when running with root privileges (sudo), and at the very least read the man pages to any commands pasted from some random guy’s blog… there, I said it again.

The kvm wiki entry also lists the settings with which Windows 7 was tested; there’s one issue here and that is that the usb-options to kvm don’t work on Hardy. So, omitting those, we can install with the following two lines:

qemu-img create -f qcow2 win7.img 15G
kvm -localtime -std-vga -m 2048 -cdrom win7.iso -boot d win7.img

I think I’ll skip explaining the switches – seriously, read the man pages. Well, actually, the kvm man page doesn’t contain much, so look at the one for qemu instead. Obviously, you can drop the -cdrom and -boot options on subsequent runs.

The installation ran buttery-smooth here, but then I’m a bit spoiled with an Intel T8100 CPU and 4GB of RAM. Anyway, I think it was mostly a disk-performance limited affair (it’s all on an encrypted LVM volume on a slow laptop harddisk…), but still I was looking at a completely installed and also fully patched system (yes, kvm/qemu takes care of passing-through your network connection) within 45 minutes. At this point, the disk image takes up 5.1GB of space.

Finally, although I took umpteen screenshots during installation, I now decided I won’t put them up here; partly because I might get shot by the users of (“Hello all, I’m the new guy who just joined, and I’m plastering your RSS readers with Windows screenshots… ;)”), partly because the web is flooded with Windows 7 screenshots already, and partly because I’m hoping you’ll try it out for yourself. Have fun!

Edit: it seems I haven’t been keeping track of my friends’ feeds properly. Shawn wrote about this already over a week ago. Also, he did post his screenshots…

Skype on Ubuntu 8.04 amd64

I know, I need to play a bit more with Ekiga and other VOIP tools. But for now I really just wanted to quickly fire up Skype, and with Ubuntu Hardy it has become quite a bit simpler than before to install it (the 32bit executable that is) on an amd64 system.

Mistrusting as I am, I didn’t at first believe that it could be as simple as this Ubuntu Forums How-To promises. Basically it says you need just three commands (and to give away the conclusion – it’s true!):

sudo apt-get install ia32-libs lib32asound2
wget -O skype-install.deb
sudo dpkg -i --force-all skype-install.deb

Now I’m fine with the first two; obviously, you need the skype package, and you’ll need some basic 32bit libraries to run it with. But “–force-all” is a bit drastic, and I really wanted to know what warnings and errors I’d be missing out on. So let’s see:

$ sudo dpkg -i skype-debian_2.0.0.68-1_i386.deb
dpkg: error processing skype-debian_2.0.0.68-1_i386.deb (--install):
 package architecture (i386) does not match system (amd64)
Errors were encountered while processing:

Unsurprising. But instead of now forcing everything, let’s just force it to accept the architecture:

$ sudo dpkg -i --force-architecture skype-debian_2.0.0.68-1_i386.deb
dpkg - warning, overriding problem because --force enabled:
 package architecture (i386) does not match system (amd64)
Selecting previously deselected package skype.
(Reading database ... 103178 files and directories currently installed.)
Unpacking skype (from skype-debian_2.0.0.68-1_i386.deb) ...
dpkg: dependency problems prevent configuration of skype:
 skype depends on libqt4-core (>= 4.2.1); however:
  Package libqt4-core is not installed.
 skype depends on libqt4-gui (>= 4.2.1); however:
  Package libqt4-gui is not installed.
dpkg: error processing skype (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:

Right. I thought this was a static build? Why does it depend on that QT stuff?

Anyway, this is where I realised that when you set –force-architecture dpkg still tells you what objections it would have had otherwise. So we may as well –force-all and get on with it:

$ sudo dpkg -i --force-all skype-debian_2.0.0.68-1_i386.deb
dpkg - warning, overriding problem because --force enabled:
 package architecture (i386) does not match system (amd64)
(Reading database ... 103313 files and directories currently installed.)
Preparing to replace skype (using skype-debian_2.0.0.68-1_i386.deb) ...
Unpacking replacement skype ...
dpkg: skype: dependency problems, but configuring anyway as you request:
 skype depends on libqt4-core (>= 4.2.1); however:
  Package libqt4-core is not installed.
 skype depends on libqt4-gui (>= 4.2.1); however:
  Package libqt4-gui is not installed.
Setting up skype ( ...

Configuration file `/etc/dbus-1/system.d/skype.conf', does not exist on system.
Installing new config file as you request.

If I had been more trusting, that would have worked straight away… Interestingly, Skype looks and works just fine despite the missing QT libs (well yeah, that’s what a static build is for). Who configured those package dependencies??

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.

First thing to do on a fresh Ubuntu Hardy installation

Edit - although of course I love to have some readership for this post, I should say that you might want to check out this cooler solution instead: etckeeper is a package that was designed to do all the stuff I’m describing here… thanks to Daniel for his comment!

Well, to be absolutely honest, it was the second thing I did. The first thing after installing was fixing the wifi drivers. But straight away after that, I set up version control on the configuration files in /etc. Basically, that stops you from making a mess out of your configuration files. Sounds good?

Thanks to the guys at Canonical (who are also the ones backing Ubuntu), version control has become easier than ever: with Bazaar it is so easy to set up that I basically have version control for anything I’m working on nowadays. If you know about revision control already, probably you see the use of it and could skip the rest of this post… or you could stick around and see how effortless things become with Bazaar (bzr).

Edit - probably superfluous, but just another word of warning: don’t do anything just because I did. There’s a lot of sudoing going on below here, so you could do damage to your system. Don’t trust a random blogger. Read the man pages, read the online documentation.


Before I show how to set it up, let’s see how you’d use it. Every time you’ve made significant changes to /etc (let’s say you installed new packages, or created new users, or reconfigured your acpi-support settings, or anything), you create a “checkpoint”, or in version control lingo: you commit a revision. That could be as simple as two lines in a terminal (and I’m sure you can get a GUI for this too):

cd /etc
sudo bzr commit -m "short comment on what you've done"

Well, actually, if you had installed new software you might not know what had changed. So you’d have a few more lines:

cd /etc
sudo bzr status #tells you which files are new or have been changed
sudo bzr diff filename #tells which lines in "filename" were just added/removed
sudo bzr add . #puts any new files under version control
sudo bzr commit -m "short comment on what you've done" #sets a checkpoint

Still, not too scary, I’d say? Later, you can review what you changed before:

cd /etc
sudo bzr log #shows comments, date, and version numbers of committed revisions

You can go back to any revision now, say e.g. to number 3:

cd /etc
sudo bzr revert -r 3 #sends state of /etc back to revision 3

Here’s the real kicker though: you can also revert changes within specific files, between any two revisions. That is, you don’t have to send the whole file back to it’s old state, bzr can just remove/reinsert the lines that you’re interested in and leave all other (later!) changes to the file intact. This is what really makes revision control more powerful than plain and simple file backup.

An example: you’ve changed /etc/X11/xorg.conf to use the proprietary fglrx video driver. You removed all the tweaks you had put in before for the open-source driver. This change was part of revision 4. Some days later, you put in all kinds of tweaks for your synaptics touchpad. That was revision 9. Yet some time later, you added wacom tablet settings. Revision 15. But now, you decide you want your open-source driver back… If you’d restore the backup, you’d lose your synaptics and wacom settings. With bzr, this is how you do it:

cd /etc
sudo bzr merge -r 4..3 ./X11/xorg.conf
sudo bzr diff #shows the changes, just to check if it was ok
sudo bzr commit -m "went back to the open-source driver by undoing rev4"

That’s it. Really. Effortless. All your fancy tweaks for the video driver have now been put back in place, but the changes you made for the input devices have not been removed. (In case you’re interested: the bzr user guide calls this reverse cherry-picking).

Stating the obvious

This is of course useful for a lot more things than just /etc. Revision control works well on anything that looks like text. Have a look at the files in your ~/.gconf directory: they’re in xml format. Now if you tweak the looks of your Gnome desktop and applications, bzr can track what changes you made. And restore older settings later.

Setting it up

Installing bzr is of course as easy as

sudo aptitude install bzr

…or apt-get if you want to be old-skool ;) Now, I had a look around the net to see if anyone else used bzr for this, and found this – frankly, that’s pretty much what I’m about to type up here. I’ll give it a spin of my own but I’ll also skip a few bits here, like how to back up your bzr repository and how to send yourself messages in case you forgot to commit your changes to the repository – so see for those parts.

Bringing everything in /etc under version control is as simple as

cd /etc
sudo bzr init #creates a version control repository under /etc/.bzr
sudo chmod go-rwx .bzr #only root may see it
sudo bzr add . #adds everything in /etc to it
sudo bzr commit -m "freshly installed state of Hardy"

You need to use superuser permissions here because you’re not allowed to read everything as a normal user (think /etc/shadow and such). As you’re storing those sensitive files in the bzr repository, you don’t want anyone to read it, hence the chmod. As a result of this chmod, you will now always need to use sudo – otherwise bzr cant access .bzr/.
Now, bzr by default is set to skip some files, for example something like apt/sources.list~ is a previous version of apt/sources.list and will get skipped because of the tilde. Of course you want to check that bzr doesn’t accidentally skip anything important, so

sudo bzr ignored #prints all skipped files

If you see any file there that you did want to add, you can add it by explicitly typing

sudo bzr add sources.list~ #you don't want that, but it's an example

Basically, your /etc directory is now under version control. You can very easily check for changes with

cd /etc
sudo bzr status

as I said before, and if you’ve installed new software and new files appear in /etc, you can now do

sudo bzr add . #adds all the new files
sudo bzr commit -m "installed awesome new package"

A few more things you should note

There may be some files that you actually don’t want or need to put version control on. You can create an ignore-list for those files, so that bzr will skip them when you say “add .”. Guess what the command is?

sudo bzr ignore ./mtab #bzr will ignore mtab from now on

This actually creates a file /etc/.bzrignore with “./mtab” in it. The leading ./ means you only want to ignore /etc/mtab, not any mtab found somewhere under /etc.

Now, you actually already added mtab in the section above, so there’s no point ignoring it now – it’s already under version control. To take something out of revision control:

sudo bzr remove --keep mtab

Here, –keep means that you don’t want to delete mtab. Otherwise, bzr might think you want to get rid of the file, while you just want to take it out of revision control. So far, I have done this on four files: ./mtab, ./adjtime, ./resolv.conf, ./ – these are all files that get generated automatically and are changed by the system (on a standard Hardy install, resolv.conf gets changed by network-manager). After running “remove –keep” on them, you’ve got something to commit again: removing is a change, too.

Second thing. If you installed bzr and immediately used it as superuser, something will be funny in your home directory now: the ~/.bazaar directory will be owned by root. If you use bzr on other things later on, without sudoing, that will generate errors. So

sudo chown -R yourname:yourname ~/.bazaar

In this .bazaar directory you will find a file .bazaar/ignore which specifies the patterns that are ignored by default (like the tilde). Change it as you like.

Finally, if you want to be more verbose in your commit messages, you can leave out the -m and the comment, and bzr will open an editor for you. Type your essay, then save and exit to complete the commit. But by now I’m really just telling you stuff you could read in the Bazaar User Guide – an excellent piece of documentation. Have lots of fun!

PS: if you’re a control freak like me (hey, you’ve read this dreadful piece all the way down), you may also like the previous post on strictly separating repo and non-repo software.

Staffdo: my handicapped version of sudo

As I’ve said before, package management is the coolest feature in any GNU/Linux distro. Prime example are the dpkg/apt tools that are used in most Debian-based distros. Repository software has been tried and tested, and package management ensures that that software Just Works. Now of course, that’s not something you’d want to mess up.

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. Usually you can easily configure a software installer by setting something like “prefix=/usr/local” somewhere.

That’s half the story: you don’t want to install stuff manually and have the package manager overwrite half of it later. The other half of the story is that there’s often a reason why that stuff wasn’t available in the package repository – most likely it’s not as thoroughly tested yet. I want to protect the main system files from alpha-quality software.

Anecdotal: I installed a piece of beta software once that thought it was ok to temporarily replace /bin/bash by something else. Because the script was too simple, it didn’t properly change it back. At the next boot, everything was obviously broken, and for a day I had no idea how to fix it, because I wasn’t aware in the first place that that installer had gone anywhere near /bin. It could do so silently because I called the installer through sudo….

On Debian, there’s a “staff” group (I discovered that on this page) that has privileges that solve the problem: members of staff can install files under /usr/local but not anywhere else. It’s also there on Ubuntu (I just installed Hardy Heron, see previous posts), although it doesn’t show up in the gnome menu that deals with groups. You can see it though in /etc/group. Unlike on plain vanilla Debian, /usr/local however doesn’t have staff group-ownership set.

Here’s what I did (note – it’s what I did, not what you should do – don’t trust a random blogger! – read the man pages for all of the following commands):

sudo adduser staffer #you can enter any password you like, because...
sudo passwd -l staffer #disables the password, just like for the root account
sudo adduser staffer staff #adds staffer to the staff group
sudo chown -R root:staff /usr/local #set group-ownership like on Debian
sudo chmod g+w /usr/local/* #make writeable for staff members
sudo chmod -R g+s /usr/local #setgid

Note that the last two lines work for me because I’m on a freshly installed Ubuntu Hardy, where /usr/local is still practically empty. If it’s not empty, this may set the setgid bit on some files, rather than on the directories only. I’m not sure if that’s a good thing (opinions welcome!). Now when you try this

cd /usr/local
touch testfile #error because you don't have write permission
sudo -u staffer touch testfile #no error
sudo -u staffer rm testfile
cd /usr
sudo -u staffer touch testfile #error

That’s it, basically. So now, you can install to /usr/local as staffer instead of as root, and you’ll get an error message when the installer at hand is trying to be naughty, writing to somewhere else. What’s this “staffdo” in the title of this post about then? Well, to make things look neat, I added

alias staffdo='sudo -u staffer'

to my .bashrc file. And you read all the way down this page to find out… hope it wasn’t disappointing!


Get every new post delivered to your Inbox.