Der MC macht einem das Leben zwar um einiges einfacher, aber braucht ein erfahrener Anwender ihn auch?

Mit DHCP ist immer so eine Sache, ich persönlich nutze schon seit Ewigkeiten und 3 Tagen ausschliesslich statische IP's.
Wichtig ist halt dass man die Netzwerkkonfiguration rechtzeitig vornehmen kann (logischerweise vor irgend welchen Downloads ).

DosFSTools sind zwar Standard, werden aber nicht von jedem gebraucht --> optionales Paket.

NTFS-3G, siehe DosFSTools.

Screen könnte durchaus interessant sein.

NcFTP kann ganz nützlich sein, aber meiner Meinung nach nur als optionales Paket.
Um z.b. weitere Sourcen downloaden zu können, sollte wget ausreichend sein.

OpenSSH, da würde ich nicht nur den Client nehmen.
Allerdings würde ich es nur als optionales Paket anbieten.

Lilo statt Grub ist gut (ich hasse Grub ).
Evtl. würde ich hier dem Anwender aber die Wahl lassen (andere schwören halt auf Grub).

RAID-Unterstützung braucht nicht jeder --> optionales Paket.

joe ist gut (nutze ich ausschliesslich), nano kenne ich nicht, mit vi(m) bin ich noch nie klargekommen.

SLocate kenne ich nicht, hört sich aber interessant an.
Bei locate sollte auch updatedb installiert werden.
Das updaten der Datenbank muss aber nicht zwangsläufig per Cronjob geschehen (mache ich manuell).

hdparm ist meiner Meinung nach Pflicht.
smartmontools währe wohl eher wieder ein optionales Paket.

dpkg und rpm würde ich auch nur als optionale Pakete anbieten.

Lynx kenne ich zwar nur von hören sagen, kann aber (in Verbindung mit wget) ganz nützlich sein.

Ich weiss nicht ob Lynx oder wget OpenSSL (bzw. Teile davon) für eine HTTPS Verbindung brauchen, wenn nicht dann als optionales Paket.

dcron ist meiner Meinung nach Pflicht.

eject ist nicht unbedingt notwendig, aber ganz nützlich.
Evtl. (sofern nicht schon geschehen) könnte man die CD nach abgeschlossener Installation automatisch auswerfen.

Ich weiss nicht ob FUSE auch für CD's gebraucht wird, wenn nicht dann nur als optionales Paket.

iptables ist meiner Meinung nach (mit einer vernünftigen "Grundkonfiguration") Pflicht.

kexec-tools nur als optionales Paket, da es u.U. zu Problemen kommen kann.

lm-sensors --> Spielkram (funktioniert eh nicht auf jedem PC ) --> optionales Paket.

net-tools sollte zur Grundausstattung gehören.

ntfsprogs, siehe NTFS-3G.

Parted kommt mit NTFS nicht klar, ausserdem bin ich der Meinung dass man sowas nicht von einem laufendem System aus starten sollte.
Halte ich also für überflüssig.

pciutils und usbutils sollten Pflicht sein.

which, keine Ahnung wofür das gut sein soll.

So, das waren mal ein paar Meinungen von einem nicht Profi.

Zitat von Dr Dau

Der MC macht einem das Leben zwar um einiges einfacher, aber braucht ein erfahrener Anwender ihn auch?

Schon richtig, ich selbst nutze ihn auch nicht. Wenn ich mal in der Shell arbeite dann arbeite ich mit den bekannten Befehlen. Und in KDE wuerde ich wohl kaum auf die Idee kommen MC den Vorzug von Konqueror zu geben.
Wenn dann kommt der eh nur als optionales Paket dazu.

Zitat von Dr Dau

Mit DHCP ist immer so eine Sache, ich persönlich nutze schon seit Ewigkeiten und 3 Tagen ausschliesslich statische IP's.
Wichtig ist halt dass man die Netzwerkkonfiguration rechtzeitig vornehmen kann (logischerweise vor irgend welchen Downloads ).

Die Netzwerkkonfiguration wird bei der Installation vorgenommen. Dort will ich halt auch die Moeglichkeit bieten DHCP nutzen zu koennen da doch so einige darauf setzen.

Zitat von Dr Dau

DosFSTools sind zwar Standard, werden aber nicht von jedem gebraucht --> optionales Paket.

Wird dann eh optional, wie es jetzt auch die NTFSProgs sind.

Zitat von Dr Dau

