[sabayon] Removed a bunch of very technical things which shouldn't be in a user manual. Moved to the wiki
- From: Scott Balneaves <sbalneav src gnome org>
- To: svn-commits-list gnome org
- Cc:
- Subject: [sabayon] Removed a bunch of very technical things which shouldn't be in a user manual. Moved to the wiki
- Date: Mon, 28 Dec 2009 19:24:28 +0000 (UTC)
commit 09cec81361d47fd04cba8d5da45b7bcf380802bd
Author: Scott Balneaves <sbalneav ltsp org>
Date: Mon Dec 28 13:24:30 2009 -0600
Removed a bunch of very technical things which shouldn't be in a user manual. Moved to the wiki
help/C/sabayon.xml | 652 ++--------------------------------------------------
1 files changed, 14 insertions(+), 638 deletions(-)
---
diff --git a/help/C/sabayon.xml b/help/C/sabayon.xml
index e20775b..ef9ace0 100644
--- a/help/C/sabayon.xml
+++ b/help/C/sabayon.xml
@@ -336,19 +336,21 @@ gksu sabayon
<para>
If you want &appname; to ignore a setting that's been
made, check the "Ignore" checkbox for that item.
- </para>
+ </para>
</listitem>
<listitem>
<para>
To have a gconf key set as a "default" setting,
- click the small shield in front of it once, so that
+ simply leave it as is on the
+ <emphasis>wooden</emphasis> shield.
it's silver.
- </para>
+ </para>
</listitem>
<listitem>
<para>
To have a gconf key set as a "manditory" setting,
- simply leave it as a gold shield.
+ click on it once to turn it into a
+ <emphasis>iron</emphasis> shield.
</para>
</listitem>
</orderedlist>
@@ -361,12 +363,13 @@ gksu sabayon
<sect2>
<title>Lockdown Editor</title>
<para>
- GNOME also has lockdown features, which allow you to do things
+ GNOME also includes the lockdown features of
+ <filename>Pessulus</filename>, which allow you to do things
like prevent users from modifying their panels, opening a
"Run Application" dialogue, etc.
</para>
<para>
- You can use &appname;'s lockdown editor by selecting Edit ->
+ You can use the lockdown editor by selecting Edit ->
Lockdown on the Desktop editor window.
</para>
<figure>
@@ -393,35 +396,13 @@ gksu sabayon
<sect2>
<title>Applying a profile</title>
<para>
- Important : I advise you creating a new user to test the profile.
- Add the following lines in /etc/gconf/2/path (add them at the beginning of the file) :
+ Important: it is advisable to create a new user to test the profile.
</para>
- <screen>
-xml:readonly:$(HOME)/.gconf.xml.mandatory
-xml:readwrite:$(HOME)/.gconf
-xml:readonly:$(HOME)/.gconf.xml.defaults
- </screen>
- </sect2>
- <sect2>
- <title>Applying profiles by user</title>
<para>
- Create and edit /etc/X11/Xsesssion.d/60sabayon_apply.
- </para>
- <screen>
-#
-# Apply the Sabayon profile for the current user (if any)
-#
-if [ "x$DISABLE_SABAYON_XINITRC" = "x" ] ; then
- if [ -x /usr/sbin/sabayon-apply ] ; then
- /usr/sbin/sabayon-apply
- fi
-fi
- </screen>
- <para>
- Select the profile that you want to apply and click on Users :
- Then, select the users that you want to apply the profile.
- In this example Eleve1 and Eleve 2 will have the profile
- my_profile.
+ Select the profile that you want to apply and click on Users :
+ Then, select the users that you want to apply the profile.
+ In this example Eleve1 and Eleve 2 will have the profile
+ my_profile.
</para>
<figure>
<title>Apply profile by user</title>
@@ -449,93 +430,6 @@ fi
alternatively, by a manual script.
</para>
<sect3>
- <title>Manually with a script</title>
- <para>
- The following is a script to apply a profile to a group of users :
- </para>
- <screen>
-#!/bin/bash
-#
-#Script : apply a profile to a group of users
-#Argument 1 : name of the profile
-#Argument 2 : name of the group
-#
-chemin_profil="/etc/sabayon/profiles/$1".zip
-if [ $# -eq 2 ]
-then
- if [ -a $chemin_profil ]
- then
- getent group | cut -d ":" -f 1 | grep $2 > /dev/null
- result=$?
- if [ $result -eq 0 ]
- then
- if [ -x /usr/sbin/sabayon-apply ]
- then
- groupe=`getent group | cut -d ":" -f 1,3 | grep $2 | cut -d ":" -f 2`
- getent passwd | while read ligne
- do
- gid=$(echo $ligne | cut -d ":" -f 4)
- name=$(echo $ligne | cut -d ":" -f 1)
- if [ $gid -eq $groupe ]
- then
- home=$(getent passwd | cut -d ":" -f 1,6 | grep $name | cut -d ":" -f 2)
- touch $home/.gconf.path
- touch $home/.gconf.path.defaults
- touch $home/.gconf.path.mandatory
- echo "include $home/.gconf.path.defaults" > $home/.gconf.path
- echo "include $home/.gconf.path.mandatory" >> $home/.gconf.path
- echo xml:readonly:$home/.gconf.xml.defaults > $home/.gconf.path.defaults
- echo xml:readonly:$home/.gconf.xml.mandatory > $home/.gconf.path.mandatory
- if [ -a $home/.gconf.xml.defaults ]
- then
- rm -r $home/.gconf.xml.defaults
- fi
- if [ -a $home/.gconf.xml.mandatory ]
- then
- rm -r $home/.gconf.xml.mandatory
- fi
- su $name -c "/usr/sbin/sabayon-apply $chemin_profil"
- chown -R root $home/.gconf.path
- chgrp -R root $home/.gconf.path
- chmod 755 $home/.gconf.path
- chown -R root $home/.gconf.path.defaults
- chgrp -R root $home/.gconf.path.defaults
- chmod 755 $home/.gconf.path.defaults
- chown -R root $home/.gconf.path.mandatory
- chgrp -R root $home/.gconf.path.mandatory
- chmod 755 $home/.gconf.path.mandatory
- chown -R root $home/.gconf.xml.defaults
- chgrp -R root $home/.gconf.xml.defaults
- chmod 755 $home/.gconf.xml.defaults
- chown -R root $home/.gconf.xml.mandatory
- chgrp -R root $home/.gconf.xml.mandatory
- chmod 755 $home/.gconf.xml.mandatory
- echo "The profile $1 has been applied to $name."
- fi
- done
- echo "The profile $1 has been applied to the group $2."
- fi
- else
- echo "The group does not exist."
- fi
- else
- echo "The profile does not exist."
- fi
-else
- echo ""
- echo "Usage: $0 [name of the profile] [name of the group]"
- echo ""
-fi
-
-
-Usage :
-# sudo ./sabayon.sh my_profil eleves
- - The name of the script is sabayon.sh.
- - 1st argument : my_profil which is the name of the profile.
- - 2nd argument : eleves which is the name of the group.
- </screen>
- </sect3>
- <sect3>
<title>Via the gui</title>
<para>
Simply use the simply sabayon-apply script above, but
@@ -563,522 +457,4 @@ Usage :
</sect3>
</sect2>
</sect1>
- <sect1 id='technical'>
- <title>&appname; Internals</title>
- <para>
- This section outlines some information about &appname; that
- Administrators, or potential &appname; developers may find useful.
- </para>
- <sect2 id='user-database'>
- <title>User database</title>
- <para>
- This page details the format of the user configuration file,
- where to store and access them.
- </para>
- <para>
- This file is located under
- <filename>/etc/sabayon/users.xml</filename>
- (see PROFILESDIR in the config.py file to change the
- prefix), as the name makes clear it is an XML file and
- usually look like:
- </para>
- <screen>
-<profiles>
- <user name="titeuf" profile="developer"/>
- <user name="fab" profile="developer"/>
- <user name="bianca" profile="secretary"/>
- ...
- <default profile="default"/>
-</profiles>
- </screen>
- <para>
- It contains a list of named users, and their associated profile.
- The profile in that case are aliases, for example
- <emphasis>developer</emphasis>
- is a shortcut for <filename>developer.zip</filename> in the same directory.
- </para>
- <para>
- The default profile will be applied for any login not listed
- explicitely in the set of users.
- </para>
- </sect2>
- <sect2 id='centralized-profiles'>
- <title>Centralized user databases and profiles</title>
- <para>
- For large and automated deployement, maintaining copies of the user
- database and profiles on all machines does not really make sense. To
- avoid the problem, the profile values can be an URI - preferably using
- HTTP - to reference a remote resource like:
- </para>
- <screen>
-...
-<user name="titeuf"
- profile="http://server.corp.com/prof/developers.zip"/>
-<user name="fab"
- profile="http://server.corp.com/prof/developers.zip"/>
-...
- </screen>
- <para>
- The profiles should then be maintained on a separate machine and
- copied over to the server when updated.
- </para>
- <para>
- The user database can also be centralized, using the
- <emphasis>XInclude</emphasis> mechanism for XML.
- For example the following assume there is a developer list maintained
- separately on the server, and defining the profiles for
- them:
- </para>
- <screen>
-<profiles>
- <xi:include xmlns:xi="http://www.w3.org/2001/XInclude";
- href="http://server.corp.com/user/devel.xml#xpointer(//user)"/>
- ...
- <default profile="default"/>
-</profiles>
- </screen>
- <para>
- This XInclude will just collect all user definitions in the developer
- list at <emphasis>http://server.corp.com/user/devel.xml</emphasis>
- and replace the include statement with that list, and process
- the XML as usual. The only difference is that the profile
- values are then assumed to be URI-References
- and for example if the <emphasis>devel.xml</emphasis> contains
- </para>
- <screen>
-...
- <user name="titeuf" profile="../prof/developers.zip"/>
-...
- </screen>
- <para>
- then &appname; will fetch the profile relative to the location of
- devel.xml, that is it will lookup the profiles relative to the base
- of where the fragment was defined and use
- <emphasis>http://server.corp.com/prof/developers.zip</emphasis>. Also note that
- shortcut are not allowed there, the trailing
- <emphasis>.zip</emphasis> is needed.
- </para>
- <para>
- The last point about the centralized support is that &appname; will
- use a cache located in the user home directory under
- <filename>.sabayon/profile_cache</filename>
- to keep a copy of the non-local files, this allows profile to function
- normally in disconnected operations or in case of server failures.
- </para>
- </sect2>
- <sect2 id='profile-format'>
- <title>Format of profile storage</title>
- <para>
- The following is a description of the requirement and the choices
- made when designing the user profile files. The existing format may
- change in the future but unless some of the requirement were missing
- it seems the existing choice is simple and flexible enough that no
- big change should be needed in the future.
- </para>
- <sect3 id='format-requirements'>
- <title>Format requiements</title>
- <itemizedlist>
- <listitem>
- <para>
- incremental update
- </para>
- </listitem>
- <listitem>
- <para>
- container for sets of settings of different apps
- </para>
- </listitem>
- <listitem>
- <para>
- associate apps with settings
- </para>
- </listitem>
- <listitem>
- <para>
- independent update of one set of settings
- </para>
- </listitem>
- <listitem>
- <para>
- ability to store full file
- </para>
- </listitem>
- <listitem>
- <para>
- ability to save path with the content
- </para>
- </listitem>
- <listitem>
- <para>
- provide metadata for the whole set and for each apps settings
- </para>
- </listitem>
- <listitem>
- <para>
- possibility to merge and detect potential clashes on merges
- </para>
- </listitem>
- <listitem>
- <para>
- possibility to extract or remove a simple set of data
- </para>
- </listitem>
- <listitem>
- <para>
- allow to process with as standard tools as possible
- </para>
- </listitem>
- </itemizedlist>
- </sect3>
- <sect3 id='design-choices'>
- <title>Design Choices</title>
- <para>
- Use ZIP for the container format:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- platform ubiquity Linux/Windows/Mac...
- </para>
- </listitem>
- <listitem>
- <para>
- free software tools and libraries
- </para>
- </listitem>
- <listitem>
- <para>
- compressed
- </para>
- </listitem>
- <listitem>
- <para>
- allows to access a single stream without exploding everything like a compressed tar or cpio requires
- </para>
- </listitem>
- <listitem>
- <para>
- allow to store name/paths
- </para>
- </listitem>
- </itemizedlist>
- </sect3>
- <sect3 id='metadata'>
- <title>XML Metadata description</title>
- <para>
- Add an XML metadata section as the first entry:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- classic design (jar)
- </para>
- </listitem>
- <listitem>
- <para>
- allow to store all metadata informations associated
- </para>
- </listitem>
- <listitem>
- <para>
- easy to extend in a backward and forward compatible way
- </para>
- </listitem>
- <listitem>
- <para>
- open source tools and local knowledge
- </para>
- </listitem>
- <listitem>
- <para>
- a lot of configuration data already require XML handling so this doesn't add an extra dependancy
- </para>
- </listitem>
- <listitem>
- <para>
- load/modify subpart/save operations are easy on an XML tree
- </para>
- </listitem>
- </itemizedlist>
- </sect3>
- <sect3 id='internal-structure'>
- <title>Internal structure</title>
- <para>
- The container is a Zip, its content can be viewed using the command
- </para>
- <screen>
-unzip -l /etc/sabayon/profiles/test.zip
- </screen>
- <para>
- The first entry is the metadata part, it is an XML file describing the
- content of the archive. It can be viewed using the command
- </para>
- <screen>
-unzip -p /etc/sabayon/profiles/test.zip metadata
- </screen>
- <para>
- Currently, the metadata contains
- </para>
- <itemizedlist>
- <listitem>
- <para>
- general description for the whole set of settings e.g. "Configuration for developers in project foo":
- </para>
- <itemizedlist>
- <listitem>
- <para>
- administrative informations
- </para>
- </listitem>
- <listitem>
- <para>
- last change timestamp
- </para>
- </listitem>
- <listitem>
- <para>
- contact
- </para>
- </listitem>
- <listitem>
- <para>
- changelog
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
- <listitem>
- <para>
- per stream description
- </para>
- <itemizedlist>
- <listitem>
- <para>
- name of the stream in the archive
- </para>
- </listitem>
- <listitem>
- <para>
- associated application
- </para>
- </listitem>
- <listitem>
- <para>
- description for settings e.g. "Mozilla starts full screen"
- </para>
- </listitem>
- <listitem>
- <para>
- administrative info
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
- </itemizedlist>
- <para>
- Then in the ZIP, each update has its own stream, the format is left to
- the corresponding user profile writer module. It can potentially be a
- full raw file, or a more synthetic description recognized by the specific
- profile module.
- </para>
- <para>
- Note that an application can have one
- stream per different configuration file for example
- .openoffice1.1/user/registry/data/org/openoffice/Inet.xcu and
- .openoffice1.1/user/registry/data/org/openoffice/Office/Common.xcu
- would be 2 different streams maintained by the OpenOffice reader
- writer module. An application may have both raw configuration files
- and digested name/values pairs, but in different files.
- </para>
- </sect3>
- </sect2>
- <sect2 id='ldap'>
- <title>LDAP profile storage</title>
- <para>
- Sabayon supports using LDAP to get profiles in a very flexible way.
- By defining server settings and queries in the
- <filename>/etc/sabayon/users.xml</filename> file it can do the mapping from user
- to profile file using LDAP queries. An example setup can look like:
- </para>
- <screen>
-<profiles>
- <ldap server="ldap.example.com">
- <profilemap search_base="ou=People,dc=example,dc=com"
- scope="one"
- query_filter="(uid=%u)"
- result_attribute="sabayonProfileURL"/>
- </ldap>
- <default profile="default"/>
-</profiles>
- </screen>
- <sect3 id='ldap-server-config'>
- <title>LDAP server configuration</title>
- <para>
- The toplevel ldap tag sets up the server connection. Availible
- attributes are:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- server (default: localhost): The address of the ldap server
- </para>
- </listitem>
- <listitem>
- <para>
- port (default: 389): The port of the ldap server
- </para>
- </listitem>
- <listitem>
- <para>
- version (default: 3): The ldap version to use
- </para>
- </listitem>
- <listitem>
- <para>
- timeout (default: 10): Timeout to use for ldap operations, 0 to disable
- </para>
- </listitem>
- <listitem>
- <para>
- bind_dn: dn to bind as, or leave out to run queries without binding
- </para>
- </listitem>
- <listitem>
- <para>
- bind_pw: password used when binding
- </para>
- </listitem>
- </itemizedlist>
- </sect3>
- <sect3 id='ldap-queries'>
- <title>LDAP queries</title>
- <para>
- Inside the ldap tag you can define the two queries used by
- &appname;. The
- first is the profilemap query, which maps from the username to the profile
- name to use for the user. The profile name is just a string, and it can be
- either an absolute URI, a URI relative to the config file, or just a name.
- If it is a name it will be looked up in the locationmap LDAP query (if specified)
- and if that didn't match, it will be converted to a
- filename in <filename>/etc/sabayon/profiles</filename> by appending ".zip".
- </para>
- <para>
- The locationmap query specifies the mapping from profile name to profile
- URI. This can optinally be used instead of storing the profile URI directly
- in the LDAP user object, to allow more flexibility in changing the URI.
- </para>
- <para>
- Both queries support these attributes:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- search_base: The search base of the query
- </para>
- </listitem>
- <listitem>
- <para>
- query_filter: the LDAP filter to use
- </para>
- </listitem>
- <listitem>
- <para>
- result_attribute: The name of the attribute to look at in the query result
- </para>
- </listitem>
- <listitem>
- <para>
- scope (default "sub"): The search scope. Can be sub, base or one.
- </para>
- </listitem>
- <listitem>
- <para>
- multiple_result (default "first"): How to handle multiple values in the
- resulting attribute. Can be "first", use the first attribute or "random", pick
- a random one (for e.g. load balancing).
- </para>
- </listitem>
- </itemizedlist>
- <para>
- Both search_base and query_filter are expanded. In profilemap %u expands to the username
- and in locationmap %p expands to the profile name. In both maps %h expands to the full
- hostname of the client, and %% expands to %.
- </para>
- </sect3>
- <sect3 id='ldap-examples'>
- <title>Examples</title>
- <para>
- There are many way to set up the &appname; LDAP integration. Here are some examples,
- all using the &appname; LDAP schema that comes in the
- &appname; package.
- </para>
- <sect4 id='store-by-user'>
- <title>Store profile URL in the user</title>
- <para>
- This is the simplest setup. Add a sabayonProfileURLObject to your user objects
- and set the sabayonProfileURL property for each user to a URI of the profile.
- </para>
- <screen>
- ...
- <ldap server="...">
- <profilemap search_base="ou=People,dc=example,dc=com"
- scope="one"
- query_filter="(uid=%u)"
- result_attribute="sabayonProfileURL"/>
- </ldap>
- ...
- </screen>
- </sect4>
- <sect4 id='store-by-entity'>
- <title>Store profile as a separate entity in ldap</title>
- <para>
- Store the name of the profile for each user (using a
- sabayonProfileNameObject object), and store the actual URI in
- a sabayonProfile object. This gives a lot of flexibility to change
- the URI of the profile, without having to update each user.
- </para>
- <screen>
- ...
- <ldap server="...">
- <profilemap search_base="ou=People,dc=example,dc=com"
- scope="one"
- query_filter="(uid=%u)"
- result_attribute="sabayonProfileName"/>
- <locationmap search_base="ou=Profiles,dc=example,dc=com"
- scope="one"
- query_filter="(cn=%p)"
- result_attribute="sabayonProfileURL"/>
- </ldap>
- ...
- </screen>
- </sect4>
- <sect4 id='pick-by-group'>
- <title>Pick profile based on group membership</title>
- <para>
- This lets you pick a profile based on what group the user
- is part of by adding the sabayonProfileURL attribute to the
- group object.
- </para>
- <screen>
- ...
- <ldap server="...">
- <profilemap search_base="ou=Group,dc=example,dc=com"
- scope="one"
- query_filter="(memberUid=%u)"
- result_attribute="sabayonProfileURL"/>
- </ldap>
- ...
- </screen>
- </sect4>
- <sect4 id='ldap-others'>
- <title>Others</title>
- <para>
- There are countless other ways, for example you could combine the
- group example and the separate profile object example. If you come up
- with an interesting way, please tell us on the mailing list.
- </para>
- </sect4>
- </sect3>
- </sect2>
- </sect1>
</article>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
