Beiträge von wn48z

    Viele Distributionen pflegen Backports von Fixes in frühere Version ein um nicht gleich auf die nächsthöhere Version wechseln zu müssen.


    Das macht auch durchaus Sinn. Vielleicht benötigt openssh 7.1 eine höhere openssl Version als diejenige die gerade bei Tumbleweed verwendet wird und dann muss man auch diese nachziehen usw. Ausserdem verhalten sich neuere Versionen zu Abhängigkeiten im OS vielleicht anders. Also man macht ein Update von einem RPM und dann funktioniert plötzlich ein anderes Programm nicht mehr wie erwartet. Eigentlich sollten die RPMs das zwar gegenprüfen - aber eine Garantie hierfür gibt es nicht.


    Wenn man nun das Update vom Packman Repo einspielt verlässt man ausserdem mit diesem RPM den Updatepfad von SuSE - d.h. künftige Securityfixes müssen dann auch vom Packman Repo kommen. Kann sein, dass das Packman Repo ebenso zeitnah solche liefert wie SuSE selbst - muss aber nicht so sein.


    Ich halte es daher immer so, dass ich nur Upgrade wenn ich eine neue Funktion der höheren Version dringend benötige - in jedem anderen Fall sollte man auf der Originalversion und im Patchpfad von SuSE bleiben.

    Man kann auch mit dem Zypper Befehl nach den CVE Patches suchen:


    Code
    # zypper list-patches --cve
    # zypper list-patches --cve=2016-0777


    Beispiel:

    Code
    # zypper list-patches --cve=2015-8704
    Loading repository data...
    Reading installed packages...
    
    
    Issue | No.       	| Patch        	| Category | Severity  | Interactive | Status
    ------+---------------+------------------+----------+-----------+-------------+-------
    cve   | CVE-2015-8704 | openSUSE-2016-70 | security | important | ---     	| needed


    Hier wird dann auch die Patchnummer von openSuSE angezeigt (openSUSE-2016-70), welche man im Link des Beitrages zuvor sieht. Wie sieht das bei Tumbleweed aus, wie werden dort die Patches benannt?

    Normalerweise wird Logrotate via cron.daily ausgeführt und das entspricht der Zeit täglich 15min nach der letzten Systembootzeit. Um das klar zu definieren kann man aber in der Datei:


    /etc/sysconfig/cron


    die Variable DAILY_TIME setzen:


    DAILY_TIME="00:00"


    Dann läuft logrotate immer Nachts um 24:00. Vorausgesetzt, der Rechner läuft um diese Zeit :)


    Diese Variable wirkt sich übrigens auf alle Dienste aus, die via cron.daily gestartet werden.

    Als Serversystem (ohne X11) macht sich Leap 42.1 bisher sehr gut. Ich habe zwei solcher System seit Release im 7x24h Einsatz und bisher nicht das geringste zu bemängeln.

    Ist dieses Cablecom Netzwerk ein 8er Subnetz - also 46.140.121.240/29?


    Dann würde man eine saubere Reverse Zone so definieren:


    In der named.conf

    Code
    zone "240/29.121.140.46.in-addr.arpa" in {
        	type        	master;
        	file        	"rev.46.140.121";
    };


    Dann das Zone-File rev.46.140.121:


    Vergleiche dazu auch die RFC2317:
    https://tools.ietf.org/html/rfc2317

    Ansonsten lassen sich gewisse ominöse ipv6 Fehlermeldungen im Bind Log damit verhindern, dass man in der Konfiguration die ipv6 Sachen auskommentiert und danach den named Daemon mit dem Argument "-4" startet.


    Dies kann man via sysconfig einstellen:

    Code
    NAMED_ARGS="-4"


    So läuft Bind dann nur mit ipv4 Unterstützung.

    Kannst Du mir mal zeigen was Du gemacht hast um festzustellen, dass der DNS den lokalen Dateinamen nicht aufgelöst hat? Also mit welchen Befehlen hast Du welche Aussage vom DNS bekommen?


    Die ipv6 Fehlermeldungen im Log sind leicht wegzubekommen - aber zeige mir doch erst wie Du getestet hast.