grafischer Login ohne Loginmanager

OsunSeyi

Well-Known Member
Hallo erstmal,
ich bin sehr erfreut, endlich bei freeBSD gelandet zu sein!

Grund war der freundliche Ton hier im Forum und die Suche nach einem System, was so stabil wie Slackware ist, aber einfacher zu warten (zB upzugraden). Auch funktionieren die Slackbuilds nicht immer wie gewünscht. Ich stelle es mir einfach sehr angenehm vor, sich über die Frage "welches Betriebssystem" nie wieder Gedanken machen zu müssen...

Übrigens war ich etwas verwundert, offenbar bereits unter meiner Email-Adresse hier registriert zu sein, weil ich mich daran nicht erinnern kann, und auch kein Passwort vorliegen hatte. Vielleicht hab ich es ja vergessen... falls es ein Hinweis auf Missbrauch sein könnte, wäre es evtl gut, dem nachzugehen!

Nun zur Frage:

Leider habe ich Slim installiert, was doch zB mit Phyton umfangreiche Abhängigkeiten mitgebracht hat.
Kann ich Slim wieder deinstallieren (ja klar) aber eben auch mitsamt den Abhängigkeiten, die automatisch "mitgeliefert" wurden? Ich würde lieber den sicher schlankeren xdm benutzen. Desktop ist Blackbox.

Weiterhin: da ich eine passwortfreie Anmeldung eingerichtet habe, kann ich nicht durch ein Einfügen von 'startx' an passender Stelle generell auf einen Loginmanager verzichten? Würde ohnehin am liebsten direkt in die grafische starten!

'startx' startet problemlos Blackbox, Slim kann zZt den 'exec blackbox' in der '~/.xsession' nicht finden.
Habe in der 'slim.conf' die Zeile 'sessiondir /usr/local/share/xsessions' auskommentiert, siehe Forums-Beitrag.
Demnach sollte Slim nun in '~/.xsession' schauen, und 'exec blackbox' ausführen...

Aber eigentlich egal, am liebsten Slim wieder raus und ein einfaches 'startx' an passender Stelle in den Init-Scripten!

mit vielen Grüßen,
tom
 
Kann ich Slim wieder deinstallieren (ja klar) aber eben auch mitsamt den Abhängigkeiten, die automatisch "mitgeliefert" wurden? Ich würde lieber den sicher schlankeren xdm benutzen.

Code:
pkg remove slim          # Entfernt slim
pkg autoremove           # Entfernt ALLE zurueckgebliebenen Abhaengigkeiten die automatisch 
                         # mitinstalliert wurden aber nicht mehr benoetigt werden (nicht nur von Slim, sondern generell alle)
pkg clean                # Entfernt alte, heruntergeladene Pakete, die nicht mehr benoetigt werden

Einzig Konfigurations-Dateien koennten dann noch uebrig bleiben...die aber manuell problemlos geloescht werden koennen.
 
Leider habe ich Slim installiert, was doch zB mit Phyton umfangreiche Abhängigkeiten mitgebracht hat.
Kann ich Slim wieder deinstallieren (ja klar) aber eben auch mitsamt den Abhängigkeiten, die automatisch "mitgeliefert" wurden? Ich würde lieber den sicher schlankeren xdm benutzen.
grundsätzlich über pkg delete und anschließend pkg autoremove.
Allerdings ist bei FreeBSD das Paket-Management immer noch "ziemlich neu" und ich habe mit Automatismen auch schon negative Erlebnisse gehabt. Deshalb an dieser Stelle der Rat, genau hinzusehen und Snapshots mit ZFS zu pflegen und generell nicht davon auszugehen, dass man immer alles richtig macht, sondern immer geeignete Vorsichtsmaßnahmen treffen.

Weiterhin: da ich eine passwortfreie Anmeldung eingerichtet habe, kann ich nicht durch ein Einfügen von 'startx' an passender Stelle generell auf einen Loginmanager verzichten? Würde ohnehin am liebsten direkt in die grafische starten!
Das ist eine interessante Frage. Kurze Zeit hatte ich mich für solche Szenarien auch interessiert, sie aber nie probiert.
Deshalb weiß ich gar nicht, wie eine "passwortfreie Anmeldung" funktioniert.
Man kann in /usr/local/etc/rc.d/ ein ausführbares script hinterlegen, dass auch zur Bootzeit ausgeführt wird oder etwas in /etc/rc.local machen (afaik), aber dann muss man das ja mittels su innerhalb des Scripts dem User zuschreiben und ich weiß nicht, ob das alles gut geht. X würde dann auf der "aktuellen Konsole" gestartet werden.

Ich selbst nutze OpenBox und die berücksichtigt beim Start eine ~/.config/openbox/autostart.sh. Wenn du also schon eine PW-freie Anmeldung hinbekommen hast, könnte das vielleicht eine gute Möglichkeit sein, falls es das für BlackBox auch gibt (wovon ich mal ausgehe).

