Difference between revisions of "VOMS"
(→Host Certificate Updates) |
(→Restarting Services) |
||
Line 30: | Line 30: | ||
echo "" | telnet voms.gridpp.ac.uk 15050 | echo "" | telnet voms.gridpp.ac.uk 15050 | ||
− | To restart | + | To restart the Java service container, run |
− | service voms-admin | + | service voms-admin restart |
− | + | This will reload all VOMS-admin instances as well. | |
− | To restart | + | To restart a single VOMS-admin instance it has to be stopped and started (there is no restart option): |
− | service voms-admin stop | + | service voms-admin stop <VO> |
− | service voms-admin start | + | service voms-admin start <VO> |
− | + | It will undeploy the VO first and then deploy it again and is therefore equivalent to running | |
− | + | service voms-admin undeploy <VO> | |
− | + | service voms-admin deploy <VO> | |
− | service | + | |
'''IMPORTANT''', please read before restarting any services: | '''IMPORTANT''', please read before restarting any services: | ||
Line 50: | Line 49: | ||
'''EVEN MORE IMPORTANT''' | '''EVEN MORE IMPORTANT''' | ||
− | VOMS-admin stores the last notification date in memory only (see [http://www.gridpp.ac.uk/wiki/VOMS_Notifications#Membership_expiry_notifications VOMS notifications]). '''Every time''' VOMS-admin | + | VOMS-admin stores the last notification date in memory only (see [http://www.gridpp.ac.uk/wiki/VOMS_Notifications#Membership_expiry_notifications VOMS notifications]). '''Every time''' VOMS-admin or a VO is restarted, emails are sent out to VO admins !!! See [https://www.gridpp.ac.uk/wiki/VOMS#Dealing_With_Notification_E-Mails Dealing with Notification E-Mails] on how to avoid the problem. |
== Adding New CAs == | == Adding New CAs == |
Revision as of 13:38, 27 June 2014
Contents
VOMS Service Setup
Replication
The current setup consists of one master server hosted in Manchester and two slaves in Oxford and Imperial.
The master server hosts both, the VOMS daemons that issue the attribute certificates (AC), and the VOMS-admin interface that is used by VO managers to manage their VOs and by users to join a VOs or update their VO membership. The slaves run the VOMS daemons, but no VOMS-admin interface. They cannot be used to get ACs, but not to modify VOs.
All servers run a local MySQL database. Each slave has a local copy of the master database which is kept up-to-date using MySQL replication. The connections between master and slaves are secured with SSL.
Restarting Services
Normally, the services only have to be restarted if their configurations have changed or if newer versions have been installed during an upgrade.
VOMS daemons can be either restarted or reloaded. Configuration changes can be applied by reloading the daemons. A restart is only necessary if there are problems with the service or after software upgrades.
A single VOMS daemon can be reloaded or restarted by running
service voms reload [VO] # reloads the daemon for [VO] service voms restart [VO] # restarts the daemon for [VO]
If the VO name is omitted then all VOMS daemons are reloaded / restarted.
The configuration is not read instantly when the service is reloaded. This happens when the next client connects, but before the client request is processed. It is enough to open a connection to the port of the daemon to force the reading of the configuration file, e.g.,
echo "" | telnet voms.gridpp.ac.uk 15050
To restart the Java service container, run
service voms-admin restart
This will reload all VOMS-admin instances as well. To restart a single VOMS-admin instance it has to be stopped and started (there is no restart option):
service voms-admin stop <VO> service voms-admin start <VO>
It will undeploy the VO first and then deploy it again and is therefore equivalent to running
service voms-admin undeploy <VO> service voms-admin deploy <VO>
IMPORTANT, please read before restarting any services:
Restarting services makes them inaccessible for a period of time. The restart of the VOMS daemons only takes a few seconds if at all. Even though the command to restart VOMS-admin returns almost immediately, it takes a lot longer to complete, as most of it is done in the background. The command just starts the process, but does not wait for its completion.
EVEN MORE IMPORTANT
VOMS-admin stores the last notification date in memory only (see VOMS notifications). Every time VOMS-admin or a VO is restarted, emails are sent out to VO admins !!! See Dealing with Notification E-Mails on how to avoid the problem.
Adding New CAs
A restart of services is not required after installing new CA certificates on the server. VOMS-admin requires a CRL to be present before accepting the CA. The CRLs of new CAs can be downloaded by manually running
fetch-crl
The list of CAs that the Tomcat server accepts can be shown with the following command (on the server):
echo "" | openssl s_client -connect localhost:8443 -CApath /etc/grid-security/certificates/ \ -cert /etc/grid-security/hostcert.pem -key /etc/grid-security/hostkey.pem
Adding New VOs
Master Server
It is not advisable to use yaim to add a VO due to the disruptions to services (multiple restarts of Tomcat and VOMS daemons) and other unwanted side effects (see comments in Restarting Services) it is causing.
Instead use the man-voms-add-vo script located in /opt/glite/bin. It will deploy the VO, update the configuration files with our default settings, update the ACL of the VO, and start the processes for the VO. It can also be used to update the yaim configuration files. All options are explained in the usage instructions that can by viewed by running
/opt/glite/bin/man-voms-add-vo -h
In most cases the following example should be sufficient when deploying a VO:
/opt/glite/bin/man-voms-add-vo --vo <vo name> --email <email> --hostname voms.gridpp.ac.uk --restart --yaim-config /etc/yaim
The --restart parameter restarts the VOMS admin siblings web application that shows the list of VOs (/vomses). Without restarting it, the list will not contain the new VO. It will not trigger any emails to VO admins.
Replicated Servers
The VO has to be configured on the replicated servers after it was deployed on the master. Currently, the replicated servers are configured by yaim, so they need the relevant yaim configuration blocks for the new VOs. These can be generated by running
/opt/glite/bin/print_slave_yaim_vo_config <vo>
on the master. Multiple VOs can be specified on the command line. Please be aware that this script only creates yaim configuration options for the configuration options supported by the man-voms-add-vo scripts. Other yaim options or direct changes to the VO configuration files are not covered and have to be either added to the yaim configuration or added to the VO configuration on the replicated servers manually after running yaim (if the option is not available in yaim). The printed information can be sent to the sites hosting the servers, which have to put it into the services/glite-vomsdaemons configuration file and re-run the configure_slave_yaim script. Site admins should not run yaim directly on the replicated servers, they should always use the wrapper script.
Removing VOs
Replicated Servers
VOs have to be removed from the replicated servers first. The hosting sites have to do the following steps for each VO (replace <vo> with the name of the VO):
- run 'service voms stop <vo>'
- remove the /etc/voms/<vo> directory
- remove <vo> from the VOS variable in site-info.def
- remove the configuration section of the VO in services/glite-vomsdaemon
There is no need to run yaim on the replicated servers to remove VOs.
Master Server
Once the VO has been removed from all replicated servers, it can be removed from the master.
Dealing With Notification E-Mails
Notification emails are sent to the VO admins or users every time the web application of a VO or the Tomcat server is restarted (see comments in Restarting Services). The easiest way of avoiding this problem is to prevent sendmail from sending out any emails during maintenance. This can be done by running the command
/opt/glite/bin/disable_sendmail
on the server. The script configures sendmail to redirect all outgoing email to the mailbox of the local root account. Those emails can be viewed with a local email client such as mutt. Important emails that are not related to automated notifications can be forwarded to the users once sendmail is re-enabled.
Currently, there is no script to re-enable sendmail, but the following steps can be used to do it:
cp /usr/share/sendmail-cf/m4/proto.m4.org /usr/share/sendmail-cf/m4/proto.m4 cp /etc/mail/sendmail.mc.org /etc/mail/sendmail.mc make -C /etc/mail service sendmail restart
The *.org files were created manually before the first run of disable_sendmail. If they are not present then look for the backup copies that disable_sendmail creates in /var/backups/sendmail.
Undelivered emails should be checked after restoring sendmail. Notification emails can be ignored, all other emails should be forwarded to the respective users. Emails with the following subjects are notification emails that can be ignored:
- [VOMS Admin] Expired members notice for VO <vo>
- [VOMS Admin] Membership expiration notice for VO <vo>
Installing Updates
Host Certificate Updates
To update the host certificate, use the following steps:
- Copy the pem files (hostcert.pem, hostkey.pem) onto the machine.
- Replace the following files in /etc/grid-security with the new hostcert.pem:
- hostcert.pem (you might want to make a backup copy of it first).
- tomcat-cert.pem (make sure it's owned by the tomcat user).
- Replace the following files in /etc/grid-security with the new hostkey.pem:
- hostkey.pem (you might want to make a backup copy of it first).
- tomcat-key.pem (make sure it's owned by the tomcat user).
- mysql-key.pem (make sure it's owned by the mysql user).
- Make sure that all the key files have the correct permissions (0400).
- Restart the VOMS daemons (see Restarting Services).
- Restart Tomcat. This will cause notification emails to be sent to VO admins (see Restarting Services)
History of host certificate updates
- 10/04/2014 (heartbleed bug)
- 11/03/2014
- 04/03/2013
- 14/02/2012
- 08/02/2011
- 01/02/2010
This page is a Key Document, and is the responsibility of Robert Frank. It was last reviewed on 2014-04-10 when it was considered to be 82% complete. It was last judged to be accurate on 2014-04-10.