Home Home > Usability
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Archive for the ‘Usability’ Category

Locking down GNOME in SUSE 11 based distributions

January 20th, 2010 by

Locking down the desktop may be an important functionality for you or it may be a major annoyance. This depends on your point of view and on which side of the administration fence you are. There are certainly many use cases where the restriction of desktop functionality is very important. One such use case may be the configuration of machines in a teaching environment.

For GNOME, Sabayon is a GUI tool that allows you to set up the desktop to your liking and store the configuration as a profile. Profiles can be deployed to any system allowing the machine to display the desired desktop based on who logs into the machine. Further you may also use Pessulus to lock down the GNOME desktop. Additional information may also be found in the GNOME Admin Guide.

In addition to the options mentioned above there is a command line tool (gconftool-2) you may use to create customizations from the command line. The gconftool-2 tool creates entries in the configuration tree for gconfd, the GNOME configuration daemon. The GNOME configuration is stored in XML files named %gconf.xml in a directory structure where directory names indicate the part of the desktop or GNOME application to which the features set in the XML file apply. For example options set in apps/nautilus/desktop/%gconf.xml determine the behavior of Nautilus when the desktop is drawn.

For users the configuration tree is stored in $HOME/.gconf allowing users to configure the desktop appearance and application behavior to their liking. For system wide configuration, configuration trees exist in /etc/gconf. Within the /etc/gconf directory structure the gconf.xml.mandatory directory tree represents the configuration tree that is used to lock down the system. Options specified in the /etc/gconf/gconf.xml.mandatory configuration tree cannot be altered by the user.

For example if we want to disable icons for mounted volumes to be displayed on the desktop and we would not want users to be able to enable this feature the following command will do the trick:

gconftool-2 --direct --config-source \
 xml:readwrite:/etc/gconf/gconf.xml.mandatory \
 --type boolean --set /apps/nautilus/desktop/volumes_visible "false"

The path of the parameter to be set can be determined by using the gconf-editor tool. The gconf-editor is an editor/browser for the GNOME configuration tree and is very helpful when trying to find features to be manipulated within the GNOME configuration directory. Detailed information about the gconf-editor can be found here. Knowing the path for the option to be set and the location of the configuration tree that contains the locked down configuration (/etc/gconf/gconf.xml.mandatory) it is easy enough to create a script that can be executed when a machine is set up to configure the desktop appearance as desired.

If you are using KIWI to create system images the gconftool-2 commands can easily be added to the config.sh script to configure the desktop behavior in the image. Creating a self installing CD/DVD or USB stick with KIWI allows you to deploy your pre-configured desktop image when ever a new system needs to be commissioned.

As a final option to locking down GNOME there is the well trusted route of editing the configuration files. Important when creating a GNOME configuration tree manually is that a %gconf.xml file needs to exist at every level. Considering our previous example one will need to create a %gconf.xml file as shown in the directory tree layout below:

apps
   |__ %gconf.xml
   |
   |__ nautilus
              |__ %gconf.xml
              |
              |__ desktop
                       |__ %gconf.xml

The XML files at the apps and nautilus directory levels are empty but must exist. The %gconf.xml file at the desktop level contains the following entry:

<?xml version="1.0"?>
<gconf>
    <entry name="volumes_visible" mtime="1260052996" type="bool" value="false"/>
</gconf>

The XML is simple enough and self explanatory. Further as you explore the configuration in the gconf-editor tool the types to be entered in the XML are fairly obvious. One caveate applies for entries of type string. Rather than having the value of a string configuration option be an attribute of the entry element like other types the string is special. For a string you will need to use the <stringvalue> child element of the <entry> element. For example if you wanted to disable the panel completely you would have the following entry

<?xml version="1.0"?>
<gconf>
    <entry name="panel" mtime="1263563592" type="string">
        <stringvalue></stringvalue>
    </entry>
</gconf>

in /etc/gconf/gconf.xml.mandatory/desktop/gnome/session/required_components/%gconf.xml

The gconftool-2 command creates the tree in the location specified with the –config-source command line option. Thus you can switch between manual edits and using a tool very easily. Once you have your tree you can package it up as an RPM and also add it to your auto YaST deployment if you are using this methodology.

With the available tools and/or by editing the configuration files directly locking down the GNOME desktop is relatively straight forward. The tricky part often is to find the correct file or the correct button to push for the desired behavior. This is where gconf-editor is the very valuable browser you are looking for.

Happy Hacking.

openSUSE Edu Li-f-e : creating open minds

November 17th, 2009 by

openSUSE Education community is proud to announce openSUSE-Edu Li-f-e: Linux for Education based on openSUSE 11.2 . Li-f-e flavor bundles the best of softwares openSUSE has to offer, such as most popular Desktop Environments, educational application, development suites, multimedia, great user experience out of the box, and a lot more that is expected in a modern Operating System.

Li-f-e
Some highlights of what makes this a very special distribution:

(more…)

LXDE: LXDM and Trash support

September 12th, 2009 by

Some cool news for any LXDE users.

The first one, LXDE developers finally started to develop their own Display Manager, that means that soon we’ll need no more the very heavy GDM or the no more developed SLIM.

That new DM is called (as you can think) LXDM and svn snapshot are now available in my home:anubisg1:LXDE repo,  as soon it will be stable enought  i’ll move it into X11:lxde.

