Das klingt genau nach dem was ich vermisst habe. Schön das nach langem Warten die neuen samba-RPMs mit dem Fix erschienen sind. Ich seh sie inzwischen auch auf einem Leap15.3 system. Dann werden sie wohl kommende Nacht oder die kommenden Tage auch auf unserem RMT-Server für SLES erscheinen.
Danke
Rainer
Nee ist es wohl nicht.
Bei SLES ist die letzte samba-Version meines Wissens nach 4.13.13+git.531.903f5c0ccdc-3.17.1, wie bei Leap siehe Deine Ausgabe oben. Mit dieser Version lief unser samba-server aber bnach dem Update eben plötzlich nicht mehr, mit der Version samba-4.13.6+git.211.555d60b24ba-3.7.1.x86_64 war die Welt noch in Ordnung. Die Version 4.13.13+git.531.903f5c0ccdc-3.17.1 ist laut Changelog datiert mit 10.11.2021 (letzter Eintrag).
Danach (2021-11-12 08:50:59) UTC hat laut Bugreport (s.o.) Stefan Metzmacher den Code noch verbessert und das User-Mapping-Script, das wir nie hatten oder brauchten obsolet gemacht. Das war am 12.11 (der merge request) und somit schon nach dem Datum des letzten Patches den SLES herausgebracht hat. Da wir zuvor niemals ein usermapping script hatten und auch unsere smb.conf sich nicht verändert hat in der Zeit wird es wohl genau an der Einführung dieses Skripts liegen, was aber eben mit den Patches von Stefan Metzmacher nicht mehr notwendig wäre.
Ein Nutzer, der die gleichen plötzlichen Probleme wie wir hatte, hat bestätigt das mit Paketen die er selbst auf OBS gebaut hat mit dem patch in bso#14901 alles wieder geklappt hat. Diese von Ihm gebauten RPMs hatte ich ebenfalls getestet und damit war auch bei uns wieder alles in Ordnung, mit der letzten SuSE-Version leider nicht. Daher hatte ich angenommen SuSE würde diesen patch aus bso#14901 ebenfalls übernehmen und aktualisierte RPMs herausbringen was aber bisher wohl nicht passiert ist.
Danke
Rainer
Hallo,
vor ca 20 Tagen hat SuSE einen Samba Security Patch herausgegeben, mit der samba-Version 4.13.13+git.528.140935f8d6a-3.12.1, einen Tag später 4.13.13+git.531.903f5c0ccdc-3.17.1. Zumindest der letzte patch hat dafür gesorgt, das unser SLES samba-Server, der bis dahin tadellos gearbeitet hat für unsere ca. 200 Nutzer schlagartig nicht mehr verwendbar war, weil es nicht mehr gelang sich erfolgreich zum samba server zu verbinden. Das dahinter stehende Problem wurde auf der samba-Liste beschrieben und es wurde auch eine Lösung erarbeitet:
Mit der dort ausgearbeiteten Lösung funktioniert auch bei uns samba wieder. Was noch fehlt ist die offizielle SUSE-Lösung.
Im Moment verwenden wir eine ältere offizielle SuSUE samba-Version damit unsere Nutzer wieder arbeiten können. Eigentlich hatte ich angenommen, das bald neue offizielle patches von SuSE für Leap 15.3 und SLES 15SP3 herauskommen, in dem die samba-team-Lösung aufgegriffen wird. Bisher ist das allerdings noch nicht geschehen. Daher die Frage an SuSE: wird an diesem Problem gearbeitet und ist eine Umsetzung in Sicht?
Viele Grüße
Rainer
Danke für den Hinweis.
Recently about 20day ago SuSE published a samba security update with package version samba 4.13.13+git.528.140935f8d6a-3.12.1, about day later 4.13.13+git.531.903f5c0ccdc-3.17.1.
These new version immediately broke our SLES15SP3 samba server, so that no one (about 200 users) was able to connect to samba any more. This was caused by a problem in this new 4.13.13+git.528 - samba version that in between has been fixed by the samba team. See here:
https://bugzilla.samba.org/show_bug.cgi?id=14901 1
At the moment we use an older samba version which was still fine (4.13.10+git.236.0517d0e6bdf-3.7.12) and I am waiting for new patched samba packages from SuSE that include the new code from above to fix the samba problem.
Since the fix from the samba team is now available since quite a while but I could not find a new SLES samba upgrade up to now, can anyone tell when the new official samba packages rolling out the fix mentioned above will be available from SuSE?
Thanks
Rainer Krienke
Die Sicherheitslücke kommt mit Java logging daher das über die log4j bibliothek bereitgestellt wird. Am einfachsten wäre wohl nachzusehen ob auf dem System log4j als Paket installiert ist: rpm -qa|grep -l log4j . Wenn das Paket nicht existiert sollte man auch nicht betroffen sein von dem Problem. Zudem muß das System von außen erreichbar sein z.B. über einen laufenden apache Webserver. Mehr steht hier:
Hallo,
ich habe einen Desktop mit leap 15.2, auf den ich von extern immer wieder mal via ssh zugreife und dann auch in der Lage sein möchte mit einem Account über den ich mich via ssh anmelde, der z.B. zu einer Gruppe "admin" gehört im Networkmanager konfigurierte VPNs zu starten bzw zu stoppen. Lokal am Desktop mit dem Networkmanager -Applet klappt das problemlos, nur eben nicht wenn man sich per ssh anmelde. Dann klappts nicht, man bekommt eine Fehlermeldung, das man nicht das Recht hat das VPN zu starten. "Schuld" ist polkit.
Eine Lösung die dies jedem angemeldeten Nutzer ermöglicht wäre in der Datei /etc/polkit-default-privs.local folgendes einzutragen:
org.freedesktop.NetworkManager.network-control yes:yes:yes
Das klappt. Was ich nun aber gerne erreichen möchte, ist das nur Nutzer einer bestimmten Gruppe sagen wir admin das Recht dazu haben sollen, nicht jeder angemeldete Nutzer.
Weiß jemand wie man das hinbekommt?
Danke Rainer
Hallo,
Ich habe vor kurzem von 42.3 auf Leap 15 gewechselt und dabei eine Neuinstallation gemacht und wie zuvor die root-Partition verschlüsselt. Dabei habe ich einfach in Yast gesagt das er mit /dev/sda machen kann was er will (Partitionen löschen oder erstellen) und das die Installation verschlüsselt sein soll. Das hat auch geklappt, allerdings ist das Ergebnis insbesondere im Vergleich mit 42.3 etwas seltsam.
Nach dem Start des Systems werden ich zunächst auf der Text Konsole (B/W) von grub2 nach einem Passwort gefragt. Hier bin ich zunächst mehrmals gescheitert. Das Passwort war falsch. Nach einmaliger Eingabe kommt man bei Falscheingabe ins Grub Rescuemenue für einen zweiten Eingabeversuch mußte ich also wieder neu booten. Irgendwann habe ich dann herausgefunden das an dieser Stelle ein englisches Locale gesetzt ist und daher die Tastaturbelegung anders ist als auf meiner deutschen Tastatur. Ok danach klappte dann die korrekte Eingabe des Passworts.
Anschließend erscheint das SuSE boot-Menü jetzt im Graphik-Modus. Nach Auswahl von "Starten von Leap15" kommt dann die zweite Passwortabfrage ebenfalls im Graphik-Modus. Hier ist das locale jetzt korrekt wie gewünscht auf Deutsch eingestellt, entsprechend intitiv ist dann auch die Passworteingabe.
In Leap 42.3 habe ich das Passwort nur einmal am Anfang eingeben müssen und dann hat das System gebootet. So möchte man es ja auch eigentlich haben.
Soll die doppelte Passwortabfrage in Leap15 so sein? Wie kann ich das Problem mit dem englischen locale in der grub2-Passwortabfrage auf ein Deutsches locale ändern, so das meine Tastaturbelegung an dieser Stelle dann eben auch wie gewünscht Deutsch ist?
Vielen Dank für Eure Vorschläge
Rainer
So, nu habe ich nochmal das zlm:/zenpuppet/openSUSE_Leap_15.0 repos genommen und puppet daraus installiert. Leider verhält sich facter auch hier nicht wie erwartet:
/opt/novell/zenworks/bin/facter operatingsystem
<leer>
Bei anderen openSuSE bzw SLES-Versionen und Ubuntus ist das Ergebnis "OpenSuSE" bzw "SLES" auf Ubuntu 18.04 ist es "Ubuntu". Ähnlich verhält es sich mit:
/opt/novell/zenworks/bin/facter osfamily
Linux
Normalerweise ist das Ergebnis bei OpenSuSE und SLES "SuSE" und bei Ubuntu 18.04 ist es "Debian".
Auf Leap 15 ist einiges anders bei den puppet-facts, bei den Puppet-Installationen, die ich bisher probieren konnte. Das macht ein Versionsübergreifendes Systemmanagement recht schwer, was ja aber eigentlich der Sinn von puppet ist.
Ich hatte auch mal ein puppet mittels:
gem install puppet installieren lassen. Der dabei installierte facter macht aber auch vergleichbare Seltsamkeiten.
Hat jemand mit den hier beschriebenen facts mit z.B. der zlm-Puppet-Version Erfolg? Kennt jemand eine puppet-Version für leap 15 bei der facter "normale" Werte liefert, für so grundlegende facts wie operatingssystem und osfamily?
Danke
Rainer
Oh sorry, den Link hatte ich nicht als Teil der Antwort erkannt und dadurch die Antwort nicht verstanden.
Das verlinkte Repos hatte ich schon gesehen bevor ich hier gepostet hatte. Ich hatte daraus das Paket puppet installiert und festgestellt, das es leer ist, also keine Datei enthält. Wie sich nach Kontakt mit dem Autor heraustellte war das Absicht und die eigentlichen Dateien liegen im novell-zenworks-puppet-Paket des Repos. Nach der Installation dieses Pakets liegt dann alles unter /opt/novell/zenworks/{share,bin,lib}.
Da mir das nicht wirklich gut gefiel, war ich hier noch auf die Suche gegangen nach einem Paket was puppet unter Standard-Pfaden installiert, was es dann aber eben nicht zu geben scheint.
Viele Grüße
Rainer
