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

U. Bauermann ub at insecma.de
Do Nov 2 11:39:10 CET 2006


Hallo

Jopp, ich denke da sind doch ne Menge Ecken an die man denken muss.
Ich nehme eure Bedenken an. Je nachdem wie es sich entwickelt, kann/muss 
/werde ich das weiterhin andenken.
Mir geht es primär um ein Serversystem, an dem Otto Normal nicht Hand 
anlegen soll/muss.
Da stehen dann Wünsche à la 'Ich will aber da nun KDE drauf 
installieren' erst gar nicht zur Diskussion.

Wenn ich eine Lösung gefunden habe werde ich hier meine Erfahrungen 
gerne weitergeben / austauschen.

Danke
Uwe

Lutz Willek schrieb:
> 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
> 
> 
> _______________________________________________
> linux-l mailing list
> linux-l at mlists.in-berlin.de
> Die Mailingliste der BeLUG (Berliner Linux User Group)
> 
> Wenn du diese Mailingliste  abbestellen willst, gehe bitte auf
> https://mlists.in-berlin.de/mailman/listinfo/linux-l
> und trage dich dort bitte aus
> 




Mehr Informationen über die Mailingliste linux-l