Beiträge von reinulli

Liebe Leute,

ich möchte hier mal mein Wissen weitergeben: In meinem Betrieb wird viel mit DISPLAY-Umlenkung gearbeitet. Diese braucht man, wenn man grafische Programme auf einem anderen Rechner laufen lassen will und sich die Grafikausgabe "herüberholen" möchte. Hierzu gibt man den entfernten Rechner auf seinem Eigenen erst einmal lokal frei:

xhost + <entfernter Rechner>

auf dem entfernten Rechner setzt man die DISPLAY-Variable entsprechend

export DISPLAY=<eigener RECHNER>:0

Startet man jetzt auf dem entfernten Rechner jetzt das Programm, z.B. Firefox etc, erscheint die Grafik auf dem lokalen Rechner, an dem man sitzt.

Leider funktioniert das nur, wenn X auf dem lokalen Rechner mit der Option "-listen tcp" gestartet wurde. Das ist standardmäßig nicht der Fall.

Hier zu konnte man früher in "/etc/sysconfig/displaymanager" den Eintrag
DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN="yes"

setzen. Leider gehorcht der Anmeldemanager sddm diesem Regelwerk nicht mehr (anders als der abgelöste kdm) und man muss in der /etc/sddm.conf folgenden Eintrag (als root) setzen

[X11]
ServerArguments=-listen tcp

Ich habe im Yast bisher noch keine Möglichkeit gefunden, das zu konfigurieren.

Ich gebe mal einen Zwischenstand meiner Nachforschungen. Seit cups 2.0 gibt es lokale Warteschlangen auch für remote Drjucker, mit der Besonderheit, dass eine lokale ppd-Datei mit dem Namen des entfernten Drjuckers unter /etc/cups abgelegt wird. Diese wird bei

lpoptions -p <Druckername> -l

abgefragt und ist bei neueren CUPS Versionen ab 15.3 stark - hier von 2261 auf 238 Zeilen - verkürzt. Infolgedessen reduziert sich die Ausgabe von lpoptions z.B. für ein großen Ricoh Multifunktionsgerät ebenso. Nun wäre es interessant, warum cups bei 15.3 hier anders arbeitet als bei älteren Versionen. Welche Optionen werden unterschlagen und nach welcher Systematik?. Daß cupsfilter-Einträge entfernt werden ist klar, weil ja remote am Ziel gefiltert werden soll. Raw_Queues werden auch nicht mehr unterstützt.

Wir betreiben viele große Netzwerkdrucker, die von einem SLE12 Server mit cups-browsed propagiert werden. Unter OpenSuSE 15.1 erhalte ich Druckoptionen schön aufgelistet wie es bisher auch unter älteren OpenSuSE (42.2/13.2...) zu sehen war:

lpoptions -p <Druckername> -l

Unter OpenSUSE 15.3 ist die Ausgabe stark verkürzt und ich erhalte statt 24 Zeilen nur noch 7Leider werden diese Druckoptionen von unseren Tools am PC ausgewertet. Was hat sich da geändert. Seit cups 2.0 werden lokale Warteschlangen für Netzwerkdrucker gebildet und auch reduzierte PPD von Remote Druckern ohne Filtereinträge unter /etc/cups/ppd gelagert. Warum verschluckt cups diese Optionen. Ich vermute, dass die Versionen zwischen OpenSuSE 15.1 und 15.3 trotz gleicher Versionen weit auseinanderliegen, weil es sich bei 15.3 um die SLE-Variante handelt.

cups-2.2.7-3.26.1.x86_64 (15.3)
cups-2.2.7-lp151.6.6.1.x86_64 (15.1)

Danke wir haben aber aktuell noch ein gravierendes Problem: Es wurden reichlich neue Fujitsu Esprimo D7010n mit Intel Grafik beschafft, die entweder beim Anmelden und danach flackern oder eckige schwarze Flecken auf dem Bildschirm produzieren. Nur mit einem alten Mesa-Paket MesalibEGL1 18.3.2 23.11. ist das Flackern weg, dafür wird der Hauptspeicher dann voll. Nach ca 1 Stunde steht der Rechner dann. Entweder es flackert oder man muss den Speicher irgendwie im Hintergrund leeren. Ab 15.2 und 15.3 flackert es nur noch. Ich denke, die neuen IntelChipsätze werden noch nicht unterstützt. Ein Abschalten des Compositing im KDE hilft leider auch nicht. Nur ein Neustart des kwin_x11 hilft zeitweise.

inxi -G zeigt auch weniger an als bei den anderen Intel Esprimo Systemen.

Graphics:

Device-1: Intel driver: i915 v: kernel

Display: server: X.org 1.20.3 driver: intel

unloaded: fbdev,modesetting,vesa tty: 80x25

Message: Advanced graphics data unavailable in console for root.

Schön, in unserer Firma wird OpenSuSE 15.1 eingesetzt. Wichtig wäre, wenn man eine alte Plasm-Konfiguration für auch für 15.4 weiterverwenden könnte. es hat einige Anpassungen zwischen 5.12.5 und 5.12.6 gegeben, da mussten wir Migrationsscripte laufen lassen. Zwischen 5.12 und 5.18 war das kompatibel

Ich hoffe, dass man keine großen Anpassungen an der Konfig für 5.24 machen muss, das war zwischen 5.12.5 und 5..12.6 der Fall. Damals hatte man den LocalPath für selbstdefinierte Icons z.B. für Firefox usw in der Leiste eingeführt. Komplexe Änderungen in der

plasma-org.kde.plasma.desktop-appletsrc

sollten vermieden werden oder bei den Awendern durch Updatescripte erledigt werden

Nun mal ganz entspannt: In Echtzeit arbeitende Virenscanner sorgen für Sicherheit, in dem Moment, in dem jemand mit einer Malware in Berührung kommt und diese Software arbeitet direkt im Kernel! Sicherer gehts nun wirklich nicht. Und OpenSuSE 15.1 ist nun gerade mal 10 Monate aus der Wartung. Die Haupteinfallstore sind aktuell gehalten. Uns ist noch kein einziger Linux-Virus begegnet. Zudem gibt es eine Firewall-Kaskade.
Es würde mich nur interessieren, ob die Konstellation Kernel aus 15.2 und OS auf 15.1 Seiteneffekte hat. Bis jetzt sieht es nicht danach aus.

Wir haben jetzt 2 Rechner, die mit OpenSuSE 15.1 liefen, nur kernelmässig von

5.11.16-lp151.3-default
auf

5.3.18-lp152.92-default

upgedatet und die Probleme sind beseitigt:
1.) nicht erkannte Netzewrkkarte (sie heisst jetzt aber em1 statt eth0)

2.) 2ter Bildschirm am 2ten Displayport, was vorher auch nicht ging)
Nun die Frage, wir müssen jetzt alle 10000 bis 12000 Rechner auf den neuen Kernel updaten, weshalb die Antivirensoftware neu kompiliert und mit ausgerollt werden muss. Frage nun, was könnte in dieser nicht distributionskonformen Situation an Fehlern auftreten, Inwieweit könnte es Probleme geben und was müsste man jetzt noch machen? Müssen wir noch kernel-firmware oder etwas anders nachziehen. In erster Näherung sehe ich keine Probleme, weil 15.1 und 15.2 sehr dicht beieinanderliegen.
Ich möchte aber nichts riskieren

Hier ist die vollständige Ausgabe:

00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (11) I219-LM [8086:0d4c]
        Subsystem: Dell Device [1028:0b8a]

Etwas OffTopic,

kein Problem, wir haben einen Virenscanner (mit Support), der in Echtzeit über den Kernel analysiert und ggf. blockt und außer reichlich Windows-Viren/Würmer haben wir noch nie einen echten Linux-Virus abgefangen. Zudem ist die Proxykette wasserdicht. Die entscheidenden Patche (Log4J) bekommen wir über die lfd. Anwendungen ins System. Zudem gibts die Factory und das aufwärtskompatible OpenSuSE 15.2. Probleme macht neue Hardware und man bekommt ältere Systeme nicht mehr in den benötigten Mengen, zumindest nicht vom Hoflieferanten. Es wäre schön, wenn das Dell Intel-basierende Onboard NIF mit 15.1 funktionieren würde