Verbesserungsvorschlag Samba/CIFS

[SpaceRat]

Hallo.

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

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 ...
Noch blödsinniger ist es, daß "enigma2-plugin-network-server" den Samba-Server nur installiert, aber nicht aktiviert ...
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.
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:

Löschen von /etc/etwork/if-up.d/01samba-start
=> nmbd und smbd werden nicht mehr als Daemons gestartet
/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.
/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:
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.
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---

[MiNe]

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

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

Ja eh, aber nicht mit dem Fix von SpaceRat, oder?

Im Moment hab ich OpenATV drauf. Soweit ich das feststellen kann, scheinen aber eh alle (mips) Images das selbe Samba Paket in den Feeds zu haben. Im OpenATV ist es samba_3.0.37-r18_mips32el.ipk.

[SpaceRat]

Ja eh, aber nicht mit dem Fix von SpaceRat, oder?
Ich muß da mal mein Licht unter den Scheffel stellen:

Was beim Kompilieren von Samba am Ende rauskommt hängt von allem ab, außer dem Quellcode oder Konfigurationseinstellungen: Mondphase, Menstruationszyklus der Frau, dem Aktienkurs von Fresenius ...

Mein Kompilat kann jetzt die Interfaces richtig lesen:
interfaces = eth0 wlan0
sagt dem Samba ja eigentlich nur "Schau mal auf den Interfaces eth0 und wlan0 nach, wie die konfiguriert sind und übernimm diese Einstellungen".

Heißt also für eth0 z.B.:
Topf:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:3E:9E:10:3A:5B
inet addr:192.168.1.17 Bcast:192.168.1.255 Mask:255.255.255.0

-> eingestellt ist IPv4 192.168.1.17, Netmask 255.255.255.0 entspricht /24 -> nimm 192.168.1.17/24

Das bisherige Samba-Kompilat konnte das - Auslesen von Interface-Informationen - nicht (Was daran liegt, daß bei Linux eine gigantische Community aneinander vorbei programmiert und es für jeden Furz immer 20 verschiedene Wege gibt, von denen auf jedem System nur einer geht, deshalb laufen ja beim Bauen einer "Hello world"-Linux-Binary noch die configure-Tests, wenn Microsoft schon ein ganzes Windows kompiliert hat).
Dementsprechend mußte man ihm die IP vorkauen:
interfaces = 192.168.1.17/24

Ohne korrekte IP/Netmask-Informationen hat Samba die für die NetBIOS-Namensauflösung benötigten Broadcasts entweder nicht oder ins falsche Subnetz gerotzt.

Übrigens hat auch mein Kompilat einen Bug, er will einfach nicht interaktiv laufen. Startet man den smbd mit
smbd -i
oder den nmbd mit
nmbd -i
dann sitzt er nur dumm da und tut nix. Das hat mich beim Testen den ein oder anderen Büschel Haare gekostet ...

Da ist dann ein anderer configure-Test in die Hose gegangen, möglicherweise der darauf, welche von 3496873496759 Varianten man auf dem Zielsystem für eine einfach Bildschirmausgabe nutzen soll.

Da aber niemand smbd/nmbd dauerhaft "interaktiv" (Also mit Bildschirmausgabe) nutzt, empfinde ich die Fixes für "interfaces = " und andere Nutzer als root als schwerwiegender als diese neue Einschränkung.

[MiNe]

Was daran liegt, daß bei Linux eine gigantische Community aneinander vorbei programmiert und es für jeden Furz immer 20 verschiedene Wege gibt, von denen auf jedem System nur einer geht, deshalb laufen ja beim Bauen einer "Hello world"-Linux-Binary noch die configure-Tests, wenn Microsoft schon ein ganzes Windows kompiliert hat

;) Ich kann deinen Frust sehr gut nachvollziehen.

Das war mir klar, dass man nicht wirklich in den Sourcen was ändern muss, sondern in dem configure Script, bzw. recipe, wenn mans mit Bitbake baut. Um Plugins für mips Boxen zu bauen braucht man doch Bitbake, oder?
Jedenfalls hab ich es ja noch nichtmal hinbekommen, Bitbake auf meinem System zum Laufen zu bekommen. Insofern ist Samba für mich am Sat Receiver nicht nutzbar. Eben wegen der Einschränkung, dass man auf jede Freigabe als root zugreift.

[SpaceRat]

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.
1. *ix-Programmierer haben sich ein ganz idiotisches Versionssystem überlegt.

