[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Reproduzierbare Erstellung



#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.

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.ä.

> 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.

> 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?!

> > - 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.

> Halte ich für schlichtweg unmöglich.

Hm.

> 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.

> notwendigen Links automatisch erzeigen sowie linuxrc umschreiben,
> damit auf der Ramdisk die richtigen Verzeichnisse erzeugt werden unter
> berücksichtigung der verfügbaren Inodes und freien Platzes.

Ja. Ich sehe kein Problem damit, ausser dass es wirklich etwas arbeitet
kostet. Anderseits behält so besser den Überblick, IMHO.

> > 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.

> 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.

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.

> Debian-Paket und lassen sich sehr schwer distributionsunabhängig erzeugen.

Distributionsunabhängig geht eh immer schwer.

> 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.

> > 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.

> 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.

> 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.

> 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.

> 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.

> 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?

MfG,
Eduard.
-- 
==========================================================
Eduard Bloch <blade@debian.org> | GnuPG: 0xEDF008C5(GnuPG)
#exclude <windows.h>

Attachment: pgpMj54gsP46S.pgp
Description: PGP signature


Reply to: