KDE Kiosk Mode
One of the more powerful aspects of the KDE desktop is the ability to customize the user experience completely. Most KDE programs use core features and plugins provided by the desktop system, creating a consistent user interface and easy-to-access configuration setup. One popular extension to this interface, known as KDE's Kiosk Mode, allows a system administrator to configure all aspects of the desktop for an end user and optionally prevent the end user from making modifications to the provided setup.
KDE applications utilize a configuration framework similar to Microsoft Windows INI files. One benefit of this file type is the ease of direct manual editing of the configuration file by an administrator or user. The INI file format is an ordinary text file that is divided into smaller named sections, each section having one or more key/value pairs. These values are used and stored directly by the applications:
... [GroupName] key=value key2=value2 ...
Configuration files are located in a number of places, largely based on which distribution is being used. When an application attempts to find its configuration, it scans according to a predefined search order. The list of directories that are searched for config files is seen by using the command kde-config --path config. The directories shown actually are searched in the reverse order in which they are listed. This search order is put together by the following set of rules:
/etc/kderc: a search path of directories can be specified within this file.
KDEDIRS: a standard environment variable that is set to point KDE applications to the installation directories of KDE libraries and applications. It most likely already is set at login time. The installation directory of KDE automatically is appended to this list if it is not already present.
KDEDIR: an older environment variable now considered deprecated in favor of KDEDIRS. If KDEDIRS is set, this variable is ignored for configuration.
The directory of the executable file being run.
KDEHOME or KDEROOTHOME: usually set to ~/.kde. The former is for all users, and the latter is for root.
Configuration files are stored in directory trees that end in /share/config, so an environment variable directory like KDEHOME has a /share/config appended to it to make the configuration file directory name.
When an application requests its configuration information, KDE searches all of the above directories for the files that go with the application and merges them together into one configuration object for the program. Information is combined on a key-by-key basis—any conflicts receive the value that was read latest in the chain. Because KDEHOME files always are read last, any local user changes made to the file always override values in other configuration files. This is the reason the output directories of the kde-config command are shown in reverse order—they are listed based on the precedence of the config files contained within.
Because the configuration file values cascade downstream, system administrators can preset certain configuration values in an upper-level directory to be used as the default for all users, or at least until those users make any changes. For example, if the system administrator wanted to set a default wallpaper for all users, until those users made custom changes, a simple edit of the kdesktoprc file in an upper-level configuration directory would provide this feature:
[Desktop0] ... Wallpaper=/usr/kde/3.3/share/wallpapers/custompaper.jpg ...
One of the features of KDE's Kiosk Mode is the ability to lock values read from configuration files earlier in the chain so that values read later cannot override them. This utility not only allows system administrators to preset certain configuration items, but it also lets the administrators lock those configuration items down so that end users cannot make custom changes. Locking configuration values in this fashion is easy.
Assume an administrator wants to lock the Konqueror configuration down so that the navigation toolbar always is presented in text form. A simple scan of the $KDEHOME/share/config/konquerorrc file shows the following information:
... [KonqMainWindow Toolbar mainToolBar] IconText=TextOnly ...
This configuration item specifies that Konqueror use Text instead of Icons in the Main Toolbar. Changing this value in Konqueror is easy—right-click on a Konqueror toolbar and select Text Position to change between settings. Figures 1 and 2 show the difference in toolbars with text and icons.

Figure 1. The Konqueror Main Toolbar with the TextOnly Setting

Figure 2. The Konqueror Main Toolbar with the IconOnly Setting
To lock this value for users, the administrator simply can create or edit konquerorrc in a higher-level configuration directory. To make this value unchangeable, simply edit the file as shown:
[KonqMainWindow Toolbar mainToolBar] IconText[$i]=TextOnly
The above [$i] specifies that this configuration value is immutable, meaning Konqueror should use this configuration value and not merge in any values in lower-level directories that normally would override this setting. Any configuration files farther down the configuration directory structure containing [KonqMainWindow Toolbar mainToolBar] group cannot override the IconText value.
Once this file is saved and Konqueror is restarted, any changes to the navigation toolbar's Text Position are not saved between Konqueror restarts. This is because the value was locked in an upper-level configuration directory, so it cannot be overwritten in a lower-level directory.
On a larger scale, whole groups of configurations can be specified as immutable. Setting the group as immutable makes all values in that group immutable as well. For example, in KCalc's configuration file, kcalcrc:
... [Precision][$i] fixed=true precision=12 ...
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Dart: a New Web Programming Experience
- A Topic for Discussion - Open Source Feature-Richness?
- The Secret Password Is...
- RSS Feeds
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




1 hour 41 min ago
3 hours 32 min ago
8 hours 46 min ago
11 hours 57 min ago
14 hours 13 min ago
14 hours 41 min ago
15 hours 39 min ago
17 hours 8 min ago
18 hours 17 min ago
19 hours 3 min ago