Pacman issues affect

Core softwareInfrastructureTestbedPreparing demosPreparing 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

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

pacman –get Atlas-testbed-gridmap

Similarly…

Many of us got the following email yesterday…

As was previously announced, support for SshProtocol 1 has been disabled at the RCF andUS Atlas Computing Facilities. Access to thesefacilities is now only allowed with Ssh Protocol 2.

Users who have not upgraded to an Ssh Protocol 2capable client will need to upgrade in orderto access the facilities. Information onSsh Protocol 2 capable clients is available fromthe 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 listUsatlas-users-l@lists.bnl.govhttp://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…

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 job demo

Condor/GDMP testCondor/GDMP test

Monitoring demo

Suggestion

virtual data demo virtual data demo

Event display DemoEvent 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.

CMT RPM Pacman

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