#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