Adding Software to your SuSE Linux

Roman Drahtmueller

Hi,

Finally I decided to start learning iptables hence installed the 2.4.7 kernel along with the iptables. The version comes on 7.2 is 1.2.1a (yes the kernel is also 2.4.4) should not be there an offical update to iptables out of curiosity ?

This is the reply from Roman Drahtmueller to the question given above. This reply is reprinted here with permission.

(This mail has become somewhat lengthy, but I wanted to write down some thoughts on closely related topics that arise when I give the answer for this question. Everything that has nothing to do with the actual question above on this thread is written below the line "########", and it does not contribute to the half-technical question. I do not wish that there will be a discussion about the issues below on this list because it would generate an off-topic lengthy thread. It's just that some of the things below need to be said every once in a while in order to prevent misunderstandings from distorting the aspects and benefits of open source software.)

The answer:

Not quite: The iptables utility is only the setup tool, it can't easily be a security problem without messing up the rules during setup (You'd easily notice! :-). The actual work of the packet filter engine happens in the kernel, not in the ipchains utility. If your machine acts as a packet filter only, you can easily kill all running processes and run rm -rf / over it - it will continue to work until you try to reboot it.

By consequence, the newer version fixes bugs that may be nasty in some way, but there are none that were security-related. The version of iptables that is on the CDs is installed on a few dozen thousand installations, and in use one some thousands, I guess. A new version is always different from the one before (this is why there is a new version in the first place): different functionality and different bugs as well. We cannot guarantee that the newer version works exatly like the one before, which is why we don't provide a newer version of the package (with iptables being just a simple example).

Please look at the changelogs of single packages in the distribution, especially the core packages and libraries, and look at the patches that we include to fix bugs that we found during testing. In order to be taken seriously in the operating systems market, you have to be able to maintain a certain level of quality in your software. You make a tradeoff between the up-to-dateness (and security) and the reliability (and security) of your software. This implies that the functionality of a single package must be guaranteed over the updates. By consequence, the version stays the same: only those bugs are fixed that break the functionality of the package or impose a security risk. If your favourite email program crashes if you hit five keys together, then do not hit these five keys together. If it crashes when a strange email arrives, it may be security related: Write to security@suse.de, and use the pgp key to encrypt your text. New versions in update packages can only happen if the new version number is beneficial from the security standpoint, and if no other package relies/depends on the package to be updated.

(Example: openssh. A user should be able to tell by the version number that the recently discovered security bugs are fixed.)

      ##################
    

There is a specific set of reasons why we make a new distribution every once in a while (with a decreasing frequency): The opensource community needs to have a new base to build on (a distribution sets standards that are most important for the thing as a whole), and new features are desired on behalf of the usership. Free software is for free: You can download it from servers worldwide. But I wouldn't want someone else to do the job that we've accomplished with each distribution (7.3 is out in a few days): many thousands of hours of CPU-time have been used for compilation of code and for stresstests, many hundreds of CDs have been burned, network equipment and computer hardware has been bought just to test the software, and many millions of keys have been hit, not to mention the thousands of hours in long nights that developers at SuSE and the rest of the world have sat down to track down crashes, add improvements to performance, stability and security, provide a nicer, ergonomic interface and make it what it is: A secure, powerful, flexible and stable operating system, ready to use. It is what people expect from it (while everybody expects something different).

If you want to give yourself a nice lesson: Play distributor! Install a SuSE-6.1, just a minimal package selection, then put away the CDs. Then, get KDE-2.2.1 running on it, with a few dozen applications that do all kinds of things from showing the time down to burning CDs and sending mails. Compile from the source tarball, not SuSE source rpms. Modularize the software that you have installed and keep an overview over it. Add icons, G/X, eye candy, sounds so that you like it more. Check it for bugs, identify crashes and find security problems. Deal with buggy hardware and BIOSes. Ensure consistency of the ready-to-install packages that you built. Make it possible to exchange parts of the system at full consistency. Communicate the bugs that you've found to the maintainers and authors of the software that you use (quite some people, many emails!).

After you have found out that you need to exchange basically everything in your minimal system in order to be able to even compile the new stuff (not to mention running or testing!), you can abbreviate to a minimal SuSE-7.2 installation and restart from the beginning. After a few weeks without much fun you will find out that kdm behaves strangely under some obscure, but usual circumstances; watch out for race conditions and buffer overflows while you nail down the reason why all of your processes get nuked by SIGTERM sometimes.

