ARC stands for "Advanced Resource Connector" and is a Grid software developed by the NorduGrid collaboration. Except of developing ARC, the collaboration deals with such other things as the cross-Nordic Certificate Authority, coordination of usage of some Nordic computing resources, user support etc. NorduGrid is the name for the collaboration, and ARC is the software, so yes, there is a difference.
There are several ways to download ARC: directly from the ftp/http server, via apt/yum repositories, or as a source from the code repository. Please follow the instructions in the download area linked from the NorduGrid web page: http://download.nordugrid.org/
If you are an ordinary user, you can install either the client package together with the latest versions of globus and gpt. Or you could install the nordugrid-arc-standalone package which contains all you need as a user. For detailed information, consult the NorduGrid User Guide or the client installation instructions at http://www.nordugrid.org/documents/ng-client-install.html If you want to install a new site, consult the NorduGrid server-install document: http://www.nordugrid.org/documents/ng-server-install.html
The code repository details are available at http://svn.nordugrid.org There is an option to download the tarball of the repository, if you wish to get the whole code. Write-access to the repository is only available via https; for more information, consult http://www.nordugrid.org/middleware/svncheat.html
No, the standalone client expects certain non-grid specific system libraries and tools to be installed at your computer. Most notably, it needs a Linux distribution with the following libraries and utilities: glibc, bash, perl, libxml2, libltdl, libtool, autoconf, openssl
A certificate is nothing more than an electronic passport. It contains information about your name and other details, e.g., your e-mail address or location. Contents of the certificate is determined by the rules set up by your national certificating authority (CA), which issues certificates. Having a certificate does not authorize you to use any resources on the Grid or elsewhere, it only identifies that you are who you claim to be. It is used to establish contact between you and another service, so that instead of typing your name, you simply present your certificate. A service may reject it, if it is not in its list of acceptable certificates. The system is analogous to that of passports and national borders: for example, if you want to travel to USA, your country must be in the list of accepted ones, if you want to use your passport; otherwise you have to request a visa (which can be rejected). With computing resources, if you want to submit a job to a cluster, your CA must be in the list of those accepted by the cluster, and your certificate subject line must be in the list of accepted users on that cluster. To achieve it, you have to either contact each cluster owner upon receiving the certificate, or join a Virtual Organization, where manager can do it for you.
First you need to generate a certificate request (see 2.3). This should be sent to your Certificate Authority (CA), for Nordic countries (Denmark, Finland, Norway, Iceland or Sweden) residents it is ca@nordugrid.org. If the request is correct, the Certificate Authority will sign your request and send your certificate back to you.
Generate NorduGrid certificate request if you are a resident in a Nordic country (Denmark, Finland, Norway, Iceland or Sweden). Assuming your site administrator have already installed the nordugrid-arc-client software or you are working with the nordugrid-arc-standalone-client, it is very easy. Just type: grid-cert-request -int and answer the questions. Please note that some of the fields are not supposed to be changed. The grid-cert-request program will generate a certificate request for that should be sent to ca@nordugrid.org. Before sending please verify that the subject of your certificate request has the form /O=Grid/O=NorduGrid/OU=<your organization>/CN=<your name>/Email=<your email> and does not contain non-ASCII characters (e.g., national accented letters in Unicode, non-latin letters etc). If these criteria are not satisfied, please rerun the grid-cert-request command. Note that you cannot use the grid-cert-request command to request the NorduGrid certificate without the -int flag, as it causes failure.
The NorduGrid Certificate Authority (like any other such authority)
has credentials that have a limited lifetime. Once in a while they
have to be renewed and updated everywhere: on client machines, in Web
browsers, on Grid servers, on Web servers etc. Users' and host
certificates can not be valid longer than the CA credentials, and
hence all have to be updated as well. The steps are the following:
1. Get the latest public certificates at http://ca.nordugrid.org (section
"The NorduGrid CA public certificate").
-- Note: normally, the entire package is also available via NorduGrid
downloads area http://ftp.nordugrid.org/download (look for IGTF,
ca_NorduGrid) and yum repositories, and via IGTF site
http://eugridpma.org/distribution/igtf/.
2. Install these public CA certificates in /etc/grid-security/certificates,
and/or in /your-standalone-path/etc/certificates, and in your browser
and mailer (eventually you will have to remove the old, expired NorduGrid
CA certificates).
3. If you are a Grid site owner, you may need to restart grid services (esp.
the Web-services) in order to load the new certificates.
4. You must request new user and/or host certificates now, see section 2.3
If you are not a resident in a Nordic country (Denmark, Finland, Norway, Iceland or Sweden), you must ask your local certificating authority (CA) about the procedure. NorduGrid client installation has only necessary utilities, but is not distributed with all the national CA configuration files. Obtain from your CA the files globus-host-ssl.conf.xxxxxxxx globus-user-ssl.conf.xxxxxxxx grid-security.conf.xxxxxxxx (here xxxxxxxx depends on your national CA identity) and store them in the proper directory: /etc/grid-security/certificates or $NORDUGRID_LOCATION/etc/certificates if you have installed a standalone client. After doing this, type grid-cert-request -int -ca and answer the questions. Please note that some of the fields are not supposed to be changed. The grid-cert-request program will generate a certificate request for that should be sent to your CA by e-mail.
Most likely, you ran it without -int option. To request NorduGrid certificate, always execute grid-cert-request -int The reason is that NorduGrid certificates require e-mail field, while the Globus grid-cert-request utility by default only asks interactively for your names, and neither can ask for e-mail or guess it.
If you are using the nordugrid-arc-standalone package, please upgrade to the latest nordugrid-arc-standalone package. If not, it is probably because your site administrator has forgotten to install the NorduGrid certrequest package. Please ask him to do it. The package can be found at: http://download.nordugrid.org/certificate_authorities/certrequest-config/0.1/
Run: grid-cert-request -host <hostname> -dir `pwd` This will generate a host-certificate-request in the current directory.
There can be many reasons for this; as a rule of thumb check that: 1. Client has access to user's Certification Authority (CA) public certificates and server CA certificates 2. Server must have access to own CA certificates and user CA certificates 3. Permission and ownership of certificate and keys must be right (private keys readable only by the owner, public keys readable by all the relevant services) 4. Take special care when you are running an ARC service as non-root. Make sure that the certificate files have the right permissions and are owned not by root, but by the user specified by the "user" configuration parameter in the corresponding [gridftpd], [httpsd] blocks of arc.conf. 5. DNS reverse lookup on host must match 6. CRLs on the server must be up-to-date 7. Avoid running client commands from the root account on the same box that has the server installed: this may mix the order in which the certificates (user and host) are read 8. If all of the above is OK, suspect corruption of either user or host public certificate (or even both). Corruption is known to occasionally take place during public certificate transfers over the Internet
A Virtual Organization (VO) is basically a group of people that are authorized to run Grid jobs on a set of Grid resources. For example, a research project members can join in a VO, so that they can negotiate access to Grid resources, policies etc. Typically, a VO has a manager which maintains the list of members and contacts resource owners whenever a negotiation is needed, for example, if a new user has a certificate issued by a new CA, or CA public keys have changed. VO managers are normally in charge of negotiating resources available for the VO members. Each site on the Grid can subscribe to different VO's allowing all their members to run grid jobs on the corresponding site. NorduGrid maintains a VO for users affiliated with Nordic academic institutions (VO name is nordugrid.org). Few VOs are set up for the purposes of testing and demonstrations. Many other VOs are authorized on the ARC-enabled resources, but they are managed outside the scope of the NorduGrid. You can always create your own VO and negotiate access to Grid resources with resource owners personally. NorduGrid does not assist in such negotiations.
You must read and accept Accepted Usage Policies, and submit a request via the respective VO management interface. For more details, please consult http://www.nordugrid.org/NorduGridVO (follow the "Users and VOs" tab on the NorduGrid home page).
You miss the definition of the VOMS server details for your VO (atlas in this example). The simplest way is to add the necessary information to the file $HOME/.voms/vomses In case you use a gLite UI client, this file may be found in $HOME/.edg/vomses Consult your respective VO managers (follow "Configuration" link at most VOMS Web interfaces) to know what are your VO's VOMS server details. Examples of valid entries for the vomses file are: "alice" "lcg-voms.cern.ch" "15000" "/DC=ch/DC=cern/OU=computers/CN=lcg-voms.cern.ch" "alice" "cms" "lcg-voms.cern.ch" "15002" "/DC=ch/DC=cern/OU=computers/CN=lcg-voms.cern.ch" "cms" "atlas" "lcg-voms.cern.ch" "15001" "/DC=ch/DC=cern/OU=computers/CN=lcg-voms.cern.ch" "atlas" "gin.ggf.org" "kuiken.nikhef.nl" "15050" "/O=dutchgrid/O=hosts/OU=nikhef.nl/CN=kuiken.nikhef.nl" "gin.ggf.org" "pamela" "voms.cnaf.infn.it" "15013" "/C=IT/O=INFN/OU=Host/L=CNAF/CN=voms.cnaf.infn.it" "pamela"
Some software is already pre-installed. The procedure of installing and advertising the software on the Grid is referred to as "creating runtime environment". Most of the environments enabled across NorduGrid sites and their partners is described at http://gridrer.csc.fi/ A simple list of installed runtime environments can be retrieved with the help of the Monitor at http://www.nordugrid.org/monitor by either using the "Search" interface (select cluster, runtime environment), or by clicking any cluster name and then on the "Runtime environment" link. In case you don't find your favorite software in these lists, you'll have to negotiate with the resource owners. If your work is a part of a national or a regional Grid project, please contact your respective project coordinators. NorduGrid can not force resource owners to install your favorite software, but if you are desperate, e-mail the NorduGrid support and we can try to help you.
Use the runtimeenvironment attribute in your job description (.xrsl) file. For example, the line (runtimeenvironment=ROOT-4.0.1) will make your client submitting the jobs only to those sites that have this particular software version installed, and will instruct the remote site to set up all the necessary pathes and environment variables needed by this software. Please read the xRSL manual and the User Guide for more info on this attribute.
There could be several reasons for this. Try to submit the job again with debug information switched on ngsub -d 2 -f <your xrslfile> For each cluster, you can now see the reasons why your job was rejected. Please modify your xrsl-file according to this information. For example, if you see the message for all clusters: Queue rejected because it does not match the XRSL specification (disk) it is probably because you have requested too much disk(space) for the job. If all clusters report that you are not authorized to run there, it is probably because, you are not yet a member of VO (virtual organization). Please jump to section 4.2. If you see plenty of messages Server unexpectedly closed connection it most likely means your clock is out of sync. Make sure your workstation has clock properly synchronised, re-create the proxy, and try again. If it does not help, check Section 3 on authentication problems.
You have made a mistake in your xrsl-specification and the xrsl-parser in ngsub thus does not know what you want to do. Please consult the xRSL manual or the User Guide for the xrsl-notation.
Short answer: Yes, at the moment a shared disk area among the front end and the nodes is required. Long answer: The preferred installation (see Server side installation instructions) assumes that some disks (the grid area, the cache directory and the runtimeenvironment scripts) are NFS mounted on both the frontend and the nodes. Not having NFS results in losing functionality like the cache or the RuntimeEnvironments, furthermore the job submission backend of the Grid Manager needs to be modified.
In general the cache directory can be split into two subdirectories, a 'control' and a 'data' subdirectory. Due to some problems with file locking feature of NFS, it is strongly recommended that the 'control' subdirectory is placed at a local file system. 'data' subdirectory can be imported over NFS. To do that you can point "cachedata" variable in arc.conf to a directory that is NFS mounted and "cachedir" variable to the directory from a local file system.
There could be several reasons for this. Try to connect to the server and look for a hint in the log-file, /var/log/gridftpd.log. If the gridftp process somehow was started as non-root, it cannot read the host-certificates that are owned by root. Another thing is to check that the host-certificates have the right file-permissions. The private key should be readable by root only and neither should have executable permissions. The problem could also arise from an outdated CRL.
In our settings the Grid Index Information Service (GIIS) is an LDAP database backend which is used as a collection of links, it maintains a list of contact strings of local information databases (GRIS). The list (or index) of GRISes can be queried through an LDAP interface.
Probably not. You should only run a GIIS if you coordinate resources. At the moment the only coordination of resources is done on the country level and several GIIS's already exists. See the following section for a list of currently running GIIS's.
There could be several reasons for this. Assuming you have a valid host certificate you problem could be: - globus-mds was not started properly You need to start the globus-mds service. If your configuration is correct this results in a grid-info-soft-register process which periodically will start and ldapadd process. - You do not register to a GIIS. Here is a cluster registration unit appropriate for registering Danish clusters to the Grid: [mds/gris/registration/GrisToDenmark] regname="Denmark" reghn=grid.nbi.dk regperiod=30 # Try to register every 30 second servicename=nordugrid-cluster-name The list of country GIIS's can be found at: http://www.nordugrid.org/NorduGridMDS/index_service.html Note that you can do multiple registrations (eg. to several country GIIS's) by having more than one section of the above type. Note however that the section label should be different. Examples: [mds/gris/registration/GrisToSwedenLund] regname="Sweden" reghn=quark.hep.lu.se servicename=nordugrid-cluster-name [mds/gris/registration/GrisToSwedenUppsala] regname="Sweden" reghn=grid.tsl.uu.se servicename=nordugrid-cluster-name - You are not authorized to connect to a higher level GIIS. This could be a country GIIS or organization GIIS. The current GIIS hierarchy is: Cluster -> Country -> Top level To get your cluster or storage element authorized please contact the appropriate GIIS administrator, see http://www.nordugrid.org/NorduGridMDS/index_service.html - Your cluster is badly misconfigured. Try to run the Monitor in the debug mode to discover possible problems: http://www.nordugrid.org/monitor/?debug=2 -The machine's clock is not synchronized and badly off-time. Consider synchronizing your clock and using ntp. -Your machine is behind a firewall that blocks access from the monitor client. Ask NorduGrid support what is the current IP address of the monitor client.
The PURGED registration status of the resource to an index means that your resource is not registering any longer or the registration information is lost due to improperly set timeouts or local clock. You should check the GIIS registration block of the globus.conf file and synchronize your clock.