Archiv 22. März 2018

Donnerstag, 22. März 2018

curlftps kann unter macOS High Sierra mit macports nicht installiert werden

Heute erhielt ich folgende Fehlermeldung:

--->  Computing dependencies for curlftpfs
--->  Dependencies to be installed: osxfuse
--->  Building osxfuse
Error: Failed to build osxfuse: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_fuse_osxfuse/osxfuse/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port curlftpfs failed

In der angegebenen main.log las ich:

...
:info:build Command /bin/sh failed with exit code 1
:info:build ** BUILD FAILED **
:info:build The following build commands failed:
:info:build 	PhaseScriptExecution BridgeSupport\ Metadata build/OSXFUSE.build/Release/OSXFUSE.build/Script-28D525C40EA8076400B7CF7B.sh
:info:build (1 failure)
:info:build T:framework          | Failed to build target
:info:build Terminated: 15
:info:build Received signal: SIGTERM
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_fuse_osxfuse/osxfuse/work/osxfuse-osxfuse-431bdc5" && ./build.sh -t packagemanager -a build -v 5 --build-directory="/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_fuse_osxfuse/osxfuse/work" -- -a x86_64 --framework-prefix="/opt/local" --fsbundle-prefix="/opt/local" --library-prefix="/opt/local" 
:info:build Killed by signal: 15
:error:build Failed to build osxfuse: command execution failed
:debug:build Error code: CHILDKILLED 1299 SIGTERM {software termination signal}
:debug:build Backtrace: command execution failed
:debug:build     while executing
:debug:build "system {*}$notty {*}$nice $fullcmdstring"
:debug:build     invoked from within
:debug:build "command_exec build"
:debug:build     (procedure "portbuild::build_main" line 8)
:debug:build     invoked from within
:debug:build "$procedure $targetname"
:debug:build invalid command name "::ui_init"
:debug:build     while executing
:debug:build "::ui_init $priority $prefix $channels($priority) {*}$args"
:debug:build     ("uplevel" body line 2)
:debug:build     invoked from within
:debug:build "uplevel 1 $body"
:error:build See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_fuse_osxfuse/osxfuse/main.log for details.

Da ich keine Lösung für das Problem fand, eröffnete ich im MacPorts Trac einen Defect: osxfuse: build failed with SIGTERM

Die Antwort kam postwended — das Problem sei bekannt und bereits im Defect osxfuse @3.7.1: Library not loaded: @rpath/libclang.dylib (LoadError) beschrieben.

Als temporärer Workaround wird dort empfohlen:

$ cd /Applications/Xcode.app/Contents/Developer/Toolchains
$ sudo ln -s XcodeDefault.xctoolchain OSX10.13.xctoolchain

Danach kompilierte die Sache problemlos.

Tags: , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 22. März 2018

WiFi-Kennwörter auch aus dem Recovery-Modus eines Macs entfernen

Kürzlich habe ich meinen Mac mini (Late 2012) verkauft. Als ich das Gerät frisch formatiert und aufgesetzt habe, habe ich realisiert, dass sich der Mac im Recovery-Modus automatisch mit meinem WLAN verbindet. Das konnte nur bedeuten, dass das Passwort für mein WLAN-Netzwerk auch noch ausserhalb der frisch formatierten Festplatte abgelegt sein musste.

Eine Frage auf Ask Different nimmt sich diesem Thema an: How to prevent storing the WiFi password on the recovery partition?

Ich entschied mich deshalb, das NVRAM des Mac minis zu löschen. Das funktioniert, indem man beim Booten folgende Tastenkombination drückt und gedrückt hält:

Option + Command + P + R

Quelle: How to reset NVRAM on your Mac

Ein erneuter Reboot in den Recovery Modus belegte dann, dass sich der Mac nicht mehr automatisch mit meinem WLAN-Netzwerk verband.

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

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 22. März 2018

Ubiquiti Edgerouter und DynDNS hinter einem doppelten NAT

Kürzlich musste ich einen Ubiquiti Edgerouter ER-X temporär hinter einem doppelten NAT betreiben (dass das nicht optimal sein kann, weiss ja wohl jeder).

Obwohl DynDNS auf dem Edgerouter konfiguriert war, um den statischen Hostnamen mit der jeweils aktuellen dynamischen IP anzupassen, funktionierte dies in einer solchen Konfiguration nicht mehr: Der Router meldete seine private IP-Adresse (192.168.0.X) am WAN-Port an DynDNS, was natürlich nicht funktionieren kann.

Damit der Edgerouter in solchen Situationen zuverlässig die öffentliche IP-Adresse des Anschlusses verwendet, muss über das GUI unter Config Tree > service > dns > dynamic > interface > eth0 des Routers das Attribut web mit dem Wert dyndns ergänzt werden:

Damit ist sichergestellt, dass der Router nicht die IP seines eth0-Interfaces zurückmeldet, sondern über den Web-Service von DynDNS seine öffentliche IP anfragt.

Wer das CLI bevorzugt:

$ configure
# set service dns dynamic interface eth0 web dyndns
# commit
# save

Quelle: Dynamic DNS behind double NAT?

Tags: , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 22. März 2018

Maxview VuQube Satellitenempfänger kann keine Schweizer HD-Sender empfangen

Ein Bekannter hat sich kürzlich einen gebrauchten Maxview VuQube Satellitenempfänger und separat dazu das benötigte Viaccess-Modul gepostet, um bei Ausflügen mit dem Wohnmobil ins nahe Ausland weiterhin Schweizer Fernsehen konsumieren zu können.

In einem Forumsbeitrag im Schweizer Satforum liest man davon, dass dem Nickname nach ein Bündner Zeitgenosse am 13. Januar 2016 mit demselben Gerät Schweizer Sender empfangen konnte:

Maxview VuQube Auto

Der Verkäufer hatte meinem Bekannten ebenfalls angegeben, dass er mit der sich selbst-ausrichtenden, portablen Satellitenschüssel die Schweizer Sender empfangen konnte. Was er leider vergessen hatte zu sagen (ein Schelm, wer sich Böses denkt): Das war vor der HD-Umstellung Ende Februar 2016 … und somit fast 2 Jahre vor dem Wiederverkaufsdatum.

Leider hat sich bei mehrmaligen Tests herausgestellt, dass zwar viele Sender auf Hotbird gefunden und angezeigt werden — die Schweizer Sender wollten aber einfach nicht reinkommen.

Einen kurzen Lichtblick gab es, als der Bekannte die Plastic-Abdeckung des Satellitenempfängers entfernte und die Kabel befestigte (er geht davon aus, dass diese beim Posttransport lose geworden waren). Dann war es möglich, ein Signal hereinzubekommen. Sobald aber die Plastic-Haube wieder auf dem Empfänger aufgesetzt hatte, wurde es aber wieder dunkel.

Weitere Google-Suchen förderten dann einen weiteren und neueren Forums-Thread zu Tage, welcher etwas klarer auf die Problematik hinweist:

Aber gerade für die Schweizer ist die [der Maxview VuQube] NICHT geeignet…..

Quelle: Megasat Campingman Portable oder Maxview VU Qube ll ?

Selbst auf der Web-Site des Herstellers liest man für das Nachfolgemodell klipp und klar:

Hinweis: Die Maxview VUQUBE Auto 2 – Antenne ist für den Empfang der verschlüsselten schweizer Sender SRF1, SRF2 usw. nicht geeignet.

Quelle: MAXVIEW VUQUBE AUTO 2

Eine E-Mail-Antwort des Maxview-Kundendiensts in Deutschland brachte dann die endgültige Bestätigung/Ernüchterung:

Die Sat-Antenne respektive der Sat-Spiegel der VuQube ist zu klein um die schweizer HD Programm zu empfangen.

Tags: , , , , , , , , , , ,
Labels: Reisen

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 22. März 2018

Mit ImageMagick eine Collage aus vier verschiedenen Bildern machen

Kürzlich musste ich vier Screenshots zu einem Bild zusammenfassen, da eine Ricardo-Auktion nur noch ein zusätzliches Bild zur Verfügung hatte. Mit ImageMagick und seinem Tool montage ist auch das kein Problem:

$ montage About_01.png About_02.png About_03.png About_04.png -tile 2x -geometry +0+0 -border 100 -bordercolor white montage.png

Damit resultiert eine 2×2 Matrix der Screenshots.

Nachtrag

Hat man nur zwei Bilder und möchte man diese übereinander stellen, wählt man folgende Syntax:

$ montage Oben.jpg Unten.jpg -tile 1x -geometry +0+0 -border 100 -bordercolor white montage.jpg

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 22. März 2018

Wo unterhält Fiber7 in Bern POPs?

Auch hier ist Init7 sehr transparent:

Unsere Fiber7 PoPs

In Bern sind dies aktuell (März 2017):

  • 640BOL – Bollwerk
  • 640BRE – Breitenrain
  • 640BUE – Bümpliz
  • 640BUZ – Burgernziel
  • 640BEM – Mattenhof
  • 640KOE – Köniz
  • 640LAG – Länggasse
  • 640WAB – Wabern
  • 640WEH – Weissenbühl

Der POP 640NIE (Niederwangen) ist noch ausgegraut.

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 22. März 2018

cacti benötigt die MySQL Zeitzonen-Datenbank

Vor kurzem habe ich meine cacti-Installation „gelüpft“. Leider kam es vorübergehend zu einem Showstopper, weil die Software nach einer MySQL Timezone database verlangt, welche ich nicht installiert hatte:

ERROR: Your MySQL TimeZone database is not populated. Please populate this database before proceeding.

Wieso das sonst sehr benutzerfreundliche cacti-Installationsscript diese Datenbank in so einem Fall nicht einfach nachinstalliert, wissen nur die Geier.

Es war also Handarbeit angesagt — nach etwas googlen kein Problem:

$ mysql -u root -p mysql < /usr/share/mysql/mysql_test_data_timezone.sql

Quelle: Upgrade problem MySQL Timezone

Die Empfehlung, dem cacti-Benutzer zudem noch die Leseberechtigung auf die Tabelle mysql.time_zone_name zu geben, war bei mir nicht nötig.

Offenbar gibt es bei MySQL auch einen eigenständigen Befehl, der die Sache installiert – getestet habe ich das aber nicht:

$ mysql_tzinfo_to_sql tz_dir

Quelle: 4.4.6 mysql_tzinfo_to_sql — Load the Time Zone Tables

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 22. März 2018

mysqldump: MySQL-Benutzer hat keine Rechte, eine Tabelle zu sperren

Als ich kürzlich ein selten gebrauchtes Backup-Script ausführen wollte, kam ich folgende Fehlermeldung zu Gesicht:

mysqldump: Got error: 1044: "Access denied for user 'username'@'10.1.2.3' to database 'app_app'" when using LOCK TABLES

Die Lösung für das Problem ist eigentlich ganz simpel. Entweder über die mysql-Kommandozeile:

GRANT LOCK TABLES ON app_app.* TO 'username'@'10.1.2.3';
FLUSH PRIVILEGES;

… oder über phpMyAdmin, wo man dem zutreffenden Benutzer unter mysql > Tables > db ein Häkchen bei Lock_tables_priv setzt …

… den Datensatz speichert und danach die Benutzerprivilegien neu lädt, indem man im Menupunkt „SQL“ den Befehl „FLUSH PRIVILEGES“ eingibt und das Kommando ausführt.

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 22. März 2018

Wenn der UniFi Controller die MongoDB Log-Datei gigabyteweise füllt

Ich betreibe an drei physischen Standorten auf zu Linux-Servern umfunktionierten Lenovo-Laptops je einen UniFi-Controller, um die UniFi-Access Points an diesen drei Standorten zu provisionieren und zu überwachen.

Wer diese Software ebenfalls im Einsatz hat, sollte insbesondere nach Updates gelegentlich mal in das Verzeichnis /var/log/unifi reinschauen und überprüfen, dass sich die Log-Datei mongod.log nicht im Sekundentakt mit nachfolgend aufgeführten Fehlermeldungen füllt und so locker mehrer Gigabyte gross werden kann:

2018-03-12T20:49:21.010+0100 I CONTROL  [main] ***** SERVER RESTARTED *****
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] MongoDB starting : pid=26817 port=27117 dbpath=/usr/lib/unifi/data/db 64-bit host=HOSTNAME
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] db version v3.2.11
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] git version: 009580ad490190ba33d1c6253ebd8d91808923e4
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.2l  25 May 2017
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] allocator: tcmalloc
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] modules: none
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] build environment:
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten]     distarch: x86_64
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten]     target_arch: x86_64
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] options: { net: { bindIp: "127.0.0.1", http: { enabled: false }, port: 27117, unixDomainSocket: { pathPrefix: "/usr/lib/unifi/run" } }, storage: { dbPath: "/usr/lib/unifi/data/db" }, systemLog: { destination: "file", logAppend: true, path: "/usr/lib/unifi/logs/mongod.log" } }
2018-03-12T20:49:21.068+0100 E NETWORK  [initandlisten] listen(): bind() failed errno:98 Address already in use for socket: 127.0.0.1:27117
2018-03-12T20:49:21.069+0100 E NETWORK  [initandlisten]   addr already in use
2018-03-12T20:49:21.069+0100 E STORAGE  [initandlisten] Failed to set up sockets during startup.
2018-03-12T20:49:21.069+0100 I CONTROL  [initandlisten] dbexit:  rc: 48

Relevant ist die eine Zeile, die da lautet:

2018-03-12T20:49:21.068+0100 E NETWORK  [initandlisten] listen(): bind() failed errno:98 Address already in use for socket: 127.0.0.1:27117

Sie besagt, dass bereits ein Prozess auf Port 27117 lauscht. Und was macht das blöde Stück Software in einem solchen Fall? Es startet neu, immer wieder, ohne Ende. Und bei jedem Neustart (gefühlt alle Sekunde, wenn man sich mit tail -f dranhänkt) füllt sich das Log mit weiteren 1600+ Bytes und somit mit 5.6 Megabytes pro Stunde, 134.4 MB pro Tag und 940.8 MB pro Woche.

Als Anschauungsbeispiel das Log-Verzeichnis auf einem meiner Server:

/var/log/unifi]# ls -lh
total 1.2G
-rw------- 1 unifi root     0 Mar 18 00:08 mongod.log
-rw------- 1 unifi root   153 Jan 12 14:32 mongod.log.10.gz
-rw------- 1 unifi root   900 Jan  5 23:38 mongod.log.11.gz
-rw------- 1 unifi root   882 Dec 30 22:15 mongod.log.12.gz
-rw------- 1 unifi root   687 Dec 23 02:27 mongod.log.13.gz
-rw------- 1 unifi root   691 Dec 16 10:58 mongod.log.14.gz
-rw------- 1 unifi root  1.1G Dec  2 12:07 mongod.log.15.gz
-rw------- 1 unifi root  3.4M Mar 13 21:30 mongod.log.1.gz
-rw------- 1 unifi root   30M Mar 12 00:09 mongod.log.2.gz
-rw------- 1 unifi root   23M Mar  4 00:09 mongod.log.3.gz
-rw------- 1 unifi root   30M Feb 26 00:07 mongod.log.4.gz
-rw------- 1 unifi root   23M Feb 18 00:09 mongod.log.5.gz
-rw------- 1 unifi root   30M Feb 12 00:08 mongod.log.6.gz
-rw------- 1 unifi root  1.7M Feb  4 00:10 mongod.log.7.gz
-rw------- 1 unifi root   675 Jan 26 09:19 mongod.log.8.gz
-rw------- 1 unifi root   236 Jan 21 14:25 mongod.log.9.gz

Wie man auf einen Blick sieht, hat sich das Log in der Woche vom 25. November bis zum 2. Dezember auf diese Weise gefüllt und war selbst mit gzip gezippt noch satte 1.1GB gross. Im Vergleich zu anderen Wochen, wo ein paar wenige Bytes zusammenkommen.

Wer den UniFi-Controller auf einer SSD-Platte laufen hat, dem werden ob diesen Schreiboperationen die Tränen kommen.

Was ist die Lösung?

# killall mongod

Startet der UniFi-Controller die MongoDB das nächste Mal neu, kann sie sich an den Port binden.

In den Foren des Herstellers finden sich auf Anhieb eine einzige Meldungen zum Symptom, aber mit einem anderen Lösungsvorschlag, der mit meiner Situation nichts zu tun hatte:

Auf Ask Ubuntu findet sich eine generelle Problemmeldung zum Thema MongoDB: Mongod server not woking due to the following error. Von hier stammt schlussendlich der essentielle Hinweis, einfach den bereits laufenden mongodb-Prozess zu „killen“.

Tags: , , ,
Labels: Linux

