Hi folks,
The new gnu-queue vaporware is now publically inspectable at least...
I've created a new CVS repository at the Savannah site and imported all
of the new source tree, automake/autoconf build files & other GNU
project standard files (place holders at the moment). check it out if
you want, it will not work out of the box or do anything impressive and
I don't have a chance to write some decent instructions for how to get
it to at least try to do something.
At the very least it will need a system wide key file created called
"system-keyfile" which the programs just expect to find in their cwd. It
just needs 20 random bytes in there. To make one, just do
dd if=/dev/random of=system-keyfile count=20
When this is all a bit more mature, this file will be created by an
install script, and it must be readable only by root or by a non-root
"system user" defined specifically for running the gnu-queue system.
Security depends entirely on the privacy of this file. If that sounds
sketchy (it is sketchy), I might point out that security of your SSH
daemon rests entirely with the privacy of your private host key file...
Some brief explanations:
To build, just ./configure && make -- if you get build errors on your
system, send the output to the list and what system you are trying on.
It has been tested on one system, mine, which is FC3. Anybody who has
different gnu/linux distros, or non-gnu/linux systems, we'll need your
help getting the build cleaned up.
There are 5 programs, here is what they do:
qs: user command submission program
qd: daemon running on compute nodes, receives job advertisements and
autonomously decides whether or not it's local system can execute them.
(if so, it responds with a volunteer message -- qm (below) picks one of
the volunteers)
qm: scheduler. receives connections from qs, distributes jobs to qd
qe: execution agent. This program must be setuid (you will need to do
that manually). This program is the only program which must run as root
(except qlogin), which it only needs to change to the user of the job
submitter. It is spawned by qd, but qd does not (and should not) run as
root. qe does not listen to the network, and only switches users and
performs execution if the username and password supplied by qd can be
validated via PAM. This is a security feature.
qlogin: This program must be setuid so it can read the system-keyfile.
It will create a file in the user's home directory called ".qtoken"
which contains the user's password in an encrypted form, as well as some
other bull. This saves the user the trouble of typing their password on
every invocation of qs. presently, this is required as qs can not prompt
for the password directly. qlogin will check the password via PAM to
make sure it's right. Otherwise, a user could queue something with a
bad .qtoken and then some time later, when their jobs come up in the
queue, they will all fail because qe will refuse to execute them if it
can't verify the submitting user's identity.
So, after creating the system-keyfile, you could try to test out on your
local system, like this:
[NOTE: qm and qd do not daemonize themselves, because I'm still working
on them quite a bit. There may or may not be a lot of debugging output
depending on whether I left that on in the source I just checked in to
CVS ]
open a terminal, ./qm
open another terminal, ./qd
open a third terminal, then
./qlogin
./qs "ls -l > ls-test"
if you get a file called "ls-test" in the directory when that command
returns, and it looks like the output of ls -l, then it worked. If it
doesn't, open up the source and see if you can figure out why... Note
there is no terminal support or any I/O redirect back to ./qs itself, so
you must quote the I/O redirect so that it happens at the remote end.
Ok, that's all I got time for. I won't have time for much else for quite
a while as I am collecting samples for my research now at the field
which seems to take all the time and energy I have... nothing that can
be done about that, plants are ready when they're ready.
Cheers,
Koni
|
