Ich nutzte samba nicht für den Netzwerk- Drucker, sondern Cups... was seit Jessie geradezu perfekt funktioniert.Simaryp hat geschrieben:30.01.2020 23:56:19Brauche ich diese ganzen Sachen, die ich zu Printern angegben habe oder reicht es, einfach keinen Abschnitt zu Printern zu haben?
Netbios (Port 139) ist an sich ein kritisches Protokoll... und nur Windows-Versionen bis Win2000 erfordern das zwingend. Microsoft hat das Protokoll wegen der Mängel auf ein TPC/IP-Basiertes (Port 445) geändert, welches alle späteren Windowsersionen natürlich auch unterstützen. Der Vorteil ist, eine potentielle Gefahrenstelle zu eliminieren. Port 139 ist nicht notwendig, bei mir gibts kein so altes Gerät oder Betriebssystem, welches das noch erfordern würde.Simaryp hat geschrieben:30.01.2020 23:56:19Was bringt mir das deaktivieren von netbios? Beziehungsweise wofür ist es gut. In den man pages steht, dass das für Win 2000 zB ok wäre, bei anderen Betriebssystemen (Windows?), aber Probleme macht.
Das Problem der Berechtigungen ist, dass man Dir eigentlich nicht wirklich raten kann, was richtig ist.... weil man nicht so recht Deine Anforderungen oder Deine Vorstellungen zum Server kennt. Ich kann nur grob umreissen, wie ich das hier gelöst habe und warum das so ist.... ob das für Dich geeignet ist, habe ich keine Ahnung.
- Prämisse: Es gibt userbezogene, rein private Verzeichnisse auf dem Server, mit exklusiven Rechten nur für den User
- Prämisse: Es gibt allgemeine Verzeichnisse, auf die alle User zugreifen dürfen, Multimedia, Dateien von gemeinsamen Interesse
- Prämisse: Es gibt geschützte Verzeichnisse, die nur für den Admin (für mich) relevant sind
- Prämisse: Keine Server-Platte kann von den Clients als "himself" gemountet werden
- Prämisse: Auf den Serverplatten können durch die Clients keine Devices oder ausführbare Programme betrieben werden
- Prämisse: Das Handling muss einfach sein, der Aufwand auf den Clients minimiert gering, möglichst zentral, am Server via Samba... auf den Clients nur ein paar Dateien kopieren und ggf. die Gruppe 'sambauser' mit den berechtigten Usern anlegen.
- Prämisse: Die Datenstrukturen müssen Backups perfekt unterstützen
Auf der Server-Platte (bei mir SSD) gibts ein Verzeichnis /media/Home, welches weiter jeweils unter dem Namen der Linux-User für jeden User ein eigenes Verzeichnis hat, was auch seitens der Rechte diesem Linux-User gehört. Die User selber haben keinen Zugang zu /media/Home, das ist kein Samba-Share! Über die Home-Section in der smb.conf können die User aber auf ihr Server-/home Zugreifen. Für jeden User findet nun einfach ein bind in der server->fstab statt, wo z.B. das User-Verzeichnis SSD->/media/Home/thomas lokal auf dem Server nach SSD->/home/thomas/SHome gebinded wird. Der User selber kann dann an seinem Client-PC mit einem Mount "/bin/mount //server/homes/SHome /home/%I/SHome" sein persönliches Server-Daten-Verzeichnis in sein lokales Homedire mounten. Samba unterstützt das wirklich perfekt. Der Vorteil ist, die Shares laufen immer genau unter dem User, der den Share mountet und bekommt auch die Rechte des Users. Zugriffe durch andere User im LAN ist gar nicht möglich... ebensowenig unerlaubte Übergriffe durch laufende Programme auf anderen Systemen... nur dieser User mit seinen Rechten hat Zugriff.
Die SSD ist ausschließlich gedacht für die sehr dynamischen Bewegungsdaten, Office-Dokumente, Mail-Systeme, Cal/Card-Dav, etc... also die typischen Daten aus dem Userspace mit hohem Änderungsaufkommen. Das Backup-Volumen soll idealerweise < 5GB bleiben, damit es noch via FTP auf den Web-Space (natürlich verschlüsselt) gesichert werden kann. Hier handelt es sich ja ausschließlich um durch oder von den Users selber laufend generierten Daten.... mit dem Attribut, dass diese Daten ohne aktuelles Backup nicht oder nur mit unverhältnismäßigen Aufwand wiederhergestellt werden können.
Zu 2.
Hier ists einfach... keine individuellen Rechte, die Gruppe wird generell mir RW auf die ID "sambausers" gesetzt. Auch das macht samba klasse. Hier ists ein Datengrab für statische Daten, typisch Multimedia, alles was groß ist, viel Speicherbedarf erfordert, sich nie oder kaum verändert (z.B. Foto-Archive), alles, was nur Kategorie 2 bei den Backups ist... ist ja bei Verlust alles mehr oder weniger leicht wieder beschaffbar. Das ist also eine klassiche HD mit mehreren TB.
Zu 3.
Ist ebenfalls einfach ...der Umstand, dass der Share nur mich als User zulässt, verhindert den Zugriff anderer. Auch das ist erfolgreich mit Samba gelöst. Meistens Install-Pakete, oder Source-Codes aus Project-Web-Sites. Wegen des teilweise hohen Speicherbedarfs und der wirklich leichten Wiederbeschaffbarkeit alles nur Kategorie 3 bezogen auf die Backups. Liegt alles in einem eigenen Verzeichnis auf der HD.
Zu 4.
Es sind in der smb.conf zwar Shares für die Platten/SSDs eingerichtet, aber die können nur im Terminal mit root-Rechten und nur von mir gemountet werden. Zu Wartungszwecken braucht man das natürlich. Ebenfalls erfolgreich mit Samba gelöst.
Zu 5.
Ist in den Mounts (noexec, nodev) auf dem Client geregelt, die durchgeführt werden, wenn sich ein User anmeldet. Das kann man umgehen, aber nur wenn man weiss wie... für normale User quasi unlösbar.
Zu 6.
Ist bei mir mit einem eigenen tool realisiert....
Zu 7.
Also... für mich war das mit einer der wichtigste Überlegungen überhaupt, die Datenstruktur an der Notwendigkeit der Backups auszurichten... denn gerade dafür will ich Erfolgsgarantien bezogen auf die Wiederherstellbarkeit wichtiger Daten. Aber ich will keinen individuellen Aufwand dafür... das soll mannlos laufen. Also die Backups waren echt eine Basis aller Überlegungen... auch das habe ich mit einem eigenen tool gelöst. Bei mir sinds mittlerweile nur keine 3 dedizierten Raspi's mehr, sondern ein Intel NUC mit 3 VMs... aber prinzipiell wurde die Logik 1:1 beibehalten.
Aber wie gesagt... das alles kann jetzt hier nicht mehr als nur eine Anregung sein... ein paar Ideen... was davon brauchbar ist, entscheiden Deine Anforderungen.