[gelöst] Änderungen beim/nach dem Start "gewünscht"

[TomL]

Moin

Ich habe gerade meinem alten Asus Minitower ein neues Jessie und die Xfce gegönnt. Jetzt sind mir 2 Dinge aufgefalllen, die ich gerne ändern würde:

1. Grub wartet höchstens 3 Sekunden, bis er durchmarschiert. Kann ich das irgendwie auf 5 oder 10 Sekunden erhöhen? (Da ist auch noch Windows drauf, welches z.Zt. noch für das Steuerprogramm gebraucht wird.)

2. Gibts eine Möglichkeit, dass der Xfce-Login-Screen den zuletzt angemeldeten User anzeigt? Ich muss jetzt der Chefin nahebringen, dass sie sich künftig an Debian gewöhnen soll. Und ich würde gerne Gemecker von vornherein unterbinden.... .... sie soll sich erst gar nicht an Kleinigkeiten aufhängen....

[debianoli]

1. Grub wartet höchstens 3 Sekunden, bis er durchmarschiert. Kann ich das irgendwie auf 5 oder 10 Sekunden erhöhen? (Da ist auch noch Windows drauf, welches z.Zt. noch für das Steuerprogramm gebraucht wird.)

Das stellst du in /etc/default/grub ein:

Code: Alles auswählen

GRUB_TIMEOUT=5

Danach ein

Code: Alles auswählen

update-grub2

Welcher User beim Login-Screen angezeigt wird: Welchen Display-manager etc nutzt du denn?

[smutbert]

2.
xfce hat keinen eigenen Loginmanager, aber du meinst vermutlich lightdm(-gtk-greeter). Lightdm kennt in /etc/lightdm/lightdm.conf im Abschnitt [SeatDefaults] die Option greeter-hide-users, die genau das macht bzw. verhindert was du willst. Also legst du dort einfach eine neue Zeile an oder bearbeitest die vorhandene, dass das Ergebnis irgendwie so aussieht

Code: Alles auswählen

[SeatDefaults]
…
greeter-hide-users=false
…

[uname]

Nett. Werde ich auch mal probieren. Du könntest falls Sicherheit keine Rolle spielt den Benutzer auch automatisch anmelden lassen. Das spart dann noch die Eingabe des Passworts.

[TomL]

Moin

Ich habe noch ein Problem "gefunden". In diesem Thread hatte ich mal von Berechtigungsproblemen berichtet. Die Lösung war uid=username mitzugeben. Ich habe dann auf meinem PC also "thomas" als uid mitgegeben und alle Probleme waren beseitigt. Aber wie mach ich das, wenn sich auf diesem Rechner mehrere User anmelden können? Da wäre ja der konstante Eintrag in der fstab "uid=thomas" völlig falsch, denn die anderen User sollen ja nicht meine Rechte erben, sondern sich mit eigenen Rechten auf dem Server tummeln. Gibt es eine Möglichkeit, den aktuellen User aus der Environment-Variable "USER" zu setzen?

[uname]

Der Eintrag "uid=username" bezieht sich auf den Benutzer und nicht auf den Client-Namen. Auch wenn ich selbst diese Konstruktion nicht nutze denke ich, dass du mit:

Code: Alles auswählen

file_mode=0644,dir_mode=0755

bzw. entsprechender Einschränkung

Code: Alles auswählen

file_mode=0600,dir_mode=0700

die anderen Benutzer ausschließt. Wobei die jeweils erste geänderte Null von links braucht wohl nicht geändert werden, da bei Debian jeder Benutzer seine eigene Gruppe hat. Aber sicher ist sicher. Mag auch sein, dass es nicht funktioniert bzw. nicht mal nötig ist. Am besten probieren.

[TomL]

Moin

Es läuft.... aber rückblickend war das mal wieder mit ner ordentlich Portion Frust verbunden.... ... Ein Single-User-PC ist wirklich schnell aufgesetzt, aber mehrere User mit von einander getrennten Zugriffsrechten auf die Netzressourcen auf einem PC.... mannomann, das handling ist echt eine Katastrophe, wenn man sich der effizienten Einstellungen bei Windows erinnert. Auf dem Server gibts User und Gruppen, die die angeschlossenen Platten berechtigen oder verwehren. Auf dem Client gibts User und Gruppen, die die entfernten Serverplatten und die lokale Platte berechtigen oder verwehren. Aber zwischen "mir" als Lokal->User und "mir" als Server-User gibts keine Verbindung, die ein gemeinsames abgestimmtes Handling ermöglicht. Es gibt quasi keine Berechtigung, die mich als Client-User unmittelbar und direkt mit dem Server-User und den -Ressourcen durchgängig in Übereinstimmung bringt. Warum? Ganz einfach, ich habe unterschiedliche ID's und GID's auf dem Client-PC und dem Server. Da hat Windows ganz klar einen riesen Vorsprung hinsichtlich der Intregation.

Ich bin mir im Moment mal wieder unsicher, ob meine Konzeption so überhaupt richtig gedacht ist. Meine Server-Platte HD_1 ist die "produktive" Platte für alle und alles und sieht derzeit so aus:

Code: Alles auswählen

HD_1                  = 770 thomas:thomas
administrative Dirs   = 770 thomas:thomas
öffentl. Dirs         = 770 thomas:sambauser
private. Dirs         = 770 ?username?:?username?

Diese fstab hat nach stundenlangem rumprobieren dazu geführt, dass die Anwender jetzt endlich genau das sehen, öffnen und bearbeiten dürfen, wofür sie zugelassen ist. Aber... ... das kann eigentlich so gar nicht richtig sein. Das ist ja ein Handling, was vom Aufwand her gar nicht geht, dass muss doch auch dynamisch passieren können. Ich erinnere mich an einiger unserer Dienststellen in meinem früheren Betrieb. Dort wurde z.T. im 4/3-Schichtbetrieb gearbeitet, an 7 Tagen die Woche, mit Urlaubsvertretung und Vertretung von Nachbarstandorten. Das heisst, an einem solchen PC in diesem Büro haben sich im Laufe des Jahres 20 oder 25 Leute angemeldet. Wer soll denn da eine solche fstab jedesmal pflegen ...?... zumal es dort gar keine lokalen Admins mehr gab. Was ist hier bei mir verkehrt, dass ich das nur so kompliziert lösen konnte?

Code: Alles auswählen

#                                                                                               Lokaler User (Client-PC)
#                                                                                               |          Lokale Gruppe (dto.)
# Admin-Share's                                                                                 V          v 
  //1.1.1.2/HD_1        /media/HD_1         cifs   credentials=/home/thomas/.smbcredentials,uid=thomas,gid=thomas,defaults 0 0
  //1.1.1.2/HD_2        /media/HD_2         cifs   credentials=/home/thomas/.smbcredentials,uid=thomas,gid=thomas,defaults 0 0
  //1.1.1.3/HD_3        /media/HD_3         cifs   credentials=/home/thomas/.smbcredentials,uid=thomas,gid=thomas,defaults 0 0

# Non-Public Share's
  //1.1.1.2/Downloads   /media/Downloads    cifs   credentials=/home/thomas/.smbcredentials,uid=thomas,gid=thomas,defaults 0 0
  //1.1.1.2/Programme   /media/Programme    cifs   credentials=/home/thomas/.smbcredentials,uid=thomas,gid=thomas,defaults 0 0

# Public Share's
  //1.1.1.2/Mail_Public /media/Mail         cifs   credentials=/home/thomas/.smbcredentials,uid=thomas,gid=sambauser,defaults 0 0
  //1.1.1.2/DatenAlle   /media/DatenAlle    cifs   credentials=/home/thomas/.smbcredentials,uid=thomas,gid=sambauser,defaults 0 0
  //1.1.1.2/MultiMedia  /media/MultiMedia   cifs   credentials=/home/thomas/.smbcredentials,uid=thomas,gid=sambauser,defaults 0 0

# Private Share's
  //1.1.1.2/homes/Daten /home/thomas/SHome  cifs   credentials=/home/thomas/.smbcredentials,uid=thomas,gid=thomas,defaults 0 0
  //1.1.1.2/homes/Mail  /home/thomas/SMail  cifs   credentials=/home/thomas/.smbcredentials,uid=thomas,gid=thomas,defaults 0 0

  //1.1.1.2/homes/Daten /home/diemama/SHome cifs   credentials=/home/diemama/.smbcredentials,uid=diemama,gid=diemama,defaults 0 0
  //1.1.1.2/homes/Mail  /home/diemama/SMail cifs   credentials=/home/diemama/.smbcredentials,uid=diemama,gid=diemama,defaults 0 0

