1. Where does calendar manager store its data?
2. What should the ownership and permissions be for the /usr/spool/calendar directory and the callog files found there?
3. What other files are related to Calendar Manager?
4. How can Calendar Manager information be moved to another system?
5. Is it possible to share/NFS mount the /usr/spool/calendar directory?
6. cm_insert doesn't seem to work as documented, is a patch available?
7. When choosing a day, why does the previous day get selected? (Or why are all appointments off by x number of hours?)
8. Why does the message "rpc.cmsd not responding, Have you run install_cmgr?" come from Calendar Manager, even after running the install_cmgr script?
9. What might be the cause of the message "rpc.cmsd file error on /usr/spool/calendar/callog.$USER"?

Q1:  Where does calendar manager store its data?

A1:  Calendar manager appointment information is stored in the
     /usr/spool/calendar directory in the callog.$USER file.
     

Q2:  What should the ownership and permissions be for the /usr/spool/calendar   
     directory and the callog files found there?

A2:  % ls -alg /usr/spool

     drwxrwsrwt  2 daemon   daemon        512 Aug 27 03:59 calendar/

     The 's' bit is the setuid bit used to set the group id to
     daemon.  The 't' bit is the sticky bit which only allows
     the owner to remove files into /usr/spool/calendar.

     To set these proper permissions, use the following commands as root:

          # chown daemon.daemon /usr/spool/calendar
          # chmod 1777 /usr/spool/calendar
          # chmod g+s /usr/spool/calendar


          % ls -alg /usr/spool/calendar

     drwxrwsrwt  2 daemon     daemon        512 Aug 27 03:59 ./
     drwxr-sr-x 19 bin        bin           512 Aug 26 09:44 ../
     -r--rw----  1 user1      daemon      19147 Aug 26 04:20 .calbak.user1
     -rw-rw----  1 daemon     daemon          0 May  9 15:33 .lock
     -r--rw----  1 user1      daemon      19147 Aug 27 03:59 callog.user1

     The callog file is owned by the user and MUST HAVE 460 permissions.

     To set the proper permissions on the callog file, use the following
     commands as user1:

          % chmod 460 callog.user1

     If these exact permissions are not maintained on both the
     directory and the files, the software suspects an intruder
     and refuses access to the data.


Q3:  What other files are related to Calendar Manager?

A3:  o   $OPENWINHOME/bin/xview/install_cmgr (in SunOS 4.1.X only):
          install script for setting up the calendar manager
          and adding rpc.cmsd to the inetd.conf file

     o   $OPENWINHOME/bin/xview/rpc.cmsd:
          calendar manager services daemon which manages all calendar
          data.  There is one rpc.cmsd daemon process per host.

     o  /etc/inetd.conf:
          modified via the install_cmgr script to contain rpc.cmsd.
          In this way, rpc.cmsd is started automatically by inetd.
          
     o  /usr/spool/calendar:
          directory containing calendar data files

     o  /usr/spool/calendar/callog.$USER:
          file containing $USER's appointments

     o  /usr/spool/calendar/.calbak.$USER:
          backup copy of the callog.$USER file, created each night
          after garbage collection

     o  /usr/spool/calendar/.lock:
          zero-length file used for mutual exclusion

     o  $HOME/.cm.rc:
          resources file, modified when calendar manager properties
          are applied


Q4:  How can Calendar Manager information be moved to another system?

A4:  The information for a user's calendar resides in the file
     /usr/spool/calendar/callog.$USER.  Before moving the file,
     check to make sure that no one is using that calendar on the
     new system.  Then copy the callog.$USER file to the new
     system's /usr/spool/calendar directory, and do the following
     commands as root:
 

     e.g., if the callog file belongs to user "user1",

        # chown user1.daemon callog.user1
        # chmod 460 callog.user1   

     Finally, before the appointments will appear, the following must be
     done as root:


        # setenv OPENWINHOME /usr/openwin
     	# $OPENWINHOME/bin/xview/install_cmgr

     o quit all Calendar Managers

     o kill the rpc.cmsd daemon (check with ps -aux | grep rpc.cmsd)

     o restart Calendar Manager


Q5:  Is it possible to share/NFS mount the /usr/spool/calendar directory?

A5:  NFS mounting of the /usr/spool/calendar directory across machines is
     not a supported configuration in OpenWindows 3.0, 3.0.1, and
     3.1.  However, support for centralized calendar data is
     expected for the version of OpenWindows bundled with Solaris 2.2.

     Workarounds for OpenWindows 3.0, 3.0.1, & 3.1 are available as follows:

     o Use the following script as a replacement of /usr/openwin/bin/cm on
       the client machines so as to run the cm process remotely and
       display it on your local system.

       #!/bin/csh
       $OPENWINHOME/bin/xhost servername   
       rsh servername "setenv OPENWINHOME /usr/openwin; \
       setenv LD_LIBRARY_PATH $OPENWINHOME/lib; \
       $OPENWINHOME/bin/xview/cm -display `hostname`:0 $* &" &

       Please replace "servername" with your server's hostname.
 
     o Centralize your calendar callog files on machine "servername",
       then on your client machines, modify your $HOME/.cm.rc file's
       "Calendar.DefaultCal:" entry to $USER@servername.  Then from
       servername, bring up Calendar Manager and give Browse, Insert,
       and Delete permission to each client machine that will be
       accessing the calendar from the calendar server.  This can be
       achieved under the Edit->Properties->Access List and Permissions
       window.
       

Q6:  cm_insert doesn't seem to work as documented, is a patch available?
   
A6:  Yes! Please call 1-800-USA-4SUN to order the Calendar Manager
     Jumbo Patch, 100523.


Q7:  When choosing a day, why does the previous day get selected?
	 (Or why are all appointments off by x number of hours?)
 
A7:  This is because the kernel timezone is set to GMT.  To remedy this, 
     run "tzsetup", located in /usr/etc, as superuser.  


Q8:  Why does the message "rpc.cmsd not responding, Have you run install_cmgr?"
     come from Calendar Manager, even after running the install_cmgr script?
	
A8:  Calendar Manager doesn't function without rpc.cmsd, the Calendar Manager 
     database daemon.  If you get the error messages above, rpc.cmsd is 
     likely not running or it has somehow lost its connection to the inetd   
     daemon (the process which initiates rpc.cmsd).
	
     This symptom can be caused by one of the following problems:

     o Calendar Manager used to work prior to changing the hostname.
               
       Solution:  Make sure all the necessary files in /etc
       (e.g., hosts, ethers, hostname.*, hostname.le0, hostname.le1,
       exports, xtab) are updated to reflect the hostname change.

     o Calendar Manager can fail on a standalone machine if the
       loopback network is not correctly set up.
          
       Solution:  
       Step 1: Edit the /etc/hosts file and merge into a single line the entry
       for your machine's hostname and the entry for "localhost", for example:
     
          127.0.0.1     hostname localhost loghost mailhost

       Step 2: Edit the /etc/rc.boot file and comment out all the       
       ifconfig commands by adding # at the beginning of each line, 
       for example:

          #if [  ... ]; then
          #     ifconfig
          #fi

       Step 3: Reboot machine 

     o Any changes made to the /etc/inetd.conf file must be followed by the
       following steps for reinitiating the Calendar Manager:
          
       Solution:
       Step 1: Edit the /etc/inetd.conf file and delete the following 
       line, and duplicates if any:

       100068/2-3   dgram   rpc/udp wait root /usr/openwin/bin/rpc.cmsd rpc.cmsd

       Step 2: Use "ps aux | grep rpc.cmsd" to see if rpc.cmsd is running.  
       If it is, issue "kill -9 ".
          
       Step 3: Use "rpcinfo -u  100068" to view the port status, 
       which should look like this:
       
            program 100068 version 2 ready and waiting
            program 100068 version 3 ready and waiting
            program 100068 version 4 ready and waiting  <- only on Solaris 2.2

       Step 4: Rerun install_cmgr "$OPENWINHOME/bin/xview/install_cmgr"
      
       Step 5: Restart Calendar Manager.

      
Q9:  What might be the cause of the message "rpc.cmsd file error on
     /usr/spool/calendar/callog.$USER"?

A9:  The $USER account is no longer available. However, other users' Calendar 
     Managers are still attempting to access the $USER in their multi-browser 
     list entry as $USER@machine.  Perform the following steps for each of
     the users experiencing the problem:

     Step 1:  Edit the file "$HOME/.cm.rc" and remove the reference to
     "$USER@machine" under "Calendar.CalendarList:"
     
     Step 2:  Use "ps aux | grep rpc.cmsd" to see if rpc.cmsd is running.  
     If it is, issue "kill -9 ".
     
     Step 3:  Restart Calendar Manager to flush the registration list

KEYWORDS           : cm

PRODUCT            : Deskset

SUNOS RELEASE      : All

UNBUNDLED RELEASE  : n/a

HARDWARE RELEASE   : All

ISO-9001 STATUS    : Uncontrolled

-- 
Tim Evans                     |    E.I. du Pont de Nemours & Co.
tkevans@eplrx7.es.dupont.com  |    Experimental Station
(302) 695-9353/7395           |    P.O. Box 80357
EVANSTK AT A1 AT ESVAX        |    Wilmington, Delaware 19880-0357