Ten Step Guide to Porting the gLite WN

Step 1: Installing ETICS locally and registering your machine

• Install the ETICS client on your build machine. Follow the guide: http://etics.web.cern.ch/etics/services/service_getting_started.html or just do the following:

1. Download the client and run the python script as described on: https://twiki.cern.ch/twiki/bin/view/ETICS/ClientHowTo
2. Download hawkeye: http://eticssoft.web.cern.ch/eticssoft/internal/public/config/org.etics.condor.config/boot/hawkeye_modules.tgz, untar it and run nmi_platform.
3. Run:

   etics-list-platform --detect

4. Send the results of points 2 and 3 above to etics-support@cernNOSPAMPLEASE.ch to have your machine type registered.

• Reinstall the ETICS client and you should now see that your machine type may or may not be described in $ETICS_HOME/etc/packageTypes.xml. It is possible that it will show your artefact types, e.g: tarballs, rpm or debs. If your platform isn't shown, please contact etics-support@cernNOSPAMPLEASE.ch.

Caveats

• If using Python 2.4 and proxies you will have intermittent wget and urllib2 issues (upgrade to Python 2.5).
• If your using x86_64 etics-client-setup may not install cleanly. Please report all issues to etics-support@cernNOSPAMPLEASE.ch or post a bug report in savannah.cern.ch. Most issues relate to finding /usr/lib instead of /usr/lib64 libraries.
• The etics-client-setup installs and depends on PyXML, 4Suite, ZSI, psyco, and pyOpenSSL. If any of these don't install properly, please report any fixes to the developers. Currently there are known to be issues under AIX (PPC) and Solaris (x86). Alternatively download each tarball and attempt to build them under your OS. Please report any issues to the developer or Eamonn.Kenny@csNOSPAMPLEASE.tcd.ie and post a bug report in the ETICS savannah.
• After first building any software from source, check the contents of the ./dist directory in your current ETICS workspace for generated tarballs. If you find nothing, then there is a problem with the ETICS client or the packageTypes.xml contains a typo. It may be prudent to delve into the ETICS client code, in particular looking at etics/lib/python2./site-packages/ModuleBuilder.py to debug the issues.

Step 2: Build VDT 1.10.*

Building from binary already uploaded to AFS

etics-checkout --ignorelocking --continueonerror --noask --config vdt v. 1.10.1-1 vdt
etics-build --continueonerror  vdt
   

Building from a binary tarball already available from Pacman

• See if your platform is available on http://vdt.cs.wisc.edu/releases/x.y.z/contents.html where x.y.z=1.10.0 in the glite-WN-3.1.0 or x.y.z=1.10.1 in the latest stable release.
• If your platform is available then see if it already exists in: http://eticssoft.web.cern.ch/eticssoft/repository/externals/globus/
• If it doesn't exist but matches an existing release then contact etics-support@cernNOSPAMPLEASE.ch or Eamonn.Kenny@csNOSPAMPLEASE.tcd.ie to have the link created for you.
• If the tarball is not in ETICS you will have to create a tarball using pacman on your build machine:

     1. download pacman: http://vdt.cs.wisc.edu/releases/1.10.1/installation_pacman.html
     2. Untar it and run:  source setup.sh; mkdir /opt/vdt ; cd /opt/vdt
     3. pacman -http_proxy http://some-proxy.at.your.site:portnumber/                        if you are using proxies
     4. pacman -get http://vdt.cs.wisc.edu/vdt_181_cache:Globus
     5. pacman -get http://vdt.cs.wisc.edu/vdt_181_cache:Globus-Base-SDK
     6. pacman -get http://vdt.cs.wisc.edu/vdt_181_cache:UberFTP
     7. pacman -get http://vdt.cs.wisc.edu/vdt_181_cache:MyProxy
     8. pacman -get http://vdt.cs.wisc.edu/vdt_181_cache:GSIOpenSSH
     9. tar -C /opt/vdt/globus -czf globus-4.0.7-VDT-1.10.1-1.tar.gz .