Mit XDM kannst du allerdings (vielleicht) ein wenig flexibler sein und hast keinen großen Abhängigkeitskatalog.
Ich nutze es gerne in FreeBSD.
In der /etc/ttys legst du fest, wo xdm starten soll. So brauche ich selbst etwa keine acht "Terminals" und starte deshalb xdm auf ttyv4, was mir ausreichende Möglichkeiten lässt, falls X mal nicht genügt und ich doch eine Ebene tiefer ansetzen muss.
Allerdings lernte ich, dass nicht alle Grafikkarten das überhaupt noch richtig hinbekommen mit FreeBSD. Mit meinem Laptop funktioniert das Umschalten zur Konsole auch bei aktivem Grafik-Modus gut und ich kann auch wieder zurück, aber auf dem PC kann ich bisher (ich habe mich nicht weiter dafür interessiert) die Konsolen nur dann wirklich nutzen, wenn zuvor kein X geladen wurde.
 
....und Snapshots mit ZFS zu pflegen und generell nicht davon auszugehen, dass man immer alles richtig macht, sondern immer geeignete Vorsichtsmaßnahmen ...

Ganz genau! Snapshots, snapshots und nochmal sbapshots!
Nichts erleichtert das Leben mehr als der Einsatz solch genialer Möglichkeiten.
Ich glaube, dass viele Benutzer von zfs sich gar nicht klar sind, welche Möglichkeiten zfs bietet - und das diese Dinge noch viel zu wenig genutzt werden.
 
Übrigens war ich etwas verwundert, offenbar bereits unter meiner Email-Adresse hier registriert zu sein, weil ich mich daran nicht erinnern kann, und auch kein Passwort vorliegen hatte. Vielleicht hab ich es ja vergessen... falls es ein Hinweis auf Missbrauch sein könnte, wäre es evtl gut, dem nachzugehen!

Du bist seit dem 17. November 2007 registriert. Das kann ich unmöglich noch nachvollziehen. Da liegen unter anderem 2 Wechsel der Forensoftware (vBulletin 3 -> Xenforo 1 -> Xenforo 2) zwischen... Allerdings musste man auch damals schon die Mailadresse bestätigen. Einfach irgendjemanden zu registrieren sollte eigentlich nicht möglich gewesen sein.

Aber eigentlich egal, am liebsten Slim wieder raus und ein einfaches 'startx' an passender Stelle in den Init-Scripten!

Ich würde es im Login-Script der Shell machen. Also ~/.login für die tcsh, ~/.bash_login für die Bash und so weiter. Dann in etwa so (ungetestet):
Code:
pgrep Xorg >/dev/null 2>&1

if [ $? -ne 0 ] ; then
    /usr/local/bin/startx &
fi
 
Im Moment bin ich etwas, naja, angepisst...

Also, zum passwortfreien Anmelden:
Deshalb weiß ich gar nicht, wie eine "passwortfreie Anmeldung" funktioniert.
Das war grundsätzlich eine Option beim Installationsvorgang, sehr angenehm.
Ein passwortfreier grafischer Login ist auch in der 'slim.conf' vorgesehen, hab's aber nicht probiert!

Also, hab bisher folgendes versucht:

1)
Im Forum ist hier "autologin and auto run X server" nach einem starten von X ohne Loginmanager gefragt worden:

Code:
I usually just create and add to /etc/rc.local
Code:
su -l myusername -c /usr/local/bin/startx &

Genau das habe ich probiert, ist ja naheliegend, da 'startx' bei mir tatsächlich X und 'blackbox' startet.
In der '/etc/rc.conf' vorher slim_enable="YES" entfernt.
Hat aber X nicht gestartet, ich habe nur den Login-prompt erhalten.

2)
Mit 'slim' einloggen mit der im Forum "Slim - failed to execute login command" beschriebenen Methode:

Code:
But if you want to start your session with ~/.xinitrc,
then comment this line in /usr/local/etc/slim.conf:

#sessiondir        /usr/local/share/xsessions

So getan, eine ausführbare '~/.xsession' erstellt mit dem Eintrag exec blackbox und rebootet.
Slim wird aufgerufen, einloggen bringt die bekannte Fehlermeldung 'failed to execute login command'...

3)
XDM installiert und laut Manual 5.6.1. XDM einrichten:
Nach der Installation lässt sich XDM durch einen Eintrag in /etc/ttys bei jedem Start des Rechners aktivieren:

ttyv8 "/usr/local/bin/xdm -nodaemon" xterm off secure

Ändern Sie den Wert off zu on und speichern Sie die Datei. ttyv8 zeigt an, dass XDM auf dem neunten virtuellen Terminal ausgeführt wird.

In der Tat erscheint xdm, aber ein Einloggen sowohl als root oder user wird mit der Meldung
Code:
Login incorrect ore forebidden by policy
quittiert.

Im Grunde würde ich am liebsten mit 'xdm' einloggen, die Frage ist nur, was hier falsch ist.
Hauptproblem ist, dass ich trotz der kleinen Konsole unten rechts gar nicht aus Xdm herauskomme, ich schaffe es nicht, den Fokus dorthin zu bekommen. Also kann ich mich zur Zeit überhaupt nicht anmelden.

Methode 1 (ganz ohne Loginmanager) wäre auch chick, aber hat ja auch nicht geklappt...
Hilfe!

Ps: übrigens schaffe ich es auch nicht, mich vom Bootmanager aus nichtgrafisch einzuloggen...
Wenn ich als 'single-user' boote, ist '/etc/ttys' nicht editierbar. Also wie jetzt überhaupt einloggen???
 
Im Grunde würde ich am liebsten mit 'xdm' einloggen, die Frage ist nur, was hier falsch ist.

/var/log/xdm.log

im Ubuntu-Wiki nachsehen, das ist recht gut erklärt, aber die nutzen natürlich andere Pfade.

Spontan: Tastur-Unverträglichkeit zwischen Konsole und X: die haben eigene Konfigurationsdateien und wenn eine auf DE steht die andere aber auf default=US, kann das Probleme machen.

Bin derzeit leider sehr angespannt und in anderen Dingen unter Wegs. Deshalb hier auch nur kurz.
Außerdem: ich habe ja keine Ahnung!
Aber du kannst hier Beiträge finden, die etwa lauten "alles in Deutsch" oder so. Hoffentlich findest du da dann Anhaltspunkte, die dich weiter bringen.
Buchstaben, die verwechselt werden könnten, sollte man deshalb zunächst mal nicht verwenden, das schließt diese Ursache dann schon mal aus.

Ansonsten sind die Grundlagen im FreeBSD-Handbuch erklärt: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x11.html
 
Spontan: Tastur-Unverträglichkeit zwischen Konsole und X: die haben eigene Konfigurationsdateien und wenn eine auf DE steht die andere aber auf default=US, kann das Probleme machen.

Jupp, Anmeldung mit root und Passwort (y mit z vertauscht) klappt. Landet aber auch wiederum im Login-Manager, möglicherweise weil für root keine .xsession angelegt ist (frei geraten).

Die passwortfreie Anmeldung für user mit leerem Passwort scheint xdm nicht zu gefallen...

Anmelden geht doch: Strg+Alt+F1 öffnet eine Konsole.
Werde mir mal /var/log/xdm.log anschauen...

Wünsch' Dir einen angenehmen Abend!
 
Also ok..
hab's vorerst aufgegeben.

Mit 'startx' startet nicht blackbox, sondern twm
mit Slim hab ich es nicht hinbekommen:

Passwortfreies einloggen in der 'slim.conf' zu konfigurieren ist kein Problem, aber exec blackbox in der (chmod a+x) '~/xinitrc' wird nicht ausgeführt.
In der 'slim.conf' ist nun eingetragen:
Code:
login_cmd           exec /bin/sh - ~/.xinitrc
# weiter unten:
# sessiondir        /usr/local/share/xsessions
Wie gesagt: failed to execute login command

Login mit xdm hat auch nicht geklappt....
Bin jetzt seit mind. 5 Stunden dabei, und habe Blackbox noch nicht mal zu Gesicht bekommen...
 
Im Moment bin ich etwas, naja, angepisst...
Lasse dihc nicht frustrieren. :) EInfach mal ein paar Stunden Abstand, rausgehen oder einfach was anderes machen. Das hilft.

Wenn ich als 'single-user' boote, ist '/etc/ttys' nicht editierbar. Also wie jetzt überhaupt einloggen???
Im Single User Mode ist das Dateisystem read only gemountet. Du kannst es aber jeder Zeit read write mounten: mount -u -o rw /

Der Weg von @bluescreen wird funktionieren. Der Trick dort ist die al-Direktive für getty. Alle anderen Wege, die du bisher probiert hast, hatten keine wirkliche Chance. Denn bevor irgendwas funktioniert, muss erst einmal eine User-Session zustandekommen und dafür brauchst du irgendeine Form von Login-Manager. Auf der Shell wird dafür normalerweise die Kombination aus eben getty und login benutzt, graphische Login-Manager implementieren es meist selbst.
 
Wie hier schon gesagt wurde musst du erst mal sicherstellen, dass ein Login grundsätzlich über den Weg möglich ist den du versuchst. Danach dann den Autologin einstellen.
Zur Vollständigkeit noch ein kleiner Hinweis, dass an Slim schon länger nix mehr passiert ist. Keine Ahnung ob der an sich noch gepflegt wird. Ich habe erst vorgestern ein Autologin über SDDM eingerichtet und das war sehr schmerzfrei muss ich feststellen (einfach die /usr/local/etc/sddm.conf anpassen - steht auch in der manpage zu sddm.conf). Ja SDDM zieht dir ein paar QT5-Abhängigkeiten rein (wobei ich das noch übersichtlich fand).
 
Habe XDM bei mir wie folgt konfiguriert.

