After the usual install on a Windows server, including dot.net and a SQL server or the integrated thingie, I can connect with a BlackBerry Web browser to the IP of the Mobile Admin server and download the necessary software OTA.

When I start it, I'm welcomed with a login screen on my device, where I get to enter my credentials:

Then, I better get used to seeing this:

I get a list of servers I may manage.

If allowed to, I can add a server to this list from my BlackBerry handheld, or via the Mobile Admin Web interface, which looks identical in a normal Web browser (yes: Firefox is supported) to what I see on my hand held device.

I then select the server I want to connect to

and Mobile Admin connects to that server. It then shows me the tasks that I may perform on that server. This is an example of a Windows machine:

So, for example, I can open the Task manager

have Mobile Admin show me the processes running on the server

and kill one of them:

If I connect to a Lotus Domino server, I see:

Mobile Admin's feature list is impressive and contains MS Windows, Active Directory, BlackBerry Enterprise Server, Lotus Domino, Oracle, IBM Mainframes (i.e. 3270 client) as well as Unix/Linux servers (i.e. ssh).

The product looks promising, the price tag does as well. Approximately USD 600 per user plus maintenance.

deepOfix is LDAP-driven with an OpenLDAP server, brings SpamAssassin and ClamAV support with it and offers Webmail and the ubiquitious SMTP, POP3 and IMAP services.

I spent an hour test driving this software and it looks good. A clean web interface to manage the lot, shell access for root and optionally for individual users offer what a small business would need.

Note to self: keep an eye on this project.

Both tools do their job. rssh is more flexible in its configuration, and I know for a fact that it is also used by some large Internet Service Providers (ISP). Both tools support chroot jails which is good.

rssh appears to have the better logging features, but it lacks subdirectories in chroot jails.

On the other hand, scponly supports home-directories in the chroot environment with the // syntax (/var/chroot//home/jpm), meaning the chroot jail is in /var/chroot and the initial working directory is in /home/jpm thereunder. Unfortunately, there is no way to lock a user into the jailed home except by restricting permissions of the directories above (more like security through obscurity). I could of course create a chroot for each user, but that is cumbersome and a huge waste of disk space…

I've tested both tools with OpenSSH's SFTP, as well as with Windows versions of WinSCP and FileZilla without any issues, but I still have to make up my mind on which to use.

Turnbull takes the reader in a fast-paced but very comprehensive fashion through the arduous tasks of closing up the open holes in a Red-Hat or Debian – based Linux distribution, and he covers all major topics which include unlikely candidates such as the virtual terminals on the console, immutable files and capabilities, system logging, rootkits, and penetration detection and recovery.

After reading up on the basics which include users & passwords, Pluggable Authentication Modules (PAM), and information on hardening the Linux kernel and the boot loaders, the reader gets an excellent introduction to firewalling with iptables with a whole firewall script for a bastion host in the appendix. That is followed by a full chapter devoted to securing connections with SSL/TLS and remote administration with ssh.

Chapter four is dedicated to securing files and file systems, and includes a section on encrypted file systems to safekeep your data, as well as a walk-through Tripwire. That is followed by a comprehensive look at logging with syslog and syslog-ng, and this chapter includes a discussion and tools related to log analysis and correlation.

NMAP, Nessus and network sniffers make up the bulk of the security testing tools with which Turnbull rightly suggests we check our work after having hardened the basic system. These are covered on fourty pages.

Although Mr. Turnbull recommends Postfix, he covers both that and Sendmail, carefully noting that he doesn't want to contribute to the "my mail server is better than yours" wars. On over fifty pages, the two mail transport agents (MTA) are given careful consideration as to making them as secure as possible. In a further chapter aptly titled Authenticating and Securing Your Mail, the author covers SSL/TLS certificate generation with OpenSSL as well as SMTP authentication (SMTP AUTH) with Cyrus SASL, for both flavors of mail server.

As far as access to mail is concerned, the Cyrus IMAP server is well documented in chapter nine, and the last two chapters guide the reader through securing FTP servers as well as the BIND name server.

Every person responsible for installing a Linux server must read this book! There is of course also detailed information to be gathered from dedicated books which cover the individual subsystems (such as those for DNS & BIND, OpenSSH, etc.), but I strongly encourage every system administrator to have a copy of this excellent book on his or her desk.

The combination of the two appliances in one is quite interesting, and they even contain an LDAP-controlled software distribution system we developed specially for DAD & miniDAD.

