[Eisfair] Samba-Probleme und Dampsoft

Thomas Bork tom at eisfair.org
Sa Jan 5 19:28:30 CET 2019


Am 05.01.2019 um 11:06 schrieb Jürgen Witt:

> ich habe in einem meiner Netze seit kurz vor Weihnachten massive 
> Probleme (es zerlegt die Dampsoft-Datenbank(-en) und es muß dann zur 
> Reparatur eine Datei-/Strukturüberprüfung ausgeführt werden).

Was wurde zu diesem Zeitpunkt in diesem Netz geändert? Andere Software, 
andere Hardware, möglicherweise Kabelschäden, unzuverlässige Switches 
usw...?

> Aus Performance-Gründen bin ich überall, wo Dampsoft eingesetzt wird, 
> sofort wieder auf die Samba-Version 3.22.0 zurück gekehrt.

Was überhaupt keine gute Idee ist, da Du nicht einmal mehr 
Sicherheitsaktualisierungen erhältst.

Du hast auf meine Fragen und Vorschläge im letzten Thread zu diesem 
Thema leider nicht mehr geantwortet...

> Dauer Dateiüberpüfung auf einem frisch aufgesetzten Windows 10 PC gegen 
> einen E1-Server: 105 Min.
> 
> Datenverzeichnis (Freigabe): 11,6 GB
> Netzwerk: 176 GB empfangen und 17 GB gesendet (Statistik auf dem W10 PC)
> 
> Dauer Dateiüberpüfung lokal auf einem frisch aufgesetzten Windows 10 PC: 
> 23 Min.
> 
> Seit dem führe ich die Updates (die immer eine Dateiüberprüfung nach 
> sich ziehen) immer so aus: Kopieren der Dampsoft-Installation vom 
> E1-Server auf einen PC im Netzwerk. Ausführen des Updates bzw. der 
> Reparatur/Dateiüberprüfung lokal auf dem PC. Zurückkopieren der lokalen 
> Dampsoft-Installation auf den E1-Server. Das geht trotz der 
> Kopiervorgänge viel schneller und zuverlässiger, als den Vorgang über 
> das Netzwerk auszuführen.

Ja klar.

> Ich habe die smb.conf (Linux wird nicht offiziell unterstützt) gemäß den 
> Herstellerempfehlungen bearbeitet.

Das ist schon Dein grösstes Problem:
Da der Hersteller das Serverbetriebssystem nicht offiziell unterstützt, 
kannst Du Probleme nicht von ihm lösen lassen. Du weisst ja nicht mal, 
ob die Probleme auf das Serverbetriebssystem zurückzuführen sind, denn 
dazu müsstest Du einen Windows-Server in das selbe Netzwerk hängen und 
damit gegentesten.

Wenn die massiven Probleme ab einem bestimmten Zeitpunkt auftreten, dann 
muss es zu diesem Zeitpunkt einen Auslöser dafür gegeben haben.

> veto oplock files = /*.dbf/*.cdx/*.fpt/
> blocking locks = No
> kernel oplocks = No
> kernel share modes = No
> level2 oplocks = No
> locking = No
> oplocks = No
> 
> local master = Yes
> os level = 255
> preferred master = Yes
> 
> dos filetime resolution = Yes
> dos filetimes = Yes
> 
> Es geht um das oplock, daß man wohl auf Windows-Maschinen nur unter smb1 
> überhaupt richtig abschalten kann.
> 
> Hier habe ich dazu im Netz etwas gefunden:
> https://social.msdn.microsoft.com/Forums/de-DE/594d5eea-c95e-437b-8ee4-8f0e2ad31b63/abschaltung-smb1-oplockproblematik?forum=foxprode 

Ja, Oplocks kannst Du clientseitig unter höheren Protokollversionen 
nicht mehr abschalten, da sie Bestandteil der Protokolle sind. Nur noch 
SMB1 zu erzwingen dürfte aus Sicherheitsgründen gar keine gute Idee 
sein, wenn es sich nicht um komplett abgeschottete Netze handelt.

> In dem Praxis-Netzwerk (ca. 30 PCs) sind auch zwei Windows 10 PCs 
> (IP-Adressen 10.20.3.94 und 10.20.3.234). Diese machen unglaublich viele 
> gleichzeitige Verbindungen zum Server auf. Die meisten dazu merkwürdiger 
> Weise als nobody/nogroup.

Das solltest Du mal mit einer neueren Samba-Version gegentesten. Meiner 
Meinung war das ein Bug, der längst behoben ist.

> So sieht es aus, wenn ich das Dampsoft-Verzeichnis vom W10-PC auf den 
> E1-Server zurück kopiere (benutzte Freefilesync):
> 
> Samba version 4.6.15-for-eisfair-1-patch-1
> PID     Username     Group        Machine    Protocol Version  
> Encryption           Signing
> ---------------------------------------------------------------------------------------------------------------------------------------- 
> 
> 16926   xxxxxxxx     users        10.20.3.149 (ipv4:10.20.3.149:50603) 
>     SMB2_10           -                    -

Das dürfte ein Win7-Rechner sein.

> 16825   praxis       users        10.20.3.134 (ipv4:10.20.3.134:51480) 
>     SMB2_10           -                    -
> 17275   praxis       users        10.20.3.94 (ipv4:10.20.3.94:58488)    
> SMB3_11           -                    partial(AES-128-CMAC)

Das ist ein Win10-Rechner.

Wie man sieht, nutzen beide verschiedene Protokoll-Versionen. Du 
könntest versuchsweise die maximal mögliche Protokoll-Version am Server 
auf die Version SMB2_10 beschränken, wenn nur die Win10-Rechner Probleme 
machen. Aber siehe unten...

> Ich muß jetzt seit kurz vor Weihnachten jeden Abend eine 
> Datei-/Strukturüberprüfung ausführen (geht nur, wenn alleiniger 
> Zugriff), weil der Zugriff auf die Dampsoft Patienten-Daten bei einigen 
> Patienten fehlerhaft ist.

Du solltest erst einmal herausfinden, warum das seit einem bestimmten 
Zeitpunkt der Fall ist. Und dann, von welchen Rechnern die Probleme 
ausgelöst werden.

-- 
der tom
[eisfair-team]


Mehr Informationen über die Mailingliste Eisfair