Verbesserungsvorschlag Samba/CIFS

[SpaceRat]

Hallo.

Ich habe mir mal ein paar Gedanken zum Samba/CIFS auf der Box gemacht.

1. Finde ich es unschön, daß die /etc/samba/smb.conf nicht Bestandteil einer Einstellungssicherung ist und auch manuelles Zufügen zur Einstellungssicherung weitgehend sinnfrei ist, da diese Datei nachträglich vom Paket "enigma2-plugin-network-server" gekillt wird.
   Eigentlich kann opkg ipks installieren und Konfigurationsdateien dabei nur optional schreiben, d.h. wenn es eine smb.conf schon gibt, würde die default config aus dem ipk als smb.conf.opkg geschrieben und die originale bliebe unversehrt ...
2. Noch blödsinniger ist es, daß "enigma2-plugin-network-server" den Samba-Server nur installiert, aber nicht aktiviert ...
3. Generell braucht kein Mensch mehr nmbd
   nmbd ist ein Server, der Anfragen zu NetBIOS-über-IP-Namensdiensten verstehen und beantworten kann.
   NetBIOS-over-TCP/IP oder kurz NBT wurde von DOS inkl. WinDOS 3.95, 3.98, 3.98SE und 4.0 (aka Windows 95, 98, 98SE, ME), Windows NT 3.xx/4.0 und OS/2 verwendet ... allesamt Clients die heutzutage noch zuhauf im Heimnetzwerk stehen ....
   Auch nur halbwegs aktuelle Linux-Clients (Inkl. der Uralt-Sambas auf den E2-Boxen) und Windows-Versionen "Windows 2000" und höher packen NBT nur noch mit der Kneifzange an und das auch nur, wenn man sie dazu zwingt.
   
   Mit anderen Worten: Der nmbd läuft in den allermeisten Umgebungen völlig sinnfrei und ungenutzt auf der Box und verplempert CPU-Zeit und RAM mit Nichtstun.
   
   Wenn irgendjemand wirklich noch einen DOS-Client oder eine Metabox (Läuft unter OS/2) rumfliegen haben sollte, dann könnte er den nmbd immer noch aus einem getrennten Paket nachinstallieren oder nachaktivieren.
