Re: [Osgmm-discuss] OSG MM and the VDT

[Mats R. <ry...@re...>]

Alan De Smet wrote:
> I have some questions about the OSG Match Maker as I'm working on
> adding it to the VDT.
> 
> 0. Would you prefer I direct these questions and comments to
>   osg...@li...?

Yes, that would be great. I have added the list to the CC line.


> 1. The documentation says the OSG Client software stack is a
>   prerequisite.  Which parts are needed?  I'm assuming you're
>   talking about the package known as "vo-client" and "OSG VO
>   Client", which only adds vomsetc/vomses and glite/etc/vomses on
>   top of the VDT install.  Are these specifically needed?  Are
>   there other things beyond the basic VDT that are required?

Basic VDT should be fine. The requirements are Condor, Java, and VOMS
clients.


> 2. I've been told that the MM requiers a "full shell."  What is
>   meant by this?  What does it do with the shell that it needs
>   this?  We're considering using the daemon account by default,
>   and while you can run /bin/sh as daemon, you typically can't
>   directly log in as the default shell is /bin/nologin or
>   similar.  Will that be good enough.

I need to do some testing here. OSGMM is shelling out to do a lot of
tasks, and I'm not sure if /bin/nologin would have an impact on the
shell outs. The other reason for having an account with a full shell is
that if validation is enabled, the user OSGMM runs under needs a valid
proxy. In the current instances we have of OSGMM we use voms-proxy-init
to maintain the proxy. I guess maintaining the proxy could be done as
another user and then copy/chown the proxy to the daemon user.


> 3. Are there other MM-specific risks to running in the daemon
>   account, or another shared account?  I notice that your sample
>   init script will kill anything running under the osgmm account,
>   but I think we can deal with this.

The risk is if validation is enabled, and there is a user proxy for
daemon. If some other process which is also running as daemon gets
compromised, the proxy can easily be stolen. Having the option for
running OSGMM in its own account would be nice.


> 4. We're considering running the MM under Condor as a top level
>   Condor daemon.  This would give it the same automatic
>   monitoring and restart capabilities as any other Condor
>   daemons.  This includes the ability to hunt down and kill child
>   processes when shutting down.  Are there any potential problems
>   with this that you immediately think of?

That would be great. The only issue is probably the daemon user issues
from 2. and 3.


> 5. What versions of Java are acceptable?  In particular, which of
>   4, 5, and 6 will work with the OSG MM?

5 or 6 will work.

-- 
Mats Rynge
Renaissance Computing Institute <http://www.renci.org>