EasyLFS Projektthread

Um auch hier mal wieder ein kleines Update einzubringen:
Es geht voran. Die Targeted-Policy scheint nun soweit nutzbar, der Resume-Support ist fast fertig und es hat sich kurzfristig ergeben, dass EasyLFS 0.3 hoechstwahrscheinlich GPG enthalten wird.

Wie in meinem Blog geschrieben moechte ich Euch nun wieder herzlich dazu einladen Ideen und Vorschlaege zu praesentieren, welche dann in Zukunft (also nach 0.3) umgesetzt werden koennen.
 
Hmm, Ideen lassen ja noch etwas auf sich warten, aber dafuer gibt es ein Update.
Zum einen scheint das Wiki, und somit auch die Downloadseite, zur Zeit leider nicht erreichbar zu sein.
Zum anderen geht es mit grossen Schritten in Richtung EasyLFS 0.3.
Ueber's Wochenende hab ich vollstaendige Testbuilds sowohl mit als auch ohne SELinux gefahren und es sieht soweit alles sehr gut und vielversprechend aus, auch die SELinux-Policy und PAM scheinen wunderbar zu funktionieren.
Letzte Probleme wurden beseitigt sodass fuer die Fertigstellung jetzt im Grunde nur noch der Resume-Support fehlt.

Noch bin ich nicht ganz sicher ob ich PAM schon fuer EasyLFS 0.3 mit in den Standardumfang aufnehmen soll. Klar ist aber, dass wenn dem nicht so ist es standardmaessig zur Installation ausgewaehlt sein wird.

Falls jemandem ein Grund einfaellt warum PAM nicht Standard werden sondern eine Option bleiben sollte waere es nett diesen zu erfahren. Ich sehe naemlich zur Zeit keinen.
Im Grunde setzen alle grossen Distributionen auf PAM, und allgemein scheint eine sinnvolle Geschichte zu sein.
 
Folgt man der LSB 3.1 ist PAM genauso "empfohlen" wie Qt4 etc - damit man zur LSB konform ist, muss man also scheinbar ein Komplett-System zur Verfügung stellen :D ...ich für meinen Teil benutze Linux gerade DESHALB, da es in Punkto Sicherheit einiges mehr als ein Windows zu bieten hat und eben dieser Punkt das System für mich erst interessant macht. Also plädiere ich natürlich dafür, dass PAM seinen Weg in EasyLFS findet, und zwar als Standard - wer es nicht mag, soll es aber abschalten können, genauso wie den Midnight-Commander, SELinux oder Lynx.

Weitere Idee: Optional Xorg 7.x sowie ein Gnome oder KDE - DAS macht EasyLFS erst für viele interessant denke ich, und stellt auch erst DANN eine ECHTE Alternative für Klicki-bunti-Ubuntu oder Gentoo dar - EasyLFS hat dann SELinux und einen Desktop, dazu noch eine Standard-Firewall, die dem User erlaubt, alles nach drausen zu senden aber nix hinein zu lassen und ist somit dann ebenbürtig mit RHEL ;)
 
andy72 hat gesagt.:
Folgt man der LSB 3.1 ist PAM genauso "empfohlen" wie Qt4 etc - damit man zur LSB konform ist, muss man also scheinbar ein Komplett-System zur Verfügung stellen :D ...ich für meinen Teil benutze Linux gerade DESHALB, da es in Punkto Sicherheit einiges mehr als ein Windows zu bieten hat und eben dieser Punkt das System für mich erst interessant macht. Also plädiere ich natürlich dafür, dass PAM seinen Weg in EasyLFS findet, und zwar als Standard - wer es nicht mag, soll es aber abschalten können, genauso wie den Midnight-Commander, SELinux oder Lynx.
Zum Vergrößern anklicken....

So ist es bisher geregelt, PAM ist standardmaessig ausgewaehlt, der User kann aber vor der Installation dafuer sorgen, dass es nicht installiert wird.
Ich werde es dann wohl optional lassen, aber als Abhaengigkeit fuer SELinux definieren, sodass es auf jeden Fall installiert wird wenn SELinux installiert wird.

andy72 hat gesagt.:
Weitere Idee: Optional Xorg 7.x sowie ein Gnome oder KDE - DAS macht EasyLFS erst für viele interessant denke ich, und stellt auch erst DANN eine ECHTE Alternative für Klicki-bunti-Ubuntu oder Gentoo dar
Zum Vergrößern anklicken....
Dann duerfte es in dem CD-Image aber ordentlich eng werden. Ich bin ja jetzt schon bei 450MB, mit X und KDE waere ich wahrscheinlich bei 700-800MB, was dann nicht mehr passen wuerde. Und da waeren dann auch nicht noch die ganzen zusaetzlichen Libraries zur Aufloesung von Abhaengigkeiten und fuer zusaetzliche Features in KDE (von QT ganz zu schweigen ;) ) dabei.

Moeglicherweise lassen sich solche grossen Zusatzpakete ueber eine weitere CD machen, vergleichbar mit BLFS. Dort koennten dann einige grosse Pakete inklusive ihrer Abhaengigkeiten und eben den passenden Installationsscript liegen und so dann auch solche Pakete schoen automatisiert installiert werden.

Allgemein wollte ich eigentlich EasyLFS eher kompakt halten, aber schon einen gewissen Satz sinnvoller Software mitbringen.
Falls ich mich dazu hinreissen lasse grosse Pakete auf eine zusaetzliche CD auszugliedern koennte ich evtl. sogar ueberlegen alle optionalen Pakete die nicht so tief im System sitzen wie SELinux und PAM auszugliedern um das eigentliche EasyLFS wieder etwas schlanker zu machen.
Eine andere Moeglichkeit waere die Modularitaet der Linux-Live-Scripts zu nutzen und optionale Pakete als Module anzubieten. Diese koennten dann in die LiveCD eingebaut werden und mitkompiliert werden.

andy72 hat gesagt.:
EasyLFS hat dann SELinux und einen Desktop, dazu noch eine Standard-Firewall, die dem User erlaubt, alles nach drausen zu senden aber nix hinein zu lassen und ist somit dann ebenbürtig mit RHEL ;)
Zum Vergrößern anklicken....

Ein Firewall-Script zu erstellen was alles dicht macht und per Connection-Tracking eben nur angefragte Daten reinlaesst ist kein Problem, das laesst sich machen.
 
Ich denke, in Zeiten von Multimedia-fähigen Rechnern könnte man ruhig über eine DVD nachdenken, jedoch diese alternativ zu 2 CD's anbieten, damit ältere Rechner darunter nicht leiden müssen ;) ... ich persönlich würde das schon schön finden, wenn es ähnlich wie in Gentoo mehere Stages gäbe, die mir erlaubt, ein minimales grundsystem zu installieren, oder eben nach einlegen einer weiteren CD erlaubt, einen Desktop nachzuinstallieren.

Nachtrag:
Wenn man in Erwägung zieht, Xorg etc zu integrieren, könnte man das ja für Oktober vorsehen, wenn KDE 4 erscheint - dann könnte man einen genialen Desktop basteln - incl. D-BUS & HAL :D
 
Zuletzt bearbeitet:
Also eigentlich wollte ich das Ganze schon ueberschaubar, also im Rahmen einer CD halten.
Die Moeglichkeit mit den zusaetzlichen Modulen gefaellt mir da noch am besten.
Das Problem dabei duerften nur die Abhaengigkeiten zu anderen Paketen sein.

In meinen Scripts, welche ja sozusagen alle voneinander wissen kann ich mit Abhaengigkeiten ziemlich einfach fertig werden, ein zusaetzliches Modul hingegen muesste z.B. mit find oder whereis pruefen ob eine notwendige Library bereits installiert wurde (falls diese nicht zum Standardumfang gehoert) und diese gegebenenfalls nachinstallieren.
 
Ja gut, installiert man zB KDE oder Gnome, werden natürlich noch zig Bibliotheken benötigt, und da bietet sich dann wohl doch an, das ganze in Pakete zu schnüren. Wobei mir da einfällt,dass man dann gleich mit RPM installieren kann, um diese Abhängigkeiten zu gewährleisten :D *an SuSE und RH denk, die dann schnell mal 200GB Platz brauchen :D*
 
Funktionieren tut es schon, ganz sicher - aber soweit ich mal mit einem früheren LFS experimentiert habe, musste ich feststellen, dass sich RPM bei einer nicht zum System gehörenden RPM-DB beschwert hat, dass Paket b ohne Paket a nicht installiert werden kann, und ich ja noch nich mal ne Bash habe - was aber der Fall war. Man muss also RPM erstmal beibringen, was alles da ist, damit man damit richtig arbeiten konnte. Habe RPM in meinen selbst kompilierten Systemen nicht mehr verwendet, brauchte nur die Libs davon und Cpio, um RPM zu dekomprimieren ;)
 
RPM funktioniert im Grunde soweit, DPkg eben erst mit der kommenden Version, da dafuer noch ein paar Dateien erstellt werden mussten.
Dass beide Paketmanager grundlegende Pakete nicht finden liegt daran, dass diese nicht in deren Datenbanken stehen, um solche Abhaengigkeiten zu umgehen gibt es aber bei beiden Managern die Moeglichkeit diese nicht zu ueberpruefen. Ist zwar nicht ganz fein, aber zum einen ist EasyLFS kein Einsteigersystem, zum anderen sollen die beiden Paketmanager eben nur dafuer da sein, dass man eben die Moeglichkeit hat fertige Pakete zu installieren.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück