# Presentation: 417824

## Scientific Linuxexperience@INFN/Trieste

- B.Gobbo – Compass
- R.Gomezel - T.Macorini - L.Strizzolo
- INFN - Trieste

## Outline of Presentation

- Introduction
- Evaluation phase
- SL Test installation
- Installation
- Configuration
- Management
- SL and Compass Computing FARM

## Before moving to SL

- When the end of official support from RedHat was announced in 2003 we had all PCs running Linux RedHat 7.3 and 9
- HEP community was evaluating different roads to follow
- Initially we are waiting for a common answer coming from INFN Computing Committee and looking at what was moving around
- At our site we tried different distribution based on RedHat Enterprise Linux like
- CentOS 3.1
- Fermi Linux
- Scientific Linux 3.0.1

## Evaluation of the needs

- As time went by we decided to have a meeting in order to discuss how to meet the needs of people involved in different experiments
- It was clear that there were many distributions which were a rebuild of RHEL3 from Red Hat’s source RPM stripped of parts that cannot be distributed without a license
- Need to have a distribution well maintained and validated by the HEP community

## Scientific Linux – Final Test installation

- As Scientific Linux 3.0.1 was available we installed it on a few PC clients in order to test how user’s feeling was
- we got a good feedback
- So we went on with the installation of SL 3.0.2
- At the time SL 3.0.3 was released we had in production
- 10 PC client (desktop functionality)
- 1 PC with server functionality

## Scientific Linux – Final test installation

- No problems or complaints coming from users running their applications and software
- Then the decision to upgrade all PCs running SL to the new SL 3.0.3 and to move more PCs  to the new release
- Right now we have 30 PCs clients and 3 PCs servers with SL 3.0.3 installed

## Scientific Linux - Installation

- Kickstart is used to install SL on the PCs
- Kickstart file generated using ***buildks***** **which is a tool developed at INFN Trieste
***Buildks ***allows to install and configure linux PCs automatically based on group-specific policy
- a specific network group configuration
- Type of PC: multiboot or singleboot
- ...

## Scientific Linux - Management

- Installed machines are currently managed via ***Linux-update***, a tool developed locally
- Linux-update allows us to modify in a centralized way
- Configuration files
- Specific installations
- RPM packets management
- Anyway YUM  is easier and more powerful  to manage RPM packets

## Scientific Linux – Configuration (1/2)

- A local repository has been created for the SL 3.0.3 distribution
- Every night via lftp a mirror is created copying the distribution from _[ftp://ftp.scientific.linux.org/linux/scientific/303/i386/](ftp://ftp.scientific.linux.org/linux/scientific/303/i386/)_
- This distribution is locally accessible using ftp anonymous just open to the local network nodes

## Scientific Linux – Configuration (2/2)

- Linux PCs are configured as “YUM clients” of the local FTP server hosting the distribution
- Update is done as the PC starts up and via a cron job using the simple command ***yum update*** as running
- Kernel update is not managed by an automatic tool
- After a test phase it is installed manually

## Scientific Linux – Release upgrade

- Moving from SL 3.0.2 to 3.0.3 was smooth and painless
- A script was created and run on all PCs with SL 3.0.2 installed
- They were updated to the new release using mainly ***yum update ***and just a few more things as running
- At the end just a reboot was necessary (for the new kernel)

## ACID (The COMPASS Trieste Compute Farm)

- Current Environment
- Hardware
- 32 PC clients, 4 disk servers, 1 tape server + a small tape library (STK L40), 1 Oracle server, 1 supervisor and software repository server. All two processors machines
- Software:
- OS: Red Hat Linux 7.3 (but Oracle server: it runs Red Hat AS2.1)
- Just few packages patched for local deeds:
-     kernel (NFS over TCP, 32k R/W size, F.Collin patches to Tape Drivers), OpenAFS, OpenSSH (local setup), CASTOR (it is a CERN software, small changes in code, local setup)

- B. Gobbo

## ACID (The COMPASS Trieste Compute Farm)

- Software
- Monitoring: BigBrother 1.9e (Quest Software)
- Resource Management: Grid Engine 5.3 (Sun Open Source Software)
- HSM: CASTOR 1.7.1.5 (CERN Software)
- RPMs upgrade using LinuxUpdate tool (Developed in INFN Trieste)

- B. Gobbo

## ACID (cont.d)

- Upgrades to be done before end of the year
- Hardware
- ~6 more PC client nodes (with Opteron?)
- Software
- OS: Move to Scientific Linux (CERN Version under test)
- 2 Client nodes already migrated for tests
- 1 Server installed with Red Hat EL3
- All needed software already ported
- Experiment software porting basically finished.
- Initially we had problems with Grid Engine 6.0: AFS token is not exported (that is a major problem as user home directories are under AFS). Lack of support for AFS credential in qsub. Anyhow Grid Engine 6.0 now works.

- B. Gobbo

## ACID (cont.d)

- Software
- Few changes are needed to “adapt” distribution to local environment
- Mainly remove some “too-CERN-related” items
- We keep CERN built kernel
- We are still considering “pure” SL too, as an alternative
- In that case few packages need to be added. Kernel has to be rebuilt.
- We keep local mirror of SLC and SL repository
- Following the CERN model: upgrade via APT (from the local repository)
- We had a look at QUATTOR too
- But the farm is not so big. Probably such a powerful too is not needed

- B. Gobbo