# Lokaler Share
  /dev/sda2             /media/Lokal_C_Win   ntfs-3g  rw

[uname]

Dein Ansatz ist falsch und bei ein paar wenigen Benutzern kann man das noch geradebiegen. In einem normalen rein linuxbasierten Client-/Server-Umfeld mit Hunderten oder Tausenden von Clients und Benutzern würde ich eher so vorgehen.

a.) zentrale Benutzerverwaltung per LDAP (nsswitch.conf, passwd, shadow, group, /ec/pam.d, je Benutzer feste UID/GID)
b.) NFS statt Samba
c.) Mounten des NFS-Shares nicht je Benutzer, sondern eine Ebene höher
Beispiel:

Code: Alles auswählen

mailserver:/var/mail           XXXG    XXXG    XXXG     X%    /var/mail

Solange du deine Windows-Denkweise nicht ablegst musst du scheitern. Du musst auch mal bereit sein loszulassen. Werfe Samba weg, nutze NFS und reg dich dann darüber auf, dass sich bei Windows vielleicht NFS nicht ordentlich einbinden lässt.

Ich weiß leider nicht ob man bei Samba-Shares das Mounten ähnlich wie in meinem Beispiel mit NFS durchführen kann. Vielleicht geht das ja auch.

[TomL]

Moin Smutbert

xfce hat keinen eigenen Loginmanager, aber du meinst vermutlich lightdm(-gtk-greeter). Lightdm kennt in /etc/lightdm/lightdm.conf im Abschnitt [SeatDefaults] die Option greeter-hide-users, die genau das macht bzw. verhindert was du willst. Also legst du dort einfach eine neue Zeile an oder bearbeitest die vorhandene, dass das Ergebnis irgendwie so aussieht

Code: Alles auswählen

[SeatDefaults]
greeter-hide-users=false

Das hat leider nicht funktioniert.... zumindest resultiert aus diesem Eintrag keine Änderung im Login-Screen. Ich kann jetzt natürlich nicht unterscheiden, welches Programm dieser Login-Screen ist, deswegen weiss ich gat nicht, ob das tatsächlich dieser von dir genannte gtk-greeter ist. Also, ich habe während des Jessie-Setups im Expert-Mode nichts vorgegeben oder geändert.Und auch nachträglich habe ich noch nichts geändert. Der Greeter ist also der, der mit dem Setup und der Xfce automatisch kommt. Ist das dann dieser gtk-greeter?

Nach dem Start öffnet sich auf leeren Debian-Background nur dieses kleine rechteckige Fenster zur Eingabe von Name und Password, mit 2 leeren Eingabefeldern. Es wäre mir egal, wenn unter Name schon der zuletzt angemeldete User steht, oder ob quasi als Icon-List die auf dem PC vorhandenen User alle angeboten werden und man clickt sich selber an. Aber nix von dem passiert mit "hide=false". Gibts evtl. noch eine andere Lösung?

[TomL]

Moin Uname

Dein Ansatz ist falsch und bei ein paar wenigen Benutzern kann man das noch geradebiegen. In einem normalen rein linuxbasierten Client-/Server-Umfeld mit Hunderten oder Tausenden von Clients und Benutzern würde ich eher so vorgehen.

Ok, jetzt bin ich ja doch beruhigt, es geht also doch auch anders.....

a.) zentrale Benutzerverwaltung per LDAP (nsswitch.conf, passwd, shadow, group, /ec/pam.d, je Benutzer feste UID/GID)
b.) NFS statt Samba
c.) Mounten des NFS-Shares nicht je Benutzer, sondern eine Ebene höher
Beispiel:

Code: Alles auswählen

mailserver:/var/mail           XXXG    XXXG    XXXG     X%    /var/mail

Ok, aber die Lösungen sind jetzt ein Problem für mich. Ich muss bei Samba bleiben, weils eben auch noch Windows-Clients gibt. Und wenn Windows kein NFS unterstützt, kann ich das derzeit noch nicht nutzen.

