Category: General

Categories
General NSP WLUG

Xensource Xen Enterprise

I’ve been following the Xensource Xen Enterprise product for a couple of months at work. The current release ships with an install CD which preps a barebones server. It installs linux with a Xen kernel and the Xen toolset, but doesn’t ask you many questions – the dom0 is really only there to support the hypervisor after all. There are no options for software raid in the installer, but that might be because software raid isn’t considered an “enterprise” tool by some people.

Once it’s installed, you can run a JAVA based console from your desktop. This will connect to the XenEnterprise server and let you run some of the hypervisor commands as well as provision and configure domU.  XE ships with support for installing a debian server from a template, and for installing RHEL from a network install server. Apparently  it’s fairly straight forward to modify the templates or to create your own, I haven’t looked into that yet.

The console provides some monitoring of the dom0 and the domUs – network, cpu, disk and memory utilisation. The
console will connect to multiple XE hosts, letting you monitor and configure your domUs across your entire network.

One other neat tool that ships with XE is a P2V migration tool. That’s Physical to Virtual migration – you run a program on your existing physical machine, and XE will create a domU suitable for it and migrate the filesystem into the new host. However, I’ve yet to use this to see how well it works.
The kicker is, of course, the pricing. XE’s pricing is available online, and it starts at $750 + $150 annual maintainance for a 2 cpu server. The big benefits of XE come in when you have multiple servers in use, so start to scale that price up accordingly.   XE is also a bit limited in that you can’t do anything outside of the box yet. Which means that if you want, for example, pass a PCI device (eg, network card or SCSI controller) through to a specific domU, you are out of luck. This may not happen very often or at all, but it does make it somewhat less useful.

Overall, it’s a nice enough tool. If you are looking at managing a large number of densely packed Xen servers and want to be able to quickly provision new servers, clone existing servers, and migrate guests easily between hosts, it’s probably spot on.

Categories
General WLUG

Trouble playing movies with Totem?

I’ve never really liked totem. It’s set up as the default movie player, but I always had problems getting it to play movies – some would play fine, others wouldn’t. It always worked for quicktime movies however.

Today, Craig asked about playing quicktime under Totem. This suprised me, because it was the one thing I had working well. We both run Ubuntu Dapper.

After closer inspection, it seems we had different gstreamer plugins installed. There’s quite a few of these packages in Ubuntu, so missing one or another is probably quite easy.

  • gstreamer0.10-plugins-base – GStreamer plugins from the “base” set
  • gstreamer0.10-plugins-good – GStreamer plugins from the “good” set
  • gstreamer0.10-plugins-bad – GStreamer plugins from the “bad” set
  • gstreamer0.10-plugins-ugly – GStreamer plugins from the “ugly” set
  • gstreamer0.10-plugins-ugly-multiverse – GStreamer plugins from the “ugly” set (Multiverse Variant)
  • gstreamer0.10-plugins-bad-multiverse – GStreamer plugins from the “bad” set (Multiverse Variant)

These are described better at  http://gstreamer.freedesktop.org/modules/.

So now I have gstreamer0.10-plugins-bad-multiverse installed which includes the xvid codec. All good!

Categories
General Tool of the Week

DenyHosts

If you have computer on a public-facing IP address, and it runs an SSH server on port 22, chances are pretty good you’ll be subjected to a number of dictionary attacks. Compromised hosts will try to login with a list of common user names and passwords.

Now, this isn’t a problem for most of us, right? We have secure passwords after all, and these attacks are just trying dictionary lists of words – username root, password of ‘password’ or ‘root’, for example. However, they are still annoying – if only because they fill up the logfiles. Also, it’d be better to just not have the connections, just in case they manage to get through.
I recently came across a tool called denyhosts. Denyhosts monitors your ssh log file and modifies /etc/hosts.deny to disallow SSH (or all access to tcpwrapped services) from hosts that have a significant number of failed login attempts. It also has a synchronised mode in which hosts running denyhosts on the internet share their list of denied IP addresses.

I set it up a week or so ago and get an email every couple of hours with a new IP address that has been blacklisted. I also managed to blacklist one of my own IP addresses while testing, which proved hard to remove – denyhosts kept adding the block back in. Fortunately I set it to purge entries after 3 days, so I can now ssh in again :)

Categories
General Tool of the Week

SSH + LDAP Public Key (LPK)

SSH public key management can be a real pain. Adding or removing a user to your system, and distributing the account details and ssh keys is time consuming. Revoking keys is the bigger issue. Has a user added an ssh public key to the root account? To other people’s accounts?

Enter SSH LPK.

The LDAP Public Key patch for ssh allows you to set up a Public Key Infrastructure (PKI) using LDAP. It consists of an ldap schema and a diff against openssh, which inserts an LDAP lookup for the public key into the authentication path. Combine this with libnss-ldap and pam_mkhomedir, and provisioning a new user on your network is as easy as creating an entry in LDAP and inserting their public key.

The patch also allows group checks. It will check for standard posix group membership in LDAP, and if the user is in the group specified, they are allowed in. There doesn’t seem to be any way to nest groups, but this could be fixed eventually by making it a query rather than an attribute to test.
In terms of security, this is fine. We’re exporting SSH public keys via LDAP, but that’s the whole point of a public key. Perhaps more concerning is exporting UIDs and other account information via LDAP. This could be tied down by creating a CA for infrastructure and requiring that connecting clients have a certificate signed by the CA.
One can enforce LPK public keys only by setting AuthorizedKeysFile to /dev/null. This prevents users from inserting their own ssh public key onto the filesystem and bypassing any revocations you might issue. It also means if the LDAP tree is unavailable, you will fall back to password auth. If you really want to be able to completely revoke a user’s permission to log in, it’s best to disable password authentication as well. Couple this with some pam configuration to only allow admin or root accounts, and perhaps OTP or S/KEY authentication to eliminate root password leakage, and this becomes a fairly tight system.

Resources: