Home Home > Server
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 ‘Server’ Category

KDE icons for Apache

February 15th, 2010 by

apache-kde

I have been working on making Apache’s directory listings a bit more beautiful by creating a collection of KDE icons (Oxygen and Crystal). Apache’s default icons are a bit old and not that vivid. In fact, they were originally made for Mosaic. So, what I’ve done is handpicking some Crystal and Oxygen icons, making a few by combining two icons, modifying some Apache’s config files, writing the instructions and, finally, putting everything together. So, now we have apache2-icons-oxygen and apache2-icons-crystal.
I would like to take this opportunity to thank Adrian Schröter and Peter Pöml for the help and feedback.

The rpm packages are available on my OBS home project:
http://download.opensuse.org/repositories/home:/javierllorente/

Comments and suggestions are welcome!

Xen para-virtualized openSUSE 11.2

February 10th, 2010 by

I had to install Xen para-virtualized openSUSE 11.2 (PVM), lucky for me 11.2 DVD iso has broken xen kernel so it does not install, the live CDs do not have any xen kernel at all so they are not useful either. After reading up all the posts on the bugzilla and forums about the subject, found the way to get it done, here is a howto for anyone else who is looking for the solution.

1. Set up http installation source

Install web-server pattern from yast to install apache2 in Dom0

Edit apache configuration /etc/apache2/default-server.conf to follow symlinks, it should look something like this:

#Options none
Options Indexes FollowSymLinks

Mount the DVD iso and copy all the files to your webserver root.

