SUMMARY: setting up calendar manager on a network

From: Danielle Sanine (danielle@systems.caltech.edu)
Date: Fri Oct 09 1992 - 01:31:19 CDT


Sun Managers,

I got quite a few helpful suggestions, some scripts and half a dozen
"me, too, please summarize" pleas, so I have included the actual
responses below. They have been edited to delete repetitions of my
original question unless it was necessary for clarity. Thanks to
everyone who responded for all your help and to Rochelle Fong at Sun
for walking me through the final fix.

The consensus on the calendar manager seems to be that it is not a very
robust program and that it was not designed to function in the way I
wanted it to, namely to allow a user to access and use their calendar
from any machine. The advice on the best way to achieve this goal was
somewhat mixed. Most respondants said DON'T mount /var/spool/calendar
around, though one did indicate that they had been doing this
successfully for a long time. It did not seem to matter whether you
run rpc.cmsd on each machine or not. Basically there were two
solutions. One was to rename the cm program, write a shell script
named cm that ran a remote shell on a calendar manager "server", then
executed the renamed cm program. You also had to be sure that each
user's .cm.rc file pointed to user@server. This ensured that users
always accessed their calendars from the "server". I tried this first
and ran into all kinds of problems with "permission denied" error msgs
when users did not have their .rhosts files set up and problems with
user's calendars popping up on remote machines because they ran the
script from a window where they were remotely logged into the other
machine.

After half a day of hassling with it, I opted for solution #2, which
was to edit everyone's .cm.rc file so that Calendar.DefaultCal pointed
to user@server, and change their Access List and Permissions (under
Edit/Properties) to show user@client with BID (browse, insert, delete)
permissions for any client machine the user wanted to access their
calendar from. This worked just fine and was a cleaner fix, I thought,
than renaming cm, etc. One note to those who also take this route: be
SURE the user sets all this up by running cm from the _server_.
Thereafter they can run cm from anywhere, but if you try to set it up
from a client, the change will be made in /var/spool/calendar on the
client which won't have the desired results.

Here is my original plea followed by the responses:

>I have a lab of ELCs, SS 2's and IPXs all running 4.1.1b. I recently
>upgraded to OW version 3. The lab is set up so that any student may
>use any machine. This is causing problems with the calendar manager.
>First, students got messages saying that install_cmgr must be run. I
>ran it on all machines. Now we have problems where opening your
>calendar on a new machine either displays a blank calendar or only
>shows appointments and gives the error "access denied" when you try
>to insert. I realize that these problems are caused by having
>seperate /var/spool/calendar directories on all the machines and
>by the permissions set in the individual's calendars. Fixing the
>problem looks a little tricky since I have callog's and .calbak's
>for each user on each machine's /var/spool/calendar at this point.
>I tried copying them over and displaying the calendar, but it did
>not work.

>My questions are:
>
>1) How do most people set this up so that a user can log in anywhere
>and use their calendar? Is it enough to have /var/spool/calendar
>mounted from a server?
>
>2) Should I have run install_cmgr on all machines? I have had con-
>flicting advice on this..
>
>>3) Is there a global default that can be set up such that the default
>is to point to "userid" rather than "userid@machine"?
>
>For the record, I searched the AnswerBook and read everything it had
>on the calendar manager, but it assumes that you want to access
>different calendars from different machines, not the scenario I have.
>>
>All help is greatly appreciated. RTFMs are fine to if you can point
>out where.
>
>Thanks in advance,
>
>Danielle Sanine
>danielle@systems.caltech.edu
>
======================================================
>From jaa101@barton.anu.edu.au Mon Oct 5 15:55:55 1992
From: jaa101@barton.anu.edu.au (James Ashton)
Subject: Re: setting up calendar manager on a network
To: danielle@systems.caltech.edu
Date: Tue, 6 Oct 92 8:55:37 EST
X-Mailer: ELM [version 2.3 PL11]
Content-Length: 1166
Status: RO
X-Lines: 24

...
>1) How do most people set this up so that a user can log in anywhere
>and use their calendar? Is it enough to have /var/spool/calendar
>mounted from a server?

I don't know if the above will work or not but I suspect that multiple
calendar managers on the same spool directory is a recipe for
disaster. The solution we use to the same problem is to install on one
machine only, one with /usr/spool/calendar on a local filesystem. Then
move /usr/openwin/bin/cm to `cm.real' and replace it with the following
script. You'll need `xrsh' set up for this to work.

        #!/bin/sh
        xrsh calendar_host cm.real "$@"

If there's a better solution, I'm eager to see it in the summary. If
not I hope Sun provides for a cleaner fix in the future since it seems
to be a problem many sites would face.
______________________________________________________________________________
James Ashton System Administrator
                                             Department of Systems Engineering
Voice +61 6 249 0681 Research School of Physical Sciences and Engineering
FAX +61 6 249 2698 Australian National University
Email James.Ashton@syseng.anu.edu.au GPO Box 4 Canberra ACT 2601 Australia
=======================================================

>From david@capmkt.com Mon Oct 5 16:32:36 1992
Date: Mon, 5 Oct 92 16:32:10 PDT
From: david@capmkt.com
To: danielle@systems.caltech.edu
Subject: Re: setting up calendar manager on a network
Content-Length: 521
Status: RO
X-Lines: 13

I just fixed this problem here this afternoon.
The problem was that both "rcp.cmsd" and
"inetd" had gotten partially wedged, and we
had to kill (kill -1 $pid) and restart both of them.

Hope this helps,
David

-------------------------------------------------------------------
David Mostardi Email: david@capmkt.com
Senior Support & Systems Manager Phone: (510) 540-6400
Capital Market Technology, Inc. FAX: (510) 540-5505
1995 University Ave. #390, Berkeley CA 94704
================================================================

>From sam@john-bigboote.ICS.UCI.EDU Mon Oct 5 18:43:04 1992
To: danielle@systems.caltech.edu
Subject: Re: setting up calendar manager on a network
Newsgroups: fa.sun-managers
Date: Mon, 05 Oct 92 18:12:43 -0700
From: Sam Horrocks <sam@john-bigboote.ICS.UCI.EDU>
Content-Length: 2555
Status: RO
X-Lines: 60

It's a general problem with calendar manager. I think the official Sun
way is to set up a calendar manager host which holds all of the files and
on which you run installl_cmgr so that rpc.cmsd runs. Then, everyone
edits their ~/.cm.rc file and adds:

    Calendar.CalendarList: <user>@<calendar manager host>

so that that host is always contacted to access the calander manager files.

At our site, I just wrote a proxy calendar manager program that runs
on every host and forwards calander manager requests back and forth
between the local host and a central calendar manager host. That way
no matter which host you contact you get the same files and you don't
run into the nightly update problem you have when running multiple
rpc.cmsd daemons on the same directory. If you're interested, I may
be able to send you the source code.

Sam

-- 
Sam Horrocks
ICS Department, UC Irvine
Email: sam@ics.uci.edu
=======================================================

>From rackow@antares.mcs.anl.gov Mon Oct 5 20:01:41 1992 To: danielle@systems.caltech.edu (Danielle Sanine) Subject: Re: setting up calendar manager on a network Date: Mon, 05 Oct 92 22:01:31 CDT From: Gene Rackow <rackow@antares.mcs.anl.gov> Content-Length: 570 Status: RO X-Lines: 10

Please let me know what you find out. I'm doing much of the same thing here. users should be able to put what calendars they want in theur .cm.rc file and user that as a point for reference. As to how they get the info into their cm, I think that they may have to install the right names in the permissions file of the cm. Basicly allow user@*.caltech.edu or some subdomain of that to have access to their cm files. I do not think you needed or should ahve run install_cmrg on all machines, it just makes for more of a mess as top where their stuff is located. =======================================================

>From csb@gdwb.OZ.AU Mon Oct 5 21:19:48 1992 Date: Tue, 6 Oct 1992 14:19:00 +1000 From: csb@gdwb.OZ.AU To: danielle@systems.caltech.edu Subject: Re: setting up calendar manager on a network Content-Length: 5222 Status: RO X-Lines: 124

My questions are: 1) How do most people set this up so that a user can log in anywhere and use their calendar? Is it enough to have /var/spool/calendar mounted from a server?

This works but there are other problems with it.

A better solution is to use the (limited) client-server capabilities of the calendar manager. Have local and remote calendars. However get your users to only use the remote calendar. The local one is bogus, it just stops a number of other problems that the calendar manager has. I can elaborate if you like. If you have dumb users having two calendars causes a great deal of confusion.

2) Should I have run install_cmgr on all machines? I have had con- flicting advice on this..

Yes you can. However all users calendars should point to the server machine. This screws up allocation permissions because the calendar manager properties will only modify the local permissions not the permissions on the server machine. These must be done by hand. 3) Is there a global default that can be set up such that the default is to point to "userid" rather than "userid@machine"? This is in the .cm.rc file in the users home directory we use this to point our users at the server.

Be warned the calendar manager is not robust, in fact it is still a load of crap. One day it will be real good. That day is not here yet. There are many many RFE's out on the calendar manager all hoping to make it a better product.

All help is greatly appreciated. RTFMs are fine to if you can point out where.

The manuals and the program just do not deal with large work groups. We have 100 suns and a server based calendar is the only way to go unfortunately the calendar manager it not quite there.

FYI, the following is a petition that was put together by Sun calendar manager users which I organised. I had 87 petitioners which represented over 10,000 installed suns.

[Actual petition deleted due to space considerations, but it is worth checking out. -DS]

=================================================== >From fallan@awadi.com.AU Mon Oct 5 21:20:34 1992 Date: Tue, 6 Oct 92 10:50:55 CST From: fallan@awadi.com.AU (Frank Allan (Network Manager)) To: danielle@systems.caltech.edu Subject: Re: setting up calendar manager on a network Cc: frank@awadi.com.AU Content-Length: 1232 Status: RO X-Lines: 36

Danielle

each user should have an entry in their .cm.rc file like this:

Calendar.DefaultCal: user@server

and /var/spool/calendar on the server should NOT be mounted on local machines. There is a problem when this is first setup and you need to have the following access entries in the callog.user file on the server:

(access read "user" ) (access write "user" ) (access delete "user" ) (access exec )

then whenever a user starts cm it reads the calendar on the server. I haven't found an easy way to do this other than editing the file, but once it is setup it is ok. Then the default user@server works from any machine.

At this stage there is no way to remove the entry for the local machine from the browse list, but it should not be used.

I have been using this setup for some months with no problems other than occassionally having to re-run install_cmgr

I have run install_cmgr multiple times on both servers and clients and it doesn't do any harm, but usually fixes the rpc.cmsd messages. This is yet another glitch with calendar manager.

Have you seen the Calendar manager petition which lists a number of gripes about CM which have been sent to Sun ? If not, let me know and I will send you a copy.

cheers ============================================================

>From Torsten.Lif@eos.ericsson.se Tue Oct 6 01:21:07 1992 Date: Tue, 6 Oct 92 08:25:40 +0100 From: Torsten.Lif@eos.ericsson.se (Torsten Lif) To: danielle@systems.caltech.edu Subject: Re: setting up calendar manager on a network Content-Length: 2199 Status: RO X-Lines: 53

In article AA12689@scrooge.systems.caltech.edu, danielle@systems.caltech.edu (Danielle Sanine) writes: >Dear Sun Managers, > >1) How do most people set this up so that a user can log in anywhere >and use their calendar? Is it enough to have /var/spool/calendar >mounted from a server?

No. I think this will cause file locking conflicts.

>2) Should I have run install_cmgr on all machines? I have had con- >flicting advice on this..

Yes, every host where cm is to run has to run the daemon. Just make sure you've installed the OpenWindows 3 version of rpc.cmsd, because the OW 2 version will croak at certain stuff put in the callog files by the OW 3 version

>3) Is there a global default that can be set up such that the default >is to point to "userid" rather than "userid@machine"?

I don't think so. You'll have to put "Calendar.DefaultCal: userid@machine" in each user's .cm.rc file. One way to simplify things a bit is to use the same machine (e.g. a mailer host) for all users. That way they can all browse each other's calendars without remembering Jack's and Jill's "home" machines. But they all have to set "access bid" for themselves@ALL hosts in order to be able to browse/insert/delete appointments for themselves from other machines. Also, "for my eyes only" appointments are invisible, even to myself, if I'm accessing the database from another host.

Another possibility is to run cm remote on the host where you keep the appointments. That way you need not have rpc.cmsd run on any other hosts but you need to set up some "wrapper" or trick so that when your users try to start cm, you really run a "rsh server cm -display client:0". And, of course, you need to set OPENWINHOME, LD_LIBRARY_PATH and path on the remote machine. And xhost on the local host. Let me know if you want an example of how to set this up.

cm is a fun tool but it needs some more perfecting. You either have to keep track of where every user's home machine is, or set up cm to always run on a specified host with some extra load for that machine.

Torsten Lif Ericsson Telecom AB, EO/ETX/TX/AD S-126 25 STOCKHOLM, SWEDEN Phone: +46 8 719 4881 =============================================================

>From matt@wbst845e.xerox.com Tue Oct 6 04:39:12 1992 Date: Tue, 6 Oct 1992 04:36:41 PDT From: matt@wbst845e.xerox.com (Matt Goheen) To: danielle@systems.caltech.edu Subject: Re: setting up calendar manager on a network Content-Length: 199 Status: RO X-Lines: 5

Replace the "cm" executable with a script that starts up the real cm on the "calendar manager server" (i.e. pick a machine). A good choice would be a machine that gets backed up regularly.

- Matt ===============================================================

>From montjoy@thor.ece.uc.EDU Tue Oct 6 04:49:26 1992 Date: 06 Oct 1992 07:49:03 -0400 (EDT) From: montjoy@thor.ece.uc.EDU (Robert Montjoy) Subject: Re: setting up calendar manager on a network To: danielle@systems.caltech.edu X-Envelope-To: danielle@systems.caltech.edu Content-Transfer-Encoding: 7BIT X-Mailer: ELM [version 2.3 PL11] Content-Length: 9913 Status: RO X-Lines: 298

HI..

Take a look at this script. It does what you want. Do not NFS mount /var/spool/calendar. You will run into lots of problems. Do setup a Centralized Calendar server(which is what this script does).

[Script was written by Neil Todd (see below) and was deleted due to space considerations. -DS]

-- Rob Montjoy - Rob.Montjoy@UC.Edu Computer Engineer - montjoy@ucbeh.BITNET University of Cincinnati - montjoy@babbage.ece.uc.edu Electrical and Computer Engineering - uunet!uceng!rmontjoy

-- The "Enviromental Destruction" President or a "Tax and Spend" President. This is a choice? =============================================================

>From N.C.Todd@bnr.co.uk Tue Oct 6 06:12:11 1992 From: N.C.Todd@bnr.co.uk Date: Tue, 6 Oct 92 14:11:16 BST To: danielle@systems.caltech.edu Subject: Re: setting up calendar manager on a network Newsgroups: info.sun-managers Organization: BNR Europe Limited, Harlow, GB Cc: Content-Length: 10160 Status: RO X-Lines: 303

In article <9210051818.AA12689@scrooge.systems.caltech.edu> you write: about calmgr.

Whilst I can not answer all your questions you might be interested in the script below. What I've got is a single calendar server host, whose calendars are accessed via the cm RPC, rather than by remotely mounting it. The remote mount gives all sorts of simultaneous update and permission denied type problems. I also tried to follow the same philosphy as we use for email, basiclly I'm interesting mailing 'user', I don't care where 'user' happens to be sitting.

Oh, I don't think that you need to run install_cm everywhere, just on the calendar host. Although we do run the rpc.cmsd everywhere simple for the sake of symmetry.

Regards,

Neil

[ Script deleted due to space limitations, but if I get the author's permission, I will send it to anyone who is interested. -DS]

-- Neil Todd | ..In general, it is best to assume that the PSI%234237100122::neil | network is filled with malevolent entities neil@bnr.co.uk | that will send in packets designed to have BNR (Europe) Ltd | the worst possible effect... RFC 1122 ======================================================================

>From pbg@cs.brown.edu Tue Oct 6 06:12:33 1992 Date: Tue, 6 Oct 92 09:12:31 -0400 From: pbg@cs.brown.edu (Peter Galvin) To: danielle@systems.caltech.edu (Danielle Sanine) Subject: setting up calendar manager on a networ Content-Length: 676 Status: RO X-Lines: 14

We make everyone "browse" their calendars on our server. This way everyone has the same calendar and you know where someone else's calendar lives. The problem is you have to set permissions for each user to modify his/her own calendar on the server by mucking with the callog file for each, or running cm on the server and changing permissions.

--Peter

------------------------------------------ -------------------------------- Peter Baer Galvin (401) 863-7623 Systems Manager, Brown Univ. Comp. Sci. pbg@cs.brown.edu Box 1910 (115 Waterman Street) uunet!brunix!pbg Providence, RI 02912 (02906) pbg@browncs.bitnet

======================================================= >From scheller@asdi.saic.com Tue Oct 6 06:56:44 1992 Date: Tue, 6 Oct 92 06:55:45 PDT From: scheller@asdi.saic.com (Mark J. Scheller (+1.619.546.6519)) To: danielle@systems.caltech.edu Subject: Re: setting up calendar manager on a network Content-Length: 797 Status: RO X-Lines: 18

Yes, you should run install_cmgr on all machines.

We mount /var/spool/calendar from a server so that each user will have the same calendar regardless of what physical machine (s)he is on -- just like /var/spool/mail.

Hope this helps! mS (scheller@asdi.saic.com) ============================================================================== Science Applications International Corporation (SAIC) (619)546-6519 (Voice) 10260 Campus Point Dr. M/S-C3, San Diego, CA 92121 (619)546-6174 (FAX) | scheller@asdi.SAIC.COM | "Remember folks. Traffic lights timed for 35 mph ...{backbone}!asdi.SAIC.COM | are also timed for 70 mph." -- Jim Samuels !scheller | ------------------------------------------------------------------------------

=========================================================== >From Jonathan.C.Davis@acenet.auburn.edu Tue Oct 6 08:19:57 1992 Date: Tue, 6 Oct 92 10:19:51 CDT From: Jonathan C. Davis <Jonathan.C.Davis@acenet.auburn.edu> To: danielle@systems.caltech.edu Subject: Re: setting up calendar manager on a network Content-Length: 2716 Status: RO X-Lines: 62

Hi Danielle,

Calendar Manager is, indeed, a pain in the neck since it's tied to a single machine. It's caused us some headaches here with many of our "floating" users. A few years ago, when our departmental network was first starting out, it was easy enough to just mount /var/spool/calendar from one of our servers and be done with it. The problem, however, is that in order for this method to work /var/spool/calendar must be mounted with root permissions, and /etc/exports does not accept netgroups for root access and it also has a limit of eight machine-names for root access. Once our network grew beyond eight clients, we were out of luck.

Currently, we're running a type of front-end to cm which starts up cm remotely from our main server. It's not necessarily elegant, but it works for us and allows all our calendar manager files to be kept in one place.

First, I created a directory named CM (an arbitrary) name in /usr/openwin/bin and I moved /usr/openwin/bin/cm into that directory. Next, I replaced the binary /usr/openwin/bin/cm with the following csh script: (aces1 is the name of the calendar manager server)

---------- /usr/openwin/bin/csh ----------

#!/bin/csh # # cm jdavis 920430 # # Front-end for Calendar Manager to run a remote shell on the server. # This allows all calendar files to remain on the server. # if ( "`hostname`" != "aces1" ) then xhost +${USER}@acenet.auburn.edu > /dev/null rsh aces1 exec /usr/openwin/bin/cm `hostname` ${argv} else if ($#argv != 0) then setenv DISPLAY ${argv[1]}:0.0 shift endif exec /usr/openwin/bin/CM/cm ${argv} endif

---------- /usr/openwin/bin/csh ----------

Users are still able to start calendar manager by either entering "cm" (and any arguments they want) at a shelltool prompt or by using the workspace menus.

I discovered that in order for this method to work, both the front-end script and the binary program had to have the same name. This is because when a user saves his/her workspace, the binary name rather than the script-name is written to ~/.openwin-init. This is why I found it easiest to just move the binary to a place not in anyone's path. (In effect, this is fooling OpenWindows.)

Hope this helps. Let me know if I can answer any questions.

-jonathan =============================================================================== Jonathan C. Davis | Alabama Cooperative Extension Service Manager, Network Support | 218 Duncan Hall INTERNET: jdavis@acenet.auburn.edu | Auburn University, AL 36849-5646 VOICE: 205-844-9660 | FAX: 205-844-9650 =============================================================================== ========================================================= >From ncf@tngstar.cray.com Tue Oct 6 08:34:29 1992 Date: Tue, 6 Oct 92 10:32:37 CDT From: ncf@tngstar.cray.com (Nicholas Franco) To: danielle@systems.caltech.edu Subject: RE: setting up calendar manager Content-Length: 3208 Status: RO X-Lines: 81

Danielle,

I have 40 slc's and had the same problem. The solution I use is to cross mount /var/spool/calendar from a server to all 40 slc's. This works without a problem and in the compnay we do the same thing for over 700 slc's. I automount the /var/spool/calendar directory so that it is only mounted when someone is using the calendar. The mount apears in a direct map.

Concerning install_cmgr, yes you should have run it on all the machines. What install_cmgr does is to append a line on the end of inetd.conf so that rpc.cmsd will be started by inetd when you access the calendar. I guess I should qualify this, if all of your systems have disks then you should have run it on them. This is spelled out in the OW install and start-up guide.

There is no global default that will get around this problem that I know of. I believe that some of the larger groups here at Cray complained to Sun about having to work around the problem this way. I guess if you want to see a change then you should do the same.

You should be able to copy the callog.uid and the .calbak.uid files to a different system and have them run. I just tried this to make sure that it worked. The only thing that I can think of to check is permissions. Make the file world readable and see if you can bring it up. If you can't then something strange is going on.

Hope this helps.

--- Nicholas C. Franco ncf@cray.com Software Information Services 612-683-3830 Cray Research Inc.

============================================================ >From miker@sbcoc.com Tue Oct 6 11:29:31 1992 Date: Tue, 6 Oct 92 11:47:15 CDT From: Mike Raffety <miker@sbcoc.com> X-Organization: Swiss Bank Corporation To: danielle@systems.caltech.edu Subject: Re: setting up calendar manager on a network Content-Length: 790 X-Lines: 20 Status: RO

> 1) How do most people set this up so that a user can log in anywhere > and use their calendar? Is it enough to have /var/spool/calendar > mounted from a server?

