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
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
VDT
U.Michigan
Boston
Fetch, LBNL ANL
install,
Indiana
setup, update BNL
by hand in the
Unix UT Arlington
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.
Similarly…
pacman –get Atlas-testbed-gridmap
Many of us got the following email yesterday…
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
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…
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.
Monitoring
job demo
demo
Condor/GDMP test
Suggestion
Use the cache concept to help put together
a coherent set of demos for SC 2002
virtual data Event display Demo
demo
Monitoring
demo
Magda Demo Grappa
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