ks@tut.fi (Syst{ Kari) (10/09/90)
In article <FITZ.90Sep30162841@dirt.frc.ri.cmu.edu> fitz@frc2.frc.ri.cmu.edu (Kerien Fitzpatrick) writes: > How are others handling the way that the Calendar Manager wants to > write files to /var/spool/calendar on whatever host you are currently > logged in to? Are people mounting via NFS? Good points/bad points? I've now used a common /var/spool/calendar for a week ot two. Today I found two problems: 1) The client (rpc.cmsd actually) seems to need a root access to the filesystem containing /var/spool/calendar. 2) Today we tested the browsing of other user's calendar and permissions. After that by OWN two calendar-tools on different hosts seem to have a different view to my calendar. The one running on file-server sees only the entries added today. ls-command on both sides tells that the callog-files have equal size, so it is not a NFS-problem. The file is the same for both hosts, but the deamons have different behaviours. BTW: Both hosts do have the root access. Any ideas ? Currently, I thing that the best solution is to run calendar-managers only on one host. The user should change his/her root-menu so that cm is started automatically on the desired host. -- This article represents my personal views. Quote of the year: "X is the Fortran of windowing systems." Kari Systa, Tampere Univ. Technology, Box 527, 33101 Tampere, Finland work: +358 31 162585 fax: +358 31 162913 home: +358 31 177412
cjc@ulysses.att.com (Chris Calabrese) (10/10/90)
In article <KS.90Oct9135811@karikukko.tut.fi> ks@tut.fi (Syst{ Kari) writes: [ stuff about sharing /var/spool/canendar among workstations delted ] >Currently, I thing that the best solution is to run calendar-managers >only on one host. The user should change his/her root-menu so that >cm is started automatically on the desired host. That's what we've done here. Here's the line from my .openwin-init: "Calandar Manager..." rcmd xanthus '(. /home/cjc/bin/x && cm)' rcmd is a script that puts the named machine into the hosts table and then calls rsh for the command part, but with stdout and stderr directed to /dev/null so that all the rsh's won't hang around waiting for the command to finish running. It, and other similar scripts, are available on the net. /home/cjc/bin/x is a script which sets the LD_LIBRARY_PATH, PATH HELPPATH, and XAPPLRESDIR to the appropriate values (take a look at the openwin script). Name: Christopher J. Calabrese Brain loaned to: AT&T Bell Laboratories, Murray Hill, NJ att!ulysses!cjc cjc@ulysses.att.com Obligatory Quote: ``pher - gr. vb. to schlep. phospher - to schlep light.philosopher - to schlep thoughts.''
ks@tut.fi (Syst{ Kari) (10/12/90)
Today I discovered a new problem in Calendar Tool. My callog-files was overwitten last nigth (4am), and most of my appointments were lost. This might have something to do to the fact that all our computers share the same /var/spool/calendar. So, be warned, don't trust on calendar tool if you have o common NFS-mounted /var/spool/calendar. PS. I would be glad to see the Sun's comment on the /var/spool/calendar issue ! -- This article represents my personal views. NeWS flash: "X is the Fortran of windowing systems." Kari Systa, Tampere Univ. Technology, Box 527, 33101 Tampere, Finland work: +358 31 162585 fax: +358 31 162913 home: +358 31 177412
nannette@xebra.Eng.Sun.COM (Nannette Simpson) (10/18/90)
In article <KS.90Oct12104652@karikukko.tut.fi> ks@tut.fi (Syst{ Kari) writes: > > >Today I discovered a new problem in Calendar Tool. > >My callog-files was overwitten last nigth (4am), and most of my appointments >were lost. This might have something to do to the fact that all our >computers share the same /var/spool/calendar. > >So, be warned, don't trust on calendar tool if you have o common NFS-mounted >/var/spool/calendar. > >PS. I would be glad to see the Sun's comment on the /var/spool/calendar issue ! > > > >-- >This article represents my personal views. >NeWS flash: "X is the Fortran of windowing systems." >Kari Systa, Tampere Univ. Technology, Box 527, 33101 Tampere, Finland >work: +358 31 162585 fax: +358 31 162913 home: +358 31 177412 The problem is that there are separate daemon processes running on each machine that you've logged into, each mounting the same backing file (callog file): _________ _________ _________ A B C --------- --------- --------- rpc.cmsd rpc.cmsd rpc.cmsd | | | | | | _________________________________________ server: callog file _________________________________________ Every one of these daemons will wake up to garbage collect its data structure back into the callog file. It's a lot like vi- the last one "wins" and becomes the "truth." If you truly want to keep your calendar data in one location and travel from machine to machine, I recommend the following: 1. Mount the callog files onto your "primary" machine. 2. From your primary machine, give Browse, Insert & Delete access to yourself on the other machines. 3. When you're working on one of the other machines, Browse your calendar from that machine so that all transactions go through your primary machine. For instance: 1. I am "nannette@xebra." My callog file resides on my workstation, xebra. 2. From xebra, I give "nannette@foo, nannette@bar" all privileges to my calendar. 3. When I log into foo or bar, I can browse "nannette@xebra" and transact it just as if I were on my primary machine. Admittedly, this is cumbersome for those of you running in a primarly shared workstation environment. But this procedure will ensure that you will not lose data. Suggestions are always welcome. -- Nannette Simpson Internet: nannette@Eng.Sun.COM Sun Microsystems, Inc. UUCP: ...!sun!nannette 2550 Garcia Ave. MS 1-40 Phone: (415) 336-2969 Mountain View, CA 94043