• do something similar for VDT 1.10.1 except that you should use vdt_161_cache and generate globus-4.0.7-VDT-1.10.1-1.tar.gz.
• After creating your appropriate globus VDT put it on a webserver and give the link to etics-support@cernNOSPAMPLEASE.ch or Eamonn.Kenny@csNOSPAMPLEASE.tcd.ie

Building from source from VDT

• You must follow the porting instructions for your architecture as described in: http://www.globus.org/toolkit/docs/4.0/ (in particular the Platform Notes on this page) or http://www.globus.org/toolkit/docs/4.0/admin/docbook/ch03.html#s-platform.
• The default description is now inserted into the ETICS database for configuration "globus v. 4.0.7-VDT-1.10.1-1src" which excludes iodbc and gsiopenssh.
• The version control system VCS is set to download the correct version using wget http://vdt.cs.wisc.edu/software/${moduleName}/${version}/${packageName}-patched-source.tar.gz
• Therefore it will be possible to clone the configuration without ever having to import the VDT source code into AFS. This is a very desirable feature to speed up porting.
• however it is very likely that a number of patches will have to be required to make the globus software portable. In the future it might be a good idea to create a globus-patches configuration that is defined as a dependency of globus. More details will follow on this if implemented.
• Within ETICS there is now a default rule for building "globus v. 4.0.7-VDT-1.10.1-1_src" using the following:

  etics-checkout --ignorelocking --continueonerror --noask --config vdt v. 1.10.1-1_src vdt
  etics-build --continueonerror  vdt
     

Reporting Issues

• report any issues you find to vdt-support@opensciencegridNOSPAMPLEASE.org or/and to Eamonn.Kenny@csNOSPAMPLEASE.tcd.ie

Step 3: Register your packages that differ for your OS

• Below is an example of the differences between SLC 4, OpenSuSE 10.3 and SLC/!CentOS 5.

  Package Name	Default Version	OpenSuSE 10.3	SLC/!CentOS 5.0	Debian 4 (x86)	Debian 4 (x86_64)	Removed Install Directory	Includes package
  boost	1.32.0-1.rhel4	1.33.1-108	1.33.1-18	1.33.1-10	1.33.1-10	/usr	a number of libboost* (Debian)
  cppunit	1.10.2	1.12.0-19	1.12.0-3.el5.rf	1.12.0-1	.	/usr	libcppunit (Debian, OpenSuSE)
  db4	4.2.52-7	4.3.29-59	4.3.29-9	4.4.20-8	4.2-4.2.52+dfsg-2	/usr	libdb4.2 (Debian x86_64), libdb4.4 (Debian x86), db43 (OpenSuSE)
  docbook-utils-pdf	0.6.16-4	0.6.14-143	0.6.14-5.1	0.6.14-1	0.6.14-1	/usr	docbook-utils (Debian/!SuSE)
  expat	1.95.7-4	2.0.1-24	1.95.8-8.2.1	1.95.8-3.4	1.95.8-3.4	/usr	expat-devel, libexpat1, libexpat1-dev (Debian)
  glib2-devel	2.4.7	2.14.1-4	2.12.3-2	2.12.4-2	2.12.4-2	/usr	libglib2.0-dev (Debian)
  httpd	2.0.52	2.2.4-70	2.2.3-7	2.2.3-4+etch4	2.2.3-4+etch4	/usr	apache-prefork-dev (Debian), apache2 (SuSE)
  httpd-devel	2.0.52	2.2.4-70	2.2.3-7	2.2.3-4+etch4	2.2.3-4+etch4	/usr	apache2-prefork-dev, libapr1-dev, libaprutil1-dev, libpcre3-dev (Debian), apache2-devel (SuSE) httpd-devel, apr-devel, apr-util-devel, pcre-devel (SL5)
  mysql	4.0.20	5.0.45-22	5.0.22-2.1.0.1	.	5.0.32-7etch1	/usr	mysql-server (Debian)
  mysql-client	4.0.20	5.0.45-22	5.0.22-2.1.0.1	.	5.0.32-7etch1	/usr	libmysqlclient15 (OpenSuSE)
  mysql-devel	4.0.20	5.0.45-22	5.0.22-2.1.0.1	.	5.0.32-7etch1	/usr	libmysqlclient15-dev (Debian), libmysqlclient-devel (OpenSuSE)
  swig	1.3.21-6	1.3.31-50	1.3.29-2.el5	1.3.29-2.1	1.3.29-2.1	/usr
  zlib	1.2.1	1.2.3-75	1.2.3-3	1.2.3-13	1.2.3-13	/usr	zlib1g (Debian)

