Well, the “problem” is, that our Education team is currently more a team of technical specialists and many work is done behind the scenes without communication to “the outside”. So even if you did not hear from us for some weeks, we are still alive and coding!

Here are just a few examples, that are going on behind the scenes:

• Translation of the new openSUSE Education Portal is work in progress. Many thanks to our contributors Guillaume for the Français, Freek de Kruijf for the Nederlands, Sabarth for the Português, Gankov for the Русский (Russian) Portal translation!
• Kirill is currently reviewing all 425(!) packages in the Build Service Education project and submitting them to openSUSE Factory afterwards – so openSUSE 12.1 will come with a huge set of packages directly inside the official repository.
• Cyberorg is working on the next release of the openSUSE Edu Li-f-e DVD with the LTSP integration.
• Anubusg1 and many others (the project currently lists 44 maintainers) are doing the “normal” packaging stuff like upgrading and fixing packages for 12.1 (aka Factory)

The Desktop4Education project from Austria was again present at the Conference and gave a great overview of the current status of the project during their talk. Good to hear that the project is being frequently used as a reference case by the Austrian Federal Ministry for Education, Arts and Culture and as such promoted by them throughout Austria.

Talking with Andre Massing from the Simula Research Laboratory during his talk at the conference was quite interesting. Looks like the Science project might see some very interesting new packages in the next months. During the discussion, we agree that the Education and the Science project can share a lot of efforts in their project setups and organization. But they will stay separated (at least in the Build Service) as their audience is very different, even if they share some packages (which is currently done via links inside the Build Service).

My DHCP Server at home is configured to use LDAP – and I’ve done the configuration via YaST. Now I read in some M$ pages, that it’s possible to tell the Clients via DHCP (and Apache) to use my Proxy server automatically. (Yes, my wife still needs Win** for her schoolwork.)

First, I had to figure out how I can insert two “non standard” options into the LDAP configuration of the DHCP server. I called “yast2 dhcp-server” (thanks for the tab completion, btw!), marked the “Global Options” entry and clicked on “Edit” (not Add!). On the next page, click on “Add” to add a new Option. Just delete the first available entry “allow” and replace it with the full line as you would write it in dhcpd.conf. In my case, this is
option wpad code 252 = text;
and
option wpad “http://myserver/proxy.pac\n”;
(dunno if the “\n” is really needed). That’s the trick. Have a look at /var/log/messages in a separate terminal when you finish the yast2 dhcp-server module to catch possible errors.

Now all what’s left is a running apache server on “myserver” delivering the “proxy.pac” file to your users. The file content is well known – and google would find hundreds of examples for you.

Here’s a short subjective excerpt of the week:

• openSUSE is now officially on the Sugar radar as being a main distro behind Fedora! We will provide a Sugar-Live Media based on the packages from the Sugar repository in the Build service, soon. (The current openSUSE-Live Media already contains a desktop icon starting sugar-emulator.)
• The final release of openSUSE-Education for 11.1 makes big progress. Yes: we’ve still no final frozen Repository on opensuse-education.org – but at the moment it’s just filling up the repo with packages not available on the official openSUSE-DVD.
• One of the biggest success stories from this week: cyberorg started pulishing and polishing our Live-Media, including the latest openSUSE Updates and our new “Li-f-e” branding theme (thanks to Sam!).
• We also reached the interesting point where people ask if they can distribute our downloadable ISO-Images on real medias for money. At the moment, adding your compensation for expenses of burning, shipping, etc. is ok. But please inform us or the openSUSE-Board, if you start marketing and shipping.
• The Novell-Training team allows us to package their training material for openSUSE – and even better: they licensed it under a Creative Commons License! So from now on, we can provide professional training material for openSUSE starters!
• We started specialized ISO images for small kids, school desktops and servers. More will come in the next weeks.
• We got our own Category here on lizards.opensuse.org – so it should be easier to find openSUSE-Education related topics here on lizards.opensuse.org from now on.
• SLEducator starts providing support via skype – if anyone wants to speak to him directly, just phone “os4ed_support”
• Jeff Shantz has started to work on the YaST2 Education Module – and is happy to receive opinions on what is needed. Currently, he has a big list of topics – some are already discussed in our mailinglist.
• We start a discussion about the initial greeter for new users: currently, this is an “openSUSE” only greeter – perhaps we can patch the current one and adapt it for our Li-f-e images.
• Talked about real “one-click-installs” for server based applications like drupal, moodle, koha and so on. Target is a running application – ready to use. The YaST2 Education module might be a solution – another one might be subpackages doing all needed things via scripts.

