Beiträge von Suelkun

Hallo,

ich bin eben dabei, mein System von openSUSE 13.2 auf Leap 42.2 umzustellen.

Dabei habe ich ein Problem mit einem eigenen Service, den ich für Zwecke der Datensicherung geschrieben habe.
Die Idee ist, den Service bei Systemstart zu starten. Der Service tut erstmals nichts. Erst wenn das System runtergefahren wird, soll ein Skript über alle (für mich) wichtigen Ordner gehen und auf separaten Disks Datensicherungsfiles erstellen, wenn sich gegenüber der letzten Sicherung etwas geändert hat.

Unter 13.2 läuft dieses Konzept einwandfrei. Unter 42.2 beobachte ich nun, daß mein Sicherungsskript auch bei Systemstart ausgeführt wird. Das ist zwar kein Beinbruch, weil bei Systemstop evt. vorhandene Sicherungsdateien des gleichen Tags überschrieben werden. Der Systemstart verzögert sich aber dadurch, d.h. der Start von 42.2 dauert erheblich länger als der Start von 13.2 und daran beteiligt ist mein Skript.

Ich weiß, daß das Skript ausgeführt wird, weil ich an dessen Ende auf dem Systemlautsprecher eine Tonleiter ausgebe und diese kommt eben unter 42.2 einige Zeit nach dem Start und dann nochmals kurz vor dem Ende, während es bei 13.2 nur kurz vor dem Ende kommt. Der Tonleiter vorausgehend ist lt. Disk-Acivity-LED ziemliche Last auf den Platten (auch typisch für mein Skript).

Kann mir jemand einen Tip geben? was hat sich an Systemd geändert von 13.2 nach 42.2? Im Anhang die frageliche Service-Datei.

ok, die Einstellung zur Zahl maximaler Empfänger habe ich gefunden. Man findet sie unter "KMail->Einrichten->E-Mail-Editor" Feld: maximale Anzahl von Empfängern.

Bei mir steht diese Zahl auf 200, also weit über der von mir bei oben geschildertem Fehler benutzten Zahl von Empfängern.

Dann haben die beiden geschilderten Probleme möglicherweise was miteinander zu tun. Möglicherweise "will" KMail viel mehr als diese 200 Empfänger eintragen, weil die Empfänger aus meiner Gruppe mehrfach eingetragen werden.

Hallo,

ich hatte gerade ein größeres Problem mit KMail / KAdressbook (unter openSuSE 13.2) zu dem ich gerne eine Lösung hätte. Ich weiß momentan aber nicht wie.

Zum Problem:

Ich habe in KAdressbook eine Reihe von Kontakten, die ich in einer Gruppe zusammengefaßt habe. Es handelt sich dabei um ca. 60 Kontakte, die ich alle mit einer einzigen Mail anschreiben wollte.
Ich habe dabei eine neue Mail aufgemacht und bei den Empfängern unter "Auswählen" geklickt. Darauf öffnet sich ein Fenster mit meinen Kontakten und ich klicke 1x auf die Gruppe mit meinen 60 Kontakten. Dann klicke ich 1x auf übernehmen und dann 1x auf schließen.

Ab dann hatte ich größere Probleme:
Ich bekam die Fehlermeldung : "Es können keine weiteren Empfänger hinzugefügt werden, die maximale Anzahl wurde erreicht".
Wenn ich diese quittiere kommt sie einfach wieder. usw.

Geholfen hat nur Abschiessen des betreffenden Prozesses und anschließend Löschen des Inhalts des Ordners $HOME/.kde4/share/apps/kmail2/autosave.
Wenn ich den Ordnerinhalt nicht gelöscht habe, dann kam nach Neustart von KMail einfach wieder obige Fehlermeldung. D.h. KMail war zeitweise bei mir komplett lahmgelegt.

Frage 1: Wo stelle ich die maximale Empfängeranzahl ein?

Beobachtet habe ich zudem, daß bei Einfügen einer Empfängergruppe mit weniger Kontakten (als meine 60 hier) die Kontakte der Gruppe tw. mehrfach in die Empfängerliste eingetragen wurden. Das konnte man zwar korrigieren (durch weglöschen der zuviel eingetragenen Empfänger) , aber lästig ist dies auch..

