Home Home
Sign up | Login

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

rjschwei

Author Archive

Newer Entries »

1-2-3 Cloud

June 20th, 2011 by

Towards the end of last year there was an article in openSUSE news “announcing” the cloud efforts in the openSUSE project and on OBS. Well, cloud is still all the rage (see Jos’ contribution to openSUSE News issue 180) and people just cannot stop talking about cloud computing.

Using openSUSE as a host for your cloud infrastructure is also making great progress. We have 3 cloud projects in OBS and hopefully these cover your favorite cloud infrastructure code, Virtualization:Cloud:Eucalyptus, Virtualization:Cloud:OpenNebula, and Virtualization:Cloud:OpenStack. The projects provide repositories for Eucalyptus, OpenNebula, and OpenStack, respectively.

We attempt to make it relatively easy to get a cloud up and running. In this process OpenNebula and OpenStack have progressed the most. Eucalyptus is working, but due to an issue with Eucalyptus and openSSL 1.0 and later (the version in openSUSE) automation has to wait until these issues are resolved.

For OpenNebula we now have a KIWI example that shows how one can get a cloud setup from scratch in less than 2 hours, including the image build. The example contains a firstboot workflow for the head node, and self configuration of cloud nodes.

For OpenStack SUSE Gallery images are in the works and will be published in the near future.

All repositories provide packages you can install on running openSUSE systems. If you are interested in using openSUSE as the underlying OS for your cloud or if you want to contribute to the cloud projects, subscribe to the cloud mailing list opensuse-cloud@opensuse.org

Posted in Build Service, Infrastructure, Packaging, Programming, Virtualization | Comments Off on 1-2-3 Cloud

Wacom Bamboo Pen and openSUSE 11.3

September 23rd, 2010 by

It all started when my daughter discovered the Bamboo Pen. Naturally the tablet quickly turned into a must have accessory to her computer. After a bit of Googling I came to the conclusion that making the beast work with Linux should be possible. The prize for the effort would be a very happy young lady.

In order to avoid any potential hassle with shipping etc. we went to the local Best Buy to buy the tablet. As the store had the hardware at the same price as online retailers that decision was easy.

Once I actually had my fingers on the tablet it was time to make it work. Doing a bit more detailed research now, I found various openSUSE forum posts and various other links. Some of these were not quite consistent, others appeared to address only half the solution. Therefore, I decided to cast away most of what I had found and just concentrate on the information found on the Linux Wacom Project. The HOWTO is informative and provides all information needed to get everything working. The HOWTO does not provide the information in the linear fashion I like, when I try to get something new to work. With a bit of hoping back and forth and some pocking around I got the tablet to work.

Now to the linear summary on how to get the tablet working.

  • Install openSUSE 11.3
  • Install the necessary packages to build the code provided by the Wacom project (root access required)
    • kernel-source
    • kernel-syms
    • xorg-x11-server-sdk
    • plus make and standard build infrastructure
  • Get the sources from the Wacom download page (0.8.8 at the time of this writing). This is the kernel driver code. The included X utilities and driver code in this version will not work on openSUSE 11.3 and will not build either, that’s OK.
  • Get the X utils and driver code from the Wacom main page. The link at the time of this writing is near the top of the page and links to version 0.10.8
  • Build the kernel driver
    • Unpack the kernel driver code tar -xjvf linuxwacom-0.8.8-8.tar.bz2
    • cd linuxwacom-0.8.8-8
    • Configure the build ./configure --enable-wacom
    • Build the driver make
  • Copy the newly built driver over the driver supplied by the openSUSE kernel (root access required) cp src/2.6.30/wacom.ko /lib/modules/`uname -r`/kernel/drivers/input/tablet/
      • If you want to make a backup copy of the project provided driver make sure you store the copy outside of the modules tree, i.e. outside of /lib/modules/`uname -r`
  • Remove any updates for the driver rm /lib/modules/`uname -r`/weak-updates/updates/wacom.ko
  • Build the X11 utils and driver
    • Unpack the sources tar -xjvf xf86-input-wacom-0.10.8.tar.bz2
    • cd xf86-input-wacom-0.10.8
    • Configure the build ./configure
    • Build make
    • Install (root access required)make install
  • Create a udev rule (root access required)
    • With your favorite editor open /etc/udev/rules.d/60-wacom.rules
    • Add the following code
      # udev rules for wacom tablets.
      KERNEL!="event[0-9]*", GOTO="wacom_end"
      # Multiple interface support for stylus and touch devices.
      DRIVERS=="wacom", ATTRS{bInterfaceNumber}=="00", ENV{WACOM_TYPE}="stylus"
      DRIVERS=="wacom", ATTRS{bInterfaceNumber}=="01", ENV{WACOM_TYPE}="touch"
      # Convenience links for the common case of a single tablet. We could do just this:
      #ATTRS{idVendor}=="056a", SYMLINK+="input/wacom-$env{WACOM_TYPE}"
      # but for legacy reasons, we keep the input/wacom link as the generic stylus device.
      ATTRS{idVendor}=="056a", ENV{WACOM_TYPE}!="touch", SYMLINK+="input/wacom"
      ATTRS{idVendor}=="056a", ENV{WACOM_TYPE}=="touch", SYMLINK+="input/wacom-touch"
      # Check and repossess the device if a module other than the wacom one
      # is already bound to it.
      ATTRS{idVendor}=="056a", ACTION=="add", RUN+="check_driver wacom $devpath $env{ID_BUS}"
      LABEL="wacom_end"
  • Regenerate the module dependencies depmod -e

There you go, now you can connect the tablet, fire up GIMP and be creative.

Posted in Desktop, Kernel, Miscellaneous | 6 Comments »

Into the Cloud

March 29th, 2010 by

Setting up your own Cloud infrastructure on SUSE has just become a lot easier. You can now use Kiwi and a mostly pre-configured set-up to build your own Cloud node images. Once these images are built setting up your Cloud can be accomplished in a few minutes.

Checkout the Cloud Recipe in the Kiwi Cookbook.

Happy Hacking

Posted in Systems Management, Virtualization | Comments Off on Into the Cloud

Setting up a slide show screen saver in GNOME

March 10th, 2010 by

There are multiple options to set up a slide show screen saver that shows the pictures of your choosing when the screen saver kicks in. The following shows the various options and works with the gnome-screensaver.

Easy does it

The most direct way to get a slide show screen saver going is to place your pictures in the $HOME/Pictures directory, then start the GNOME screen saver settings dialog by using gnome-screensaver-preferences from the command line or by selecting the Screensaver icon in the Control Center (gnome-control-center). In the screen saver settings dialog select “Pictures folder” and click “Close”.

One step of customization (not the preferred option)

If you do not want to use the Pictures directory as the location for the pictures to be shown you can customize the location by making a few simple edits. As the root user edit the file /usr/share/applications/screensavers/personal-slideshow.desktop. At the end of the line that starts with “Exec” add “–location=PATH_TO_PICTURE_DIRECTORY”, without the quotes and with PATH_TO_PICTURE_DIRECTORY being a real path. For example if my pictures were in /opt/slideshow the modified line would look as follows:

Exec=/usr/lib/gnome-screensaver/gnome-screensaver/slideshow –location=/opt/slideshow

Save the file and select the “Pictures folder” in the screen saver preferences dialog to select the slide show as your screen saver.

While this is a straight forward modification this is not really a good solution. The reason being that this modifies a file that is part of a package and when the package gets updated you will loose your changes.

A second step of customization

The better solution to accomplish the task of customizing the picture location is to create a new .desktop file in /usr/share/applications/screensavers. You should use the personal-slideshow.desktop file as your starting point.

As root copy the personal-slideshow.desktop file to a file with a name of your choice, then edit the file. Change the value of “Name”, “Comment”, and add the “–location” option at the end of the “Exec” value as previously. Save the file and start the GNOME screen saver preferences dialog. In the list to the left search for the value you assigned to the “Name” variable when you edited the new .desktop file. Select it and your all set.

Getting fancy

