This is my tentative summary for the Calendar Manager question I
posted. I say tentative, cause no doubt a few of you are going to
roast/amend/enhance what I say here.
My original question:
Subject: Calendar Manager
Date: Mon, 27 Jan 92 12:52:10 -0600
From: Gregory Higgins <higgins@math.niu.edu>
I'm planning on mounting /var/spool/calendar on all workstations from
the same partition. If you know of any reason this shouldn't be done,
(ala /var/spool/mail), please let me know.
On the same subject: Does rpc.cmsd still have to be run on all systems
in this case?
Are there any std tools which will allow one to access the calendar data
from a std terminal command line?
Regarding the second question: We're not going to do this, so who cares?
Regarding the std tools question: There is under OW3 (cm_delete, cm_insert,
and cm_lookup), but not under OW2.
I have heard from some people who NFS mount the same calendar directory
everywhere and who seem to experience only minor problems. I've heard
from a lot more who said "It can't be done." I'm guessing that whether
this works or not for you depends on the amount of Calendar activity
you have. We are a small site (only 20 workstations), so I might be able
to get away with this. I chose not to. The solution I am using,
I borrowed heavily [stole unmercifully] from Jan H. Bohn@rdrc.rpi.edu.
His solution was posted to comp.windows.open-look the same day I asked
the question of the list. I have modified his solution some, but I
include his posting and two others below.
CAVEATS: I am running OW2 not OW3, there are differences. The postings
I have included were designed for OW3, so read them. My scripts
were designed for my site, your paths may vary. Also, not all
of my users are using OW, so I really can't generate the kind of
activity one needs to test this adequately. Finally, I've been able
to work on this only in bits and pieces, I don't think I forgot anything,
but who knows.
The solution:
0) Get everybody out of OW, shutdown all the rpc.cmsd s running,
designate one (trusted) machine as the cm server [let's suppose
this machine is called cmserver.your.local.domain, aka cmserver],
copy everybodys callog.user-name to the calendar directory of
cmserver, ensuring the permissions stay correct.
1) Create the shell script xrsh
#!/bin/csh -f
# Let this script be installed on the local machine (local):
# This script will start an OPENWIN application on $1 (remote),
# but will display the application on (local):
xhost $1 >& /dev/null
if (`hostname` == "$1") then
$argv[2-]
else
rsh $1 /usr/openwin/bin/openwin_REMOTE `hostname` $argv[2-]
endif
1a) The reason the cmserver needs to be trusted is that you are
xhosting it in the script above. This means that not only can that
machine send you cm, it can also put anything it wants to your
screen, or read anything it wants from your screen.
2) Create the shell script openwin_REMOTE
#!/bin/csh -f
# Let this script be installed on the remote server (remote):
# This will start up a OPENWIN application on the remote and display
# on the local machine
setenv DISPLAY $1':0.0'
setenv OPENWINHOME /usr/openwin
setenv LD_LIBRARY_PATH $OPENWINHOME/lib
set path = ($OPENWINHOME/bin{,/xview} $path)
$argv[2-] &
2a) The above (which I borrowed) is pretty neat. I imagine that with a
few minor modifications (or even just as it is), it could be used for
all sorts of things. I've already started thinking about modifying
myxrsh to require both a host and a newsserverstr.
3) I chose to put these in /usr/openwin/bin in violation of my general
rules for software. There's nothing magic about the location.
4) Modify /usr/openwin/lib/Xinitrc (for new users )
find the line which says
$HOME/.openwin-init
and change it to
cat $HOME/.openwin-init|sed 's/^cm /xrsh cmserver cm /'|/bin/sh
4a) This is necessary since under OW2 at least, I can't find any way
to control what SAVE_WORKSPACE writes to the file $HOME/.openwin-init
5) For each user, modify the local copy of .xinitrc to have the
same change as 4).
5a) This assumes your using the standard .xinitrc which OW2 sticks in
the users home directory. If you're not, you'll need to decide
for yourself what change you need.
6) Modify /usr/openwin/lib/openwin-menu
find the line which says
"Calendar Manager..." exec $OPENWINHOME/bin/cm
and change it to
"Calendar Manager..." exec $OPENWINHOME/bin/xrsh cmserver cm
7) Unless you particularly enjoy being bugged every 30 seconds,
let your users back on.
8) There's nothing magical about doing it all at once, I think you
can do it incrementally just as easily. (Maybe easier if you
have dozens of users or more)
9) This still doesn't prevent users from doing a cm & from the
command line. Most of mine will listen if I tell them "Don't!",
so I'm going to ignore this possibility.
Some responses I found particularly helpful in implementing and
deciding to implement this particular approach are below:
************************************************************************
Newsgroups: comp.windows.open-look
From: bohn@ptolemy0.rdrc.rpi.edu (Jan Bohn)
Subject: Calendar Manager problems
Message-ID: <pj7rm9k@rpi.edu>
Organization: Rensselaer Polytechnic Institute, Troy NY
Date: 27 Jan 92 07:01:15 GMT
Lines: 58
One way to get around the problem of cm on multiple workstations
is to designate a permanent machine on which everyone runs cm.
One can then make use of the X in Openwindows to operate the program
as if it was running on the local machine. In fact, this way one can
extend the life of SUN3's which only can run OW2 --- the new OL3
applications can be run on a SPARC with OW3 and display on the SUN3.
Here are some scripts:
xrsh:
=====
#!/bin/csh -f
# Let this script be installed on the local machine xxx.xxx.com (local):
# This script will start an OPENWIN3 application on yyy.yyy.com (remote),
# but will display the application on xxx.xxx.com (local):
xhost +
if (`hostname` == "yyy.yyy.com") then
$argv[1-]
else
rsh yyy.yyy.com openwin3_REMOTE `hostname` $argv[1-]
endif
openwin3_REMOTE:
================
#!/bin/csh -f
# Let this script be installed on the remote server yyy.yyy.com (remote):
# This will start up a OPENWIN3 application on the remote and display
# on the local (xxx.xxx.com):
setenv DISPLAY $1':0.0'
setenv OPENWINHOME /usr/openwin3
setenv LD_LIBRARY_PATH $OPENWINHOME/lib
set path = ($OPENWINHOME/bin{,/xview} $path)
$argv[2-] &
In the file .openwin-init:
==========================
OW2:
----xrsh cm -i 2 -Wp 169 134 -Ws 640 690 -WP 1011 3 -Wi -fg "black" -bg "white" &
OW3: ----
toolwait xrsh cm -i 2 -Wp 245 117 -Ws 730 690 -WP 1011 3 -Wi -fg black -bg white
================================================================================
Good Luck !!!
Jan H. Bohn bohn@rdrc.rpi.edu ******************************************************************************* *******************************************************************************
From: matthew@sunpix.East.Sun.COM (Matthew Stier - Sun Video and Imaging Products) Newsgroups: comp.windows.open-look Subject: Re: Calendar Manager, /var/spool/calendar ownership problems Message-ID: <5727@southeast.East.Sun.COM> Date: 22 Jan 92 16:30:11 GMT References: <1992Jan21.141357.1896@bmw.mayo.edu> <1992@fang.dsto.oz> Organization: Sun Microsystems, Research Triangle Park, NC Lines: 63
[*********I have deleted included messages - EGH ******************]
This is the solution we use at our site (sunpix.east.sun.com).
After having a few disk SparcStation local disk crash after a power outage. Our sysadm decided to provide a way to backup calendars, in the same manner he was backing up mail. [note: this works for OW 3.0. OW 2.0 is untested]
1) Create the '/var/spool/calendar' directory on the machine that will be the cm host (hence forth know as 'cmhost').
2) Foreach user, have the users complete all changes in progress.
3) Have each user bring up the properties editor (Edit -> Properties).
4) Under "Catagory:", select 'Display Settings'. For 'Default Calendar", enter "user@cmhost" and (Apply) the changes. [of course "user" is the users name, and cmhost is the host that the calendars will be placed on.]
For me, I entered 'matthew@sunpix'.
5) Under "Catagory:", select 'Access List and Permissions'. Next to the (Calendar) button, enter the user's name. For Permissions, select the Browse, Insert, and Delete buttons. Now press the (Calendar) and (Apply) buttons. This will give the user all Browse, Insert, and Delete permissions.
For me, I entered "matthew" on the line next to the (Calendar) button, and then pressed Browse, Insert, Delete, Calendar, and Apply.
6) Quit the calendar manager.
7) Copy the calendar to the cmhost. [rcp /var/spool/calendar/callog.$USER cmhost:/var/spool/calendar]
8) Ensure that the permissions on the new file are correct. [rsh cmhost "chmod 460 /var/spool/calendar/callog.$USER"]
9) Have the user start and use a new calendar manager.
10) Instruct the user to ignore the "user@hostname" entry under the (Browse) button.
-- Matthew Lee Stier | Sun Microsystems --- RTP, NC 27709-3447 | "Wisconsin Escapee" Email: matthew.stier@East.Sun.COM | Phone: (919) 469-8300 fax: (919) 460-8355 |
****************************************************************************** ******************************************************************************
From: Bryan McDonald <bigmac@erg.sri.com>
The cm process wants a local rpc.cmsd. The local rpc.cmsd thinks that everything it can see locally is under its control, no matter what. If you mount your /var/spool/calendar on all your machines, you will have all your machines writing into the data files without any coordination, resulting in race conditions. The only way to centralize the spool that I have found is very disgusting, and it involves mounting the spool from a central source, but not named /var/spool/calendar, then linking into it, but not directly. I have to make separate subdirs for each user, then link each users machine to the subdir.
******************************************************************************
Thanks to all who replied, and to those who posted to comp.windows.open-look. chuck@fsg.com (Chuck Yerkes) "John D. Barlow" <John.D.Barlow@arp.anu.edu.au> pomeranz@isis.dccs.upenn.edu (Hal Pomeranz) zjat02@trc.amoco.com (Jon A. Tankersley) caxwgk@pki-nbg.philips.de (Wolfgang Kuehnel ) reynolds@icgmfg.mke.ab.com (Michael D. Reynolds) sutton@luke.ATdiv.Lanl.GOV (John Sutton) neptune@diamond.ICD.Teradyne.COM (Alan Steele) kla!brandari%sunra@Sun.COM (Paul Brandariz x6546) Mike Raffety <miker@sbcoc.com> Claus Assmann <ca@idefix.informatik.uni-kiel.dbp.de> todd@petadmin.wustl.edu (Todd Gamble) vdp@mayo.edu (Vinayak Dutt, Graduate Student (Biophysics)) wjm@itd.dsto.oz.au (Wayne Mildren) eric@redwood06.cray.com (Eric Markwardt) matthew@sunpix.East.Sun.COM (Matthew Stier - Sun Video and Imaging Products) imp@solbourne.com (Warner Losh) johnm@oakhill.sps.mot.com (John Morris) marc@hemlock.cray.com (Marc Bouron) rhaar@albert.cs.gmr.com (Bob Haar) edsr!jcn@uunet.UU.NET (Jim Niemann) csb@gdwb.oz.au (Craig Bishop) doehr@magellan.den.mmc.com (Brett B. Doehr) bohn@ptolemy0.rdrc.rpi.edu (Jan Bohn) nannette@canrith.Eng.Sun.COM (Nannette Simpson) justice@dao.nrc.ca (Gerald Justice) Liza Weissler <liza%moose@rand.org> Dave Plummer <dlp@mph.sm.ucl.ac.uk> jeffy@teda.EDA.Teradyne.COM (Jeffrey Youngstrom) Mario Nigrovic <mario@wdc.sps.mot.com> trdlnk!mike@uunet.UU.NET (Michael Sullivan) paulo%dcc.unicamp.ansp.br@UICVM.UIC.EDU (Paulo L. de Geus) Debbie McGlade <debbie@cs.odu.edu> tgsmith@spdev.East.Sun.COM (Timothy G. Smith - Special Projects) Bryan McDonald <bigmac@erg.sri.com> Paul Gill <paul@concour.cs.concordia.ca> blc@sol.med.ge.com (Brett Chapman x7-4391) kevin@toad.com
Gregory Higgins, Systems Manager, math.niu.edu
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:35 CDT