Faktisch ist es doch so, dass Leap der erweiterte Beta-Test für SLES ist, und die Pakete zu weit über 90% die gleichen sind. Somit sind auch SLES Probleme openSUSE Probleme.
1 Like
Wenn der Support mit CVEs nichts anzufangen weiß, dann ist das sicher nicht mein Problem, sonern eher die mangelnde Qualifikation des Suppoprters.
Und es gibt CVEs, die sind “unter Verschluß”, vermutlich weil sie “so heiß” sind. Ich darf die hier gar nicht posten.
Hatte ich mittlerweile dann auch gefunden.
Nein, denn der Kunde kann nur sehen, was der Supporter schreibt. Den Request einfach als “Duplicate” ohne weitere Referenz abzuweisen, hilft wenig, zumal ich dann kein Tracking habe. Wäre es nicht korrekt gewesen, den Case auf “wartet auf Umsetzung” zu setzen?
Aus Bugzilla-Sicht mag es ein Duplicate sein, aber was hilft mir das beim End-User-Support?
Das nennt man dann “self service”, und das steht auch dem nicht zahlenden Kunden fast aller Open Source Produkte zur Verfügung. Und schließlich nicht vergessen: Die SLES-Kunden finanzieren über ihre Support-Verträge die OpenSUSE Entwicklung. Die mit den nicht-zahlenden “Kunden” gleichzusetzen macht keinen guten Eindruck, um e mal so zu sagen…
Siehe meinen Kommentar zu “non-disclosed” CVE Details. Ich darf das hier nicht posten, aber der Support hat sie.
Der war gut! 
Ja, ich habe auch den Eindruck, dass da teilweise studentische Hilfskräfte im Support arbeiten, die wenig Ahnung von professionellem Produktsupport haben.
Ich habe meine Aufgabe vom Sicherheitsbeauftragten der Firma erhalten, der Aufgrund einer BSI-Meldung auf Behebung der Sicherheitslücken drängte. Zusammen sind wir über 100 Jahre alt, und somit vermutlich keine Praktikanten. BTW. Ich hatte sämtliche SUSE Gründungsmitglieder persönlich getroffen, also erzählt mir nichts von “Praktikant”…
Dann solltest du mal die entsprechenden Meldungen hier posten statt herumzureden. (bitte nicht als Bild).
Keiner kann ohne Infos helfen.
2 Likes
Nun die Sicherheitslücken in LibreOffice sind zumindest für mich nicht relevant da nicht installiert. Aber wenn ich es benutzen müsste würde ich vermutlich die flatpak Variante nehmen.
Das Firefox Thema ist an anderen Stellen im Forum ausgiebig diskutiert worden da wird alles relevante bereits gesagt.
Ja das ist durchaus ein Punkt der nicht so optimal klingt.
Leap benutzt den aktuellsten Firefox ESR, daher weiß ich gar nicht, was so eine Diskussion soll.
Wir haben nur Standard-Support; daher habe ich mir in kritischen Fällen (copy.fail & Co.) schon mal frische Kernel-Sourcen gezogen und mir mit der SuSE-config selbst einen aktuellen Kernel gebaut:
zcat /proc/config.gz >.config; make oldconfig; make; ...
Bisher hat das immer geklappt, aber es gibt keine Garantie dafür …
Auch wenn ein großer Teil der openSUSE Software ein “binäres Geschenk” der Firma SUSE an das Community-Projekt openSUSE ist, so können die openSUSE Varianten nicht mit den SUSE Produkten gleichgesetzt werden.
Die openSUSE-Varianten beinhalten neben dem “binären Geschenk”, auch Software, die nur von der Community entwickelt wird (z.B. Plasma) und selbst das “binäre Geschenk” kann z.B. bei der Konfiguration angepasst sein.
Die SUSE Linux Enterprise Produkte enthalten Software, die nicht an die openSUSE-Varianten weitergereicht wird.
Nein. Aber wenn man Abhilfe möchte, dann muss man sich an den wenden, der in der Lage ist diese Abhilfe zu schaffen.
Das openSUSE Forum ist ein Benutzerforum; d.h. hier tauschen sich Benutzer der openSUSE Varianten (Tumbleweed, Leap, …) untereinander aus und versuchen sich gegenseitig zu unterstützen.
Die Entwickler der von Dir genutzten Software (SLE) oder die Verantwortlichen der Firma, mit der Du einen Supportvertrag abgeschlossen hast, kannst Du hier nicht erreichen.
Die Entwickler der (open)SUSE Software, seien es Freiwillige aus der Community oder Angestellte der Firma SUSE, sind hier, wenn überhaupt, dann nur in eher geringer Zahl vertreten. Der einzig sichere Weg, um sie (Entwickler aus der Community oder SUSE-Mitarbeiter) zu erreichen , ist das Einstellen einer Fehlermeldung in Bugzilla. Ob es für SLE-Produkte andere/weitere Berichtswege gibt, kann ich Dir nicht sagen, aber das sollte aus Deinem Supportvertrag ersichtlich sein.
Wenn SUSE die mit Dir vereinbarten SLAs nicht einhält, dann kann Dir bzw. dem Sicherheitsbeauftragten Deiner Firma diesbezüglich nur das zuständige SUSE Management weiterhelfen.
Damit wir uns nicht falsch verstehen: Es geht nicht darum, dass man Dir hier im Forum nicht weiterhelfen will. Nur kann dieses Forum meines Erachtens in keiner Weise auf das Unternehmen SUSE direkten, nachhaltigen Einfluss nehmen.
3 Likes
Gerade beim Kernel würde ich mich eher auf das SUSE-Kernelteam verlassen; die bleiben doch immer am Ball, gerade mit Security-Fixes. Genauso bei Basis-Komponenten wie systemd oder Grub. Deshalb gibt es doch alle paar Tage einen neuen Kernel:
Wohlgemerkt, das ist Slowroll, und auch noch mitten in der Urlaubszeit.
Bei Paketen, die nicht zur systemkritischen Basis von SLES zählen wie das oben erwähnte LibreOffice sieht das weniger rosig aus; einmal, weil es eben nicht Business-kritisch für Geschäftskunden ist, und natürlich auch, weil niemand die notwendige Manpower dafür bezahlen will. Das war sicher auch die Überlegung dahinter, keinen SLED mehr anzubieten.
@windl kann ich (als ehemaliger (!) SUSEaner) nur empfehlen, sich an den zuständigen TAM (Technical Account Manager) zu wenden, wenn in seiner Organisation das Gefühl entstanden ist, daß der Support für SUSE Linux Enterprise nicht mehr so gut funktioniert, wie er sollte.
Aber wie andere schon geschrieben haben, ist das kein Problem, das hier im Benutzerforum gelöst werden kann.
2 Likes
Im Prinzip schon - das mit Copy.Fail war tatsächlich eine Sondersituation, da ich eine Lösung für einen Server brauchte, der aus Gründen noch auf einem älterem Servicepack festhing und daher keine Kernel-Updates mehr bekam …
das mit Copy.Fail war tatsächlich eine Sondersituation, da ich eine Lösung für einen Server brauchte, der aus Gründen noch auf einem älterem Servicepack festhing und daher keine Kernel-Updates mehr bekam …
Für solche Anwendungsfälle bietet SUSE das LTSS-Angebot an (Long Term Service Pack Support). Ohne LTSS-Support-Vertrag erhält SLES 15 SP7 bis 31.07.2031 Sicherheitsupdates. Mit einem LTSS-Support-Vertrag erhält diese SLES 15 SP7-Installation bis 31.07.2034 Sicherheitsupdates. Das LTSS-Angebot verlängert die Lebensdauer eines SLES Service Pack um 3 Jahre.
1 Like
Danke für den Tipp. Aber eigentlich sollte der Server schon längst auf SP7 hochgezogen worden sein. Aber wenn eine Stelle vakant ist, dauert es damit auch mal länger 
Die vakante Stelle ist kein Problem: Mit dem LTSS-Supportvertrag kann das Update von SLES15 SP6 auf SLES15 SP7 bis zum 31. Dezember 2028 herausgezögert werden.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.