Now that I want to write a site-specific GUI-based LDAP management tool as referenced in a previous post, I’m jumping back into software development a little bit. I’ve decided to use wxPython for a few reasons. We already use it within our group, we have in-house expertise in the form of an actual developer and the GUI-builder tools seem to work best with wxPython (wxGlade was producing bad wxPerl code, go figure).

Let me also say that I’ve never been a big python guy. I’m really a perl kind of dude, so this learning a new object oriented API while learning python at the same time is a challenge… but I’m making progress! Basically, wxPython seriously kicked my ass for about 3 days but now I’m gaining speed and things are moving faster than I expected. Python and wxPython are starting to make more sense and behave.

So far I have a frame with menubar, statusbar and a three-tabbed notebook with a grid on each tab of the notebook. The program is able to connect to an LDAP server (with TLS) and query the directory for all the users, groups and autofs information and then display that information in the grid… and that’s about it so far. I need to build in new user, group and autofs functionality as well as basic editing of existing entries (in place editing with wx.Grid looks really nice but I haven’t tried it yet!).

Although my ass has been kicked for the last few days, I’m actually feeling pretty optimistic about it now.

Hopefully I can share the kludge code at some point, though it will never be easily transportable to different environments since I’m not building this to be the end-all-be-all LDAP user/group/autofs management tool, just one tailored for our environment.

No related posts.

As part of my learning experience with cfengine, I’ve decided to start posting some of the code that I’ve begun developing in the hopes that by writing about it, I can learn better, faster and maybe even receive some helpful comments from readers along the way. Beware, I’m a cfengine newbie and so what I post here should NOT be copy and pasted into your environment unless you’re ok with the potential of wildly breaking things!

The first snippet of code I want to discuss is related to managing our DenyHosts configuration. As part of our “security policy”, I would like to ensure that every RedHat/CentOS system is running a properly configured DenyHosts instance. Here is what I’ve come up with so far.

################################################################################
#
# FILE: denyhosts.cf
# DESC: Install, update, configure and ensure DenyHosts is running
# DATE: May 2010
#
#################################################################################

bundle agent denyhosts
{

packages:

  "denyhosts" -> "Security policy"
    comment               => "Ensure denyhosts is installed once a week",
    package_policy        => "add",
    package_method        => yum,
    package_architectures => { "noarch" },
    action                => if_elapsed("10080");

  Night::

  "denyhosts" -> "Security policy"
    comment               => "Check for update to denyhosts every 24 hours (and only at night)",
    package_policy        => "update",
    package_method        => yum,
    package_architectures => { "noarch" },
    action                => if_elapsed("1440");

files:

  "/etc/denyhosts.conf" -> "Security policy"
    comment   => "Standard base DenyHosts configuration",
    copy_from => mycopy("$(g.confdir)/denyhosts/denyhosts.conf", "$(g.cfserver)"),
    classes   => cdefine("denyhosts_restart", "denyhosts_conf_copy_failed"),
    perms     => mo("400", "root"),
    action    => if_elapsed("1440");

processes:

  "python /usr/bin/denyhosts.py" -> "Security policy"
    comment       => "Define denyhosts_restart class if denyhost is NOT running",
    restart_class => canonify("denyhosts_restart");

commands:

  "/sbin/service denyhosts restart" -> "Security policy"
     comment    => "Restarting DenyHosts after configuration change or death",
     ifvarclass => canonify("denyhosts_restart");

}

If you’re familiar with cfengine at all, you’ll quickly realize this is not a complete configuration. I am relying on the cfengine standard library for several body definitions as well as custom site variables defined in the common bundle named “g” (not shown). And of course, there are no control bodies, bundlesequence or many other things that make up a complete cfengine configuration, hence “snippet”.

Let’s ignore what’s lacking for now and focus on the meat of the promises.

Packages

The first part of the denyhosts bundle is dealing with packages. I’m making two promises regarding the “denyhosts” package. The first promise is that the package has been added to the system via yum and the second is that the package is up to date via yum. I’m not entirely clear on how to best manage promises like this yet so perhaps I’m missing some cute shorthand for both adding and keeping packages up to date. For now, I’ll stick with two separate promises.

