Rob's Tech Fun and Games

Just a quick sneaky trick – if you’re used to being able to run terminals as root, or you need to run a lot of commands as root, and are sick of having to type sudo every time, there is a sneaky way of increasing your privileges for the terminal sessions. 

Open a terminal, and run:

sudo su

and you have a terminal running as root!  running su by itself doesn’t work with Ubuntu … but if you sudo the command, it does.  Generally, this isn’t great practise – its too easy to make a mistake and damage the system, so use with caution!

Setting the hostname on an Ubuntu linux installation is pretty easy during the installation.  However, for a standard image to be dropped onto a wide range of machines, it really needs to be unique and set via a script.

We like to use the serial number of the PC in question, though this is more or less practical depending on the brand of PC.  Acer, for example, tend to have VERY long serial numbers – it may be unique, but its going to be harder to type than just an IP address.  IBM tend to use reasonable 7 digit strings, which is is much more usable.  Other brands can be longer or shorter.

Setting hostname itself seems easy – just run

hostname <newname>

(where sudo is used to run the command as root) in a terminal, and the hostname of the machine will change.  You’d think we were done, but unfortunately not!  This will only change the hostname until the next reboot.  On startup, the contents of the file

/etc/hostname

is used to set the  hostname.  To update this, I like to set the hostname for the current sessions, then run

hostname > /etc/hostname

(as root) which willoverwrite the file with the current hostname.  If running as part of a script on startup, this will set the hostname now, then update the file for future restarts.  However, we still aren’t done.  We need to update another file

/etc/hosts

with the details of the name for networking purposes.  We need to add the hostname, and any domain name aliases too.  The hosts file will probably look something like:

127.0.0.1                        localhost                 localhost.domain.local

127.0.1.1                        <hostname>

Update the hostname line, and add new aliases for the hostname for any domains that may be relevant.  At this point, the system is renamed!  However, this is all still pretty manual – ideally we need to script the process.

Now, to get the serial number, we can query the bios using the dmidecode command, and then process it usign the myriad of linux text handling commands.

dmidecode | grep “Serial Number” | head -n1 | sed -e ‘s/\tSerial Number: //g’

(as root, again) should return the serial number from the bios!  We can combine this with the hostname command, as follows:

hostname $(dmidecode | grep “Serial Number” | head -n1 | sed -e ‘s/\tSerial Number: //g’)

(once again, as root.) This will set the hostname to the serial number.

I actually combine all of the commands discussed to form a single script -

hostname $(dmidecode | grep “Serial Number” | head -n1 | sed -e ‘s/\tSerial Number: //g’)

hostname > /etc/hostname

echo “127.0.0.1       localhost     localhost.domain.local” > /etc/hosts.new

echo “127.0.1.1     ”$hostname”     “$hostname”.domain.local” >> /etc/hosts.new

mv /etc/hosts.new .etc/hosts

This sets the hostname, then updates the hostname file.  It then generates a complete hosts file line by line, and overwrites the old version.  There are probably better ways of updating the text file directly, but this works effectively enough.

Finally, I set this script file (which I named hostname.sh) to run on system startup.  Simply copy the file to

/etc/init.d

and run (as root)

update-rc.d hostname.sh defaults

where hostname.sh is the chosen name for your script.  This will add the script to the startup scripts on the machine, where it will automatically be run as root.

Recently, I’ve been playing with Linux, specifically Ubuntu, in an attempt to set up a simple, maintainable client for virtual desktops.  Its been a fair while since I’ve used linux in a serious sense, so I thought I’d post up what I’ve done, as I progress (largely for my own reference, but hopefully others might find it of use!)

Key requirements are:

A virtual client!  In this instance, the vmware open client will need to be installed and configured on the desktop.  There are still limitations with the open client that may break the plan – limitations with remote media playback, and usb redirection are two areas in particular that may cause issues.

A working web browser!  Of course, Firefox is an obvious standard, installed with Ubuntu, so thats not much of a challenge, at least on the surface.  Beyond a working web browser, we need to possibly extend our server architecture to support browsers beyond Internet Explorer for our key wep applications, allowing a level of work to be carried out in the event of virtual desktop failures.  This is where things get a lot harder!

A standard environment across different hardware, locked down for the default user.   This is actually quite tricky.  By default, linux is designed to be easy to customise and configure, so locking it down to a single user, while allowing network proxy changes and wireless connections, is actually quite a challenge.  In addition, desktop launchers will need to be variable, depending on local printer installations for users on laptops with home printer (vmware-view allows you to redirect a printer, but you need to specifically do it by name).

An architecture to allow remote reconfiguration, support and updates across a company wide platform.  This is one of the worst areas – linux still lags quite badly behind the sort of architecture taken for granted on a Windows network when it comes to administration through global policies.  It’s still fundamentally a server operating system,and admin tools generally focus on supporting machines runnign in that capacity, not as clients.  This is the hardest area of all, looking forward to a possible roll out of well over a thousand machines world wide, with a technical team with no linux experience!  Keeping the client simple and cheap, allowing machines to be swapped instead of supported is a very high priority where possible.

Hopefully the next series of posts on this topic will be useful, although its quite a change of tack from SharePoint!  Don’t worry, as new SharePoint issues come up, I’ll still be posting on that topic too.