Manual

Documentations about SmartClient can be found at source:trunk/documentation.

The voluminous (around 100 pages), always outdated and still incomplete manual (in German !) can be found at here:

• LaTeX sources: source:trunk/documentation/betriebshandbuch/
• PDF: SmartClient-main.pdf​

Future documentation work should be done in this wiki.

Server

Client

SmartClient Components

• common/sc_base
• client/sc_hardware
• client/sc_mkwsconfig
• client/sc_install
• client/sc_desktop_permissions
• client/sc_kprofile
• client/sc_ldap2authorizedkeys
• client/sc_print
• client/sc_inventar2ldap
• client/sc_vmware
• client/sc_tools_client

Configuration

• client/init

KDE

KDE4

While the manual describes KDE3 configuration, our preliminary results for KDE4 are documented at ​http://techbase.kde.org/Projects/Plasma/Kiosk

adding appications

Example application: example

Where possible, we store our stuff in a separate subdirectory smartclient

/usr/share/applications/example.desktop	general application description, like Name, Exec(utable), Icon. SmartClient subdirectory /usr/share/applications/smartclient/ would by possible, but %suse_update_desktop_file does not support directories
/usr/share/pixmap/example.png	application icon (using /usr/share/icons/default.kde4/48x48/apps/example.png is also possible, but more complicated. Also problems occur, if the user changes the default icon them)

testing KDE4 icons

to test, if an icon is recognised by the system, act as follow:

# copy the icon example.png or example.svgz to /usr/share/pixmap/
# if available, choose the svgz image format, otherwise png. (xpm does also work)
cp -a example.svgz /usr/share/pixmap/

# create a directory for testing
mkdir /tmp/test

# copy some .desktop files to the testing directory. At least one should have the line "Icon=example"
cp -a example_working.desktop example_testing.desktop /tmp/test

# remove the users icon cache
rm -r ~/.kde4/cache-*/kpc/

# check if the icons gets displayed correctly
strace -e trace=access -o /tmp/test/konq_icon.strace  -f konqueror /tmp/test

# close konqueror

# in case of problems, analyse the strace log file
less /tmp/test/konq_icon.strace

disable application

sometimes, applications are installed on the system, but not all users should not be able to start it.

uninstalling not always possible, because some users may use it, or it is part of a larger RPM and the other applications from the RPM should stay on the system.

different approaches:

TryExec

check, if the user is allowed, to execute the application:

[Desktop Entry]
Comment=Ganttproject
Exec=/opt/ganttproject/ganttproject.sh
TryExec=/opt/ganttproject/ganttproject.sh

If the command that is specified by TryExec is not executable by the user, the Desktop-Entries is not displayed in the Start-Menu.

hide application by modifying the .desktop file

show only, if VMware image exists (and is readable):

vmware-winnt.desktop:

[Desktop Entry]
Comment=VMware mit Windows NT starten
Exec=/usr/bin/sudo /usr/bin/sc_vmware.sh /local/vmware/vermka/Windows_NT.vmx
Hidden[$e]=$(test -r /local/vmware/vermka/Windows_NT.vmx || echo "true")

permissions

Set application permissions to not executable by normal user and desktop files to be not readable. Define this in a permissions file under /etc/permissions.d/. Filename must match a installed RPM name.

Execute /sbin/conf.d/SuSEconfig.permissions

which sets permissions accordanly. After package installation by YaST, SuSEconfig is called and sets permissions. Therefore application is still unaccessable after a package update.

Example: /etc/permissions.d/k3b:

/usr/bin/k3b                                    root.media      750
/usr/share/applications/kde4/k3b.desktop        root.media      640