KDE is an extensively configurable desktop environment. In addition to being configurable for the individual user, administrators have the possibility to create global configurations. This allows system administrators to provide custom default settings for their environments. Settings can differ between groups and individual users. It is also possible to restrict which settings users can change. Additionally, access to parts of KDE or functions in KDE can be restricted for users and groups.
These global configurations allow administrators to, for example, set up a network-wide desktop the user is not allowed to change. It is also feasible to assign task-specific profiles with access to only a limited set of applications to different groups within the network.
KDE reads and stores all configuration files in fixed directory trees called profiles. A profile is a collection of default settings and restrictions that can be applied to individual users or groups of users. These profiles are handled by the KIOSK framework. Use the graphical KIOSK Admin Tool to generate and manage profiles or manually edit and create files and structures in a profile.
To set up a global KDE desktop configuration for clients within your network, you need:
root
access to a server and to the clients in the network
the KIOSK tool (pakage kiosk
) installed on your
workstation
KDE 3.x - the procedure described here will most likely not work with older or future KDE versions
The Kiosk Admin Tool allows you to define profiles with desktop policies, environment restrictions, and menu definitions. It allows you to modify existing profiles and lets you assign them to groups and users. Kiosk also lets you automatically deploy profiles to a remote host.
Start the Kiosk Admin Tool from the KDE main menu or with -F2 and the command kiosktool.
To create a new profile, click the section called “Deploying Profiles to the Local Machine” for more information about the profile directory.
. In the dialog that opens, enter a and a . You can also specify an owner to which the files of the profile should belong. The user specified here must have write access to the profile directory. You also need to know the password of the user specified here. SeeIt is possible to change the data entered here any time with
.By choosing an existing profile and clicking
, set up configurations for all KDE components, such as icons, menus, and file associations. After choosing a component, activate a restriction by checking the box of the respective entry. Choosing an entry with the mouse displays a help text explaining the effect the restriction has.
Entries either describe a specific feature that you can
disable
(such as ) or describe configuration options that you can
lock down
(such as ). By doing so, the feature or configuration option is
not available when the profile is used.
Apart from disabling features and locking down configuration options, you can also configure the look and feel of the desktop itself. When selecting the components
, , , , and , get two additional buttons— and . When clicking , the desktop settings of the currently selected profile are loaded and temporarily overwrite your own desktop settings. Now you can make changes just as you would when configuring your own desktop. When you confirm your changes by clicking , the changes made are permanently added to the profile and your own desktop settings are restored.When you create a profile, it is not “active” by default. First assign it to users or groups first. opens a dialog where you can assign all existing profiles to distinct users or groups. If you are applying more than one profile to a user or group, settings from all profiles are used. If a profile contains settings that conflict with settings in another profile, the settings in the earlier listed profile take precedence. The same rule applies if you apply a profile to a specific user and another profile to a group of which this user is a member.
![]() | Users and Groups on Remote Hosts |
---|---|
You can assign profiles to groups and users available on the local machine. If you are planning to deploy your profiles to a remote server, make sure that the needed users and groups from the remote host are also available on the local machine (for example, by using NIS). |
The KIOSK Admin Tool not only allows you to deploy profiles to the local machine, but also to a remote computer. In doing so, you can, for instance, deploy the profiles onto an NFS server from which they are exported to all clients on the network.
If you are deploying your profiles to the same machine as the KIOSK Admin
Tools is running on, no manual intervention is required—the tool
takes care that the profiles are “found” on start-up. By
default, all profiles are stored in
/var/lib/kde-profiles
to which only the user
root
is allowed to write. It is
recommended not to change this setting.
However, if you need to change the location to which the profiles are written, select
-> and change the .It is also possible, although not recommended, to distribute profiles to different locations. Uncheck
in the configuration dialog. Having done so, you must specify the when creating a profile.
The KIOSK Admin Tool configuration
(fish
protocol. The field
in the configuration dialog is initialized with
fish://root@host/
. Replace root
with
the user to which the files on the remote server should belong and
host
with the remote hostname. By default, the same
directory as on the local host is used. To change this, click
to specify a new directory on the
remote server. After entering the password for the remote user, you can
browse directories. By default, the directory on the local host is
appended to the specified. Use
to change this.
By default, KDE expects its profiles in
/var/lib/kde-profiles
. If you are deploying them to
this directory on a remote machine or to a directory on an NFS server that
will be mounted with this path by the clients, no further interaction is
required. Otherwise, adjust /etc/kde3rc
. See http://websvn.kde.org/trunk/KDE/kdelibs/kdecore/README.kiosk?view=markup
for details.
In the following example, a profile called myCompany is created and
assigned to the user tester
on the remote host
testserver
.
Start the Kiosk Admin Tool from the KDE main menu or with -F2 and the command kiosktool.
Open the configuration dialog with
/var/lib/kde-profiles
by default. Also
by default, users with a UID
lower than 500 are
not displayed.
The profile in this example should be deployed to a remote host named
testserver
in the default profile
location. Therefore, activate
and change the to fish://root@testserver/
.
Open the myCompany
.
Click root
password before the files can be saved.
Clicking
opens a dialog where you can configure the various aspects of KDE.If you choose, for example,
then , the configuration dialog for the themes opens. All changes you make here do not affect your current desktop, but are added to the profile you are working on after you confirm your changes with in the window.After finishing setting up the profile, return to the main menu by clicking
.Assign the profile to distinct users or groups by clicking
.Return to the main menu by clicking
.
Now the profile is available on the local machine. Before deploying it to
the remote host, you can test it. Start a new session by right-clicking
the desktop and choosing tester
.
Return to your own desktop by logging out as
tester
. If you need to make changes, start the setup
procedure again. Otherwise leave the KIOSK Admin Tool. On exit, it
deploys all profiles to testserver
. You must
enter the root
password on testserver
for this
operation. Because the profiles are deployed to the default KDE profile
location in this example, no further action is required. The next time
tester
logs in on testserver
, the
myCompany profile is used.
If you prefer manually editing configuration files over using a graphical tool, the KIOSK framework lets you do this, too. Every configuration file in a profile is a plain text file that can be edited with the editor of your choice. KIOSK's configuration and deployment options are described in detail in The KDE Source Repository at http://websvn.kde.org/trunk/KDE/kdelibs/kdecore/README.kiosk?view=markup. Refer to this resource for details. In the following, only the fundamentals needed to use the KIOSK framework are described.
KDE reads and stores files used by the KDE environment itself as well as
by the KDE applications in fixed directory trees, also referred to as
“profiles” in this context. By default, there are two such
directories: /opt/kde3
and
~/.kde
. The ~/.kde
directory
contains the user-specific settings. The /opt/kde3
directory contains data and configuration files that came with the
packages. It is not recommended to make any changes there, because they
get overwritten with the next update. Therefore, as a system administrator
you can create additional trees that are used by the KIOSK framework. The
default location for an additional fixed directory tree is
/var/lib/kde-profiles
. You can add custom locations
in /etc/kde3rc
. Refer to the KIOSK documentation for
details.
A fixed directory tree consists of the following directories (although not all directories need to be present):
bin
Executables
cgi-bin
Help center scripts
lib
Libraries
socket-<HOSTNAME>
Communication sockets
tmp-<HOSTNAME>
Temporary files
cache-<HOSTNAME>
Cached data
share
Application and configuration data
Among others, the share
directory contains the
following subdirectories:
share/applications
.desktop files for all applications appearing in the KDE menu
share/applnk
The KDE menu structure
share/config
Configuration files for applications and components as well as the
global configuration file kdeglobals
share/icons
Icons, categorized by theme, dimension, and usage category
share/mimelnk
.desktop files with mime types
share/wallpapers
Images that can be used as background pictures
KDE scans all directory trees known to the system. When a specific file is present in multiple directory trees, the order of precedence determines which file is used.
When configuration files are scanned, an additional rule applies. Generally, the contents of multiple configuration files with the same name are merged. However, if the same configuration key is defined more than once, the key from the file with the highest precedence determines which value is used.
The rule of precedence is:
User directory (~/.kde
)
Directories configured in /etc/kde3rc
Systemwide default directory (/opt/kde3
)
As a user, you can overwrite this order by setting the variable
$KDEDIRS
. Directories should be separated by a colon
(:
). The first directory has highest precedence and the
last one lowest precedence.
KDE configurations are stored in text files in UTF-8 format. Each configuration option consists of a key and value pair and is placed inside a group:
[Group 1] key=value key 2=value 2
White space at the beginning or end of keys and values are ignored. However, both may contain spaces as shown in the example above. If a value is supposed to start or end with space or should contain line breaks or special characters, use the following special codes:
\s
: space
\t
: tab
\r
: carriage return
\n
: new line
\\
: backslash
To use dynamically generated values, KDE allows you to use shell
expansions. If a key is followed by [$e]
,
shell expansions are activated. When using this construct, the value is
written to the file the first time it is read. Using
[$ie]
, lock down this behavior so the expansion is
evaluated every time the configuration file is read. Shell expansions
allow you to either use environment variables or the output of commands as
values.
[example group] UserName=$USER Group=$(id -g) HomeDirectory=$HOME
All configuration values can be localized with a language code added to the key entry:
[example group] Label=Language Label[de]=Sprache Label[ru]=Язык
All configuration entries can be protected from being overwritten. You can lock down entire configuration files, groups, or individual keys. Do this by adding [Si] on a separate line at the beginning of a file, placing it behind the group name, or adding it behind a key.
[example group][$i] Label=Language [example group 2] UserName[$i]=$USER
Profiles can be created anywhere in the file system. To make the KDE
environment read your profiles, you must make them known to the system in
/etc/kde3rc
. The default profile location
/var/lib/kde-profiles/
is already configured there.
By default, a custom profile is not associated to users or groups. You can
make this association in the user profile map file at
/etc/kde-user-profile
. The only exception from this
is the default profile. If you create a profile named
“default” under /var/lib/kde-profiles/
this is automatically associated to all users on this machine (such a
profile does not exist by default).
Find more detailed information about activating profiles and mapping them to users in the KIOSK framework documentation.