Re: Reproduzierbare Erstellung
On Sun, May 13, 2001 at 09:06:32PM +0200, Eduard Bloch wrote:
> #include <hallo.h>
> Klaus Knopper wrote on Sun May 13, 2001 um 08:28:47PM:
>
> > > - Definieren eines Targets task-knoppix, das alle Pakete enthält, die
> > > auf der Knoppix benötigt werden
> >
> > Das kann man sicher noch machen. Wobei die jeweiligen Pakete für die
> > jeweilige Distribution und den jeweiligen Kernel (sofern der
>
> Das ist mehr oder weniger einfach:
> Das "task-knoppix" Paket enthält Abhängigkeiten von allen benötigten
> Paketen. Will man später eine CD "reproduzieren", setzt man eine
> chroot-Umgebung auf, setzt die gewünschten Distributions-Pfade in
> "sources.list" und lässt "apt-get task-knoppix" laufen. Dann werden
> automatisch alle Pakete mit den benötigten Dep's heruntergeladen.
Habe ich noch nicht ganz verstanden, was dies mit chroot zu tun hat.
Hört sich aber gut an. ;-)
> Für den Kernel und -abhängigen Pakete gibt es das "kernel-package".
> Kernel-Source kommt nach /usr/src/linux, alle zusätzlichen
> Source-Pakete, z.B. alsa-source, werden bei Debian in /usr/src/modules
> entpackt. Nun kann der Skript "make-kpkg" aus kernel-package aus diesem
> Verzeichnissbaum in einem Rutsch verschiedene Pakete bauen. Was
> rauskommt sind Standard-konforme DEBs, d.h. z.B. kompilierte
> ALSA-Module, die mit den gleichzeitig erzeugten Kernel-Image eingesetzt
> werden können. Auch das Kernel-Paket ist ein "richtiges"
> Debian-Kernel-Paket mit eingebauter LILO-Boot-Loader-Installationroutine
> u.ä.
Hmm.. Was ist mit so Sachen wie reiserfsutils, pcmcia(-utils)? Das sind nicht
direkt Module, die brauchen aber schon die Includes des gleichen Kernels.
Gibts irgendwo eine Anleitung, wo drinsteht, wie dieses debian-Paketsystem
funktioniert? Der "New Maintainers Guide" ist ziemlich unbrauchbar, finde ich.
> > nicht sowieso neu gebaut wird) neu compiliert werden müssen.
> > Kann task-knoppix das automatisch tun?
>
> Ich würde sagen, jain. Ich würde ein "task-knoppix" Paket machen, dass
> wirklich nur den Inhalt des Knoppix-System abbildet, und ein
> "task-knoppix-dev", dass Abhängigkeiten zu den genannten Source-Paketen
> und ähnlichen, evtl. benötigten Dingen führt.
Aber solche Sachen wie cloop.o müssen zum aktuellen Kernel passend compiliert
werden. Einfach Binaries abkippen ist da nicht.
Und die Bootdiskette ist wieder ein Thema für sich, da müssen ja auch die
passenden Module zum Kernel bzw. der Kernel selbst und eine ash mit eingebautem
insmod (Redhat-SRC-RPM habe ich) drauf.
> > Schwierig. Diese Skripte sind ja hochgradig Distributionsspezifisch.
> > Dass z.B. bei Debian der Standard-Mountpoint für das CD-Rom nicht wie
> > bei allen anderen Distributionen /mnt/cdrom heißt, sondern /cdrom,
> > wird schon mal viel Arbeit verursachen. Lässt sich IMHO nicht
> > automatisieren.
>
> Sag jetzt nicht, dass du überall die Pfade fest eingetragen und
> keine Möglichkeit zur automatischen Veränderung durch eine zentralle
> Einstellung vorgesehen hast?!
Im Bootscript linuxrc passiert viel mit Variablen, und einige Sachen werden
in /etc/sysconfig/subsystem registriert (argh, das gibt's unter Debian ja auch
nicht!!!) und später von den Initscripten und bei der Autokonfiguration
übernommen. Vor allem wichtig wegen eventueller Parameter, die beim Booten
übergeben wurden wie lang=en oder desktop=GNOME oder ähnliches.
Ich bin halt immer von einem "normalen" System ausgegangen, und da sollte
unter /usr kaum schreibbares Zeug liegen, dafür einiges in /var (was auf der
Ramdisk ist) und /etc (was auch auf der Ramdisk ist), und es müssen ein Haufen
Softlinks geseztz werden. Das IST eben distributionsspezifisch.
> > > - Schreiben eines Programmes knoppify (muss auch in knoppix.deb rein),
> > > das die Initscripte verbiegt, dass die Knoppix-Versionen benutzt
> > > werden und Boot-Floppy und CD erzeugt
>
> Yep. Aber halt in das knoppix-dev.deb.
Ich hatte die KNOPPIX-Initscripte bisher einfach in einem anderen Verzeichnis
in /etc als die normalen. Leider sind ja bei Debian auch wieder die
Runlevelverzeichnisse anders als woanders...
> > Halte ich für schlichtweg unmöglich.
>
> Hm.
Naja, Ideen und Leute, die sie auch umsetzen, sind natürlich immer gesucht.
Ich bin halt bisher immer mit ziemlich witzlosen URLS und Dokumentationen
zugepflastert worden statt mit konkreten Lösungsvorschlägen, wenn ich eine
(scheinbar einfache) Frage hatte. Im Moment sehe ich noch kein Land, aber das
liegt einfach daran, dass ich bisher nur auf RedHat-basierten Systemen
(RH, Mandrake, SuXe, DLD) gearbeitet habe. Wie Debian funktioniert ist mir noch
nicht ganz klar, und es hat mich etwas beruhigt, dass es auf #debian.de auch
offenbar niemand weiß. ;-)
Also ich relativiere mal das "unmöglich" in "ich weiss nicht, wie es geht, bin
aber lernfähig, glaube aber nicht, dass wir den Automatismus bis zu dem Termin,
an dem die CD ins Presswerk muss, fertig bekommen".
> > Das Skript müsste automatisch herausfinden, welche Programme welche
> > Konfigurationsdateien an welcher Stelle schreibbar brauchen, und die
>
> Ja. Dafür würde ich eine kleine Datenbank anlegen.
Die wird nicht klein sondern ziemlich gross und muss von allen Betatestern
zugreifbar sein. Mailingliste besser?
> > > Vorgehensweise zum Erzeugen der Knoppix:
> > >
> > > 1. Installation einer Minimal-Debian (base)
> >
> > Alleine das dauert jetzt schon 3 Tage, und war nicht ohne Handarbeit möglich.
> > Einige der notwendigen (libkudzu für hwsetup) oder zumindest nützlichen
>
> Für libkudzu hab ich ein ITP gesehen, ich würde die Person fragen, ob er
> evtl. schon Snapshots davon zur Verfügung stellt.
Wenn mir das Source-Paketsystem von Debian etwas klarer wäre, könnte ich sicher
auch selber das Paket paketieren. Evtl. lohnt es sich auch, hwsetup für die
libdetect umzuschreiben, die ja anscheinend von Debian bevorzugt wird.
Allerdings weiss ich nicht, wie stabil die ist. Kann die auch Monitorfrequenzen
proben? (das schafft nämlich dir libkudzu noch nicht), und wie sieht es mit
Grafikkartenerkennung aus?
> > Pakete (xmms mit SMPEG-Support, nessus, gcdmaster,...) gibt's nicht als
>
> gcdmaster gibt es in Unstable. Geht im Moment nur nicht, wegen
> veralteter Abhängigkeiten. Muss lediglich neukompiliert werden. Trivial.
gcdmaster gehört zu dem wirklich guten cdrdao, das habe ich als SRC-RPM für
RedHat und hätte es natürlich auch gerne für Debian. Es braucht gtk-- (bzw.
gtkmm in der neuen Schreibweise).
> Amsonsten:
> satan - Security Auditing Tool for Analysing Networks
> libnasl-dev - Nessus Attack Scripting Language, static library and headers
> libnasl1 - Nessus Attack Scripting Language, shared library
> libnessus-dev - Nessus static libraries and headers
> libnessus1 - Nessus shared libraries
> nessus - Remote network security auditor, the client
> nessus-dev - Nessus development header files
> nessus-plugins - Nessus plugins
> nessusd - Remote network security auditor, the server
> smpeg-plaympeg - SMPEG command line MPEG audio/video player
> smpeg-xmms - SDL MPEG Player Library - XMMS plugin
>
> Geht nicht, gibt's nicht.
WO finde ich diese Sachen denn?! apt-cache search findet die alle nicht.
Kann man die in einer Form bekommen, so dass man sie auf der "stable"
Debian 2.2 compilen kann, ohne dass man alle möglichen Developer-Pre-Alpha-Libs
installieren muss?
> > Debian-Paket und lassen sich sehr schwer distributionsunabhängig erzeugen.
>
> Distributionsunabhängig geht eh immer schwer.
Du sagst es. :-(
> > Bei Redhat/Mandrake hat die Installation des Basissystems mit allen Utilities
> > inclusive der Menüanpassung gerade mal einen nachmittag gedauert, nur so zum
> > Vergleich.
>
> Moment, vergleichst du da etwa Potato mit einer aktuellen RedHat? Nimm
> lieber Testing (Woody), das entspricht eher dem Umfang, aber auch der
> Stabilität.
Falls instabile Pakete dabei sind, können wir die mit einer hinreichend langen
Betatestphase alle eliminieren bzw. neu bauen. Aber das Grundsystem sollte
stabil sein (Kernel, Libs, X-Server, Sysutils), und die netten Gimmicks und
Spezialpakete (die halt auf der Redhat-Knoppix drauf waren) sollten dann auf
dieser Basis neu gebaut und integriert werden.
> > > 2. apt-get install task-knoppix
> >
> > Bis wir soweit sind, diesen Teil zu automatisieren, schätze ich, ein halbes
> > Jahr.
>
> Oh Mann, hätte ich Zeit, würde ich euch gerne helfen. Ich tippe eher auf
> wenige Wochen, aber das Studium ist im Moment ziemlich ätzend.
Kleiner Tipp: Das bleibt auch bis zum Studienende so. ;-)
Und Du hast recht: wir haben eigentlich auch nur wenige Wochen, bis es
schon mal irgendwie laufen muss, sonst schaffen wir es bis zum LinuxTag nicht
mehr. Auf jeden Fall brauchen wir so viel Hilfe wie möglich. Wenn Du z.B.
aus Redhat SRC.RPMS Debian-Pakete bauen könntest (zumindest mal so weit, dass
ich mir ansehen und verstehen kann, wie das geht), wären wir schon eine großen
Schritt weiter.
> > Ich glaube nicht dran, dass das überhaupt ohne menschliche Intelligenz geht.
> > Sorry. Bin kein Informatiker und kann leider "nur" aus Erfahrung sprechen.
>
> Meinst du? Nur so als Beispiel: Debian's "base"-System wird auch so
> automatisch gebaut, und es schein zu funktionieren, mehr oder weniger.
Ist das irgendwo dokumentiert?
> > Sicher wäre es theoretisch möglich, ein entsprechendes KI-Programm zu
> > entwickeln, dass sämtluche KDE/GNOME/Console/...-Software testet und
> > nachschaut, warum sie crasht wenn bestimmte Filesysteme read-only sind,
>
> Was soll denn, bitte schön, writeable sein? $HOME sowieso, /etc, /dev,
> /tmp und /var/tmp, noch einiges unter /var, das war es schon.
Also, es gibt ab dem Moment, wo init startet, 2 bis 4 Partitionen:
/KNOPPIX 1.5 Gig, über cloop gemountet von CD, read-only
da liegt ALLES drauf, was nicht unbedingt schreibbar sein muss.
Softlinks in / zeigen auf /KNOPPIX/usr, /KNOPPIX/bin usw.
/ Ramdisk, 4 MB (rw), da liegt auch /etc drauf
/home Ramdisk, variable Größe, kann auch auf / sein, falls nicht genug
Hauptspeicher vorhanden.
/var Ramdisk, variable Größe, siehe /home. Alles, was NICHT schreibbar sein
muss, wird per Softlink von /KNOPPIX verlinkt.
Ob diese Einteilung sinnvoll ist, mag diskutiert werden. Sie läuft
zufriedenstellend ab 8 MB Hauptspeicher (natürlich dann ohne X).
Unter /cdrom ist die Knoppix-CD als normales iso-Filesystem gemountet,
und bleibt es auch bis init 0, wonach sie automatisch ausgewofen wird.
Ihr Inhalt ist aber bis auf das komprimierte KNOPPIX-Loopback-File
für das System unwichtig.
> > 2.) ist bei der nächsten Debian sowieso wieder alles anders, und der
> > Automatismus, der vielleicht mit hohem Aufwand noch bei 2.2 geklappt hat,
> > versagt im nächsten Release schon wieder.
>
> Glaube ich nicht, weil sich alle Maintainer an die FHS zu halten haben,
> und das kann sehr wohl automatisch verarbeitet werden.
Ist /cdrom unf /floppy wirklich Filesystemstandard?! Was ist denn bei mehreren
CD-Roms, heissen die dann auch /cdrom1, /cdrom2 ... oder werden die, wie ich es
von Redhat-Systemen her kenne, als Unterverzeichnisse von /mnt gemountet?
> > Soweit möglich, lassen wir "script" mitlaufen, um die arbeitsaufwendigsten
> > Schritte zu dokumentieren (Anpassen der Init-Skripte, Schreiben von Wrappern
> > für alle möglichen Programme, Umstrukturieren von /usr/share/applnk und tausend
> > andere Sachen) oder es werden Changelogs geführt mit abstrakten Beschreibungen,
> > was zu tun ist.
>
> Was zu
> - umständlichen Logs führt, wo dann doch jemand einen wichtigen Eintrag
> vergisst, und
> - irrsinigen, immer zu wiederholenden Aufwand.
Hier fehlt mir noch der entscheidende Hinweis, wie wir das einfacher
hinbekommen ohne Handarbeit.
> > Die Dinge, die sich automatisieren lassen (VIELLEICHT
> > Kernel+Spezialmodule+Utilities) werden in .deb-Paketen abgelegt. Hier fehlt mir
> > noch immer der Durchblick, wie man "Sub-Packages" unter Debian baut.
>
> Ich komme mal vorbei. Hast du Zeit am Montag, ab 15:30, oder Dienstag,
> ab 14 Uhr?
Dienstag habe ich von 16-18:000 Uhr Kurs am RHRK, und 14:00 Uhr ist ein
bisschen früh für mich. Ich versuche mal, am Montag um 15:30 Uhr im
Linuxtag-e.V. Raum zu sein.
Gruß
-Klaus
---
Klaus Knopper LinuxTag 2001 - Europes largest Linux Expo
Technical Solutions Where .com meets .org
knopper@linuxtag.de http://www.linuxtag.de/
gPhone +49-(0)180-5-546898 Fax +49-(0)180-5-546893
Reply to: