Linux process scheduling made easier: lance
I guess many old school admins reading this will "crucify" me for trying to say that there is another process scheduling system besides cron. While cron does its' job and does it well, other more recent systems offer new capabilities that might help the administrator one way or the other. One example is lance, a young project written in Python which offers, among others, remote task administration and web-based control. Since the project is sometimes a little rough around the edges, don't start replacing cron tasks just yet. We will tell you why, what's good, what's not-so-good and how to install and configure lance to your liking. We expect you to have some knowledge of system administration and maybe some shell scripting might be useful as well. But we will do our best to walk you through every step necessary to get lance up and running. If you still have some questions after reading this article please try our new LinuxCareer Forum.
2. Installing lance
Lance's documentation specifies python-ssl as the main dependency and python-ldap if you have a LDAP server in your organization and you intend to use it. So far, so good, but python-ssl has different names on different distributions so here's a short list of popular Linux/Unix operating systems:
# aptitude install python-openssl
# yum install pyOpenSSL
# emerge pyopenssl
Slackware doesn't have the package in its' official repositories, but there is a slackbuild named pyOpenSSL.
Arch offers this module for Python 2 and for Python 3. The difference in naming is a prefix of "python2-" for Python2 users. So, assuming you're using Python3, just do
# pacman -S pyopenssl
# zypper in python-pyOpenSSL
2.1.7. BSD systems
# cd /usr/ports/security/pyopenssl # make install clean
# cd /usr/pkgsrc/security/py-OpenSSL # make install clean
# cd /usr/ports/security/py-openssl # make install clean
Needless to say, you'll need Python installed, but chances are you already have it. Fedora and Gentoo's packaging systems rely on Python, so it's in the base system already. If it's not, it will be pulled as a dependency of python-ssl (or whatever name it has on your system). If you don't have a dependency-based package manager or none at all, make sure Python is there and installed in your path.
2.2. Getting and installing lance
We recommend you create a separate directory in your user's home, named suggestively, like "source" or "src" where you will keep your downloaded source code that's independent of your distribution. Download lance-1.3.tgz (the last release as of this writing) in that directory, then, to unpack it, simply type
$ cd ~/source && tar xzvf tar-1.3.tgz
This will create a directory named 'lance-1.3'. Go there and let's start by...of course, the doc/README file. We recommend you oscillate between this file and the "Documentation" section of the website (not the one on Sourceforge, the one listed there as 'Project Home"). As it often happens with new, undermanned projects, there are a few discrepancies between the two sources, but I managed to get by with the website, as the info there seemed more recent. Since the document, regardless of source, is a bit sparse and in some places it has missing parts, we want to spare you of our experiences having to try things out 'till they work and lead you step by step. The developer is obviously a Fedora user since there is a rpm package for download for 64-bit PCs. If you run Fedora, use it. What is next in this section is for the rest of us.
In the main directory you will find a file named lance.conf. Copy it to /etc to use later as a model.
# cp ~/source/lance-1.3/lance.conf /etc
This is the main configuration file for lance, but we will get to use it a bit later. Now we have to create the /etc/lance.d directory where all the .conf files, local or remote, will reside, plus the SSL key and certificate.
# mkdir /etc/lance.d
# mkdir /etc/lance.d/remote
The next step, if we believe the documentation, is to create the *.conf files, but we don't know what they are yet, so we'll get to that later. Afterwards we're told to copy lance.py and lc.py somewhere in $PATH. Since the init.d script assumes that "somewhere" equals /usr/sbin, let's comply:
# cp ~/source/lance-1.3/lance.py /usr/sbin # cp ~/source/lance-1.3/lc.py /usr/sbin
lc.py probably stands for "lance control" because it's used to start, pause, stop or view the status of lance.
Now let's prepare our lance_manager.conf file (lance_manager takes care of incoming connections, this will become clear when editing its' config file).
# cp ~source/lance-1.3/lance_manager.conf /etc
# cp ~source/lance-1.3/lance_manager.py /usr/sbin
2.3. Configuring lance
Now that all our files are in place, let's start with configuring lance. Before we start, we will assume you have a web server installed, configured and running. Lance offers you a startup script to copy in /etc/init.d, but we won't cover it because it's Fedora/Redhat specific, as it depends on /etc/init.d/functions. Besides that, testing it on Fedora 16 failed miserably. It's obvious that it's a script copied from another package (stunnel, to be exact) and that it hasn't received a lot of attention. It may have to do with Fedora's recent change to systemd, but we were unable to test as it's the only Fedora machine we have.
'/etc/init.d/lance stop' reports success but fails to actually kill the process, so we had to do that by hand. What you will also have to do by hand is create /var/run/lance where the pidfile of the executable is kept. Fedora, probably from security reasons, deletes this directory between reboots, so be careful. We'll get to the matter of how to start lance later.
Let's start our configuration with editing /etc/lance.conf. The syntax is pretty simple and the file is well-commented, so it shouldn't be too hard to tailor it to your needs, although not much manual configuration is necessary in a simple scenario. Since this file holds the key to the TCP server, we recommend you use proper permissions. We used the same key here and when creating the .key and .crt files needed for connection encryption (the next two sections in the file), but this was only for ease of remembering. If you use lance in a corporate environment, obey the local policy to make sure no security incidents will occur. The log levels are similar to other server applications in that they set when you should be alerted if something goes wrong. "When" means "how bad does it have to be for lance to write messages to syslog". Below this we felt no need to change something except manager_host. If the lance server runs on the machine named armstrong (as known by DNS or local /etc/hosts files), then use
on the client machines. Else leave it as it is (localhost) or comment it. All good, but we need our key and cert files. The following commands will do that, assuming the name myhost for both files (remember to change that in lance.conf):
# cd /etc/lance.d # openssl genrsa -des3 -out myhost.key 1024 Generating RSA private key, 1024 bit long modulus .......................................++++++ ...................................................++++++ e is 65537 (0x10001) Enter pass phrase for myhost.key: Verifying - Enter pass phrase for myhost.key: # openssl req -new -key myhost.key -out myhost.csr # openssl x509 -req -days 365 -in myhost.csr -signkey myhost.key -out myhost.crt
This should be it for lance.conf. Let's go to lance_manager.conf, which, as you remember, was to be put in /etc. Its' syntax is more straightforward than the one of lance.conf, and it's better commented. We only changed the key to match the one in lance.conf, changed the names of the key and the certificate to match reality, commented the LDAP options since we don't use it and changed the DNS info. In the server section change the values accordingly if you're a lance client or leave localhost if you're the server.
2.4. Running lance
Now we're ready to run lance and its' manager:
# lance.py -s
If everything went well, you should see the message "lance: Server started". But we have nothing configured to be started by lance yet. Here the /etc/lance.d/*.conf files come into play. These are files for every program you want to start via lance, so if you want to start, say, mutt, you will create a file named mutt.conf. The remote .conf files will go to /etc/lance.d/remote and the local ones one directory up. We will show you our test .conf file that, not quite usefully, starts lxterminal every two minutes. We callled it lxterminal.conf and we recommend you to choose proper names for your files.
#This is a comment
#That's 20:12 and you can add seconds too in the same manner
#That's 120 seconds interval, equaling two minutes :-)
Pretty simple, huh? You can also use lance.py -r to check the validity of the lance.conf file (errors, typos). But we haven't shown you yet the greatest trick.In a browser's address bar, type 'localhost:1977'. Before that, make sure that the firewall doesn't stand in your way and enjoy. You can now monitor scheduling from your web browser, not only for the local machine, but also for remote hosts. Awesome, isn't it?
Regarding lance's broken init script, if you don't have the patience, time or know-how to fix it or write another, we recommend using the easier route. Debian will be our example here, but every distribution (and the BSDs) offer you a way to start local software at boot. In Debian, the file responsible is /etc/rc.local and is executed at the end of each multi-user runlevel. OpenBSD offers /etc/rc.conf.local, Arch offers also a /etc/rc.local, and these are only few examples. You will want, on Fedora at least, to add a 'mkdir /var/run/lance' in your lance startup script.
It is our hope that you will find lance useful (as we did) and if you know some Python programming, we invite you to hack at it, make it better for you and others and share what you changed.