Sabayon is a system administration tool to manage GNOME desktop settings. Sabayon provides a sane way to edit GConf defaults and GConf mandatory keys: the same way you edit your desktop. Sabayon launches profiles in an Xephyr window. Any changes you make in the Xephyr window are saved back to the profile file, which can then be applied to user's accounts.
More screenshots and a step by step example are available from Seth Nickell blog about sabayon 0.12.
Currently Sabayon is limited to the creation and update of user preference profiles. It does not deal with the very large problem of actually populating target system with those preferences.
So far Sabayon supports complete files and the configuration format for:
We are looking into or planning on adding support for the following:
Contributed documentation is welcome:
Use this link for looking at open bugs with Sabayon. Please make sure the new and unconfirmed bugs conform the the bug reporting guidelines laid out in the testing section.
The GNOME Bugsquad has a good triage guide for people new to bugzilla and GNOME. Read up on that before doing any triage work with bugzilla and if you know that please also read our bug reporting guidelines in the testing section.
Distribution SupportSabayon needs as much testing and widespread distribution as possible in order to become the default preference management tool for sysadmins in GNOME, replacing the ad hoc solutions that people currently use.
Ask your favorite distribution to package Sabayon and use it.
To get the very latest copy of Sabayon you'll need to pull it from CVS. Here's how you'll do it.
export CVSROOT=':pserver:anonymous@anoncvs.gnome.org:/cvs/gnome'
cvs login
[press enter for blank password]
cvs -z3 co sabayon
cd sabayon
Download the latest source package from the Sabayon package directory: http://ftp.gnome.org/pub/GNOME/sources/sabayon/. Then untar the files like this:
tar -zxvf sabayon-0.1.0.tar.gz
cd sabayon-0.1.0
Assuming you've changed into the Sabayon source directory from either a package or CVS you now want to start the build.
./autogen.sh --prefix=/usr/local
make
make install (sudo make install may work for you)
Check the README file, to test sabayon you need a number of packages to be up to date. This is checked by the RPM upon installation. You also need a sabayon user defined like:
sabayon:x:50140:99:Sabayon user:/var/sabayon:/sbin/nologin
The RPM post install scripts uses the following command to create this specific user:
/usr/sbin/useradd -c "Sabayon user" -d /var/sabayon -g nobody -s /sbin/nologin sabayonYou may need to do this by hand or in you package to have a working installation of sabayon
Now that you have Sabayon installed try it by launching sabayon as root and create new profiles and edit them. Don't forget to save the session before quitting to have the profile updated. Check the step by step example available from Seth Nickell blog about sabayon 0.12.
When reporting bugs about Sabayon it is most helpful to explain the sequence of events you did to generate the bug. If we can reproduce the bug it is of course easier to fix.
Report bugs for sabayon to GNOME Bugzilla under the Sabayon product.
The GNOME web site has lots of materials for helping you build packages from source, see the developer site for more information about CVS and autogen and building. If you have any other questions feel free to direct them to IRC or the mailing list.
The AUTHORS file has the current people in charge of the Sabayon project maintenance and development.
If you'd like to start working on Sabayon see the Testing section for how to get the latest CVS sources of Sabayon.
Sabayon hackers use the mailing list and irc channel #sabayon on the server irc.gnome.org for keeping in touch and discussing issues regarding the project.
Sabayon has a TODO list that should be updated frequently describing the work that the developers would like to undertake and will gladly accept patches for.
This page details the format of the user configuration file, where to store and access them.
This file is located under /etc/desktop-profiles/users.xml (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:
<profiles>
<user name="titeuf" profile="developer"/>
<user name="fab" profile="developer"/>
<user name="bianca" profile="secretary"/>
...
<default profile="default"/>
</profiles>
It contains a list of named users, and their associated profile. The profile in that case are aliases, for example developer is a shortcut for developer.zip in the same directory.
The default profile will be applied for any login not listed explicitely in the set of users. At this point there is no support for grouping user definitions in the format, this may be added later if there is an unambiguous way to do it.
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:
...
<user name="titeuf"
profile="http://server.corp.com/prof/developers.zip"/>
<user name="fab"
profile="http://server.corp.com/prof/developers.zip"/>
...
The profiles should then be maintained on a separate machine and copied over to the server when updated.
The user database can also be centralized, using the XInclude mechanism for XML. For example the following assume there is a developer list maintained separately on the server, and defining the profiles for them:
<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>
This XInclude will just collect all user definitions in the developer list at http://server.corp.com/user/devel.xml 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 devel.xml contains
: ...
<user name="titeuf" profile="../prof/developers.zip"/>
...
then sabayon 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 http://server.corp.com/prof/developers.zip. Also note that shortcut are not allowed there, the trailing .zip is needed.
The last point about the centralized support is that sabayon will use a cache located in the user home directory under .sabayon/profile_cache to keep a copy of the non-local files, this allows profile to function normally in disconnected operations or in case of server failures.
Sabayon also supports using LDAP to get profiles in a very flexible way. Further details here.
Sabayon supports using LDAP to get profiles in a very flexible way. By defining server settings and queries in the /etc/desktop-profiles/users.xml file it can do the mapping from user to profile file using LDAP queries. An example setup can look like:
<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>
The toplevel ldap tag sets up the server connection. Availible attributes are:
Inside the ldap tag you can define the two queries used by sabayon. 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 /etc/desktop-profiles by appending ".zip".
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.
Both queries support these attributes:
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 %.
There are many way to set up the sabayon LDAP integration. Here are some examples, all using the sabayon LDAP schema that comes in the sabayon package.
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.
...
<ldap server="...">
<profilemap search_base="ou=People,dc=example,dc=com"
scope="one"
query_filter="(uid=%u)"
result_attribute="sabayonProfileURL"/>
</ldap>
...
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.
...
<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>
...
This lets you pick a profile based on what group the user is part of by adding the sabayonProfileURL attribute to the group object.
...
<ldap server="...">
<profilemap search_base="ou=Group,dc=example,dc=com"
scope="one"
query_filter="(memberUid=%u)"
result_attribute="sabayonProfileURL"/>
</ldap>
...
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.
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.
Use ZIP for the container format:
Add an XML metadata section as the first entry:
The container is a Zip, its content can be viewed using the command unzip -l /etc/desktop-profiles/test.zip
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 unzip -p /etc/desktop-profiles/test.zip metadata:
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.
Note that an application can have one stream per different configuration file for example .rhopenoffice1.1/user/registry/data/org/openoffice/Inet.xcu and .rhopenoffice1.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.