COSmanager FAQ
From Documentation
Contents |
Scheduler (for Version 4.x Applications and Newer)
These Schedule Definitions are valid for COSmanager Framework versions 4 or newer. The Schedules for older versions of the products will still work.
Schedule: Daily - except Thursday Friday
- Config > COSmanager configuration > Other tables > schedule
- select "70 Daily - except Thursday" > Maintain > Clone
- change Order to 75
- change Schedule name to "Daily - except Thursday Friday"
- press choose on Day(s) and use Ctrl-click to select all days EXCEPT Thursday and Friday
- press Accept
Note: the above steps can be followed for any combination of days.
Scheduler (for Version 3.x Applications and Newer)
These Schedules are valid for all current versions of COSmanager Suite products.
How do I define a scheduled time for the last Friday of the month?
Set up a new scheduled time as follows:
Ord:nnn When:Monthly - last Friday Schedule Cmd:D1=`cal | tail -c4` ; D2=`expr $D1 - 7` ; db_datemat -d$D2-$D1 -w5 $Today $Start Crontab string:* * 5 Check cron:yes
On some platforms the flag to tail the command may have to be... tail -4c
How do I define a scheduled time for the last working day of the month
Setup new scheduled time as follows:
Ord:nnn When:Monthly - last working day Schedule Cmd:day=`cal | tail -c4` ; last="`date +%Y%m$day`" ; [ "`db_date`" -eq "`db_datemat -p -b -w1-5 $last`" ] Crontab string:* * * Check cron:yes
On some platforms the flag to the tail command may have to be ... tail -4c
How do I define a scheduled time for once a fortnight
Setup new scheduled time based on the following:
Example: schedule time for the first Monday each fortnight:
Ord:nnn When:Fortnightly - 1st Monday Schedule Cmd:WK=`date +%U` db_datemat -w1 && [ 1 -eq `expr $WK % 2` ] Crontab string:* * 1 Check cron:yes
Example: schedule time for the second Wednesday each fortnight:
Ord:nnn When:Fortnightly - 2nd Wednesday Schedule Cmd:WK=`date +%U` db_datemat -w3 && [ 0 -eq `expr $WK % 2` ] Crontab string:* * 3 Check cron:yes
Explanation of example Schedule Commands above:
WK=`date +%U` gets the week number for today. db_datemat -w3 returns true if today is Wednesday. -w0 is Sunday, -w6 is Saturday. `expr $WK % 2` returns a modulo 2 number, 1 for the first week in a fortnight, and 0 for the second.
How do I define a scheduled time for the last Friday of June and December (6 monthly)
Setup new scheduled time as follows:
Ord:nnn When:June, Dec - last Friday Schedule Cmd:D1=`cal | tail -c4` ; D2=`expr $D1 - 7` ; db_datemat -m6,12 -d$D2-$D1 -w5 $Today $Start Crontab string:* * 5 Check cron:yes
On some platforms the flag to the tail command may have to be ... tail -4c
General Questions
How do I configure SSH communications?
When COSmanager is installed a cosmos user is created, and this user needs to be configured at an OS level to use ssh. The end result is that as the cosmos user on HostA you can run ssh HostB <command> (and vice versa) without entering a passphrase.
The COSmanager Framework version 4.1 and later optionally support ssh as their communications. However, its configuration requires some effort, because keys for the cosmos user must be generated and copied to the remote hosts. This process must be repeated for each host on which COSmanager is installed.
The following commands assume that you are running a reasonably modern version of ssh which supports protocol version 2, and the DSA algorithm. They also assume that the ssh package has been installed correctly on your hosts, and that the sshd daemon process is running on each.
To allow COSmanager on host hostA to run remote COSmanager commands on hostB, follow the following instructions:
- On hostB, login as root, and run:
su cosmos - Type the command
idto make sure that your user ID is cosmos. - Generate a dsa public key/private key pair:
ssh-keygen -t dsa or ssh-keygen -d
If you get the message ‘not found’, check that the SSH bin directory is in your shell's path, and if not add it.
This command should generate a dsa private/public key pair for user cosmos. Hit Enter to accept all default value when it asks for the file name to save the key, and also hit Enter each time you are asked for a passphrase (we do NOT want to use a passphrase).
This should create the files:
- ~cosmos/.ssh/id_dsa
- ~cosmos/.ssh/id_dsa.pub
- ~cosmos/.ssh
Copy the file id_dsa.pub to a temporary directory on hostA. This file will be accessed later when you log onto hostA.
Login in as your normal user ID (assumed to be registered to COSmanager as a Manager), and run: cos cosmos -C. This should bring up the COSmanager Global Configuration window.
Double-click on Hosts, and a list of COSmanager hosts should appear in another window. Double-click on hostA, and when the form appears, change the Comm method field to ssh. Hit Accept to save the change. If hostA is NOT in the list, select Maintain > Add, and add an entry for hostA, with the Comm method field set to ssh.
Login to hostA as Root, and run: su cosmos then ssh-keygen -t dsa or ssh-keygen -d to generate the keys for hostA.
Change to the ~cosmos/.ssh directory and append the copy of id_dsa.pub copied from hostB (NOT the one in the local directory which was just created by the ssh-keygen command) to the file authorized_keys2. If authorized_keys2 does not exist simply copy the id_dsa.pub file from hostB to it. This allows the cosmos user on hostB to run a command as user cosmos on hostA.
ssh is very fussy about the permissions and ownerships of the files in the .ssh directory, and the ~cosmos & ~cosmos/.ssh directories themselves. Ensure that they are all owned by user cosmos and that the permissions are:
~cosmos drwxr-xr-x (755) ~cosmos/.ssh drwxr-xr-x (755) ~cosmos/.ssh/authorized_keys2 -rw------- (600) ~cosmos/.ssh/id_dsa -rw------- (600) ~cosmos/.ssh/id_dsa.pub -rw-r--r-- (644)
Copy the file id_dsa.pub from the .ssh directory to a temporary directory on hostB.
Now go back to hostB, login as Root, run: su cosmos and then try the command: ssh hostA pwd (of course the ssh program must be in a directory in your search path). When run for the first times to a new host, ssh may say that the host cannot be authenticated, and will ask you if you want to connect. Reply "yes". ssh should add hostA to list of known hosts (file known_hosts2), and you should never be asked again.
If the ~cosmos directory name is NOT returned, then you have a problem! It may be that the public key was not copied into authorized_keys2 correctly, or that the permissions or ownerships of some ssh files are not correct. The easiest way of debugging is to kill the sshd process on the other host (hostA), and run in in DEBUG mode (as root): sshd -Dddd This will NOT start it as a daemon, and will give a lot of debugging information, which should help you pinpoint the problem.
 | Note |