Tastatur-Layout für Xorg korrekt setzen:
Code:
#/usr/local/etc/X11/xorg.conf.d/90-keyboard.conf
Section "InputClass"
        Identifier "keyboard"
        MatchDevicePath "/dev/kbdmux"
        Driver "kbd"
        Option "Protocol" "standard"
        Option "XkbRules" "base"
        Option "XkbModel" "pc105"
        Option "XkbLayout" "de"
        Option "config_info" "devd:kbdmux"
EndSection

Im Home-Verzeichnis folgendes durchführen:
Code:
echo "exec openbox-session" > ~/.xinitrc
ln -s ~/.xinitrc ~/.xsession

Xorg support
Code:
#/etc/rc.conf
hald_enable="YES"
dbus_enable="YES"

Editiere /etc/ttys und aktiviere folgende Zeile:
Code:
ttyv8 "/usr/local/bin/xdm -nodaemon"  xterm   on secure

Fehlermeldung werden im ~/.xsession-errors gesammelt, gibt somit Aufschluss im Falle von weiteren Problemen.
 
Hi again,

Lasse dich nicht frustrieren. :)
Cool, vielen Dank für den Zuspruch!

BTW, schreibe von freeBSD aus, dank Eurer Hilfe...
...und möchte kurz resümieren:

"autologin and auto run X server"
Code:
I usually just create and add to /etc/rc.local Code: su -l myusername -c /usr/local/bin/startx &

Wie dort ebenfalls beschrieben, funktioniert das besser mit:
Code:
in /etc/rc.local:
/root/autologin.sh

dort:
sleep 5
su -l myusername -c /usr/local/bin/startx &

Ohne das sleep 5 hat man in X keine Tastatureingabe...

Ob das alledings ein eleganter Weg ist, oder der von Yamagi bzw Bluescreen beschriebene Weg besser ist, weiß ich in gnädiger Unkenntnis nicht. Auf jeden Fall klappt es ja, wenigstens.

Also wäre das meine erste Frage, ob Ihr diese Methode für ok haltet, oder mit Nachteilen behaftet?
Alle anderen Wege, die du bisher probiert hast, hatten keine wirkliche Chance

Weiterhin:
Code:
~/xinitrc:
#
#  Sprache und Keyboardlayout:
    export LANG=de_DE.UTF-8
    setxkbmap de

#  'xrdb' lädt die Einstellungen in 'Xresources':
    xrdb -load .Xresources

#  Programme, die beim Start von X mitgestartet werden (Pager etc):
    /usr/home/tom/CONFIG/USER/AUTOSTART &

#  Openbox starten:
    exec /usr/local/bin/openbox

Eine Xsession wird dafür nicht gebraucht, anscheinend auch kein Eintrag enable_openbox="YES"in "rc.conf".

Und schon die zweite Frage:
b4lr0g hat geschrieben, man solle Openbox mit openbox-session starten. Hat das Vorteile?

Weiterhin:

Beim booten will sich die Kiste unbedingt mit dem Wlan verbinden, daß hier aber oft nicht funktioniert.
Ich glaube, dafür ist 'wpa-supplicant' verantwortlich. Jedenfalls kommt es immer wieder vor, daß sich der Bootvorgang dadurch unschön verlängert, bzw 'wpa-supplicant' (?) einfach nicht aufhört, zu suchen...

Ich würde es besser finden, wenn sich BSD erst nach dem Start von X (zB in der von mir in xinitrc eingebundenen 'AUTOSTART') mit dem Wlan verbinden wollte. Wie kann ich das am Besten bewerkstelligen?

Und zuletzt quasi als Anmerkung:

Auf der Suche nach einem schlanken Browser war ich erfreut, auf Midori in einer mir unbekannten, aufgeräumten GTK-3 Fassung zu stoßen, die sich leider als unbrauchbar erwiesen hat, weil sich kein Bookmark-Menü finden ließ, und er beim Öffnen neuer Tabs gerne abstürzt. So ist es nun doch der für einen Thinkpad T60 überdimensionierte FF geworden...

Habt Ihr andere Erfahrungen oder einen anderen schlanken Browser? Wollte nicht unbedingt extra QT4 installieren...
Vivaldi war gelobt worden.

Bisher auf jeden Fall vielen Dank...!

Ps:
Ja, BSD ist ungewohnt. Besonders irritierend, daß sich $HOME und ~ auf /home/tom (ja, das bin ich ;)) beziehen, und nicht auf /usr/home/tom.

Ist das eine Notwendigkeit (zB aus Kompatibilitätsgründen)? Man muss aufpassen mit Softlinks, die nach $HOME nicht gültig sein werden, weil dieses ja selber schon ein Link ist...
 
Zuletzt bearbeitet:
Ob das alledings ein eleganter Weg ist, oder der von Yamagi bzw Bluescreen beschriebene Weg besser ist, weiß ich in gnädiger Unkenntnis nicht. Auf jeden Fall klappt es ja, wenigstens.
Jau, das geht tatsächlich auch. In deinem Fall macht su die Login-Session für dich auf.

Vivaldi war gelobt worden.
Als alter Opera-Fan fände ich es wunderbar, wenn Vivaldi auf FreeBSD laufen würde. Aber auch wenn die Entwickler mehrmals gesagt haben, dass es irgendwann kommen wird, glaube ich ehrlich gesagt nicht daran. Denn Vivaldi hat im Moment zu viele andere Baustellen, als das sie groß Zeit für eine Randgruppenplattform, die ihnen wahrscheinlich nicht mal 100 zusätzliche Nutzer bringen würde, investieren könnten. Da ist zum Beispiel mit einem Ausbau der gerade als erste Beta erschienen Android-Variante oder dem ebenfalls lange versprochenen Mailclient M3 viel mehr zu holen.

Außerdem ist Vivaldi auf Chromium basierend. Chromium selbst unterstützt FreeBSD offiziell nicht, es muss aufwändig portiert werden. Dafür ist diese Patchwüste notwendig: https://svnweb.freebsd.org/ports/head/www/chromium/files/ Und ich glaube nicht, dass man sich als recht kleiner Anbieter das dauerhaft antun will.

Aber siehe es so. Wenn das alte Thinkpad Firefox nicht stemmen kann, wird es auch keinen auf Chromium basierenden Browser sinnvoll ausführen können. Die beiden Familien nehmen sich meiner Erfahrung nach in Sachen Ressourcenverbrauch und geschwindigkeit unter dem Strich nichts. Firefox braucht etwas mehr CPU-Power, Chromium dafür mehr RAM. das einzige Argument für Chomium ist, dass es auch auf X11 sinnvolle GPU-Beschleunigung kann. Firefox bekommt das hoffentlich endlich 2020 mit der flächendedeckenden Einführung von Webrenderer. Nur hat das alte T60 eh keine dafür geeignete GPU.

Ja, BSD ist ungewohnt. Besonders irritierend, daß sich $HOME und ~ auf /home/tom (ja, das bin ich ;)) beziehen, und nicht auf /usr/home/tom.

Ist das eine Notwendigkeit (zB aus Kompatibilitätsgründen)? Man muss aufpassen mit Softlinks, die nach $HOME nicht gültig sein werden, weil dieses ja selber schon ein Link ist...
Das ist historisch bedingt. Es ist egal, ob $HOME auf /home/xyz oder /usr/home/xyz zeigt. Wichtig ist nur, dass es auf das reale Verzeichnis zeigt und es einen Symlink in die Gegenrichtung gibt. Anderereits dürfte sich moderne Software daran generell eher nicht mehr verschlucken.
 
Auf der Suche nach einem schlanken Browser
bin ich zuletzt auf cliqz gestoßen (www/cliqz). Nutze ihn mal zeitweise, aber nicht ständig und intensiv, weshalb ich nicht sagen kann, wie gut er läuft. Wie viele Abhängigkeiten er alleine hat, weiß ich grad nicht. Es kam mir wenig vor, aber ich habe auch den FF installiert und stelle mir vor, dass da manche Abhängigkeiten gleich sind.
Aus unerfindlichen Gründen setzt Claws-Mail nun auf dillo, der auch in den Ports ist (www/dillo2). Der ist schnell und für mich eigentlich unbrauchbar, was aber vielleicht auch an meinen Einstellungen liegen könnte.
@ralli (der sich nun scheinbar auch hier abgemeldet hat), hatte mal einen eigenen Browser auf Qt5 Basis erwähnt und erklärt, wie einfach und schnell so etwas zu erstellen ist. Natürlich, wenn man kein Qt5 sowieso installiert hat, ist das ja eher eine große Abhängigkeit.

https://wiki.ubuntuusers.de/Internetanwendungen/
nennt und erklärt einige weitere, die aber natürlich nicht alle für FreeBSD gelten.
 
Habe cliqz jetzt in Benutzung, ist FF schon sehr ähnlich.

Midori lief in der Gtk-2 Version auf Salix super (wenn auch manche Seiten nicht korrekt dargestellt wurden, wg der veralteten engine). Warum die Bsd-Version in meiner Installation so buggy ist, weiß ich nicht. Vielleicht fehlt ja einfach eine Abhängigkeit , da die Bookmarks ja nicht funktionieren wollen.

Auf Salix verwende ich Qupzilla (Qt4), der sehr flott ist. Für Seiten, die der nicht anzeigt, FF.

Dillo gibt's auch im Repository, er kann mittels der dillorc so konfiguriert werden, daß der Seitenhintergrund hell ist usw, auch ohne Panels als reiner Textbrowser. Ich benutze ihn zum offline -Browsen im heruntergeladenen
Handbuch.

WIFI

Beim booten will sich die Kiste unbedingt mit dem Wlan verbinden, daß hier aber oft nicht funktioniert.

Kann ich das unterbinden?
Ich würde das Wlan im Zweifelsfall lieber händisch verbinden, und möchte gerne, das die Kiste schneller bootet!