• Overrides for glite_branch_3_1_0 will need to be generated for each of your packages so that ETICS doesn't build the SLC 3 or 4 version by default. Please report your override versions for your OS to Eamonn.Kenny@csNOSPAMPLEASE.tcd.ie or etics-support@cernNOSPAMPLEASE.ch.
• You must send a tarball version of the packages to Eamonn.Kenny@csNOSPAMPLEASE.tcd.ie or etics-support@cernNOSPAMPLEASE.ch (better to post them to a local webserver for pickup). Without these tarballs you will never build VOMS correctly and hence will not be able to build the WMS.
• If you need a python script that automatically generates tarballs with the correct versioning of the form x.y.z-r (from an RPM) removing the lead directories such as /usr or /opt from the software, use tarball-creator.py. This script was recently adapted for debs packages and tested under Mac OS X, so please report any bugs that it might still contain.

Examples of how to package dependencies

• Under Debian 4 to package up expat, libexpat1 and libexpat1-dev together for AFS (removing /usr the install directory of expat) do the following:

     ./tarball-creator.py --name="libexpat" --contains="libexpat,libexpat-dev" --dir=/usr --packager=debs --age
     

• Under Debian 4 to package up all libboost modules (removing /usr the install directory of libboost*) using the following:

     ./tarball-creator.py --name="boost" --search="libboost" --dir=/usr --packager=debs --age
     

• Under Debian 4 to package up the httpd-devel tarball contains the apache2, apr and pcre development packages do the following:

     ./tarball-creator.py --name="apache2-prefork-dev" --contains="apache2-prefork-dev,libapr1-dev,libaprutil1-dev,libpcre3-dev" --dir=/usr --packager=debs --age
     

• Under SL5 to package up the httpd-devel tarball contains the apache2, apr and pcre development packages do the following:

     ./tarball-creator.py --name="httpd-devel" --contains="httpd-devel,apr-devel,apr-util-devel,pcre-devel" --dir=/usr --age
     

• Note that when using a package name that doesn't actually exist as a package in the system, the package version will be deduced by the first package found by the regular expression match or by the first comma separated item passed to the contains flag.

Step 4: Building external dependencies

This section has recently changed to reflect a better way of testing that the external dependencies build correctly for a new platform:

• All externals should be built within the org.glite branch glite_branch_3_1_0_dev, not using the project externals
• No component should be checked out with the --checkout flag. The reason for this is two-fold:

1. We immediately know whether the .DEFAULT flag is set in glite_branch_3_1_0_dev.
2. We have a way to define a checkout script that will transfer to any new platform.

Unlocked Build Rules

etics-checkout	etics-build	complete build
externals-checkout.sh	externals-build.sh	externals-full.sh

Caveats

If one or more of the components don't build, this is due to one of the following problems:

1. Your component has no tarball in AFS. Check this by looking at: http://eticssoft.web.cern.ch/eticssoft/repository/externals/componentName/configurationNumber/platformName.
2. There is no configuration for your module. Use "etics-list-configuration " to check this whether it exists, or look on the ETICS web interface for your entry.
3. The .DEFAULT override is not set for your platform. This is seen by an attempt to check out an older version of the component. An example of this, is an attempt by the etics-build to wget swig-1.3.21.tar.gz instead of a newer version because swig.DEFAULT has not been set correctly for the new platform you want to include.
4. You component name is different than the package name, which requires a special property to be set by the ETICS team of the for "packageName: myComponentName". An example of this is mysql-devel having package name libmysqlclient15-devel under Debian.

Step 5: Build a minimal set of modules

• The idea here is to obtain a small set of modules that will enable edg/glite-job-submit to run on the worker node. For this, edg-gridftp-client, yaim and a few other modules must be built.

Unlocked Build Rules

etics-checkout	etics-build	complete build
Basic-checkout.sh	Basic-build.sh	Basic-full.sh

Step 6: Build RGMA

• log4cxx has been removed from RGMA recently, making it much more portable. There are currently 41 packages in all in version R_5_0_81_1.

Unlocked Build Rules

etics-checkout	etics-build	complete build
RGMA-checkout.sh	RGMA-build.sh	RGMA-full.sh

RGMA Patches

Patch File / Sed Replace	Description	OS applicability
org.glite.rgma.api-cpp-primaryProducerImpl.h.patch	org.glite.rgma.api-cpp patch	plat_arch_gcc4xy (gcc-4 compiler)
org.glite-targets-common_20070703.patch	glite Packager issue: org.glite/targets-common.xml patch	SuSE/Debian
org.glite.rgma.api-c	SSL patch	Systems with OpenSSL >= 0.9.8
sedPatcher.py --file="*.spec" --search="Copyright:" --compare="Copyright:" --equals --replace="s/^Copyright:/License:/"	RPM issues: Replace Copyright with License	Newer OSes: CentOS 5, Debian 4
sedPatcher.py --file="*.spec*" --search="%build" --offset="1" --compare="" --equals="True" --replace="s/^%build/#%build/"	comment out %build if followed by a blank line	SuSE
sedPatcher.py --file="targets-common.xml*" --search="os.arch" --compare="os.arch" --replace="s/\${os.arch}/i586/"	architecture setting wrongly set to i386	SuSE
sedPatcher.py --file="store.xml" --search="i386" --compare="i386" --replace="s/i386/i586/"	architecture setting wrongly set to i386	SuSE

• See XML patch description for full details: http://grid.ie/autobuild/patches/patches.xml

Step 7: Build VOMS

• VOMS must be built do that LCG-DM/GFAL can be built. The sample scripts are shown below.

VOMS Patches

Sed Replace	Description	OS applicability
sedPatcher.py --path="org.glite.security.voms" --file="Makefile*" --search="PDF_HYPERLINK" --compare="YES" --replace="s/PDF_HYPERLINK\(.*\)YES/PDF_HYPERLINK\1NO/"	VOMS documentation issue: PDF hyperlinks terminates build without a report since run in batch mode	SuSE

• See XML patch description for full details: http://grid.ie/autobuild/patches/patches.xml

Unlocked Build Rules

etics-checkout	etics-build	complete build
VOMS-checkout.sh	VOMS-build.sh	VOMS-full.sh

Caveats

• Under different OSes you may not realise that some variant of: docbook-style-xsl is required, resulting in missing documentation and broken builds.

Step 8: Build LCG-DM/GFAL

• LCG-DM the main data management software is written in C/C++ and requires Oracle/MySQL for your system. If you have not site license for Oracle the define PROC_INIT to be an empty string to unset the pro*C compiler location used in CERNs AFS. This will deactivate the Oracle requirement and prevent LFC-oracle and DPM-oracle from being built.

Unlocked Build Rules

etics-checkout	etics-build	complete build
DM-checkout.sh	DM-build.sh	DM-full.sh

• GFAL requires both LCG-DM and VOMS to be buildable.

etics-checkout	etics-build	complete build
GFAL-checkout.sh	GFAL-build.sh	GFAL-full.sh

LCG-DM patches

Command Line Patch / Sed Patch	Description	OS applicability
cp LCG-DM/config/slc4.spec.requires LCG-DM/config/centos4.spec.requires	Copy configurations for SPEC files	CentOS 4
cp LCG-DM/config/sl5.spec.requires LCG-DM/config/centos5.spec.requires	Copy configurations for SPEC files	CentOS 5
sedPatcher.py --file="Makefile.etics" --search="PROC_INIT" --compare="PROC_INIT" --replace="s/^PROC_INIT/#PROC_INIT/"	Remove Oracle Packages for LFC/DPM from build	All sites without Oracle
sedPatcher.py --file="*.spec.template" --path="org.glite.data.gfal" --search="libldap.so.2" --compare="libldap.so.2" --replace="s/libldap.so.2/openldap2 > 2.0.46/"	GFAL requires openldap2 under different OSes	SuSE

Step 9: Building the Workernode or user-interface clients

• Currently the method for building the workernode is to build the component/meta-package glite-WN/glite-UI from branch glite_branch_3_1_0_dev.
• The org.glite branch glite_branch_3_1_0_dev is associated with this branch at the top of the hierarchy.
• Any properties required to define external dependencies must be associated with the properties section of glite_branch_3_1_0_dev, which are then propagated down to the component and meta-package level.
• each sub-system/component that is fixed will be added to glite_branch_3_1_0_dev as a development branch by the JRA1 developers. If you do not insert bug reports into Savannah, you will never see your fixes in the development branch, so it is important that all bugs found are submitted to http://savannah.cern.ch/ at:

  Project Name	Bug Type	Savannah Page
  JRA1	Source Code Bug	https://savannah.cern.ch/projects/jra1mdw/
  SA3	Integration Issue/Configuration Issue	https://savannah.cern.ch/projects/sa3-coordination/
  ETICS	Build System Bugs	https://savannah.cern.ch/projects/etics/

Other Relevant Patches: WMS/LB

Sed Patch / Patch File	Description	OS applicability
sedPatcher.py --path="org.glite.lb.common" --file="Makefile" --search="mkdir" --compare="mkdir" --replace="s#mkdir ${REPORTS}#mkdir -p ${REPORTS}#"	Directory Generation Error	SuSE
org.glite.wms-utils.classad-cassert_20070727.patch	cassert fix	plat_arch_gcc4xy (gcc-4 compiler)
org.glite.wms.common-dqblk_20070802.patch	disk quota block allocation different under some OSes	SuSE (possibly Mac OS X)

Step 10: Packing the Workernode

• The contents of the glite-WN-3.1.0 Worker node is specified at any one time for certification, pre-production (PPS) and production by the glite-release lists of SA3, found at:

     cvs -d :pserver:anonymous@glite.cvs.cern.ch:/cvs/glite  co  glite-release 
     

• It is important to note that these scripts do not generate apt or old yum repositories (only createrepo yum). Some of the lines of code are contained in glite-release/scripts/generate-yum-repository for genbasedir but are commented out. Contact Eamonn.Kenny@csNOSPAMPLEASE.tcd.ie for apt/old yum support.
• An example of how to generate a repository on your webserver is given by:

     ./glite-release/scripts/create-rpm-repository -l glite-release/prod-lists/glite-WN -p "SuSE9_ia32_gcc335" -v 3.1.0-6_suse -d /var/www/distribution/glite/R3.1/glite-WN/suse9/i586 -e /var/www/distribution/glite-3.1.0 -n release 
     

• In the above example the production list glite-WN is interrogated by check-etics-repository looking for artefacts of type RPM, searching for each artefact in /var/www/distribution/glite-3.1.0 and producing the yum/apt repository in a directory structure similar to the repository layout used by CERN. For release R3.1 there will exist different nodes. Each node will contain different OS versions of the worker node for different architectures.

-- EamonnKenny - 05 Oct 2007. Last revised 30 May 2008