We've created DAD for the enterprise administrator who wants to easily deploy Open Source to the site's user-base and who wants a migration path. All utilities supplied with DAD are geared towards making the process both painless and efficient. We've even included a utility which, when run on a Windows server, will export a list of users in such a way as that these can easily be imported into DAD. Alternatively, an NT trust can be set up between DAD and the Windows world.

In part 2, Michael Stahnke discusses the configuration of OpenSSH starting with a detailed look at the files required by the client and the server portions of the program including manual-page-like descriptions of the keywords in sshd_config and the options and syntax of the command-line tools. The chapter on Authentication digs into Public Key Authentication, key generation and distribution as well as key management (also taken onto a new level in a later chapter), and agent forwarding. This is a must-read for anyone who uses SSH to connect to more than one host.

The advanced topics start in part 3, and this is where the "Pro" begins. The complex topic TCP forwarding is well explained and a number of diagrams help the reader to better understand the nitty-gritty of setting up tunnels with OpenSSH.

The most interesting chapter I found next; Managing your OpenSSH Environment, in which the author introduces an OpenSSH secure gateway that can be used in large environments. Securing OpenSSH, SSH- and Key-Management are followed by SSHFP(Secure Shell Fingerprints) (RFC 4255), a method to store public host keys in DNS. Stahnke implements a method for distributing public keys using RPM(RedHat Package Manager). Although that is interesting in itself, I strongly missed a discussion on storing SSH public keys in an LDAP directory; a must-have IMHO.

Part 4 of Pro OpenSSH deals with Administration. Sundry Shell and Perl scripts in real-world examples give the reader a good look into the capabilities of using OpenSSH in her own tools on her own systems. Last but not least, the appendices focus on alternative SSH clients and SSH on Windows.

Even if you have, like I have, already read SSH, The Secure Shell, Apress' Pro OpenSSH is well worth reading. I give it an 8/10.

To this effect I have created a tiny Firefox and Thunderbird extension called whatmon, which can monitor almost anything you wish to monitor. Number of logged on users? Current load average? Health of your LDAP servers? Mail server queues? No problem for whatmon, as long as you can create a CGI(Common Gateway Interface) program in Perl, C, or any other language you are comfortable with, or even a PHP or Active-Whatever script which runs on your web server and can produce a wee bit o' XML(eXtensible Markup Language). There is one thing that whatmon can't watch: the web server from which it retrieves that XML …

whatmon periodically reads a short bit of XML text from a web server (in my case: Apache). The XML contains an integer status and a single line of text. In practice, that line of text can contain whatever the administrator desires. I want an indication of the health of the mail queues on a number of mail servers we have inhouse. The line of text therefore contains two-letter codes with which I can identify the hostname of the mail server in question as well as a count of mails on the queue for each of the servers in question.

The program that produces that line of text also returns a numeric integer indicating okay, warning or critical so that the extension can colour-code the status bar accordingly. Sample XML.

I've tried to keep this as simple as possible so as to not overcomplicate the extension proper (and because creating Mozilla extensions is about the worst I've ever had to do ). Each of the labels and values on the status bar could have been individually described in the extension, but then it would require modification whenever something changes. I didn't want that to happen.

The extension requires two preferences to be set. I've named these whatmon.url and whatmon.refresh. They are the URL from which the XML is to be read and the frequency in seconds in which the extension should do a GET request from the URL.

Use the configuration editor in Firefox or Thunderbird to create or change these settings. To call up the preference settings in Firefox, go to the URL about:config. In Thunderbird choose Tools => Options => Advanced => General => Config Editor. Create the two new settings by right-clicking on the page an choosing New => String. Enter whatmon.url as the preference name and the URL to your service (e.g. http://example.com/monit.php as its value. Repeat that step, for a new integer value, naming it whatmon.refresh and give it an integer number of seconds after which the extension should refresh the status bar. I'd think 120 or 60 should do the trick nicely. The preferences for whatmon should then resemble this:

After restarting Firefox or Thunderbird, whatmon will then periodically perform a GET request on the URL set in the whatmon.url preference.

The actual monitoring program is part of your web server, and it can be written in any language supported by the latter. It will return a tiny bit of XML text specifying both a status code and a string that whatmon will print to the status bar of Firefox or Thunderbird.

This simple example shell script displays the number of currently running processes on the server.

Visit fupps.com/extensions to download.

Can this be improved on? You bet! Firefox and/or Thunderbird need restarting whenever the URL preference changes. A nice options dialog with which the extension's preferences can be set would be welcome. Instead of plain text on the labels, I'd have liked to display images generated by the web server which change as the status changes. Any takers?

SSH(Secure Shell) also supports public-key authentication. Public-key authentication allows you to connect to a remote server without sending your password over the Internet. Public-key authentication uses two keys, a private key that only you have, and the public key, which is placed on the server you wish to gain access to, usually by yourself, adding your public key to the ~/.ssh/authorized_keys file. There is a nice introduction to public key authentication with SSH here, and another one here.

That is all very well when you only have a couple of machines you want to log in to, but what happens when you have dozens or more? You have to maintain your public keys on all those systems, ensuring they are kept up to date. God forbid that you loose your private key, or that it becomes compromised: you'd have to _quickly_ change all the authorized_keys files on all machines!

Enter LDAP. Eric Auge has made a patch to OpenSSH which allows the SSH server (sshd) to read the public keys from an LDAP directory. I've tested it with OpenLDAP and the patch works like a charm.

After patching the source of portable OpenSSH (I used version 4.1p1) with Eric's OpenSSH LDAP Public Key Patch corresponding to the OpenSSH version you downloaded, it is a matter of following the good instructions in README.lpk, adjusting your ./configure invocation according to the flavor of the day. After building, installing and restarting the patched OpenSSH, ensure you can still log on to your system.

Now add the LDAP options to your sshd_config file, adjusting the settings to suit your LDAP directory information tree, and restart _sshd_. Add the schema file openldap-lpk.schema to your slapd.conf and restart your directory server.

Add an object of class _ldapPublicKey_ to your LDAP user entry, ensuring that you also have a _posixAccount_ (sshd constructs the LDAP search filter by and-ing both object classes and the userid of the person logging on), and add one or more _sshPublicKey_ attribute types. My LDIF now looks like this:

dn: uid=jpm,ou=People,dc=fupps,dc=com
sn: Mens
cn: Jan-Piet Mens
gecos: JP Mens
uidNumber: 400
gidNumber: 400
uid: jpm
homeDirectory: /home/jpm
loginShell: /bin/bash
objectClass: inetOrgPerson
objectClass: person
objectClass: ldapPublicKey
objectClass: posixAccount
sshPublicKey: ssh-rsa CAr9x8...
sshPublicKey: environment="LDP_USER=jpm" ssh-rsa AAAAB...

I can now connect to all machines which have an _sshd_ appropriately set up, without needing to distribute my public keys. [In case you are wondering about the _environment_ option in the second public-key: that is for ldp, my LDAP distributed shell profile; have a look at that too!]

Isn't that insecure? Well, not if you are careful. _sshd_ will only allow you to connect if you already a a "local" user (i.e. if sshd can find your username on the local system). That doesn't necessarily mean that you have an entry in /etc/passwd; it means that whatever underlying mechanism your systems use to determine whether your username is valid to log on to the machine, they have reported that you are a valid user. These mechanisms could be any combination of PAM(Pluggable Authentication Modules), NSS(Name Server Switch), etc.

So before letting the OpenSSH LDAP Public Key Patch fly on your publicly accessible machines, do ensure you are careful during deployment.

Oh, and before you ask: if the LDAP directory server is unavailable, it will obviously not be able to return public keys. In that case, _sshd_ falls back to the other mechanisms you've configured (i.e. password) and/or public-key authentication from ~/.ssh/authorized_keys. This ensures you won't be locked out in case the directory server goes South.

Used properly, any user logging on as _root_ to a machine, can have her customized .profile loaded upon login instead of having to "share" a ~root/.profile or similar. That for me, is the end of having to put up with colleagues who prefer _emacs_ mode in a bash.

I've submitted an initial announcement and a release of my distributed .profile from LDAP idea to freshmeat.net. I've put up quite an extensive document about ldp on my wiki (the home of _ldp_); do have a look & comment on it, please.

There are still some things pending: decent _man_ pages, an import utility and perhaps profile storage in the user's real $HOME instead of in a spool directory. Anothing thing pending is my first freshmeat submission: it is still in the queue…

In any case, even though the whole thing is rather simple, I'm quite pleased with the result of _ldp_. I've been testing it from a number of different machines, and my life has changed for the better!

I'm working on a solution which entails keeping a distributed profile which will be loaded depending on the _username_ of the person logging on. I'll be keeping the profile in an LDAP directory server, although any remote location would be fine. And how will the machine know it is me? By judiciously using an environment variable set up by the SSH server.

Oh, and before you ask: yes, of course I know all about NFS(Network File System). A number of machines we use may not use NFS, though, quite apart from the fact that it'd be overkill for just that.