February 22
This Monday, Kyle, Mike, and I have had a phone interview with Alan Cox. He asked us a few questions about deploying Linux on desktops. We tried to be as informative as possible, but sometimes his Welsh accent was a bit hard to understand. It felt awesome to talk to someone as great as Alan Cox.
I have subscribed to the the LVM mailing list. Here are my comments:
I have written a bash script that allows for preservation of settings in *.desktop files over software updates. In case if you do not know, these files are displayed as applications in Gnome desktop menu. By default, they have not very descriptive titles. We change them to something simple, e.g., "Firefox" becomes "Browser" and "gFTP" becomes "FTP Client". However, an update of the application may change the menu entry's name. We used to have a lot of trouble renaming those titles. The task of fix-gnome-icons.sh is to free us of this work. Here is the comment from inside of the script that describes how to configure it:
# # If you want to make a permanent change to _some_ lines in a # *.desktop file: # 1) Copy *.desktop file into *.desktop.cosi # 2) Delete all the lines you do not need (including "[Desktop # Entry]") from the *.desktop.cosi file. # 3) Customize the remaining lines in the *.desktop.cosi file. # 4) Run this script. #
Following Kyle's advice, I have created a local user for remote querying of workstations. The user's name is "remote-query". He is used to look up information that does not require a root access to a system. I broke apart the file remote.sh into remote-look.sh and remote-touch.sh. Extensive work have been performed on remote-look.sh in order to make it accept arguments in the style we have grown accustomed to. Here is the usage information of remote-look.sh:
solomarv@animal solomarv $ remote-look.sh
Usage: remote-look.sh [-h] [-a action] [-l lab] [-c command] [-n number]
Options:
-h - Show this message.
-a - Perform an action.
-l - Run in the specified lab. If the lab name is
omitted, the action is applied to the first lab
listed in config.
-c - Command to run if the action is "run". Use
quotes when a command contains spaces.
-n - Number of the workstation to perform the action on.
If number is omitted, the action is performed on
the whole lab.
Actions:
up - Check if network is up.
ssh - Check if ssh is running.
users - Get number of users.
stats - Show the summary of above three queries.
run - Run the command specified by "-c".
login - Remotely login into a workstation. Requires a
workstation number.
This is "look-only" program.
The configuration file /etc/cosi-remote/config must be edited before using remote-look.sh. Here is the contents of mine:
# # /etc/cosi-remote/config # This is the configuration file for the COSI lab management and # monitoring tool. # # # Host names are constructed of lab-name, delimiter, and number. For # example, if the lab name is "cs", delimiter is "-", and the number # is 45, the host name is assumed to be "cs-45". # # The list of labs. Your host names should begin with one of this. LABS=(cosi itl) # Number of machines in each lab. A number that is bigger than real # could be specified, but it will cause an excessive load on your dns # server. Your host names should end with a number less than the # number corresponding to its lab. NUMBER_COSI=10 NUMBER_ITL=28 # The number from which the numbering starts. NUMBERING_START=1 # The separator between a lab name and a number of the workstation in # your host names. DELIMITER="-lab-" # Your lab's domain name. It is assumed that all labs have the same # one. DOMAIN="sclab.clarkson.edu" # The user name you use to query data (not super user). # You have to generate a public SSH key and put it into this user's # $HOME/.ssh/authorized_keys2 file (unless you want to type your # password every time). LOOK_USER="remote-query"From what I have gathered, remote-look.sh parses this file correctly. Perhaps the most difficult task in parsing the config is picking $NUMBER_LABNAME variable to use. First, the script extracts the name of the lab from $LABS array. Next, it changes it into capital letters using
LAB_IN_CAPS=`echo $LAB | tr a-z A-Z`At last, the magic of the following sort happens:
eval AMOUNT=( \$NUMBER_${LAB_IN_CAPS} )
While programming, I have learned a bunch of useful stuff about
bash. For example, the statement ARRAY=(element1 element2
element3) creates a new array. The statement
${ARRAY[0]} accesses the first element,
${ARRAY[1]} -- the second one, and so on. If you want to
know the number of elements in an array (e.g., for use in a 'while'
loop), that number is returned by ${#ARRAY[@]}.
Even though remote-touch.sh still exists, eventually it is going to become obsolete. It may be replaced by a "-t" (touch) option to remote-look.sh.
In other plans, we may switch to "pushing" upgrades on workstations, as opposed to "pulling" them from the server. Hopefully, rsync supports this operation. As Mike McCabe noted, performing "pushes" allows for better control and security. If we were to push updates, an image target would not have any scripts to sync it (which is equivalent to destruction in some cases). Local nodes will only have scripts to fix their own configs, which cannot (as far as I can see) be harmful. Controlling all upgrades from one place will also make for better scheduling. It will be possible to upgrade machines on a one-by-one basis, as opposed to syncing at certain times technique COSI utilizes now.
There is a possibly of upgrading certain parts of a target node without rebooting it, or interrupting any processes and/or users. Mike is working on something like that (Xen), but his project might be a little bit too complicated for our simple tasks.
During the past week, I managed and supervised installation of two alternative operating systems in COSI lab. The OS's are Ubuntu and Gentoo. They were installed on second hard drives left over from the old workstations after the lab upgrade a few weeks ago. I have started forming a team for an OSDL project. Rob Tirrell and I are going to work on the set of software applications for remote monitoring of lab computers and remote software management. The main purpose of the project is to provide an easy way to install and update software in multiple workstations. The script i wrote last week has been renamed to remote.sh. Now, it has the possibility to work with different labs. It is far from complete, but it is on the sure way of getting there.
Over the course of last week, I have developed a bash script called
cosi-remote.sh program. It has capabilities to detect network and ssh status
of workstations in COSI and number of users logged in on each workstation. It
can sync all machines either one by one with output or all at once without
output. Also, it can run arbitrary commands on all or selected machines and
login using ssh. Eventually, it might serve as a back-end for a lab monitoring
and managing application. Here are some sample outputs from the script:
solomarv@animal solomarv $ cosi-remote.sh
Usage: cosi-remote.sh {sync|fast-sync|up|ssh|users|stats|run
cosi-remote.sh login
solomarv@animal solomarv $ cosi-remote.sh stats 6
NETWORK: UP
SSH: UP
USERS: 2
solomarv@animal solomarv $ cosi-remote.sh fast-sync 1
Sync launched
solomarv@animal solomarv $ cosi-remote.sh ssh
Determining which machines are running SSH in COSI lab
cosi-lab-1 - SSH UP
cosi-lab-2 - SSH UP
cosi-lab-3 - SSH UP
cosi-lab-4 - SSH UP
cosi-lab-5 - SSH UP
cosi-lab-6 - SSH UP
cosi-lab-7 - SSH UP
cosi-lab-8 - SSH UP
cosi-lab-9 - SSH UP
cosi-lab-10 - SSH UP
SSH: 10 up, 0 down, and 0 denied permission out of 10 total
Rouslan Solomakhin