Monday, 9 August 2010

Using Ubuntu 10.04 ltsp workstations as character terminals

I've finally got round to updating our LTSP setup to use Lucid. We have a number of LTSP terminals that work just at the character terminal level, with the screens doing a telnet into another system and with no X Window running on them at all.

Lucid's switch to the Plymouth startup system has an interesting side effect with this - namely that with the default setup, you are left just looking at the Plymouth screen and are not able to access any of the VTs to do anything else.

The solution is a custom entry in the pxelinux.cfg directory relevant to the Lucid boot set (in my case /srv/tftp/ltsp/lucidi386/pxelinux.cfg - note the change from previous versions where /var/lib/tftpboot has been replaced by /srv/tftp)

I've rearranged the IP addresses of my text only workstations so that they are all in a block of 16 IP addresses which will look for the same config file using the hex address notation that PXE uses. Then in that file I put

default ltsp-text

label ltsp-text
kernel vmlinuz
append ro initrd=initrd.img quiet splash nbdport=2004 vga=normal nomodeset


This has the added advantage that the console stays at 80x30 characters which is very usable for the application that we are using.

Monday, 26 July 2010

Using https with wget

The version of wget installed on a debian box seems to not like doing https by default due to not knowing about the CA certificates.

Here's a solution I found:

Download cacert.pem from http://curl.haxx.se/docs/caextract.html and put it in /etc/ssl/certs

Then amend /etc/wgetrc to add the line

ca_certificate=/etc/ssl/certs/cacert.pem

Then wget knows about the CA certificates and all is well for https

Monday, 24 May 2010

Thunderbird 3 in a business setup

For a number of years we've used Thunderbird as the mail client of choice. It has a good feature set and does IMAP well. However, the advent of Thunderbird 3 adds a little issue.

To reduce the size of roaming profiles (and therefore speed up login and log out) we have thunderbird profiles mapped to a directory within the users' login directory - and hence stored on the server. Thunderbird 3, automatically downloads copies of all the users' IMAP email to make both an offline cache and to index the mail for the new search facility.

This would mean that the server space used by the Thunderbird profile would grow considerably.

So there's two choices. Either disable the global indexing and off line store or put the off line store somewhere else.

As the new search is a good tool, I've opted for the second - though I'll leave it up to the users as to whether they use the search tool or not.

The solution here is to add a couple of files to each machine running Thunderbird:

Firstly in the defaults/pref/ folder (/usr/lib/thunderbird-3.0.4/defaults/pref on linux , C:\Program Files\Thunderbird\defaults\pref on windows) I add a little file custom.js

/* Custom local config */

pref("general.config.obscure_value", 0);
pref("general.config.filename", "custom.cfg");


The first of those settings means that you can write your config file in plain ASCII rather than a strange encoding and the second is the name of the custom config.


Next, the custom config goes in /usr/lib/thunderbird-3.0.4 for linux or C:\Program Files\Thunderbird for windows

//
/* This will disable indexation by default - can be enabled per user */
defaultPref("mailnews.database.global.indexer.enabled", false);

/* This will disable offline download by default */
defaultPref("mail.server.default.offline_download", false);

/* This will parse the prefs.js and set the directory for "offline_download" for each IMAP account */

if(getenv("USER") != "") {
// *NIX settings
var env_user = getenv("USER");
var env_home = getenv("HOME");
var env_os = "linux";
} else {
// Windows settings
var env_user = getenv("USERNAME");
var env_home = getenv("HOMEPATH");
var env_os = "windows"
}

if (getPref("mail.accountmanager.accounts")) {

var listExistingAccounts = getPref("mail.accountmanager.accounts");
var arrayExistingAccounts = listExistingAccounts.split(',');

for (var i=0; i < arrayExistingAccounts.length; i++){
var serverFromAccount = getPref("mail.account." + arrayExistingAccounts[i] + ".server");
var configType = getPref("mail.server." + serverFromAccount + ".type");
if (configType == "imap") {
defaultPref("mail.server." + serverFromAccount + ".offline_download", false);
lockPref("mail.server." + serverFromAccount + ".server_sub_directory", "INBOX.");
var serverName = getPref("mail.server." + serverFromAccount + ".hostname");
var userName = getPref("mail.server." + serverFromAccount + ".userName");
if (env_os == "windows") {
lockPref("mail.server." + serverFromAccount + ".directory", "[LocalAppData]Thunderbird/" + serverName + "/" + userName);
lockPref("mail.server." + serverFromAccount + ".directory-rel", "[LocalAppData]Thunderbird/" + serverName + "/" + userName);
}
if (env_os == "linux") {
lockPref("mail.server." + serverFromAccount + ".directory", "/opt/mailcache/" + env_user + "/" + serverName + "/" + userName);
lockPref("mail.server." + serverFromAccount + ".directory-rel", "/opt/mailcache/" + env_user + "/" + serverName + "/" + userName);
}
}
}
}


I also take advantage of this to set the server directory for the IMAP folders to INBOX. as that gives the better layout of mailboxes in Thunderbird when talking to a Courier IMAP server.

On a Windows machine, I set the users' offline cache to being in the Local Settings part of their profile - this keeps it safe to the user but avoids it being synced to the server.

For a Linux machine, I set up an area called /opt/mailcache with the same kind of permissions as /tmp i.e. globally writable but with the sticky bit set. This has the result that individual users can't get at each others mail cache.

In our LTSP setup, /opt/mailcache will be excluded from the backup as there is no need to back this stuff up as it is simply a copy of what is already in the mailbox.

Tuesday, 6 April 2010

Windows 7 on a Samba domain

After years of happily running Samba domains controlling Windows XP machines, I've had to investigate how Windows 7 integrates into that environment.

I usually use Debian as the server platform of choice. This has the benefit of a stable software platform at the detriment of not always being up to date. And in this instance that is a problem. Some of the bits that are required in Samba to support 7 in a domain environment don't appear until later versions of Samba than the one currently shipped with Debian "lenny" - the current stable release.

