Enforcing some KDE configs
Hi all -- I have a situation where I want to set certain KDE desktop attributes for all users in KDE 4 on Debian "squeeze", and not allow users to change them. Specifically, I want to turn off nepomuk and nepomuk/strigi, because our systems have NFS-mounted user home directories, and "desktop search" plays havoc with the NFS server. I thought I could do this by putting the appropriate nepomukserverrc and nepomukstrigirc files in /etc/kde4/share/config, after copying these files out of an example home directory's $HOME/.kde/share/config directory, where they had been turned off. I also tried appending "[$i]" to all the group stanzas in the config files, I read somewhere that this was supposed to lock stuff down. However, this didn't work, or at least, when I restored the pre-shutoff files to the account and logged in again, nepomuk was running. I found some documentation about order-of-operations and search paths for KDE config files, but it seems to be for KDE3, and I haven't found any for KDE4 specifically, has the scheme changed? I am also confused about the order of precedence -- the docs seem to say that the KDEHOME files always have the highest precedence, but also have some discussion about the [$i] scheme to lock things down, which I suppose means that the [$i] scheme overrides the precedence scheme, but I have not yet run across a clear statement to that effect in the docs, and I can't seem to make it work. By way of explanation/apology, as a sysadmin I am generally strongly in favor of maximal user control, and I'm not really fond of the idea of locking down settings, but the sad fact in this case is that the defaults are killing the server, and as the "squeeze" roll-out picks up, it's only going to get worse. Thanks in advance for extra clues... -- A. -- Andrew Reid / rei...@bellatlantic.net -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201110171946.50403.rei...@bellatlantic.net
Re: Enforcing some KDE configs
On Tuesday 18 October 2011 01:46:50 Andrew Reid wrote: > I thought I could do this by putting the appropriate nepomukserverrc > and nepomukstrigirc files in /etc/kde4/share/config How about /etc/skel/ ? That's the place to configure defaults for new users, so I'm not sure if that's sth you can use. Diederik -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201110180159.02045.didi.deb...@cknow.org
Re: Enforcing some KDE configs
On 18/10/11 10:46, Andrew Reid wrote: > > Hi all -- > > I have a situation where I want to set certain KDE desktop attributes > for all users in KDE 4 on Debian "squeeze", and not allow users to change > them. Specifically, I want to turn off nepomuk and nepomuk/strigi, because > our systems have NFS-mounted user home directories, and "desktop search" > plays havoc with the NFS server. > > I thought I could do this by putting the appropriate nepomukserverrc > and nepomukstrigirc files in /etc/kde4/share/config, after copying these > files out of an example home directory's $HOME/.kde/share/config directory, > where they had been turned off. > > I also tried appending "[$i]" to all the group stanzas in the config > files, I read somewhere that this was supposed to lock stuff down. > > However, this didn't work, or at least, when I restored the pre-shutoff > files to the account and logged in again, nepomuk was running. I found > some documentation about order-of-operations and search paths for KDE > config files, but it seems to be for KDE3, and I haven't found any for > KDE4 specifically, has the scheme changed? > > I am also confused about the order of precedence -- the docs seem > to say that the KDEHOME files always have the highest precedence, but > also have some discussion about the [$i] scheme to lock things down, > which I suppose means that the [$i] scheme overrides the precedence > scheme, but I have not yet run across a clear statement to that effect > in the docs, and I can't seem to make it work. > > By way of explanation/apology, as a sysadmin I am generally strongly > in favor of maximal user control, and I'm not really fond of the idea > of locking down settings, but the sad fact in this case is that the > defaults are killing the server, and as the "squeeze" roll-out picks > up, it's only going to get worse. > > Thanks in advance for extra clues... > > -- A. > -- > Andrew Reid / rei...@bellatlantic.net > > As suggested by Diederik, put your settings into /etc/skel eg.:- /etc/skel/.kde/share/config/nepomukserverrc /etc/skel/.kde/share/config/nepomukstrigirc (0644) New accounts will then automagically get those settings as:- ~/.kde/share/config/nepomukserverrc ~/.kde/share/config/nepomukstrigirc NOTES: you'll want:- ==~/.kde/share/config/nepomukserverrc= [Basic Settings] Start Nepomuk=false [Service-nepomukstrigiservice] autostart=false [main Settings] Maximum memory=0 == You probably *won't* need nepomukstrigirc as the nepomukserverrc I've suggested stop that strigi service from starting. Cheers -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e9ccb27.4020...@gmail.com
Re: Enforcing some KDE configs
> On Tuesday 18 October 2011 01:46:50 Andrew Reid wrote: > > I thought I could do this by putting the appropriate nepomukserverrc > > and nepomukstrigirc files in /etc/kde4/share/config > > How about /etc/skel/ ? > That's the place to configure defaults for new users, so I'm not sure if > that's sth you can use. Thanks, that's a good thought -- we have an account template for new users, and I had forgotten about it. But, I still need to sovle the problem for existing users migrating to KDE4 on their new "squeeze" workstations. Fortunately, by the Power of Posting, I have identified the dumb thing I was doing -- it turns out I had typo'd the "KDEDIRS" environment variable in /etc/profile, so the overrides I had put in /etc/kde4 weren't being used -- if you set the environment variable correctly, all of a sudden the documentation starts to make some sense. The docs are on techbase.kde.org, btw, and although some of the pages talk about kde3, they seem to apply to kde4 also. -- A. -- Andrew Reid / rei...@bellatlantic.net -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201110172024.18886.rei...@bellatlantic.net
Re: Enforcing some KDE configs
On Tuesday, 2011-10-18, Andrew Reid wrote: > > On Tuesday 18 October 2011 01:46:50 Andrew Reid wrote: > > > I thought I could do this by putting the appropriate nepomukserverrc > > > and nepomukstrigirc files in /etc/kde4/share/config > > > > How about /etc/skel/ ? > > That's the place to configure defaults for new users, so I'm not sure if > > that's sth you can use. > > Thanks, that's a good thought -- we have an account template > for new users, and I had forgotten about it. > > But, I still need to sovle the problem for existing users > migrating to KDE4 on their new "squeeze" workstations. > > Fortunately, by the Power of Posting, I have identified the dumb > thing I was doing -- it turns out I had typo'd the "KDEDIRS" > environment variable in /etc/profile, so the overrides I had > put in /etc/kde4 weren't being used -- if you set the environment > variable correctly, all of a sudden the documentation starts to > make some sense. kde4-config can help to determine lookup path lists, e.g. kde4-config --path config for a list of directories searched for config. List in order of lookup and precendence with the exception of immutable entries, sections or files, which are resolved the other way around. > The docs are on techbase.kde.org, btw, and although some of > the pages talk about kde3, they seem to apply to kde4 also. Config handling itself hasn't been changed, so most docs should apply without any change as well. Some key names might have been changed or replaced though. The mechanism for marking things as immutable or environment based is still in place. Cheers, Kevin signature.asc Description: This is a digitally signed message part.