BTW gab es im Zuge des Installationsvorganges ein kleines Konsoleprogramm, das die verfügbaren Netzwerke anzeigt und eine Auswahl ermöglicht. Daher sollte die Verwendung eines grafischen Managers wie wifimgr eigentlich nicht nötig sein!
 
Zuletzt bearbeitet:
Kann ich das unterbinden?
Ich würde das Wlan im Zweifelsfall lieber händisch verbinden, und möchte gerne, das die Kiste schneller bootet!

Also, ganz von selbst sollte sich eigentlich kein Rechner mit einem LAN oder WLAN verbinden. Dazu sind ja die Einträge in der /etc/rc.conf vorhanden.
Und ich denke, wenn die nicht vorhanden sind, startet da auch kein Verbindungsversuch.
Ansonsten lies mal, wie FreeBSD bootet: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-introduction.html
Code:
pit@Celsius ~:- > cat /etc/defaults/rc.conf | grep netif
netif_enable="YES"        # Set to YES to initialize network interfaces
netif_ipexpand_max="2048"    # Maximum number of IP addrs in a range spec
das bedeutet, dass ein Eintrag netif_enable="NO" den Eintrag aus default überschreiben müsste und somit gar kein "Netzwerk" zur Bootzeit gestartet wird. Dann kann man alles später manuel machen, inklusive des Starts von netif (/etc/rc.d/netif).

Code:
networkmgr-3.1                 FreeBSD/GhostBSD network conection manager
starte ich in meiner autostart als User als grafischen Netzwerkmanager. Der bettet sich in meinem Panel ein und kann mittels Maus einige Dinge veranlassen. Eines dieser Dinge ist "disconnect from Network". Ich vermute, dass es nach einem disconnect dann auch wieder ein "connect" geben wird. Ob das dann aber automatisch auch ein netif starten wird (netif restart etwa), kann ich nicht sagen.

Da gibt es also für dich einiges herauszufinden (und natürlich am Besten in einem neuen und passenden Thread).
Ganz generell war ich einigermaßen erstaunt um nicht zu sagen erschrocken, als ich bei einem Ausflug in die Ubuntu-Welt erlebte, dass hier das Netzwerk erst nach Einloggen des Users aktiviert wird und unter dessen Regie erfolgt.
Für mich (und FreeBSD) war Netzwerk System-Sache. Ich brauche doch zur Bootzeit meine entfernten Laufwerke, auf denen ja System-relevante Daten liegen können. Da kann ich nicht warten, bis ein Nutzer sich einloggt. Oder etwa die Systemzeit über ntp.
Wenn ich aber in Richtung mobiler Endgeräte denke, dann wird das Konzept des Nutzer-regierten Netzwerks sinnvoll. Ein mobiles Gerät ist in unterschiedlichen Netzen zu Hause und wird nicht in jedem immer alle Freigaben zur Verfügung haben, weshalb System-relevante Daten nicht auf Netz-Laufwerken realisiert werden können.
Deshalb ist das hier nicht ganz OT. Es geht um einen kleinen Paradigmen-Wechsel im Denken mit FreeBSD.
Unix-Systeme sind Multi-User-Systeme und (natürliche) User müssen sich einloggen. Mit dem von dir realisierten automatischen Einloggen, könnte jeder sich an deinen PC setzen und als DU damit arbeiten. Das ist in der traditionellen Unix-Welt nicht vorgesehen. (In einem deiner Beiträgte glaubte ich sogar zu lesen, dass du nicht als DU sondern als ROOT grafisch einloggst. Wahrscheinlich habe das im überfliegen der Zeilen falsch verstanden. ROOT loggt niemals grafisch ein!, meiner Meinung nach).
Nun, die erwähnte Tradition wurde begründet, als nicht jeder Nutzer einen eignen PersönlichenComputer hatte. Heute hat jeder mehrere PCs. Und, als PCs noch Rechner hießen und niemand daran dachte, dass diese mal transportiert werden könnten und innerhalb weniger Sekunden innerhalb vollkommen unterschiedlicher Umgebungen und Netzwerke genutzt werden könnten. Und zwar, während solch ein PC gerade mal schlafen gelegt wurde (OK, an solche Konzepte dachte damals natürlich auch noch niemand), sodass er in einer vollkommen neuen Umgebung aufwachen kann/muss.
Das umreißt vielleicht kurz, weswegen Viele FreeBSD (auch) nicht für Desktop-ready und schon gar nicht für Laptop-ready halten.
GNU/Linux entstammt natürlich den gleichen Ursprüngen, aber hier haben viele Entwickler sich bemüht, Distributionen so anzupassen, dass sie einem modernen Endnutzer gerecht werden. Dafür unternehmen sie gelegentlich Anstrengungen, die soviel Energie und Man-Power verbrauchen. dass damit mehrere neue FreeBSD-Versionen programmiert werden könnten. Vielleicht nur, um einen neuen Netzwerkmanager unter der Regie eines einfachen Users (und nicht des Sysadmins) zu realisieren.

FreeBSD hat nicht die Man-Power und nicht die gleichen Ziele. Es bleibt schon deshalb recht konservativ (was mir ausgezeichnet gefällt). Die Entwicklung hat andere Schwerpunkte, nicht den Endanwender mit einem Laptop und dem Wunsch nach einer Desktop-Umgebung, die dauernd wechselnden Umgebungen (also Netzwerken) gerecht wird und auch noch die Batterie schont.
In der Folge gibt es keine generalisierten Lösungen, wie sie von GNU/Linux-Distributionen üblicherweise (zu Hauf) geschaffen wurden. Hier können nur individuelle Lösungen gefunden werden und das heißt nun mal, dass das auch jeder für sich selbst und seine Situation finden muss und dass diese dann nicht auf andere Situationen übertragbar ist.
Trotzdem sind sicher alle Nutzer dankbar, wenn diese Lösungen auf individuelle Anforderungen und Bedürfnisse öffentlich kommuniziert werden (wie du das auch tust).
Der besseren Übersichtlichkeit halber sollten dann aber unterschiedliche Themen in unterschiedlichen Threads landen. Nicht jeder, der vielleicht ein Nutzer-abhängiges Netzwerk will, wird unter "grafischer Login ohne Loginmanager" suchen.

Für mich selbst habe ich übrigens entschieden (vielleicht aus purer Bequemlichkeit), mit den alten FreeBSD-Pradigmen zu leben und nichts zu ändern, auch nicht für meinen Laptop mit FreeBSD. Einen längeren Bootvorgang kann ich verschmerzen und eine misslungene automatische Verbindung ist im Bedarfsfall leicht manuell zu setzen. Im Gegenzug kann ich FreeBSD "von der Stange" nehmen, muss nicht bei allen Updates immer wieder kontrollieren, ob meine Sonderlösungen auch konform sind, noch funktionieren und noch ausreichend sicher sind.
Obwohl bei mir zumindest der ACPI S3 auf Lid-Switch gut funktioniert, habe ich ihn mir vollkommen abgewöhnt. Ich spare dadurch vielleicht 30 Sekunden oder so. Beim Booten macht das System aber so viele gute Sachen (inklusive meiner Boot- und Sync-Scripts), dass ich das lieber jedesmal laufen lasse (wodurch der Sync-Aufwand auch aus kleineren Inkrementen besteht und die Bootzeiten schon deshalb für mich überschaubarer bleiben).
 
Code:
pit@Celsius ~:- > cat /etc/defaults/rc.conf | grep netif
netif_enable="YES"        # Set to YES to initialize network interfaces
netif_ipexpand_max="2048"    # Maximum number of IP addrs in a range spec
Mein Beitrag trägt nichts zu Sache bei. Da mir das aber auch ständig passiert und ich danach jedes mal schmunzeln muss, wie "doof" ich bin:
Code:
grep netif /etc/defaults/rc.conf
reicht aus. Hier "cat" einzusetzen macht einfach keinen Sinn. :)

Nichts für ungut. :)
 
reicht aus. Hier "cat" einzusetzen macht einfach keinen Sinn. :)

Nichts für ungut.
stimmt natürlich und ich will mich da auch nicht herausreden. Das ist eine doofe Angewohnheit und rührt einfach daher, dass ich mit cat die Autovervollständigung der shell benutze um zu meiner Datei zu kommen und sie dann erst voll anzusehen. Blicke ich sofort, was ich suche, ist ja gut. Wenn es zu unübersichtlich ist, pipe ich einfach ein grep hinterher und extra für einen Beitrag hier, wollte ich das nicht verschönern und neu tippen. Habe es halt falsch gelernt und solche Angewohnheiten legt man nicht mehr leicht ab.
Ist aber gut, wenn dann darauf hingewiesen wird, damit nicht Andere einfach den Blödsinn nachahmen.
 
Tipp am Rande: Redirection macht die Shell und der ist es egal, an welcher Stelle des Befehls das passiert. Wenn man also erst eine Datei ansehen und dann was greppen will, geht auch

Code:
< $datei cat
< $datei grep foo
 
Habe es halt falsch gelernt und solche Angewohnheiten legt man nicht mehr leicht ab.

Ich scripte gerne, und bin dabei ein ziemlicher Anfänger geblieben. Alles muss mit Linien unterteilt sein, und bestens kommentiert. Ich glaube, Richard Stallman hat irgendwo geschrieben, man müsse so kommentieren, als wenn ein Blöder das später lesen soll... Ich kann das nur bestätigen, nach einem Jahr versteh' ich mein eigenes Geschreibsel in der Regel nicht mehr. In dem Zusammenhang ist ein:

Bash:
cat $FILE                                   |\
                                             \
# hier kommt das weitere:
                                             \
        grep 'blub'                         |\
        sed 's/hallo/du/g'                   \
                                             \
# nein, wir sind nicht blöd :)
                                             \
        > FILE_1

...doch schön übersichtlich!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In einem deiner Beiträgte glaubte ich sogar zu lesen, dass du nicht als DU sondern als ROOT grafisch einloggst. Wahrscheinlich habe das im überfliegen der Zeilen falsch verstanden.