4. IPv6-Tauglichkeit
   Der verwendete Samba 3.0.37 ist nicht IPv6-tauglich. Es gibt zwar einen IPv6-Patch (von AVM) für Samba 3.0.37, ich habe allerdings den gepatchten Samba nicht kompiliert bekommen.
   Nun ist IPv6 für den Samba nicht wirklich wichtig, solange die E2-Box eh nicht IPv6-only laufen kann, ich verspreche mir aber von der Nutzung von IPv6 eine höhere Zuverlässigkeit der MyFritz!-Adresse (Der MyFritz!-Dienst aus der Fritz!Box "vergißt" gelegentlich, die Zuordnung MyFritz!-Name<>Gerät aufrecht zu halten, wenn die Fritz!Box den Client für inaktiv hält. Nach meinen Beobachtungen wird diese Zuordnung umso stabiler, je mehr - auch LAN-internen - IPv6-Traffic die Box verursacht.
   Nun ist es so, daß sich auch Samba durch einen Trick zumindest für eingehende Verbindungen IPv6-tauglich machen läßt, indem man den smbd einfach über inetd startet ...

Daraus ergeben sich folgende Vorschläge, die man auch ohne Neubau eines Images leicht vorab testen kann:

1. Löschen von /etc/etwork/if-up.d/01samba-start
   => nmbd und smbd werden nicht mehr als Daemons gestartet
2. /etc/inetd.conf um "microsoft-ds stream tcp6 nowait root /usr/sbin/smbd smbd" ergänzen
   Ergebnis:
   

   # /etc/inetd.conf: Internet superserver configuration database
   #
   # <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
   #
   8001			stream tcp6 nowait root /bin/streamproxy	streamproxy
   ftp				stream tcp6 nowait root /usr/bin/vsftpd		vsftpd
   telnet			stream tcp6 nowait root /usr/sbin/telnetd	telnetd -i
   ssh				stream tcp6 nowait root /usr/sbin/dropbear	dropbear -i
   microsoft-ds	stream tcp6 nowait root /usr/sbin/smbd		smbd

   optional könnte man noch folgende Zeilen zufügen:
   #netbios-ns dgram udp wait root /usr/sbin/nmbd nmbd
   #netbios-ssn stream tcp nowait root /usr/sbin/smbd smbd
   dies sind die für NBT benötigten Dienste.
   Da diese heutzutage eh nicht mehr benutzt werden,
   - braucht es hier kein tcp6 oder udp6, die Clients die noch NBT benötigen können eh kein IPv6
   - können die Zeilen auskommentiert bleiben, so sind sie für diejenigen, die sie unbedingt noch brauchen, schon da und können schnell aktiviert werden, belasten aber das System bei allen anderen nicht.
3. /etc/samba/smb.conf vor Überschreiben schützen
   Dazu muß das ipk wie folgt geändert werden:
   1. Eine Datei namens conffiles mit folgendem Inhalt erzeugen:
   

   /etc/samba/smb.conf

   2. Diese Datei "conffiles" zusammen mit der Datei "control" in die control.tar.gz packen

Ergebnis:

Offene Server-Ports:

Topf:/# netstat -lnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:41046           0.0.0.0:*               LISTEN
tcp        0      0 :::8001                 :::*                    LISTEN
tcp        0      0 :::16200                :::*                    LISTEN
tcp        0      0 :::80                   :::*                    LISTEN
tcp        0      0 :::21                   :::*                    LISTEN
tcp        0      0 :::22                   :::*                    LISTEN
tcp        0      0 :::23                   :::*                    LISTEN
tcp        0      0 :::443                  :::*                    LISTEN
tcp        0      0 :::445                  :::*                    LISTEN

bzw. mit Namen:

Topf:/# netstat -lt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:sunrpc          0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:41046           0.0.0.0:*               LISTEN
tcp        0      0 :::8001                 :::*                    LISTEN
tcp        0      0 :::16200                :::*                    LISTEN
tcp        0      0 :::www                  :::*                    LISTEN
tcp        0      0 :::ftp                  :::*                    LISTEN
tcp        0      0 :::ssh                  :::*                    LISTEN
tcp        0      0 :::telnet               :::*                    LISTEN
tcp        0      0 :::https                :::*                    LISTEN
tcp        0      0 :::microsoft-ds         :::*                    LISTEN

microsoft-ds (= SMB over TCP) ist der einzige Port, den Samba wirklich benötigt!
= vollständiger IPv6-Support. Alle Dienste der Box sind direkt mit IPv6 nutzbar.

Verbindungen:

Topf:/# netstat -t
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 Topf.fritz.box:microsoft-ds pc.fritz.box:10334 ESTABLISHED
tcp        0      0 Topf.fritz.box:microsoft-ds Ultimo.fritz.box:59540  ESTABLISHED
tcp        0      0 Topf.fritz.box:https    pc.fritz.box:10315 ESTABLISHED
tcp        0    208 Topf.fritz.box:ssh      pc.fritz.box:10328 ESTABLISHED
tcp        0      0 Topf.fritz.box:45188    Ultimo.fritz.box:10005  ESTABLISHED
tcp        0      0 Topf.fritz.box:56228    fritz.box:10005         ESTABLISHED

Oder mit IPs, damit's klarer wird :

Topf:/# netstat -nt
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 fd07:1234:d015:affe:23e:9eff:fe10:3a5b:445 fd07:1234:d015:affe:96de:80ff:fe6c:789a:10334 ESTABLISHED
tcp        0      0 ::ffff:192.168.1.17:445 ::ffff:192.168.1.16:59540 ESTABLISHED
tcp        0      0 2001:db8:2345:0:23e:9eff:fe10:3a5b:443 2001:db8:2345:0:96de:80ff:fe6c:789a:10315 ESTABLISHED
tcp        0    208 2001:db8:2345:0:23e:9eff:fe10:3a5b:22 2001:db8:2345:0:96de:80ff:fe6c:789a:10328 ESTABLISHED
tcp        0      0 fd07:1234:d015:affe:23e:9eff:fe10:3a5b:45188 fd07:1234:d015:affe:21d:ecff:fe03:6789:10005 ESTABLISHED
tcp        0      0 fd07:1234:d015:affe:23e:9eff:fe10:3a5b:56228 fd07:1234:d015:affe:9ec7:a6ff:fe23:5678:10005 ESTABLISHED

Auf dieser Box kommuniziert fast nichts mehr über IPv4, auch der Windows-Client verbindet sich (Übrigens ohne jedes Zutun, Windows bevorzugt IPv6 wenn vorhanden) mit der SMB-Freigabe der Box über IPv6 ...
tcp 0 0 fd07:1234:d015:affe:23e:9eff:fe10:3a5b:445 fd07:1234:d015:affe:96de:80ff:fe6c:789a:10334 ESTABLISHED
... der OSDingenskirchen holt sich Wasauchimmer per IPv6 von der Ultimo und der Fritz!Box ....
tcp 0 0 fd07:1234:d015:affe:23e:9eff:fe10:3a5b:45188 fd07:1234:d015:affe:21d:ecff:fe03:6789:10005 ESTABLISHED
tcp 0 0 fd07:1234:d015:affe:23e:9eff:fe10:3a5b:56228 fd07:1234:d015:affe:9ec7:a6ff:fe23:5678:10005 ESTABLISHED
... ssh und Webzugriff laufen über IPv6 ...
tcp 0 0 2001:db8:2345:0:23e:9eff:fe10:3a5b:443 2001:db8:2345:0:96de:80ff:fe6c:789a:10315 ESTABLISHED
tcp 0 208 2001:db8:2345:0:23e:9eff:fe10:3a5b:22 2001:db8:2345:0:96de:80ff:fe6c:789a:10328 ESTABLISHED
... nur noch die Samba-Kopplung Ultimo<>Topf läuft über IPv4 (Weil auch auf der Ultimo ein Samba 3.0.37 läuft) ...
tcp 0 0 ::ffff:192.168.1.17:445 ::ffff:192.168.1.16:59540 ESTABLISHED

Der für die Allgemeinheit wahrscheinlich schwerwiegendere Vorteil wäre aber, daß man nun den Samba auch direkt ins Image mit einbauen könnte:
Da er erst bei Zugriff über inetd gestartet wird, wird er bei denjenigen die Samba nicht nutzen auch nicht gestartet und belastet das System nicht. Er würde sogar bei denjenigen die ihn nutzen deutlich seltener laufen, wenn nämlich für den Zugriff autofs benutzt wird, da dieses Freigaben nur so lange offen hält, wie drauf zugegriffen wird.
Gleichzeitig entfielen mindestens zwei Arbeitsschritte bei (Neu-)Installationen:
1. Server-Plugin installieren
2. Server aktivieren
und ggf.
3. Eigene /etc/samba/smb.conf wiederherstellen

Fazit:
- nmbd entfällt = weniger CPU-/Speicherlast
- Samba standardmäßig nutzbar = weniger Konfigurationsaufwand = höhere Benutzerfreundlichkeit
- (eingeschränkte) IPv6-Kompatibilität ohne auf einen neueren (=fetteren) Samba aufrüsten zu müssen

- - - Aktualisiert - - -

PS: Meines Erachtens startet die Box sogar etwas schneller, weil jetzt der smbd und nmbd nicht mehr während des Bootens beim Herstellen der Netzwerkverbindung in den Speicher geschaufelt werden, sondern nur noch der smbd und wirklich erst, wenn ein Client zugreift.

[suchmich1983]

Ganz auf nmbd verzichten ist prinzipiell kein Problem, allerdings ist dieser in Windows Netzwerken durchaus sinnvoll. Der Dienst ermöglicht nämlich auch das Browsen nach Shares in der Windows Netzwerkumgebung. Gabs hier auch schon mal nen Thread zu, glaub mit @Mikam und mir.

Klar ist der Zugriff direkt dann noch möglich durch zum Beispiel das Mappen eines Netzlaufwerks oder UNC aber warum auf den Komfort verzichten? Es sind hier halt auch Leute unterwegs, denen es so leichter fällt.

Das nur zu nmbd... und der macht den Braten nicht fett

LG

[SpaceRat]

Ganz auf nmbd verzichten ist prinzipiell kein Problem, allerdings ist dieser in Windows Netzwerken durchaus sinnvoll. Der Dienst ermöglicht nämlich auch das Browsen nach Shares in der Windows Netzwerkumgebung. Gabs hier auch schon mal nen Thread zu, glaub mit @Mikam und mir.

Tjor, dumm nur, daß es gar nicht funktioniert:
Auch wenn ich meine inetd-Änderungern rückgängig mache und den nmbd sowie smbd wieder als Daemons starte, der Topf taucht niemals in der Netzwerkumgebung auf.

Klar ist der Zugriff direkt dann noch möglich durch zum Beispiel das Mappen eines Netzlaufwerks oder UNC aber warum auf den Komfort verzichten? Es sind hier halt auch Leute unterwegs, denen es so leichter fällt.

Würde ich Dir Recht geben, wenn's denn funktionieren würde.

Ich habe dieselben Änderungen übrigens auch auf meiner Vu+ Ultimo durchgeführt und die war vorher tatsächlich in der Netzwerkumgebung zu sehen.

Diesen Zustand (Sichtbar in der Netzwerkumgebung) kriegt man aber auch ohne Daemon durch die zusätzliche Angabe von
netbios-dgm dgram udp wait root /usr/sbin/nmbd nmbd
in inetd.conf wieder hin (Auf der Ultimo, auf dem Topf geht es so oder so nicht).

Es macht wohl speichermäßig keinen Unterschied, ob man den nmbd als Daemon oder über inetd startet, da der NBT-Traffic so stetig reinkommt, daß der inetd-gestartete nmbd auch nie wieder beendet wird.

Der smbd über inetd hingegen ist sehr sinnvoll:

1. Wird er für jede Verbindung n nur ein einziges Mal im Speicher gehalten
   Je nach Anwendungsprofil und verwendeten Clients ist er also u.U. gar nicht im Speicher und steht doch zur Verfügung.
   Mit smbd als Daemon hat man den Daemon an sich immer im Speicher plus die o.g. zusätzliche Instanz je Verbindung, man hat also n+1 Instanz.
2. Kann er so auch IPv6

Ich würde sagen: Win:Win-Situation.
Wozu einen smbd-daemon im Speicher halten, der weniger kann als der eh schon laufende inetd?

Das nur zu nmbd... und der macht den Braten nicht fett

while (1) {
print "Hello world!\n";
}
auch nicht und das Programm würde sogar was tun ...

[SpaceRat]

Auch wenn ich meine inetd-Änderungern rückgängig mache und den nmbd sowie smbd wieder als Daemons starte, der Topf taucht niemals in der Netzwerkumgebung auf.

Jetzt wo wir drüber sprechen fällt mir auch wieder ein, daß da doch was war ...

Und richtig, die Unsichtbarkeit des Topfes in der Netzwerkumgebung hing mit einem fehlerhaften Samba zusammen.

Mit
interfaces = eth0 wlan0
in der smb.conf, wie es eigentlich richtig (= generisch funktionierend) wäre, ist die Box unsichtbar, aber mit
interfaces = 192.168.1.17/24
ist sie sichtbar ...

Also habe ich mich doch noch mal daran gesetzt Samba selber zu kompilieren und hier ist das Ergebnis:
- Samba 3.0.37 mit fast allen Sicherheits-Patches wie in Freetz (Abzgl. Fritz!Box-spezifischer)
- Für "interfaces" dürfen wieder Interface-Namen stehen
- Fehler mit anderen Benutzern als "root" behoben, d.h. man kann auch eine Konfiguration schreiben, in der für guest der Benutzer nobody (Statt root ...) verwendet wird. Damit sind dann auch "security = user"-Konfigurationen möglich.
- smbpasswd mit im Paket (Siehe vorheriger Punkt)

[SpaceRat]

Hat jemand mein Kompilat des Samba im Einsatz und kann was dazu sagen?

Wäre ja in einem ersten Schritt auch schon was wert, wenn der Samba mit der Standardeinstellung
interfaces = eth0 wlan0
im LAN sichtbar wäre, statt daß man in auf die tatsächliche IP, z.B.
interfaces = 192.168.1.17/24
umkonfigurieren muß.

Übrigens:

Mit

smbpasswd -a root

dann ein Passwort setzen

plus dieser Konfiguration

smb.conf

[global]
   load printers = no
   guest account = nobody
   map to guest = bad user
   log file = /tmp/smb.log
   log level = 1
   security = user
   workgroup = WORKGROUP
   netbios name = %h
   case sensitive=yes
   preserve case=yes
   short preserve case=yes
   socket options = TCP_NODELAY
   preferred master = no
   oplocks = no

   username map = /etc/samba/users.map
   encrypt passwords = true
   passdb backend = smbpasswd
   obey pam restrictions = yes
   max stat cache size = 64
   mangled names = no
   bind interfaces only = yes
   interfaces = eth0 wlan0
   null passwords = yes
   domain master = no
   local master = no
   preferred master = no

[Root]
  comment = Everything - take care!
  path = /
  read only = no
  public = yes
  guest ok = no
  username = root
  valid users = root
  create mask = 0777
  force create mode = 0777
  directory mask = 0777
  force directory mode = 0777
  veto files = /Schlafzimmer/Wohnzimmer/Server/

[Harddisk]
  comment = The harddisk
  path = /media/hdd
  read only = no
  public = yes
  guest ok = no
  username = root
  valid users = root
  create mask = 0777
  force create mode = 0777
  directory mask = 0777
  force directory mode = 0777
  veto files = /Schlafzimmer/Wohnzimmer/Server/

ggf. plus

users.map

root = <Benutzername>

erhält man einen Samba-Server auf der Box, an dem man sich anmelden muß, um auf Freigaben zugreifen zu können und man kann dazu wahlweise den Benutzernamen "root" oder das in users.map definierte Alias "<Benutzername>" verwenden.

Prinzipiell liessen sich auf der Box auch weitere Unix-Benutzer mit entsprechendem Samba-Gegenpart anlegen, die sich an dem Samba dann z.B. mit reinen Leserechten auf die Harddisk anmelden könnten.

[MiNe]

Also habe ich mich doch noch mal daran gesetzt Samba selber zu kompilieren und hier ist das Ergebnis:

Boah cool! Bin ich froh, darauf gestoßen zu sein.
Ich bin auch schon auf das Problem gestoßen, dass man Freigaben nur für den root Benutzer definieren kann.
Hab das Problem schon in anderen Foren angesprochen, jedoch immer nur Unverständnis geerntet. "Es funktioniert doch eh alles mit der Standardfreigabe der Images. Man kann ja auf alles zugreifen".

Aus diesem Grund war ich schon drauf und dran selbst auf die Fehlersuche zu gehen und das Paket neu zu bauen. Jedoch hab ich Bitbake auf meinem System nicht zum Laufen bekommen.
Hast du es mit Bitbake gemacht? Hast einfach das das Recipe geändert?
Hast du eine Ahnung, warum in sämtlichen Receiver Images immer diese alte Samba Version drinnen ist? Auf OpenEmbedded gibts ja schon jahrelang Version 3.5.x.

MfG,
MiNe

[bonkel]

Liegt wohl daran das sh4 nich per bitbake. Gebaut wird

[MiNe]

Oh, oh!
Mir schwant, dieser SH4 ist gar kein MIPS Gerät. Kann das sein? Das würde dann auch erklären, warum ich auf meinem Xtrend ET8000 die Binaries aus diesem zip File nicht ausführen kann *g*

Das blöde ist, jetzt stehe ich immernoch vor dem Problem, dass Samba bei meiner Box defacto nicht verwendbar ist :-(

[TheChip]

DAs hast Du richtig festgestellt. SH4 ist nicht Mips und auch nicht Binärkompatibel.

[bonkel]

Oh, oh!
Mir schwant, dieser SH4 ist gar kein MIPS Gerät. Kann das sein? Das würde dann auch erklären, warum ich auf meinem Xtrend ET8000 die Binaries aus diesem zip File nicht ausführen kann *g*

Das blöde ist, jetzt stehe ich immernoch vor dem Problem, dass Samba bei meiner Box defacto nicht verwendbar ist :-(

was für ein image hast du drauf???

normal wird bei mips schon mit samba_3.0.37 gebaut---