# Presentation: 431267

## 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

## Great progress has been made in making caches

**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]

## 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

## The cache manager concept helps.  I would suggest

- 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.

## 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.

## Similarly...

**Many of us got the following email yesterday...**

## OpenSSH-protocol2.pacman

- 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**

## Rapid response for any Pacman issues is needed

- Alain Roy & S.Y. will provide this.
- Pacman will be absorbed into VDT soon...

## Part of the cultural shift...

- 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

## Suggestion

**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

## 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.

## Pacman

- MDS

- Patrick McGuigan
- Dantong Yu

- Arrange so that installation, setup & configuration are automatic.

## Pacman

- RPM

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

## 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.

## Testbed Issues for discussion

-  Redistributing modified Pacman versions.
-  Hard wiring installation locations.
-  Putting stuff in /usr/local/bin.
-  cernlib – glibc & ld issues.

## 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.

## Cernlib rpm issues...

-      testbed cernlib wants to replace **glibc** & **the loader**