DON'T DO THIS! cmsd is NOT doing any NFS file locking.

> 2) Should I have run install_cmgr on all machines? I have had con- > flicting advice on this..

If you want people to be able to log on to any machine, and get their calendar, no. You should have run it on ONE server, and ...

> 3) Is there a global default that can be set up such that the default > is to point to "userid" rather than "userid@machine"?

Told everyone to use "userid@machine". You CAN set it to default to that; modify their .openwin-menu or .openwin-init to start "cm -c userid@machine".

Please be sure to summarize back to the list; thanks.

=========================================================

>From danny@ews7.dseg.ti.com Tue Oct 6 11:34:17 1992 Date: Tue, 6 Oct 92 13:31:13 CDT From: danny@ews7.dseg.ti.com To: danielle@systems.caltech.edu Subject: Re: setting up calendar manager on a network Content-Length: 486 X-Lines: 11 Status: RO

2) yes,install_openwin or install_cmgr on all systems 1) do NOT mount calendars anywhere, in fact you should remove the calendar directory everywhere except on the master calendar system 3) if you edit the callog.name file manually, just grant access to "name" rather than "name@whatever" x) set Calendar.DefaultCal: username@mastersystem in each ~/.cm.rc xx) you will periodically have to kill the rpc.cmsd processes, both locallay and on the master calendar system



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:51 CDT