Direct SA1 Links
Etics Portal - Etics Web - EticsAgendas - ETICS 2 SA1 Savannah - SA1Actions (in Savannah) , SA1 Internal

Collaboration with VEGA

Short Description of the Task

Deploying complete ETICS operational infrastructure at VEGA.

Useful Links

Requirements, Ideas, Constraints etc

Any requirement and from where it comes

• item
• item

Open Issues

• Network accessibility (proxy, firewall policies, etc.)

Current Firewall Restrictions at VEGA corporate Network, Status info:

! No opening of dynamical range of ports allowed from DMZ to Integration Network. 20 Ports for each WN are a minimum. ==> 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.

==> 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 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 decision is taken that VEGA uses ETICS as an official development tool.

GCB ???

Question: Are there any better (and more elegant) configuration alternatives which I might have overseen up to now?

Figure in attachment shows our actual setup: The etics server platform also hosts the condor master and submitter as well as the ETICS DB. The red point marks the problem.

• Support, "ownership" of ETICS after Feb'2010

Plans, Dates and Status

Week 41: Presentation to VEGA, collaborators

Status

Operational installation. Working on attaching more platfroms, registering users.

Future improvements

ToDo

• WN installation : Solaris v5.8(9) blocked due to firewall restrictions
• WN installation : WinXP

Done

• 20-May-2009: Completed installation
• 20-May-2009: Attaching SLC_4 ia32 platform
• 20-May-2009: initial setup of Solaris v5.8(9)
• Sept-2009: move from internal network, to DMZ, make accessible from outside
• Sept-2009: Implemented privacy patch
• 01-Oct-2009: SLES9 : done (32 bit platform)

Experiences during Setup of the system, as pesented during 4. AHM, Bologna

Two Servers: etics.vega.de: ConfigurationWS etics-rep.vega.de: RepositoryWS

can be called via: https://etics.vega.de (only for registered persons).

1. Scripts for nmi are packed in tgz format and are located under:

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

on the ConfigurationWS. 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.

Untar the scripts, perform a grep for cern and replace accordingly.

2. etics-client-setup.py is located under:

/var/www/html/archive on the repositoryWS:

and will be called via wget https://...

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 the changes automatically.

3. 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 the etics server@cern, 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.

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 is given. This has to be corrected. This is also true for every mail adressing etc.

Experiences after implementing the access filters from Lorenzo:

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:

do not point to any certificate 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.

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 always expected under /etc/grid-security) and inserted the userDN of the certificate of the WN in the user table and made it active. Now the WN can identify itself at the etics-server as an autorized user and the remote build passes.

Fazit: the deployment scripts for eticsWS and eticsRep are fairly portable, with some minore exceptions, however the etics client setup and the plugins need to be reviewed for being really system independent.

Firewall issues: Current Firewall Restrictions at VEGA corporate Network, Status info:

! No opening of dynamical range of ports allowed from DMZ to Integration Network. 20 Ports for each WN are a minimum. ==> 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.

==> 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 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 decision is taken that VEGA uses ETICS as an official development tool.

GCB ???

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 which I might have overseen up to now?

Figure in attachment shows our actual setup: The etics server platform also hosts the condor master and submitter as well as the ETICS DB. The red point marks the problem.