Fortunately the very nice people at SerNet provide Debian packages for the latest Samba release (http://enterprisesamba.com/index.php?id=148) - so by simply adding the relevant repository and installing sernet-samba in place of the normal samba, we can get these extra features.

There are still a couple of registry hacks needed to make 7 work:

HKLM\System\CCS\Services\LanmanWorkstation\Parameters
DWORD DomainCompatibilityMode = 1
DWORD DNSNameResolutionRequired = 0

And then it will join the domain. There is a warning that pops up about dns issues, but that is fine to ignore and it will work.

Now, the next fun part is that due to the drastic changes in profile data between XP and 7, the two won't share a profile - so you end up with two for each user if you are in a mixed environment. This is not a problem as such, but you will want to consider some folder redirection, particularly of My Documents to a location that both can see, otherwise you'll have a different copy of documents for each operating systems.

If you set that to be a network location - which would be the most sensible - then on desktop PCs you'll probably also want to disable offline files. While they're great for laptop users, there is no point in syncing each users files to the desktop in an environment where the machines never leave the network, plus the system tends to get rather confused as it keeps trying to connect to sync other users files without the appropriate permissions to do so.

Wednesday, 10 February 2010

Ubuntu machine with NFS home and LDAP authentication

A while ago I posted about joining Ubuntu machines to an NFS / NIS setup. Well, things have moved on since then; both later Ubuntu distros and our authentication is now LDAP. So, here's the up to date procedure. This does assume some knowledge of linux commands and familiarity with editing config files.

As before, the first issue is that of moving /home. And that hasn't changed. When setting up the machine create a user who is local to the machine - pick a name that won't clash with any user in the LDAP - and then after the initial setup, boot in single user mode and move /home to /localhome. Then edit /etc/passwd to change references to /home into /localhome.

To allow NFS shares to be mounted install the nfs-common package. Then you can edit /etc/fstab to include the mounting of any NFS shares (after having made the mount point)

e.g.

bigserver:/home /home nfs defaults 0 0

Then to get the authentication going you want to install libnss-ldap and libpam-ldap. The installation of these packages will ask for the details of your LDAP setup such as the base dn and the admin cn and password.

Give it a re-boot and you should be off and running.

One caveat - due to the timing of things launching - you may see warnings about certain partitions not being mounted. This can be caused by delays in getting a network address.

A quick fix for this is to add "mount -a" to the /etc/rc.local file to force a re-try at any mounts that fail at the end of the boot process.

If you want to allow any of your users to have special powers on the desktop then /etc/security/group.conf is your friend. This grants extra group membership to logged in users depending on where they come from and what time / day it is.

You will probably want a line like:
gdm;*;*;Al0000-2400;cdrom, floppy, audio, video, plugdev

to allow all users at the desktop access to relevant hardware

But you may also want
gdm;*;importantuser;Al0000-2400;lpadmin, admin

To allow importantuser to do administrative things. You'll then need to add
auth optional pam_group.so
to /etc/pam.d/common-auth to make this active.

Friday, 20 November 2009

Creating user based firewalls on inbound pptp connections

There are certain security situations where you want to be able to allow a remote user to connect to your network using pptp, but you want to lock down what devices on the network they have access to.

Usually with the linux pptp system, once the user is connected, assuming ip forwarding is running on the host that is the pptp end point, they have access to anything on the local subnet.

What I've done to allow some control over this situation is create some custom scripts to go in /etc/ppp/ip-up.d and /etc/ppp/ip-down.d

For the "up" version I have:

#!/bin/sh

PPP_USER=`/usr/bin/w | /bin/grep "$PPP_IFACE" | sed "s/ .*//"`

if [ -x "/etc/ppp/userfw/$PPP_USER" ]; then
"/etc/ppp/userfw/$PPP_USER"
fi

exit 0


and for the down version I have

#!/bin/sh

PPP_RULE=`/sbin/iptables -L FORWARD -n -v --line-numbers | /bin/grep "$PPP_IFACE" | /usr/bin/head -1 | /bin/sed "s/ .*//"`
while [ "$PPP_RULE" != "" ]
do
/sbin/iptables -D FORWARD "$PPP_RULE"
PPP_RULE=`/sbin/iptables -L FORWARD -n -v --line-numbers | /bin/grep "$PPP_IFACE" | /usr/bin/head -1 | /bin/sed "s/ .*//"`
done

PPP_RULE=`/sbin/iptables -L INPUT -n -v --line-numbers | /bin/grep "$PPP_IFACE" | /usr/bin/head -1 | /bin/sed "s/ .*//"`
while [ "$PPP_RULE" != "" ]
do
/sbin/iptables -D INPUT "$PPP_RULE"
PPP_RULE=`/sbin/iptables -L INPUT -n -v --line-numbers | /bin/grep "$PPP_IFACE" | /usr/bin/head -1 | /bin/sed "s/ .*//"`
done

exit 0


Then create a directory /etc/ppp/userfw and put in there per user scripts

e.g.
#!/bin/sh
/sbin/iptables -A FORWARD -i "$PPP_IFACE" -j ACCEPT
/sbin/iptables -A INPUT -i "$PPP_IFACE" -j ACCEPT


(yes - that's a silly example as it just gives complete access - which they had anyway)

With this lot, you have a simple method to lock certain users down to only be able to access certain things on your network - within the flexibility of the iptables system. The important thing to do is to make sure that your user based rules all reference the interface with $PPP_IFACE so that they are attached to the right connection and they're deleted again with the down script when the interface is removed.

Monday, 2 November 2009

Bluetooth pairing on the command line

I use a debian linux box with the Gnokii SMS daemon to do computer based texting. Now normally on a server I wouldn't want to go to the bother of installing Gnome - after all, you don't sit at the server console. But, that can be an issue for doing the bluetooth pairing needed before you can use the phone with gnokii.

The answer is in /usr/share/doc/bluez-utils/examples. There's some C code in there called passkey-agent.c

Make sure you have build-essential and pkg-config and libdbus-1-dev installed then you can build it.

Then, in one terminal window run "passkey-agent 1234" and in another do "rfcomm connect rfcomm1 xx:xx:xx:xx:xx:xx" to connect to your device. The pairing will then be on the key 1234.

A useful trick to avoid installing a huge amount of stuff just to do a one off job.

Update:
Debian squeeze ships with a command "bluetooth-agent" which replaces the passkey-agent and is already complied, so you just need to do "bluetooth-agent 1234" in one terminal to set up the passkey.