Archiv ‘IT’

Montag, 13. April 2020

HP ProBook 6570b erkennt bootbaren USB-Datenträger nicht

Link zu diesem Artikel

Gestern half ich einer Bekannten, ihr HP ProBook 6570b mit einer vom Software-Hersteller nicht mehr unterstützten Windows 7 Professional-Installation auf Windows 10 zu lüpfen.

Diese unsägliche Upgrade-Odyssee bestätigte mir wieder einmal, dass mein Entscheid 2004 richtig war, Windows den Rücken zu kehren und auf Mac OS X (heute: macOS) sowie Debian GNU/Linux zu setzen.

Frickelmässig hat sich im Umgang mit Windows kaum etwas geändert — mit Backup-Image, dateibasiertem rsync-Backup, Installationsdatenträger herunterladen und erstellen sowie drei (!) Installationsversuchen (Stichwort: 0x800f0955 - 0x20003 und „The installation failed in the SAFE_OS phase with and error during INSTALL_UPDATES operation.“) habe ich gut und gerne 12 Stunden verbraten.

Ein kleines Problem ganz zu Beginn: Der USB-Installationsdatenträger, ein 8GB USB-Stick, wurde vom HP BIOS anfänglich nicht als Bootquelle aufgeführt (beim Booten ESC drücken, dann F9). Nach viel Haare ausreissen dann die Erkenntnis auf Grund eines Tipps in einem Forum: Ich hatte den Datenträger an einem der zwei SS (SuperSpeed) USB-Anschlüsse auf der rechten Seite des Geräts angeschlossen. Das BIOS erkennt aber nur USB-Datenträger, die am linken USB/eSATA-Anschluss angeschlossen werden.

Wie bescheuert ist das denn?!

Tags: , , , , , , , , , , , , , ,
Labels: IT

2 Kommentare | neuen Kommentar verfassen

Montag, 13. April 2020

Bildschirm eines Debian-Servers nach Inaktivität ausschalten

Link zu diesem Artikel

Ich habe hier bereits erwähnt, dass gebrauchte ThinkPads mit Debian die Linux-Server meiner Wahl sind.

Gestern habe ich meinen ELK Log-Server von einem Lenovo ThinkPad X201 auf ein Lenovo ThinkPad T440p migriert (und habe gleichzeitig von einem unsäglichen Docker-Gefrickel auf native Pakete gewechselt).

Eines der bis eben ungelösten Probleme war, dass sich der Bildschirm des ThinkPads nach einer Inaktivitäts-Zeitlimite nicht automatisch ausschaltete. Das habe ich nun folgendermassen gelöst:

/etc/default/grub

...
GRUB_CMDLINE_LINUX_DEFAULT="consoleblank=60"
...

Der Wert 60 drückt die Inaktivitätszeit in Sekunden aus.

Danach muss noch GRUB aktualisiert werden, und dann wird’s ab dem nächsten Neustart nach 60 Sekunden dunkel:

# update-grub

Tags: , , , , , , , , , , , , , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 9. April 2020

Hände weg von Zoom

Link zu diesem Artikel

Zoom is a security and privacy disaster, […] In the meantime, you should either lock Zoom down as best you can, or — better yet — abandon the platform altogether.

Quelle: Security and Privacy Implications of Zoom

Tags: , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 1. März 2020

Unter macOS High Sierra mit MacPorts, postfix und s-nail E-Mails versenden

Link zu diesem Artikel

Emails von der Kommandozeile versenden — was man bei Linux im Handumdrehen hinkriegt, erforderte bei mir unter macOS stundenlange Handstände.

MacPorts postfix anstelle macOS postfix

Doch jetzt habe ich den Kniff raus: Die von macOS mitgelieferte postfix-Installation habe ich schlussendlich ignoriert und auf das MacPorts postfix-Paket gesetzt.

MacPorts Variants nicht vergessen

Der erste Fallstrick lauert schon hier: Um heutzutage über einen Hoster E-Mails zu versenden, benötigt man zwingend SASL und TLS. Diese Features müssen als sog. MacPorts Variants explizit mitinstalliert werden, sonst landen sie nicht auf dem Mac:

# port install postfix +sasl +tls

Ansonsten meldet postfix:

...
Mar 01 14:16:11 imac postfix/smtp[70687]: warning: smtp_sasl_auth_enable is true, but SASL support is not compiled in
Mar 01 14:16:11 imac postfix/smtp[70687]: warning: TLS has been selected, but TLS support is not compiled in
...

Verzeichnisse und Pfade zur Sicherheit hardkodieren

Eine funktionierende postfix-Konfiguration mitsamt Installationsscript habe ich von meinen Linux-Servern herüberkopiert (diese Anleitung alleine würde das Format dieses Blog-Artikels sprengen). Die Konfiguration habe ich aber mit den MacPorts-Einstellungen ergänzt. Denke daran: Bei Linux liegen die Konfiguration sowie die Arbeitsverzeichnisse allesamt am erwarteten Ort (bspw. /etc/postfix/main.cf). Da wir unter macOS auf MacPorts setzen, liegt dieselbe Datei hier unter /opt/local/etc/postfix/main.cf. Deshalb habe ich zur Sicherheit in main.cf folgende von MacPorts vorgeschlagene Ergänzungen (siehe /opt/local/etc/postfix/main.cf.sample) hinzugefügt:

$ cat /opt/local/etc/postfix/main.cf
# Directories
queue_directory = /opt/local/var/spool/postfix
command_directory = /opt/local/sbin
daemon_directory = /opt/local/libexec/postfix
data_directory = /opt/local/var/lib/postfix
meta_directory = /opt/local/etc/postfix
manpage_directory = /opt/local/share/man
sample_directory = /opt/local/share/postfix/sample
readme_directory = /opt/local/share/postfix/readme
shlib_directory = no
html_directory = no

# Paths
sendmail_path = /opt/local/sbin/sendmail
newaliases_path = /opt/local/bin/newaliases
mailq_path = /opt/local/bin/mailq

# Log
maillog_file_prefixes = /var, /var/log/macports/postfix
maillog_file = /var/log/macports/postfix/postfix.log

# Other stuff ...
mail_owner = _postfix
setgid_group = _postdrop
default_privs = nobody
unknown_local_recipient_reject_code = 550
debug_peer_level = 2
...

Logs in eine Datei schreiben

Weiter hatte ich während dem Debuggen so meine liebe Mühe, die Logging-Informationen zu finden, da diese an syslog gesendet werden und bei macOS dann in der Console.app landen. Deshalb habe ich im Gegensatz zu meinen Linux-Installationen auch noch die Konfigurationsdatei /opt/local/etc/postfix/master.cf anpassen müssen. Essentiell war es, die folgende Zeile einzufügen:

...
postlog   unix-dgram n  -       n       -       1       postlogd
...

Quelle: Postfix logging to file or stdout

Verhindern, dass fälschlicherweise die macOS postfix-Konfiguration geladen wird

Damit mir die Parallelinstallation von Postfix nicht in die Quere kommt und ich mir sicher war, dass die MacPorts-Installation von postfix tatsächlich die Konfiguration unter /opt frisst, habe ich kurzerhand den macOS postfix-Ordner verschoben:

# mv /etc/postfix /etc/postfix.bkp

Ob das wirklich nötig gewesen wäre sei dahingestellt; Vorsicht, wer das auf seinem System macht: Ich garantiere für nichts.

Postfix starten und stoppen

Die Postfix-Installation lädt man folgendermassen:

# port load postfix
# launchctl unload /Library/LaunchDaemons/org.macports.postfix.plist
# launchctl load -w /Library/LaunchDaemons/org.macports.postfix.plist

Die plist-Datei zeigt als symbolischer Link nach /opt/local/etc/LaunchDaemons/org.macports.postfix/org.macports.postfix.plist. In dieser Datei habe ich folgendes angepasst/ergänzt — das ist nicht zwingend nötig, sollte aber dazu führen, dass Postfix bei jedem Neustart automatisch gestartet wird. Ausserdem sollten im Fall von Start-Problemen Fehlermeldungen in eine Log-Datei geschrieben werden:

...
        <string>--pid=none</string>
    </array>
    <key>Disabled</key>
    <false/>
    <key>KeepAlive</key>
    <true/>
    <key>StandardOutPath</key>
    <string>/var/log/launchd.macports.postfix.standard.log</string>
    <key>StandardErrorPath</key>
    <string>/var/log/launchd.macports.postfix.error.log</string>
</dict>
</plist>

s-nail verwendet standardmässig die macOS mail-Executables

Anschliessend musste noch eine Mail-Programm her, welches erlaubt, den Absender eines E-Mails selber zu setzen. MacPorts bietet hierzu s-nail an (Homepage des Entwicklers).

# port install s-nail

Als ich mit s-nail ein Test-Mail versenden wollte folgte eine weitere Hiobs-Botschaft:

$ echo "Test email" | mail user@domain.tld
unknown: fatal: open /etc/postfix/main.cf: No such file or directory
/Users/user/dead.letter 7/135
mail: ... message not sent

Ich übertreibe nicht, wenn ich sage, dass ich Stunden mit Debugging verbracht habe. Bis ich plötzlich realisierte, dass s-nail die offiziellen Mail-Executables mail, mailx und/oder sendmail unter /usr/bin verwendet. Der Lackmus-Test: Wenn ich diese Mail-Executables manuell aufrief, erschien ein- und dieselbe Fehlermeldung.

Dies obwohl meine Bash PATH-Variable /opt/local/bin und /opt/local/sbin vor /usr/bin und /usr/sbin nennt, verwendete s-nail aus irgendeinem Grund standardmässig die letztgenannten Pfade.

Wie sage ich s-nail aber, dass es stattdessen die MacPorts mail-Befehle verwenden soll? Folgende Anpassung in /opt/local/etc/mail.rc war nötig:

...
set mta=/opt/local/sbin/sendmail

Absender (From:) der E-Mails selber festlegen

Anschliessend musste noch eine Mail-Programm her, welches erlaubt, den Absender eines E-Mails selber zu setzen. Ich verwende in Bash-Scripts sehr oft folgendes Konstrukt, und ich wollte sicherstellen, dass die Scripts sowohl unter Debian GNU/Linux als auch macOS laufen (Argument -a):

$ echo -e "Test" | $(which mail) -a "From: DNS Query Analyzer " -s 'Top 25 DNS Queries' user@domain.tld another.user@domain.tld

Ich habe leider eine schlechte, aber auch eine gute Nachricht. Die gute: Man kann auch unter macOS den Absender setzen. Leider aber nicht mit demselben Befehl wie unter Debian GNU/Linux.

Bei s-nail muss ich leider ein anderes Argument verwenden:

$ echo -e "Test" | $(which mail) -r "DNS Query Analyzer " -s 'Top 25 DNS Queries' user@domain.tld another.user@domain.tld

Postfix hat Probleme mit selber gesetzter Absenderadresse und SPF Records

Doch nun trat bereits das nächste Problem auf, wie ein Blick in die leere INBOX und in /var/log/macports/postfix.log zeigte:

...
Mar 01 15:43:59 imac postfix/smtp[81049]: 4D0E3FBBE221: to=<user@domain.tld>, relay=s000.cyon.net[149.126.4.000]:25, delay=20, delays=0.03/20/0.03/0.04, dsn=5.0.0, status=bounced (host s000.cyon.net[149.126.4.000] said: 550 SPF: 1.2.3.4 is not allowed to send mail from emeidi.com (in reply to RCPT TO command))
...

Faszinierend. Unter Linux hatte ich eine solche Fehlermeldung noch nie gesehen. Ich verwende für den Versand „offizieller“ E-Mails jeweils emeidi.com als Absenderadresse.

Schlussendlich blieb nur die Holzhammer-Methode. Ich verschob alle Konfigurationsdateien, welche auf meinen Linux-Installationen nicht existierten, von /opt/local/etc/postfix in den Unterordner _old. Schlussendlich sah das Verzeichnis so aus:

$ find /opt/local/etc/postfix/opt/local/etc/postfix
/opt/local/etc/postfix/_old
/opt/local/etc/postfix/_old/access
/opt/local/etc/postfix/_old/access.sample
/opt/local/etc/postfix/_old/aliases
/opt/local/etc/postfix/_old/aliases.sample
/opt/local/etc/postfix/_old/bounce.cf.default
/opt/local/etc/postfix/_old/canonical
/opt/local/etc/postfix/_old/canonical.sample
/opt/local/etc/postfix/_old/generic
/opt/local/etc/postfix/_old/generic.sample
/opt/local/etc/postfix/_old/header_checks.sample
/opt/local/etc/postfix/_old/LICENSE
/opt/local/etc/postfix/_old/main.cf.default
/opt/local/etc/postfix/_old/main.cf.proto
/opt/local/etc/postfix/_old/main.cf.sample
/opt/local/etc/postfix/_old/master.cf.proto
/opt/local/etc/postfix/_old/master.cf.sample
/opt/local/etc/postfix/_old/relocated
/opt/local/etc/postfix/_old/relocated.sample
/opt/local/etc/postfix/_old/TLS_LICENSE
/opt/local/etc/postfix/_old/transport
/opt/local/etc/postfix/_old/transport.sample
/opt/local/etc/postfix/_old/virtual
/opt/local/etc/postfix/_old/virtual.sample
/opt/local/etc/postfix/header_checks
/opt/local/etc/postfix/main.cf
/opt/local/etc/postfix/makedefs.out
/opt/local/etc/postfix/master.cf
/opt/local/etc/postfix/postfix-files
/opt/local/etc/postfix/sasl
/opt/local/etc/postfix/sasl/outgoing
/opt/local/etc/postfix/sasl/outgoing.db

In sasl/outgoing entfernte ich zudem den TCP-Port nach der Server-Adresse, und master.cf ergänzte ich mit Zeilen, die bisher nur unter Linux existierten.

Heureka

Und jetzt endlich kann ich mir von der Kommandozeile aus E-Mails senden. Hat nur geschlagene sechs Stunden gedauert.

Tags: , , , , , , , , , , , , , , , ,
Labels: Apple, IT

Keine Kommentare | neuen Kommentar verfassen

Montag, 10. Februar 2020

Raspberry Pi zeigt ständig „Can’t update Chromium“ Overlay an

Link zu diesem Artikel

Mein Dashboard zu Hause läuft auf einem Raspberry Pi 3 mit Debian Buster 10.2. Der RPi lädt beim morgendlichen Neustart um Punkt 05:00 Uhr den Chromium-Browser, welcher die Web-Site mit dem Dashboard aufruft.

Seit ein paar Tagen zeigt Chromium oben rechts ein Layover mit folgender Meldung an:

Can’t update Chromium

Chromium couldn’t update to the latest version, so you’re missing out on new features and security fixes.

(da ich selber kein Photo des Dashboards angefertigt habe, verlinke ich hier auf einen Screenshot eines anderen Benutzers aus dem Internet)

Da Debian kein Update von Chromium anbietet, hilft ein apt-get upgrade chromium hier leider nicht weiter.

Das Symptom behebt man, indem man Chromium mit einem zusätzlichen Kommandozeilenargument startet — nachfolgend ein Auszug aus /home/pi/.config/lxsession/LXDE-pi/autostart:

...
@chromium-browser --no-default-browser-check --check-for-update-interval=604800 --disable-pinch --incognito --kiosk

Den Tipp mit --check-for-update-interval=604800 (Eintrag in der Liste der Kommandozeilenargumente) habe ich auf Stack Overflow in der Frage Disable “chrome is out of date” notification gefunden.

Da man als verantwortungsvoller SysAdmin entweder Debian unattended-upgrades respektive cron-apt (Vergleich) eingerichtet hat, oder sich zumindest automatisiert über Paket-Aktualisierungen informieren lässt, ist diese Symptombekämpfung vertretbar.

Die Entwickler von Chromium könnten sich meiner bescheidenen Meinung nach überlegen, ob es nicht besser wäre, nur dann eine Meldung anzuzeigen, wenn auch tatsächlich ein Update verfügbar ist. Denn die Meldung erscheint rein basierend auf dem Alter der Applikation, nicht basierend darauf, ob eine neue Version verfügbar ist:

there’s background process that checks the build date against the current time, and will start to complain if it’s more than 12 weeks ago.

