PSEUDO- Calendar Manager Insert Permission
2007-12-25 8:23:00
> Hi, all --
>
> I'm having the following problem on an LX running OS 5.2, OW 3.2:
>
> I'm not a calendar manager user, so I don't have a callog file for
> myself. This problem does happen to one of my customers, though,
> who had her 4.1.x callog and .calbak files restored when she got
> her LX. I have two other Solaris 2.2 users on the network who had
> their files restored from 4.1.x and are using cm successfully.
>
> Anyway, the problem is that I can't insert appointments into my
> own calendar. I can browse and I can delete, but I can't insert.
> I get a popup saying, "You do not have insert access to calendar:
> lbd@surya" (that's me, on the local machine). The appointments window,
> however, indicates that I do have insert access. Deletions, however,
> do show up in the callog file.
Thanks to the following people for your ideas, though I'm afraid
the workaround I ended up using wasn't among them:
Andrew Lister (lister@sydtsg.cv.com)
Pat Cain (pjc@denver.ssds.com)
I'll list their responses at the end of this e-mail.
Pat mentioned the possibility of a calendar manager patch for Solaris 2.2
that I can't find on Sun's BBS. All they have is one for 4.1.x. Pat, might
you have a number for the 2.2 patch?
I ended up having to manually edit the callog file and add the
access permissions I wanted. My user's original file had this:
(access read "world" )
(access write )
(access delete )
(access exec )
I changed them thusly:
(access read "user@machine" "world" )
(access write "user@machine" )
(access delete "user@machine" )
(access exec )
Now we can insert to our heart's content. However, it's still a mystery
to me why I had to do this by hand. Cm should have done it for me in the
properties menu. Then again, it also seems odd that the correct definitions
weren't already there, since the callog file was restored from the 4.1.x
machine (where it worked fine). I would think she would have had the same
problem in the older OS.
I still have problems with cm if I either don't already have a callog file
or the file that's there is empty. I ran rpc.cmsd in standalone, debug mode
and here's what I got from it:
With a zero-length file:
# /usr/openwin/bin/rpc.cmsd -s -d
rtable_ping_4 called
rtable_get_access_4 called
mmap: Invalid argument
rpc.cmsd: syntax error
at line 0
rpc.cmsd: rbsize=0
Access: world(r__)
register_callback_4 called
lbd@surya.cnet.att.com requested registration on lbd. registered pid= 15472
lbd@surya.cnet.att.com registered on lbd
number of registered clients on lbd=1
rtable_lookup_next_reminder_4 called
Next reminder after Tue Jul 20 10:59:02 1993
--- Active Reminder Queue ---
rtable_ping_4 called
rtable_abbreviated_lookup_range_4 called
Range lookup from Wed Jun 30 23:59:59 1993 to Sun Aug 15 00:00:00 1993
rtable_internal_range: total = 0, skipped = 0
rtable_internal_range: 0 call to next_tick
rtable_internal_range: next_tick calls skipped 0
Found 0 entries in range lookup
With no file:
# /usr/openwin/bin/rpc.cmsd -s -d
rtable_ping_4 called
rtable_get_access_4 called
rpc.cmsd: file /usr/spool/calendar/callog.lbd does not exist
register_callback_4 called
rpc.cmsd: file /usr/spool/calendar/callog.lbd does not exist
rtable_create_4 called
rtable_ping_4 called
rtable_abbreviated_lookup_range_4 called
rpc.cmsd: file /usr/spool/calendar/callog.lbd does not exist
In either case, I can't do anything with it -- insert appointments, modify
access permissions, nothing.
So, we've got it working for anyone who used to use it under 4.1.x,
but G-d help anyone who starts using it for the first time...:/
Leslie Dreyer Kalra
AT&T Bell Labs
Allentown, PA
(Usual disclaimers apply)
===========================================================================
Here are the responses I got:
-------------------------------------------------------------------------
I'd try removing the ~/.cm.rc file before starting cm and then resetting the
properties from within calendar manager.
Andrew Lister
-------------------------------------------------------------------------
You were on the right track when you went to "Properties".
It is important to SELECT your calendar before you moidify the permissions
for it. Here is what I used as a workaround:
Select Edit/Properties
Select the WORLD entry
(memeory fades - is there a list of calendars on screen? if so, select yours)
Change the "WORLD" entry to JUST YOURSELF. Change it to full perms.
Close the calendar manager
Open a new one
THings should be better, and now you can ADD world Browse.
pjc
Pat Cain
SSDS, Inc.
-------------------------------------------------------------------------
Other suggestions:
Get the calendar manager patch from Sun.
I think we're running a patched version of the 4.1.3 servers,
and a patched version on the Solaris 2.2 clients.
Also:
Don't use host names when specifying a user. It restricts them
from modifying their own cm files from a different host, and potentially
makes things less robust.
See if you can change "world" to "BID" permissions, and see
if it stays that way. That will tell you if the thing
will support ANY changes...
BTW - am I correct in stating that you restored an old cm file?
the permissions on the file should read -r--rw---- , UID=user, GID=daemon.
Pat Cain
-------------------------------------------------------------------------
Perhaps you could try killing and restarting the daemon rpc.cmsd but you've
probably already done this.
I also know of a jumbo patch I once had to apply for a user but their
actual problem I was not told. This may have been something to do
with it. Unfortunately, it was at another site and I have no documentation
on the patch other than we obtained it from Sun.
Has the user's login or machine changed? (I lost the original message)
- this can cause problems.......
Here is some more information I found:
If the user is in the NIS maps on either machine, then everything
should be a-ok (assuming both machines are in the same domain). If
the user doing the inserting is only known to his local machine, that's
where CM will not allow the insert. CM does a double check to make
sure the user is known on the remote machine as well as the local machine.
Since the user is not known on the remote machine, it fails.
Workaround: add the user doing the inserts to the remote machine's
/etc/passwd file or to the NIS maps. Then restart the rpc.cmsd daemon
on the machine who's /etc/passwd was modified.
That's about it - hope it helps
Andrew
-------------------------------------------------------------------------
Comments
Got something to say?
You must be logged in to post a comment.
