The Deep End | Paul Venezia » August 2006

August 31, 2006 | Comments: (0)

Fun with OpenVZ

TAGS: ./configure && make && make install, Systems

I've been messing around with OpenVZ for the past few weeks and having a blast. I really liked Virtuozzo, its' commercial sibling, and I find that OpenVZ lacks only the management tools available in Virtuozzo. Since I was going to be building quite a few VPSes on the host servers, I wrote some very simple shell scripts to automate the process, from the actual VPS creation to custom package installation, NIS and NFS mount configuration, and so forth. Also, I found that I wanted to be able to run several commands across all VPSes simultaneously, or in series, so there's a script that handles that.

I also decided that although the /etc/sysconfig/vz-scripts/$VPSID.mount and umount scripts are handy, in my case they would all be the same, so there's a global script for those that is run from a symlink. These were written for one specific purpose, but I imagine that there are others that could use these tools as a starting point at least, so have at it. You can download the tools here: ovztools-0.0.1.tgz

ovztools-0.0.1

This is a selection of simple bash-based OpenVZ tools, written to streamline VPS builds and configuration. They're written in bash for portability. They have been tested on Red Hat-based distributions such as Fedora and CentOS. Modifications will need to be made for other distributions.

INSTALL

Simply place all of the scripts in a directory in your path, such as /usr/local/sbin. Then move the global.* scripts to /etc/sysconfig/vz-scripts. You will need to modify variables in most of them to reflect your environment, and probably make significant modifications to vzsetup.sh.

TOOLS

mkvz -
This script condenses the creation of a VPS into a few prompts for hostname, IP address and VPSID, then builds the VPS to spec, adding packages specified in the $packages variable as well as performing post-install work via the vzsetup.sh script, such as modifying files to provide for NIS authentication and configuring various NFS mounts.

vzsetup.sh -
This is called from mkvz to perform various tasks within the new VPS, such as NIS setup and whatever else is needed.

vzdo -
This script is used to run global commands across multiple VPSes, such as installing new packages to all VPSes via vzyum.

global.mount, global.umount -
These scripts control all bind mounts to the VPSes when they're started and stopped. Rather than using a single script for each, these scripts are called via symbolic links in the /etc/sysconfig/vz-scripts directory, such as 101.mount -> global.mount. The script parses out the VPS id from $0 and performs the requisite mount --bind operations. Originally written as a single script, I broke it into two for simplicity.

vzdomount -
This script can be called manually to mount --bind and directories within a VPS

As always, YMMV.

Posted by Paul Venezia on August 31, 2006 07:47 PM

August 15, 2006 | Comments: (0)

Sound MPLS route redistribution

TAGS: Networks

I usually file things like this under "duh", but a recent conversation with a network architect made me think that it's worth noting in public space.

I recently had a problem related to dynamic route distribution in an MPLS environment. Several remote sites were served via a Paetec MPLS network, all sites falling under a common major net, 192.168.0.0/16, with DMZ and edge networks built on another major private net. In a frame-relay or PTP network, routing would easily be handled by EIGRP or OSPF, or even static routes, and moving subnets from one site to another would be as simple as referencing them in the routing table of a core switch or router at the target site. In an MPLS environment, however, the routers connecting the LAN to the MPLS network are controlled by the provider, and the nature of MPLS dictates that these routers have explicit routes that are propagated among the participating MPLS routers via BGP.

The problem was that in order to be able to move subnets around between sites, for instance in order to accommodate the failure of an inbound Internet circuit at one site by moving VPN subnets to another site, the provider would need to be in on the configuration, and that can hardly be considered a workable proposition in an emergency. So, I built an OSPF area at each site that was redistributing connected and static subnets, and had the MPLS provider configure their router to participate in that area, and redistribute routes learned via OSPF into BGP. With this in place, adding a route statement to any router at any site causes that route to be propagated throughout the MPLS network, and then into the OSPF area at each site, including defroute information. Turning the routing around now is absurdly simple and doesn't require the involvement of the provider at any level. Prior to this, all routes were static, with subnet of the major net assigned to each site, such as 192.168.0.0/20, 192.168.64.0/20 and so on. Now, it's as granular as necessary.

If you're going to undertake this configuration, be sure that you properly assign loopback interfaces on the core routers and switches with the highest IP in the subnet assigned to that site to ensure that it becomes the DR/BDR interface and the status of any physical interface doesn't interfere with proper OSPF operation.

Posted by Paul Venezia on August 15, 2006 06:14 PM

August 14, 2006 | Comments: (0)

Security (finger)tip

TAGS: Gear, Systems

I've been using an MXI Security Outbacker MXP for a few months now, and although I generally eschew portable storage devices (usually since I have a nasty habit of losing the power cords, if not the actual device itself), I like this one.

At it's essence, it's a 1.8" 20GB drive with a fingerprint scanner built into the case. When it's powered up or connected to a USB host device, an LED blinks on the case, and either the drive is not visible to the host system, or only a public partition is available, depending on the configuration. Once a valid fingerprint is detected, however, the secure partition is made available to the OS.

This split personality is a nice feature, since you can store non-sensitive info on one partition and use the other for private data. The only problem I faced is that the device requires a Windows system to configure the partition settings and enroll fingers for access to the private partition. Once the configuration is done and one or more fingers have been enrolled, you can access and format any partition as you wish, with ext3, NTFS, UFS, or what have you. The security aspect blocks access to the secure partitions, but doesn't affect otherwise normal operation.

Another nice feature is that the control software for configuring the device is housed in a small read-only partition on the disk itself. If you lose the accompanying CD, or simply don't have it handy, you can still hook the drive up to a Windows system and run the configuration tool, assuming you have your fingers handy. Additionally, the device can be powered exclusively from the USB port on most laptops.

So all in all, it's a good solution for carrying around sensitive information, especially if your laptop doesn't offer biometric security. And I'm happy to say that I have yet to lose it.

Posted by Paul Venezia on August 14, 2006 02:19 PM

August 05, 2006 | Comments: (0)

Relaydelay patch

TAGS: ./configure && make && make install, Systems

After I don't know how many years using and coding on Evan Harris's relaydelay Sendmail milter, I just recently found and fixed a small bug in the recipient whitelisting code on version 0.04. Prior to this fix, recipient whitelisting wouldn't work if the database entry for the address wasn't enclosed in <> brackets. This was due to the way that the rcpt_to variable was handled prior to the database call. The patch below yanks those out of the string if they exist, rendering normal addresses viable for recipient whitelisting.

Note that this patch was made against a heavily modified milter, so it might fail on the stock version. Just add the regex in the patch in the right place in your version.

--- relaydelay.rcpt_to.pl       Sat Aug  5 12:27:25 2006

+++ relaydelay.pl       Thu Aug  3 10:18:41 2006

@@ -743,6 +743,7 @@

   # See if this recipient (or domain/subdomain) is wildcard white/blacklisted

   #   Do the check in such a way that more exact matches are returned first

   if ($check_wildcard_rcpt_to) {

+    $rcpt_to =~ s/(?:<|>)//g;

     my $subquery = "rcpt_to = " . $dbh->quote($rcpt_to);

     my $tstr = $rcpt_domain;

     while(index($tstr, ".") > 0) {

Posted by Paul Venezia on August 5, 2006 03:34 PM