1. INFSO-RI-223782 ETICS Local Setup Experiences A Case Study for Installation at Customers Location 4th. All Hands MeetingUwe Müller-Wilm VEGA Bologna, Nov. 2009

2. INFSO-RI-223782 2 Bologna, Nov. 2009Local SetUp Experiences VEGA's Sandbox: 2 Servers: etics.vega.de: ConfigurationWS etics-rep.vega.de: RepositoryWS, both based on SL4 CERN templates 2 Worker nodes: SL4 (CERN template), SLES9: custom made, integrates ESOC patches Works on: VMWare ESX Server Customisation: Access restriction https://etics.vega.de

3. INFSO-RI-223782 3 Bologna, Nov. 2009Local SetUp Experiences

4. INFSO-RI-223782 4 Bologna, Nov. 2009Local SetUp Experiences 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 5 Bologna, Nov. 2009Local SetUp Experiences 2. NMI Scripts 1. 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 6 Bologna, Nov. 2009Local SetUp Experiences 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/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.

7. INFSO-RI-223782 7 Bologna, Nov. 2009Local SetUp Experiences 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 8 Bologna, Nov. 2009Local SetUp Experiences 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 etics@cern.ch is given. This has to be corrected. This is also true for every mail adressing etics.cern.ch etc.

9. INFSO-RI-223782 9 Bologna, Nov. 2009Local SetUp Experiences 6. ETICS Access Filter The Access filter restricts all access to the ETICS server to those users which 1.have a valid certificate and 2.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 certificate 2.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 10 Bologna, Nov. 2009Local SetUp Experiences 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 11 Bologna, Nov. 2009Local SetUp Experiences 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 12 Bologna, Nov. 2009Local SetUp Experiences 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 13 Bologna, Nov. 2009Local SetUp Experiences

14. INFSO-RI-223782 14 Bologna, Nov. 2009Local SetUp Experiences Consequences This 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 15 Bologna, Nov. 2009Local SetUp Experiences Topics to Discuss Usage of Generic Connection Brokering (GCB)? 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 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