We're now in the final stages of preparation for our rollout of 123 ltsp clients. The machines are using kde 3 configured to look and feel as close to windows as we can get it in order to minimise any potential hostility to the migration. What I'd like to do to ensure that users get a uniform and 'non-broken' desktop environment when they log in is to copy enough stuff into their home directory at login to ensure their desktop, menus, panel etc are what we would like them to be. Sadly, this seems to be a little more complicated than just copying in a set of files from a 'golden' user's home directory as many of the config files (e.g. konquerors file management profile) have hard wired paths to the 'golden' user's home directory. Another problem we have is that even if we copy across the OpenOffice directory from a user who has already run through the open office network workstation installation, the first time the new user runs an open office component, they have to go through the setup process. I suspect that someone on the list must have been here before and got it sorted. Advice please :) Cheers -- Phil Driscoll
Hi, [BTW you might be better of asking such questions on the kde-kiosk@kde.org mailng list -- it's a list for people administrating KDE in network environments] On Friday 03 May 2002 9:55 am, Phil Driscoll wrote:
What I'd like to do to ensure that users get a uniform and 'non-broken' desktop environment when they log in is to copy enough stuff into their home directory at login to ensure their desktop, menus, panel etc are what we would like them to be. Sadly, this seems to be a little more complicated than just copying in a set of files from a 'golden' user's home directory as many of the config files (e.g. konquerors file management profile) have hard wired paths to the 'golden' user's home directory. Another problem we
What exactly do you mean by this? Surely doing something like: cp /samples/konq-file-manage-profile $KDEHOME/share/config should work, and not have any hard wired paths? Ah, actually I think I might understand what you mean. Unfortunately it's not in KDE 3.0 (will definitely be in 3.1 in about 5/6 months), but maybe the following is help: http://lists.kde.org/?l=kde-core-devel&m=101996857631011&w=2 It should be pretty easy to path KDE 3.0 to do this though, just needing to recompile a tiny bit of it. There's also a document detailing all of these things: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/kdecore/README.kiosk?rev=1.10&content-type=text/vnd.viewcvs-markup I was working on setting up sysadmins.kde.org but sadly the guy who was going to do the writing no longer has time to do so :(
have is that even if we copy across the OpenOffice directory from a user who has already run through the open office network workstation installation, the first time the new user runs an open office component, they have to go through the setup process.
I think that as well as the OpenOffice directory, you need to copy a file or two to ~/. I think this is the .user60.rdb file. -- Cheers, Chris Howells -- chris@chrishowells.co.uk, howells@kde.org Web: http://chrishowells.co.uk, PGP key: http://chrishowells.co.uk/pgp.txt KDE: http://www.koffice.org, http://edu.kde.org, http://usability.kde.org
What I'd like to do to ensure that users get a uniform and 'non-broken' desktop environment when they log in is to copy enough stuff into their home directory at login to ensure their desktop, menus, panel etc are what we would like them to be. Sadly, this seems to be a little more complicated than just copying in a set of files from a 'golden' user's home directory as many of the config files (e.g. konquerors file management profile) have hard wired paths to the 'golden' user's home directory. Another problem we have is that
You could try setting up a template user with "~" subsituted for the user. This will work some of the time. Alternativily you can generate the files fron a shell script using environment variables such as $USER, which works well with the preferences.js file in the older versions of Netscape. (Which needs variations on the username and home directory in multiple places.) The newer versions of Netscape appear to use ~/.mozilla/$USER/$OUTPUT_OF_SOME_HASH_FUNCTION to store their config data (Galeon manages with ~/.galeon/mozilla/galeon
even if we copy across the OpenOffice directory from a user who has already run through the open office network workstation installation, the first time the new user runs an open office component, they have to go through the setup process.
Star/Open office is a big pain. Even with ~/<version>/user/sofficerc set up to contain the correct user details things you still get this. I think Michael Brown may know a solution. -- Mark Evans St. Peter's CofE High School Phone: +44 1392 204764 X109 Fax: +44 1392 204763
What I'd like to do to ensure that users get a uniform and 'non-broken' desktop environment when they log in is to copy enough stuff into their home directory at login to ensure their desktop, menus, panel etc are what we would like them to be. Sadly, this seems to be a little more complicated than just copying in a set of files from a 'golden' user's home directory as many of the config files (e.g. konquerors file management profile) have hard wired paths to the 'golden' user's home directory. Another problem we have is that You could try setting up a template user with "~" subsituted for the user. This will work some of the time. Alternativily you can generate the files fron a shell script using environment variables such as $USER, which works well with the preferences.js file in the older versions of Netscape. (Which needs variations on the username and home directory in multiple places.) The newer versions of Netscape appear to use ~/.mozilla/$USER/$OUTPUT_OF_SOME_HASH_FUNCTION to store their config data (Galeon manages with ~/.galeon/mozilla/galeon even if we copy across the OpenOffice directory from a user who has already run through the open office network workstation installation, the first time the new user runs an open office component, they have to go through the setup process. Star/Open office is a big pain. Even with ~/<version>/user/sofficerc set up to contain the correct user details things you still get this. I think Michael Brown may know a solution.
You're right : we have had to solve this problem already. We have a (rpm) package available for StarOffice 5.2 that wraps StarOffice in order to create a default user working environment the first time a user tries to run StarOffice. The user will see the message "Initialising the StarOffice components for the first time after installation" but will not see any setup screens. This package also creates K menu entries for StarWriter, StarCalc etc. so that you can open up blank documents without going via the StarOffice desktop. It sets up MIME types so that StarOffice docs can be easily opened via Konqueror. It also hacks the StarOffice printing system so that you don't ever need to run spadmin. Probably the easiest way for me to distribute this is to publish the .nosrc.rpm that is used to generate the staroffice rpm. This is now available from http://osie.sourceforge.net/staroffice-5.2-6fs.nosrc.rpm. You will need to obtain the StarOffice installer binary (so-5_2-ga-bin-linux-en.bin) separately and place it in the SOURCES directory within your RPM build tree. If you don't know what this means, visit www.rpm.org and learn how to build RPMs from source. Running "rpm --rebuild staroffice-5.2-6fs.nosrc.rpm" should start the build process. It will run through the StarOffice graphical installer. Accept the path selected (/home/.../usr/share/staroffice). Once the process is complete, you will have a staroffice-5.2-6fs.i586.rpm file that you can install just as you would any other RPM. So far, there has been no need to do this for OpenOffice; the Mandrake package for OpenOffice installs an office suite that is already usable out-of-the-box, without requiring any setup process. (There is one minor irritation; it will ask where to find the user's address book, but I expect this to be a minor workaround). As far as the template KDE config files goes, try this: #!/bin/sh # Exit if user's .kde directory already exists [ -d ~/.kde ] && exit # Sample user to use as a template # Ensure that ~$SAMPLE_USER is world-readable SAMPLE_USER=sample_user # Calculate SAMPLE_USER's home directory SAMPLE_HOME=`eval echo ~$SAMPLE_USER` # Copy .kde from SAMPLE_HOME to ~ cp -dR $SAMPLE_HOME/.kde ~/.kde # Search and replace instances of home directory for file in `find .kde`; do perl -pi -e "s{$SAMPLE_HOME}{$HOME}g" $file done Untested, use at your own risk etc. etc. This may not work if your distribution already does some hacking around with your .kde folder at KDE startup. I'm fairly sure it would fail under Mandrake, for example. As far as a proper, elegant solution goes: I don't yet know of one although I'm working on it. Michael
Thanks to all for their advice on this. For those using KDE in schools in a standalone or LTSP environment who want a 'get on with some work, don't twiddle with the desktop' type environment, I stongly suggest you follow Chris Howells' link to http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/kdecore/README.kiosk?rev=1.10&content-type=text/vnd.viewcvs-markup and read up on the [$i] 'immutable' setting which can be applied to prevent global kde configuration settings being overridden by local ones. We generated the desktop and kicker config files we wanted just using the gui tools, then copied them from the home directory of the user we were logged in as into the global kde area, after doing a bit of tweaking in a text editor and adding a [$i] at the top of the file. It worked a treat - now all users get the same desktop and kicker and they can't fiddle around with them! Cheers -- Phil Driscoll
I've been crying out for something easy along these
lines. I let you know if it's truely easy enough for
me ;)
--
Matt Johnson
--- Phil Driscoll
For those using KDE in schools in a standalone or LTSP environment who want a 'get on with some work, don't twiddle with the desktop' type environment, I stongly suggest you follow Chris Howells' link to
and read up on the [$i] 'immutable' setting which can be applied to prevent global kde configuration settings being overridden by local ones.
We generated the desktop and kicker config files we wanted just using the gui tools, then copied them from the home directory of the user we were logged in as into the global kde area, after doing a bit of tweaking in a text editor and adding a [$i] at the top of the file. It worked a treat - now all users get the same desktop and kicker and they can't fiddle around with them!
Cheers -- Phil Driscoll
-- To unsubscribe, e-mail: suse-linux-uk-schools-unsubscribe@suse.com For additional commands, e-mail: suse-linux-uk-schools-help@suse.com
__________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 07 May 2002 6:08 pm, Matt Johnson wrote:
I've been crying out for something easy along these lines. I let you know if it's truely easy enough for me ;)
Well what I want to do is to write a simple program to make doing this kind of thing easier by handling all this stuff behing a GUI. I've just about finished all my A-Level coursework now (hooray!) but my first A-Level exam is in 8 days so I don't think it's going to happen too soon ;) - -- Cheers, Chris Howells -- chris@chrishowells.co.uk, howells@kde.org Web: http://chrishowells.co.uk, PGP key: http://chrishowells.co.uk/pgp.txt KDE: http://www.koffice.org, http://edu.kde.org, http://usability.kde.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE82EFMF8Iu1zN5WiwRAopbAKCoBSf/Emlh7lu6oI1Y7xfYeNO6MgCgliFZ MbcW+U0HDBtYcwbmiPYJpSA= =kl3n -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 07 May 2002 5:14 pm, Phil Driscoll wrote:
text editor and adding a [$i] at the top of the file. It worked a treat - now all users get the same desktop and kicker and they can't fiddle around with them!
Great, I'm glad it worked ;) One thing that I don't think was mentioned is that if kickerrc is read only, then the "Preferences" menu option won't (shouldn't) be shown. - -- Cheers, Chris Howells -- chris@chrishowells.co.uk, howells@kde.org Web: http://chrishowells.co.uk, PGP key: http://chrishowells.co.uk/pgp.txt KDE: http://www.koffice.org, http://edu.kde.org, http://usability.kde.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE82EIjF8Iu1zN5WiwRAmpaAJ0dtWlJ6DIUk3gXeSyYZ33XLC0KiACgmvzH wgBVX8Nl2xuZmKpmGDrYdP8= =vYF+ -----END PGP SIGNATURE-----
On Tuesday 07 May 2002 9:07 pm, Chris Howells wrote:
Great, I'm glad it worked ;)
Slightly less good news this morning. We tried the same trick with the kioslaverc file but the immutable setting seems to be completely ignored. Have I misunderstood something here, or do not all kde components honour the [$i] setting? Cheers -- Phil Driscoll
On Wednesday 08 May 2002 10:35 am, Phil Driscoll wrote:
On Tuesday 07 May 2002 9:07 pm, Chris Howells wrote:
Great, I'm glad it worked ;)
Slightly less good news this morning. We tried the same trick with the kioslaverc file but the immutable setting seems to be completely ignored. Have I misunderstood something here, or do not all kde components honour the [$i] setting?
Well all the programs use the same KConfig backend to read and write configuration files. So in theory it should work fine. Waldo, any ideas? (please see http://lists.suse.com/archive/suse-linux-uk-schools/2002-May/0015.html and http://lists.suse.com/archive/suse-linux-uk-schools/2002-May/0003.html for the full thread if requried) -- Cheers, Chris Howells -- chris@chrishowells.co.uk, howells@kde.org Web: http://chrishowells.co.uk, PGP key: http://chrishowells.co.uk/pgp.txt KDE: http://www.koffice.org, http://edu.kde.org, http://usability.kde.org
On Wednesday 08 May 2002 12:50 pm, Chris Howells wrote:
On Wednesday 08 May 2002 10:35 am, Phil Driscoll wrote:
On Tuesday 07 May 2002 9:07 pm, Chris Howells wrote:
Great, I'm glad it worked ;)
Slightly less good news this morning. We tried the same trick with the kioslaverc file but the immutable setting seems to be completely ignored. Have I misunderstood something here, or do not all kde components honour the [$i] setting?
Well all the programs use the same KConfig backend to read and write configuration files. So in theory it should work fine.
Waldo, any ideas? (please see http://lists.suse.com/archive/suse-linux-uk-schools/2002-May/0015.html and http://lists.suse.com/archive/suse-linux-uk-schools/2002-May/0003.html for the full thread if requried)
I've just done the experiment on a SuSE 8.0 box at home and [$i] does seem to work here in kioslaverc - it prevents any changes I make to the proxy settings from being acted upon. Maybe I messed something up at school - sorry! Cheers -- Phil Driscoll
I've just done the experiment on a SuSE 8.0 box at home and [$i] does seem to work here in kioslaverc - it prevents any changes I make to the proxy settings from being acted upon. Maybe I messed something up at school - sorry!
Just to confirm - I checked at school this morning and I'd messed up file permissions on the immutable kioslaverc file - it was only readable by root, so it's no wonder it did not affect other users. Sorry! Cheers -- Phil Driscoll
participants (5)
-
Chris Howells -
Mark Evans -
Matt Johnson -
Michael Brown -
Phil Driscoll