NTFS-3G, siehe DosFSTools.

Siehe DosFSTools.

Zitat von Dr Dau

Screen könnte durchaus interessant sein.

Sehe ich auch so, aber eben auch optional, wie so viele Pakete.

Zitat von Dr Dau

NcFTP kann ganz nützlich sein, aber meiner Meinung nach nur als optionales Paket.
Um z.b. weitere Sourcen downloaden zu können, sollte wget ausreichend sein.

Richtig wget und der normale FTP-Client reichen eigentlich aus. Was ich persoenlich an NcFTP schaetze ist die Bookmarkfunktion. Daher koennte es durchaus als Option dabei sein denke ich.

Zitat von Dr Dau

OpenSSH, da würde ich nicht nur den Client nehmen.
Allerdings würde ich es nur als optionales Paket anbieten.

Zitat von Dr Dau

Lilo statt Grub ist gut (ich hasse Grub ).
Evtl. würde ich hier dem Anwender aber die Wahl lassen (andere schwören halt auf Grub).

Ich hab ehrlich gesagt bisher nie mit Grub gearbeitet und muesste entsprechend erstmal gucken wie ich den automatisch konfiguriert kriege. Denn soweit ich weiss wird dort nicht einfach mit /dev/hdxY gearbeitet, sondern mit anderen lustigen Devicenamen. Da muesste ich dann also mal rausfummeln wie ich vom normalen Device zum "Grub-Device" komme.

Zitat von Dr Dau

RAID-Unterstützung braucht nicht jeder --> optionales Paket.

Ist schon optional, aber auch auf der LiveCD installiert falls benoetigt.

Zitat von Dr Dau

joe ist gut (nutze ich ausschliesslich), nano kenne ich nicht, mit vi(m) bin ich noch nie klargekommen.

Ich selbst nutze auch lieber joe. vim wird halt wieder Pflicht da crontab drauf setzt.

Zitat von Dr Dau

SLocate kenne ich nicht, hört sich aber interessant an.
Bei locate sollte auch updatedb installiert werden.

updatedb wird eh mit installiert da sowohl locate als auch updatedb Teil der FindUtils sind. SLocate biete ich halt als Alternative.

Zitat von Dr Dau

Das updaten der Datenbank muss aber nicht zwangsläufig per Cronjob geschehen (mache ich manuell).

Richtig, moeglicherweise sollte ich diesen Cronjob als Option bieten.

Zitat von Dr Dau

hdparm ist meiner Meinung nach Pflicht.
smartmontools währe wohl eher wieder ein optionales Paket.

Sind beide als Option drin, hdparm ist aber per Default ausgewaehlt.

Zitat von Dr Dau

dpkg und rpm würde ich auch nur als optionale Pakete anbieten.

Sind sie.

Lynx kenne ich zwar nur von hören sagen, kann aber (in Verbindung mit wget) ganz nützlich sein. [/quote]
Das Problem bei wget ist ja, dass man keine Moeglichkeit zum Browsen hat und somit URLs wissen muss um an weitere Software kommen zu koennen. Mit Lynx kann man aber auch bei Sourceforge oder Freshmeat vorbeischauen und da nach Software suchen.

Zitat von Dr Dau

Ich weiss nicht ob Lynx oder wget OpenSSL (bzw. Teile davon) für eine HTTPS Verbindung brauchen, wenn nicht dann als optionales Paket.

Ja, wird von denen benoetigt. Und da OpenSSL auch ansonsten recht gern genutzt wird ist dies eines der wenigen zusaetzlichen Pakete welches nicht optional ist.

Zitat von Dr Dau

dcron ist meiner Meinung nach Pflicht.

Viele Leute nutzen Cron, aber ich denk nicht unbedingt alle. Wenn ich nicht per Cronjob meinen Virenscanner und die SLocate-Datenbank aktualisieren wuerde wuerde ich ihn eigentlich nicht brauchen.

Zitat von Dr Dau

eject ist nicht unbedingt notwendig, aber ganz nützlich.
Evtl. (sofern nicht schon geschehen) könnte man die CD nach abgeschlossener Installation automatisch auswerfen.

Das hab ich schon probiert, das wollte aber bisher nicht so recht.

Zitat von Dr Dau

Ich weiss nicht ob FUSE auch für CD's gebraucht wird, wenn nicht dann nur als optionales Paket.

FUSE ist hauptsaechlich dabei um mit den NTFSProgs (und evtl. NTFS-3G) vernuenftigen Schreibzugriff fuer NTFS-Partitionen zu bieten. Wie auch die NTFSProgs ist FUSE optional.

Zitat von Dr Dau

iptables ist meiner Meinung nach (mit einer vernünftigen "Grundkonfiguration") Pflicht.

Es sollte im Grunde dazugehoeren, richtig. Ich denk mal ich werd es in die Standardinstallation aufnehmen falls sich dazu hier keine Gegenstimmen finden.

Zitat von Dr Dau

kexec-tools nur als optionales Paket, da es u.U. zu Problemen kommen kann.

Zitat von Dr Dau

lm-sensors --> Spielkram (funktioniert eh nicht auf jedem PC ) --> optionales Paket.

Kann aber durchaus mal interessant sein, deshalb ist es als Option mit dabei.

Zitat von Dr Dau

net-tools sollte zur Grundausstattung gehören.

Da geb ich Dir Recht. Wie auch bei IPTables wird es wohl in der naechsten Version Standard werden wenn sich hier keine Gegenstimmen finden.

Zitat von Dr Dau

ntfsprogs, siehe NTFS-3G.

Genau, siehe NTFS-3G, und auch FUSE.

Zitat von Dr Dau

Parted kommt mit NTFS nicht klar, ausserdem bin ich der Meinung dass man sowas nicht von einem laufendem System aus starten sollte.
Halte ich also für überflüssig.

Parted kommt, die NTFSProgs vorausgesetzt, wunderbar mit NTFS klar. Ich hab damit bereits meine NTFS-Partitionen verkleinert und verschoben und es hat wunderpraechtig und absolute ohne Datenverlust funktioniert.

Zitat von Dr Dau

pciutils und usbutils sollten Pflicht sein.

Sie sind zur Zeit optional, aber per default ausgewaehlt.

Zitat von Dr Dau

which, keine Ahnung wofür das gut sein soll.

which ist ganz praktisch um herauszufinden wo ein bestimmten Binary liegt, innerhalb der im $PATH angegebenen Pfade.

Code :

1 2	bash-3.1# which locate /usr/bin/locate

Kann auch gut in Kombination mit anderen Programmen genutzt werden.

Code :

1 2 3 4

bash-3.1# ldd `which locate`         linux-gate.so.1 =>  (0xb7fa8000)         libc.so.6 => /lib/libc.so.6 (0xb7e6a000)         /lib/ld-linux.so.2 (0x80000000)

Der Vorteil von which gegenueber whereis ist dass hier nur ein Pfad ausgegeben wird, und nicht evtl. mehrere. So weiss man dann auch welche Version genutzt wird wenn man das gleiche Binary in mehreren Verzeichnissen (z.B. einmal in /usr/bin und einmal in /usr/local/bin) liegen hat.

Zitat von Dr Dau

So, das waren mal ein paar Meinungen von einem nicht Profi.

Vielen Dank fuer Deine Ansichten.

Wie Du siehst, die meisten Pakete die nicht Teil des Original-LFS sind sind bei mir optional, ein paar davon sind standardmaessig aktiviert, koennen aber eben deaktiviert werden.

Hm,

so viel getippsel auf einmal
Also, ich würd ja mal sagen, dass der MC sehr wohl zum Pflichtprogramm gehört,wa ? *g*
*aufreg* ... *rumnörgel*

Grund:
Ich arbeite seit 1992 mit PC's, und bin seit je her den guten alten Norton Commander gewohnt, mit dem ich heute im Linux noch sehr gerne arbeite, gerade, weil ich im tippseln
nicht der schnellste bin und auch nicht die Lust dazu habe, das alles zu schreiben, was man an der Konsole macht. zB macht sich mit MC FTP wesentlich komfortabler, kopieren geht schneller, als wenn ich das erst tippen muss, gerade bei langen Pfaden oder wenn ich noch nicht so recht weiss, wo was hin soll etc - Gründe gibts viele. Klar, man das alles an der Konsole machen, dazu gibts auch genug Befehle

Was VIM betrifft, auf den mag ich auch nicht mehr verzichten, gerade, wenn es was zu Patchen oder fixen geht, leistet er gute Dienste - nee, man braucht das Ungeheuer nicht wirklich im X11, aber an der Konsole schon ...

LG
Andy

Zitat von Dennis Wronka

updatedb wird eh mit installiert da sowohl locate als auch updatedb Teil der FindUtils sind.