| sshd will probably NOT be in your search path. Some common locations for it are:
/sbin | |
You will probaly need to use the full pathname when running it.
| | Note |
| Killing sshd is probably not a good idea if other people or applications are using ssh to that host. | |
Finally, you must go back to hostA, and repeat steps e & f, this time using hostB rather than hostA. Then login as root, run su cosmos and repeat steps i through l, using hostB instead of hostA.
Congratulations, COSmanager is now configured to use ssh in both directions between hostA & hostB.
| | Note |
| {{{1}}} | |
There is also an ssh configuration file often found in /etc/ssh/ssh_config. In this file you can effectively force ssh to use either protocol 1 or protocol 2 by specifying the identity file. Normally no identity file should be specified as ssh is smart enough to determine which to use in any given situation. If you are having problems configuring ssh to use protocol 2 (symptoms include falling back to password authentication even though the keys have been exchanged correctly), check this file and comment out the IdentityFile line:
# IdentityFile ~/.ssh/identity
Once this is complete you can configure COSmanager to use ssh:
- Start COSmanager configuration:
cos cosmos -Cfrom the command line, or click on Config > COSmanager configuration and double click on the hosts icon. - Select the remote host that you wish to access via ssh and double click it to modify its configuration.
- Change the comm meth field to ssh.
- Test your connectivity by clicking on the Planet icon on the button bar and select Remote.
- Choose the host you just configured. You should see the button bar for the remote host.
- Repeat this process to allow access from HostB back to HostA.
How does COSmanager's remote system management affect the security of remotely managed systems?
To answer this it is necessary to explain how COSmanager manages those systems.
For the purpose of system management, COSmanager defines a host as either a Master, a Remote or a Slave. A Master can administer any other host configured as Remote or Slave. A Remote system is another Master on the same network. This enables arbitary management domains to be defined.
To administer a Slave host, a Master executes commands through a local program called FSremote. This program looks up a communication method, in the comm_meth table, and uses this to execute the command via the cos command on the Slave. The Slave will reject requests from hosts that are not pre-configured in COSmanager.
The standard communication method uses a proprietary protocol implemented by FSremote and COSserver on a fixed, private TCP port. Alternatively rsh or ssh protocols can be used. Neither the rsh nor the proprietary protocol encrypt data, but they do not transmit the user's password across the network. Ssh provides encryption at the expense of speed and being more time consuming to set up.
The command, cos, is a set UID root program used to either start COSmanager or execute a command passed as a parameter. This is because root access is required to perform most System Management activities under Unix and Linux. Under normal usage, the cos command performs security checks to validate the user ID and check that they are authorised to use COSmanager, that they have the appropriate capabilities to perform the request.
When a COSmanager Master executes a request via FSremote to a Slave, the cos command on the Slave is invoked. This ensures that the user on the Master is allowed to run that System Management task. However, because the Slave trusts requests from its Master, and assumes that the Master has already authenticated the user, much of the authentication on the Slave is bypassed. In particular, if a user on the Master can get a cosmos or a root shell, then they can remotely execute any command on any Slave as root. This means that root on the Master system has root privileges on all the Slave systems. Most products currently available on the market are susceptable to the same problem.
By ensuring that the root account on COSmanager Master is protected from unauthorised use, COSmanager does not introduce further security risks to a network. COSmanager facilitates this by enabling the use of the root account to be minimised.