Configuring Host/IP Security in Condor

Now, we're going to experiment with some of the Host/IP security settings in Condor and examine the log files to see what is happening.

First, let's look at the current configuration of the host/IP settings on your machine. We will use "condor_config_val" to view your current configuration. (Note: In your shell environment, I set up an alias, "ccv", which can be used instead of "condor_config_val") 

% ccv hostallow_administrator
% ccv hostdeny_administrator
% ccv hostallow_read
% ccv hostdeny_read
% ccv hostallow_write
% ccv hostdeny_write
% ccv hostallow_owner
% ccv hostdeny_owner

As you can see, most of them are undefined. So, all hosts are allowed read and write access to your machine, the local host and the central manager have "owner" access, and only infn-corsi98 has administrator access.

Let's look more closely at hostallow_administrator, since this is the setting you will most likely want to customize. First, lets look directly at the config file to see what it is set to: 

% grep -i hostallow_admin ~/condor_config

You'll notice two references. The first is were we define it. Here, we use the $(CONDOR_HOST) macro, which holds the hostname of your central manager. This is the default that Condor is shipped with: only the central manager has administrator access. This means that all users logged on to your central manager can perform administrative commands in your pool.

If you now perform an administrative command on your own machine, it will be denied: 

% condor_reconfig

Look at the MasterLog file on your machine to see what just happened: 

% tail -20 ~/log/MasterLog

You will notice the entry that mentions "PERMISSION DENIED". This is a common problem in a pool, and whenever administrative commands (condor_off, condor_on, condor_restart, condor_reconfig, etc) don't "seem to be working", this is what's going wrong. In these situations, you often need to send the UNIX signal, SIGHUP, to your daemons to get them to reconfigure.

You're probably wondering why condor_reconfig worked before, and you successfully reconfigured your machine to switch pools. In the previous excercise, your machine was the central manager, so you could perform administative commands (like condor_reconfig). However, once you reconfigured your machine to use infn-corsi98 as the central manager, the $(CONDOR_HOST) macro that defines HOSTALLOW_ADMINISTRATOR is now different, so now, when you perform the condor_reconfig, it is denied.

Now, let's reconfigure your machine again to allow both the central manager and your local host to have administrator access:

  1. Edit ~/condor_config (use vi or emacs)
  2. Search for "HOSTALLOW_ADMINISTRATOR"
  3. Change it to look like this: 
      HOSTALLOW_ADMINISTRATOR = $(CONDOR_HOST), $(FULL_HOSTNAME)
  4. Save the file and exit

You will have to use the UNIX "kill" command to send a SIGHUP to your condor_master. First, use "ps" to find the pid (process ID): 

% ps auwwx | grep condor_master

The number in the second column is the pid. Now pass that number to "kill -HUP" (you must replace the "pid" in the command below with the right number). 

% kill -HUP pid

Now, view the MasterLog again to see that the SIGHUP was successful: 

% tail -20 ~/log/MasterLog

Your machine can now send administrative commands to itself. As a final test, we'll have you shutdown most of Condor on your machine with the "condor_off" command: 

% condor_off

This command tells the condor_master to shutdown all of the daemons it is controlling. However, the condor_master will continue to run to recieve requests for "condor_on", "condor_restart", etc.

Look at the MasterLog again to see what happened: 

% tail -20 ~/log/MasterLog

Also, lets examine the status of "ps" to make sure the daemons are gone, and only the condor_master remains: 

% ps auwwx | grep condor_

Now, let's turn the daemons back on with condor_on: 

% condor_on

If you run "ps" again, you should see all the daemons: 

% ps auwwx | grep condor_

Note: You still have a condor_collector and condor_negotiator running on machine. That's because the DAEMON_LIST setting still includes all these daemons, back from when your machine was configured to be in its own pool. Take a look for yourself: 

% ccv DAEMON_lIST

We will fix this in the next tutorial excercise.

Finally, we'll tell the master shutdown and exit: 

% condor_off -master

Look at the MasterLog again to see what happened: 

% tail -20 ~/log/MasterLog

Also, lets examine the status of "ps" to make sure the daemons are gone, including condor_master: 

% ps auwwx | grep condor_

You're done! Please let the instructor know you have finished.