Calendar Manager Troubleshooting

This section describes basic Calendar Manager troubleshooting.

RPC Problems and Calendar Manager Installation

The Calendar Manager consists of two parts:

• A database manager, called rpc.cmsd (Calendar Manager service), that maintains the information for the Calendar Manager

• The Calendar Manager application itself, called cm

The Calendar Manager application cannot function without the Calendar Manager service.

If your Calendar Manager does not display appointments, or if you get RPC timeout messages in the console window, rpc.cmsd may not be running. To check your configuration, use these steps:

1. Open a Command Tool or Shell Tool.

   See Chapter 6, Command Tool, Shell Tool, and Console Window for information about the Command and Shell Tools.

2. At the system prompt type ps -e | grep rpc.cmsd and press Return.

   This asks for a listing of all processes containing the string rpc.cmsd.

3. Look at the listing displayed in the window.

   Figure A-1 shows a listing that contains the Calendar Manager service process. You can ignore the entry grep rpc.cmsd in your ps listing.

   Figure A-1 A ps Listing Showing the rpc.cmsd Process

   
   

   If you do not have an rpc.cmsd process running, follow these steps:

   ---

   Note -

   If you have a Calendar Manager application running, quit the Calendar Manager by choosing Quit from the Window menu.

   ---

1. Become root.

2. At the system prompt, type vi /etc/inetd.CONF

3. Look for the entry: Rpc.cmsd

   Make sure the pathname specified is correct and that an Rpc.cmsd entry exists in the specified pathname. If not, change the path to point to where the Rpc.cmsd exists. Then view the pid of inetd by typing:

   ps -e | grep inetd

   Then reread the inetd.CONF file by typing:

   kill -1 inetd-pid

4. Restart Calendar Manager.

5. To make sure that the Calendar Manager Service is now running, type ps -e | grep rpc.cmsd and press Return.

Upgrading SunOS and Calendar Manager

If you are upgrading the SunOS, you need to back up the following directory, to preserve the information there:/var/spool/calendar

Use whatever backup medium is available to you, and restore the directory when the operating system upgrade is complete.

Missing Calendar Data or NO NAME in Header

If your appointments are not displayed, make sure you have run the installation script, as necessary. See "RPC Problems and Calendar Manager Installation" for information. Before trying the following procedure, try restarting Calendar Manager first.

If your appointments are still not displayed, and you see the string NO NAME in your Calendar Manager header, the permissions are probably wrong for the /usr/spool/calendar directory and files. Make sure they are exactly as described in the following steps.

1. Type ls -lsa /usr/spool, and check the permissions for the directory: /usr/spool/calendar.

   The permissions need to be exactly: drwxrwsrwt. This should be owned by daemon in the daemon group. (Get help from your system administrator to change the permissions, if necessary.)

2. To check the permissions of your calendar database, type:

   ls -lsa /usr/spool/calendar/callog.<username>.

   Substitute your user name in place of <username>. For example, type ls -lsa /usr/spool/calendar/callog.egret. The permissions need to be exactly: -r--rw----. Also, this file needs to be owned by the user and in the daemon group.

Remote Access Problems

There are two basic symptoms of remote Calendar Manager access problems:

• You try to browse a remote calendar where you think you have Browse access, and all you can see are appointment times.

• You try to insert, delete, or change an appointment on a remote calendar where you think you have access, and Calendar Manager gives you an Access Denied... error message in the footer of the Appointment Editor.

There are three things you can check to try to fix these access problems:

1. If you are using the NIS or DNS system, which uses the concept of mail domains, make sure you are trying to browse a calendar in your domain or that you have specified the domain in your browse list. For example, if you are trying to browse the calendar of user Rob in your domain, you can simply specify Rob@host. If you are in a domain called Eng, and Rob is in a domain called Corp, you need to specify rob@host.Corp in your browse list.

2. Make sure that the owner of the remote calendar has really given you Browse, Insert, and/or Delete access.

   In order for the access to occur, make sure both of these conditions are met:

   1. Names in the access list must take the form user@host or just user. (Note that if the name in the access list is just user, access is given to anyone on your network with that user name.) If you are using the NIS or DNS system, make sure your name in the access list is not listed in the form user@domain or user@name.domain.

   2. The owner of the calendar must remember to click SELECT on the Apply button on the Access List and Permissions Properties window.

      Check the user ID and group ID on both your workstation and the remote workstation. The user ID and group ID must be the same in both locations.

3. Determine your user ID and group ID on each workstation as follows:

   1. Look for your password entry in the file /etc/passwd.

      If you have an entry in this file, the user ID is the third field (the number between the second and third colons). The group ID is the fourth field (the number between the third and fourth colons). For example, if the entry for user Egret in the /etc/passwd file is:

      egret:X4y8r2Bg:3286:10:& West:/home/egret/:/bin/csh

      the user ID for user Egret is 3286, and the group ID is 10. The values of the user ID and group ID should be between 0 and 32767.

   2. If you are using the NIS system, and you do not have an entry in the file /etc/passwd and the last line of /etc/passwd starts with a `+', check for an entry in the NIS passwd entries. To determine your NIS user entry, type ypmatch username passwd in a Command Tool or Shell Tool.

      For example, to find the NIS password entry for user Egret, type:

      ypmatch egret passwd

      If the system responds with a user entry, the user ID is the third field, and the group ID is the fourth field.

Adding a Second Calendar on your Workstation

If you'd like to add a second calendar on your workstation, you need to create a dummy user for that calendar. For example, you might want to add a second calendar for appointments for your entire work group.

To create the dummy user and new calendar, use the following steps. These steps assume a basic understanding of UNIX system administration, so you may need to get some assistance. This assumes you are root.

1. Add a dummy entry in the /etc/passwd file of the workstation where you want to create the second calendar.

   You need to specify a name, a dummy user ID, and so forth.

2. Bring down the cm and rpc.cmsd processes.

3. Log in as the new dummy user, and start a new Calendar Manager.

4. Edit the access list and permissions for your group.

5. Add the calendar name to the browse list.

6. Log out, and log back in with your own login.

   You can now browse the new calendar.

Sharing Calendars Across Workstations

If you move around from workstation to workstation, and you want to always be able to access your real Calendar, you need to have Calendar Manager running on each workstation. Use the following steps to set up access to your calendar from multiple workstations:

1. On your primary workstation, give full access list permissions to your calendars at the remote workstations.

   For example, suppose user Egret has his real calendar on the workstation named "work", and also accounts and calendars on remote workstations named "sea" and "ocean". He would add egret@sea and egret@ocean to his calendar access list, and give these users full Browse, Insert, and Delete permissions. See the section Chapter 5, Calendar Manager, for instructions.

2. When you are logged in at the remote workstations, browse your real calendar.

   Since you have full access permissions, you can read all your appointments, change your appointments, and so forth.

   In the previous example, when Egret is logged in to "sea" or "ocean" he can browse the calendar egret@work to access his real calendar.

   ---

   Note -

   Do not mount the /usr/spool/calendar directory from a remote disk. Doing so may result in loss of Calendar data.

   ---

Running Different Versions of OpenWindows and Calendar Manager

If you run an older version of OpenWindows after running the current version of OpenWindows, the older version of Calendar Manager will not be able to read your appointment data file. To avoid this problem, back up the following file before starting the current version of Calendar Manager: usr/spool/calendar/callog.<user>.

Before you return to an older version of Calendar Manager, restore your old file making sure you maintain the permissions on the directory and file. If you browse a calendar that is running a different version from your own, it should work.