EasyLFS Projektthread
- Themenstarter Dennis Wronka
- Beginndatum
Dennis Wronka
Soulcollector
Mit PAM hab ich mich bislang auch nicht gross auseinander gesetzt.
Ich hatte glaub ich mal versucht es irgendwann irgendwo einzubinden aber anschliessend war kein Login mehr moeglich wenn ich mich recht erinnere.
Ich muss da also scheinbar was falsch gemacht haben.
Wird PAM denn auch effektiv genutzt oder ist es einfach nur da?
Welchen Vorteil bringt uns PAM?
Ich hatte glaub ich mal versucht es irgendwann irgendwo einzubinden aber anschliessend war kein Login mehr moeglich wenn ich mich recht erinnere.
Ich muss da also scheinbar was falsch gemacht haben.
Wird PAM denn auch effektiv genutzt oder ist es einfach nur da?
Welchen Vorteil bringt uns PAM?
andy72
Erfahrenes Mitglied
PAM bringt den Vorteil, dass es sämtliche Logins abgreift, OpenSSH noch etwas mehr einschränkt (absichert) und eben auch auf SELinux aufsetzt. Ich vermute, da es auf SELinux aufsetzt, dass es intern ebenfalls den Context abprüft, ob im Sys was passieren darf. Ersteres ist aber Fakt - SuSE und RedHat setzen das schon seit Jahren ein 
Dennis Wronka
Soulcollector
Ich denke es koennte durchaus eine Ueberlegung wert sein PAM einzubauen.
Aber ich denke eher in der nachfolgenden Version und nicht mehr in der kommenden, da ich ja jetzt im Grunde schon bei den letzten Tests bin und ungern noch was umfangreiches wie PAM einkleben moechte.
Allgemein bin ich auf jeden Fall nicht abgeneigt PAM einzubauen, moeglicherweise sogar als Teil der Standardinstallation.
Aber ich denke eher in der nachfolgenden Version und nicht mehr in der kommenden, da ich ja jetzt im Grunde schon bei den letzten Tests bin und ungern noch was umfangreiches wie PAM einkleben moechte.
Allgemein bin ich auf jeden Fall nicht abgeneigt PAM einzubauen, moeglicherweise sogar als Teil der Standardinstallation.
Dennis Wronka
Soulcollector
Ich denk allein durch den SELinux-Support kann sich EasyLFS schon von so einigen Distributionen abheben. Denn so viele Distributionen duerften dies auch nicht bieten.
Suse ist nach einem kurzen Zwischenspiel mit SELinux auf AppArmor, welches aber nicht so umfassenden Schutz bietet wie SELinux, umgestiegen und auch bei vielen anderen Distributionen vermisst man es im Auslieferumfang.
Ausserdem bin ich eben auch der Meinung "wenn SELinux, dann auch richtig", also dass es gleich mit dem System installiert wird und auch die Software, soweit noetig, darauf abgestimmt wird.
Und wenn wir dann eben auch noch PAM bieten waer das noch besser.
Ich hab mir auch vorgenommen mich mal etwas mit UDev auseinander zu setzen um noch umfassendere Regeln ausliefern zu koennen sodass z.B. kein zusaetzliches Script mehr noetig ist um beim Systemstart z.B. die USB-Module zu laden und sowas.
Sollte ja eigentlich ueber UDev moeglich sein.
Suse ist nach einem kurzen Zwischenspiel mit SELinux auf AppArmor, welches aber nicht so umfassenden Schutz bietet wie SELinux, umgestiegen und auch bei vielen anderen Distributionen vermisst man es im Auslieferumfang.
Ausserdem bin ich eben auch der Meinung "wenn SELinux, dann auch richtig", also dass es gleich mit dem System installiert wird und auch die Software, soweit noetig, darauf abgestimmt wird.
Und wenn wir dann eben auch noch PAM bieten waer das noch besser.
Ich hab mir auch vorgenommen mich mal etwas mit UDev auseinander zu setzen um noch umfassendere Regeln ausliefern zu koennen sodass z.B. kein zusaetzliches Script mehr noetig ist um beim Systemstart z.B. die USB-Module zu laden und sowas.
Sollte ja eigentlich ueber UDev moeglich sein.
andy72
Erfahrenes Mitglied
hm, soll ich dir was sagen ? ich hab von udev absolut NULL ahnung 
... ich freu mich, wenn es - den letzten kernel, den ich vor deinem 2.6.19 kompiliert habe, war noch aus der 2.4er Reihe ... und da brauchte ich weder udev noch /sys noch /srv, wo ich mich frage, was /srv macht - das verz. ist in allen Distris die hin und wieder mal teste immer leer
...das einzige, was ich über udev weiss ist, dass es wohl hotpug ersetzt *glaub*
... ich freu mich, wenn es - den letzten kernel, den ich vor deinem 2.6.19 kompiliert habe, war noch aus der 2.4er Reihe ... und da brauchte ich weder udev noch /sys noch /srv, wo ich mich frage, was /srv macht - das verz. ist in allen Distris die hin und wieder mal teste immer leer ...das einzige, was ich über udev weiss ist, dass es wohl hotpug ersetzt *glaub*
Dennis Wronka
Soulcollector
/srv ist einfach nur da, und zwar aus dem Grund dem FHS zu entsprechen.
Warum die Distributionen nicht so konsequent sind und es auch mal nutzen anstatt es einfach nur dem Standard zuliebe kann ich aber auch nicht nachvollziehen.
Viel hab ich mit UDev bisher auch nicht gemacht. Ich hab mal eine Regel geschustert die einen SymLink fuer meinen MP3-Stick anlegt, egal welches Device er zugewiesen bekommt, sodass ich eben immer auf /dev/mp3stick zugreifen kann und 2 Regeln fuer meine CD-Laufwerke.
Mit dem Laden von Modulen hatte das alles aber nichts zu tun.
Aber ich hab bei einem Blick auf ein paar Regeln was dazu gesehen und gehe somit davon aus, dass es machbar sein sollte.
/sys finde ich persoenlich uebrigens eine Klasse Sache. Man bekommt dort einen Haufen nuetzlicher Informationen gut sortiert praesentiert. Geplant ist ja scheinbar, dass saemtliche Hardware-Informationen von /proc nach /sys wandern, was im Grunde keine schlechte Idee ist, nur eben noch ein paar Jahrzente dauern duerfte.
Nachtrag: Frueher haben Hotplug und UDev zusammengearbeitet. Seit Kernel 2.6.irgendwas (ich glaub 16) ist Hotplug aber wohl nicht mehr notwendig.
Warum die Distributionen nicht so konsequent sind und es auch mal nutzen anstatt es einfach nur dem Standard zuliebe kann ich aber auch nicht nachvollziehen.
Viel hab ich mit UDev bisher auch nicht gemacht. Ich hab mal eine Regel geschustert die einen SymLink fuer meinen MP3-Stick anlegt, egal welches Device er zugewiesen bekommt, sodass ich eben immer auf /dev/mp3stick zugreifen kann und 2 Regeln fuer meine CD-Laufwerke.
Mit dem Laden von Modulen hatte das alles aber nichts zu tun.
Aber ich hab bei einem Blick auf ein paar Regeln was dazu gesehen und gehe somit davon aus, dass es machbar sein sollte.
/sys finde ich persoenlich uebrigens eine Klasse Sache. Man bekommt dort einen Haufen nuetzlicher Informationen gut sortiert praesentiert. Geplant ist ja scheinbar, dass saemtliche Hardware-Informationen von /proc nach /sys wandern, was im Grunde keine schlechte Idee ist, nur eben noch ein paar Jahrzente dauern duerfte.
Nachtrag: Frueher haben Hotplug und UDev zusammengearbeitet. Seit Kernel 2.6.irgendwas (ich glaub 16) ist Hotplug aber wohl nicht mehr notwendig.
andy72
Erfahrenes Mitglied
naja, bisher nutze ich noch /proc, da ich weiss, wo man was findet ... was udev betrifft, hab ich mich ja schon öfter gewundert, wie das geht, dass mein cdrom automatisch gefunden wird ... ich dachte bis dato immer dran, dass die gucken, welches LW nen cdrom ist und in proc gucken oder im dmeg nen grep veranstalten ... also ist ja udev ne schöne sache, wenn das das ganze scripting ersetzt und man nicht per hand den symlink von /dev/hd? auf /dev/cdrom setzen muss 
was mir gerade dazu einfällt:
Ich hatte was falsch an der config gemacht, als ich mit SELinux gebastelt hatte und init konne keine console mehr öffnen, weil die devices fehlten - konnte das damit umgehen, dass ich per hand in /dev/console und /dev/null mit mknod angelegt habe. vielleicht sollte man vor dem mounten die geräte im bootscript trotzdem anlegen, falls beim boot/mount was schief geht - dann kommt man wenigstens noch bis zum login - so musste ich am lilo "init=/bin/sh" eingeben, um ans system zu kommen
... was udev betrifft, hab ich mich ja schon öfter gewundert, wie das geht, dass mein cdrom automatisch gefunden wird ... ich dachte bis dato immer dran, dass die gucken, welches LW nen cdrom ist und in proc gucken oder im dmeg nen grep veranstalten ... also ist ja udev ne schöne sache, wenn das das ganze scripting ersetzt und man nicht per hand den symlink von /dev/hd? auf /dev/cdrom setzen muss was mir gerade dazu einfällt:
Ich hatte was falsch an der config gemacht, als ich mit SELinux gebastelt hatte und init konne keine console mehr öffnen, weil die devices fehlten - konnte das damit umgehen, dass ich per hand in /dev/console und /dev/null mit mknod angelegt habe. vielleicht sollte man vor dem mounten die geräte im bootscript trotzdem anlegen, falls beim boot/mount was schief geht - dann kommt man wenigstens noch bis zum login - so musste ich am lilo "init=/bin/sh" eingeben, um ans system zu kommen
Dennis Wronka
Soulcollector
/dev/console und /dev/null sollte es eigentlich geben.
Diese werden bei der Installation angelegt da diese, wenn ich mich recht erinnere, schon vor UDev oder von UDev benoetigt werden.
Der Rest wird dann dynamisch angelegt.
Diese werden bei der Installation angelegt da diese, wenn ich mich recht erinnere, schon vor UDev oder von UDev benoetigt werden.
Der Rest wird dann dynamisch angelegt.
Bash:
LFS_JOB="populating /dev"
echo $LFS_JOB
mknod -m 600 /dev/console c 5 1 || LFS_ERROR=1
mknod -m 666 /dev/null c 1 3 || LFS_ERROR=1
. /lfs-install/modules/error.sh