If the animation of the pictures in the previous slide show setup is not sufficiently fancy for you, the GLSlideshow screen saver maybe the ticket for you. Unfortunately you cannot just simply configure the location of the images you would like to use in the GNOME screen saver preferences dialog or via command line arguments to the glslideshow screen saver. In order to configure the location of the images to be used it is necessary to run the xscreensaver settings dialog (don’t worry, in the end gnome-screensaver will be running again).

Just starting xscreensaver will fail as only one screen saver daemon per display is allowed. Therefore, it is necessary to first kill the gnome-screensaver; use the following commands:

-> ps -A | grep gnome-screens

At the beginning of the line this produces you will find a number, this is the process ID (PID). Use this number in the next command

-> kill -9 PID

Now fire up xscreensaver and select “Settings”. In the settings dialog select “GLSlideshow” and then switch to the “Advanced” tab. In the “Image Manipulation” frame select “Choose Random Image” and then enter the path of the directory containing your image files in the text box below the check button text. If you click the “Settings” button on the “Display Modes” tab you can set various parameters for the slide show.

With the slide show configured you can switch back to the GNOME screen saver if you so desire. In the settings dialog select File->Kill Daemon, then File->Quit. Now in a terminal window restart the GNOME screen saver by using the “gnome-screensaver” command. The process is a daemon and it will background itself. That’s it, now if you select the GLSlideshow in the GNOME screen saver preferences dialog you will see your images being selected.

With this you can have a slide show as your screen saver in no time.

Happy Hacking.

Posted in GNOME | 1 Comment »

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.

Posted in GNOME, Usability | Comments Off on Locking down GNOME in SUSE 11 based distributions

openSUSE 11.2 on Dell Mini 10v

January 4th, 2010 by

The Dell Mini 10v is nothing special from a hardware perspective for a Netbook, and follows along the specs of most other Netbook models on the market today. The integrated buttons in the track-pad take some time getting used to, and IMHO separate buttons are more user friendly. For my recently acquired new toy I increased the RAM to 2 GB and added the larger battery. On the software side the Dell Mini 10v is something special as it is one of few Netbooks available with Linux pre-installed. Other Netbook brands either have no Linux option or charge extra when straying of the beaten hardware and OS combination path, at what I consider to be outrages rates. While as a devoted SUSE user I’d rather see openSUSE than Ubuntu pre-installed getting Linux on the machine and not having any of my hard earned money diverted to the monopolist from Redmond was a key purchasing decision.

Once unpacked and the battery charged I played with the Ubuntu distribution pre-installed by Dell for a while. Network configuration was easy enough and I could probably get used to the Desktop interface if I used it for a while. Next up was Moblin, more out of curiosity than for “serious” evaluation purposes. Having read some concerns about openSUSE 11.2 on Netbooks in some mailing list thread or review I decided to give it a try, knowing that I might be in for an unpleasant surprise. At the same time I was setting up the machine a thread about the Broadcom wireless card used in the Dell Mini appeared on the openSUSE mailing list,very timely indeed. As it turns out my concerns were unfounded.

I downloaded the GNOME Live CD from http://www.opensuse.org/en/, then used the information provided on the openSUSE wiki (http://en.opensuse.org/Live_USB_stick) to create a USB live image. After fiddling with the BIOS setting to boot from USB media first I was able to run the openSUSE 11.2 live image and the installer from the stick. Once openSUSE 11.2 was installed I configured the Ethernet card to get network access. Empowered with access to the Internet I added the packman repository

# zypper ar http://ftp.skynet.be/pub/packman/suse/11.2/ Packman

This can also be done through YaST for those more comfortable with GUI tools.

Next step was to refresh the repository data

# zypper refresh

and then to install the Broadcom firmware package and kernel driver

# zypper in broadcom-wl broadcom-wl-kmp-default

last but not least I loaded the module into the kernel

# modprobe wl

and now the Broadcom wireless card showed up when using the ifconfig command as eth1. I used the NetworkManager applet to configure the network connecting to my wireless AP and everything works just fine.

In summary, all is well with openSUSE 11.2 on the Dell Mini 10v including the 3D desktop with compiz.

Posted in openSUSE 11.2 | 1 Comment »

Newer Entries »