Hallo,
leider muss ich bei meinem aktuellen Linux-Thema verschiedene Distributionen unterstützen.
Das ist mehr Aufwand, als würde man sich exklusiv für eine entscheiden.
Und darum nervt es etwas.
Gibt es da vielleicht schon eine Seite, die die Unterschiede zwischen den Distributionen auflistet?
Ich beziehe mich hier nur auf Serverkram. Also ohne Gnome, GUI und Monitor.
Gruß, Thomas
Hi Thomas;
welche Themen interessieren Dich denn genau? Spontan hätte ich distrowatch vorgeschlagen, aber vermutlich ist das zu high-level...
Viele Grüße, Kristian
Am 04.06.19 um 13:25 schrieb Kristian Rink:
Hi Thomas;
welche Themen interessieren Dich denn genau? Spontan hätte ich distrowatch vorgeschlagen, aber vermutlich ist das zu high-level...
Mir geht es um konkrete Dinge wie:
- Apache-Konfig ist bei RedHat hier, bei Suse da, bei Debian dort. - Neue (eigene) Zertifikate werden per .... eingespielt. - ...
Ah ok.
Am Mittwoch, den 05.06.2019, 10:26 +0200 schrieb Thomas Güttler:
Mir geht es um konkrete Dinge wie:
- Apache-Konfig ist bei RedHat hier, bei Suse da, bei Debian dort.
- Neue (eigene) Zertifikate werden per .... eingespielt.
- ...
Hmmm, ich vermute auch, dergleichen wird es generisch nicht geben. Punktuell findet man zwar immer mal wieder Wikis oder Websites a la "XXX für YYY-Administratoren", aber das geht sehr selten über Paketverwaltung und vielleicht noch Bootprozess hinaus.
Distro-unabhängiges Shipping mit allen Abhängigkeiten in Deiner Anwendung und Installation nach /opt ist keine Alternative, vermute ich mal...? ;)
Viele Grüße, Kristian
Am 05.06.19 um 12:48 schrieb Kristian Rink:
Ah ok.
Am Mittwoch, den 05.06.2019, 10:26 +0200 schrieb Thomas Güttler:
Mir geht es um konkrete Dinge wie:
- Apache-Konfig ist bei RedHat hier, bei Suse da, bei Debian dort.
- Neue (eigene) Zertifikate werden per .... eingespielt.
- ...
Hmmm, ich vermute auch, dergleichen wird es generisch nicht geben. Punktuell findet man zwar immer mal wieder Wikis oder Websites a la "XXX für YYY-Administratoren", aber das geht sehr selten über Paketverwaltung und vielleicht noch Bootprozess hinaus.
Distro-unabhängiges Shipping mit allen Abhängigkeiten in Deiner Anwendung und Installation nach /opt ist keine Alternative, vermute ich mal...? ;)
Danke für den Hinweis.
Systemd will ich zB nicht neu erfinden, bzw dazu eine Alternative aufsetzen.
Anfangs war ich naiv und dachte Configurations-Management-Tools wie zB Ansible helfen in dem sie die Distri-Unterschiede weg abstrahieren.
Aber das klappt nur bedingt. Im Endeffekt muss dann doch wieder Fallunterscheidungen programmieren.
Container haben hier klar einen Vorteil, weil man exklusiv auf eine Distribution setzt.
Gruß, Thomas
Am Donnerstag, den 06.06.2019, 10:25 +0200 schrieb Thomas Güttler:
Anfangs war ich naiv und dachte Configurations-Management-Tools wie zB Ansible helfen in dem sie die Distri-Unterschiede weg abstrahieren.
Aber das klappt nur bedingt. Im Endeffekt muss dann doch wieder Fallunterscheidungen programmieren.
Ja, das ist leider insgesamt relativ nervig. Wir nutzen puppet für diesen Zweck intern, das löst *einige* dieser Probleme, aber vieles bleibt Kleinkram und kommt einem ganz gern in die Quere. Portierung des Packagings auf docker, flatpak, snap oder sowas in der Art ist keine Option...?
Viele Grüße, Kristian
Am 06.06.19 um 14:13 schrieb Kristian Rink: ...
Ja, das ist leider insgesamt relativ nervig. Wir nutzen puppet für diesen Zweck intern, das löst *einige* dieser Probleme, aber vieles bleibt Kleinkram und kommt einem ganz gern in die Quere. Portierung des Packagings auf docker, flatpak, snap oder sowas in der Art ist keine Option...?
Ein Container (zB Docker) würde das einfacher machen, da man explizit auf ein bestimmtes Linux aufbauen kann.
flatpak/snap lösst (so weit ich weiß) nicht das Problem, dass zB die Apache-Konfig und die ssl-Cert-Konfig pro Disti anders ist. Oder sehe ich das falsch?
Gruß, Thomas
Am Freitag, den 07.06.2019, 11:00 +0200 schrieb Thomas Güttler:
flatpak/snap lösst (so weit ich weiß) nicht das Problem, dass zB die Apache-Konfig und die ssl-Cert-Konfig pro Disti anders ist. Oder sehe ich das falsch?
Ich habe mit docker deutlich mehr Erfahrung als mit snap, aber auch schon snaps (u.a. für Nextcloud) gesehen/in der Hand gehabt, in denen Dinge wie apache- und ssl-Config mit drin stecken. flatpak nutze ich bislang nur für Desktop- oder lokale Anwendungen; ob das für Server- Use-Cases brauchbar ist, weiß ich insofern nicht. Wie viele Distributionen musst Du unterstützen? Ist es eine Option, sich auf ein oder zwei zu beschränken und die Open-Source-Community das Packaging für andere Distributionen übernehmen zu lassen? ;)
Viele Grüße, Kristian
Am 07.06.19 um 11:24 schrieb Kristian Rink:
Am Freitag, den 07.06.2019, 11:00 +0200 schrieb Thomas Güttler:
flatpak/snap lösst (so weit ich weiß) nicht das Problem, dass zB die Apache-Konfig und die ssl-Cert-Konfig pro Disti anders ist. Oder sehe ich das falsch?
Ich habe mit docker deutlich mehr Erfahrung als mit snap, aber auch schon snaps (u.a. für Nextcloud) gesehen/in der Hand gehabt, in denen Dinge wie apache- und ssl-Config mit drin stecken. flatpak nutze ich bislang nur für Desktop- oder lokale Anwendungen; ob das für Server- Use-Cases brauchbar ist, weiß ich insofern nicht. Wie viele Distributionen musst Du unterstützen? Ist es eine Option, sich auf ein oder zwei zu beschränken und die Open-Source-Community das Packaging für andere Distributionen übernehmen zu lassen? ;)
Aktuell muss ich nur SuSE-Enterprise, OpenSuse und Ubuntu unterstützen. Aber in verschiedenen Versionen. Das schon allein ist ein lustiger Kasper-Floh-Zirkus. Sicherlich kann man ins snap eine Apache-Konfig integrieren. Aber wie soll das über mehrere Distris hinweg funktionieren? Ich vermute, dass das doch wieder jedes mal pro Anwendungsfall mit Fallunterscheidungen gelöst ist. Das wäre coole "Magic" wenn das Distri-übergreifend geht.
Gruß, Thomas
Thomas Güttler guettliml@thomas-guettler.de (Fr 07 Jun 2019 16:04:53 CEST):
Aktuell muss ich nur SuSE-Enterprise, OpenSuse und Ubuntu unterstützen. Aber in verschiedenen Versionen. Das schon allein ist ein lustiger Kasper-Floh-Zirkus. Sicherlich kann man ins snap eine Apache-Konfig integrieren. Aber wie soll das über mehrere Distris hinweg funktionieren? Ich vermute, dass das doch wieder jedes mal pro Anwendungsfall mit Fallunterscheidungen gelöst ist. Das wäre coole "Magic" wenn das Distri-übergreifend geht.
Docker ist für sowas vielleicht wirklich Deine Antwort. Auch wenn es etwas shiny ist und vermutlich dahinter ordentlich stinkt.
Von rkt habe ich lange nichts mehr gehört, das fand ich damals besser, wenn auch nicht so einfach, weil es zu viel Flexibilität bot. (das übliche: Playmobil vs Lego)
Der Trend scheint klar zu Containern zu gehen, aber auch da sind teilweise mehr Fragen als Antworten. Gerade wenn es um Verantwortlichkeiten geht, Abhängigkeiten zu z.B. Libraries, die Du vielleicht nutzt, aber auch nicht trackst. Wer baut das Image neu? Wer ist für die Distro-Integration des Images beim Start verantwortlich usw.
Applikation linkt LibFoo
Nun gibt es in LibFoo ein sicherheitskritisches Update. Wenn es ein Image ist, dann ist der Image-Erzeuger (vermutlich Du) verantwortlich, das möglichst zeitnah neu zu bauen.
Ist es ein Distro-Paket, wird vermutlich ohne Dein Wissen in der Distro die Library getauscht und alle Nutzer Deiner Applikation sind auf der sicheren Seite.
Dafür hast Du vielleicht mehr Arbeit, weil Du irgendwie mit allen Varianten von libFoo leben musst, erst recht, wenn es eine LibBar gibt, die behauptet, kompatibel zu LibFoo zu sein. Dieses Problem hast Du bei einer Container-Lösung nicht. Da schnürst Du alles zusammen, definierst die Schnittstellen zur Außenwelt (Port, Mountpoint, vielleicht erforderliche Services und fertig.) - na ja, hört sich einfach an, ist aber letzten Endes auch viel Gefrickel.
-- Heiko
Am 07.06.19 um 16:24 schrieb Heiko Schlittermann:
Thomas Güttler guettliml@thomas-guettler.de (Fr 07 Jun 2019 16:04:53 CEST):
Aktuell muss ich nur SuSE-Enterprise, OpenSuse und Ubuntu unterstützen. Aber in verschiedenen Versionen. Das schon allein ist ein lustiger Kasper-Floh-Zirkus. Sicherlich kann man ins snap eine Apache-Konfig integrieren. Aber wie soll das über mehrere Distris hinweg funktionieren? Ich vermute, dass das doch wieder jedes mal pro Anwendungsfall mit Fallunterscheidungen gelöst ist. Das wäre coole "Magic" wenn das Distri-übergreifend geht.
Docker ist für sowas vielleicht wirklich Deine Antwort. Auch wenn es etwas shiny ist und vermutlich dahinter ordentlich stinkt.
Von rkt habe ich lange nichts mehr gehört, das fand ich damals besser, wenn auch nicht so einfach, weil es zu viel Flexibilität bot. (das übliche: Playmobil vs Lego)
Der Trend scheint klar zu Containern zu gehen, aber auch da sind teilweise mehr Fragen als Antworten. Gerade wenn es um Verantwortlichkeiten geht, Abhängigkeiten zu z.B. Libraries, die Du vielleicht nutzt, aber auch nicht trackst. Wer baut das Image neu? Wer ist für die Distro-Integration des Images beim Start verantwortlich usw.
Ich denke der Ablauf sollte etwa so sein:
- vanilla Image wird als Vorlage genommen. - Updates werden eingespielt - Config-Management Tool mach aus dem Image den Container, den man möchte - Continous Integartion prüft den Container - Falls alle Tests ok sind: Deployment.
Wenn es von der Distribution ein neues RPM/DPKG gibt (zB Security-Update), dann wird obiger Ablauf erneut durchgespielt.
Applikation linkt LibFooNun gibt es in LibFoo ein sicherheitskritisches Update. Wenn es ein Image ist, dann ist der Image-Erzeuger (vermutlich Du) verantwortlich, das möglichst zeitnah neu zu bauen.
Ist es ein Distro-Paket, wird vermutlich ohne Dein Wissen in der Distro die Library getauscht und alle Nutzer Deiner Applikation sind auf der sicheren Seite.
Dafür hast Du vielleicht mehr Arbeit, weil Du irgendwie mit allen Varianten von libFoo leben musst, erst recht, wenn es eine LibBar gibt, die behauptet, kompatibel zu LibFoo zu sein. Dieses Problem hast Du bei einer Container-Lösung nicht. Da schnürst Du alles zusammen, definierst die Schnittstellen zur Außenwelt (Port, Mountpoint, vielleicht erforderliche Services und fertig.) - na ja, hört sich einfach an, ist aber letzten Endes auch viel Gefrickel.
Mir gefällt dabei die klare Trennung zwischen Code und Daten. Der Container ist der Code, er ist ohne Gedächtnis (ohne Datenspeicher). Er kann dadurch super leicht ausgetauscht werden. Kein ssh+vi mehr :-)
Auch wenn ich es schon lange als sinnvoll ansehe, habe ich bisher nicht darauf umgestellt.
Erstmal die Pioniere mit Entdecker-Engagement die Bugs rausmachen lassen :-)
Gruß, Thomas
Hallo Thomas,
wie wäre es mit Docker? Distributionsunabhängig?
Gruß
Am 04.06.19 um 14:09 schrieb Henri Wahl:
Hallo Thomas,
wie wäre es mit Docker? Distributionsunabhängig?
Das wird aktuell bei dem konkreten Projekte (noch) nicht verwendet.
Das würde es etwas einfacher machen.
Gruß, Thomas
lug-dd@mailman.schlittermann.de
-
"Bernd Müller" -
Heiko Schlittermann -
Henri Wahl -
Kristian Rink -
Thomas Güttler