2 Kommentare | neuen Kommentar verfassen

Donnerstag, 22. März 2018

Nicht über Apple gekauften AppleCare Protection Plan registrieren

Da mein iMac 27″ (Late 2015) diesen März ein Jahr alt wurde, habe ich mich entschieden, einen Apple Care Protection Plan anzuschaffen. Diesen kann man innerhalb eines Jahres nach Kaufdatum des Macs erstehen und die Garantie des Geräts auf drei Jahre verlängern.

Für meinen iMac handelt es sich um das Produkt mit der Produktenummer MF216D/A. Es wäre möglich, die Garantieverlängerung bequem online über Apple zu kaufen, doch dies hätte mit satten 249 CHF zu Buche geschlagen.

Kauft man die physische Box-Version über einen Detailhändler, kann man einiges an Geld sparen. Da dies mein erster Kauf eines AppleCare Produkts war, entschied mich für volles Risiko und orderte stattdessen den Artikel Apple AppleCare Protection iMac MD007D/A von Techniworld.ch — für 153.55 CHF. Eine Ersparnis von knapp 100 CHF. Und um es vorwegzunehmen: Ja, es handelt sich um das identische Produkt und Apple hat die so gekaufte Garantieverlängerung akzeptiert.

Mit der Seriennummer, die auf der Papierbroschüre aufgeklebt ist, identifiziert man gegenüber Apple die Gültigkeit des Plans. Diese Nummer muss gemäss Apple folgendermassen zusammen mit dem Gerät registriert werden:

AppleCare-Vertrag registrieren

  • Melden Sie sich bei „Mein Support“ mit Ihrer Apple-ID und Ihrem Passwort an.
  • Wählen Sie das Gerät aus, für das Sie einen AppleCare-Vertrag registrieren müssen.
  • Klicken Sie auf „Abdeckung hinzufügen“.
  • Klicken Sie auf „Jetzt registrieren“.
  • Geben Sie Ihre Vertragsnummer und Ihre E-Mail-Adresse ein. Akzeptieren Sie dann die Allgemeinen Geschäftsbedingungen von Apple.

Quelle: Ihre Apple-Geräte und AppleCare-Verträge bei „Mein Support“ ansehen

Soweit so gut — ich konnte mich tatsächlich problemlos auf „My Support“ einloggen, sah meinen iMac und darunter den blau hinterlegten Link, um einen AppleCare Protection Plan für das Gerät zu hinterlegen.

Das Problem kam erst beim Ausfüllen meiner Kontaktdaten zu Tage: Als Land waren die „United States of America“ hinterlegt, und ich konnte diese Auswahl nicht ändern (wieso Apple nicht einfach die bereits in der Apple ID hinterlegten Informationen verwendet, ist mir schleierhaft).

Nach etwas Pröbeln schaffte ich es dann schlussendlich, dass in diesem Formular die Schweiz als Land voreingestellt war und schweizerische Adressen eingegeben werden konnten. Wie man das macht?

  • Zuerst einmal verwendet man einen anderen Browser, der noch nicht in diese Apple Support-Seite eingeloggt ist. Am Besten löscht man alle Caches und Cookies, oder verwendet gleich den Incognito-Modus. Ich habe Firefox gewählt.
  • Anschliessend stellt man die Sprache des Browsers auf „Deutsch/Schweiz [de-ch]“ ein. In Firefox unter Mac erfolgt dies über das Menu Firefox > Einstellungen > Allgemein > Sprache
  • Schlussendlich verwendet man die (fast) identische URL, wie sie Apple im Hilfedokument angibt, fügt aber als GET-Parameter folgenden Zeichenkette an: ?selectedLocale=de_CH. Die URL lautet nun also komplett mysupport.apple.com/?selectedLocale=de_CH. Surft man die Support-Seite auf diesem Weg an, sollte sie auf Deutsch angezeigt werden

Danach bin ich dem normalen Weg gefolgt.

Falls es damit immer noch nicht klappt — d.h. als Herkunftsland sind immer noch die USA ausgewählt — empfehle ich noch einen letzten Versuch: mysupport.apple.com/agreements/enroll?selectedLocale=de_CH

A propos: Wenn ich heute mit Firefox die Support-Seite ansurfe, erscheint folgende Fehlermeldung:

Tags: , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen