Hello,
this letter is meant as a technical follow-up to the recent community
letter. This is the first part of a mini-series of introducing the
community to our technical approaches, We will start with the current
situation
The openthinclient software suite consists of two somewhat independent
software blocks:
*
openthinclient Manager (OM)
*
openthinclient OS (TCOS)
The OM software suite consists of a Tomcat distributed Java Application
allowing graphical management of ThinClients and a daemon to provide
HTTP, NFS, DHCP/Proxy, TFTP network services. Thus it is possible to be
installed on whatever platform (Oracle) JVM exists for. It implements a
deb packagement within the Java environment.
The TCOS was until now mix-up of Ubuntu 6.06 and 9.04 userland, plus a
custom initrd and kernel in order to boot the client off the network nfs
shares:
*
base.sfs (basically a debootstrapped ubuntu) mounted to "/"
*
<application>.sfs (like Firefox) mounted to "/opt"
*
a python framework to interpret the OM settings
The latter is the most custom part of the TCOS, as it connects our own
management software with the configuration state of the ThinClient.
Technically we do use Apache DS / openLDAP (localboot) as directory
server and do support the import of Users/Groups of a secondary
ActiveDirectory.
Thus the python functions (tcos.py) are mainly built around the ldap
module, to read the key-value pairs and transform them to config files
(e.g. .desktop files).This leads to the second main part of the python
framework. We use them for our build environment to simplify the task of
building new application packages. Why do we need this to package
software, you might ask?
*
The software is mounted to /opt, thus everything including config
must be there
*
Think of TCOS as a read-only system, needing the directory to have a
persistant place to save configurations
*
To meet the different challenges of software, autostart of software,
services, post-login-start, registy-like configurations (e.g. gconf)
The typical workflow for a package development goes like:
*
tcos_genpackage <name> (frontend to dh_make)
*
take binaries out of a deb or compile your software manually
*
adapt the <name>/<name>-version/tcos/launcher (python script)
*
adapt the xml scheme for the configuration interface (wtihin the OM)
*
tcos_buildpackage (-b) (frontend to dpkg-buildpackage)
*
upload the package and install it from the manager.
A basic laucher script:
#!/usr/bin/env python
# Standard modules
import os
import sys
import subprocess
# TCOS modules
import tcos
l = tcos.Launcher()
u = tcos.Util()
This tcos module is the boilerplate code to give you access to the OM
configuration.
Here I will show you the relation of a launcher script and the xml scheme.
excerpt of launcher.py:
## Get-Credentials
user = os.getenv('USER') # get systems username
domain0 = l.ENTRY.get('Domains.domain0', '')
excerpt of the according application.xml
<group name="Domains">
<label value="Domaene" lang="de"/>
<label value="Domain" lang="en"/>
<entry value="" name="domain0"/>
</group>
We have the instance "l" of the tcos.launcher() class method and use the
python dict.get method to fetch the value of the domain0 value in the
Domain group. Now we can provide the launcher script with whatever
domain the Administrator provides in the Manager.
The building process tcos_buildpackage works through the debian/rules
Makefiles , compresses the package specific files and tcos launcher
scripts under .../debian/<name>/opt/<name> and copies the schema files
to .../debian/<name>/schema>. Finally it willbe put in a deb package.
example run of tcos_buildpackage
# Add here commands to install the package into debian/bsc-smbmounter.
# /usr/bin/make install
DESTDIR=/develop/bsc-smbmounter/bsc-smbmounter-1.0.0/debian/bsc-smbmounter
cp -al bsc-smbmounter debian/bsc-smbmounter/opt/
cp -al tcos debian/bsc-smbmounter/opt/bsc-smbmounter/
cp -al schema debian/bsc-smbmounter/
mkdir -p debian/bsc-smbmounter/sfs/package
mksquashfs debian/bsc-smbmounter/opt/bsc-smbmounter/
debian/bsc-smbmounter/sfs/package/bsc-smbmounter.sfs -noappend
-always-use-fragments
So that's it for this time. In the next -devel letter I will go into
details about how we plan to build our new system, which tools and so on.
--
Mit freundlichen Grüßen
Steffen Hönig
--
Development & Support
openthinclient gmbh, Büro Dresden
Frühlingstr. 11, 01099 Dresden, Deutschland
Telefon: +49 35141886215-1
Mobil: +49 176 99635238
mailto: [email protected]
openthinclient gmbh
Heilbronner Str. 150, 70191 Stuttgart, Deutschland
Telefon: +49 711 1378636-0
Telefax: +49 711 1378636-9
Amtsgericht Stuttgart: HRB 245 177; USt-ID: DE216017092
Geschäftsführer: Alexander Stecher
http://openthinclient.com
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
The Open Source Thin Client Solution http://openthinclient.org
[email protected]
https://lists.sourceforge.net/lists/listinfo/openthinclient-developer