Ja, hast Du! Während des Installationsvorganges gab es unmittelbar vor setzen des User-Passwortes die Möglichkeit "empty Password" zu setzen, und ich konnte nach Eingabe meines Accout-Namens die Passwortabfrage tatsächlich leer mit Enter bestätigen. Also ist kein User-Passwort angelegt worden.

Tatsächlich habe ich im OB-Menü den Eintrag sudo shutdown -p now eintragen und er wird ohne weiteres akzeptiert. Ja, natürlich tom ALL=(ALL) ALL wurde gesetzt.

Genauso kann ich im Rox-Filer unter 'senden an' ein Script sudo rox $1 setzen und damit jederzeit ein Verzeichnis als root öffnen. Aber ich lege unter root eine gtkrc-2.0 an, in der ich den Hintergrund hellrot färbe. Zur Sicherheit. Ich finde sowas sehr angenehm! Ab einem bestimmten Punkt, wenn alles eingerichtet ist, braucht man sowieso nicht mehr oft den Root-Account.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
FreeBSD ... bleibt schon deshalb recht konservativ (was mir ausgezeichnet gefällt).

Ja, lieber kontinuierlich bei einer Sache bleiben, als sich dauern auf Neues einstellen müssen.
Bei Slackware werden nur Sicherheitsupdates eingespielt, und das 8 lange Jahre.
Das ist (speziell bei meinem ultra-langsamen Internet hier in den Walachuten) sehr, sehr angenehm!

Andererseits: Viele Webseiten werden mit Html-5 auf meinem SL 13.37 nicht mehr korrekt dargestellt, weil für die installierte Firefox-Version schon lange keine Updates mehr verfügbar sind, und eine neuere Version nicht so leicht zu installieren ist. Gtk-3 ist mal überhaupt noch nicht drauf.

Das wird mir dann alles zu kompliziert und ich hoffe, das freeBSD genauso konservativ ist, aber dabei leichter aktuell zu halten und praxisorientierter. Ganz abgesehen vom Forum hier :):rolleyes:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Der besseren Übersichtlichkeit halber sollten dann aber unterschiedliche Themen in unterschiedlichen Threads landen.

Jupp!
 
Zuletzt bearbeitet:
In dem Zusammenhang ist ein:

Bash:
cat $FILE                                   |\
                                             \
# hier kommt das weitere:
                                             \
        grep 'blub'                         |\
        sed 's/hallo/du/g'                   \
                                             \
# nein, wir sind nicht blöd :)
                                             \
        > FILE_1

...doch schön übersichtlich!

Das sieht nicht nur grauenhaft aus, das funktioniert nicht mal. Das Beispiel da gibt mir den Output von sed auf stdout aus und legt eine leere Datei FILE_1 an. (Edit: Der Bonus-Witz ist, dass nicht mal ersichtlich ist, warum es nicht funktioniert. In Zeile 3 fehlt genau wie in der anderen Kommentarzeile am Ende der Backslash. Die Mechanik sieht an beiden Stellen gleich aus, aber die Pipe von cat zu grep funktioniert komischerweise noch, die Redirection von sed zu FILE_1 dagegen nicht mehr. Da müsste man erstmal Man-Page lesen, was jetzt überhaupt an der Stelle abgeht in der Shell. Ein furchtbares Beispiel.)

Das Pipe-Zeichen am Ende der Zeile zu "verstecken", zerstört jegliche Übersicht darüber, was die Pipe jetzt alles umfasst. Die Einrückungen sind dann nur dazu da, irgendwie noch Lesbarkeit reinzubringen, aber vergeblich.

Das ist ein fürchterliches Beispiel, wenn ich beim Escapen noch anfangen muss, Bugs zu suchen.

Ausufernde Pipes sehen bei mir deshalb so aus:

Code:
cat bla \
| grep \
| sed \
> blubb

Man sieht direkt am Anfang der Zeilen, wie der Fluss ist und vor allem funktioniert es.
 
Code:
    ~~~~~~~~~~snip
echo 'blub'                                 |\
                                             \
# hier kommt das weitere:
                                             \
        grep 'blub'                         |\
        sed 's/blub/pip/g'                   \
                                             \
# nein, wir sind nicht blöd :)
                                             \

    ~~~~~~~~~~snip

$ ./N*
pip

Funktioniert hier schon, der Kommentar muss (darf) nicht einen Backslash bekommen.

Es ging ja nur darum, das 'cat' in der nutzlosen Form für solche wie mich, die mit gefährlichem Halbwissen um sich schmeißen, hilfreich sein kann...

Weil ich es in der Form übersichtlicher finde, auch dann, wenn das Pipe-Zeichen am Ende der Zeile steht.

Hab mir das so angewöhnt, und ein guter Stil ist es ganz sicher nicht.
Übrigens hast Du recht, wie Du es schreibst ist es deutlich schöner.
 
Zuletzt bearbeitet:
Zurück
Oben