Normale Entwickler haben immer einfach nur Haupt- und Unterversionen durchnummeriert, also
OS/2 1.0
OS/2 1.1
OS/2 1.3
OS/2 2.0
...
Arbeitsversionen auf dem Weg zu Version x.y heißen bereits x.y, lediglich versehen mit Anhängseln, die diesen Entwicklungsstatus widerspiegeln, also Alphas für frühe Versionen, Betas für halbwegs stabil erscheinende Versionen, die man dann auch bei Testern einsetzt und Gammas oder RCs (Release Candidates), von denen der oder die Entwickler annimmt/annehmen, daß sie fertig sind und die dann in größerem Umfang im Testbetrieb laufen.
Der letzte RC, an dem keine Änderungen mehr nötig waren, ist dann meist absolut identisch zur veröffentlichten Version ...



*ix-Programmierer machen Bockspringen:
1.0.x
1.2.x
1.4.x
1.6.x
1.8.x

Die erste Nummer ist ganz normal die Generation, die zweite aber springt immer in Zweierschritten, denn die ungeraten Nummern an zweiter Stelle sind den "Entwicklerversionen" vorbehalten.
haproxy 1.5 ist also die Entwicklerversion auf dem Weg zu 1.6, die aktuelle "stabile" Version hingegen ist immer noch die 1.4.

Du wirst also auch keine normale Linux-Distribution finden, die einen ungeraden Kernel (2.1, 2.4, 2.7,...) nutzt, sondern nur 2.0, 2.2, 2.4, 2.6, ...
Auch Samba 3.5 ist also keine stabile Version, sondern eine Entwicklerversion auf dem Weg zu Samba 3.6 ...

Also steht Samba 3.5 an sich für ein Produktivumfeld allein schon wegen seines "unstable" Charakters nicht zur Debatte.

Falls Du jetzt fragst, wieso dann nicht Samba 3.6 verwendet wird:
"Arsch wie ein Brauereipferd" sagt Dir was?
Das Teil ist so unglaublich fett geworden, daß es niemand freiwillig auf einem eher schwach bestückten embedded device einsetzen würde.

Auch auf den Fritz!Boxen findest Du noch Samba 3.0.37 vor, einfach weil es unendlich schlanker ist als die höheren Versionen.

- - - Aktualisiert - - -


Das war mir klar, dass man nicht wirklich in den Sourcen was ändern muss, sondern in dem configure Script, bzw. recipe, wenn mans mit Bitbake baut. Um Plugins für mips Boxen zu bauen braucht man doch Bitbake, oder?
Nein.

Bitbake ist einfach nur ein - dafür, daß es *ix-Hirnen entsprungen ist, sogar verblüffend schlüssiges - System, um einen Haufen Einzelpakete zu pflegen und daraus am Ende ein Gesamtkunstwerk zu dengeln.

Letztendlich enthält ein bitbake-Paket aber auch wieder nur
- Anweisungen zum Bau des Paketes (z.B. configure-Switches)
- Patches
- Einpackanweisungen, um daraus die zu verteilende Pakete zu erstellen

Du kannst Dir aber auch mit jeder anderen cross-compiler-Umgebung einen Samba für mips zimmern und den auf die Box packen, es geht halt nur nicht automagisch schief, sondern Du mußt von Hand verzweifeln.

Wenn man davon absieht, daß keine zwei Pakete dieselben Umgebungsvariablen gleich benutzt, sind die Schritte sogar relativ nachvollziehbar.

Beim Samba ist es besonders übel, daß der "PREFIX" ganz anders interpretiert als alle anderen Pakete. Normalerweise gibt das an, wohin später mit make install die binaries hin installiert werden, also beim Cross-Compilen eben nicht in das laufende System, sondern ein Verzeichnis, wo Du Dein Zielsystem aufbaust (z.B. /opt/cross/build/sh4 ), aber Samba ignoriert PREFIX fast völlig. Ich habe mir mehr als einmal die Samba binaries meiner virtuellen Maschine mit den sh4-Kompilaten überschrieben ...
die funktionieren in einer virtuellen Maschine auf dem PC natürlich gar nicht.

- - - Aktualisiert - - -


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

normal wird bei mips schon mit samba_3.0.37 gebaut---
... aber auch kaputt ...

[Mumpitz23]

Was ist den bei den Mips am Samba kaputt? Version 3.0.37-r2-vuplus3 (VTi) läuft auf meiner Duo ohne Probleme.

Die Macken von Samba hatten wir hier schonmal besprochen. Wir hatten festgestellt das die damalige 3.0.28 keine interfaces auflösen kann, es sei denn man weißt eine feste IP in der config zu. Samba 2.2.9 z.B. konnte wiederum mit interfaces = eth0 umgehen, hatte aber andere Probleme.
Es gibt leider nur eine wirklich problemlos laufende Version und das ist 3.6.9 die aber immerhin 11MB hat ;) Aber lieber so, als gar nicht.

Edit:
Die Samba-Version auf dem feed startet bei mir nicht, weil /etc/init.d/samba auf 644 steht anstatt auf 755. Da sollte mal jemand nachschauen.
Wäre es nicht sinnvoller die smb.conf mit ins ipk zu packen?

Edit2:
Die 3.0.37 die du da gebastelt hast, scheint soweit auch zu funktionieren, habe jedenfalls auf Anhieb kein Problem entdeckt. Auf jeden Fall, wird der Receiver unter seinem Namen in Windows gelistet.

[SpaceRat]

Was ist den bei den Mips am Samba kaputt? Version 3.0.37-r2-vuplus3 (VTi) läuft auf meiner Duo ohne Probleme.
Hast Du mal versucht
guest account = nobody
map to guest = bad user
einzustellen?
Wenn der Samba dann noch startet hätte ich die binaries gerne ...



Wäre es nicht sinnvoller die smb.conf mit ins ipk zu packen?
Bitte nicht.
Ich will meine eigene Config, es sollen sich nämliche alle Boxen gleich verhalten.

Außerdem will ich da zumindest grundlegende Sicherheit:
Natürlich gebe ich Samba nicht ins Netz frei, aber daß sich in der Standardeinstellung jeder Arsch und seine Großmutter ohne Kennwort mit der Freigabe verbinden können ist mir absolut suspekt.



Die 3.0.37 die du da gebastelt hast, scheint soweit auch zu funktionieren, habe jedenfalls auf Anhieb kein Problem entdeckt. Auf jeden Fall, wird der Receiver unter seinem Namen in Windows gelistet.
Schön dazu mal eine Rückmeldung zu kriegen. Bedankt :)

Ja, das war der Sinn der Aktion und diesmal wollte ich es auch mal von anderen getestet haben, bevor es zu einem temporären Fiasko kommt wie damals beim OpenVPN :)

[Mumpitz23]

Hmmm startet laut log, ist aber dann doch tot der Prozess...

[SpaceRat]

Hmmm startet laut log, ist aber dann doch tot der Prozess...
Welcher?
Meiner oder der "3.0.37-r2-vuplus3 (VTi)" mit guest account = nobody?

Wenn es der 3.0.37 mips ist:
Starte ihn mal mittels

killall smbd
smbd -i
neu, dann siehst Du auch das Problem:

Failed to set gid privileges to (-1,65534) now set to (0,0) uid=(0,0)
PANIC: failed to set gid

Die Macke haben fast alle cross-compilierten Sambas (NAS-Hersteller müssen das natürlich hinkriegen, aber fast alle anderen bauen Murks)
Der Fehler ist leidlich bekannt Bug 3426 - "PANIC: failed to set gid" on mipsel when starting smbd (https://bugzilla.samba.org/show_bug.cgi?id=3426), aber eine wirklich funktionierende Lösung habe ich dafür noch nicht gefunden.

Für sh4 habe ich ja nun immerhin eine Binary die zumindest die rudimentären Linux-Rechte kann, aber für meine mips/Ultimo hätte ich das auch gerne und noch lieber den Samba 3.0.37+AVM-Benutzerrechte-Patch+IPv6-Patch...

Außerdem irritiert mich, daß der samba immer noch viel zu fett ist. Die Samba-Multicall-Binary von Freetz auf der Fritz!Box (Beinhaltet smbd, nmbd und smbpasswd) ist kleiner als der reine smbd den ich gebaut habe und smbd/nmbd zusammen verbrauchen auf der Fritte weniger RAM als allein der nmbd auf dem Topf. Ich weiß jetzt nicht, ob das an der Architektur (sh4 vs mips) liegt, oder an den Einstellungen beim Bauen.

[suchmich1983]

Hi,

ich sagte ja schon, gabs bereits einen Thread zu. Hab ne nun wiedergefunden. Zum Ende hab ich noch ne funktionierende Version gepostet: klick (http://www.hdmedia-universe.com/board/showthread.php?3520-EPG-dat-laden-Samba-Problem&p=44661&viewfull=1#post44661)

Hier klick (http://www.hdmedia-universe.com/board/showthread.php?3520-EPG-dat-laden-Samba-Problem&p=40937&viewfull=1#post40937) ist auch noch mal der nmbd das Thema... lag an der Version. Mit entsprechendem Eintrag in "Interfaces" gings dann auch mit der damaligen Version vom Feed!

Grüße