Category Archives: Linux

TAR und die Symlinks

Posted on by

Von Problemen mit TAR-Backups hört man zum Glück recht selten, heute schauen wir uns mal eines dieser Probleme an: Symlinks.

Wann man Symlinks nicht erhält

Schauen wir uns erstmal an um was es geht. So sieht etc/alternatives aus:

[root@s160 tmp]# ls -la /etc/alternatives/
insgesamt 68
drwxr-xr-x 2 root root 4096 2. Aug 06:22 .
drwxr-xr-x 125 root root 12288 2. Aug 06:25 ..
lrwxrwxrwx 1 root root 39 2. Aug 06:22 cifs-idmap-plugin -> /usr/lib64/cifs-utils/cifs_idmap_sss.so
lrwxrwxrwx 1 root root 25 2. Aug 06:22 ebtables -> /usr/sbin/ebtables-legacy
lrwxrwxrwx 1 root root 37 2. Aug 06:22 ifdown -> /etc/sysconfig/network-scripts/ifdown
lrwxrwxrwx 1 root root 35 2. Aug 06:22 ifup -> /etc/sysconfig/network-scripts/ifup
lrwxrwxrwx 1 root root 26 2. Aug 06:22 ip6tables -> /usr/sbin/ip6tables-legacy
lrwxrwxrwx 1 root root 34 2. Aug 06:22 ip6tables-restore -> /usr/sbin/ip6tables-legacy-restore
lrwxrwxrwx 1 root root 31 2. Aug 06:22 ip6tables-save -> /usr/sbin/ip6tables-legacy-save
lrwxrwxrwx 1 root root 25 2. Aug 06:22 iptables -> /usr/sbin/iptables-legacy
lrwxrwxrwx 1 root root 33 2. Aug 06:22 iptables-restore -> /usr/sbin/iptables-legacy-restore
lrwxrwxrwx 1 root root 30 2. Aug 06:22 iptables-save -> /usr/sbin/iptables-legacy-save
lrwxrwxrwx 1 root root 60 2. Aug 06:22 java -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/java
lrwxrwxrwx 1 root root 68 2. Aug 06:22 java.1.gz -> /usr/share/man/man1/java-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 59 2. Aug 06:22 jjs -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/jjs
lrwxrwxrwx 1 root root 67 2. Aug 06:22 jjs.1.gz -> /usr/share/man/man1/jjs-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 51 2. Aug 06:22 jre -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64
lrwxrwxrwx 1 root root 51 2. Aug 06:22 jre_11 -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64
lrwxrwxrwx 1 root root 50 2. Aug 06:22 jre_11_openjdk -> /usr/lib/jvm/jre-11-openjdk-11.0.3.7-1.fc29.x86_64
lrwxrwxrwx 1 root root 51 2. Aug 06:22 jre_openjdk -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64
lrwxrwxrwx 1 root root 63 2. Aug 06:22 keytool -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/keytool
lrwxrwxrwx 1 root root 71 2. Aug 06:22 keytool.1.gz -> /usr/share/man/man1/keytool-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 34 2. Aug 06:22 libnssckbi.so.x86_64 -> /usr/lib64/pkcs11/p11-kit-trust.so
lrwxrwxrwx 1 root root 45 2. Aug 06:22 libwbclient.so.0.14-64 -> /usr/lib64/samba/wbclient/libwbclient.so.0.14
lrwxrwxrwx 1 root root 23 2. Aug 06:22 mta -> /usr/sbin/sendmail.exim
lrwxrwxrwx 1 root root 19 2. Aug 06:22 mta-mailq -> /usr/bin/mailq.exim
lrwxrwxrwx 1 root root 29 2. Aug 06:22 mta-mailqman -> /usr/share/man/man8/exim.8.gz
lrwxrwxrwx 1 root root 24 2. Aug 06:22 mta-newaliases -> /usr/bin/newaliases.exim
lrwxrwxrwx 1 root root 15 2. Aug 06:22 mta-pam -> /etc/pam.d/exim
lrwxrwxrwx 1 root root 19 2. Aug 06:22 mta-rmail -> /usr/bin/rmail.exim
lrwxrwxrwx 1 root root 19 2. Aug 06:22 mta-rsmtp -> /usr/bin/rsmtp.exim
lrwxrwxrwx 1 root root 18 2. Aug 06:22 mta-runq -> /usr/bin/runq.exim
lrwxrwxrwx 1 root root 22 2. Aug 06:22 mta-sendmail -> /usr/lib/sendmail.exim
lrwxrwxrwx 1 root root 63 2. Aug 06:22 pack200 -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/pack200
lrwxrwxrwx 1 root root 71 2. Aug 06:22 pack200.1.gz -> /usr/share/man/man1/pack200-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 60 2. Aug 06:22 rmid -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/rmid
lrwxrwxrwx 1 root root 68 2. Aug 06:22 rmid.1.gz -> /usr/share/man/man1/rmid-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 67 2. Aug 06:22 rmiregistry -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/rmiregistry
lrwxrwxrwx 1 root root 75 2. Aug 06:22 rmiregistry.1.gz -> /usr/share/man/man1/rmiregistry-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 31 2. Aug 06:22 spf -> /usr/bin/spfquery.perl-Mail-SPF
lrwxrwxrwx 1 root root 27 2. Aug 06:22 spf-daemon -> /usr/bin/spfd.perl-Mail-SPF
lrwxrwxrwx 1 root root 47 2. Aug 06:22 spfquery-man-page -> /usr/share/man/man1/spfquery-perl-Mail-SPF.1.gz
lrwxrwxrwx 1 root root 65 2. Aug 06:22 unpack200 -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/unpack200
lrwxrwxrwx 1 root root 73 2. Aug 06:22 unpack200.1.gz -> /usr/share/man/man1/unpack200-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 15 2. Aug 06:22 whois -> /usr/bin/jwhois
lrwxrwxrwx 1 root root 37 2. Aug 06:22 whois-man -> /usr/share/man/man1/whois.jwhois.1.gz

In dem Verzeichnis schreiben Pakete Symlinks zu Programmen rein, die es im System doppelt gibt. Z.B.: OpenJDK mit Java 8 und Java 11 . Das Paket, welches zuletzt installiert oder aktualisiert wird, nagelt dort die Symlinks über. (Anm. so bin ich überhaupt erst zum Thema gekommen 😉 ).

Wenn man jetzt die Symlinks vor der „Katastrophe“ wieder haben will, entpackt man sein Systembackup. Weil /etc weit vorne im Archiv steht und so ein Backup auch schon mal 80-100 GB haben kann, bricht man i.d.R. ab, wenn tar -xvzf archiv.tgz etc/alternatives keine Ausgaben mehr macht, weil der Verzeichnispfad dann „durch“ ist. So spart man sich viiiieeel Zeit, oder auch nicht 🙂

Weil, wenn man dann in das Verzeichnis schaut sieht man das hier:

[root@s160 tmp]# ls -ls etc/alternatives/
insgesamt 0
0 ---------- 1 root root 0  2. Aug 09:30 cifs-idmap-plugin
0 ---------- 1 root root 0  2. Aug 09:30 ebtables
0 ---------- 1 root root 0  2. Aug 09:30 ifdown
0 ---------- 1 root root 0  2. Aug 09:30 ifup
0 ---------- 1 root root 0  2. Aug 09:30 ip6tables
0 ---------- 1 root root 0  2. Aug 09:30 ip6tables-restore
0 ---------- 1 root root 0  2. Aug 09:30 ip6tables-save
0 ---------- 1 root root 0  2. Aug 09:30 iptables
0 ---------- 1 root root 0  2. Aug 09:30 iptables-restore
0 ---------- 1 root root 0  2. Aug 09:30 iptables-save
0 ---------- 1 root root 0  2. Aug 09:30 java
0 ---------- 1 root root 0  2. Aug 09:30 ld
0 ---------- 1 root root 0  2. Aug 09:30 libnssckbi.so.x86_64
0 ---------- 1 root root 0  2. Aug 09:30 libwbclient.so.0.14-64
0 ---------- 1 root root 0  2. Aug 09:30 mta
0 ---------- 1 root root 0  2. Aug 09:30 mta-mailq
0 ---------- 1 root root 0  2. Aug 09:30 mta-mailqman
0 ---------- 1 root root 0  2. Aug 09:30 mta-newaliases
0 ---------- 1 root root 0  2. Aug 09:30 mta-pam
0 ---------- 1 root root 0  2. Aug 09:30 mta-rmail
0 ---------- 1 root root 0  2. Aug 09:30 mta-rsmtp
0 ---------- 1 root root 0  2. Aug 09:30 mta-runq
0 ---------- 1 root root 0  2. Aug 09:30 mta-sendmail
0 ---------- 1 root root 0  2. Aug 09:30 spf
0 ---------- 1 root root 0  2. Aug 09:30 spf-daemon
0 ---------- 1 root root 0  2. Aug 09:30 spfquery-man-page
0 ---------- 1 root root 0  2. Aug 09:30 whois
0 ---------- 1 root root 0  2. Aug 09:30 whois-man

Das schockt, oder? Keine Symlinks mehr, nur noch leere Files mit 0 Byte Größe.

Was tun????

Vielleicht Man-Page lesen? Viel Spaß beim Suchen, keine Chance 🙂 Da findet sich nur dies:

-h, –dereference
Follow symlinks; archive and dump the files they point to.

Das macht TAR eh von alleine, … sagt man.  Probierts aus, ob Ihr -h im Extract drin habt oder nicht, spielt keine Rolle. Die Ursache liegt in einem kleinen Erwartungsproblem: Man erwartet, daß sobald eine Datei aus dem Archiv extrahiert wurde, diese im Filesystem auch mit allen Infos wie UID/GID, Filerechten vorhanden ist.

Da tickt tar aber leider etwas merkwürdig. Es macht das erst, wenn das Backup komplett durchlaufen wurde.

Lösung

Die Lösung lautet: Durchlaufen lassen!

Danach stimmt alles wieder, so wie man das erwarten würde. Machmal sind Lösung auch trivial. Das es im Einzelfall dann 100GB per Netzwerk sind, ist dann halt so, wenn man alles in ein Backupfile schreibt.

Regionaltreffen der deutschen LUGs in Braunschweig

Am Samstag den 3.8.2019 finden in Braunschweig ab 12 Uhr das Treffen der Linux-User-Groups aus dem Norddeutschen Umland statt.

Afaik wird gegrillt, genetzwerkelt und zufällig auch über Linux gesprochen 🙂

Wer kommen will, ist herzlich ins ..

Nachbarschaftszentrum
Haus der Talente

Elbestr. 45
38120 Braunschweig

eingeladen. Wer sein „Linux“ mitbringen will, kann das gern tun: Internet, Strom, Beamer vorhanden.

FireFox: Netflix-Fehler M7399-1260 ist wieder da

Posted on by

Seit 2 Tagen ist Netflix-Fehler M7399-1260 wieder im Firefox zu sehen, wenn man versucht einen Film abzuspielen. Verursacht wird dies durch das „Netflix 1080p“ Add-On von Vladikoff.

Firefox, Linux und die 1080p Wiedergabe von Netflix

Es ist ein ewiger K(r)ampf zwischen den Leuten, die NetFlix auf Linux mit 1080p sehen wollen und NetFlix, das irgendwie so gar kein Interesse hat, das zuzulassen, obwohl die Leute dafür bezahlen. Deswegen haben zwei findige Menschen das Problem analysiert und unabhängig voneinander zwei Add-Ons für Firefox entwickelt, die das lösen: NetFlix 1080p ist so ein Add-On.

Seit 2 Tagen steuert NetFlix dagegen und verweigert die Wiedergabe, wenn das Add-On aktiv ist. Mozilla hatte das Add-On auch bereits aus dem Add-On-Repository verbannt, weil es Teile des NetFlix Sourcecodes modifiziert und mitgeliefert hat. Das führt zu der nicht so schönen Situation, daß Benutzer das Add-On nicht ohne weiteres mehr hinzufügen können. Updates gestalten sich auch eher aufwändig.

Workaround

Für Benutzer die das Add-On bereits installiert haben, gibt es einen einfachen Workaround:

Add-On abschalten, Film anstarten, anhalten und das Add-On wieder aktivieren.

Wenn man jetzt die Serie oder den Film wieder frisch! anstartet, ist er 1080p und es kommt keine Fehlermeldung M7399-1260 mehr. Scheinbar prüft NetFlix das nur einmal in der Session und danach kann das Add-On wieder übernehmen.

Kniffliger wird die Sache, wenn man das Add-On noch nicht hat. Da gibt es jetzt 1,5 Wege:

1)

  1. via about:config
  2.  xpinstall.signatures.required auf false setzen
  3. Add-On-XPI-File im Add-On-Manager von Hand installieren

Problem dabei, Ihr müßtet XPI Files aus dubiosen Quellen vertrauen. z.B. dem hier:

https://github.com/vladikoff/netflix-1080p-firefox/files/3438656/Netflix_1080p_v1.9_for_Fx.zip

Da es direkt von Valdikoff kommt, kann man dem Link wohl vertrauen. Bei anderen wäre ich vorsichtiger. Ich habe es daher ausprobiert und es geht. Einfach das ausgepackte XPI File nach .mozilla/firefox/<DEIN PROFIL>/extensions/  kopieren, Firefox neu starten. Fertig.

oder 2)

Das GitHub-Repo von Valdikoff ( Link oben ) auschecken und die Dateien als Extension selbst in den Extension-Ordner vom FireFox verfrachten. Leider gibt es dazu keine einfache Anleitung. Der Inhalt vom Git müßte in ein XPI File umgewandelt werden. Wenn man eh so weit ist, kann man es auch wie in 1) installieren.

Es hätte nur den Vorteil, daß man Updates verscripten könnte und das dann automatisch gemacht werden kann.