Ini Installer Comments

This page is intended to document questions/comments/concerns regarding the ini based glideinWM installer. It is intended as a working/temporary/reference document maintained by -- JohnWeigand

1. (Justin - 10/26/10) Script could possibly check if it's on the same machine as the node, and not try to ssh into itself

• Answer (10/27/10): I am still debating this one. The rationale of ssh'ing in, even when on the same node, is to insure the same/clean environment regardless of where you are initiating the script.

2. (Justin - 10/26/10) Tell where to get stuff (javascriptrd, condor, m2crypto)

• Answer (10/27/10): Documented here - http://home.fnal.gov/~dstrain/newdoc/components/prerequisites.html
  Will talk to Doug about how we incorporate with the doc above.

3. (Justin - 10/26/10) Client files for factory in documentation different from in template file

• Answer (10/27/10): Not sure what this means. Can you point me to the factory doc you are talking about?

4. (Justin - 10/26/10) If javascript rrd (also m2crypto and others) are not installed, the installer does not seem to be installing them even when the tarball is specified

• Answer (10/27/10): This was a part I don't think I ever implemented. Was uncertain whether it should or should not be at the time. Main focus was on the glidein services and deferred this. Some users get them from rpm's. Some already have them installed. Still not certain if this should be a part of the installer. I may need some direction on this.

5. (Doug - 10/28/10) Defaults should be changed for the cvs copy of glideinwms.ini. All the defaults have your (weigand's) machine and service certs. Also, use_ccb should be defaulted to y. web_url defaults to port 8319, which is a fairly strange choice.

• Answer (10/28/10): The glideinWMS is not a default file. Just a sample. Not sure what the "defaults" should be.

6. (Doug 10/28/10) Confusion as to what unix_acct means and messages indicating what acct is being used to install the service Example is the case where, on the WMS Collector with privilege separation you have install as root but the unix_account option cannot be root. * Answer (10/28/10) - I am not sure how to really clarify this more than what is in the doc at this time. It says in the Description ("UNIX user account that this services will run under. DO NOT use "root".
.
In the Comments, it says "However, if privilege separation is being used, you MUST *install *as root user as the condor switchboard requires it".
.
This, however, is incorrect in the User Collector ini doc. This comment should be in the Submit/Schedd section. It is not the collector or negotiator.
It is the schedd's that have the security issue. At least as I understand it and I think we had a thread on this a while ago.
.
However, that said, if you are installing collector/schedd using same condor location, they better all be the same user I think. Although I am not totally sure and I know I don't check for that.

7. (Doug - 10/28/10) The vofrontend installation is a little confusing. I installed everything on one node, and wanted a separate condor for each service (I like everything separate). This is possible in Q&A, since you install condor VO frontend separately. The documentation implies this is possible: "condor_location: Directory in which the condor software will be installed". However, it seems to think that you have to use the submit/userschedd condor. This should be explained more clearly -

• Answer (10/20/10) - Hmmm.... looks like a bug to me. Will investigate.

8. (Doug (10/28/10) There is still a port problem. I installed the wmscollector with "collector_port = 9618" and usercollector with "collector_port = 8618" on the same node, but it installed the submit schedds on the wms collector and not user collector.

• Answer (10/28/10) - I check the WMSCollector and UserCollector? for collisions and ... oops.... I never insure the User Collector non-standard port is correct but not the VOFrontend This does not happen if you share condor_location of the vofrontend and user collector on the same node. This will be a problem also if a non-standard port is used when on different nodes.
  .
  Should also check this on the Factory (I am sure I am not) if the WMS Collector is on a non-standard port.
• Resolved (11/2/10) - Fixed/committed in services/Condor.py.

9. (Parag 11/1/10) The certificates option confusing (certificates=/home/weigand/glidein/vdt). Why do you need parent dir for certificates? Why can't you directly get it from vdt since you already ask and check for the existence of VDT.

10. (Parag 11/1/10) Related to the cert_proxy_location option (cert_proxy_location = /etc/grid-security/cmssrv97condorcert.pem). Are you sure you do not need the location of the key file?

11. (Parag 11/1/10) Related to the gsi_dn option (gsi_dn = /DC=org/DC=doegrids/OU=Services/CN=condor/cmssrv97.fnal.gov). Why can't you extract the DN from the certificate? Why do I need to type it in here?

• Answer (11/2/10) - Because my need for it is another node. e.g., if I am installing the user collector, I need to know who the frontend and schedds are. They may not be installed on the same node as the user collector and I cannot then read the cert to get the DN. Also, this is one area I have seen people put the wrong value (issuer vs subject depending on if a cert or proxy) and when installing a service I check to see if they did it right. Troubleshooting these authorization problems is a major pain in the the butt and the most likely reason when nothing works.

12. (Parag 11/1/10) Related to the pacman_location option (pacman_location = /home/gfactoryparag). Why do I need this pacman_location? Once vdt is installed pacman can be technically deleted. And it is confusion when you label the parameter as xxxx_location while you want the parent dir on xxxx in some cases. There needs to be consistency across the board. Either ask for pacman_location and you take it as pacman_location or ask for pacman_basedir (or pacman_installation_dir) when you need the parent dir. Applies to other cases as well

13. (Parag 11/1/10) Related to the glidein_install_dir option (glidein_install_dir = /home/gfactoryparag/v2.5pre/glideinWMS). Another redundant parameter. You can do tricks to determine the full path of manage_glideins and get the glideinWMS codebase Also, we need some consistency. glideinwms_location is a better name then glidein_install_dir.

14. (Parag 11/1/10). There is a misleading error message given when the ini file does not contain all the required sections for the installation of a service. In this case, it was a WMS Collector install and no Factory section was provided. The error message says the vdt_location is missing.

ERROR: Section (<Configuration from /home/weigand/glidein-ini/parag-wmspool.ini>
vdt_location /home/gfactoryparag/vdt) does not exist in ini file (/home/weigand/glidein-ini/parag-wmspool.ini)