If you're there, invest some time to sit down with others and argue the technical reasons why you (lazily) added your docs to /opt/kde/docs instead of /usr/share/doc. Be sure to have a comprehensive result afterwards, so that your distribution follows the defined standards (SuSE is leading in terms of that). Then you change what doesn't match the standards, and recompile everything. Don't forget to write down how to use it for your grandma and your kids.

SuSE employs the best people that the world has for many of the subsystems that a SuSE Linux distribution is built on. They are paid for doing their job and for refining the software they wrote to a thing that you can use. The software is still for free, the patches are for free (the distributors even share their additions), but the fact that you can easily install and use it is not!

Provided you earn only Euro 2.50 an hour, you couldn't make it in time to be faster than 100 times the price of a Linux distribution (a SuSE in particular). If you buy all the software that is on the (filled up to the last byte) SuSE CDs from a commercial vendor, expect a bill of a few hundred thousand Euro. I've never ever paid a single buck for software, but if I didn't (proudly) work for SuSE, I'd pay significantly more. I would want new versions of single software packages every few months, but as you might know we're not forced to buy it either. It's just easier and less expensive.

The price of a Linux distribution does not compare to the price of commercial software, but to the price your own time and your freedom.

Thanks,

Roman.

- --
 - -
| Roman Drahtmueller >draht@suse.de< // "You don't need eyes to see, |
  SuSE GmbH - Security Phone: // you need vision!"
| Nurnberg, Germany +49-911-740530 // Maxi Jazz, Faithless |
 - -
Feel free to pass on this text, provided that it is complete and unchanged!
    

Here are some places you can look:

• http://www.usr-local-bin.org

• http://packman.links2linux.de/index.php4 all SuSE packages. Site in German

• http://guru.unixtech.be/rpm/

Richard Bos

Apt is a package installer, to install rpm packages [1]. Apt does not replace rpm, the contrary it enhances rpm by providing very good dependency checking. Apt works according the client/server model, were the server provides an apt repository containing the standard rpm packages. Besides the rpm packages the repository provides meta information about the rpm packages. The client uses this information to determine if new packages have arrived and which other dependend packages are needed.

A nice example to show the above is the installation of kdevelop:

dar:~ # apt-get -S install kdevelop3
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
  arts-devel doxygen flex freetype2-devel html-dtd kdebase3-devel
  kdelibs3-devel kdelibs3-devel-doc kdesdk3 kdoc libmng-devel
  libogg-devel libvorbis-devel mesaglut-devel qt3-devel
  qt3-devel-doc qt3-devel-tools xdevel
The following NEW packages will be installed:
  arts-devel doxygen flex freetype2-devel html-dtd kdebase3-devel
  kdelibs3-devel kdelibs3-devel-doc kdesdk3 kdevelop3 kdoc
  libmng-devel libogg-devel libvorbis-devel mesaglut-devel qt3-devel
  qt3-devel-doc qt3-devel-tools xdevel
0 packages upgraded, 19 newly installed, 0 to remove(replace) and 10 not 
upgraded.
    

As shown apt sorts out all dependend packages and will download and install these. The package version does not need to be provided, which is very convenient, too!

The apt client administrates in the file called sources.list the different apt repositories that the client can connect. With the information from all those apt repositories apt determines, were the most recent version rpm package is located of the rpm package to be installed. If dependend rpms need to be installed all apt repositories will be checked to look for the correct version. The the latter is not important the most recent version will be downloaded and installed. By the way, the apt repository can be located on the user's own harddisk too of course.

Apt can be told to hold an rpm package in case the user does not want a package to be automatically upgraded. The kernel package k_dflt is a good example of a package that should not be automatically downloaded.

Hopefully you can conclude that the apt is really an Advanced Package Tool, as that is what APT stands for.

For SuSE there is 1 repository available, the repository is located at ftp://ftp.gwdg.de. More information about the apt repository and apt can be found at http://apt4rpm.sourceforge.net. For information about the SuSE-7.3 apt repository follow the link called apt-rpm reps.

If you try it, there is a great chance that you don't want to use anything else anymore!