-
Notifications
You must be signed in to change notification settings - Fork 20
ESGFNode|IDP|FAQ
| Wiki Reorganisation |
|---|
| This page has been classified for reorganisation. It has been given the category MOVE. |
| The content of this page will be revised and moved to one or more other pages in the new wiki structure. |
localhost.localdomain?)
mmm.... probably not, there are a lot of difficulties I run into for attempting such a thing.
just give yourself a name (for testing) by calling hostname myname.mydomain and updating the /etc/hosts file to include this. For Example:
...
my.ip.goes.here myname.mydomain
127.0.0.1 myname.mydomain localhost.localdomain
...
This will solve at least some issues arising probably with the new security infrastructure.
Well... that still gives me the chills... The password for the dbuser is expected to be the same as the one of the postgres user.
If not, you have to provide it prior to calling the esg-gway script through
the pg_sys_acct_passwd variable... what might confuse the installer In any
case make sure that the /etc/pam_pgsql.conf file contains the proper
password (this sets up the PAM configuration for myproxy)
But for the time being, better use the same password for both of them.
If you can't visit the page http://localhost/esgf-node-manager/
then check that everything under /usr/local/tomcat is owned by user tomcat.tomcat . Try the following:
# esg-node stop
# chown -R tomcat.tomcat /usr/local/tomcat
# esg-node start
(server perspective)
Be sure to also check out this section if your answer is not resolved here:
General FAQ MyProxy section (client-side)
For the default installation its: /usr/local/globus/sbin/myproxy-server
You cannot debug a running server, but you may run a parallel instance of it without having to shut down the running one. This will start a new instance at port 7777, just remember to use that port for debugging purposes.
myproxy-server -p 7777 -dv
if there is no sign of myproxy-server running (no pid file in /usr/local/globus/var/myproxy.pid ; no pid listed in ps aux | grep proxy
) check you can manually start it. Start it locally in debug mode with:
myproxy-server -d
The -d option will avoid forking and you will get more information on the matter. After processing one request the server will shut down.
If the certificate has expired you can recreate it with:
#if using a self signed certificate
esg-node --myproxy-config regen-simpleca
#if retrieving the certificate
esg-node --fetch-esgf-certs
You shouldn't. See above for how to do it for the node.
But if you still need to do it manually:
$GLOBUS_LOCATION/bin/grid-cert-request -host `hostname --fqdn`
If this doesn't work, you can go finer and try this:
openssl req -new -keyout hostkey.pem -newkey rsa:2048 -nodes -out hostcert.req -days 365 -config /etc/grid-security/globus-host-ssl.conf && chmod 600 hostkey.pem
This creates an unencrypted rsa 2048 key and stored it in pem format in hostkey.pem and a request with 1 year validity in hotcert.req with the configuration from the mentioned file.
If properly setup, you can sign it with:
$GLOBUS_LOCATION/bin/grid-ca-sign -in hostcert.req -out hostcert.pem
Or look at that file to know how to sign it using openssl only. This did the trick for me.
Just be sure the DN is the proper one! If you are regenerating an expired certificate assure it's just like the old one, if you are creating a new one, you might be sure that the CN is host/myserver.somewhere.com (replace _ myserver.somewhere.com _ with the proper domain name, but leave the _ host/ _ prefix unless you know what aou are doing.
-
Backup the full content of the directory /etc/grid-security
-
Make sure that the directory /etc/grid-security contains the following files, possibly sym-linked to some other files:
bash-3.2# ls -l /etc/grid-security/globus* lrwxrwxrwx 1 root root 61 Oct 8 06:50 /etc/grid-security/globus-host-ssl.conf -> /etc/grid-security/certificates/globus-host-ssl.conf.685ca547 lrwxrwxrwx 1 root root 62 Oct 8 06:50 /etc/grid-security/globus-user-ssl.conf -> /etc/grid-security/certificates//globus-user-ssl.conf.685ca547
-
Run the following command:
$GLOBUS_LOCATION/bin/grid-cert-request -host
hostname --fqdn-force
which will create the following files:
-r-------- 1 root root 887 Oct 8 06:55 hostkey.pem
-rw-r--r-- 1 root root 1380 Oct 8 06:55 hostcert_request.pem
-
Send the file
hostcert_request.pemto esgf-ca group for signing. -
Install the signed file as /etc/grid-security/hostcert.pem
-
esg-node restart
Make sure your firewall has the port open. From the node try:
telnet <your.gateway.host.domain> 7512
_ Note: Change 7512 to the appropriate MyProxy port if you are not using the default one. _
An Unable to connect will signal a problem at the gateway.
Check the port was opened. At the gateway run:
netstat -tulpen | grep 7512
If the third column is not 0 0.0.0.0:7512 then the myproxy instance at the server is not properly running. Check here in FAQ for a solution to that. if it is working, check the firewall configuration with:
iptables-save
In case no port 7512 is open add it with something like: ( _ warning _ you should know what this does before executing it! Your system might have a different setup.)
iptables -I RH-Firewall-1-INPUT 10 -p tcp -m state --state NEW -m tcp --dport 7512 -j ACCEPT
For permanent change use services iptables save or modify manually the
proper file ( /etc/iptables or /etc/sysconfig/iptables ).
There is a second hurdle in CetnOS/Red Hat and other Enterprise-oriented
distros. SELinux is a more fine-tunable firewall, you can configure it with lokkit .
This appears to be a "known" problem... well... not that well-known, anyway...
Just delete (or rename) the directory pointed at by the X509_CERT_DIR variable
(normally ~/.globus/certificates-esg ) and try from a node retrieve the
certificate again.
myproxy-logon -s <gateway_name> -l <user@gateway> -p <gateway_myproxy_port> -o $X509_CERT_DIR -T
_ Note: This might happen only if the data node has retrieved a certificate from another gateway although I'm not sure. _
Start the server in debug mode (-d) and check there. If you get a tokenize error, the problem occurred while parsing the distinct name (DN) of the certificate. This is caused in my case because the CN field contains slashes for the open ID and myproxy uses slashes to tokenize the string.
This should be changed in future releases.
unknown"
This error indicates that the MyProxy server is unable to find/use the pam_pgsql modules on your system.
Step 1 : Most probably the postgres library is missing (e.g. libpq.so* ). First check that the libpq.so.* files exist in /lib (or sometimes /lib64 on your system). If they do not, be sure to copy them over. For example, using the install scripts, they may be located in /usr/local/pgsql/lib/, so you can run the following to make sure that they are usable by the system:
ln -s /usr/local/pgsql/lib/libpq.so.* /lib
ln -s /usr/local/pgsql/lib/libpq.so.* /lib64
Step 2 : Next, be sure that the pam_pgsql modules exist in your system's /lib/security (or /lib64/security) directory. If you need to manually build pam_pgsql from source, the default installation places them in /usr/local/lib/security/, so they must be copied over.
In any case check which libraries are used at /etc/pam.d/myproxy and
assure these exists and are accesible from the paths listed in LD_LIBRARY_PATH while starting the server.
Verify if the following files exist, and copy them over if they do not:
ls -al /lib/security/pam_pgsql.so*
ls -al /lib64/security/pam_pgsql.so*
You might also want to try strace to check for missing files, or use "ldd"
on any library files to see if they indicate which other dynamic libraries are
not found.
If the certificate from MyProxy has a subject like (notice the null ):
...
Subject: O=Grid, OU=GlobusTest, OU=simpleCA-somewhere, CN=null
...
X509v3 extensions:
1.2.3.4.4.3.2.1.7.8:
..null
The cause is is very probable to be something missing from the configuration
files. This might happen in some cases where the installer fails to setup
properly some environment variables (like running esg-gway \--myproxy rege- simpleca without the \--type cet parameters). Check especially that the
JAVA_CMD there is properly filled with all required information.
For the subject:
-
See
[/usr/local/globus/share/myproxy/]myproxy-certificate-mapapp.JAVA_CMD="java ESGOpenIDRetriever -h @@postgress_host@@:@@postgress_port@@ -u @@postgress_user@@ -p @@pg_sys_acct_passwd@@ -d @@gateway_db_name@@ -g @@gateway_name@@ -U"
For the extension:
-
See
[/usr/local/globus/bin/]esg_attribute_callout_app.JAVA_CMD="java ESGGroupRetriever -h @@postgress_host@@:@@postgress_port@@ -u @@postgress_user@@ -p @@pg_sys_acct_passwd@@ -d @@gateway_db_name@@ -g @@gateway_name@@ -U"
Both files might change so check the scripts in /etc/myproxy-server.config
. This is the file that configures which scripts are run in order to create
the MyProxy
certificates.
It is advisable to change java to $JAVA_HOME/bin/java to avoid
problems if the path is not correctly set.
Error...
The certificates created by the MyProxy server are signed with a master certificate. This certificate needs to be added to the truststore.
Make sure the CA signing the gateway certificate is in the tomcat truststore. This won't be the case if you use the simpleCA.
Check this by looking at the tomcat truststore:
keytool -list -keystore /usr/local/tomcat/conf/jssecacerts | sed -n '/Certificate/p'
and comparing the signature with the one from the simpleCA:
openssl x509 -in ~/.globus/simpleCA/cacert.pem -fingerprint -md5 -noout | sed 's/[^=]*=//'
One liner:
keytool -list -keystore /usr/local/tomcat/conf/jssecacerts | sed -n '/Certificate/p' | grep "$(openssl x509 -in ~/.globus/simpleCA/cacert.pem -fingerprint -md5 -noout | sed 's/[^=]*=//')" && echo "Found" || echo "Not found"
If it is not there, add it:
keytool -importcert -file ~/.globus/simpleCA/cacert.pem -keystore /usr/local/tomcat/conf/jssecacerts -alias $(hostname -f)
OR !!!
If you are using the esg-node install script you can do the following:
-
use the --register flag
%> esg-node --register
This flag will pull the certificate from the 's tomcat truststore and import it into your local host's truststore, therefore allowing the to complete the publication transaction which requires the to make a callback connection to you.
In the case of the simpleCA on the same host, the --rebuild-truststore flag will address this.
-
use the [--force] --rebuild-truststore flag.
%> esg-node --rebuild-truststore
Rebuilding truststore from esg certificates... Integrating in local simpleCA_cert
/export/drach1/.globus/simpleCA/cacert.pem' ->/etc/grid-security/certificates/simpleCA_cacert.pem.0' [OK] ... /etc/grid-security/certificates/simpleCA_cacert.pem.0 -> + Certificate was added to keystore ...
This will do the job described above, namely fetch the simpleCA's cert from where myproxy is configured to point to the certificate (specifically the value associated with the "certificate_issuer_cert" key in the /etc/myproxy- server.config file), copy it to where the other certificates are located and rebuild the truststore file used by tomcat. Oh, the --force flag will additionally pull down new certs from the central certificate repository, thus making sure you have the most up-to-date certs, and then proceed with the rebuilding of the truststore.
NOTE: This is similar but DIFFERENT than using the --register flag, which imports keys only available via the remote host's tomcat truststore. Take a look at the esg-node --help output to see the other key management flags that are available and see the [ installer's site ](http://esgf.org/esgf-installer- site/) for more information on the esg-node script.
You have to restart the server if you change any truststore, they are loaded only once at startup.
OR !!!
If you are sure that the truststore on the Gateway side already has the CA certificate loaded into it using the above methods, there's a chance that you need to modify the Tomcat server.xml file and explicitly add the following parameters:
<Connector port="443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
truststoreFile="/usr/local/gateway-home/certs/esg-truststore.ts"
truststorePass="*"
keystoreFile="/usr/local/gateway-home/certs/esg-keystore.jks"
keystorePass="*"
clientAuth="want" sslProtocol="TLS" />
What this does is explicitly references the truststore on the Gateway side, rather than doing the override method that you may be currently using (i.e. setting "-Djavax.net.ssl.trustStore=..." etc). Either should work, but in some cases, you may have to resort to this before things will work.
NOTE: All of these changes will NOT take effect until the Tomcat container is restarted.
this appears to be a problem with tomcat. A security hole was fount in the TLS/SSL protocol, so tomcat has disabled the certificate renegotiation. If the user is not allowed, the connection is simply cut. This should be the same as an "403 Access denied". To check it, add :allowUnsafeLegacyRenegotiation="true"_ to the SSL connector in the conf/server.xml file. This will be probably fixed in new versions of Tomcat, but just in case...
strings)
The library hessian.3.1.3.jar is missing or is loaded after spring-web.jar (probably the former).
allowUnsafeLegacyRenegotiation
If you have set legacy protocol renegotiation as indicated above and the esgpublish command hangs you may have an incompatible version of openssl on the datanode. Verify your openssl version with:
$ openssl version
OpenSSL 0.9.8k 25 Mar 2009
openssl-0.9.8k is known to have this problem and you may see it between versions 0.9.8h and 0.9.8m. To fix it you must upgrade openssl and python (since python's ssl module depends on openssl).
First check if your proxy certificate is properly created:
$ openssl x509 -text -noout -in $path_to_my_proxy_cert
If you see some _ null _ values that's probably it, please refer to the entry " MyProxy is issuing a certificate without any username "
If the install script complains that Postgres isn't running test that you can
login as user postgres .
# su postgres
$ id
uid=26(postgres) gid=115(postgres) groups=115(postgres)
If this doesn't work see which shell is defined for postgres in /etc/passwd . Change it from /bin/false to /bin/bash . You should
then reinstall Postgres and may need to clean out and repeat the entire
installation.
You can pre-empt this problem by creating the postgres user manually before
running esg-node \--install :
# useradd -r -s /bin/bash -u26 -c"PostgreSQL Service" -p $pg_sys_acct_passwd postgres