[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

preconfiguration on the user side and its maintenance



C. Gatzemeier wrote:
Am Sunday 03 October 2004 16:04 schrieb Finn-Arne Johansen:

Problem is that you have to set up the username as well, and this changes for each user. The same with password. Will it work to provide all the other things, and will the username then be set automagically.


At least kde3 supports shell expansion. (Not sure about kde2) I appended an example to bug #550.

I see this kmailrc thing as a special case of a more general problem,
for which i haven't seen a solution in Skolelinux yet.
[Maybe i just didn't look at the right place; then please point me (and
 others) right to it ;-) ]

Kmail is just _one_ 'client'-program; there are -- and will be --
others*, that _need_ a proper user-specific configuration before they
work "out of the box" like the servers/daemons (for which there are
proper preconfigurations).
And not every program is 'inside' KDE so that one can make use of the
features of the KDE-rc system, regardless if it's the actual or future KDE.

*) Thinking esp. of 'config.-wise beasts' which are more environments
than just-another-application like Mozilla and family, OOo, KDE
[starting with desktop wizard and _language_selection_ :-(], Evolution,
etc.; but console programs too like mutt, emacs (auctex), irssi etc.

And we want _system_wide_ out of the box preconfiguration, don't we?

At least some of this user-specific things can't be done by just copying
files from /etc/skel/ to $HOME. Regarding this, /etc/skel/ is like an
image, but one needs a template [also?/instead?].

So what I would like to see is a hook in the process of creating $HOME
where one can link own scripts into it ...or cfengine-scripts.
"man adduser" says "/usr/local/sbin/adduser.local" is the hook to be
used. (...Is it really this the place to go for? Please read on...)

Ok, we can bump up our own scripts for adduser.local now; but with
'skolelinux - the system' or 'skolelinux - the distribution' and not
only 'our little installation here' in mind, a general concept and
policy have to be made up and agreed upon.

Answers to questions like the following have to be found:
 o  Where should this template directory lie?
 o  Do we go with an extra directory at all
    or just put 'template enhanced'* files in skel [too]?
    *) with "${USER}" and other 'variables' in it
 o  Do we -- or at least some of us -- want different preconfiguration
    for different user-/ "authority"-/ whatever-groups?
 o  Does that mean different templates? ...different template-dirs.?
 o  Do we need some kind of cascading/class system for this?

....And is "adduser.local" the right place (read: hook) at all?:
 o  How to make sure not only new-created users have all the necessary
    preconfiguration in their $HOMEs?
 o  Better use the regarding template(s) for all(?!) users when a
    program is installed?
 o  What about [often wanted] resetting user settings to some kind of
    system default settings when users have 'played' to much with their
    personal program-/desktop-configuration;
    preferably by only resetting the respective settings and not just
    wiping away $HOME and recreate it from scratch?
 o  What about spreading changes when the templates change?
     +  ...changes necessary for new versions of a program/package?
     +  ...changes made by our own? --> xxx.local systematics?
 o  Make up a system like the cron-driven maintenance of /etc-files by
    cfengine also for /skole/tjener/home0 or even all $HOMEs?

IMHO this is a 'big' issue, so i'm adressing it in the 'big' plenum. ;-)
I'm looking forward to get comments on these thoughts/questions.

Maybe someone knows about an already existing+working+suitable
infrastructure for these things that we can have a look at or even
integrate; maybe from a non-Debian or even a non-Linux system?

Best wishes,
  Patrick

--
Wherever I lay my .vimrc, there's my $HOME.



Reply to: