CERN frontier rpms: The frontier rpms are: squid rpm (installed at tiers 0,1,2): - frontier-squid frontier server rpms (installed at tier0 and some tier1's): - frontier-awstats - frontier-tomcat Remark: As of January 2012, production also uses rpm frontier-servlet. This rpm needs xml configuration file %prefix/tomcat/conf/Catalina/localhost/atlr.xml The following documentation refers to more new frontier rpm releases, starting from frontier-tomcat-6.0.33_3.29-1, where the functionality of frontier-servlet rpm has been merged into frontier-tomcat rpm, and hence frontier-servlet rpm is not used. Supported operating systems: The rpms are built on SL5, they have been tested on both SL5 and RHEL6. They are presumed to work on any RHEL6-derived operating system including SL6. What releases to install: In order to decide what releases of frontier rpms to install, consult the people in charge, via the following emails. Email addresses: frontier mailing lists: atlas: atlas-frontier-support@cern.ch cms: cms-frontier-support@cern.ch rpm builder: david.front@cern.ch Installing/upgrading rpm/s At quattor managed sites (CERN), update cdb to use the new rpm version. Otherwise, one may install/upgrade rpms via 'rpm' or 'yum': 1) Prerequisites: - The (configurable) frontier user to own rpm files (defaulting to dbfrontier or squid) should exist prior to rpm installation. - The frontier user should be allowed to run crontab, as explained further at: 5) crontab - If you are installing frontier rpms via a configuration manager (Quattor, or puppet, for example), take care to create the needed (configuration) files. - Ports: The firewall should allow incoming connections for services: frontier-tomcat: the port is (usually) 8080. frontier-squid: -- http_port may be controlled by customize.sh (following). It may be, for example, 8000 or 3128. -- Port 3401 may be used for snmp monitoring of squids - If you are installing frontier rpms, instead of existing non rpm (tarball) package/s: first uninstall the existing non rpm SW: -- Remove the existing directory in which the software was installed, -- and take care to remove/undo changes at other files that have been edited manually or by scripts. In particular, undo crontab (manual) changes. - Service upgrade: If a service to be upgraded (frontier-tomcat or frontier-squid) has a redundent/backup server, it is recommended to take the server out of service before upgrading. 2) Configuration: - Configuration files that may be edited by the user: rpm name applied at syntax install only ================ ======================= ============ ===================== frontier-squid /etc/squid/customize.sh awk frontier-squid /etc/squid/squidconf + export frontier-tomcat /etc/tomcat/tomcat.conf + export frontier-tomcat /etc/tomcat/servlets.passwd Microsoft Windows INI frontier-tomcat /etc/tomcat/servlets.conf Microsoft Windows INI frontier-awstats /etc/awstats/customize.sh export+'sed_conf' frontier-awstats /etc/awstats/password-file password - Avoiding using default directory /data for logs: -- Take care the preferred directory will be created before rpm installation. -- Replace /data by your preference, at the following rpm, file, records: frontier-tomcat: /etc/tomcat/tomcat.conf: export FRONTIER_TOMCAT_LOGS="/data/tomcat_logs" frontier-squid: /etc/awstats/customize.sh: setoptionparameter("cache_dir", 2, "/data/squid_cache") setoption("access_log", "/data/squid_logs/access.log awstats") setoption("cache_log", "/data/squid_logs/cache.log") setoption("pid_filename", "/data/squid_logs/squid.pid") setoption("coredump_dir", "/data/squid_cache") - Controlling the user and group to install at (default being: dbfrontier) -- This can be done for frontier-squid, by changing the following defaults at /etc/squid/squidconf: export FRONTIER_USER=dbfrontier export FRONTIER_GROUP=users -- If done for frontier-squid, frontier-awstats follows and automatically uses the same user and group -- This can be done for frontier-tomcat, by changing the following default at /etc/tomcat/tomcat.conf export FRONTIER_USER=dbfrontier 3) Install rpm/s: In case of errors at installation, consult: http://frontier.cern.ch/dist/rpms/frontierRpmInstallationError.txt In order to install frontier rpms, as user root, import the gpg public key once (per machine): rpm --import http://frontier.cern.ch/dist/rpms/cernFrontierGpgPublicKey *** Using the command 'rpm': To see what rpm releases exist: browse (under the rpm specific directories at) http://frontier.cern.ch/dist/rpms, (or: ssh frontier.cern.ch ls -lt /data/home/dbfrontier/dist/rpms) To install, as user root: rpm -Uvh [--prefix ] where 'rpm url' looks like: http://frontier.cern.ch/dist/rpms/{SRPM|RPMS}[/]/ Example of an rpm url: http://frontier.cern.ch/dist/rpms/RPMS/noarch/frontier-awstats-6.0-14.noarch.rpm Relocating an rpm: - The defaults of RPM_INSTALL_PREFIX are: frontier-squid: / frontier-awstats: / frontier-tomcat: /usr/share/frontier-tomcat - The frontier rpms are relocatable - Exception: frontier-tomcat rpm can not be relocated to /, currently. *** Or, using 'yum': In order to install cernFrontier rpms via yum, as user root, get cernFrontier repository file once (per machine): wget -O /etc/yum.repos.d/cern-frontier.repo http://frontier.cern.ch/dist/rpms/cern-frontier.repo Now you may use yum as usual, (but without relocation,) for example, as root: yum install package1 [package2] [...] yum upgrade package1 [package2] [...] 4) Testing: Verifying rpm files: In order to verify that the installed files of an rpm are correct, as root, the following command may be used: rpm -V For a simple test of tomcat and squid, using fnget.py, you may adjust and run commands like the following, from bash: wget -O /tmp/fnget.py http://frontier.cern.ch/dist/fnget.py chmod +x /tmp/fnget.py server=atlasfrontier1.cern.ch # Adjust this to your server servlet=atlr # Adjust this to you servlet port=8000 # To test tomcat. Adjust if needed /tmp/fnget.py --url='http://'${server}':'${port}'/'${servlet}'/Frontier' --sql="select 'TOMCAT_IS_HAPPY' from dual" --refresh-cache port=8080 # To test squid. Adjust if needed /tmp/fnget.py --url='http://'${server}':'${port}'/'${servlet}'/Frontier' --sql="select 'SQUID_IS_HAPPY' from dual" --refresh-cache If all went well, you should get x_IS_HAPPY records like the following: ... 'TOMCAT_IS_HAPPY' CHAR ... 'SQUID_IS_HAPPY' CHAR ... In order to verify that awstats works (for ATLAS and CERN, for example): # The following test may be used, with care: # Ensure that /data/squid_logs/access.log has some unprocessed data: # If this is not the case, one may add a few records from the log of another server. # Note that this is faking, but if done for a small amount (for example 100 lines), # this should not pose a problem. # One way to do this can be: sudo -u dbfrontier scp :/data/squid_logs/access.log /tmp # where may be atlasfrontier1 or atlasfrontier2 # Run as user dbfrontier: sudo -u dbfrontier bash # copy a small amount of records to the local log: head -100 /tmp/access.log>>/data/squid_logs/access.log # Run awstats: cd /etc/awstats ./run_awstats.sh /data/squid_logs/access.log # When finished, manually verify that fresh data appears at the web interface: # http://frontier.cern.ch/awstatsatlas.html 5) crontab: - Frontier rpms install various crontab activities periodically (logrotate logs and run awstats). - Requirement: If /etc/cron.allow and/or /etc/cron.deny exist at the machine where frontier rpms are installed, the frontier user must appear at the allow file and should not exist at the deny file, otherwise, the crontab activities that are installed by frontier rpms will not work. - Currently, it is the responsibility of the installer to take care of the above requirement. (Future rpm releases may do this automatically.) - In order to edit crontab after rpm installation, one may, as the user to be edited: 'crontab -e', and edit. However, this is not recommended, because at rpm removal (or upgrade), depending on the nature of the manual changes done, the manually edited records may be erased. - It is not recommended to manually edit the underlying files of the command crontab. Building frontier rpms. For this the sources SHOULD be checked out from git. 1) check out sources from git, into an "rpms" directory. For example with $HOME/rpms: #!/bin/sh export GITROOT=https://:@gitlab.cern.ch:8443/frontier dir=$HOME/rpms mkdir -p $dir cd $dir packages="doc frontier-awstats frontier-release frontier-squid frontier-squid3 frontier-squid4 frontier-tomcat scripts" for package in $packages; do git clone $GITROOT/rpms/$package.git done 2) Build an rpm: cd $HOME/rpms/ pushd ./scripts; ../../scripts/rpmbuild_.sh; popd Details about rpmbuild_.sh: This script creates a .rpmmacros file and source tarball(s): - It creates a .rpmmacros file, at $HOME/rpms//scripts. - Source tarball(s) at $HOME/rpms//SOURCES: -- For all rpms, at $HOME/rpms//src: tar --exclude=.git -zhcf ../SOURCES/.tar.gz * -- For frontier-squid rpm, also creates the following tar: wget "http://frontier.cern.ch/dist/${Name}-${Version}-${release4source}.tar.gz" 3) Copy rpm to the web: cd $HOME/rpms/ pushd ./scripts; ../../scripts/rpm2web.sh ; popd (to copy an rpm to the web debug dir: http://frontier.cern.ch/dist/rpms/debug/ : pushd ./scripts; ../../scripts/rpm2web.sh /data/home/dbfrontier/dist/rpms/debug; popd) 4) Rebuild an rpm from a source rpm: Prerequisite: directoryToBuildAt should have the following directories: BUILD SOURCES SPECS RPMS SRPMS rpmbuild --rebuild --define "_topdir " Example: rpmbuild --rebuild --define "_topdir /tmp/testrpmrebuild" /data/dfront/rpms/frontier-tomcat/SRPMS/frontier-tomcat-6.0.35_3.29-11.src.rpm README files: - This file, _README is common for all cernFrontier rpms - In addition, each rpm has its own README file (example: frontier-awstatsREADME) (The rpm specific READMEs may appear at the end of this document.) - Other README files appear at frontier-squid rpm Related urls: - This document: To see when this document has been updated, and in order to see earlier versions of this document: https://gitlab.cern.ch/frontier/rpms/doc/raw/master/_README - Known issues with frontier rpms: http://frontier.cern.ch/dist/rpms/knownIssues.txt - Handling installation errors: http://frontier.cern.ch/dist/rpms/frontierRpmInstallationError.txt - The main url of frontier: http://frontier.cern.ch/ - Current frontier rpms: http://frontier.cern.ch/dist/rpms/ - To browse git files of frontier rpms: https://gitlab.cern.ch/frontier/rpms - To clone a frontier rpms git directory (example: frontier-tomcat): git clone https://:@gitlab.cern.ch:8443/frontier/rpms/frontier-tomcat.git - Atlas frontier documentation by John Destefano: https://www.racf.bnl.gov/docs/services/frontier/ - Obsoleted: Documentation of pevious frontier rpms, by Flavia Donno: squid: https://twiki.cern.ch/twiki/bin/view/PDBService/SquidRPMsTier1andTier2 tomcat, awstats: https://twiki.cern.ch/twiki/bin/view/LCG/WLCGFrontier rpms: http://grid-deployment.web.cern.ch/grid-deployment/flavia Per frontier rpm specific notes: :::::::::::::: ./frontier-awstats :::::::::::::: Configuration files, to be edited before or after rpm installation: 1) Required: /etc/awstats/password-file File for rsync with the password of user $SITE$PROJ (Example: cernatlas). The contents of the password-file should be shared privately with Dave (or whoever will be adding new sites), so that the site can be added for monitoring on the remote side. The file should be owned by the package/installation owner (e.g., dbfrontier) and be non-readable by others (chown 0600 password-file). awstatsSiteProjectNodesMapping A central mapping from site-project to 'DNS alias' and 'awstats name' is used in order to enable any node that reports awstats data to find its site-project and 'awstats name', via its 'DNS alias'. In order for this to work correctly, the following file should be edited accordingly when new nodes to report to awstats are added: frontier:/home/dbfrontier/dist/rpms/awstatsSiteProjectNodesMapping The mapping appears on the web as: http://frontier.cern.ch/dist/rpms/awstatsSiteProjectNodesMapping :::::::::::::: ./frontier-squid :::::::::::::: For installation instructions see https://twiki.cern.ch/twiki/bin/view/Frontier/InstallSquid :::::::::::::: ./frontier-tomcat :::::::::::::: Prerequisite: In addition to installing frontier-tomcat rpm, the installer should supply the following files, in order to use frontier-tomcat server: 1) /etc/tomcat/servlets.passwd The file should be owned by frontier user (dbfrontier) and it should have mode 400: read access to the frontier user only. Further related explanations follow. 2) /etc/tomcat/servlets.conf The default ${RPM_INSTALL_PREFIX} is /usr/share/frontier-tomcat Meta configuration files: In order to configure servlets, 3 meta configuration files are used at tomcat start, to create the following configuration files, per each servlet: - ${RPM_INSTALL_PREFIX}/tomcat/conf/Catalina/localhost/.xml - ${RPM_INSTALL_PREFIX}/tomcat/webapps//WEB-INF/classes/config.properties - ${RPM_INSTALL_PREFIX}/tomcat/webapps//WEB-INF/web.xml Generally, the syntax of the meta configuration files is: A set of sections, each with key value pairs, one per line like: # [
] : : ... After editing meta configuration files, in order to apply meta configuration changes, fromtier-tomcat service should be restarted. The meta confguration files are: 1) File: /etc/tomcat/servlets.conf This file is not managed by the (public) rpm, because there are no default values that are good for all. The installer must take care that this file will exist in order to use frontier-tomcat. (At rpm upgrade/uninstall, this file is not changed.) Syntax of the file: - The file must have a [servlet] section per servlet. Example: [atlr] - A 'username' key (for the DB user name) must exist per servlet. - defaults: The file may have a [defaults] section. Per servlet, these entries are applied before the per servlet entries. Hence, defaults entries may be overriden at per servlet section. - Generlly, this file may look like: [defaults] : ... [] username: : ... [] username: : ... - Following is a example of a /etc/tomcat/servlets.conf for ATLAS. # [defaults]: variables that apply to each servlet. Servlets may override them [defaults] # For tomcat/conf/Catalina/localhost/.xml maxDbConnections: 20 # For WEB-INF/classes/config.properties LongCacheExpireSeconds: 3000 ShortCacheExpireSeconds: 3000 ValidateLastModifiedSeconds: 300 LastModifiedTableName: ATLAS_FRONTIER_TRACKMOD.LAST_MODIFIED MaxDbExecuteSeconds: 60 MaxDbAcquireSeconds: 300 MaxThreads: 500 # [atlr]: servlet atlr (the default one and only servlet that ATLAS uses) [atlr] # For tomcat/conf/Catalina/localhost/.xml username: ATLAS_FRONTIER_READER tnsName: atlas_frontier - tnsName The tnsName refers to an entry at a tnsnames.ora file. (As explained at http://www.orafaq.com/wiki/Tnsnames.ora,) TNSNAMES.ORA is an Oracle SQL*Net configuration file that defines databases addresses for establishing connections to them. This file is managed by Oracle administrators and normally resides in the ORACLE HOME\NETWORK\ADMIN directory, at CERN: /etc/tnsnames.ora. The following connection definition template (more or less) is used at CERN and BNL: [frontier_servlet_name] = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = [oracle_host])(PORT = [oracle_port])) ... (ADDRESS = ... ) (LOAD_BALANCE = on) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = [oracle_listener_service_name]) ) ) ) Examples of Oracle database connections for frontier at CERN and BNL: ATLR = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = atlr1-v.cern.ch)(PORT = 10121)) (ADDRESS = (PROTOCOL = TCP)(HOST = atlr2-v.cern.ch)(PORT = 10121)) (ADDRESS = (PROTOCOL = TCP)(HOST = atlr3-v.cern.ch)(PORT = 10121)) (ENABLE=BROKEN) (LOAD_BALANCE = on) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = atlr.cern.ch) (FAILOVER_MODE = (TYPE = SELECT)(METHOD = BASIC)(RETRIES = 200)(DELAY = 15)) ) ) frontieratbnl = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = voracluster01.usatlas.bnl.gov)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = voracluster02.usatlas.bnl.gov)(PORT = 1521)) (LOAD_BALANCE = yes) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = bnlfrontier.bnl.gov) ) ) ) 'useCopyOfTnsnames': In order to prevent tomcat failure in case of a wrong change to the DB connection of the servlet/s at /etc/tnsnames.ora, a copy of DB connection may be used by the servlets rather than tnsnames.ora. After the DB connection changes at tnsnames.ora, (at the next 9AM) an email is sent to the administrator/s asking to approve and MANUALLY apply the change to the copy of tnsnames.ora that the rpm uses. Remark: The rpm is not responsible for sending the email: The rpm installs a crontab script that writes the related text, and it is assumed that each write causes an email to be sent to the administrator/s. This is true for CERN, and may not be applicable to other sites. In order to use the useCopyOfTnsnames feature there should be a record at the [defaults] section of /etc/tomcat/servlets.conf like: useCopyOfTnsnames: After the record exists, fontier-tomcat service should be restarted in order to activate the feature. At first activation, an initial copy of the tnsnames.ora is kept automatically. In order to deactivate, remove the record and restart. Technical detail, not in use currently: Using a shortcut instead of an entry at tnsnames.ora: As of Oracle 11G, there is another possibility to define a tnsName: Rather than pointing to an entry at tnsnames.ora, this variable may be a shortcut that contains a round-robin of the DB servers, the port number and the service name, for example: tnsName: atlr-scan.cern.ch:10121/atlr.cern.ch However, this practice is not recommended, because it does not imply the option ENABLE=BROKEN which is needed in order to detect when a different DB node has taken over for a failed node. 2) File: /etc/tomcat/servlets.passwd This file is not managed by the (public) rpm, because it contains secrets. The installer must take care that this file will exist in order to use frontier-tomcat. (At rpm upgrade/uninstall, this file is not changed.) Syntax of the file: - Each servlet 'username' value must have a section with a 'password' key, as: [] password: [] password: ... Per password, the recommended key is its 'tnsName' from servlets.conf Example (for ATLAS): [atlas_frontier] password: In order to backward compatible with earler releases, the key may as well be its 'username' from servlets.conf Example (for ATLAS): [ATLAS_FRONTIER_READER] password: 3) File: ${RPM_INSTALL_PREFIX}/servlets.confConstants The user should NOT edit this file. Variables that appear at this file should not be repeated at /etc/tomcat/servlets.conf. Otherwise, an error message will appear, and tomcat will fail to start. The constants are: [constants] maxWait: -1 logAbandoned: true removeAbandoned: true removeAbandonedTimeout: 300 minEvictableIdleTimeMillis: 60000 timeBetweenEvictionRunsMillis: 20000 Licensing: frontier-tomcat rpm uses Oracle Database 10g Release 2 JDBC Drivers. You must accept the OTN Development and Distribution License Agreement to download this software, as detailed at Oracle Technology Network Development and Distribution License Terms: http://www.oracle.com/technetwork/licenses/distribution-license-152002.html Remark: The 'Requires: jdk >= 1.6.0' line at the spec is temporarily commented out, in order to test without this package.