apt-get  //  Wednesday, October 29, 2008

Please note, there are some things that you should avoid, namely the following type of command:

for N in `seq 2 8`; do
ssh grid$N apt-get -u dselect-upgrade ;

Especially if there are any configuration options that require interaction, say in the case of the Sun JDK. If you do this, apt will complain, and leave your package unconfigured. Make sure you go back through your nodes and configure them, or you will have a crippled system.

Also, for future reference, it might be a good idea to do something like:
apt-get -u dselect-upgrade -y -q


posted by Christian @ 6:41 AM

New Digs  //  Tuesday, October 21, 2008

I spent the better part of the day today reorganizing the room in which the grid lives. Through various contacts, I was able to acquire a server shelf on which to house all of the systems, which allowed us to free up much of the real estate in the room. The entire grid is now side-by-side with the department web server. Nothing technical, but here's pictures:

Next time, I will discuss my solution to the node-addition problem. I'm considering g4l, to image the nodes and distribute the OS, although I admit, there doesn't really seem to be a good way to do it. I am also looking into the possibility of using something like BOINC to distribute grid jobs across more of campus.

Here's to next time.


posted by Christian @ 5:36 PM

Sticky Situation  //  Wednesday, October 1, 2008

I have gotten a sticky directory set up on each server, so the users will have a place to keep things locally on each machine. On each node (and the master), there exists /sticky, which looks thusly:

drwsrwsrwt 2 root users 4096 2008-09-21 15:32 sticky

For those that need explanation, there are two less-than-common things going on with this directory. First off, it's got the sticky bit set (chmod +t). This means that items inside /sticky can be renamed or deleted only by the item's owner, the directory's owner, or root (aka, me). The second bit of cool filesystem magic that I worked on this directory is that I set the setgid permission on /sticky. Setting the setgid permission on a directory (chmod g+s) causes new files and sub-directories created therein to inherit the parent directory's GID, rather than the primary GID of the user who created the file. I thought that this might come in handy somewhere down the road, especially if two users need to collaborate on something.

As far as accessing the sticky directory is concerned, that part is cake. I have put a symlink in each user's home directory (and /etc/skel) called local that will point to /sticky. Observe:

lrwxrwxrwx 1 caf caf 7 2008-10-02 11:35 local -> /sticky

In other news, I have gotten around to some physical moving of the grid, as well. I put the two machines (disseminate and mete) into the server closet where they will live, and adjusted their network configurations appropriately. All eight of the grid machines, along with the master, are now in their final locations. I have attached a few pictures of the setup, so you can see (kind of) what it will look like. Please note, these are not the highest of quality, as they were taken with my iPhone.

The Grid - Broad View

The Grid - Action Shot

That's all for now. Tonight, I hope to get the temporary master installed and imaged and whatnot. That will allow me to start planning for the implementation of the real master down the road.

Until then,


posted by Christian @ 11:42 AM

Site Design Copyright © 2008 Christian Funkhouser

Site used in accordance with the Elon University Web Policy.

Make note of this disclaimer.