[linux-l] Debian - Eigene Installations-CD erstellen

Lutz Willek willek at gmx.de
Do Nov 2 01:01:23 CET 2006


Peter Ross wrote:
> Lutz Willek schrieb:
>> Über ein Skript läuft da nix.
>> Die Idee ist gut, aber warscheinlich so nicht machbar, das haben andere
>> schon versucht und in den Sand gesetzt. Da Du das ganze verkaufen willst
>> musst Du natürlich auch die Folgen tragen, falls ein Paket als Update mal
>> den Server lahm legt. Die Konsequenz ist also ein eigenes Repository für die
>> Kunden.
> 
> Warum?
Weil es über längere Zeit gesehen nicht sauber durchführbar ist. Du
musst immer wieder anpassen. Aber der Reihe nach:
> 
> Die Installation selbst ist auitomatisierbar und anpassbar (habe das nicht 
> mit Debian, aber mit Red Hats kickstart schon gemacht),
Das geht auch mit Debian super, siehe nico's link.
> 
> und hinterher laeuft bei mir ein postinstall-Skript, um notwendige 
> Anpassungen zu machen und Software zu installieren, die heimgebraut ist.
auch das geht. Es setzt aber eine genau definierte Ursprungsumgebung
vorraus, die aber so nicht gegeben ist.
> 
> Letzteres ist derzeit ein Skript und Tarball, aber es koennten auch RPMs 
> (oder bei Debian DEB-Pakete) sein, die auf der CD sind.
mit angepasssten Paketen geht das, klar.
> 
> Hinterher liessen sich die apt-Sourcen (zusaetzlich) auf einen 
> Firmenserver setzen, um Updates einzuspielen.
genau das habe ich doch vorgeschlagen. Nur das der Firmenserver eben
nicht nur die Updates bereit stellt, sondern auch die restlichen,
getesteten Pakete.
> 
> Die selbstgebauten DEBs koennten Versionen (kleiner groesser) anderer 
> Debian-DEBs als Abhaengigkeit definieren, so dass apt meckert, wenn jemand 
> etwas Neueres installiert, wofuer Du keinen Test gemacht hast, und also 
> keinen Support anbietest.
Du willst also in Deinen Paketen Abhängigkeiten für alle anderen Pakete
definieren? Viel Spaß dabei.
> 
> Wenn Du neuere Versionen getestet hast, stell neue DEBs Deiner Software 
> rein, die als Abhaengigkeit auch neuere Debian-DEBs zulassen.
> 
> Wo ist da der Haken?
Das geht schon alles, irgendwie. Ich male mir da gerade was aus.
Zugegeben, dieser Fall ist sehr konstruiert, aber es _kann_ so laufen.

Der Kunde will ein neues Programm, für das Du keinen Support bietest.
Das Programm hat mit Deiner Installation erstmal nichts zu tun.
Beispielsweise lieferst Du einen angepassten LAMP, mit Administration
über Webbrowser und über eine graph. Konsole in Gnome. Der Kunde möchte
aber lieber KDE haben. Bei der Installation von KDE (vom normalen
Debianserver) wird ein Paket installiert, das Deine Bilder fürs Web
automatisch zurecht schneidet. Du benutzt in Deinem Lamp aber ein
anderes Programm, weil es für Deine Zwecke besser ist. Das neue Programm
kommt mit der Befehlsübergabe von deinen skripten nicht zurecht, Bilder
werden falsch dargestellt.

Szenario 1:)
Genau diesen einen Fall möchtest Du verhindern, weil er Dir bekannt ist.
Du setzt also in einem deiner Debianpakete eine Abhängigkeit, die das
installieren dieses Paketes verhindert. Der Kunde ist sauer, nicht mal
KDE kann er installieren, obwohl es in den Paketquellen existiert.

Szenario 2:)
Du weißt nichts von diesem Problem, setzt also keine Abhängigkeit. Der
Kunde installiert KDE, Dein LAMP tut nicht mehr. Der Kunde ist sauer. Er
hat doch nur KDE installiert, weil er es konnte.

Szenario 3:) Du verwendest ein eigenes Repository, in dem nur angepasste
oder getestete Programme enthalten sind. Der Kunde sucht KDE, findet es
aber nicht. Jetzt muss der Kunde aktiv werden. Er muss die Paketlisten
anpassen, wofür Du keinen Support leistest. Das Ergebnis wird das
gleiche sein, Dein LAMP tut nicht mehr. ABER: Der Kunde musste sich
bewusst entscheiden, etwas zu tun, wofür Du keinen Support leistest.
Damit kann er sich nur noch über sich selbst ärgern.
> 
> Das letzte, was ich als Kunde will, ist, auf grandmas-lib.1.0 fuer alle 
> Zeiten festgenagelt zu sein (vielleicht auch mit zig Sicherheitsluecken), 
> nur weil der Hersteller der Add-Ons es so befiehlt.
Doch, genau *das* willst Du haben, wenn Du ein Paket kaufst, das aus
vielen einzelnen Programmen besteht, die zusammen arbeiten. Du willst
definierte Strukturen haben. Du willst Dich nicht selbst mit irgend
welchen lib's rumschlagen. Und wenn Du das wirklich willst solltest Du
Dir überlegen, ob Du das richtige Produkt gekauft hast.

*Aber:*
Wenn der Hersteller einer Paketlösung grandmas-lib.1.0 einsetzt spricht
das Bände über die Qualität des Produkts... Die Sicherheit hat erstmal
nichts mit dem Problem hier zu tun. Das aktualisieren der Installation
ist Sache des Herstellers, nicht des Kunden. Der Hersteller hat solche
Updates bereit zu stellen, er wird ja auch dafür bezahlt. Der Kunde darf
  und soll Sie dann einspielen.

> 
> Natuerlich bedeutet das etwas Aufwand fuer den Add-On-Hersteller, aber dr 
> kann sich das ja fortlaufend durch Subskription fuer den Update-Service 
> bezahlen lassen.

Wir sprechen hier nicht über Add-On's, sondern über eine Komplettlösung!
Und da sind die Gegebenheiten etwas komplexer.
Ja, klar. Der Aufwand ist in jedem Fall da. Nur ist er in Szenario 3
wenigstens kalkulierbar.

Ich streite keineswegs ab, das andere Lösungen funktionieren können. Sie
sind aber nicht wirtschaftlich. Du willst als Hersteller ein gutes
Produkt verkaufen. Also musst Du sicher stellen, das Dein Produkt auch
gut bleibt. Es gibt bei Debian geschätzte 18.000 Pakete. Wenn Du alle
testen willst kommst Du mit nur einer Stelle für die Produktpflege nicht
mehr aus. Verstehst Du jetzt, auf was ich hinaus wollte?

> 
> Es gruesst
> Peter





Mehr Informationen über die Mailingliste linux-l