Fedora: Kernelupdates für BleedingTooth verfügbar

Moin, wie ich gerade gesehen habe, sind die Patche für die 5.8er Kernels bereits in Fedora eingepflegt und die Kernel bereitgestellt worden.

Fedora: Kernelupdates für BleedingTooth verfügbar

This update contains patches for the BleedingTooth CVEs.
The 5.8.15 stable kernel update contains a number of important fixes across the tree.
The 5.8.14 stable kernel update contains a number of important fixes across the tree.

IN YOUR FACE, ANDROID. <24h, so geht das mit Kernelupdates bei Sicherheitslücken!

Danke Justin.

FunFact: Einige Mirrors habe die Updates noch nicht im Programm. Das resultiert in einer langen Fehlermeldungskette beim DNF, wird aber am Ende niemanden stören 🙂

[MIRROR] kernel-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for https://mirror.dogado.de/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-5.8.15-101.fc31.x86_64.rpm (IP: 185.3.234.216)
[MIRROR] kernel-core-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for https://mirror.dogado.de/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-core-5.8.15-101.fc31.x86_64.rpm (IP: 185.3.234.216)
[MIRROR] kernel-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for http://mirror.dogado.de/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-5.8.15-101.fc31.x86_64.rpm (IP: 185.3.234.216)

[MIRROR] kernel-modules-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for http://ftp.icm.edu.pl/pub/Linux/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-modules-5.8.15-101.fc31.x86_64.rpm (IP: 2001:6a0:0:31::2)
[MIRROR] kernel-core-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for https://ftp.icm.edu.pl/pub/Linux/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-core-5.8.15-101.fc31.x86_64.rpm (IP: 2001:6a0:0:31::2)
[MIRROR] kernel-modules-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for https://ftp.icm.edu.pl/pub/Linux/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-modules-5.8.15-101.fc31.x86_64.rpm (IP: 2001:6a0:0:31::2)

Ein anderer Mirror hatte das Paket dann doch schon, er ist nur nicht der schnellste.

Netflix, Firefox und die 1080p – Teil 3

Endlich! Das aktuelle Firefoxproblem mit der 1080p Wiedergabe von Netflix ist gelöst.

Nachdem im Truedread Build die nötigen Anpassungen bereits vor einigen Tagen gemacht wurden, konnte endlich der Pull-Request bei Vladikoffs FireFox Version eingebaut werden.

Netflix, Firefox und die 1080p

Nun müßte man das nur noch eingebaut bekommen und da haperts gerade! Es ist etwas Handarbeit nötig um das im Firefox zu installieren. Ich habe für Euch aus den Sourcen einen AddOn-Build gebaut. Damit Firefox das unsignierte Addon schluckt, muß zuerst die Signaturprüfung abgeschaltet werden.

Dazu gebt Ihr in die Addresszeile vom Firefox „about:config“ ein und sucht nach „xpinstall.signatures.required“ und ändert es auf „false“ ( einfach „true“ Doppelklicken ).

Danach könnt Ihr dann netflix_1080p-1.9.xpi ohne Probleme installieren und habt wieder 1080p Wiedergabe im Firefox. Das File heißt noch 1.9 um es mit dem aktuellen Masterstand in Übereinstimmung zu halten, aber vermutlich wird auch Vladikoff auffallen, daß er vergessen hat die Versionnummer anzuheben 🙂

Ich vermute mal, daß es in den nächsten Tagen auch einen signierten Build geben wird. Allerdings muß man dazu bei Mozilla im DevNetzwerk angemeldet sein und da habe ich keine Lust zu 🙂

Quickfix: Exim <= 4.91 for CVE-2019-10149

Ok, Exim 4.87 < 4.92 has a serious security hole, which can also be trivially exploited: CVE-2019-10149

A lot of fuss has been made about the weak point, but unfortunately nobody has been able to tell whether it can be fended off without an update. Let’s have a look at what it’s all about.

What is the trivial exploit?

As a local attacker it is enough to send an email with Exim’s sendmail replacement to „<${run{bash}}@zieldomain.de>“. At the moment it is delivered, the embedded command (here bash) is executed as root.

The whole thing can also be executed remotely, so it’s a really nasty vulnerability. But only versions > 4.87 < 4.92 are affected. For this, however, various things must be allowed in the config, which is only partially the case in the default configuration. For example, you cannot include a „/“ in the command because these are illegal characters. This of course restricts the attacker from being strong.

Since even on the exim list there was a lot of secrecy in the game until today, here are the equally trivial countermeasures:

Countermeasures

Just don’t allow „$“ in email addresses 😀 That’s it. There only ARGS came to my mind 😀

This comes into your Exim configuration, then restart Exim:

acl_check_rcpt:

deny message = Restricted characters in address
domains = +local_domains
local_parts = ^[.] : ^.*[\$@%!/|]

deny message = Restricted characters in address
domains = !+local_domains
local_parts = ^[./|] : ^.*[\$@%!] : ^.*/\\.\\./

….

acl_check_mail:

drop message = Restricted characters in address
condition = ${if match{$sender_address}{\N.*\$.*run.*\N}{1}{0}}}

# IMPORTANT: Write in before these instructions, otherwise it’s not working!

accept hosts = +relay_from_hosts

This chokes off the attacker before the email is delivered.

The better countermeasure would of course be to switch to a more recent Exim. But as it is, there are always „reasons“ why and why something can’t be updated.

Nobody gets his teeth apart…

What annoys me most of all about the gap is that this cheap countermeasure does not appear in the Advisory of Qualys and in the hints of the Exim Team. With the Exim people I can still understand it, because they had fixed the bug independently already at the beginning of the year and can say justly: Just do updates.

Qualyss looks different, they write :

As per the distros list policy:

Below is an abridged version of our advisory (with all the vulnerability
details, but without exploitation details); we will publish the complete
version in 24 hours, or as soon as third-party exploits are published,
whichever happens first.

We believe that it makes no sense to delay this any longer than that:
this vulnerability is trivially exploitable in the local and non-default
cases (attackers will have working exploits before that, public or not);
and in the default case, a remote attack takes a long time to succeed
(to the best of our knowledge).

Nice that you omitted the exploit, how about the workaround, so that the good guys have a small lead?  And this cryptic hint „a remote attack takes a long time to succeed“ means that you should restart your exim every 24h, because there is some shit with „tar pits“.

These are usually spam traps that respond so slowly that the attacker’s attack is just as tough as in a tar pit, up to „no progress at all“. The attackers take advantage of something like this here. Therefore once in the cron „killall -9 exim; systemctl restart exim“ daily  : Done.

A follow-up of the aftermatch and some real exploits can be found here: Exim – Exploit in der Wildnis unterwegs

Translated with www.DeepL.com/Translator

BTW: yes, ofcourse i could have written it in english myself, but the translation isn’t that bad 😉

XenServer zu alt um Kernel 5.0 zu laden

Wer XenServer und Kernel 5.0.x einsetzen will, sollte jetzt gut aufpassen, sonst => VM Streik

Kernelimage zu neu für XenServer 6.2.x

Da es sich um etwas handelt, daß international wichtig sein könnte, gibts das auf Deutsch und English,
so don’t wonder if you just understand halve of it 😉

Ihr wollt Eure VM booten, bekommt aber diesen Fehler?
You wanne boot your VM and get this message ?

xenopsd internal error: XenguestHelper.Xenctrl_dom_linux_build_failure(2, “ panic: xc_dom_core.c:616: xc_dom_find_loader: no loader\\\““)

Das passiert, weil das Kernelimage mit einer neuen Compressionmethode gepackt wurde, die das alte XEN nicht kann.  The reason is, that your kernel image file is compressed with a new algorithm, your old XEN can’t handle.

Als erstes brauchen wir die UUID der VM:
First, get the UUID of your VM:

xe vm-list | grep -A5 -B5 <vmname>

Um das zu beheben, braucht man den Befehl: xe-edit-bootloader.sh -u uuid
To fix your vm, you need to execute : xe-edit-bootloader.sh -u uuid

/root/xe-edit-bootloader.patched.sh -u 317fb132-283a-56c6-1627-8b39cf944148 -p 1

Nun kann man die Reihenfolge der Bootmenüeinträge so ändern, daß der bisherige Kernel vorn steht. Dann speichern und Editor beenden und jetzt sollte die VM auch wieder starten.
Now you can change the order of your grub menuentries to the last working kernel being first. When you have saved and exited the editor, the parition will be unmounted and you can start your VM again.

Tipps – Additional hints for you

Der Befehl mountet die Systemplatte der VM und lädt die gebräuchliste grub.conf. Das wird aber vermutlich nicht auf anhieb klappen. Man muß etwas über das Festplattenlayout der VM wissen:
This will mount your VM’s main disk and access the most likely location of your grub.conf, but that will not work without your knowlage of the VMs structure:

-p: Partition number to mount (default: none)
-f: Location of bootloader config file to edit

Wenn man eine traditionelle SDA1 SDA2 Partitionierung in der VM hat, dann gibt man -p die Partitionsnummer der Platte an, wo man /boot/ finden kann. Wer LVM in der VM benutzt, dürfte jetzt so ziemlich am Arsch sein. Kleiner Tip, exportiert die VM auf einen neuern XenServer.

If you have a sda1 and sda2, where sda2 is swap, that -p 1 will mount partition 1 and your good to go.
If you have i.e. a seperate boot partition, you need to know it’s number.
IN CASE you have LVM inside your VM, i guess your screwed now. In this case, export it to a newer XenServer Version.

Weil sich Grub1+2 ein bisschen uneinig wegen der Verzeichnispfade sind, kann man Position der grub.cfg mit -f angeben. Wer eine eigene /boot Partition hat, braucht dann nicht /boot/ hinschreiben, -f grub2/grub.cfg reicht.

Grub1+2 differ a bit, where to find the grub.conf file. Thats where -f will be handy. You can just tell it, if you knew it: -f /boot/grub2/grub.cfg   should usally work, except, you are already on /boot (seperate partition) then it’s just -f grub2/grub.cfg .  As theres only a texteditor loaded, you could try to change other files too 😉

Ich habe einen gepatchten xe-edit-bootloader, der mir erlaubt, gleich die ganze Platte in Dom0 zu mounten. d.h. ich kann alles in der VM anpassen, nicht nur Textdateien, was extrem praktisch ist.
Why is my xe-edit-bootloader.sh  patched? because i adapted it to just mount the disk and wait for me to explore the disk. That’s so helpfull, you won’t believe it.

Bei einigen Systemen kann durch setzen der $EDITOR Variablen auf „/bin/bash“ eine Shell bekommen, aber ich rate davon ab, daß auf Produktivsystemen auszuprobieren, das könnte böse Nebenwirkungen haben.
In rare cases it’s possible to trick the script with the $EDITOR variable set to „/bin/bash“ to open a bash shell for you, but i really suggest not to mess with your dom0 on a production system.

Firefox 65 und das Tableistendrama

Es ist eigentlich mal wieder Zeit den Rick rauszukehren: Die Firefoxlayouter haben am HTML für die Oberfläche rumgespielt und damit die Anpassungen für die Tableiste verkompliziert. Rick bleibt aber im Schrank, ich hab keine Lust mehr mich noch länger mit dem Scheiss zu beschäftigen, als es mich jetzt schon wieder gekostet hat!

Die Lösung – userChrome.css

Wie schon in dem Beitrag Der schnellste Firefox nachzulesen war, kann man einiges über die userChrome.css rückgängig machen, was einem an dem wohl langsamsten Firefox aller Zeiten nicht gefällt. Und hier kommt es auch schon:

/* Tab bar below Navigation & Bookmarks Toolbars */
#nav-bar { /* main toolbar */
-moz-box-ordinal-group: 1 !important;
box-shadow: none !important;
}
#PersonalToolbar { /* bookmarks toolbar */
-moz-box-ordinal-group: 2 !important;
height: 100px;
}
#TabsToolbar { /* tab bar */
-moz-box-ordinal-group: 3 !important;
padding-top: 0px !important;
top: 92px;
position: absolute;
}

.tabbrowser-tab,#new-tab-button {
display: inline-block !important;
width: auto !important;
background:red;
height: auto !important;
min-height: 33px;
}

#personal-bookmarks {
display: inline;
}

#personal-bookmarks {
vertical-align: top;
position:absolute;
margin-top: -25px !important;
}

vbox#titlebar {
position:relative;
}

toolbox#navigator-toolbox {
position:relative;
}


/* Clean up spacing */
.titlebar-placeholder {
display: none !important;
}
toolbarbutton.bookmark-item {
padding-top: 2px !important;
padding-bottom: 2px !important;
}

/* If you display either:
(1) The title bar, or
(2) On Windows, the menu bar
You might not want the following extra space above the main toolbar. 
In that case, delete the following rule:
*/
#navigator-toolbox {
padding-top: 20px !important;
}