Nun, unter Eisfair ist zwar per default locate installiert, aber wenn man updatedb eintippt kommt nur ein "command not found".
updatedb ist für locate also nicht zwingend erforderlich..... nur ohne dem macht locate nicht wirklich Sinn.
Darum habe ich daruf hingewiesen.

Zitat von Dennis Wronka

Das Problem bei wget ist ja, dass man keine Moeglichkeit zum Browsen hat und somit URLs wissen muss um an weitere Software kommen zu koennen.

Genau deshalb kann Lynx ja ganz nützlich sein.

Zitat von Dennis Wronka

Viele Leute nutzen Cron, aber ich denk nicht unbedingt alle.

Iregndwas, was automatisiert ausgeführt werden soll, gibt es mit sicherheit immer.
Daher sehe ich es als Pflicht an.

Zitat von Dennis Wronka

Das hab ich schon probiert, das wollte aber bisher nicht so recht.

Schade.
Aber ein umount mit anschliessendem Hinweis die CD rauszunehmen sollte es auch tun.

Parted kommt, die NTFSProgs vorausgesetzt, wunderbar mit NTFS klar. Ich hab damit bereits meine NTFS-Partitionen verkleinert und verschoben und es hat wunderpraechtig und absolute ohne Datenverlust funktioniert.

Da habe ich mich nur an die Feature Liste orientiert..... und die ist alles andere als vielversprechend (nichtmal dass erstellen einer ext3 Partition wird unterstützt).

Zitat von Dennis Wronka

Vielen Dank fuer Deine Ansichten.

Bitte.

Zitat von Dennis Wronka

Wie Du siehst, die meisten Pakete die nicht Teil des Original-LFS sind sind bei mir optional.....

Ich weiss/sehe nicht welche Pakete bei LFS dabei sind.
Um mich so intensiv damit zu befassen, sind meine Kenntnise einfach nicht ausreichend genug.
Aber der eine oder andere Blick ins LFS-Handbuch hat mir (dank der deutschen Übersetzung) auch schon sehr weiter geholfen.

@andy72, ich sage ja, der MC kann einem das Leben einfacher machen.
Ich selbst habe früher auch mit dem NC 5/5.5 gearbeitet.
Von daher hat mir der MC sehr gut bei den "ersten Berührungsängsten" mit Linux geholfen.

So, die Arbeit an der naechsten Version kann losgehen.

Ich hab jetzt grad 139MB Pakete runtergeladen, insgesamt 33 Pakete, davon 7 neu und 26 neue Versionen bereits eingesetzter Pakete.
Die neuen Pakete sind:

• Bind
• DHCP
• DosFSTools
• Midnight Commander
• NcFTP
• OpenSSH
• Screen

Diese Pakete werden also, wenn es keine Probleme gibt den Weg in die naechste Version finden.
Zu den aktualisierten Paketen gehoeren unter anderem:

• GCC 4.0.4 und 4.1.2
• saemtliche SELinux-Pakete
• ncurses
• iproute2
• Kernel 2.6.20

Und natuerlich noch andere.

Als naechstes mach ich dann erstmal ein Backup von meinem bestehenden Verzeichnis und dann faengt die Arbeit an.

So, mal wieder ein kleiner Bericht meines schaffens:

Habe gestern und heute morgen versucht, SELinux zum laufen zu bekommen,
leider noch ohne generellen Erfolg, da noch einiges nicht so funktioniert, ich denke aber, bis zum Montag werde ich ein erstes Ergebnis haben.

Folgendes ist bis jetzt erfolgreich integriert:
Der Kernel (noch 2.6.19.1) ist erstmal SELinux-aktiviert (geht unter Security Options zu aktivieren), und man muss dann am Lilo (noch) selinux=1 mit angeben um das ganze zu starten. Habe die SELinux-Libraries und Tools kompiliert und in das System integriert,
in der /etc/fstab gibt es nun ein neues virtuelles Dateisystem: selinuxfs und es wurde auch
erfolgreich unter /selinux gemounted. Nun kommt noch ein Patch für init, da die Policies bereits beim System-Start geladen werden müssen und einige Pakete wie zB shadow,coreutils müssen auch noch neu integriert werden. Noch stürzt der Kernel beim herunterfahren des Systems ab, entweder, ich bekomm das behoben, oder auch ich werde auf Kernel 2.6.20 upgraden und es dann neu versuchen.
Desweiteren fehlt noch völlig die policy.conf, welche die Hauptkonfiguration ist, diese werde ich dann am WE mal schreiben, zumindest für einen Basis-User.

