infso-ri-223782 etics local setup experiences a case study for installation at customers location...

INFSO-RI-223782

ETICS Local Setup ExperiencesA Case Study for Installation at Customers Location

4th. All Hands Meeting Uwe Müller-WilmVEGA

Bologna, Nov. 2009

2

INFSO-RI-223782

Bologna, Nov. 2009Local SetUp Experiences

VEGA's Sandbox:

2 Servers: etics.vega.de: ConfigurationWS etics-rep.vega.de: RepositoryWS, • both based on SL4 CERN templates2 Worker nodes: SL4 (CERN template), SLES9: custom made, integrates ESOC patchesWorks on: VMWare ESX ServerCustomisation: Access restriction

https://etics.vega.de

https://etics.vega.de/

3

INFSO-RI-223782


4

INFSO-RI-223782


1. Deployment Scripts

Deployment scripts for ETICS WS and Repository WS are fairly OK. Only pitfall: do really only configure one purpose at each of both machines. Else you get a mixture of both services, even if the scripts offer you the option to specify ETICS WS or repository WS.

Problems start with installation of ETICS client and NMI scripts needed for remote build (and plugins) if your system is located inside of an isolated environment (no access to etics.cern.ch).

5

INFSO-RI-223782


2. NMI Scripts1. Scripts for nmi are packed in tgz format and are

located (on our system) under:

/opt/etics/etc/nmi/etics-nmi-scripts.tar.gz

on the Configuration WS. They have to be adapted, as they all contain references to etics@cern.

Example: there is a script post_all which establishes a link to /afs.cern, something you probably do not have on your local system.

Workaround: Untar the scripts, perform a grep for cern and replace accordingly. Then tgz again.

6

INFSO-RI-223782


3. Adaptation of ETICS Client

etics-client-setup.py is (in our case) located under:

/var/www/html/archive on the Repository WS:

and will be called via:

wget https://etics-rep.vega.de/archive/

have to be adapted as well as there are references to etics@cern. This has to be done everytime a new client is released, so it is recommended to prepare a patch and to do the changes automatically.

https://etics-rep.vega.de/archive/

7

INFSO-RI-223782


4. Build System Client Package

The etics build-system-client package, which is called from the etics-client-setup.py script must be accessible from the etics configuration server. In our installation it is located under:

/var/www/html/archive/org.etics/org.etics.build-system.client-py.

It contains a tar.gz file, which includes a template for the etics.conf script, which is used during remote builds. This script by default tries to contact etics.cern.ch, so the remote build always fails. If you have internet access, this server will be used for remote builds, even if you "think" you are working on your local system.

8

INFSO-RI-223782


5. Plugins

All plugins which should be used are of course also expected under:

/var/www/html/archive/org.etics/org.etics.plugins ...

Same procedure: if a plugin fails it is very probable that a reference to [email protected] is given. This has to be corrected. This is also true for every mail adressing etics.cern.ch etc.

9

INFSO-RI-223782


6. ETICS Access Filter

The Access filter restricts all access to the ETICS server to those users which

1. have a valid certificate and2. are registered in the ETICS User DB.For this purpose http via port 80 has to be disabled in the apache

conf.Works fine, however again some issues have to be reflected for

remote builds:etics.conf (see above) has default settings, which:1. do not point to any certificate2. but use https as standard protocol.After implementing the access filters, this was now rejected, as no

valid certificates had been found and the etics client stopped here, as http access was disabled.

10

INFSO-RI-223782


ETICS Access filter, Solution

• modify the etics.conf in your local archive in that way that it is by default pointing to the correct certificates of the worker node (which is expected under /etc/grid-security)

• insert the userDN of the certificate of the WN in the user table and make it active.

• Now the WN can identify itself at the etics-server as an autorized user and the remote build passes.

• You can completely disable access via http, port 80.

11

INFSO-RI-223782


Resumee: It Works, but ...

• The deployment scripts for eticsWS and eticsRep are fairly portable, with some minore exceptions (Mail direction etc), however the etics client setup and the plugins need to be reviewed for being really system independent.

• If I transfer my experiences to a customer who might invest nor more than 14 days to set up the system, I'm pretty sure that we do not get many successful deployed systems without doing concrete improvement of the identified open issues.

• However, the problems are identified and can be fixed without too much effort, which is a good news.

12

INFSO-RI-223782


7. Firewall issues

Current Firewall Restrictions at VEGA corporate Network:

! No opening of dynamical range of ports allowed from DMZ to Integration Network. 20 Ports for each WN are a minimum for NMI. ==> this disallows the usage of condor master + submitter at DMZ and condor worker at the integration NW (behind the Firewall).

! No Webservers in Corporate Network allowed which are accessible from internet. No Webservers in Integration Network allowed which are accessible from internet.

13

INFSO-RI-223782


14

INFSO-RI-223782


ConsequencesThis disallows move of ETICS behind the firewall and to make

it accessible via https over ssh port tunneling from DMZ to the Integration Network. This solution would probably be technical possible, but not allowed from security points of view.

Current temporary solution which is implemented: WN are in the DMZ ==> no firewall problem. Sufficient for demos, but not a final integration for a production system.

Long term solution:

Condor web services interface with defined number of open ports (https)? This could be probably established when final decision is taken that VEGA uses ETICS as an official development tool.

15

INFSO-RI-223782


Topics to Discuss

Usage of Generic Connection Brokering (GCB)?

http://www.cs.wisc.edu/condor/manual/v6.9/3_7Networking.html#24212https://www-auth.cs.wisc.edu/lists/nmi-users/2008-January/msg00001.shtmlhttp://nmi.cs.wisc.edu/taxonomy/term/3?page=3

Question: Are there any better (and more elegant) configuration alternatives - Condor WS ???

All these topics can be found on the internal SA1 Wiki:https://twiki.cern.ch/twiki/bin/view/ETICS/SA1VegaCollaboration

http://www.cs.wisc.edu/condor/manual/v6.9/3_7Networking.html#24212

https://www-auth.cs.wisc.edu/lists/nmi-users/2008-January/msg00001.shtml

http://nmi.cs.wisc.edu/taxonomy/term/3?page=3

https://twiki.cern.ch/twiki/bin/view/ETICS/SA1VegaCollaboration

infso-ri-223782 etics local setup experiences a case study for installation at customers location...

Documents