/* Background for Light and Dark themes */
#main-window[lwthemetextcolor="bright"] #TabsToolbar, 
#main-window[lwthemetextcolor="dark"] #TabsToolbar {
background-color: var(--chrome-secondary-background-color) !important;
background-image: none !important;
}
#main-window[lwthemetextcolor="dark"] .scrollbutton-up,
#main-window[lwthemetextcolor="dark"] .scrollbutton-down,
#main-window[lwthemetextcolor="dark"] .tabs-newtab-button,
#main-window[lwthemetextcolor="dark"] #new-tab-button,
#main-window[lwthemetextcolor="dark"] #alltabs-button {
fill: var(--lwt-text-color) !important;
}
/* Left and right borders on Win 7 & 8, but not on 10 and later: */
@media (-moz-os-version: windows-win7), (-moz-os-version: windows-win8) {
/* Vertical toolbar border */
#main-window[sizemode=normal] #navigator-toolbox > vbox#titlebar > toolbar#TabsToolbar {
border-left: 1px solid hsla(240,5%,5%,0.3) !important;;
border-right: 1px solid hsla(240,5%,5%,0.3) !important;;
background-clip: padding-box;
}
}

/* Override vertical shifts when moving a tab (9 Jan 2018) */
#TabsToolbar[movingtab] {
padding-bottom: 0 !important;
}
#TabsToolbar[movingtab] > .tabbrowser-tabs {
padding-bottom: 0 !important;
margin-bottom: 0 !important;
}
#TabsToolbar[movingtab] + #nav-bar {
margin-top: 0 !important;
}

/* tab top border roundness */
#TabsToolbar .tabs-newtab-button,
#TabsToolbar .tabbrowser-tab,
#TabsToolbar .tabbrowser-tab .tab-stack,
#TabsToolbar .tabbrowser-tab .tab-background,
#TabsToolbar .tabbrowser-tab .tab-content {

border-top-left-radius: 8px !important;
border-top-right-radius: 8px !important;
background-color: #f4f4f4;
border-top: 1px solid #d8d8d8;
border-left: 1px solid #d8d8d8;
border-right: 1px solid #d8d8d8;
border-image: none !important;
}

#TabsToolbar .tabbrowser-tab .tab-stack {
margin-left: 1px !important;
margin-right: 1px !important;

}

#TabsToolbar .tabbrowser-tab::after,
#TabsToolbar .tabbrowser-tab::before {
border-left: none !important;
}

/* tab-background tab-loading-burst tab-content */
/* tab-stack ist der gesamte tab */

.tab-line {
display: none;
}
/* remove colored line above each tab */

#TabsToolbar .tabbrowser-tab .tab-line {
visibility: hidden;

}

Erwartet nicht zuviel, es ist nicht perfekt und könnte bei abweichenden Fonts oder DPI Zahl im System angepaßt werden müssen. Ich habe die Stellen markiert, die dann vermutlich anzupassen sind.

Kleines Update:

Sie sieht die neueste Version aus:

Erst fand ich den Gedanken, daß Tabs unterschiedlich groß sind ungewohnt, aber es hat was. Besonders wenn die alle mit „Gockel – Nachrichten …… “ anfangen :

/* Tab bar below Navigation & Bookmarks Toolbars */
#nav-bar { /* main toolbar */
  -moz-box-ordinal-group: 1 !important;
  box-shadow: none !important;
}
#PersonalToolbar { /* bookmarks toolbar */
  -moz-box-ordinal-group: 2 !important;
  height: 100px;
}
#TabsToolbar { /* tab bar */
  -moz-box-ordinal-group: 3 !important;
  padding-top: 0px !important;
  top:    92px;
  position: absolute;
}

.tabbrowser-tab,#new-tab-button {
  display: inline-block !important;
  width: auto !important;
  min-width: 10em !important;
  height: auto !important;
  min-height: 33px;
}
tab#tabbrowser-tab {
  max-width: auto !important;
}

#personal-bookmarks {
  display: inline;
}

#personal-bookmarks {
  vertical-align: top;
  position:absolute;
  margin-top: -25px !important;
}

vbox#titlebar {
  position:relative;
}

toolbox#navigator-toolbox {
  position:relative;
}


/* Clean up spacing */
.titlebar-placeholder {
  display: none !important;
}
toolbarbutton.bookmark-item {
  padding-top: 2px !important;
  padding-bottom: 2px !important;
}

/* If you display either:
   (1) The title bar, or
   (2) On Windows, the menu bar
   You might not want the following extra space above the main toolbar. 
   In that case, delete the following rule:
*/
#navigator-toolbox {
  padding-top: 20px !important;
}

/* Background for Light and Dark themes */
#main-window[lwthemetextcolor="bright"] #TabsToolbar, 
#main-window[lwthemetextcolor="dark"] #TabsToolbar {
  background-color: var(--chrome-secondary-background-color) !important;
  background-image: none !important;
}
#main-window[lwthemetextcolor="dark"] .scrollbutton-up,
#main-window[lwthemetextcolor="dark"] .scrollbutton-down,
#main-window[lwthemetextcolor="dark"] .tabs-newtab-button,
#main-window[lwthemetextcolor="dark"] #new-tab-button,
#main-window[lwthemetextcolor="dark"] #alltabs-button {
  fill: var(--lwt-text-color) !important;
}
/* Left and right borders on Win 7 & 8, but not on 10 and later: */
@media (-moz-os-version: windows-win7), (-moz-os-version: windows-win8) {
  /* Vertical toolbar border */
  #main-window[sizemode=normal] #navigator-toolbox > vbox#titlebar > toolbar#TabsToolbar {
    border-left: 1px solid hsla(240,5%,5%,0.3) !important;;
    border-right: 1px solid hsla(240,5%,5%,0.3) !important;;
    background-clip: padding-box;
  }
}

/* Override vertical shifts when moving a tab (9 Jan 2018) */
#TabsToolbar[movingtab] {
  padding-bottom: 0 !important;
}
#TabsToolbar[movingtab] > .tabbrowser-tabs {
  padding-bottom: 0 !important;
  margin-bottom: 0 !important;
}
#TabsToolbar[movingtab] + #nav-bar {
  margin-top: 0 !important;
}

   /* tab top border roundness */
#TabsToolbar .tabs-newtab-button,
#TabsToolbar .tabbrowser-tab,
#TabsToolbar .tabbrowser-tab .tab-stack,
#TabsToolbar .tabbrowser-tab .tab-background,
#TabsToolbar .tabbrowser-tab .tab-content {

	border-top-left-radius: 8px !important;
	border-top-right-radius: 8px !important;
        background-color: #f4f4f4;
        border-top: 1px solid #d8d8d8;
        border-left: 1px solid #d8d8d8;
        border-right: 1px solid #d8d8d8;
        border-image: none !important;
   }

#TabsToolbar .tabbrowser-tab .tab-stack {
        margin-left: 1px !important;
        margin-right: 1px !important;

}

#TabsToolbar .tabbrowser-tab::after,
#TabsToolbar .tabbrowser-tab::before {
	border-left: none !important;
}

/* tab-background tab-loading-burst tab-content */
/* tab-stack ist der gesamte tab */

.tab-line {
	display: none;
}
/* remove colored line above each tab */

#TabsToolbar .tabbrowser-tab .tab-line {
      visibility: hidden;

}

 

Mitten im DBUS Update poweroff

Es fing wie immer harmlos an, obwohl, tut es das nicht immer ?  Hmm.. also.. es fing harmlos an :

Berlin: „0:10 Ping…Bist Du da ?“
Ich: „0:12 Ja, klar. Was gibt es denn?“
Berlin: „0:12 Mein Rechner bootet nicht mehr..Ich schick Dir mal ein Foto“

Womit das Unheil seinen Lauf nahm …Fehlermeldung von system-logind und anderen DienstenIch: „Also logind geht nicht ? Starten wir doch mal mit einem anderen Kernel… “
Berlin: „Mist, gleiches Ergebnis.“

Das ist natürlich eine Kaskade, wenn ein wichtiger Dienst nicht startet und andere auf den angewiesen sind, dann starten die auch nicht. Es wird daher nur eine Sache nicht gehen, das stand zu dem Zeitpunkt eigentlich schon fest.

Nun startet man den Rechner im Debugmodus…

Dazu im Kernelauswahlmenü auf die Taste „e“ drücken und in der Zeile mit „linux /vmlinuz….“ am ENDE “ 1″ anfügen. Dann mit STRG+X booten.

Was nun passiert ist, daß sobald ein Minimalsystem von der Platte startet, der Admin sein Passwort eingeben kann und in der Shell den Fehler beheben kann, wenn man ihn denn findet.

Ich: „schauen wir mal in die Logs vom letzten Boot..  journalctl –boot=-1“

Fehler von systemd im letzten BootlogIch: „Connection timed out… also hat er versucht einen Systemdienst zu kontaktieren, der nicht geantwortet hat. Wir starten den mal so, vielleicht gibt es noch mehr Ausgabe“

Ich: „systemctl start systemd-logind“
Berlin: „Nichts..“
Ich:  „Also der logind will nicht…  suchen wir mal die Service Datei“

[root /]# locate logind.service
/usr/lib/systemd/system/systemd-logind.service
/usr/lib/systemd/system/multi-user.target.wants/systemd-logind.service
/usr/share/man/man8/systemd-logind.service.8.gz

[root /]# cat /usr/lib/systemd/system/systemd-logind.service | grep Exec
ExecStart=/usr/lib/systemd/systemd-logind
MemoryDenyWriteExecute=yes

Ich: „Na dann starten wir mal systemd-logind von Hand. Gib ein was in der ExecStart hinter dem = steht“
Berlin: „Passiert nichts“
Ich: „Also jetzt müßte man strace benutzen, das traue ich Dir zu, aber die Ausgabe zu interpretieren ist eine Sache für sich. Ich muß auf Deinen Rechner.“

Zu dem Zeitpunkt liefen außer dem PID=1 Prozess noch genau 3 andere auf dem Rechner 😀

Ich: „start mal das Netzwerk … systemctl start network“
Berlin: „Geht nicht. Hängt.“
Ich: „Mist.. aber kein Beinbruch.. STRG+C und dann brauche ich mal die IP der Portfreigabe für SSH aus Deinem Fritz-Router.“

Jetzt muß man dazu wissen, daß man in der Fritzbox eine Portfreigabe für den SSHD machen kann und die leitet man auf die feste LAN IP des Pcs, den man von außen kontaktieren will. Das hat den Vorteil, daß der befreundete Admin, jederzeit helfen kann. Es setzt aber auch voraus, daß das Netzwerk da ist, was es nicht war…

Nachhilfe – Wie konfiguriert man eine Netzwerkkarte von Hand

Nachdem die IP kennt, gibt man ein:

ifconfig enp1s5  192.168.178.22 network 255.255.255.0 up
route add default gw 192.168.178.1
/usr/sbin/sshd

Wobei man hier natürlich die ermittelte IP einträgt und das richtige Netzwerkkarteninterface wählen muß. Wer seins nicht kennt, kann das mit „ip l“ auflisten:

# ip l
1: lo: <loopback,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000</loopback,
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 50:13:3e:47:35:31 brd ff:ff:ff:ff:ff:ff

Ab der Stelle kann man dann per SSH auf dem Rechner einloggen, was sehr praktisch ist. Es stellte sich jetzt recht schnell raus, daß die ganzen Programm dem Init Prozess eine Message schicken wollen, aber keine Antwort mehr bekommen. Was daran lag, daß der DBUS-Daemon nicht lief. Jetzt konnte man endlich suchen, was dafür die Ursache war und das geht z.b. so :

[root /]# locate dbus.service
/usr/lib/systemd/system/dbus.service
/usr/lib/systemd/system/multi-user.target.wants/dbus.service
/usr/lib/systemd/user/dbus.service
/usr/lib/systemd/user/dbus.service.d
/usr/lib/systemd/user/dbus.service.d/flatpak.conf
[root /]# cat /usr/lib/systemd/system/dbus.service | grep Exec
ExecStart=/usr/bin/dbus-daemon –system –address=systemd: –nofork –nopidfile –systemd-activation –syslog-only
ExecReload=/usr/bin/dbus-send –print-reply –system –type=method_call –dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig

Also starten wir den dbus-daemon von Hand und stellen fest, daß er nicht startet. In dem Fall, weil seine libdbus.so.3 ein Target nicht enthielt, was nur sein kann, wenn die Version des Daemons und der lib nicht zusammen passen.

Ein „rpm -qa | grep dbus | sort “ brachte dann auch gleich den Fehler zutage. Statt 1.11.18 war der dbus-daemon nur als 1.11.16 installiert. Offensichtlich war der Rechner beim Update unsanft gestört worden oder der Updateprozess hing aus irgendeinem anderen Grund. Das kann man ja leicht mit einem Update beheben, oder ? 😉

Wie sich rausstellte, konnte man das nicht, weil für das Update durch RPM der DBUS-Daemon laufen müßte. Nun Starten Sie mal einen Update um den DBUS Daemon zu updaten, weil der nicht startet, weil er die falsche Version hat.

Das Ende naht ?

Hier hätte das Ende der Geschichte sein können, weil zu dem Zeitpunkt auch keine Livedisk vorhanden war, um den Rechner mal sauber zu starten und in einer Chroot dann das ausstehende Update zu applien.

Hey… wir haben doch einen SSH Zugang .. da geht doch auch … SCP 😀 Und wie der Zufall das so wollte, hatten beide Rechner das gleiche OS drauf.

Lösung:

scp /usr/bin/dbus-daemon root@externeipdeszielrechners:/usr/bin/

Dann den dbus von Hand starten und die dbus pakete installieren die noch im DNF-Cache  auf der Platte lagen. Das findet man unter /var/cache/dnf/updates…./  Da müßt Ihr ggf. mit find mal nach“.rpm“ suchen. Das Cache kann ziemlich unaufgeräumt sein.

Nun noch sauber den dbus über systemd neugestartet und „dnf update -y“  benutzen um alle ausstehenden Updates einzuspielen. Das wärs dann.

Kleiner Tip: Zwei Shells benutzen, weil der Updateprozess wird gemäß den Anweisungen in den RPMS die Dienste neustarten wollen, was wegen des nicht vorhandenen Systemstarts nicht klappt. d.h. die Hängen alle beim „systemctl start blahblah.service„, was man mit ps auxf leicht sehen kann.

Einfach die Pids von den Starts mit kill abschiessen, wir rebooten danach eh frisch.

Berlin: „2:12 Hey, da passiert was“
Ich: „2:12 Ja, ich hab den Reboot ausgelöst, sollte jetzt starten“

Jetzt sind wir fertig. Der Rechner bootet wieder und mehr als 2 Stunden hat es gedauert, denn natürlich haben wir noch einige andere Dinge probiert 😉 Da die aber nicht zur Lösung geführt haben, war ich mal so frei die Euch zu ersparen 🙂

Genauso wenig hilfreich waren :

Microsoft – Skype Zwangstrennung nach 1 Stunde reden .. args!
DTAG – DSL Zwangstrennung  mitten im Debug ! Das kann man sowas von gebrauchen wenn man einen Notfall hat!
SystemD – mangels Fehlermeldung, daß DBUS nicht gestartet werden konnte ! Das hätte die Suche ja nur um knapp 90 Minuten verkürzt! Dafür wird noch jemand bezahlen … muharharhar …

 

 

WordPress Traffic Stats Widget defekt

Wer in seinem WordPress Blog das „Traffic Stats Widget“ einsetzt, der könnte ein Problem haben. Seit dem 20.9. hat unser Plugin nichts mehr in die Logdatenbank geschrieben und damit sind fälschlicherweise meine Zugriffszahlen für September und Oktober leicht rückläufig, um nicht zu sagen, nicht mehr vorhanden 😉

Der Fix dafür ist recht einfach:

In der Datei „wp-content/plugins/traffic-stats_widget/wp-traffic-stats-widget.php“ Zeile 174, ersetzt man:

 $data = array (
 'IP' => $ip,
 'Time' => time(),
 'IS_BOT'=> tsw_is_bot(),
 'IS_HIT'=> is_hit($ip)
 );
 $format = array ('%s','%d', '%b','%b');
 $wpdb->insert( $table_name, $data, $format );

mit :

if (!$user_count) {
    $wpdb->query("INSERT INTO $table_name set IP='".$ip."', Time='".time()."', IS_BOT ='". tsw_is_bot() ."', IS_HIT='". is_hit($ip)."'");
}

Damit werden die Zugriffe wieder in die Datenbank eingetragen und die Stats zeigen in einigen Tagen wieder normale Werte an 😀

WPA2 Fix – erfreulich fix

Kaum das die Welt von dem katastrophalen WPA2 Bug erfahren hat, da ist er auch schon wieder aus der Linux Welt verschwunden:

Oct 17 10:01:07 INFO Upgraded: wpa_supplicant-1:2.6-3.fc25.1.x86_64

Und das war drin :

* Mo Okt 16 2017 Lubomir Rintel <lkundrak@v3.sk> – 1:2.6-3.1
– hostapd: Avoid key reinstallation in FT handshake (CVE-2017-13082)
– Fix PTK rekeying to generate a new ANonce
– Prevent reinstallation of an already in-use group key and extend
protection of GTK/IGTK reinstallation of WNM-Sleep Mode cases
(CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081,
CVE-2017-13087, CVE-2017-13088)
Prevent installation of an all-zero TK*
– TDLS: Reject TPK-TK reconfiguration
– WNM: Ignore WNM-Sleep Mode Response without pending request
– FT: Do not allow multiple Reassociation Response frames

*) War der Fall mit dem 00000000 Key, was in dem KRACK Video zu sehen war und auch in Android 6 steckt. Da hilft dann auch nur ein Smartphoneupdate.

Es bleibt nur die Frage, was mit all den Android Altgeräten ohne Updates passiert. Werden die jetzt endgültig weggeworfen, weil man nicht mal mehr im heimischen WLAN damit surfen kann ?

Fedora – PHP 7 – ZipArchive

Wer mit Fedora 25+ die Meldung „PHP Fatal error: Uncaught Error: Class ‚ZipArchive‘ not found in /www/pages/….“ sieht, wenn er eine Webanwendung installiert, der braucht folgenden Fix:

libzip-1.1.3-1.fc25.x86_64
php-pecl-zip-1.13.5-1.fc25.x86_64

Dafür das in die Konsole eingeben:

dnf install php-pecl-zip

und dann ggf. noch einen Neustart seines Webservers, wenn man PHP als Modul einsetzt, was man nicht machen sollte.

GDM crasht im Endlosloop

Heute morgen der Schreck des Tages: Ein Login in Cinnamon war nicht möglich.

Der Versuch endete einem erneuten Loginscreen. Auch Gnome war nicht zur Kooperation zu bewegen. Nachdem ich die Xorg Logs gelesen hatte, stach mir die Datei „gnome-settings-daemon.desktop“ ins Auge, weil diese nicht „formal korrekt parsebar“ war, also der Inhalt einen Fehler hatte. Nachdem diese Desktopdatei aus /etc/xdg/autostart entfernt wurde, startete zumindest Cinnamon wieder und ich dachte, daß das Problem damit behoben sein.

Wie man sich irren kann..

Nach einem kleinen Ausflug wurde der Rechner abends neugestartet und hier kam der Schock: GDM restartete in einem Endlosloop alle paar Sekunden neu!

Nach einigen Reinstalls von GLIB -> mesa -> lightdm und glib2, die alle ohne Wirkung waren, fiel meine Aufmerksamkeit auf:

Jun  3 22:38:52 eve gnome-session: gnome-session-binary[15330]: WARNING: Unable to find required component ‚gnome-settings-daemon‘
Jun  3 22:38:52 eve gnome-session-binary[15330]: WARNING: Unable to find required component ‚gnome-settings-daemon‘
Jun  3 22:38:52 eve gnome-session-binary: Entering running state
Jun  3 22:38:52 eve gnome-session: Unable to init server: Could not connect: Connection refused
Jun  3 22:38:52 eve kernel: gnome-session-f[15337]: segfault at 0 ip 00007f94983fa4b9 sp 00007fff41c22bf0 error 4 in libgtk-3.so.0.2200.15[7f949811b000+6f9000]
Jun  3 22:38:52 eve abrt-hook-ccpp: Process 15337 (gnome-session-failed) of user 42 killed by SIGSEGV – ignoring (repeated crash)
Jun  3 22:38:54 eve dbus-daemon[15374]: [session uid=42 pid=15374] Activating via systemd: service name=’org.a11y.Bus‘ unit=’at-spi-dbus-bus.service‘ requested by ‚:1.2‘ (uid=42 pid=15380 comm=“/usr/libexec/gnome-session-check-accelerated “ label=“system_u:system_r:xdm_t:s0-s0:c0.c1023″)
Jun  3 22:44:23 eve gdm: GLib: g_hash_table_find: assertion ‚version == hash_table->version‘ failed

„Unable to find required component ‚gnome-settings-daemon'“ und das, obwohl ich die Autostartdatei wieder zurück geschrieben hatte. Hmm.. zu welchem Paket gehört die doch gleich ? Ah.. gnome-settings-daemon, klar oder ? 🙂 Während  GDM noch im Endlessloop war, reinstallierte ich dieses Paket und oh Wunder… plötzlich war alles wieder normal. Wie konnte das passieren ?  Tja, keine Ahnung .. Die Datei wurde nicht aktualisiert. Sie muß im laufenden Betrieb eine Macke abgekommen haben. Ein Hoch auf „dnf reinstall“ 😀

Beim nächsten derartigen Problem suche nicht stundenlang nach dem Fehler, dann kommt „dnf reinstall *“ zum Einsatz 😀