Quelle: Debian Bug report logs – #943668 Getting „Can’t update Chromium“ notifications

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 23. Januar 2020

grep interpretiert Dateiinhalte fälschlicherweise als Binärdaten

Link zu diesem Artikel

Ein Bash-Script, welches täglich meine SVN-Logs auf unerwartete Zugriffe durchgeht, meldete mir gestern:

...
1  Binary  file  (standard  input)  matches
...

Dabei handelt es sich um eine Meldung von grep, mit welchem ich die Apache-Logs filtere. Offenbar enthält das Access Log von dieser Woche Inhalte, die grep glauben machen, dass es sich um eine Binärdatei und nicht um eine ASCII/UTF-8-Datei handelt. In Durchgängen in früheren Monaten und Wochen trat dieses Problem nicht auf.

Wenn man sich sicher ist, dass man grep ASCII-Daten füttert, kann man dies mit einem Argument forcieren:

$ grep --text README.txt

So klappt die Auswertung nun auch wieder mit meinem Bash-Script.

Nachtrag

Gemäss diesem Unix & Linux Stack Exchange-Artikel erachtet grep eine Datei als Binär, wenn es erstmalig auf das NUL-Zeichen trifft.

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 19. Januar 2020

Signal-Werte meiner Ubiquiti UF-SM-1G-S

Link zu diesem Artikel

Kürzlich hat ein Bekannter ein zweites Stockwerk mit Netzwerkverkabelung erschlossen. Hierzu haben wir nicht Ethernet Cat6 gewählt, sondern wegen der Grösse der Lehrrohre auf Glasfaser gesetzt.

Dies bedingt leider aber auch, dass an beiden Enden des Glasfasers SFP-Module verwendet werden müssen, die die Lichtwellen auf Ethernet konvertieren.

Ich habe mich auf der einen Seite für einen gebrauchten Ubiquiti Unifi Switch US-8-150W entschieden, auf der anderen Seite ein bei mir nach Fiber7-Tests unbenutzt herumliegender TP-Link MC220L, der im Modus Auto mit Ethernet auf einen Ubiquiti Unifi Switch US-8-60W gepatcht ist. Als SFP-Module verwende ich beidseitig Ubiquiti UF-SM-1G-S. Als Kabel hat der Bekannte ein Lightwin LWL-Patchkabel LC/APC-LC, Singlemode, Simplex, 15m gezogen.

Aktuell erreiche ich mit diesem Setup auf Seite des US-8-150W folgende Signal-Werte:

  • Output Pwr. -6.03 dBm
  • Input Pwr. -8.57 dBm

Das SFP-Modul ist 47 Grad Celsius warm, die Spannung beträgt 3.284 Volt und der Strom beträgt 31.890 mA. Diese Infos kann man allesamt in Echtzeit über die UniFi Controller-Software auslesen.

Leider habe ich keine Ahnung, ob diese Werte gut oder schlecht sind …

Tags: , , , , , , , , , ,
Labels: IT

2 Kommentare | neuen Kommentar verfassen

Sonntag, 12. Januar 2020

Kabelmodem direkt nach dem Verstärker anschliessen? Schlechte Idee.

Link zu diesem Artikel

Ein Bekannter plant derzeit, die Stockwerke seiner Immobilie mit Ethernet- oder Glasfaser-Kabeln zu erschliessen.

Da hatte ich eine zündende Idee: Da der Bekannte upc cablecom-Kunde ist, könnte man nach der Verkabelungsaktion das Kabelmodem von der Stube im 1. OG in den Keller zügeln, wo der Verstärker angebracht ist. Ich erhoffte mir davon höhere Bandbreiten beim Up- und Download, da ich der Qualität der Verkabelung vom Verstärker zur Stube nicht traue. Je näher das Modem am Verstärker ist, desto weniger leistungsschwächende Interferenzen erhoffte ich mir.

Nachdem das Modem zum Verstärker gezügelt worden wäre, hätte man nur noch ein Netzwerkkabel vom Kabelmodem zum Stockwerks-Switch ziehen müssen und die Bewohner wären in den Genuss schnellerer Bandbreiten gekommen.

Falsch gedacht. Eine kurze Google-Recherche lotste mich auf folgende Forumsdiskussion:

Einfach so an den Verstärker anschließen geht nicht. Das Modem ist von genau definierten Pegelwerten abhängig, d.h. Deine vom Techniker gesetzte Dose wurde eingemessen. Bei dieser Einmessung fanden das zur Dose führende Kabel und die Dose selbst Berücksichtigung.

[…] [Die Installation einer neuen Kabeldose] sollte jemand machen der Ahnung von Kabelanlagen, Dämpfungen und Rückkanal hat.

Quelle: Kabelmodem direkt mit dem UM-Gerät im Keller verbinden

Tags: , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Montag, 16. Dezember 2019

Netflix mit zehntausenden DNS-Queries pro Tag von meinem Sony KD-55AF8

Link zu diesem Artikel

Seit ein paar Monaten steht in unserer Wohnung der erste richtig „smarte“ TV, ein Sony KD-55AF8, auf welchem mittlerweile Android TV 8.0 installiert ist.

Seit gestern analysiere ich die DNS-Queries, die von Netzwerkgeräten im LAN an den lokalen DNS-Forwarder gestellt werden sowohl quantitativ (welche Domains werden am meisten aufgelöst, welches Gerät setzt die meisten Queries ab und in welcher Stunde des Tages gibt es die meisten Queries) sowie qualitativ (werden von SANS als Suspicious eingestufte Domains aufgelöst, was ein Zeichen für Malware-Befall sein könnte). Ich war nicht schlecht überrascht, dass ein TV-Gerät, welches allerhöchsten zwei von 24 Stunden im Tag „läuft“, der Spitzenreiter aller Queries ist. Ich zählte innerhalb von 24 Stunden sage und schreibe 90’498 Queries. Gefolgt wurde der TV vom Server selber, auf welchem der DNS-Server läuft mit 72’411 Queries. Auf Platz drei dann ein Client mit noch 7’162 Queries.

Heute nun nahm mich Wunder, was zum Teufel der TV ständig abzufragen hat. Hier das Resultat der Analyse der named-Logs vom Vortag (10.1.2.3 ist die (fiktive) IPs meines TVs):

$ cat queries.log.1 | grep 10.1.2.3 | cut -d "(" -f 2 | cut -d ")" -f 1 | sort | uniq -c | sort -rn
  13052 cdn-0.nflximg.com
   9112 nrdp51-appboot.netflix.com
   8777 api-global.netflix.com
   8564 uiboot.netflix.com
   8487 ichnaea.netflix.com
   8332 customerevents.netflix.com
   8262 nrdp.nccp.netflix.com
   6970 secure.netflix.com
   6886 nrdp.prod.ftl.netflix.com
   3115 push.prod.netflix.com
   1556 occ-0-593-769.1.nflxso.net
   1284 clients3.google.com
   1220 connectivitycheck.gstatic.com
   1196 www.google.com
   1195 mtalk.google.com
    994 nrdp52-appboot.netflix.com
    324 events.cid.samba.tv
    162 us.edge.bamgrid.com
    142 watch.product.api.espn.com
    118 clients4.google.com
    109 androidtvchannels-pa.googleapis.com
    105 footprints-pa.googleapis.com
     91 fling.cid.samba.tv
     83 www.youtube.com
     52 mdh-pa.googleapis.com
     41 clientservices.googleapis.com
     37 www.googleapis.com
     35 play.googleapis.com
     34 platform.cid.samba.tv
     28 android.googleapis.com
     13 www.gstatic.com
     12 youtubei.googleapis.com
     10 static.doubleclick.net
      7 www.netflix.com
      7 android.clients.google.com
      6 api-cdn.arte.tv
      5 lh3.googleusercontent.com
      5 antv-26-sony-bravia4kgbatv3-414000300.api.amazonvideo.com
      4 sdk.hockeyapp.net
      4 middleware.7tv.de
      4 devices.ted.com
      4 cdn-gl.imrworldwide.com
      4 android.googleapis.com
      3 zdf-cdn.live.cellular.de
      3 geoloc.arte.tv
      3 geocheck.sim-technik.de
      3 config.ioam.de
      3 cdn.meta.ndmdhs.com
      3 bam-sdk-configs.bamgrid.com
      2 sdk.imrworldwide.com
      2 api.meta.ndmdhs.com
      1 www.sony.net
      1 www.sony-asia.com
      1 voledevice-pa.googleapis.com
      1 update.biv.sony.tv
      1 time.android.com
      1 static-cdn.arte.tv
      1 sportscenter.api.espn.com
      1 secure.espncdn.com
      1 safebrowsing.googleapis.com
      1 r4---sn-1gieen7e.gvt1.com
      1 people-pa.googleapis.com
      1 ocsp.int-x3.letsencrypt.org
      1 metadata.erabu.sony.tv
      1 log.core.cloud.vewd.com
      1 isrg.trustid.ocsp.identrust.com
      1 images.erabu.sony.tv
      1 fls-na.amazon.com
      1 cloudfront.xp-assets.aiv-cdn.net
      1 cert-cdn.meta.ndmdhs.com
      1 cdn.espn.com
      1 browserjs-legacy.core.cloud.vewd.com
      1 broadband.espn.com
      1 bravia-cfgdst-ore-pro.bda.ndmdhs.com
      1 bdcore-apr-lb.bda.ndmdhs.com
      1 app-measurement.com
      1 api.erabu.sony.tv
      1 api.auth.adobe.com
      1 ajax.googleapis.com