(more info about LXDM available here: http://blog.lxde.org/?p=531

SLIM itself has been improved with a couple of patches and the logotrate support.

The second cool thing is a nice patch i got from a Slackware developer, it add trash support using the python trash-cli based on freedesktop.org standards.  PCManFM with trash support is alread yavilable into X11:lxde and home:anubisg1:LXDE repos.

Some screenshots here:


Please consider that home:anubisg1:LXDE needs to be considered a development only repo. I experiment in my repo, and only when i think the changes are stable enought than i’ll move the into OFFICIAL X11:lxde repo.

openSUSE-LXDE live CD now ready!

September 2nd, 2009 by

Yes, that’s true! After some develop and tests i finally completed the openSUSE-LXDE live installable iso based on openSUSE 11.1 made with SUSE-STUDIO.

I provide now, only 32bit (i686) image because that may still need some testing.

Some great news, bug #531667 has been accepted and fixed, that means that suse 11.2 will be able to run slim using /etc/init.d/xdm script as usual. The iso already includes that fixs.

here iso link: http://lxde.bsnet.se/openSUSELXDE_32bit.i686-0.9.4.iso

MD5: ffc163867d55f8e23718347a323d5c9a
SHA1: fd52440de253b9b801c4343c29de5472ffabe935

— post edit —

Thanks to Fisher Duan we have a new “mirror” here:

http://www.steamedfish.org/downloads/

— post edit —

if somebody else wants to host it, feel free to do it, just email me : andrea@opensuse.org

Oh, i forgot, some release notes and links:

RELEASE NOTES:

Login Manager : SLIM

Login manager used here is very lightweight, i’m talking about SLIM. it’s actually configured to autologin ROOT user on live CD; that setting is also saved on installed system (if you choose to install it), so to remove autologin (or just to autologin with you user) you MUST edit /etc/slim.conf, the file is well commented will not be difficult to find the lines.

LINKS:

http://en.opensuse.org/LXDE

http://lxde.org

Thanks to: Brother- for hosting

Andrea

Twitter Statusupdate via CLI (Shell)

August 13th, 2009 by

This was an interesting Idea, and i have found it on Tips4Linux. Based on: http://tips4linux.com/update-your-twitter-status-from-the-linux-command-line/

T4L: You can easily update your Twitter status from the CLI by using this one simple command:
curl -u user:password -d status=”Your status message” http://twitter.com/statuses/update.xml
where user is your username and password is your Twitter password entered in plaintext. Replace the text Your status message with anything you wish.

Smarter osc commit

August 3rd, 2009 by

Some hours ago I have worked on fix of eclipse build. But two parallel builds of eclipse (there are eclipse.spec and eclipse-archdep.spec) eats almost all resources of my computer, which was unusable. Fortunately vim needs a little of CPU time, so I decided to improve smarter osc commit, I implemented on Friday.

If you work with osc and packaging, you probably forgot to add a new patch, or source and commits sources with missing file, so build in OBS fails. Our internal script, which we used before BuildService has a check, which warns about files not specified in Patch or Source in a spec file, so it was a great feature for forgetful developers (as myself, for example). The problem is how to get a list of sources and patches for a current spec file? The internal script uses some “magic” shell code which calls a rpmbuild, because it’s rather impossible to parse a specfile correctly. Fortunately there is a simplest approach.

In build service package directory each file has a state – added, modified, removed, …. So my idea is simple – check state of all files in the directory and if there is any file with ‘?’ (file exists, but not in metadata) or ‘!’ (file is in metadata, but not in directory) state, ask user what to do. The initial implementation allows to continue or abort and was not user friendly as it could be. So during rebuild of (two) eclipse I wrote a better implementation.

Lets have a package (for example called xdoclet) and we want commit our changes to OBS. So

$ osc status
?    xdoclet-modules-objectweb-4.6.tar.bz2
?    xdoclet-src-1.2.3.tar.bz2
!    xdoclet-modules-objectweb-4.6.tgz
!    xdoclet-src-1.2.3.tgz
M    xdoclet.changes
M    xdoclet.spec

You see, that we used bznew to repack tgz files to tar.bz2, which is recommended in openSUSE. Then we commit our changes

osc commit
File `xdoclet-modules-objectweb-4.6.tar.bz2' is not in package meta. Would you like skip/remove/edit file lists/commit/abort? (s/r/e/c/A)

I suppose that all options are clear – skip will skip check for this file, remove will remove it, commit forced commit and abort breaks it. But I don’t like this message, so if you have some better proposal, please contact me.

The most important command is edit file list. I thought how to easily add and remove files using this smarter commit. The final implementation has been inspired by one of the coolest git feature – interactive rebase.

So after selecting e, the list of files is opened in your EDITOR

  1 leave   xdoclet-AbstractProgramElementTagsHandler.patch
  2 leave   xdoclet-WebLogicSubTask.patch
  3 leave   xdoclet-XDocletModulesEjbMessages.patch
  4 leave   xdoclet-ant.not-required.patch
  5 leave   xdoclet-build_docs_xml.patch
  6 leave   xdoclet-build_xml.patch
  7 leave   xdoclet-component-info.xml
  8 leave   xdoclet-maven-plugin-project.patch
  9 leave   xdoclet-maven-plugin-template.patch
 10 leave ? xdoclet-modules-objectweb-4.6.tar.bz2
 11 remove ! xdoclet-modules-objectweb-4.6.tgz
 12 leave   xdoclet-project_xml.patch
 13 leave ? xdoclet-src-1.2.3.tar.bz2
 14 remove ! xdoclet-src-1.2.3.tgz
 15 leave M xdoclet.changes
 16 leave M xdoclet.spec
 17
 18 # Edit a filelist for package %s
 19 # Commands:
 20 # l, leave = leave a file as is
 21 # r, remove = remove a file
 22 # a, add   = add a file
 23 #
 24 # If you remove file from a list, it will be unchanged
 25 # If you remove all, commit will be aborted

and a manipulation is obvious. Just replace a command listed in a first column by another one, then save a file and instructions will be processed and package will be commited.

BTW: Of course this feature can be suppressed by new -f/–force option.

Source Services 0.0.1, no more writing SPEC files ?

August 3rd, 2009 by

Okay, my first example of the build service source services did something usefull on my notebook. I submitted a very short file and I got installable packages in return. The file is actually that simple that it can easy get created by any IDE, website or desktop shortcut.

So the final goal is to get a 1-Click package build, but there is even more !

(more…)

Self Optimization through Self Awareness

July 15th, 2009 by

Nat blogged about Life Logging which means that one logs some life influencing parameters such as get up and go to bed times, blood pressure and more. While it might be funny to see some statistical data about ones life and maybe useful for pub evenings (“I bet you can’t beat me in that: On mornings after evenings where I had fife beers and the average temperature in the pub was not above 25°C and the amount of female guests was under 56% I make it to a shoesize of 46!”) I think that is quite useless. The human being is a too complex thing. It is influenced by tons of parameters. Measureing just can log a few of them. That would not be a problem, as long as one does that for the pub purpose, but as Nat says this is done for “performance optimization” of the person, it gets difficult.

I would love to argue now with more or less esoteric theories of what a person is influenced from like the polarization of the sunlight or earth rays but I fear that would not be appreciated by the usual audience here. So lets stress automatic control engineering (german Regelungstechnik, I hope that translates) which fascinated me earlier.

There is a base axiom that says: The more complex the system to control is, the more complex the model of the system is and the more parameters you have to take into account for your controller model to control the system to get the expected outcome. If your model of the controlled system does not align with the real system and/or wrong input parameters are picked you do not get what you want. The whole circle of controlled system and controller becomes unstable.

Given the complexity of the human being I think it is impossible to get something usefull out of measuring a few parameters of life and hope to get any hints for “performance improvements”. Its dangerous because it easily might become unstable.

And imagine how long it takes to log all the data and how complicated it might become – for example if you need to log the percentage of women in the pub every 10 minutes, that might lead to interesting social interaction. That time and trouble can be saved.

My suggestion is to improve self performance through self awareness. People need to learn to listen to themselves and do what is good for them. How that can be done? Well, yes, that seems not always to be an easy task. Suggestions around that I better leave that for the next “Dragos hints for a better personal life” lesson 😉

Official X11:lxde project now open! We need you!

July 13th, 2009 by

Thanks to Pavol Rusnak, the official project X11:lxde is now open, first packages are already there available for testing, but, some of them just fail because of code and security checks, we need some patches than, before provide you the best packages you can imagine for that DE.

WE NEED YOU!!!

if any of you want to help us providing patches and various fixing you are welcome, and of course you can begin using OBS collaboration way: http://en.opensuse.org/Build_Service/Collaboration

A fast review of the problems we have are available on that post into LXDE forum.

Right now than, if you want to use LXDE you should continue to follow instructions provided on my previous blog post here

Waiting for you and you help

Andrea

Coming soon on the servers near you: Easy-LTSP-NG

June 2nd, 2009 by

Easy-LTSP, an easy to use GUI to configure LTSP‘s lts.conf file was developed as a part of Google Summer of Code ’08 by Jan Weber. It was written in C#, it was decided to use C# at that time to accomplish a complex task in a very short period of time given for GSOC. Thanks to it setting up LTSP on openSUSE is just a few mouse clicks.

Easy-LTSP was designed to work on any distribution, but unfortunately it is not integrated anywhere other than openSUSE, discussing with the upstream LTSP developers suggested the slight reservation could be due to it being written in C#. We wanted to add new features to the GUI to take care of all the exciting new development we have in KIWI-LTSP so it was felt that the rewrite will be much better option than to extend the current code, as it is anyway being written from scratch why not use something like Python which would be easier to attract more contributors and increase possibility that users of all distributions running LTSP server can benefit from it inclusion in their prefered distro.

Here are the screencaps of the “Next Generation” Easy-LTSP(click image to see full album):

The code is in very initial stage, many things do not work yet, these screenies would give some idea where the design is going. If you are a developer interested in hacking get the source from here, drop us a line if you want SVN commit access. If you are a user and have some suggestions or an idea how this tool should be like file an enhancement request on devzilla here.