The wikis are now using the new authentication system.
If you did not migrate your account yet, visit


Jump to: navigation, search

Susemini.png 本文处于需要翻译的文章的状态,欢迎您积极参与翻译与修订。 翻译人员:无,修订人员:无。



The look behind: the development of the Edu-CD...


Currently, we have some "meta-packages" in our buildservice project:

The pattern-* packages contain the pattern files which can be found in CD1/suse/setup/descr/*.pat (*.pat.gz in openSUSE 10.3) and also xml-pattern files to create *.ymp files. We create the patterns "on the fly" via a couple of textfiles, which are merged dynamically during the build of the package. So we can use one central place for creating patterns for all distributions and architectures. If we add or remove a package from a pattern file, we re-submit the package to the buildservice - and all patterns for all distributions are in sync again.

A good description of the pattern content is available here.

The skelcd-education package contains all files, which are extracted on the media. For example:

  • README* (small Readme-Files)
  • autorun.inf (for users who inserted the CD on a windows client)
  • gpg-pubkey-*, pubring.gpg (the official openSUSE-Education GPG-Key - armor exported. All RPMs from openSUSE-Educaiton are signed with this key)
  • documentation in plain text
  • ...

Currently we use /CD1/ as base directory and place all files below this directory in the same way the would be placed on the real media. So you would find the README files in /CD1/README if you install the skelcd-education package as root on your system.

As we need some adjustments for every distribution and architecture, the skelcd-education package is also checked in to the education buildservice repository. Currently we use it for creating the content-, the README- and media-files with the right strings for each distribution and arch.

But using a rpm for this gives us more options for the future. Perhaps the package can require all packages in the pattern files as build requires - so we can be shure that a package exists for a distribution _bevore_ we add it as required package in the pattern, or we ignore some packages for a specific architecture, or we replace some strings in the readme and content files in each distribution or architecture...

Unpacking the meta packages

As we don't want to place all files for all distributions in the same /CD1/ directory to create our Repositories, we use the command unrpm (a bash-script which comes with the package build) and move the package content to the right place after extraction.

You can find more information about the "meta" files on the media here.

Preparing the packages

To get all available packages right when we need them, our CD-Creation server mirrors the Education:desktop and Education:server repository for all distributions, where we want to create CDs and repositories.

So the next step, after unpacking the meta-packages to the right location is to move all build packages to their directories in the repository.

We use the Vendor target "openSUSE-Education" in all our packages, So YaST can detect packages from us and we can update them later.

As the buildservice currently doesn't support own GPG keys, we resign all packages on their new location with our own GPG key (the one you can find in the root-directory of the CD). Yes: this is a small security hole as we currently can't be shure that we get the right packages from the buildservice - but this is what we can get so far...

Now we use some scripts from the inst-source-utils package and some simple bash scripts to create the dynamic meta files on the CD.

For our examples below, we use

  • /CD1/ as root directory ROOTDIR
  • suse/setup/descr as DESCRDIR
  • suse/ as RPMDIR
  • media.1/ as MEDIADIR
  • docu/ as DOCUDIR

Create patterns file

The patterns file contains all pattern files. So YaST knows in a very early step all about the available pattern files. The creation of the patterns file is so simple that we just need a single "ls" for it:

pushd $DESCRDIR 1>/dev/null
ls -A1 *.pat* > patterns 2>/dev/null
popd 1>/dev/null

Create MD5SUMS and directory.yast files

The MD5SUMS file contains the MD5SUMS of all files in a directory. YaST compares the md5sum in this file with the downloaded file to check for transmission errors.

The file directory.yast contains the whole directory content. Some FTP-Servers don't allow directory listings - but YaST needs to know which files are available in a directory to save time (for example: have a look in the i586 directory of the openSUSE-10.3 distribution) and sometimes to redirect to another workflow (if the file is available in media.1/media - display it; if not, search for the file licence.txt in the same directory...).

So we create the files for each needed directory:

for dir in . boot $MEDIADIR $DESCRDIR; do
    create_directory.yast $dir
create_md5sums .

Create SHA1-Entries in content file

To improve security, YaST searches for SHA1-Sums for some important files in the $ROOTDIR/content file since 10.1:

  • /gpg-pubkey*
  • /pubkey*

The script from inst-source-utils does this job.

Signing content and products file

Now we have to sign the $ROOTDIR/content and the $MEDIADIR/products file with our the GPG-Key.

gpg -a -b $ROOTDIR/content
gpg -a -b $MEDIADIR/products

and place our amor-exported GPG key there, too.

cp ~/gpg-pubkey $ROOTDIR/content.key
cp ~/gpg-pubkey $MEDIADIR/products.key

Create the ISO image

Last step: use mkisofs to create the ISO image. The steps above should have created a valid online-repository already (you can test it with YaST, adding the $ROOTDIR as repository). So the commandline looks like:

mkisofs -p '' \
-publisher 'openSUSE-Education Team' -r -J -f -pad \
-A OSSEdu-$DIST -V Edu${DIST}.001 \


Currently we built all packages on the media in the openSUSE Buildservice following the SUSE Build Tutorial and the Build Service Tutorial. So everyone who wants to help us packaging needs a buildservice account first.

Afterwards you can write an email to Lars or the mailinglist and we'll add you as maintainer of your package in the openSUSE-Educaiton buildservice repository.


Education Packaging Policy (draft)

I like to enhance the general Packaging Guidelines and Conventions a bit for packages in the Education repositories:

  • add the line
    Vendor: openSUSE-Education
    to your specfile. So zypper knows that this package comes from the same vendor as all other packages and allows updating this package. This includes some kind of "quality" for our packages. Later we will add this string to /var/lib/zypp/db/trustedVendors (for details see Bug 186636) so our packages are unlocked and can be updated later.
  • Use a separate Changelog file. You have to enter a
    tag in your specfile to be consistent with the general RPM guidelines. But for some later enhancements (packaging also debian packages), it is necessary to have the changes of a package in a separate file. The buildservice already handles this files automatically, if the %changelog entry in the specfile is empty and a file named echo $(basename *.spec .spec).changes is present. (So for example: you have a specfile called mypackage.spec and a changelog file called mypackage.changes). The format of this mypackage.changes is
Tue Apr 22 20:54:26 CEST 2008 -


  • Add a valid changelog entry each time you do something with the package! Even if it's just fixing a typo: please add it to the changelog, so users outsite can see that the new release number of your package is the result of a real change and not of a simple rebuild.
  • If you update to a new version, please don't enter just the new version number in your package changelog. Give the user a short summary of the changes (just think: "Why should a user upgrade to the newer version of the package?"). You can use the original changelog as reference, but remember: telling Linux users about changes in the windows part of the package is _not_ usefull...
  • Use "real packages" in the Education Repositories. Means: normally you like to "develop" a package by changing it's specfile, adding scripts, updating the tarball and so on. As the Education repositories should always in an installable state, this development would perhaps break the installation for endusers. So you have two options here:
    • develop your package in your home project and afterwards copy the source back to the Education resporitory
    • use the "publish enabled/disabled" switch for your package in the Education Repository. But be warned: "publish disabled" means that an already build package in the outside repositories will stay there until it's replaced when you enabled publishing again for your package.
  • Needed packages from other repositories? Thats a real problem, hugh! Two options here:
    • using aggregates will automatical copy the build packages of the original project without any rebuild. BUT: until all packages in the original project have build, the Education repository will be blocked! So this is currently no option for us. Cross.png
    • using links will create a link an the package is normally (if you didn't patch it) rebuilded in the education repository each time the original package changed. This is unfriendly to the build hosts - as they have to build the same package again and again. But it would only block the packages depending on this package and not the whole project. 22px-Tick.png
  • Add the Authors to the description in your specfile. As RPM currently has no extra field for this, we like to inform our users about the real Authors of a software by adding them to the description field. Use the following form at the end of your %description tag (please note the four whitespaces bevore the Name):

    Name <email>


Have a look at the wishlist and try to build a package in the buildservice. Please: don't create just a new package without any content than the source and the pseudo specfile. We expect that a user who creates a new package will work on it until he is finished...


The current software repositories can be added following the instructions here

Have a look at

These packages are already finished an need testing. To track already tested packages, please enter a new bug containing the keyword TESTING:<packagename> in the bug "Summary" and mark it as "Trivial". So everybody knows that this package is already tested and we avoid conflicts. If everything works as expected, just close the bug.


We need descriptions especially for the complex applications like the ones listed in the Server section. A "normal" user should be able to set up the application on his server following the descriptions on the wiki pages. If you create such a page (and be shure you're very welcome if you do!) please follow the layout proposals on the Education wiki page.

YaST Modules

For a really good integration and administration, we need additional YaST-Modules for our work. We've started with two "simple" modules, which might be extended in the future:

  • YaST/Modules/Education - The "Education"-module is a module desinged for family-computers to give ones children controlled access to the computer.
  • YaST/Modules/SquidGuard - This module should provide an easy way to edit personal black- and whitelists.
  • YaST/Modules/LTSP - A module for configuring LTSP with YaST

Time will show if we need more modules.