COSmanager FAQ

From Documentation

Revision as of 06:49, 21 July 2006

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

1. Config > COSmanager configuration > Other tables > schedule
2. select "70 Daily - except Thursday" > Maintain > Clone
3. change Order to 75
4. change Schedule name to "Daily - except Thursday Friday"
5. press choose on Day(s) and use Ctrl-click to select all days EXCEPT Thursday and Friday
6. 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:

1. On ‘hostB’, login as root, and run: su cosmos
2. Type the command ‘id’ to make sure that your user ID is ‘cosmos’.
3. 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 Run the command: 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
/usr/sbin
/usr/local/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: If you are using an older version of ssh, which does not support protocol version 2, you should follow the above instructions, except the filenames under the .ssh directory are different:

id_dsa == identity
id_dsa.pub == identity.pub
authorized_keys2 == authorized_keys
known_hosts2 == known_hosts

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:

1. Start COSmanager configuration (cos cosmos -C from the command line, or click on Config > COSmanager configuration) and double click on the hosts icon.
2. Select the remote host that you wish to access via ssh and double click it to modify its configuration.
3. Change the ‘comm meth’ field to ssh.
4. Test your connectivity by clicking on the Planet icon on the button bar and select ‘Remote‘.
5. Choose the host you just configured. You should see the button bar for the remote host.
6. 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? (draft)

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 Slave system can only administer itself. A Master can administer and any other host marked 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, 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 standard communication method used by COSmanager is rsh. To use this method a .rhosts file is created for the user fsadmin on the Slave systems that allow root or fsadmin access from the Master. In itself, this .rhosts file does not represent a security threat. In version 2.5.2 the fsadmin account is not privileged and users remotely logging in are captured by a .profile and securely put into COSmanager.

The command, FSadmin, is a set UID root program used to either start COSmanager or execute a command passed as a parameter. Running the command CM results in the execution of FSadmin which starts COSmanager. Under normal usage, the FSadmin command performs security checks to validate the user ID and check that they are authorised to use COSmanager. If the FSadmin command is invoked by root or fsadmin and passed a command to execute the normal security checks are bypassed and the command is run as root. This is the case when it is executed by FSremote to manage a remote system.

Normally the slave FSadmin is executed as a request from a COSmanager Master. This ensures that the user on the Master is allowed to run that administration task. However, if the user on the Master can get an fsadmin or a root shell, then they can remotely execute any command on any slave as root. This is possible because the slave does not authenticate that the commands were sent by COSmanager. This means that root on the Master system has root privilages on all the remote systems. Most products currently available on the market do not perform authentication,and so are susceptable to the same problem.

By ensuring that the root account on COSmanager masters 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.

CPIO versus TAR versus DUMP (draft)

Advantages of CPIO:

• allows file/pathnames of up to 1024 characters
• streaming, ie. non-blocked, output is good for non-blocking devices (networks, disk files, some tape drives)
• uses wildcards to match filenames upon restore
• can interactively rename files during restore
• reads list of filenames to backup from stdin; this allows for precise control of files backed up, but can be an inconvenience as well since more thought has to go into using the command
• flexible use at the beginning or end of a shell pipeline, or as a filter (read filenames from stdin, send archive to stdout, or vice versa)
• preserves hard links and symbolic links, as selected by options
• SVR4 (and Solaris) support multiple volumes
• backup and restore special device files
• supports incremental backups

Disadvantages of CPIO:

• recovering files from a damaged archive can prove difficult if the archive contains other cpio archives, since the embedded archive trailer will cause recovery to become out-of-sync
• filesystems being backed up *must* be mounted; a file could be modified while being written to media
• no built-in method for incrementals (must use "find -mtime" technique, which has crude granularity)
• format is not portable from SVR4 to SVR3

Disadvantages of TAR:

• may not handle very long filenames
• filesystems being backed up *must* be mounted; a file could be modified while being written to media

Advantages of DUMP:

• maintains an index on the tape
• supports backup of unmounted filesystems

Disadvantages of DUMP:

• does not read through the filesystem, but reads the raw device. Therefore dump backups can be out of sync with the in memory copy of the filesystem
• filesystems should be unmounted before performing a dump backup
• restore will not work remotely because it opens /dev/tty
• format not portable across all platforms
• not available on all platforms/filesystems