One additional point: Markus's slides say that Argus 1.1 is scheduled
for glite 3.2 update 9 - the next one. This was later contradicted by
Mario David who said it had currently been removed. 

There is also an issue with 1.0 as it doesn't authenticate but just
passes the public key of the user (or is it proxy) to the Argus server.
CNAF verified that you could exhaust pool accounts by sending lots of
public keys - possible DoS. This is rectified in 1.1. 

John

> -----Original Message-----
> From: Testbed Support for GridPP member institutes [mailto:TB-
> [log in to unmask]] On Behalf Of J Coles
> Sent: 25 March 2010 13:57
> To: [log in to unmask]
> Subject: Re: ARGUS testing
> 
> Hi Ewan/All
> 
> This is interesting initial feedback. The ARGUS/SCAS topic came up at
> the GDB yesterday. On ARGUS specifically it was mentioned that there
> is a compatibility issue between ARGUS 1.1 that is about to be
> released and ARGUS 1.0 which means that the clients must match. This
> does not have any bearing on your findings but does again suggest that
> the product is still evolving.
> 
> The GDB as a whole did not see any need to specify what product sites
> should take - i.e. SCAS or ARGUS. It was noted that SCAS is now better
> tested and should have a lifetime of a few years. It can not use the
> central banning list being established at CERN but then ARGUS is not
> (quite) ready for that either. Feedback generally is that installing
> SCAS or ARGUS is relatively striaght forward - well perhaps ARGUS is
> not given your feedback - and so sites should not hesitate with SCAS
> now.
> 
> The MB on Tuesday agreed to continue the suspension of the MUPJ
> policies so that the experiments can continue running as now without
> glexec. I would expect some statement to the community about this
> soon. For now we need to continue rolling out instances of glexec with
> SCAS or ARGUS to allow experiment testing to evolve. There are also
> some Nagios tests for glexec. One problem noted yesterday concerned
> where glexec is installed - the default being sbin which may not be
> appropriate. For those sites that have glexec there is a need to
> publish the existence via GlueCECapability: glexec . For more
> information on these updates and more see Markus's talk at
> http://indico.cern.ch/sessionDisplay.py?sessionId=4&confId=84636
>   (also good for the middleware update) and Maarten's here:
> http://indico.cern.ch/sessionDisplay.py?sessionId=7&confId=84636
> .
> 
> We'll follow up at Tuesday's sites plus deployment team meeting.
> 
> Jeremy
> 
> 
> On 25 Mar 2010, at 13:14, Ewan MacMahon wrote:
> 
> > Hi all,
> >
> > We've done some very basic testing of ARGUS, and the short
> > version so far is that it doesn't seem to work. We've tried
> > it on two different SL5-64 systems and the install as per the
> > instructions[1] is essentially straightforward, consisting
> > of the usual steps of getting the appropriate yum repository
> > file, installing a metapackage (an actual one, not a
> > yum group), and running yaim. The packages are missing a
> > dependency on OpenJDK, which is a known bug[2], so that
> > needs to be yum installed explicitly.
> >
> > Yaim appears to complete successfully, however any attempt to
> > start the services simply causes them to burn CPU time for
> > about four seconds before dying with a java error apparently
> > related to problems reading the host certificate (see below).
> >
> > Clearly, it can't be that broken for everyone since it's made
> > its way through a lot of development and a certification
> > process, but I don't think we've done anything special with
> > our configuration. We'll be following this up, but it would
> > be good to know if anyone else has tried it at all.
> >
> > Ewan
> >
> > [1] https://twiki.cern.ch/twiki/bin/view/EGEE/AuthzQSYaimInstall
> > [2] https://savannah.cern.ch/patch/index.php?3076#comment13
> >
> >
> > Example java error:
> >
> > Error: Identity reading failed: null
> > java.security.cert.CertificateException: Identity reading failed:
> null
> >         at
> > org.glite.security.trustmanager.UpdatingKeyManager.loadKeystore
> > (Updating
> > KeyManager.java:264)
> >         at
> > org.glite.security.trustmanager.UpdatingKeyManager.<init>
> > (UpdatingKeyMan
> > ager.java:125)
> >         at
> > org.glite.security.trustmanager.ContextWrapper.initKeyManagers
> > (ContextWr
> > apper.java:497)
> >         at
> > org.glite.security.trustmanager.ContextWrapper.init
> > (ContextWrapper.java:
> > 415)
> >         at
> > org.glite.security.trustmanager.ContextWrapper.<init>
> > (ContextWrapper.jav
> > a:266)
> >         at
> >
>
org.glite.authz.pap.server.standalone.TrustManagerSelectChannelConnecto
> r
> > .initializeSSLContext(TrustManagerSelectChannelConnector.java:83)
> >         at
> >
>
org.glite.authz.pap.server.standalone.TrustManagerSelectChannelConnecto
> r
> > .createSSLContext(TrustManagerSelectChannelConnector.java:91)
> >         at
> > org.mortbay.jetty.security.SslSelectChannelConnector.doStart
> > (SslSelectCh
> > annelConnector.java:575)
> >         at
> >
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:
> > 50)
> >         at org.mortbay.jetty.Server.doStart(Server.java:233)
> >         at
> >
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:
> > 50)
> >         at
> > org.glite.authz.pap.server.standalone.PAPServer.<init>
> > (PAPServer.java:12
> > 1)
> >         at
> > org.glite.authz.pap.server.standalone.PAPServer.main(PAPServer.java:
> > 344)