1. Pacman issues affect Core software Infrastructure Testbed Preparing demos Preparing interoperability tests This is a critical time for establishing good practice in making caches… Saul Youssef, Boston University, 2002

2. Great progress has been made in making caches Sean McKee [ iperf ] Lisa Ensman & Shava Smallen [ grappa, vrvs ] Jason Smith [ globus2, gdmp, all rpmed ] Alain Roy [VDT] Kaushik De & Pat McGuigan [testbed apps] LBNL guys [system admin stuff]

3. We’re making a cultural transition Boston BNL LBNL Indiana UT Arlington U.Michigan ANL VDT Fetch, install, setup, update by hand in the Unix tradition. We need new traditions and conventions to help this work smoothly

4. The cache manager concept helps. I would suggest The cache manager be responsible for the installations and setups working properly. If anything in an installation or setup goes wrong, the cache manager should be the person to complain to. The cache manager decides when updates occur and is responsible for upward compatibility. We should distinguish caches which are in flux and caches which are kept upward compatible. A forum for the cache managers to regularly communicate – one of the weekly phone meetings. Identify a “cache manager manager” to coordinate name clashes, who’s doing what etc. and to help establish helpful standards.

5. For example… pacman –get DOE-certificate Advantages are the same as for software: One person can maintain DOE-certificate.pacman so that it always points to the right documentation and always does the right thing. Instructions automatically come up at the time when they are needed. We can update the procedure for doing this globally with a minimum of fuss and confusion. Convenient way to guarantee a standard certificate for the outside world.

6. pacman –get Atlas-testbed-gridmap Similarly… Many of us got the following email yesterday…

7. As was previously announced, support for Ssh Protocol 1 has been disabled at the RCF and US Atlas Computing Facilities. Access to these facilities is now only allowed with Ssh Protocol 2. Users who have not upgraded to an Ssh Protocol 2 capable client will need to upgrade in order to access the facilities. Information on Ssh Protocol 2 capable clients is available from the Ssh FAQ. http://www.employees.org/~satch/ssh/faq/ssh-faq.html Shigeki Misawa (misawa@bnl.gov) -- This message forwarded from the RCF announcements page. Recent messages are available at: http://www.rhic.bnl.gov/RCF/Announcements/announce.html _______________________________________________ Usatlas-users-l mailing list Usatlas-users-l@lists.bnl.gov http://lists.bnl.gov/mailman/listinfo/usatlas-users-l OpenSSH-protocol2.pacman

8. Rapid response for any Pacman issues is needed Alain Roy & S.Y. will provide this. Pacman will be absorbed into VDT soon…

9. Often demos are prepared at great cost and then fail to work after a few months for one reason or another. Similarly for interoperability tests. It might be much more helpful to create demos and tests which are maintained over time and distributed via caches. Part of the cultural shift… job demo Condor/GDMP test Monitoring demo

10. Suggestion virtual data demo Event display Demo Monitoring demo Use the cache concept to help put together a coherent set of demos for SC 2002 Grappa demo Magda Demo

11. Technical improvements to the existing caches: We should automate any remaining post-installation, configuration, certificate fetching etc. Setup should guarantee a working environment. Need helper packages like “RedHat-7.2” etc. Improve relevance of web pages pointed to as docs. Point to local documentation where it exists. Point to demo app when it exists. Keep track of daemons when they exist. Support at least linux2 and possibly Solaris. Cache documentation is chaotic at the moment. Use Pacman “root” when root is required for nicer errors.

12. Pacman MDS Patrick McGuigan Dantong Yu Arrange so that installation, setup & configuration are automatic.

13. CMTRPM Pacman If this works, we will be able to create a Pacman cache from any CMT installation & transport it anywhere.

14. Pacman recent additions: (version 1.075) Better rpm handling is in place. Recursive uninstall and remove. -get == -fetch –install Shava’s fixes are in. Kaushik’s favorite tar switches are in. Coming next: Relative installation. Cache:XXX package names.

15. Testbed Issues for discussion Redistributing modified Pacman versions. Hard wiring installation locations. Putting stuff in /usr/local/bin. cernlib – glibc & ld issues.

16. Hard wired locations considered harmful /vdt /opt /cern, putting things in /usr/local/bin Needlessly requires root Can’t test new version without removing old. Sets up needless conflicts with other users, e.g. CMS. Creates needless admin problems, e.g. full /opt. Can’t rm –r to start from scratch. I personally think that it’s worth removing these now before people start assuming fixed locations for software.

17. Cernlib rpm issues… testbed cernlib wants to replace glibc & the loader