[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kdm
From:       Ravi <ravi () kde ! org>
Date:       2003-09-09 19:39:03
[Download RAW message or body]

Hello,
  Sorry about the late reply. Had no access to email yesterday.

> [don't remove jirka from the cc:!]
Apologies again. Did not notice.

> > > /var/lib/dm/users/<name>.{face,face.icon,dmrc}
> > >  -> global face and saved session choice location
> >
> > What does this mean? If this is stuff per user,
>
> it is.
>
> > it should stay in the user's home directory.
>
> a) explain this to AFS.
>    (hmm, in fact, this means that users cannot own their dmrc files in
>    this scenario ...)
> b) explain this to the admins that don't want to allow their users to
>    set their face arbitrarily.

Ok. In this case, I see two pseudo-solutions, neither of which is 
satisfactory:
  1. This data is not really user modifiable, i.e., it is modified only by the 
sysadmin. Looking at other similar data (login name, password, etc), we could 
make this come off an NIS map (or rely on nsswitch.conf), i.e., use the same 
mechanism as everything else that KDM uses.
  2. Separate file for this alone which is configurable. This way, we put the 
decision in the sysadmin's hands. The face data (pics, etc.) may reside 
anywhere so long as the file contains a path through which the data is 
accessible. In this case, we have (at least) two directories where the pics 
reside: one under $KDEDIR for KDE-installed pics, and another site-specific 
one for site-specific pics (modeled on emacs startup file scheme).

> > In many networks (including mine), /var is not an NFS-mounted
> > partition but /usr and /opt (which usually contain $KDEDIR) are.
> > Storing persistent user data in /var is not an option.
>
> hmm, indeed ... this is prolly what
>   --sharedstatedir=DIR   modifiable architecture-independent data
> [PREFIX/com] is supposed to be good for ... too bad that i haven't seen
> this on a single system ... :}

Agreed. Not an option in the near term.

Regards,
Ravi

[prev in list] [next in list] [prev in thread] [next in thread]