There are for sure many more topics discussed during the week – the above is just covered by me. Looking at the list, I’m very interested how we will look like on one or two years…

This DVD includes:

• the official updates to all packages since the openSUSE 11.1 release
• fully pre-configured, ready to run KIWI-LTSP server
• tons of applications from openSUSE Education repository

You can get it from here: http://download.opensuse.org/repositories/Education/images/iso/ – it’s called openSUSE-Edu-KIWI-LTSP-live*.iso (the openSUSE-Edu-KIWI-LTSP-live-unstable*.iso is for development only). Please watch for the Build Numbers at the end of the ISO-Name if you report bugs in our bugzilla.

Have a look at CyberOrgs blog on the most efficient ways to download the image.

It turns out that the most problematic part was the new RPM-“Distribution” string for openSUSE since 11.1. As openSUSE is now completely build in the openSUSE Build Service, the Distribution string of each package switched from “SUSE LINUX Products GmbH” to “openSUSE 11.1” – and zypper complains about this vendor switch during a live upgrade.

My Solution: Just create a new file “/etc/zypp/vendors.d/openSUSE” as root and insert the following content:

[main]
vendors=openSUSE,SUSE LINUX Products GmbH

Now, zypper identifies packages from Vendor “openSUSE” as the same as packages from vendor “SUSE LINUX…”
Whats left is the adaption of the repositories (they should point to 11.1 now):

localhost:~ # cd /etc/zypp/repos.d/
localhost:~ # sed -i “s|11.0|11.1|g” *

…and right afterwards, the show can go on…

localhost:~ # zypper ref

Retrieving repository ‘OBS-Edu’ metadata [done]
Retrieving repository ‘Packman Repository’ metadata [done]
…

localhost:~ # zypper dup

Loading repository data…
Reading installed packages…
Computing distribution upgrade…

The following packages are going to be upgraded:
…

Press “y” and Enter – and go to bed or something else – next day, reboot your machine and welcome your new 11.1!

People using HTTP requests to download packages are sadly very affected by this limitation at the end of each month, and I apologise for the trouble caused. Thanks to the FTP-Server Admins of openSUSE, we’ve already a place to host our ISO-Images, containing the same files as the frozen repositories. We’ve also a FTP (ftp://ftp.opensuse-education.org/) and a RSync-Server up and running (rsync rsync.opensuse-education.org::download/) – which should make it a bit easier until we’ve the final decision from the new openSUSE-Board, if they can provide some space for us.

Until then, feel free to offer additional space for our repositories. We’ve already an offer from Peter Poeml to help us configuring a “Mirrorbrain” setup.

So for production purposes, we always recommend to use our frozen repositories on http://download.opensuse-education.org/. But as “frozen” implies, the repositories there are frozen at the time, the openSUSE-Education team declares them as “Goldmaster” (which is the case for all except the 11.1 repo at the moment) – and no package update or changes happens for this repositories.

The openSUSE-Education team has relatively long development and testing cycles – but as everywhere, shi* happens, and so it might be that some of the packages in the frozen repository are broken or need a security fix. For this, we have created update repositories (for at least 11.0 and the upcomming 11.1 Edu-Release) which are disabled per default, but added to the system during installation of the openSUSE-Education-release  package. (Reason behind this decision: if an administrator installs openSUSE-Education in a school, he wants to “mirror” the update repositories and not point every client to the official ones. All a user has to do is to enable this update repository via YaST or via “zypper mr -e ‘openSUSE-Education Updates'”.

We’re using the “updateinfo.xml” file formal described in the openSUSE-Wiki. Currently, we’ve 5 package updates/fixes for 11.0 in the update repository – and this might grow over the time. The updates are shown in the current online-update-applets as “normal” updates like the openSUSE ones. Interestingly, the user can’t see if an update is from the official openSUSE or the openSUSE-Education update repository – even if we use a different “from” tag. Perhaps we have to “play” with the “release” or other tags: testing is needed as it looks like nobody tries this before…

Here are some reasons why:

1. No displayed License before adding the repository (have a look at the Non-OSS or Education Repositories to get an idea how this works) – this might be important if people crash their hardware after adding a repository with special kernel modules without being informed about possible problems…
2. No package groups called “patterns” – so people can’t get an easy overview about the various software areas a project provides (using YaST -> Software -> RPM Groups is not usable for me since someone decided to show just a plain structure there).
3. No package translations (sometimes I like to see the Summary and Description of a package translated in my own language to understand the real area of application for this package).
4. As the Repositories change over and over again (sometimes just because a dependend package in another project has changed), you need to download at least the metadata of a project again and again. For the Education repository in the Build Service this means: transfering 4MB of data each time you call “zypper”. Not really nice for people with a low bandwith.
5. Endusers will “upgrade” their installed packages again and again – without knowing the real reason for this upgrade until they can have a look at the package changelog (hoping the developer has added some informations there). Not even the Factory distribution has this problem with automatic rebuilds (resulting just in increased release numbers) and no information for endusers why they had to download tons of MB each week…
6. Real Packagers use their Build Service repositories for development and testing – so some packages will likely be broken during this phase – and just the packager knows when it will be really “stable”. (I’m talking about “real packagers” as I often see people using their home projects in the Build Service just to create an own repository containing packages they use – just by linking packages from other projects without any changes. But this is another topic…)

Projects like KDE or GNOME try to balance some of this problems by using the “publish disabled” option until they want to release a new version of their project. But this makes testing for developers and testers harder: with publish disabled, developers and testers can’t easily download and test new packages via the synced, public repositories – they have to download their packages via the API of the Build Service one by one.

With the upcomming releases of the Build Service, this will hopefully change. Up with 1.5 project admins can create a “full featured YaST Repository” for their projects covering the points 1, 2 and perhaps 3. But I think we also need more or less “frozen” repositories beside the current project repositories to cover 4, 5 and 6.

These “frozen” repositories should IMO be placed in separate directories (like the official openSUSE distribution directories) to make it clear to everyone that these repositories have an “enduser focus” and not a “developer focus”. This way, a project like KDE or GNOME could:

• use the current repositories below download.opensuse.org/repositories as their “bleeding edge”  development repos for packagers and testers.
• have a separate enduser repository with additional features like patterns and translations using the “ftp tree generation” feature.

…and thats the reason why the summary of this blog contains the word “currently” – I think the Build Service is on a good way to be a really good solution for developers and endusers. But we should find a final solution for the open issues mentioned above before we point endusers to this tool.

Sometimes, you want to patch a package from another repository to build with special features enabled or disabled. The Build Service allows you to link the package from this other repository (and avoid wasting space by duplicating the sources) and add your patches.

Now think about a patch against a special version of a package – and you know that you don’t want a package with a newer version in your repository for a foreseeable time. But if you use the plain link command of the Build Service, the linked package in your repository will get updated if the original package in the original project is updated.

Luckily, the buildservice allows you to link against a “frozen” state of a package: it’s source-revision. People already knowing any revision control systems like Subversion also know that the revision of a source is increased each time, a new change is submitted. And that’s what we need now: link against a special revision of the package from the other repository and apply our patch against it. The webclient currently doesn’t support such special features, but with osc it’s very easy.

First, check the needed revision in the original project:

cd Education/MultiplicationStation
osc info


Project name: Education
Package name: MultiplicationStation
Path: /home/data/SVN/Education/MultiplicationStation
API URL: https://api.opensuse.org
Source URL: https://api.opensuse.org/source/Education/MultiplicationStation
srcmd5: 484c329659d613e3bbdd515a1a8d1099
Revision: 10
Link info: None

Now create a link with this (or any further) revision to your new project:

osc linkpac -r 10 Education MultiplicationStation isv:hp:education

..and in the resulting “_link” file in your new project, you’ll find:

<link project="Education" package="MultiplicationStation" rev="10">
<patches>
<!-- <apply name="patch" /> -->
<!-- <topadd>%define build_with_feature_x 1</topadd> -->
</patches>
</link>

So your linked package will always use the source revision 10 of the original project. Let’s start applying patches…

A normal user, who wants to use one of these apps, might just choose to install the package and has the problem how to proceed afterwards. openSUSE sadly has no “post config” scripts like Debian based distributions – even the SuSEconfig scripts are deprecated. So all a packager can currently do is:

1. write a README.SuSE (which is already the case for many packages) and place it in /usr/share/doc/packages/<packagename>/README.SuSE explaning how to proceed
2. sugget what the user always wants to do and do it via %post-script after the installation of the RPM
3. combine 1&2 and point the user to a script in the README.SuSE
4. write a YaST module which can be started during installation or afterwards
5. any other option I missed (please inform me!)

For the Education project, I’m currently thinking about two ways to make the life of the admins easier.

First: think about “wrapper packages” around the normal packages. I’ll take moodle as example. The normal moodle package installs the php-scripts, an apache configuration and some other config stuff – but will not setup the complete moodle instance. So the user has to install the mysql database himself. An additional wrapper package can do this for him. This package comes with a SQL-Dump of the current moodle version (therefore requires the exact moodle version), and uses a stored mysql-root password to create a new database and insert the database-dump. If needed (for example: the user enables the “user LDAP-Auth wherever possible” checkbox in a (to be written) yast-edu module), additional tasks can be triggered by the wrapper package.

We can also think about calling a “generic” YaST module after installation of such a “needs postconfiguring” package. If we define a place (say: /var/adm/YaST/postinstall/) where packages can place a file containing some important questions to configure the application, and someone writes a YaST module which can be started, this would perhaps be “very cool”. If the user has entered his values, the YaST module can start one or more scripts (coming with the package) and feeds it with the entered values. The biggest questions for this solution:

1. When should this YaST module be started? IMO it could be enough to let the user start it manually and select the package he wants to configure. => No adaptions of the current workflows is needed. But perhaps there are other options (like calling it via “SuSEconfig”)?
2. Who can write such a module?
3. Who defines the config syntax?

Think about a file like this:

<package name=”moodle”>
<questionpack type=”string” action=”/usr/share/moodle/scripts/install_database”>
<question arg=”1″ type=”string”>What’s the database password?</question>
<question arg=”2″ type=”string”>What should be the name of the new database (suggest: moodle)?</question>
<question arg=”3″ type=”string”>What’s the username of the new database user?</question>
<question arg=”4″ type=”string”>What’s the password of the new database user?</question>
</questionpack>

<questionpack action=”/use/share/moodle/scripts/configure_auth_backend” type=”selectbox”>
<question arg=”1″>What auth-backend should be used?</question>
<answer value=”1″>ldap</answer>
<answer value=”2″>mail</answer>
<answer value=”3″>passwd</answer>
</questionpack>
</package>

I think, there’s room for many enhancements in this area – what do you think ?

Should/Could we produce something like a “Windows-Installer” for openSUSE? Or is it enough to provide special “wrapper packages”? Or is “what was hard to write, should be hard to install” still a valid answer?