Netflix führt die Statistik unangefochten an:

$ cat queries.log.1 | grep 10.1.2.3 | cut -d "(" -f 2 | cut -d ")" -f 1 | sort | uniq -c | sort -rn | grep -i "netflix\|nflx"
  13052 cdn-0.nflximg.com
   9112 nrdp51-appboot.netflix.com
   8777 api-global.netflix.com
   8564 uiboot.netflix.com
   8487 ichnaea.netflix.com
   8332 customerevents.netflix.com
   8262 nrdp.nccp.netflix.com
   6970 secure.netflix.com
   6886 nrdp.prod.ftl.netflix.com
   3115 push.prod.netflix.com
   1556 occ-0-593-769.1.nflxso.net
    994 nrdp52-appboot.netflix.com
      7 www.netflix.com

Von den täglich über 90’000 Queries entfallen über 90 Prozent auf Netflix-Domains:

$ cat queries.log.1 | grep 10.1.2.3 | grep -i "netflix\|nflx" | wc -l
84114

Dabei schauen wir — wenn überhaupt — mit der Netflix-App auf dem Apple TV 4K mit einer anderen IP Netflix, und nie mit der Android TV App.

Netflix, shame on you! Die Frage, wieso die Netflix-App das macht, konnte ich bis jetzt noch nicht beantworten, werde es hier aber nachtragen, sollte ich es erfahren.

Tags: , , , , , , , , , , , , , , , , ,
Labels: IT

10 Kommentare | neuen Kommentar verfassen

Dienstag, 3. September 2019

MacTeX-Download extrem langsam

Link zu diesem Artikel

Gestern wollte ich mir MacTeX 2019 herunterladen (veröffentlicht im Mai 2019). Das macOS Installations-Package für die LaTeX-Distribution ist mittlerweile sagenhafte 3.9 GB gross.

Als ich den Link tug.org/cgi-bin/mactex-download/MacTeX.pkg auf der offiziellen Download-Seite anklickte, tröpfelten die Daten nur Kilobyte-weise rein.

Nach etwas Recherche (einen Torrent-Link fand ich auf die Schnelle leider nicht) stiess ich dann auf die Homepage der Distribution auf CTAN. Dort wird stattdessen der Link mirrors.ctan.org/systems/mac/mactex/MacTeX.pkg angeboten, der per Zufall (oder nach geographischen Kriterien?) einen Mirror zum Download auswählt. Über den gestern Abend gewählten Mirror erreichte ich dann Download-Geschwindigkeiten von bis zu 10 MB/s und hatte das Paket dementsprechend in ein paar Minuten heruntergeladen. Der Web-Download über den offiziellen Link war zu dem Zeitpunkt erst bei 189 MB angelangt …

Tags: ,
Labels: Apple, IT

Keine Kommentare | neuen Kommentar verfassen

« Older Entries
Newer Entries »