So, das erstmal zu easyLFS und von mir, wenn wer Erfahrung mit SELinux hat, wäre ich an dieser Stelle sehr dankbar für jeden Hinweis, wie man das ganze komplett integriert.

LG
Andy

Ja, SELinux ist so eine Sache.
Wenn man es voll im System haben will dann muss wohl auch die GlibC entsprechend kompiliert werden. Entsprechend wird bei EasyLFS GlibC auch nochmal neu kompiliert wenn SELinux installiert wird, damit auch alles drin ist was drin sein muss.

Fuer die neue Version werd ich mir auch mal von allen Paketen die configure-Optionen anschauen um zu sehen ob es da eine Option fuer SELinux gibt, und natuerlich auch um /usr/etc loszuwerden.

Gestern auf der Arbeit hab ich mir auch die gut 50 Seiten FHS ausgedruckt um zu checken wo mein System diesem nicht entspricht (ein Punkt ist das angesprochene /usr/etc) und dieses dann nach Moeglichkeit korrigieren.

Ansonsten fang ich jetzt auch schon mit den ersten Kompiliertests an damit ich spaeter hoffentlich nicht ganz so viel Arbeit habe.
Waehrend jetzt Stage 1 mit GCC 4.1.2 kompiliert werd ich dann mal eben einkaufen gehen und dann mit den neuen Scripts anfangen.

So, ich hab wieder einen Schritt in Richtung Vereinfachung der Installation getan.
Ich hab mir mal chroot etwas genauer angesehen und dort gesehen, dass man einen beliebigen Befehl zur Ausfuehrung angeben kann. Das kann ja dann statt einer Shell im Grunde auch gleich eines meiner Scripts sein.
Nun ich hab die entsprechenden Scripts etwas angepasst und noch ein weiteres gebastelt was, wenn nun alles funktioniert, dafuer sorgen sollte dass die Installation durch den Aufruf eines einzigen Scripts abgewickelt werden kann.
Natuerlich muss weiterhin vorher die lfs_config.sh bearbeitet werden, aber danach gibt es nur noch einen weiteren Aufruf.
Die Installation wird dann 2 bis 3 mal unterbrochen, einmal zu Beginn um die Zeitzone einzustellen, einmal am Ende um das root-Passwort festzulegen und eventuell ein drittes Mal (das kommt auf die neue Einstellung LFS_USE_CDKERNEL an) um den Kernel zu konfigurieren.

Die Konfiguration des Kernels kann nun auch, dank der angesprochenen Option LFS_USE_CDKERNEL und dem Kernel-Feature die Kernel-Konfiguration mit in den Kernel aufzunehmen und in eine Datei in /proc zu exportieren, auch uebersprungen werden. Dabei wird dann eben die Konfiguration des auf der LiveCD befindlichen Kernels genutzt. Das macht die grundlegende Installation ein wenig einfacher, und wenn man so weit gekommen ist sollte das eigentlich Beweis genug sein, dass der Kernel auf der CD auf dem eigenen System lauffaehig, wenn auch nicht unbedingt optimal konfiguriert, ist.
Dieser wird dann in Zukunft auch noch etwas kompletter ausgestattet. Hierbei denk ich nun in erster Linie an die Module fuer Netzwerkkarten, welche dann auch im Grunde die CD netzwerkfaehig machen werden.

Hier ist nun wieder Eure Meinung gefragt.
Sollte diese Option standardmaessig an ("automatische" Kernel-Config) oder aus (manuelle Kernel-Config) sein?

So, mal ein kleines Update zum chinesischen Neujahr, und natuerlich Kung Hei Fat Choi!

Gestern hab ich den ersten Testrun mit dem neuen Script hinter mich gebracht.
Soweit laeuft die komplette Installation mit dem einen Script durch, jedoch scheint es Probleme beim unmounten der Partition zu geben. Woran das liegt konnte ich aus Zeitgruenden gestern nicht mehr recherchieren, aber da werd ich entweder heute oder spaetestens morgen die Zeit zu finden.
Auf jeden Fall ist damit ein weiterer, wichtiger Schritt vorwaerts getan worden da ja nun nurnoch die Bearbeitung der lfs_config.sh noetig ist und anschliessend der Aufruf von lfs_install.sh, und nicht mehr lfs_stage1.sh, lfs_chroot.sh, lfs_stage2.sh, lfs_finish.sh (plus 2 mal cd /lfs-install, jeweils vor lfs_stage2.sh und lfs_finish.sh) wie es zur Zeit noch der Fall ist.