You’ll also notice that I’m only checking to see if the package is installed once a week (via action => if_elapsed) and only checking to see if the package is up to date once every 24 hours (if_elapsed, again). The update promise is also subject to the Night class to ensure that package updates only occur at night and not during the work day. This is just a matter of preference. I’d prefer if updates occur at night, you may not.

Since I’m using a “smart” package manager to ensure that denyhosts is installed, I can count on having yum resolve any dependencies (such as python) for me automatically. I would loath to describe every dependency for every package I want control over by hand.

Files

There is only one file that I’m concerned with when it comes to denyhosts and that is the denyhosts configuration file in /etc/denyhosts.conf. Instead of doing file edits on the default denyhosts.conf file provided in the denyhosts packages that I’ve promised to install, I simply copy a pre-defined configuration from my cfengine server. This file has our site’s default denyhosts configuration all ready to go. If I needed to customize the configuration on a per-host or per-host-type basis, I could copy the base file to a temporary location then perform edits on the temp file and write out the changes to the final location of the default configuration file or simply maintain several pre-configured versions of denyhosts.conf and copy the appropriate file.

Also of note about files is that if the file promise must be repaired (if the file must be copied because it’s changed), I’m setting a class to be defined so that DenyHosts can be restarted. More on that later.

Processes

In this case, I’m only checking to see if the DenyHosts python process is running or not. If DenyHosts is running, we do nothing. If DenyHosts is not running, we define a class using the same name as the class we define if we have to copy the configuration file.

Commands

Finally, in the commands section we tell cfengine how and when to restart DenyHosts. If the “denyhosts_restart” class is defined, we instruct cfengine to restart DenyHosts with the “/sbin/service denyhosts restart” command. The canonify and cdefine special functions in cfengine provide a very powerful way of defining some rather complex relationships.

What is Missing?

Well, probably a lot of stuff. One obvious thing is that I’m not promising that DenyHosts is set to startup at boot time using the hosts’ native init system. Of course, this shouldn’t be a big deal because cfengine will start it up if it’s not running at the next cf-agent run, but perhaps it would be nice to make that promise anyways.

I’m also not using many (or any!) classes to limit the scope of where (to what hosts) these promises will apply. Right now, I’m just working with a test environment so it’s easy to get away with that but I’m learning that it’s good to be as explicit at possible from the start when building promises.

UPDATE: Ah, how could I forget.. Reporting is totally missing! I knew I was setting some of those classes for a reason. In the next installment, I’ll include the most basic of reporting functionality.

I think that’s all for now. Please critique my amateur use of cfengine 3 in the comments, I want to hear from you!

Related posts:

1. Cfengine 3 Snippets Part 2: sudo
2. RHEL/CentOS, NFS and Firewalls
3. Nanorcs: Ultrasimplistic Configuration File Revision Control

Luckily, RedHat’s /etc/sysconfig/nfs configuration file read by  various “nfs”, “nfslock” and RPC services init scripts provides an easy means of locking down specific ports for all the NFS-related services so that one doesn’t have to work around the dynamic port assignment problem when it comes to firewalling.

In /etc/sysconfig/nfs there are six different options relating to port assignment:

1. RQUOTAD_PORT
2. LOCKD_TCPPORT
3. LOCKD_UDPPORT
4. MOUNTD_PORT
5. STATD_PORT
6. STATD_OUTGOING_PORT

These options do not represent all the ports that will be used by the entire NFS service but it includes the most important option for eliminating the uncertainty of rpc.mountd.

I’ve set the port options as follows:

1. RQUOTAD_PORT=875
2. LOCKD_TCPPORT=4045
3. LOCKD_UDPPORT=4045
4. MOUNTD_PORT=861
5. STATD_PORT=865
6. STATD_OUTGOING_PORT=866

After making the changes, restart the “nfs” and “nfslock” services and check to make sure the configured ports are now in fact in use with the “rpcinfo -p” command:

# rpcinfo -p
program vers proto   port  service
100000    4   tcp    111  portmapper
100000    3   tcp    111  portmapper
100000    2   tcp    111  portmapper
100000    4   udp    111  portmapper
100000    3   udp    111  portmapper
100000    2   udp    111  portmapper
100011    1   udp    875  rquotad
100011    2   udp    875  rquotad
100011    1   tcp    875  rquotad
100011    2   tcp    875  rquotad
100021    1   udp   4045  nlockmgr
100021    3   udp   4045  nlockmgr
100021    4   udp   4045  nlockmgr
100021    1   tcp   4045  nlockmgr
100021    3   tcp   4045  nlockmgr
100021    4   tcp   4045  nlockmgr
100003    2   tcp   2049  nfs
100003    3   tcp   2049  nfs
100003    4   tcp   2049  nfs
100003    2   udp   2049  nfs
100003    3   udp   2049  nfs
100003    4   udp   2049  nfs
100005    1   udp    861  mountd
100005    1   tcp    861  mountd
100005    2   udp    861  mountd
100005    2   tcp    861  mountd
100005    3   udp    861  mountd
100005    3   tcp    861  mountd
100024    1   udp    865  status
100024    1   tcp    865  status

Now, the entire NFS-related firewall rules must allow the following ports from the applicable client address range(s):

• Incoming and Outgoing ICMP type 3
• Incoming TCP and UDP ports 111, 861, 865, 875, 2049, 4045
• Outgoing TCP and UDP ports 111, 861, 865, 866, 875, 2049, 4045

These rules can easily be configured with your favorite firewalling software (I’m using fwbuilder to manage iptables rules). Often times firewalls will be configured to allow all outgoing connections, so if that’s the case with your firewalls, don’t worry about specific outgoing rules. I’ve been testing this configuration for two days now and all seems well.

Related posts:

1. Browsing Automounted NFS with Nautilus
2. Cfengine 3 Snippets Part 1: DenyHosts
3. OpenGear CM4116 Review

Most of the problem is solved through age-old UNIX techniques. For group ownership, all we need to do is setup the top-level directory to be owned by the “project” or “group share” group and setgid the directory:

$ mkdir project1
$ chown .projgroup project1
$ chmod g+s project1

This effectively forces every file created, moved or copied into the “project1″ directory to be owned by group “projgroup”. So far, so good. The difficulties begin when we attempt to use default ACLs to enforce the permissions of any files created, moved or copied into the directory.

The POSIX ACL standard defines “default” ACLs which can be applied to a directory, which are in turn inherited by newly created/copied/moved child files and directories. While the default ACLs are inherited properly, the ACL mask when applied to files copied into the group share directory WITHOUT previous group write set prevents the files from being group writable!

$ getfacl project1
# file: project1
# owner: root
# group: projgroup
user::rwx
group::rwx
other::r--
default:user::rw-
default:group::rw-
default:group:projgroup:rw-
default:mask::rwx
default:other::r--

So far so good, right?

$ ls -alh test
-rw-r--r--  1 user1 user 0 Apr 23 15:10 test
$ cp test project1
$ ls -alh project1/test
-rw-r--r--+ 1 user1 projgroup 0 Apr 23 15:10 project1/test

What the… ?!?! No group write? Noooooo!

$ getfacl project1
# file: project1/test
# owner: user1
# group: projgroup
user::rw-
group::rw-			#effective:r--
group:projgroup:rw-		#effective:r--
mask::r--
other::r--

And so we have the great POSIX ACL mask problem, which is by design in fact. Still looking for a complete solution that doesn’t involve global trying to force a specific umask on every account… It would be nice if I could ensure that every file had group write set before it was copied into the group share directory but alas, I cannot. Telling users to manually check and change permissions is also a pain. Cron jobs to change group write recursively is also ugly. Please, someone provide me with the solution.

Related posts:

1. Cfengine 3 Snippets Part 1: DenyHosts
2. FreeIPA and Samba 3 Integration
3. When using Syncrepl…

I’d like to present this script and then psuedo-challenge other visitors of this site to write a more efficient algorithm in the language of their choice. Unfortunately, any way (that I know of) for measuring the efficiency of two or more algorithms across different languages is going to be skewed due to differences in efficiency of compilers, interpreters and what not.

The script converts a file in the format:

1 2 3 4 5 6 7 8 9 10
11 12 13 14 15 16 17 19 19 20

to:

1 11
2 12
3 13
4 14
5 15
6 16
7 17
8 18
9 19
10 20

I should add that the program must be able to handle unequal number of items in each line, too.

#!/usr/bin/perl
#
# l2c.pl - lines to columns
#
# http://techslaves.org/

# variables
my @lines;
my @columns;
my $iter = 0;
my $linesize = 0;

# if num of command line arguments is 2
if (($#ARGV + 1) == 2) {

  # open input file for reading
  open(INFILE, $ARGV[0]);

  # read input file into an array of arrays
  # an array of "lines" and each "line" is an array of it's "elements" (based on space or tab)
  while()  { push @lines, [ split(/\s+/, $_) ]; }

  # close input file
  close(INFILE);

  # find the longest line (so we know how many times to loop below)
  foreach $line (@lines) {
    if(@$line > $linesize) { $linesize = @$line; }
  }

  # open output file
  open(OUTFILE, ">$ARGV[1]");  

  # $iter = line element counter
  # loop while the line element counter is less than the longest line
  while ($iter < $linesize) {
    # loop through every line in the array of lines
    foreach $line (@lines) {
      # if a line element at position $iter exists...
      if( @$line->[$iter] ) {
        # print the line element + a tab to the output file
        print OUTFILE @$line->[$iter], "\t";
      }
      # advance the line element counter
    } $iter++; print OUTFILE "\n";
  }

  # close output file
  close(OUTFILE);

# if num of command line arguments is NOT 2 print usage
} else { print("usage: $0 inputfile outputfile\n"); }

No related posts.

What is nanorcs? It’s a very simple bash script wrapper around the nano, the cute GNU version of pico and RCS, a basic but functional revision control software package. The script is used in place of a call to ‘nano’ when editing a file and it automates the tasks related to change management of configuration files including tasks such as check in/out, and prompting the user when a discrepancy between the current file version and the RCS version exist.

Basic Prerequisites

While few prerequisites exist for nanorcs, most of them should be quite simple to satisfy on any Linux system:

Nanorcs also makes some assumptions regarding the path to certain executables: it assumes the required executables are in your path!. I know I could have made it “cleaner” by providing a variable in which to set the paths, but this script was 99% written for me, on my systems… where the RCS and nano commands are in my path… and besides, if you’re reading this you can probably figure out how to edit it to suit you anyways! This is just an example of how this might be done, not necessarily a working solution for your systems.

Functionality

Using nanorcs

Using nanorcs is easy, but you always have to remember the key point that it must be invoked against a file that is in your current working directory! The basic calling convention is (assing the script is in your path!):

root@box:/etc/ssh
# nanorcs sshd_config

The Script

And finally, the script itself:

#!/bin/bash
#
# Name: 	nanorcs
# Desc: 	RCS wrapper around nano for editing config files
#

# Check if file exists in RCS
#
if [ ! -e $1,v ]; then
  echo "First time editing, checking file into RCS..."
  ci -l $1,v $1
else
  # Check if RCS version is different from local version
  rcsdiff $1,v $1 &> /dev/null
  if [ "$?" -eq 1 ]; then
    echo -n "File $1 is not the same as RCS version, clobber it (y/n)? "
    read clobber
    if [ "$clobber" = "y" ]; then
      co -l $1,v $1
    else
      echo -n "Commit current version to RCS (y/n)? "
      read commitfirst
      if [ "$commitfirst" = "y" ]; then
        rcs -l $1,v
        ci -l $1,v $1
      else
        echo "Nothing left to do, exiting..."
        exit
      fi
    fi
  else
    co -l $1,v $1
  fi
fi

nano $1

echo -n "Commit changes to RCS (y/n)? "
read commitfinal
if [ "$commitfinal" = "y" ]; then
  echo "Committing changes..."
  ci -u $1,v $1
else
  rcsdiff $1,v $1 &> /dev/null
  if [ "$?" ]; then
    echo -n "Do you want to revert to RCS version of $1 (y/n)? "
    read revert
    if [ "$revert" = "y" ]; then
      echo "Reverting to RCS version..."
      co -u $1,v $1
    else
      echo "Changes made have NOT been committed!"
    fi
  else
    echo "File unchanged from RCS version, BYE!"
  fi
fi

#
# END
#

That is all. Nanorcs is my ultra-simplistic solution to the minor hassle of managing configuration file revision. For more advanced users and admins, things like cfengine and pikt are certainly light years ahead of this in every way imaginable, but for those of you who don’t necessarily need or want a configuration engine, this type of solution seems to be suitable enough.

Related posts:

1. Time Navigator HA Cluster Agent Configuration
2. l2c.pl – Lines to Columns