mount openSUSE-11.2-DVD-i586.iso /mnt -o loop
mkdir -p /srv/www/htdocs/suse-11.2
cp -ar /mnt/* /srv/www/htdocs/suse-11.2/
cd /srv/www/htdocs/suse-11.2/boot/i386/
rm *-xen*
wget http://download.opensuse.org/distribution/11.2/repo/oss/boot/i386/initrd-xen
wget http://download.opensuse.org/distribution/11.2/repo/oss/boot/i386/vmlinuz-xen
ln -s initrd-xen initrd-xenpae
ln -s vmlinuz-xen vmlinuz-xenpae
cd /srv/www/htdocs/
wget http://download.opensuse.org/update/11.2/rpm/i586/kernel-xen-2.6.31.12-0.1.1.i586.rpm (or the latest)
mv kernel-xen-2.6.31.12-0.1.1.i586.rpm kx.rpm
rcapache2 start

2. Start installation via “yast2 vm-install”, select para-virtualization and as installation source use http://dom0IP/suse-11.2/
3. The hack part:
When the install is about 80%  or “Stop” the reboot after the completion of first stage install, switch to tty2 by using “Sendkey > ctrl+alt+F2”.

chroot /mnt
rpm -Uvh http://dom0IP/kx.rpm –force

Reboot and let the install run its course, at the end of it there should be working domU

Edit: If you have fast internet connection available during install, add the update repository as “Addon product”, with that in place the above hack will not be necessary.

Edit2: If the image still don’t boot, mount the disk image to edit grub’s menu.lst:

mount -o loop,offset=32256 /full/path/to/image/disk0 /mnt
cd /mnt
ln -s vmlinuz-….-xen vmlinuz-xen
ln -s initrd-…..-xen.img initrd-xen
vi /mnt/grub/menu.lst #to look like below:

title XEN
root (hd0,0)
kernel /vmlinuz-xen root=…..
initrd /initrd-xen

Cheat ocfs2-tools

February 9th, 2010 by

When running ocfs2 on cLVM, openais+pacemaker setup, you may run into something like described below.

The symptoms:

umount /data1
mspx1d0:~ # tunefs.ocfs2 –fs-features=sparse,unwritten /dev/system/data1
tunefs.ocfs2: Unable to access cluster service while opening device “/dev/system/data1”
mspx1d0:~ # mount /dev/system/data1 /data1
mspx1d0:~ # tunefs.ocfs2 –fs-features=sparse,unwritten /dev/system/data1
tunefs.ocfs2: Configuration error discovered while opening device “/dev/system/data1”

Here is how to get past cluster check when running ocfs2-tools.

From hb_gui or crm stop mounting of the file system and ocf::ocfs2:o2cb resources.

Install ocfs2-tools-o2cb package

Do normal stack configuration using /etc/init.d/o2cb configure, but do not auto start on boot. Read the fine ocfs2 manual.

Bring ocfs2 online: /etc/init.d/o2cb online ocfs2

Start ocfs2 service: rcocfs2 start

Update cluster stack on your partition with ocfs2 filesystem: tunefs.ocfs2 –update-cluster-stack /dev/system/data1

Do your thing with ocfs2-tools, such as: tunefs.ocfs2 -v –fs-features=sparse,unwritten /dev/system/data1

Stop ocfs2 service and unload o2cb: rcocfs2 stop && /etc/init.d/o2cb offline ocfs2 && /etc/init.d/o2cb unload

Re-enable ocf::ocfs2:o2cb resources and run tunefs.ocfs2 –update-cluster-stack /dev/system/data1 again. Re-enable mounting from hb_gui.  Hope there is a simpler way somewhere that I am not aware of.

A stable repository for kolab

January 17th, 2010 by

During the X-mas holidays Kolab, the groupware server got a stable repository for 11.1 and 11.2 on the openSUSE build service (OBS). All packages that are not provided by the openSUSE base distribution have been copied (using osc copypac) to the STABLE repository. Another possiblity to achieve the same result could be by making a fixed link to the unstable package using osc linkpac -r <rev>. Once the unstable package works again the link could be updated with osc setlinkrev -r <newrev> to point to the working revision or updated revision.

The stable repository already shows its benefits, as cyrus-imapd was updated from version 2.3.14 to 2.3.16 in the server:mail, being the cyrus-imapd development repository for Factory. As the cyrus-imapd package in kolab:UNSTABLE links to the server:mail one, it no longer builds as the kolab patches no longer apply. Unfortunately my computer went South, and real package development is at the moment not possible. A good thing to mention here is, that cyrus-imapd-2.3.16 includes patches that are needed for Kolab and which have been in the review queue for multiple years!

Just before X-mas Kolab-2.2.3 was announced. This version is not used in the openSUSE packages, as we package the version from trunk. After the 2.2.3 release the kolab development, moved back to trunk and the next version will be from trunk.

During the 8th annual KDE PIM meeting in Osnabrück, Northern Germany Kolab got some attention as well, with the following exciting announcement: KDAB and Intevation will be working on making a functional PIM suite and Kolab Groupware client based on Kontact for mobile platforms.

First post / First whishes

December 20th, 2009 by

Dear Santa-Claus, can you provide us a real full kvm solutions for next year.
So I didn’t have to fight with Esx .

Kolab cyrus-imapd inherits from openSUSE base cyrus-imapd

December 3rd, 2009 by

This week kolab became one small step closer to realize feature request 307846: include Kolab in openSUSE. Although it will take lots and lots of more work to achieve this goal at all. The one step closer was realized in cooperation with the openSUSE cyrus-imapd maintainer R. The openSUSE cyrus-imapd spec file in the repository server:mail spec file has been extended with information about kolab, but the actual execution of the information has been switched off. With the Build Service link functionality the package server:mail/cyrus-imapd has been linked to the package server:kolab:UNSTABLE/cyrus-imapd-kolab, where the kolab functionality gets built. This is achieved by activating the variable with_kolab in the project related configuration file:
# osc meta prjconf server:Kolab:UNSTABLE
%define with_kolab 1
Macros:
%with_kolab 1

See the Build_Service prjconf page in the openSUSE wiki for more information about this awesome functionality. This way the cyrus-imapd-kolab package inherits everything from the openSUSE base cyrus-imapd package.

One drawback for kolab administrators, you have to manually correct the currently installed kolab packages. Start with downgrading cyrus-imapd-kolab (it only downgrades the Build service version and not cyrus-imapd itself):
# zyp in cyrus-imapd-kolab
This will install the dependent package perl-Cyrus-IMAP-kolab instead of perl-Cyrus-IMAP and perl-Cyrus-SIEVE-managesieve-kolab instead of perl-Cyrus-SIEVE-managesieve and it might remove kolab and perl-kolab.

Now reinstall kolab with:
# zyp in kolab
that should be sufficient to be in sync with the repository again. Don’t forget to restart the services, with:
# rckolab restart

This week also showed the power of the build service, as I could install kolab within only some minutes after installing openSUSE-11.2 in Virtualbox, while I never installed openSUSE-11.2 before.

The kolab installation in openSUS-11.2 made some problems visible in kolabconf -n. The latter has been fixed, it was a general problem in kolabconf and did not have anything to do with openSUSE-11.2.

The kolabconf problem however required some debugging, with a resulted spin off that the spamassassin daemon spamd is no longer activated via the startup scripts, but as a library of amavisd instead. That is the way amavisd and spamd have been configured in kolab, but what was not honored in the kolab setup on openSUSE.

Due to the change in the amavisd and spamd deamons, the script kolabsrv has been extended, and can now show a list with services required by kolab and what their current status is (see screenshot):

kolabsrv list and status output

kolabsrv list and status output

The main task of kolabsrv is to convert the openpkg service names to the distribution dependent names.

The kolab project is heading towards a new release 2.2.3 with a planned release date in December 2009.

Sascha released a nice Brain Dump of the Week, giving a nice insight in the possible future of Kolab.

In one of the replies of Sasha’s brain dump, a references was made to project-builder, a project similar to the openSUSE build service. Although the OBS and project-builder may be similar, some people are wondering what the differences (1) and (2) are.

That’s quite a lot of information, but lots of things happened since my last blog entry about Kolab.

PS: many thanks that M. from Novell, who made my Lizards blog account working again. For the most part of this week, I’ve not been able to login to my blog account. After logging in with the correct credentials, I was referred back to the Lizards entry page. M. knows the details, so if this happens to you contact M. from Novell 🙂

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…)

Kolab becomes available again for openSUSE

October 18th, 2009 by

Kolab on openSUSE made some very good progress since my last blog update on this topic. The most visible thing to the system administrator is that all Kolab required packages are available on the build service for openSUSE_Factory which will become openSUSE_11.2 very soon and its and predecessors.

In the past Kolab depended on the project c-client for imap annotations, but about a year ago this project became less open source than it used to be. For this reason I started to look for an alternative, which was found by just removing the c-client project as a dependency for Kolab. This forces Kolab to use the php-pear-net_imap annotation code. It is perhaps not as fast as the c-client code, but I assume that this gives no problem on openSUSE based Kolab installations.

Getting rid of the c-client project has another very big advantage as it now no longer required to rebuild the php module php5-imap. This was always very very problematic, especially for the x86_64 architecture. So the current setup is really nice.

As usual with building packages, getting rid of the c-client looks easier than it actually was, as a bug in the php-pear-net_imap project resulted in a non working setup. It took quite some time, before the solution was found and Kolab started to behave correctly again 🙂

For openSUSE_11.2 the php package php5-pear-log was removed from the base distribution, which prevented many Kolab required php5-pear modules to be build. Once the package was added to the server:php:applications build repository all the required Kolab required php5-pear modules started to build properly.

So for the brave at heart, give Kolab on openSUSE-11.2 a try. For the less brave ones try Kolab on openSUSE-11.1.

Oh and don’t forget to vote for Kolab in openSUSE’s feature tracking system openFATE!

Hybrid Live Systems

August 5th, 2009 by

When talking about live systems on USB sticks people reported many problems with bootloaders like grub to boot the stick. Even though this is most often a problem with the stick hardware or the PC BIOS it’s an annoying situation which should have a better solution. There are also many people who wants to use the stick as a data container in combination with a live system to work with

With the ISO hybrid technology and the integration into kiwi there is a way to create such a stick very easily. A hybrid ISO is an iso filesystem which contains a MBR and thus it’s seen as a disk to the PC BIOS. As it’s an ISO the isolinux bootloader is used instead of grub which works better on many systems. Additionally the hybrid ISO can be used as a live system on CD/DVD as well as on a USB stick

What’s required to use this

  • kiwi v3.68 or later
  • syslinux-3.82-2.1 or later

How do I setup a hybrid ISO in kiwi

In order to activate the creation of a hybrid iso in kiwi you only have to add the hybrid=”true” attribute as part of your iso image type in config.xml:


<type boot="isoboot/suse-11.2" flags="clic" hybrid="true">iso

You can use the suse-11.2-JeOS from the kiwi-templates package as example image description for your hybrid testing. The generated .iso file can be dumped via a simple dd call onto the USB stick. The same file also can be used to be burned on a CD/DVD


dd if=LimeJeOS-openSUSE-11.2.i686-1.11.2.iso of=/dev/... bs=32k

After that the stick can be tested. By default all attempts to write data will go into the RAM of the system. As a stick allows storing data persistently you can create a write partition on the stick using fdisk:


fdisk /dev/...

kiwi will prevent using a vfat partition for the operating system. So make sure you create a 0x83 (linux) type partition and not a vfat partition for the write support. If you additionally create a vfat partition you can use it as a container for any kind of data independently from the live system. We choose vfat here to stay compatible with Windows systems.

Known bugs

  • when using the clicfs filesystem (flags=”clic”) the persistently write feature into a single partition will fail because clicfs currently can’t deal with raw block specials as cow device. Will be fixed as soon as possible

Have fun 🙂

Improved mirror selection for India

July 29th, 2009 by

Recently, it became evident that users in India don’t get good mirrors. This was solved by configuring a few German and US mirrors to serve users from India.

Courtesy of Adrian Reber from Esslingen University of Applied Sciences, there is an illustrative screenshot that visualizes the efficacy of this. The world map shows accesses to their openSUSE mirror by country (live view). In openSUSE’s MirrorBrain configuration, this mirror is set up to receive German, Danish, Polish, and Indian requests.

The background is that India has bad connectivity to neighbouring countries, but good connection to German and US mirrors. Therefore, now a few German and US mirrors are configured to serve India. The screenshot below demonstrates this for the mirror of the Esslingen University of Applied Sciences:

world map showing client distribution of accesses to an openSUSE mirror in Germany

world map showing client distribution of accesses to an openSUSE mirror in Germany

The world map clearly shows how the mirror gets nearly exclusively German requests, as well as those from India. The same happens for some other German and some US mirrors.

Note that if a mirror in India should become available (would be nice!), it would automatically be preferred, and the other mirrors become fallback mirrors.

While it is not new that we do this, the screenshot of Adrian’s analysis illustrates the issue very nicely. We have similar configuration for a number of countries, where a mirror selection purely based on countries and regions wouldn’t work. For this kind of tuning, we depend on user input.

Hints about how to improve serving our downloads are always appreciated. Please write to admin at opensuse dot org with input in this regard. Thanks!