Your university or experiment logo here Package Management of VO Records Concept: Take XML from Ops Portal, Convert to RPM, Combine with YAIM Logic, Manage Updates with RPM or YUM

Your university or experiment logo here 29/04/2015 Talk Title Goes Here 2 Recap Recap: Ops Portal exports XML – what good it that? Not obvious how to convert to YAIM. Peter G. wrote “Approved Vos” wiki to contain YAIM records. This records only need to be transcribed once. Nonetheless, it went stale. Answer: Automate doc update (i.e. VomsSnooper). More problems: Recent Backup VOMS changes took weeks. Answer: Make it easier – but how?

Your university or experiment logo here 29/04/2015 Talk Title Goes Here 3 Recap Plenty of ways to do it: Download VOID card, transcribe yourself manually  Scrape the records you want from the Approved VOs documents, load into YAIM yourself  Go directly from the Tarball, supplied on Approved VOs document  Download site copy of VomsSnooper  Chris W. suggests: Maybe with RPMs? ( ?)

Your university or experiment logo here 29/04/2015 Talk Title Goes Here 4 Recap Amelia Earhart: “The most effective way to do it is to do it.” But she disappeared (assumed dead).

Your university or experiment logo here 29/04/2015 Talk Title Goes Here 5 Investigation Results of “doing it”: 5 line script that can break up the Jumbo VOID cards XML from the ops portal into individual XML for any approved VO. Put the individual XML into specific RPM for that VO, and rig it up so that the XML gets copied out when the RPM is installed. New mini-vomssnooper (specific) in Perl called update- voconfig.pl. It uses standard Perl components that “always” get installed (I can't use Java/VomsSnooper because Java may not be installed or have poor version, different components etc.)

Your university or experiment logo here 29/04/2015 Talk Title Goes Here 6 Logic Logic in update-voconfig.pl to perform config_vomsdir and config_vomses. Put update-voconfig.pl into the RPM as well. Use a hook (epilog, trigger, %post, whatever …) into the RPM so the final act is to call update-voconfig.pl. But RPM calls local-update-voconfig.sh instead, should it be present. So, to customise, place local-update-voconfig.sh that contains any logic you like.

Your university or experiment logo here 29/04/2015 Talk Title Goes Here 7 Script has 280 lines of perl Two classes: –VoidCardHandler – holds a VOID card (just the bits we need), and an interface for a SAX parser. –VomsServer – holds data of one Voms Server. A VoidCardHandler has several of these. Pass the handler to the SAX parser, feed in the XML, load the data. Then call routines to: –sub checkVo ($); –sub configVomsdir ($) { –sub configVomses ($) { –sub printYaimRecords ($) { Or anything else you want. Details

Your university or experiment logo here 29/04/2015 Talk Title Goes Here 8 Bad news Caveats: Bad news first: The VOMS_SERVER variable is also used by config_mkgridmap. This is (unfortunately) a complex, unstructured monster shell script that does much fixing and poking about in an unfathomable manner. It might take a week to reverse.

Your university or experiment logo here 29/04/2015 Talk Title Goes Here 9 Good news Good news: Despite the horror story that lies inside config_mkgridmap, the shell script works OK. And, when using central authentication with ARGUS, config_mkgridmap only needs to be run on the ARGUS server and DPM. This bit can be managed by hand. When (if) DPM moves to central authentication with ARGUS, 50% of the problem vanishes automatically (nice!) In the fullness of time, further standardisation may make it possible to either (a) replace “gridmap” and its children with a pucker database solution or (b) if “gridmap” and its children persist, then reverse config_mkgridmap into something comprehensible.

Your university or experiment logo here 29/04/2015 Talk Title Goes Here 10 Outcome Upshot: Here's a draft procedure to update a “typical” site using this prototype RPM scheme: Update the site-info.def on all servers with newest VO records. This is not necessarily needed in all usecases, but it should be kept up to date as a point of fact. BTW: A feature in update- voconfig.pl prints out the records, so you don't need to scrape the Approved VOs wiki page. Do update: –WN: Install RPMs. –CREAM: Install RPMs. –ARGUS: Install RPMs (& run config_mkgridmap if new admin voms_servers). –DPM: Install RPMs (& run config_mkgridmap if new admin voms_servers). Restart services as appropriate (e.g. restart tomcat, ARGUS daemons or DPM daemons).

Your university or experiment logo here 29/04/2015 Talk Title Goes Here 11 Discussion Problem: is this less work? At present, you just roll out a new site-info.def and run YAIM everywhere. Now you can be selective, and avoid running YAIM everywhere. But you still need to maintain site-info.def (in case you need to run config_mkgridmap). On the other hand, you can implement your own local-update- config.sh. If you do so, you can just install RPM and relax. I dunno – let’s have a think.

Your university or experiment logo here 29/04/2015 Talk Title Goes Here 12 Other ideas Here a way to operate it: Give it a local-update-config.sh that does nothing Ask Puppet to do all the config. Just install RPM; puppet does the rest. Here’s another way to operate it: Put in a local-update-config.sh in that spits the VOMS records out into the Site-info.def/vo.d dir in YAIM format, Run YAIM.

Your university or experiment logo here 29/04/2015 Talk Title Goes Here 13 Pros, Cons, Ideas, Infrastructure etc.  Various ideas have come up about control of the material.  For example, we could test the rollout first.  We could put version numbers on the RPMS.  We could sign the RPMS to make them safer.  We could add the management to the Ops Portal or keep it outside and maintain it ourselves.  This could be done in conjunction with the Approved VOs or instead of the Approved VOs document.  Because we have versioned the RPMS, we could manage the adoption with great certainty.  There would be no need to screen scrape the Approved Vos  We could alert sites when rollouts occur. .

Your university or experiment logo here 29/04/2015 Talk Title Goes Here 14 Finally Assuming (for a moment) that it is less work and assuming no bugs (a big assumption?), then the site is now "Ship Shape and Bristol Fashion" wrt. voms records. I won't go much further with this until I get some feedback. But I'm going to try this process at L'pool to get things straight, and monitor it (I’ll take my own medicine before giving it to anyone else!) This may (TBD) represent a viable way to configure a site wrt. VO records. Cheers, Steve Feedback please?