Frage 2: Ist für dieses Problem eine Lösung bekannt?

Für Tipps wäre ich sehr dankbar, denn meine 60 Empfänger werde ich vermutlich öfters anschreiben müssen und die Kugelfuhr von heute muß ich nicht ständig haben.

... Leider war meine Fehler-Interpretation falsch.

Ich habe mir heute morgen überlegt: Wenn meine Interpretation richtig wäre und meine Konfigurationsdatei smb.conf die Zeile enthält:

server string = Samba %v unter LINUX 42.2

Warum bricht dann die Samba-Verbindung nicht jedes Mal zusammen, wenn ich eine neuere Samba-Version erhalte (weil der Parameter %v durch die aktuelle Samba-Version ersetzt wird). D.h. die Server String würde sich dann ändern.

Die Wahrheit ist: Meine smb.conf enthielt tatsächlich einen Fehler. Sie enthielt nämlich auch die Zeile

hosts allow = 192.168.0

und hinter dem Zeichen "0" fehlt das Zeichen ".".

Das war die eigentliche Ursache meiner Probleme.

Das Problem ist gelöst.

Der ursprüngliche Gedanke war, gegenüber der virtuellen Windows7-Maschine den OpenSUSE 13.2-Fileserver durch einen Leap42.2 Fileserver zu ersetzen, wobei das Windows-System nicht registrieren soll, daß es mit einem anderen Fileserver kommuniziert.

Das schien nicht zu funktionieren. Die dabei beteiligten Dateien smb.conf und smbpasswd habe ich x-fach ergebnislos geprüft.

Den Durchbruch brachte das googeln nach der Fehlermeldung, die Windows ausgab, wenn ich eine Share des Leap42.2-Fileservers verbinden wollte. Das konnte man doch so verstehen, als ob Windows trotz alledem registrieren würde, daß es sich mit einem anderen Fileserver verbinden sollte. Zwar mit gleichem Netbios-Namen und gleicher IP-Adresse, aber trotzdem ein anderer Server. Die Frage war dann: Woran kann Windows das überhaupt "merken", wenn dem so ist?

Meine 13.2 smb.conf / 42.2 smb.conf unterschieden sich im Samba-Parameter "server string".
Während die 13.2 - Datei die Zeile enthielt:

server string = Samba %v unter LINUX 13.2

enthielt die 42.2-Datei die Zeile:

server string = Samba %v unter LINUX 42.2

Ich habe heute morgen in die smb.conf von Leap42.2 die Parameterzeile "server string" des 13.2-Systems eingebaut und Samba neu gestartet.

Ergebnis: Windows scheint zu einer Freigabe neben dem Freigabe- und Netbios-Namen des anbietenden Servers tatsächlich auch dessen Server String zu speichern. Nach dieser Änderung in smb.conf hat
Windows sofort und klaglos mit meinem Leap42.2-Fileserver zusammengearbeitet.

Ich bin eigentlich nicht vorbereitet, meine Infrastruktur umfassend zu verteidigen. Wenn es aber bei der Problemlösung hilft:

Es gibt einige Gründe, einen Fileserver für eine einzige Client-Maschine einzurichten. Einer davon ist die Datensicherheit. Ich habe mein Linux so konfiguriert (d.h. so modifiziert), daß es alle mich interessierenden Verzeichnisse beim Herunterfahren des Rechners durchgeht, bei geändertem Verzeichnisinhalt ein tar-File des gesamten Verzeichnisses anfertigt und auf eine separate Festplatte verschiebt.
Ich will natürlich, daß die unter Windows erzeugten Daten ebenfalls so gesichert werden und mit meiner Mimik funktioniert das auch. Dies ohne daß ich mir irgendetwas besonderes einfallen lassen müßte.

Der nächste Grund ist, daß ich Server und Client immer gleichzeitig brauche und damit auch gleichzeitig starte bzw. runterfahre. Der Linux-"Server" dient mir in den meisten Anwendungsfällen auch als Client. In den wenigen Fällen, in denen das nicht geht (z.B. das Steuerpaket WISO oder mein Dokumentenmanagement-System laufen nur unter Windows) starte ich eben dann VMWare (das ist mein Virtualisierungssystem) und dort mein virtuelles Windows7. Dann erledige ich die dort notwenigen Sachen. Die zugehörigen Daten landen über Samba auf dem Linux-Fileserver und dort kann ich sie mit Linux-Bordmitteln auch bearbeiten, was manchmal notwendig ist (z.B. PDF-Zusammenstellungen o.ä.). Ich brauche den Windows-Client nur dann, wenn der "Server" auch hochgefahren ist und wenn ich den "Server" nicht mehr brauche, dann brauche ich den Windows-Client auch nicht mehr.

Das "Netzwerk" zwischen VMWware und Linux ist eine virtuelle Bridge d.h. das virtuelle Windows7 bekommt von meiner Hardware-Firewall (= DHCP-Server) genauso eine IP-Adresse aus meinem Heimnetzwerk-Adress-Pool wie das Linux. Windows7 könnte damit prinzipiell vollwertig agieren, ich nutze es aber nur sehr eingeschränkt für die paar Programme, für die es kein Linux-Äquivalent gibt.

Reicht das?

Die geschilderte Infrastruktur läuft wunderbar unter SUSE13.2, nicht aber unter Leap42.2. Das liegt im weitesten Sinne an Samba und das will ich ändern.

a) ich will das Linux-System als Fileserver nutzen.
Unter Linux läuft eine virtuelle Windows-Maschine, die ihre Daten auf einer Freigabe des Linux-Systems ablegt. Diese Freigabe wird über Samba bereitgestellt.
Dieses Konstrukt funktioniert einwandfrei unter SUSE13.2 und funktioniert nicht mehr unter 42.2 (d.h. ich bekomme es unter 42.2 nicht zum Laufen).
Die Frage ist: Was ist falsch, nachdem ich nahezu identische Dateien smb.conf für die beiden Fälle verwende.

b) die fstab habe ich gepostet, weil Nutzer "Sauerland" darum gebeten hat. Er hat vermutet, daß irgendwelche Berechtigungen nicht stimmen.

Ich will nicht eine Linux-Partition über irgend ein Modell von Windows aus mounten, d.h. mein Problem hat nichts mit der fstab zu tun, da bin ich mir auch ziemlich sicher.

Ich will schon gar nicht von Linux aus auf irgendeinen Datenpool von Windows zugreifen (mal abgesehen von den Daten, die Windows über die Samba-Freigabe auf dem Linux-System ablegt, wenn ich es schließlich zum Laufen bringe).
Seit Jahren mache ich jede Anstrengung, um Windows nicht benutzen zu müssen und bis auf mein Dokumenten-Management-System habe ich das auch geschafft.

Nachdem ich auf 42.2 erst dann wirklich umstelle, wenn alles funktioniert wie es soll ( auch Samba ) habe ich momentan keinen Leidensdruck. Als einzigen etwas unangenehmen Nachteil empfinde ich, daß ich unter 13.2 keine automatischen Updates mehr erhalte.
Wenn mir eine Idee kommt, die ich zur Lösung des oben beschriebenen Problems ausprobieren kann, dann boote ich 42.2 an, sonst benutze ich 13.2 (und da funktioniert auch Samba).

ok, bin wieder da.

Fehlermeldung von smclient hatte die Ursache, daß smbd nicht lief. Nach dessen Aktivierung habe ich wieder den hier in früheren Beiträgen geschilderten Zustand.
Also: ich kann unter 13.2/ samba unter Windows die Freigaben benutzen, unter 42.2/samba kann ich die Freigaben nicht einrichten und nicht ansprechen.

... bitte erst einmal nichts tun.

Ich habe gerade eben festgestellt, daß ich mit dem Aufruf von:

smbclient -L localhost

unter 42.2 einen Fehler bekomme, während ich unter 13.2 mit dem gleichen Befehl keinen Fehler bekomme. Das ist erst einmal ein Ansatzpunkt, den ich selbst untersuchen kann.
Ich melde mich mit dem Ergebnis später wieder.

... diese ist zwar dem ersten Beitrag zu diesem Thema als Anhang beigefügt und daran geändert hat sich seither nichts. Sicherheitshalber aber nochmals zum Vergleich die (unter 13.1 funktionierende ) smb.conf und die ( unter 42.2 nicht funktionierende) smb.conf.