Compyblog

Unerbauliche Erkenntnis von heute: Der Server, auf dem ich meinen Podcast hoste, verweigert die Kommunikation per http(s). Ich habe da erstmal ne Weile gewartet, falls schon jemand daran arbeiten würde, dann versucht, eine Mail an den Support zu schreiben (da meldet GMail, die Domain cloudhero.es gib't gar nicht mehr), dann den Firmen-Chef angemailt (keien Reaktion). Das sieht nicht so richtig gut aus. Per FTP komme ich noch an den Rechner ran, aber das hilft niemandem sonst. Wenn ich mal wild vermuten soll, könnte die Tatsache, dass die letzte Rechnung für das Hosting über ein Jahr zurück liegt etwas damit zu tun haben, dass da niemand erreichbar ist. Entweder haben die Leute ihre Domains nicht im Griff, von denen sie Mails versenden, oder/und die Rechnungen. Ich bin da gerade auf der Suche nach längerfristigen Lösungen (Podseed wird ja im Netz gerne verwendet, da hab ich auch ne Mail hingeschickt), alternativ könnte ich auf dem Blogserver auch Dateien hosten, habe da nur das Limit, dass da nur 50 GB Platz sind, und mein Jahresvorrat Podcasts laut Finder 77 GB groß ist.

Update: Ich habe jetzt im Blog die Folgen für ein Jahr so umgestellt, dass die MP3s auf dem Blog-Server verlinkt werden. Die sind aber längst nicht alle dort. Ein paar Teilfolgen für mich habe ich da erstmal bereitgestellt, um den Rest kann ich mich erst dann sinnvoll kümmern, wenn ich den Platz auf dem Server habe. Nebenbei habe ich auch gelernt, wo ich im Server-Admin-Frontend einstelle, wie viel von der vertraglichen Kapazität dem User zur Verfügung steht. Bisher waren das nämlich nur 500 MB, von eigentlich verfügbaren 50GB.

TL;DR: Podcast zieht zum Blog, braucht aber noch eine Vertragsaufrüstung, um komplett erledigt werden zu können.

Update 30.7.: Inzwischen habe ich bei Manitu den Vertrag aufgerüstet. Damit ist jetzt auf denn Server genug Platz für das Jahr an MP3-Dateien, was ich online haben will. Nur hochladen muss ich die Daten noch, das kann ne Weile dauern. 

Am Dienstag hat Apple noch per Pressemitteilung die Notebooks aktualisiert. Konkret waren dieses Mal MacBook Air und das MacBook ‚Escape‘ dran, die beide mit Touchbar ausgestattet wurden, jeweils CPUs der achten Generation von Intel abbekommen haben, und als günstigere Geräte für Schüler und Studenten am Back-To-School-Programm teilnehmen. Nicht ganz so groß erwähnt wird dabei, dass die Macs damit die gleiche Tastatur bekommen, wie die MacBook Pro aus dem späten Frühjahr bereits haben. Dass das dem gerade erst eine Woche vorher veröffentlichten Gerücht von Ming-Chi Kuo widerspricht (noch 2019 würden MacBook Air eine ganz neue Tastatur bekommen), interessiert eher nur Gerüchterstatter, und mich als amüsierten Beobachter. 

Ein paar Geräte sind damit unauffällig verschwunden: ein MacBook Pro ohne Touchbar (eben das ‚Escape‘) gibt es nicht mehr, und das 12-Zoll große MacBook ohne Nachname hat Apple unauffällig aus dem Verkauf genommen. Beide waren schon länger nicht ernsthaft aktualisiert worden, wobei das MacBook als mögliches erstes Gerät für die gerichtete ARM-CPU vermutet wurde. Und dann hat Apple noch die Preise für SSD-Aufrüstungen beim Gerätekauf (Build-To-Order) von völlig absurd auf unangemessen teuer gesenkt. 

Für mich zeigt die Änderung, dass Apple (noch?) glaubt, mit dem neuesten Tastatur-Anlauf die härtesten Fehler eingefangen zu haben. Ob das stimmt, ist noch nicht klar. An die ominöse neue Tastatur noch 2019 glaube ich nur im Rahmen eines neuen, gerüchteten 16-Zoll-Gerät, aber zwei Updates für das gleiche Modell (hier: MacBook Air) sind in den letzten Jahren nur extrem selten vorgekommen, wenn überhaupt. 

Und dann ist mal wieder ein Sicherheitsproblem durch das Netz geschwappt. Konkret geht es um eine Videokonferenz-Software, die bei ihrer Installation auf Macs neben der eigentlichen Anwendung noch einen Webserver installiert, der auf dem immer gleichen lokalen Port auf Aufrufe wartet, um dann die eigentliche Software in Videokonferenzen einzubinden, weil das ja so viel bequemer ist, als wenn Anwender erst eine Datei in einer Anwendung öffnen müssten... Das alleine wäre noch kein Sicherheitsproblem, würde dem Anwender wenigstens freigestellt, ob bei Meetings Kamera und Mikrofon automagisch an oder aus sein sollten. Dummerweise wird das vom Ersteller des Meetings festgelegt, und so kann eine böswillige Webseite mit einem unauffälligen Link, iFrame, Bild oder sonstwas ein Meeting öffnen, mit dem Besucher der Webseite ausgeschnüffelt werden könnten. Das ist aber immer noch nicht alles, denn wenn man Mac-typisch die Client-Amnwendung durch Verschieben in den Papierkorb loswerden will, hat man den Server noch nicht erwischt, der wiederum die Anwendung aus dem Netz laden und installieren kann.

Öffentlich ist das Ganze nun geworden, nachdem die Herstellerfirma die übliche Zeit von 90 Tagen ohne sinnvolle Lösung verstreichen lassen hat, und bis vor einer Woche auch noch geleugnet hat, dass es da überhaupt ein Problem gäbe.

Und dann gab es vor einer Woche mal eine öffentliche Bewegung in der Frage, ob und wann denn Apples Bezahlfunktion denn mal bei Sparkassen verfügbar werden würde. Mir ist dazu zuerst dieser Tweet des offiziellen Twitter-Accounts der Sparkassen begegnet. Danach ist mir noch begegnet, dass auch der Heise-Ticker berichtet hat.

Kurz zusammengefasst: Pay soll noch 2019 zur Sparkasse kommen, aber laut Heise-Ticker nicht mit den Giro-Karten beim Start. Womit sich dann wieder die Frage aufdrängt, ob ich mir denn eine Kreditkarte zulegen will, die ich ansonsten nicht akut vermisse bisher. Na, abwarten.

Okay, das ist zu irre, als dass ich es nicht aufschreiben sollte: Seit rund einer Woche habe ich immer wieder Probleme gehabt, mein Blog vom Festnetz aus zu erreichen. Mit etwas Suchen habe ich Tools gefunden, die mir mal ordentlichere Fehlermeldungen als 'geht nicht' ausspucken und dabei folgendes Muster bemerkt: Auf der IPv4-Adresse hat der Server auf Https-, http und sogar ftp-Port immer Connection Refused geantwortet, über IPv6 war das Netz desöfteren nicht nutzbar, und ich war reichlich vewrwirrt. Anfangs half es, die Fritzbox eine neue PPPoE-Verbindung bauen zu lassen, aber das hielt nie lange, und ist ohnehin nicht der saubere Weg.

Übers Wochenende ging alles halbwegs glatt, IPv6 funktionierte die paar Mal, wo ich das Blog erreichen wollte, aber gestern nachmittag ging wieder nichts. Okay, so einen Blogeintrag kann ich auch über einen Hotspot auf dem iPhone veröffentlichen (aka Krankenhaus-Konfiguration). Heute früh fiel mir ein, dass ich mit RIPE Atlas ja noch ne Runde spielen kann, und so habe ich ein paar (37) Probes aus dem gleichen Netz auf den Server losgelassen zum SSL-Check. Dafür verbindet sich die Probe schließlich mit dem Server und beguckt das Zertifikat. Nebenbei hat sie damit gezeigt, ob der Connect klappt. Ergebnis war kompliziert: Eine Reihe Probes kam problemlos zum Server, einige hatten irgendwelche obskuren Fehler. Als mich eben der Fehler wieder ereilt hat, habe ich den Versuch nochmal gemacht, und im Ergebnis lauter erfolgreiche Verbindungen bis auf meine Probe bekommen. Ergo: Das Problem kommt nicht von draußen.

Da fiel mein Verdacht auf die Fritzbox, die noch nichtmal einen Monat im Einsatz ist, aber schon ein paar obskure Fehler hatte. Bei jeder Änderung der Internet-Konfiguration holt sie sich zuerst einen Access Denied (44, aber auch schon mal 11), dann hat heute Mittag die Probe ihre Online-Verbindung verloren und kam erst nach IP-Neuvergabe wieder richtig online, konnte aber die ganze Zeit noch DNS-Requests rausschicken. Und überhaupt kann die lahme Internet-Verbindung über die TimeCapsule auch an der Fritzbox liegen.

Ergo: Ich will das mal testen. Zwei Optionen gab es da: Die alte 7490 sollte noch wissen, wie sie ins Netz kommt, wünscht aber ihre alten Kabel zurück, oder ich packe eine noch unbenutzte 7590 aus, die ich in der Woche gekauft hatte, als ich die erste 7590 eingesetzt habe, für genau solche Fälle. Vorteil an der 7590: Ich kenne jetzt die Stolperfallen bei deren Einrichtung (Experten-Ansicht für das Update von einer Datei, der braucht kein Telefon, um Nachfragen zu bestätigen. Man muss nur einen Knopf am Gerät drücken, und ja, das sind zwei Reboots). Gesagt, getan. Und gleich, als die Fritzbox frisch gestartet online war, habe ich das Blog mal per IPv4 erreicht. Funktionierende Technik kann manchmal so einfach sein.

Spannende Frage: Heißt das, bei der 'kaputten' 7590 ist irgendwas an der Hardware? Wenn AVM da mal nachsehen will, können sie das Gerät gerne haben, so ein Ausfall ist doch reichlich obskur.

Update: Und dann stellt sich raus, dass die V6-Verbindung auch auf der neuen Box nicht sauber funktioniert. Hat das auf der 7490 auch schon so unzuverlässig agiert, und ich hab's nur nie gemerkt?

Update 2: Stellt sich raus, dass auch die neue Fritzbox das Connection Refused-Spiel macht. Damit kommt dann Stand 19:44 wieder die 7490 zum Einsatz. Mit dem Netzteil der 7590, aber ihrem DSL-Kabel. Irgendwas ist an den 7590 uncool, und die 7490 spricht erstmal V4 und V6 sauber. Ich werde das weiter beobachten.

Update 3 vom 3.7.: der Manitu-Support hat sich gemeldet und einen Ansatz zur Ursachenforschung geliefert. Und zwar gibt es (neu?) eine Funktion auf dem Server, dass bei wiederholten IMAP-Zugriffen mit falschem Passwort der Server nicht mehr erreichbar sein will. Ich Verdächtige dann entweder das iPhone 7+ oder das iPad mini 4, die ich tagsüber zuhause am Strom lasse. Und wenn da das falsche Passwort zum Server geschickt wird, blockiert der eben. Denn inzwischen ist die Domain auch wieder unerreichbar, laut Probe. Dann liegt das wohl nicht an der Fritzbox. Und ich teste das mal per Hotspot, wenn ich zuhause bin.