Solange du deine Windows-Denkweise nicht ablegst musst du scheitern. Du musst auch mal bereit sein loszulassen.

Nee, das solltest Du jetzt nicht annehmen. Es gibt wirklich nichts, warum ich mit Gewalt an der Windows-Denke festhalten will. Ganz im Gegenteil, ich habe mich entschieden, und mich hält nichts "bei" Windows. Ich habe halt nur das Problem, dass ich mich derzeit an einigen Maschinen noch mit Windows arrangieren MUSS, da geht kein Weg dran vorbei. Und das zweite Problem ist, 30 Jahre Windows schaffen natürlich auch eine gewisse Erwartungshaltung. Und wenn was neues kommt, versucht man es zuerst mit den gewohnten Handgriffen. Ist doch eigentlich auch ganz klar, wenn ich 30 Jahre lang die defekten Birnen linksrum rausgedreht habe, würde ich das als Neu-Engländer auf der Insel auch erst mal so versuchen, ohne darüber nachzudenken, dass die dort rechts drehen

Ich weiß leider nicht ob man bei Samba-Shares das Mounten ähnlich wie in meinem Beispiel mit NFS durchführen kann. Vielleicht geht das ja auch.

Mein Problem war, dass es genau das, was Du bemerkt hast (nämlich durchgängige UID und GID) nicht gibt. Das kannte ich beispielsweise unter Windows nicht. Da funktionierte das immer. Der aktuelle Effekt war, entweder hat
- der User die öffentlichen Shares gesehen, die Non-Public, aber gar keinen der privaten Shares, nicht mal seinen eigenen.
- oder er hat alle öffentlichen gesehen, die Non-Public auch und alle privaten ebenfalls
- oder er hat alle öffentlichen gesehen, die Non-Public nicht, dafür aber alle privaten
- oder alle öffentlichen, die Non-Public nicht, nur seinen privaten Share, aber nicht mehr den Card-Dav-Server (aktueller Stand)

Ganz ehrlich.... ist schon echt total bescheuert....

[TomL]

Moin

Es läuft.... und der wohlwollende Kommentar der Chefin war:"Oh, sieht ja nett aus.... das gefällt mir auch...." Es gab allerdings noch ein paar Probleme. Icedove habe ich nicht in Deutsch hingekriegt... keine Chance, er hat sich hartnäckigst geweigert "deutsch" sprechen. Es wurde in englisch installiert und es blieb kompromisslos dabei. Interessant daran ist, dass wir zu dem jeweils privaten eigenen Profil 2 weitere öffentliche Profile haben. Eines der beiden war deutsch, das andere ebenfalls in englisch, obwohl die gleiche de.xpi zugrunde lag. Vom Windows-Client aus betrachtet waren alle ordentlich in Deutsch. Selbst nach Entfernen und Neu-Install wurde Icedove nicht Deutsch. Ich habe dann Thunderbird in gleicher Version aus dem Mozilla-Release-Archiv installiert und das lief auf Anhieb korrekt.

Das Problem mit dem Greeter ist auch gelöst.... da hats tatsächlich einen Neustart gebraucht, nur Abmelden hat nicht gereicht.

Danke für die Hilfe

[uname]

Ich gehe davon aus, dass icedove-l10n-de installiert ist. Leider kenne ich mich mit Icedove sonst nicht aus.

[TomL]

Ich gehe davon aus, dass icedove-l10n-de installiert ist. Leider kenne ich mich mit Icedove sonst nicht aus.

Ja, ich habe das ja jetzt schon oft gemacht.... generale-user-agent-local stand auf de-De, das war alles korrekt. Ich vermute ein Kompatibilitätsproblem. Wahrscheinlich hat ein Windows-Client sein Thunderbird und das Sprach-Plugin upgedatet und da kam halt Icedove nicht mit klar. Ich habe die Versionen jetzt auf Thunderbird mit gleichem Versionsstand synchronisiert und auf dem Win-Client das automatische Update erstmal geblockt. Danach funktionierte es ja.... war halt nur wieder mal aufregend und brauchte erst mal nen Spaziergang ne Stunde mit meinem Hund den Kanal entlang..... da kamen dann die Lösungsideen.