Dadurch kann die Installation nun auch laenger unbeaufsichtigt sein ohne viel Zeit zu verlieren. Wie im vorigen Beitrag erwaehnt wird jetzt nur noch am Anfang und Ende kurz unterbrochen. Wenn man die erste Unterbrechung, die Einstellung der Zeitzone, hinter sich hat kann man eigentlich getrost was anderes machen, vor allem wenn man den Kernel "automatisch" konfigurieren laesst, denn dann wird nach der naechsten Unterbrechung (dem Setzen des root-Passworts) nichts mehr kompiliert und es geht alles recht fix dem Ende entgegen.

Ausserdem moechte ich den folgenden Punkt auch nochmal in Erinnerung rufen.

Zitat von Dennis Wronka

Die Konfiguration des Kernels kann nun auch, dank der angesprochenen Option LFS_USE_CDKERNEL und dem Kernel-Feature die Kernel-Konfiguration mit in den Kernel aufzunehmen und in eine Datei in /proc zu exportieren, auch uebersprungen werden. Dabei wird dann eben die Konfiguration des auf der LiveCD befindlichen Kernels genutzt. Das macht die grundlegende Installation ein wenig einfacher, und wenn man so weit gekommen ist sollte das eigentlich Beweis genug sein, dass der Kernel auf der CD auf dem eigenen System lauffaehig, wenn auch nicht unbedingt optimal konfiguriert, ist.
Dieser wird dann in Zukunft auch noch etwas kompletter ausgestattet. Hierbei denk ich nun in erster Linie an die Module fuer Netzwerkkarten, welche dann auch im Grunde die CD netzwerkfaehig machen werden.

Hier ist nun wieder Eure Meinung gefragt.
Sollte diese Option standardmaessig an ("automatische" Kernel-Config) oder aus (manuelle Kernel-Config) sein?

Hallo allerseits,

auch von mir gibt es was neues in Sachen SELinux:
habe mich übers WE mit SELinux ausgiebig beschäftigt, Erfolge gibt es nur insoweit, dass die Basis-Konfiguration erstmal läuft, nachdem ich etliche Dinge angepasst habe,
nun gibt es neben easyLFS wohl doch ein neues Unterprojekt, da ih mich entschlossen
habe, das SELinux abzukapseln. Das heisst im Grunde, dass es gegen ende dieser Woche auf meiner Homepage einige Infos zu SELinux geben wird, speziell, wie man
SELinux erfolgreich in easyLFS integriert. Bis dahin werde ich die entsprechenden Applikationen umprogrammieren, da es bei einigen Sachen nicht mehr reicht, einfach zu patchen - zB gibt es massive Probleme bei den Coreutils, da es generell keine Patches
dafür gibt, die mit SELinux (noch) kompatibel sind.

Bis jetzt gibt es die Anwendung "ls -Z" und "ls --context", die nicht wie bisher nur die dateistruktur eines Verz. anzeigen, sondern auch deren Context unter SELinux sowie selbige Schalter für "stat". Allein dieser Umbau hat mich den Sonntag gekostet, auch "init" wurde umprogrammiert, um SELinux bereits beim Bootvorgang zu aktivieren.

@Dennis:
Der Patch für Init, den ich Dir geschickt habe, weisst massive Fehler auf, bitte verwende diesen Patch nicht weiter - auch dafür gibt es gegen ende der Woch einen funktionierendes "init", da auch kill/killall noch umgebaut wird.

Eine schöne Woche
Andy

Wow, das sind ja mal gute Nachrichten.

Erstmal vielen, vielen Dank fuer Deinen Einsatz. Ich haette echt nicht gedacht, dass die Integration von SELinux so aufwaendig waere. Ich frag mich ob man nicht irgendwo ueber Fedora Infos finden kann, dort ist doch SELinux auch integriert, nicht?
Man kann nur hoffen, dass immer mehr Pakete in Zukunft den SELinux-Support gleich mit in die Pakete bauen sodass die Installation einfacher wird.
Vor allem sollte es eben auch moeglich sein SELinux gleich bei der Systeminstallation installieren zu koennen. Aber naja, SELinux-Unterstuetzung ist im Grunde mit drin, aber wie ich nun weiss wirklich nur die Anfaenge.

Naja, aber Dank Deiner unermuedlichen Arbeit geht es ja mit der SELinux-Unterstuetzung nun wirklich vorwaerts, mit, wie es sich anhoert, greifbaren Erfolgen.

Auch auf meiner Seite geht es tapfer weiter. Nachdem ich heute vormittag die Scripts fuer die neuen Pakete geschrieben hab hab ich damit einen erfolgreichen Testlauf durchmachen koennen. Nur Midnight Commander will noch nicht da dieser die GLib haben will. Da werd ich also mal nach weiteren Abhaengigkeiten forsten und diese dann, falls nicht zu zahlreich, mit einfuegen. Falls GLib zu viele Abhaengigkeiten hat wird mc wohl erstmal wieder rausfliegen. Mal schauen.
Auf jeden Fall lassen sich Bind, DHCP und auch OpenSSH wunderbar installieren.

Der naechste Schritt wird nun auch sein dafuer zu sorgen, dass /usr/etc wegfaellt und ich will auch mal mein System mit dem aktuellen FHS vergleichen um zu diesem weitestgehend kompatibel zu sein.

Ein wenig Zeit hab ich jetzt noch, heute Abend wird wohl das Feuerwerk sein, in der Zeit wollt ich noch einen Testlauf starten. Und morgen hab ich ja auch noch frei. Da kann ich dann auch noch einiges an Arbeit in das Projekt stecken.

In der Zeit die ich jetzt noch hab werd ich wohl wegen der GLib schauen. Aber mal sehen, vielleicht faellt das Feuerwerk auch wegen schlecht Wetter in's Wasser da es heut ein wenig regnerisch aussieht.

Nachtrag: Die GLib kann im aktuellen System also ohne Probleme installiert werden.
Da Midnight Commander nun wohl recht egal ist ob man Version 1.2 oder eine 2er Version nutzt hab ich nun Version 2.12.4 installiert. Damit scheint mc auch wunderbar zu funktionieren.
Mir stellt sich nun nur die Frage ob es vielleicht fehlende Abhaengigkeiten zu X gibt, welche spaeter evtl. dafuer sorgen koennten, dass man GLib nochmal kompilieren muss?

Ich werd da mal schauen, auch mal in Version 1.2.

Fedora bietet nur HowTos, wie man SELinux in RH deaktiviert, nix davon, wie man überhaupt eine Policy schreibt, geschweige, wie man was integriert. ich habe vieles von Gentoo geholt, so auch ein funktionierendes Init, und auch, wie man SELinux überhaupt im Kernel zum Laufen bringt, da man doch recht viele Dinge dabei beachten muss.
Weitere Dinge habe ich durch lesen von Patches gelernt, da diese doch recht umfangreich sind, wenn alles zusammen passen soll Hast aber Recht: Die Integration von SELinux ist echt nix neue Linuxer, da der Programmier-Aufwand recht hoch ist und vieles auf Anhieb nicht funktioniert. zB passen nach der SELinux-Integration keine Patches mehr vom LFS-Project, um mal Klartext zu reden - das heisst, deren Patches müssen direkt NEU integriert werden.

Na dann wird eben SELinux "erstmal" ein weiteres "Feature fuer Mutige", wie es zur Zeit auch Ext4 scheinbar noch ist.

Ach so:
@LFS Patches: Von denen bin ich mittlerweile zu recht grossen Teil weg da ich ja bei so gut wie allen Paketen ein paar Versionsnummern weiter bin. Das hat die meisten Patches ueberfluessig gemacht.

So, mal wieder ein kleines Update.

Es scheint irgendwie, dass irgendwas noch auf /mnt/lfs zugreift zu dem Zeitpunkt wo es unmountet werden soll. Das scheint damit zusammenzuhaengen, dass nun alle Scripts von einem Script ausgefuehrt werden.
Damit das System trotzdem nach der erfolgreichen Installation rebooten kann hab ich mir mal die Optionen von umount angeschaut und den Parameter -l gefunden, fuer "lazy unmount".
Das heisst im Klartext, dass das System zwar ausgehaengt wird, aber von Prozessen die noch drauf zugreifen weiter genutzt werden kann. Neue Prozesse koennen dort aber nicht mehr drauf zugreifen.
Da alle zugreifenden Prozesse beendet sind sobald auch das Installationsscript schliesslich zu seinem Ende kommt wird zu diesem Zeitpunkt auch die Partition endgueltig ausgehaengt, was einen sicheren Reboot garantieren sollte.

Bis ich das aber testen kann dauert noch ein wenig da ich dafuer erstmal eine neue LiveCD bauen muss und diese dann in QEmu installieren lassen muss.
Aber eigentlich sollte es gehen.

Weiterhin hab ich nun die meisten Scripts aus /lfs-install in das Unterverzeichnis modules verbannt, was die Uebersicht fuer den User vereinfacht.
Dadurch gibt es nun nur noch 2 Scripts direkt in /lfs-install, das zu bearbeitende Script lfs_config.sh und das eigentliche Installationsscript lfs_install.sh.

So, nach ein paar Tagen harter Arbeit mal wieder ein Update.

Da es mir ja wichtig ist, dass die von mir gelieferte Software moeglichst aktuell ist soll sich das ja auch in der LiveCD selbst wiederspiegeln. So hab ich also auch die neuen Linux-Live-Scripts runtergeladen und mich die letzten Tage damit rumgeaergert.
Dabei gibt es ein paar ordentliche Aenderungen welche mir eben erstmal einiges an Arbeit eingebracht haben. Allgemein muss ich aber sagen, dass die neue Version der Live-Scripts es dem geneigten LiveCD-Bastler einfacher macht als es mit aelteren Versionen der Fall war.
Nun mal zu den Aenderungen: UnionFS wird durch AUFS (Another UnionFS) ersetzt. Dieses soll wohl stabiler laufen als UnionFS und auch mehr Features bieten.
Weiterhin wird SquashFS nun mit LZMA-Kompression genutzt was nun dazu fuehrt, dass mein CD-Image bei ca. 20MB mehr Inhalt ca. 1MB kleiner ist als die aktuell verfuegbare Version. Es gibt also bei der kommenden Version also mehr Fisch zum gleichen Preis.

Diese beiden Geschichten waren schon recht umstaendlich.
AUFS bietet nicht einfach einen Kernel-Patch und gut, sondern will erstmal ein Makefile erzeugt haben und anschliessend muss man die Sourcen in den Kernel kopieren. Um es mir fuer die Zukunft einfacher zu machen hab ich das einmal gemacht und dann daraus einen Patch erstellt.

Der LZMA-Patch fuer SquashFS war nicht so einfach, vor allem da das mitgelieferte Makefile nicht so ganz wollte wie ich. Ausserdem bin ich eh kein Freund von solchen Makefiles die irgendwie wild rumwuseln.
Entsprechend hab ich dieses Makefile in ein Script umgeschrieben und meinen Anspruechen entsprechend angepasst.
SquashFS mit LZMA-Unterstuetzung hat mich in den letzten Tagen einiges an Zeit und Nerven gekostet, aber es ist jetzt geschafft.

Wenn ich mich irgendwann mal ransetze ein Tutorial ueber die Erstellung einer LiveCD mit den Linux-Live-Scripts zu schreiben werd ich das alles da mit einbringen.

Da sich halt auch an den Live-Scripts selbst einiges geaendert hat hab ich natuerlich erstmal ein paar Fehlversuche gebraucht bis ich langsam aber sicher voran kam.
Aber auch die Scripts duerften nun vollstaendig angepasst sein sodass die naechste LiveCD wohl keine Probleme mehr haben duerfte.
Diese wird grad erstellt, was aber durch die LZMA-Kompression nun "etwas" laenger dauert. Aber es gibt schlimmeres als darauf zu warten bis gut 1.5GB an Daten zu 450MB zusammengepresst werden.

Somit ist nun ein wichtiger Schritt getan, sodass ich nun auch die ersten "Live-Tests" im QEmu starten kann. Weiterhin sind noch die Tests mit GCC 4.0 und GCC 4.1 faellig und danach sollte dem Release eigentlich nichts mehr im Wege stehen.
Da ich naechstes Wochenende umziehen werden will ich auf jeden Fall schauen, dass ich vorher noch releasen kann, denn danach wird meine Zeit um an meinem Projekt zu arbeiten zumindest anfangs ein wenig eingeschraenkter sein als sie jetzt ist.
Sterben lassen werde ich EasyLFS aber nicht, denn dafuer hab ich nun auch schon zu viel Zeit investiert und ich will ja auch fuer mich selbst ein gutes System bauen was ich auch selbst nutzen wuerde.