Not only that, but the behaviour was quite bizzare: upon my first attempt to connect the public key would get rejected and a regular password would be requested by the ssh session. But once I successfully logged in with my password, any subsequent ssh connections would happily authenticate by my public key and would let me in without a problem.

Those of you using home dir encrypiton in Ubuntu are probably smiling right now! But becase I have never consciously configured or used this feature, it took me a good few hours to troubleshoot the issue and come up with the fix.

Why public-key based SSH doesn't work with encrypted home directories

The answer is quite simple: before your server can decide whether you are providing a valid and trusted SSH key, it must read your public key stored in your homedir. But if your homedir is encrypted, this becomes a classical chicken-and-egg scenario – until you log in and therefore decrypt your homedir the server won't gain access to your public key. Only you wouldn't be needing the public key by then, would you?

Store your authorized SSH keys outside your encrypted home directory

If you happen to like your homedir encryption AND would like to use public/private key SSH authentication,  there is a way out: you need to store your authorized keys outside of your encrypted homedir.

The usual access restrictions and directory/file permissions still apply, so the only thing you're changing is moving your authorized keys outside of the encrypted homedir on your server. This way things will work exactly as you expect: you authenticate with your private key and this results in your automatically mounted and decrypted homedir.

Here are the steps to make this happen. You're going to need superuser privileges for my scenario because it caters for all the users on your Ubuntu server, not just one account that belongs to you (use sudo to become root).

Step 1: create a directory structure for your authorized keys.

First, the main directory, I created it under /var – seems quite a safe choice since this directory is unlikely to grow and is equally unlikely to get removed by accident.

# mkdir /var/openssh

Perfect! Now we need to create user-specific directories, just to keep this dir really tidy. My username is "greys", so here is the directory:

# mkdir /var/openssh/greys
# chown greys /var/openssh/greys

Step 2: copy existing authorized keys file into new location

(you must log in as your username for this, otherwise the homedir will stay encrypted)

$ cp /home/greys/.ssh/authorized_keys /var/openssh/greys

Step 3: update SSHd config with new location for authorized_keys file

You're going to do this as root once again:

# vi /etc/ssh/sshd_config

update the value of the AuthorizedKeysFile so that it looks like this:

AuthorizedKeysFile        /var/openssh/%u/authorized_keys

Step 4: Restart SSH service

# service ssh restart
ssh start/running, process 3708

That's it! Give it a try and let me know how it worked out.

Recommended books:

See also

• How To Enable Secure Shell service in Ubuntu

I have great plans for UnixTutorial in 2012, and would welcome any opportunity to share knowledge and experience with all of the readers and new visitors
of this blog.

Here's just a few of the things I plan to do:

• UnixTutorial members area – long time coming, this area of the website will finally make a proper debut in the next few months. I'll be announcing the next round of email subscriptions shortly, so don't miss out if you're still interested
• A series of UnixTutorial eBooks – eventually a balanced collection of free and paid material in PDF and Kindle formats (polls to decide which topis are in demand will follow shortly)
• Broader coverage of Unix topics – this year I expect to write a lot more about Mac OS and AIX systems
• New WordPress theme and quite likely a mobile copy of the website (let me know what devices you have, I own  iPhone and iPad so will do initial testing)
• Completion and expansion of the Basic Unix Commands and Advanced Unix Commands sections
• More Unix book reviews and recommendations
• Reviews of latest Unix-like OS releases
• Even more Questions and Answers

If you expect to see even more – now would be a really good time to let me know by leaving a comment. Thanks and stay tuned!

Not everyone is aware that dig command is very useful for entry-specific DNS research. This post just shows you a very simple example.

dig to confirm TTL for a DNS entry

When using dig, we're usually after a specific section of its output. Consider this simple query (your output may slightly vary):

srv1# dig www.google.com

This query targets a specific DNS record – namely the www. one, rather than a whole google.com domain.

; <<>> DiG 9.7.1-P2 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4968
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 13, ADDITIONAL: 8

;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         541187  IN      CNAME   www.l.google.com.
www.l.google.com.       156     IN      A       209.85.148.104
www.l.google.com.       156     IN      A       209.85.148.105
www.l.google.com.       156     IN      A       209.85.148.106
www.l.google.com.       156     IN      A       209.85.148.147
www.l.google.com.       156     IN      A       209.85.148.99
www.l.google.com.       156     IN      A       209.85.148.103

;; AUTHORITY SECTION:
com.                    37414   IN      NS      d.gtld-servers.net.
com.                    37414   IN      NS      e.gtld-servers.net.
com.                    37414   IN      NS      g.gtld-servers.net.
com.                    37414   IN      NS      f.gtld-servers.net.
com.                    37414   IN      NS      a.gtld-servers.net.
com.                    37414   IN      NS      h.gtld-servers.net.
com.                    37414   IN      NS      b.gtld-servers.net.
com.                    37414   IN      NS      m.gtld-servers.net.
com.                    37414   IN      NS      c.gtld-servers.net.
com.                    37414   IN      NS      j.gtld-servers.net.
com.                    37414   IN      NS      i.gtld-servers.net.
com.                    37414   IN      NS      l.gtld-servers.net.
com.                    37414   IN      NS      k.gtld-servers.net.

;; ADDITIONAL SECTION:
a.gtld-servers.net.     22830   IN      A       192.5.6.30
a.gtld-servers.net.     23008   IN      AAAA    2001:503:a83e::2:30
c.gtld-servers.net.     581     IN      A       192.26.92.30
d.gtld-servers.net.     581     IN      A       192.31.80.30
e.gtld-servers.net.     581     IN      A       192.12.94.30
f.gtld-servers.net.     581     IN      A       192.35.51.30
g.gtld-servers.net.     23226   IN      A       192.42.93.30
h.gtld-servers.net.     581     IN      A       192.54.112.30

;; Query time: 1 msec
;; SERVER: 88.198.6.2#53(88.198.6.2)
;; WHEN: Fri Jul  1 03:50:38 2011
;; MSG SIZE  rcvd: 512

We're only interested in the ANSWER section:

;; ANSWER SECTION:
www.google.com.         541187  IN      CNAME   www.l.google.com.
www.l.google.com.       156     IN      A       209.85.148.104
www.l.google.com.       156     IN      A       209.85.148.105
www.l.google.com.       156     IN      A       209.85.148.106
www.l.google.com.       156     IN      A       209.85.148.147
www.l.google.com.       156     IN      A       209.85.148.99
www.l.google.com.       156     IN      A       209.85.148.103

As you can see from this example, the global www.google.com name is a CNAME entry with quite a high TTL, pointing to a number of www.l.google.com A entries with a much smaller TTL. In this particular example, the TTL for each www.l.google.com is 156 seconds, which is slightly less than 3 minutes.

Once that's done, you can use do-release-upgrade for a hassle free upgrade.

IMPORTANT: are you can see, I've used a really old Ubuntu server with 8.10, hence your procedure for upgrading more recent Ubuntu versions may be slightly different. For example, later upgrades will warn you if you're doing a release upgrade over ssh.

What do-release-upgrade is and when you should use it

do-release-script is a Python script which automates the process of updating multiple packages. It relies upon Ubuntu's core package management functionality.

Apart from downloading and installing updated versions of packages found on your system, this command attempts to take care of all the necessary Ubuntu-release related file changes.

Step 1: Run do-release-upgrade

Once you type the do-release-upgrade command name and press Enter, you should see how vital information about packages currently installed is being collected:

# do-release-upgrade
Checking for a new ubuntu release Done
Upgrade tool signature Done
Upgrade tool Done
downloading
extracting 'jaunty.tar.gz'
authenticate 'jaunty.tar.gz' against 'jaunty.tar.gz.gpg'
Reading cache
Checking package manager
Reading package lists: Done
Reading state information: Done
Updating repository information
Done http://archive.ubuntu.com jaunty Release.gpg
Done http://archive.ubuntu.com jaunty-updates Release.gpg
Done http://security.ubuntu.com jaunty-security Release.gpg
Done http://us.archive.ubuntu.com jaunty-backports Release.gpg
Done http://security.ubuntu.com jaunty-security Release
…
Checking package manager
Reading package lists: Done
jaunty-security/multiverse
Packages: 98  2
Reading state information: Done
Reading state information: Done
Reading state information: Done
Calculating the changes

2. Confirming what upgrading will do

This is your last change to change your mind. All the necessary information about your current Ubuntu release is collected, and now you're presented with the exact upgrade details: how many packages will be removed, how many new ones will be installed, how many will be upgraded. You also are given details about the required amount of data to be downloaded should you decide to proceed with the upgrade;

Do you want to start the upgrade?

1 package is going to be removed. 23 new packages are going to be installed. 420 packages are going to be upgraded.

You have to download a total of 248M. This download will take about 7 minutes with your connection.

Fetching and installing the upgrade can take several hours. Once the download has finished, the process cannot be cancelled.

Continue [yN]  Details [d]

Ready? Press y for yes!

3. Downloading all the packages

Just like with apt-get, you will now see the progress of downloading all the updated packages for your Ubuntu OS. At the bottom of the screen you will see the overall completeness of the download (22% in my example), the current download speed (598kB/s in my case) and the ETA:

Done http://archive.ubuntu.com jaunty-updates/main libbz2-1.0 1.0.5-1ubuntu1.1
Done http://archive.ubuntu.com jaunty/main libdb4.7 4.7.25-6ubuntu1
Done http://archive.ubuntu.com jaunty/main libncursesw5 5.7+20090207-1ubuntu1
Done http://archive.ubuntu.com jaunty-updates/main libssl-dev 0.9.8g-15ubuntu3.6
Done http://archive.ubuntu.com jaunty-updates/main libssl0.9.8 0.9.8g-15ubuntu3.6
Done http://archive.ubuntu.com jaunty/main python2.6 2.6.2-0ubuntu1
[23%] 598kB/s 5min17s

4. Upgrade

Once package are downloaded, they will get installed once by one, with package-specific questions asked for software like postfix or apache.

5. Reboot

To finalize the distro upgrade, you will need to do a reboot. Once completed, you should have a shine next release available.

Recommended books:

While Mac OS is unlike any Unix-like operating system I've managed so far, there are certainly some of similarities. I can honestly say that I'm enjoying the Mac Book Pro so far, and hope to discover most of the differences compared to my previous Unix-like desktop which is Ubuntu 9.10.

Mounting NFS on MAC OS X

One thing which I noticed immediately was that out of the box it was impossible to mount any NFS shares from my Ubuntu NAS server. Any attempt to mount a remote filesystem would give me an error like this:

mbp:~ root# mount nasbox:/try /mnt
mount_nfs: /mnt: Operation not permitted

This error was happening for a relatively simple NFS share on the Ubuntu box:

nasbox# cat /etc/exports
/try            (rw)

… so I started looking around and realized that the reason for this strange problem is quite simple.

Mac OS X uses non-standard port for outgoing NFS connections

That's right – apparently, Mac OS X uses a non-privileged port (2049) for TCP and UDP connections serving the NFS transport. What this means is that most likely attempts to mount remote filesystems will fail, because most NFS servers don't really like connections from insecure ports.

There are two ways to approach this problem:

1. Fix it on the client side (probably makes more sense)
2. Fix it on the NFS server side (if you manage both systems)

Using reserved NFS port number on Mac OS X

There's a mount option supported by the mount_nfs command, which allows you to force the NFS client connections to originate from a privileged port. This will magically make your attempts to mount remote filesystems successful. The option is called resvport.

First we double-check that default mounts still don't work:

mbp:~ root# mount nasbox:/try /mnt
mount_nfs: /mnt: Operation not permitted

… and now let's use the resvport option:

mbp:~ root# mount -o resvport nasbox:/try /mnt

… and make sure we're actually looking at a mounted filesystem:

mbp:~ root# df -h /mnt
Filesystem   Size   Used  Avail Capacity  Mounted on
nasbox:/try    61Gi   56Gi  2.6Gi    96%    /mnt

Allowing connections from non-privileged ports on NFS server

Like I said, if you manage both the Mac OS based client and the NFS server, perhaps it makes more sense to relax the default NFS server security and allow the connections from non-privileged ports.

Just to remind you about the validity of such a decision, the option to allow non-privileged connections is called insecure.

Here's how you use it:

nasbox# cat /etc/exports
/try            (rw,insecure)

After making this change to the /etc/exports file, you'll have to restart your NFS server. On my Ubuntu NAS box, it's done like this:

nasbox# /etc/init.d/nfs-kernel-server restart
* Stopping NFS kernel daemon
…done.
* Unexporting directories for NFS kernel daemon…
…done.
* Exporting directories for NFS kernel daemon…
…done.
* Starting NFS kernel daemon
…done.

We know are ready to attempt the default mount of the same filesystem on the Mac OS X client:

mbp:~ root# mount nasbox:/try /mnt

That's it! I won't promise any Mac OS posts just yet, but if there is enough interest – I'd love to do the research and to post all the discoveries on the Unix Tutorial pages.

If you're an existing member and have a topic which you think belongs to the Operating Systems Basics module, please leave a comment.

The purpose of the module is to give a very high level overview of how modern operating systems work and to also explain the importance of securely managing all the available resources (hence a few topics on files, users and privileges). Almost every single topic deserves a separate module, if not a course, on its own – but for the moment it will be really basic stuff.

Here's the list of topics so far:

• What OS is and why we need it
• Features of a modern OS
• Kernel and kernel modules
• Features of Unix OS
• MINDMAP: Features and components of an OS
• Everything is a file! Types of files in Unix
• A typical filesystem tree of a Unix-like OS
• Users, privileges and file ownership
• Executing a binary file in Unix

To all those of you asking for the date when this module will be posted: I will make the Operating Systems Basics module available to all the existing Unix Tutorial Members on February 1st, 2010.

See also:

• Unix Tutorial – members area
• What Unix Tutorial members area is about
• Unix Tutorial gets a Facebook page

See you all there, and feel free to share your suggestions – either here or on the wall of the Unix Tutorial page.

How to confirm if IPv6 is running on your system

IPv6 is implemented as a kernel module, so you can use the lsmod command to confirm if it's currently running on your Red Hat system:

$ lsmod | grep ip
ipv6                  410913  36

If lsmod doesn't return anything, it confirms that your system isn't running IPv6.

Prevent IPv6 from getting started by modprobe

As you probably know, modprobe command is used for probing modules upon system boot. Probing simply means a module is loaded and an attempt is made to start it up. With any luck, the module starts successfully and its functionality becomes available to the Linux kernel.

For the boot stage, modprobe uses a special config file which helps you control its behavior: /etc/modprobe.conf. For now, let's just concentrate on the IPv6 task at hand. To make sure modprobe doesn't load the actual module next time your OS reboots, add the following line to the top of the /etc/modprobe.conf file (yes, you're going to need root privileges for this):

install ipv6 /bin/true

WHY THIS WORKS: just to quickly explain the line above, here's why we're using the /bin/true command. install is rule of the modprobe config file which overrides the standard way of probing a module. Effectively, it tells modprobe to just run the specified command for starting a module. In the line above, we're telling modprobe to use the /bin/true command for probing the ipv6 module. And as you remember, /bin/true is a command which doesn't do anything but still returns a successful completion code – so in effect we're doing nothing instead of loading the ipv6 module, and we're looking good while doing this too.

Next, add the the following two lines to the same /etc/modprobe.conf file, and they will ensure that common aliases used for starting the IPv6 module are ignored by modprobe:

alias net-pf-10 off
alias ipv6 off

IMPORTANT: These change doesn't immediately disable IPv6 on your system. Being a pretty important module, IPv6 isn't easy to disable on a live system, and so the easiest is to always follow the changes above with a reboot.

Make sure your IPv6 firewall is disabled

The ip6tables service (/etc/init.d/ip6tables sciprt) is responsible for starting IPv6 firewall, and so you probably want to disable it:

# chkconfig ip6tables off

and then confirm that it won't be started next time you reboot or switch to any runlevel:

# chkconfig --list ip6tables
ip6tables       0:off   1:off   2:off   3:off   4:off   5:off   6:off

That's it, there really is nothing else to disabling IPv6. Let me know if you have any questions, otherwise I'll talk to you soon!

Since Unix Tutorial is a technical blog, I'll try and stay as technical as possible within the topic.

Virtualize to consume less energy, get rid of old hardware

Old servers required a much bigger commitment in the past: not only did they cost a fortune, but they also needed a lot of space and required a lot of power. These days, 1u or 2u server solution can easily outperform a computing system which used to take a whole cabinet in your datacentre. And since the cost of supporting old hardware only increases with each year, it makes a lot of sense to simply but a new server to replace the old infrastructure.

If you're really big into the whole life cycle thing, an even better approach is to virtualize most of your systems. There are quite a few great solutions today – vSphere from VMware, Xen and KVM based virtualization from RedHat and the xVM family of virtualization solutions by Sun Microsystems (Oracle).

A ratio of 15 virtual machines per 1 physical server isn't that uncommon, which can give you an idea about the kind of improvement you'll get by following the route of virtualization.

The math is really simple: shut down 15 old servers, keep only 1 new server running – this means greatly reducing the amount of energy and therefore helping the planet stay green for a bit longer.

Read from your screen, print less

Perhaps on a much smaller scale, the issue of printing materials is also a direction you may want to explore if you're serious about helping the climate change prevention.

Many of us still print dozens of sheets of A4 paper a day. We print out emails and directions, man pages and screenshots – many of these to never be used again.

Start small and pay attention to every urge of yours to print something out. Ask yourself a few simple questions just to be sure that you absolutely need each piece of the information printed out.

As a Unix administrator, you should find ways to monitor your printing service. Even simple things like weekly stats of the top users printing stuff out might sometimes help you save really big on the paper and toner cost. Many users print stuff out without a certain reason for doing so – it's just their habit.

This means that if you're familiar with lpstat and lpadmin commands, you have a chance to help yourself and others become more aware of how much you're printing and what can be done to break your printing patters.

eInk-based book readers are a great alternative for those of you who claim they absolutely can't read off screen. It may be a while until A4-sized readers become widely available and affordable, but already you can get a book reader for just a few hundred dollars and this little device can be used for storing and reading of many books – all without much of an environmental impact, since you no longer need paper books.

Use only what you need

You'll be amazed how much can be saved if you run CPUs on your system at the speed sufficient to fulfill your computational needs instead of having everything running at 100% of their speed!

Many modern servers have power-awareness and intelligence built-in. I especially like blade server solutions – Dell, HP and Sun have all got a range of blade enclosures and blade servers on offer.

The beauty of using blades is that blade enclosures are extremely intelligent and configurable devices – you can use them to cap the power draw for your whole enclosure or a certain blade. Such power limitations will usually result in a lower performance, but for many solutions it's not critical at all. For example, if your blade hosts a FlexLM licenses server or serves web pages, it will be almost impossible to spot a performance difference even if you significantly lower the CPU speed.

Most operating systems support power management options. For desktops, this means ability to manage the speed of your cooling fans or the speed of your CPU which immediately has an impact. Sometimes you can also control your graphics card in the same manner. If you add screen blanking and hard drives management to this (configuring the sleep times for periods of long inactivity), you have all you need to reduce the power draw of your PC and ultimately help our planet stay the way it currently is or maybe even get refreshed over the next few years.

That's it for today! Sure enough, these tips may not seem to be all this climate change preventative, but trust me – we all have to participate with however small steps and environmental improvements we can think of.

See also:

• Blog Action Day website
• Change
• Desktop Virtualization website

If you're in need of quick help – drop me a message on Twitter – I'm UnixTutorial there. I can't promise a prompt reply, but at least this way you'll have some interactivity.

I see how many people leave questions in comments to my posts, and I don't always have the time to reply – so feel free to send me an email if you really need my help.