May 24, 2012

Full TeX Live modularized for openSUSE 12.2 - 6000+ packages coming

Werner Fink - the SUSE TeX guru, master of bash and scripting - really surprised me today. He just increased the number of binary RPMs in a significant way with adding 6000 packages from the full TeX Live distribution. So, if we can convince him to add 3000 more packages, we would have 30000 rpm packages.

So, what has he done? He has downloaded the TeX Live package database, applies his self-written perl parser to it to generate 2200 spec files out of it (including recording the dependencies that the package database contains) and additionally generates some collection packages and schemes - and also builds the binary packages. The split in these packages, collections and schemes is part of TeX Live, Werner put them with his generator in rpms.
Collection packages just require other packages and are topic related, e.g. there's a collection package called texlive-collection-latex, if you install it, it installs everything you need for typesetting LaTeX files.
Schemes are the basis for everything, there's for example a small (texlive-scheme-small) and a full scheme (texlive-scheme-full).
So, you could install the small scheme and enhance it with the LaTeX and music collections.

For building the 2200 packages (they contain fonts, documentation, TeX code), Werner wrote a meta package that runs rpmbuild in a loop for those packages. So, the build service sees only one package (which results in 6000 rpm packages) and not 2200.

So, TeX on openSUSE 12.2 will have 83 collections and 9 schemes, a few source packages, 6000 rpm packages - for a total of 1.4 GB plus 52 MB for the binaries of TeX. Fortunately the 6000 rpm packages are of architecture "noarch", so we only have them once in the openSUSE repository.
Previous openSUSE releases only contained the normal TeX Live distribution with a small number of very large packages, now openSUSE contains everything in a modular way.

All of this is available in the openSUSE Build Service as part of the TeX Live project and soon in openSUSE 12.2.

May 22, 2012

Security or Convenience? Defining a better policy

The openSUSE security concepts have been changed gradually over the years with new tools like PolicyKit, PolKit and its usage in system tools.

It's time now to step back, and review what we have and want.

Marcus and Ludwig from the SUSE security team and myself have discussed over the last weeks a bit and like to open this to a broader round now to get your help defining what needs to be done.

Challenges we face

Administrating a system in a secure way is always balancing the needs and requests of security, convenience and usability.  There's also the additional challenge that upstream projects often have a different view on either of these and therefore make different decisions and influencing upstream projects is quite often a difficult task.


Linus Torvalds in his Google+ rant said:

"I first spent weeks arguing on a bugzilla that the security policy of
requiring the root password for changing the timezone and adding a new
wireless network was moronic and wrong.

I think the wireless network thing finally did get fixed, but the
timezone never did - it still asks for the admin password.

And today Daniela calls me from school, because she can't add the
school printer without the admin password.

So here's a plea: if you have anything to do with security in a
distro, and think that my kids (replace "my kids" with "sales people
on the road" if you think your main customers are businesses) need to
have the root password to access some wireless network, or to be able
to print out a paper, or to change the date-and-time settings, ..."

How to continue?

We've collected a couple of use cases for the administration of a
local system at:

For each use case we added a short security evaluation but in most cases don't give a recommendation on what to do.

I now have a call for action: Review and discuss the contents of the wiki page
 using the following questions:

  • Are there any use cases missing?
  • Is there any thing missing in the specific use cases?
  • How can we solve these use cases so that a system is easy to setup for the most common usage scenarios?

Let's do the discussion on the opensuse-factory mailing list, I'll update the document with any improvements. Feel free to enhance it as well.

May 7, 2012

openSUSE - the upstream of SUSE Linux Enterprise

openSUSE contains many independent software projects that have an "upstream" - for example the GNOME desktop in openSUSE is developed mainly by the upstream GNOME community, and the openSUSE developers add integration to make a distribution polished and easy to use. Integration consists of packaging, testing, bugfixing and some extra customization and development. Also the openSUSE developers talk with the GNOME developers about their needs and problems.

It's good practice to push everything upstream and then the upstream community might just accept the change, ask for changes, or even reject it.

Similarly, for SUSE Linux Enterprise openSUSE is an upstream development - and the openSUSE community with its release team can decide what to do with changes or requests coming from downstream (SUSE Linux Enterprise).

Also, SUSE as a company, has developers working in upstream projects like GNOME or the Linux kernel as well as in the upstream openSUSE and for sure on SUSE Linux Enterprise.

There are different ways to integrate: Some of that work will be done downstream first and then pushed upstream - and others will be done upstream with the intent to have it downstream later.

openSUSE 12.1 saw for example the integration of snapper - a snapshoting tool for BtrFS where development was driven by SUSE Linux Enterprise needs with the goal to have it in SUSE Linux Enterprise 11 Service Pack 2. It was stable, integrated without problems into openSUSE Factory and thus was added in time for openSUSE 12.1.

Note that SUSE Linux Enterprise as a distribution selects packages from openSUSE, adds some of its own, especially own branding packages, might have some different policies (e.g. how to partition or regarding security) and a different installation work flow. Before a release is done, the distribution need to run on all supported architectures - currently x86, x86-64, System z, Power, Itanium -, gets tested extensively which makes bugfixes necessary and gets certified by ISVs and IHVs and passes certifications like LSB or for IPv6 compliance. This testing leads to fixes that then go back to the upstreams - to the openSUSE distribution and the upstream open source projects.

A recent example: The testing for SLE 11 SP2 on Linux 3.0 resulted in a number of fixes. These went in the upstream kernel and thus became via upstream part of the Linux kernel that openSUSE uses. Many of these patches were also added directly to the openSUSE kernel.

So, SUSE Linux Enterprise is working in many ways similar with upstream as the openSUSE GNOME team with the upstream GNOME project: both take packages from upstream, add own branding, have refined polices from upstream, send patches etc.

What hasn't been done loudly in the past is raising voice - the SUSE Linux Enterprise developers  and product managers raising their voice on what they need for their product and therefore would like to have from openSUSE and discuss how this can be done best. I expect to see more of this engagement of the openSUSE community by the SUSE Linux Enterprise stakeholder.