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)

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 -

VOFrontend dependency and validation checking complete

Checking for co-located services

The VOFrontend, Submit and/or the User Collector service are being installed on the same node and can share the same Condor instance, as well as certificates and VDT client instances. ...... VOFrontend Condor: /opt/vofrontend/condor .......... Submit Condor: /opt/vofrontend/condor ... UserCollector? Condor: /opt/usercollector

The condor_location for UserCollector? service is different. Do you really want to keep them separate? If not, stop and fix your ini file condor_location. Do you want to continue? (y/n) [n]: y .......... Submit Condor: /opt/vofrontend/condor

The condor_location for Submit service is different. Do you really want to keep them separate? If not, stop and fix your ini file condor_location. Do you want to continue? (y/n) [n]: y

Checking for co-located services complete

Configuring VOFrontend started

Collecting configuration file data. It will be question/answer time. ... checking user and submit nodes for schedds sh: /opt/vofrontend/condor/ No such file or directory [] ERROR: Failed to fetch list of schedds running condor_status -schedd Your user pool collector and submit node condor need to be running.

  • 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/

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.

  • Answer (11/2/10) - Because the certificates may be installed and maintained independent of the VDT client. The VDT client is not needed on all nodes. Only the submit/schedd for sure. And likely the VOFrontend although depending on how the proxies are maintained not necessarily true. I maintain all my proxies on the submit/schedd and distribute to the VOFrontend.
  • Parag (11/2/10) - I understand that you can have these certs independent of vdt but the main question (which got lost along with the other question) is why ask for parent dir? If you want the certs dir ask for certs dir don't ask for parent dir. This also applies to couple of other config attrs where you ask for parent dir. Also, I would prefer you rename the config attr "certificates" to x509_cert_dir or ca_cert_dir. Everyone knows what you are asking when you name the attr that way. Naming it as certificates is simply confusing and doesn't give much hint to the user. We should aim for naming the config attrs to be self descriptive so that the user doesn't need to look at the documentation.

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?

  • Answer (11/2/10) - Yes, I'm sure. I suppose I could verify it is there but that is all I can do with it. Do you know anything else I can do with it?
  • Parag (11/2/10) - I am not completely convinced and here is why. If you are using the certificate just to extract the DN and other info, then you are right. However, if you are configuring condor daemons (for example) to use the certs/key, you need to ask for the location of the key as well. Certs and keys can be in different location and don't necessarily have to be in same dir. Though having them in difference dir is not a common use case, it is still possible. So I would ask the user for key file as well.

11. (Parag 11/1/10) Related to the gsi_dn option (gsi_dn = /DC=org/DC=doegrids/OU=Services/CN=condor/ 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

  • Answer (11/2/10) - The pacman location is needed to I know where you want to install it. The actual (top level dir) of pacman is dictated by the pacman tarball when extracted and has the version in it which is a good idea to retain. I think it will still be confusing regardless of how you label it. All the prerequisite software should probably be an independent process and not part of the glidein installation. As you have said, some my have it already installed with the OS, some via RPM, others may use tarballs. Too many choices to handle.
    As for "Once vdt is installed pacman can be technically deleted", this is not necessarily true. You need pacman to perform updates on the VDT installation when they are available.
  • Parag (11/2/10) - Not at all convinced. Ask for pacman_location and take it as pacman_location. It shouldn't be difficult to get the parent dir of pacman_location if you need it for any reason.

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.

  • Answer (11/1/10) - Let me know what the "tricks" are. I am clueless. The new name is ok. When I came up with the old one I was not in too creative a state, just wanted to get the basic install functional.
  • Parag (11/2/10) - os.path.dirname(os.path.abspath(pathname))

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)
  • Resolved (11/2/10) - Problem in Fixed and committed. Error message now reads.
    ----- wmscollector ----
    ERROR: Section (Factory) does not exist in ini file (/home/weigand/glidein-ini/parag-wmspool.ini)
Topic revision: r5 - 2011/01/04 - 20:12:09 - JohnWeigand
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback