[Pkg-gridengine-devel] pkg-gridengine first steps

[Michael Banck]

Hi,

On Mon, Apr 23, 2007 at 11:51:02PM +0100, Mark Hymers wrote:
> On Tue, 24, Apr, 2007 at 12:03:37AM +0200, Michael Banck spoke thus..
> > Anyway, I checked in the debian/ directory of my old work on gridengine
> > to svn://svn.debian.org/svn/pkg-gridengine/trunk/debian , comment very
> > welcome.
> 
> Is there any reason we're only keeping the debian/ directory in
> subversion?  For freeradius, we keep an upstream branch in
> /branches/upstream/trunk and tag upstream releases in
> /tags/upstream/freeradius-x.x.x.  We then keep a full tree in
> /trunk which is the upstream + the debian directory.  Updating to the
> new upstream is easy; we use svn_load_dirs to load it into
> upstream/trunk, then svn merge that into /trunk.  Personally, I just
> find it easier to work this way but your mileage may vary :-)

Well, I've never seen the point in keeping upstream in RCS if you only
touch debian/ in the Debian diff anyway.  The alioth projects I'm
involved with don't do this either (maybe the X Strike Force still does
it, not sure).

But if you two prefer it that way, no problem with me.

> > There's also debian/TODO which lists the (IMHO) missing stuff, feel free
> > to add to it.
> 
> One of the important ones of these (for me) before upload would be to
> offer four packages instead of the current two.  I'd divide it up like
> so:
>  * gridengine-master (the master / scheduling daemons)
>  * gridengine-exec   (the execution daemon)
>  * gridengine-client (the client utilities)
>  * gridengine-common (anything which is needed by >1 of these)

Yes, the gridengine-server->gridengine-{master,exec} split certainly has
to be done before an upload.

I'm not sure how much we could stick into -common, maybe
/etc/default/gridengine, would -clients (or -client) depend on it?

> I'd have to check (off-hand I don't remember) how much the execd needs
> to run.  The reason for this division is that in most cases you will
> have machines configured with just the execution daemons and probably
> don't want the scheduler daemons even installed there.  Thoughts?
> If this is ok, I'll give doing it a shot.

Sure.
 
> > Probably the most pressing right now is figuring out how to run the
> > client programs without having to set environment variables (their
> > startup expects SGE_ROOT SGE_QMASTER_PORT and SGE_EXECD_PORT to be set).
> > Maybe we can hardcode the first one to /var/lib/gridengine (if $SGE_ROOT
> > is set, it would take precedence, of course), and get the other two from
> > /etc/services (there's support for this already).  We just need to get
> > some ports (which?) allocated here.  I've never had to bother with this
> > in Debian myself, anybody know where to request this?
> >
> > The daemons aren't a problem, they could just source
> > /etc/default/gridengine in their init scripts (to be written) or so.
> 
> Hmm.  My /etc/services has:
> 
> sge_qmaster 6444/tcp            # Grid Engine Qmaster Service
> sge_qmaster 6444/udp            # Grid Engine Qmaster Service
> sge_execd   6445/tcp            # Grid Engine Execution Service
> sge_execd   6445/udp            # Grid Engine Execution Service
> 
> in already.  It appears to have been added in netbase 4.28.  So we
> should be good to go for the SGE_*_PORT stuff.

Excellent, I've been using an outdated etch on my notebook and only had
netbase-4.25 installed.

> The problem is that (by my reading of policy) we can't require
> environment variables to run at all.  So for SGE_ROOT (and presumably
> SGE_CELL), we need to hardcode some defaults.  We could of course simply
> wrap all of the executables as scripts which, if SGE_ROOT and SGE_CELL
> aren't set, source them from /etc/default/gridengine.  That should be
> easy enough to sort out and is (sort-of) suggested in policy 9.9.

We could install the q* binaries in /usr/lib/gridengine and have a
wrapper script like this:

--8<--
#!/bin/sh

. /etc/default/gridengine

export SGE_ROOT
export SGE_QMASTER_PORT
export SGE_EXECD_PORT

NAME=`basename $0`

/usr/lib/gridengine/$NAME $@
--8<--

> > Using sgeadmin as admin user seems reasonable to me, just getting a
> > dynamically allocated system uid/gid seems enough for me. However, does
> > it make sense to have that user at all? If somebody knows about the
> > security implications etc., please speak up.
> 
> I'd just do the adduser --system ourselves in the gridengine-common
> postinst.  We can then setup the directories properly in postinst etc as
> each package requires.  That should be fine.

If -client depends on -common, that would mean all the clients/submit
hosts would needlessly get an sgeadmin user I guess.  I don't think
that'd be necessary, would it?
 
> > Maintainer: is currently set to the not-yet-existing list
> > pkg-gridengine-maint at lists.alioth.debian.org, does it make sense to
> > create this one (for bug report/upload spam etc), or should we keep
> > just use pkg-gridengine-devel?
> 
> Personally, unless this becomes very high traffic, I'd just stick to
> using the -devel list.

OK.


Michael