Freitag, 21. Oktober 2016

Wenn eine Linux-Anwendung trotz logrotate in das rotierte Log-File schreibt

Am letzten Wochenende habe ich meine Site-to-Site OpenVPN-Infrastruktur auf Vordermann gebracht (Github-Repo folgt). Da ich aus Debugging-Gründen anfänglich sehr, sehr viel geloggt habe (verb 5 in der lokalen OpenVPN .conf-Datei) sind die Log-Dateien innert eines Tages auf satte 110 MB angewachsen. Mittlerweile — da alles sauber läuft — verwende ich verb 3 und die Log-Files sind nur noch einige Kilobytes gross.

Dennoch habe ich mich entschieden, logrotate so zu konfigurieren, dass die Log-Dateien täglich rotiert werden. Leider musste ich nach der ersten Durchführung aber realisieren, dass OpenVPN munter weiter in /var/log/openvpn/append.log.1 weiterschreibt, obwohl nun /var/log/openvpn/append.log angesagt wäre. Mit meinem Linux-Halbwissen gehe ich davon aus, dass der Filepointer des OpenVPN-Daemons auf dieselbe Datei zeigt, auch wenn sich deren Namen ändert.

Glücklicherweise kennen die Entwickler von logrotate dieses Problem und bieten dafür eine handliche Option namens copytruncate an:

/var/log/openvpn/*.log {
	daily
	missingok
	rotate 366
	compress
	delaycompress
	copytruncate
	create 600 root root
}

Quelle: openvpn logrotate

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 11. Oktober 2016

SFP-Informationen unter Linux anzeigen

Weil ich meinen Fiber7 SFP-Transceiver im Turris Omnia (noch) nicht zum Laufen bringen konnte, habe ich mich schlau gemacht, wie man Informationen über diesen Hardwarebaustein mit Linux-Bordmitteln abfrägt.

Ein Knowledgebase-Artikel bei Cumulus Networks lotste mich zu ethtool.

Konkret (von der Cumulus Web-Site kopiert):

$ ethtool swp1
Settings for swp1:
        Supported ports: [ FIBRE ]
        Supported link modes:   1000baseT/Full
                                10000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: No
        Advertised link modes:  1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Speed: 10000Mb/s
        Duplex: Full
        Port: FIBRE
        PHYAD: 0
        Transceiver: external
        Auto-negotiation: off
        Current message level: 0x00000000 (0)

        Link detected: yes

sowie noch viel spannender folgende SFP-spezifischen Informationen:

# ethtool -m swp1
swp1: SFP detected
    Connector : CopperPigtail
        EncodingCodes : Unspecified
    ExtIdentOfTypeOfTransceiver : GBIC/SFP defined by twowire interface ID
        LengthCable(UnitsOfm) : 1
    NominalSignallingRate(UnitsOf100Mbd) : 103
        RateIdentifier : Unspecified
    ReceivedPowerMeasurementType : OMA
        TransceiverCodes :
                SFP+CableTechnology : Passive Cable
    TypeOfTransceiver : SFP or SFP Plus
        VendorDataCode(yymmdd) : 110830
    VendorName : Amphenol
        VendorOUI : Amp
    VendorPN : 571540001
        VendorRev : M
    VendorSN : APF11350017C4V

Leider scheint ethtool auf dem Turris Omnia nicht standardmässig installiert zu sein:

root@TURRIS-OMNIA:~# which ethtool
root@TURRIS-OMNIA:~# 

Nachinstallieren kann man dieses, indem man unter System > Software das Paket ethtool herunterladen und installieren lässt:

turris-omnia-ethtool
image-7008

Leider klappt es nicht wirklich, mittels dem Argument -m Informationen über Ethernet-Schnittstellen abzufragen:

# ethtool -m eth0
Cannot get module EEPROM information: Not supported

Links

Einige Hintergrundinformationen hier unter Phylink & SFP support

Tags: , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 11. Oktober 2016

Turris Omnia: Erste Erfahrungen

Am Freitag, 7. Oktober 2016, wurde mir mein über Indiegogo ge-crowdfundeter Turris Omnia-Router ins Büro geliefert.

Am Sonntag-Abend ging ich mit dem Gerät online. Zeit für ein erstes Fazit:

Fiber7 SFP funktioniert (noch) nicht

Der Router wird mit einem SFP-Slot ausgeliefert. Optimal, dachte ich mir, so kann ich meinen Gerätedschungel lichten und den im Januar gekauften Fiber Media Converter TP-LINK MC220L auf’s Altenteil schicken.

Zu früh gefreut! Wie von mir im offiziellen Forum beschrieben und von Michael Stapelberg bestätigt funktioniert der flexOptix BIDI LX SFP Transceiver aktuell nicht im Router.

Zuerst ging ich (fälschlicherweise) davon aus, dass das Problem bei Turris zu suchen ist, doch ein Tweet von Fiber7 von heute Dienstag, 11. Oktober 2016, legt nahe, dass auf Seite ISP resp. auf Seiten des SFP-Herstellers noch etwas geändert werden muss:

Performance

Eigentlich hätte ich erwartet, dass der neue Router näher an die Schallgrenze (d.h. 1 GBit/s Down- und Upstream) herankommt. Doch mein stündlich laufendes Script, welches die Geschwindigkeit zu Init7s Ookla Geschwindigkeitsserver (Ookla Server ID 3026) misst, sagt etwas anderes aus:

ookla-init7-asus-rt-ac66u-turris-omnia
image-6997

Links sieht man die Werte, die ich mit einem Asus RT-AC66U (Merlin-Firmware und mit deaktivierter Firewall) erzielt habe; rechts (nach dem Unterbruch) die Werte von Turris Omnia (mit aktivierter Firewall).

Beim Client handelt es sich um einen Intel NUC DC3217IYE, welcher mit einem Cat 5e-Kabel über einen 16-Port TP-LINK TL-SG1016D über ein 20m Cat 6 STP-Flachband-Kabel auf einen ZyXEL GS1100-8HP PoE Switch via ein Cat 5e-Kabel am Turris angeschlossen ist.

Ich gehe davon aus, dass die Performance höher wäre, wenn ich einen nicht so schmalbrüstigen Client verwenden würde. Und ja, die Firewall des Turris könnte ich ja eigentlich der Performance wegen auch deaktivieren. Doch mich reizt es, die Crowd-Firewall eingeschaltet zu belassen, um mich und mein Netzwerk besser vor Gefahren aus dem Internet zu schützen.

Doch das spielt hier keine Rolle, weil im Setup einzig der Router selber ausgewechselt wurde, der Rest blieb gleich.

Michael hingegen kommt der Schallmauer gefährlich nahe — 927 MBit/s:

Führe ich speedtest-cli (ein Python-Script) direkt auf dem Turris Omnia aus, erhalte ich folgende Werte:

# ./speedtest-cli --simple --server 3026
Ping: 4.704 ms
Download: 684.35 Mbit/s
Upload: 208.04 Mbit/s

CPU-Auslastung

Dank der Aufzeichnung der Vitalparameter des Routers mittels Cacti musste ich soeben feststellen, dass die beiden CPUs des Gerätes seit heute Mitternacht (sprich seit meinem zweiten, fehlgeschlagenen Test mit dem SFP-Transceiver) 100% beträgt. Auf beiden Cores:

turris-omnia-cpu-0-usage
image-6998

turris-omnia-cpu-1-usage
image-6999

Ein Login auf dem Router und htop zeigen, welche Prozesse die Last verursachen:

turris-omnia-socat-cpu-usage
image-7000

Die Prozesse habe ich direkt in htop mittels F9 und SIGKILL abgeschossen (ein Neustart von socat im LuCI-Interface unter System > Software hat nichts gebracht). Jetzt ist die CPU-Auslastung im einstelligen Prozentbereich und die Load Average bereits bei 0.40.

LEDs

Natürlich dürfen frei konfigurierbare LED-Farben nicht den Ausschlag geben, ein Produkt zu kaufen. Dennoch möchte ich dies nicht mehr missen. Nun sehe ich nämlich von der Eingangstüre unserer Wohnung aus, ob der Router läuft (grünes LED für Power) und ob er mit dem Internet verbunden ist (rotes LED für WAN). Hinzu kommen weiss blinkende LEDs, die mir zeigen, dass im LAN Pakete herumgeschickt werden.

turris-omnia-leds
image-7001

IPv6

Das Ding würde auch IPv6 unterstützen, doch mental, fähigkeitstechnisch und auf Grund meiner leicht komplexeren Netzwerk-Infrastruktur im LAN sehe ich mich derzeit nicht imstande, diesen Schritt bereits zu wagen. Gut zu wissen, dass Turris auf jeden Fall bereit wäre:

Usability

Verwirrend (und unschön) ist es, dass der Router über zwei Web-Oberflächen verfügt: Einerseits das von Turris Omnia selbst entwickelte Foris, welches einen Wizard, aber kaum Einstellungsmöglichkeiten bietet, andererseits das OpenWRT-LuCI-Interface, über welches man jedes hinterste Bit des Routers konfigurieren kann (oder so).

Das letztere Interface kannte ich so bereits von meinem TP-LINK TL-MR3020 Travel-Router, der mich auf Reisen überall hin begleitet. Ganz interessant ist hier der Paket-Manager des Turris, obwohl ich abgesehen von snmpd und ethtool noch kein Paket installiert habe. Die Bedienbarkeit dieses Interfaces ist aber nicht so simpel gehalten wie bei einem Consumer-Router und benötigt deshalb eine gewisse Einarbeitungszeit.

Nachtrag: Unboxing-Photos

Turris vom Flickr-Benutzer Doommeer

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

3 Kommentare | neuen Kommentar verfassen

Samstag, 8. Oktober 2016

Der neueste Furz der Zürcher Öko-Päpste

Ich, soeben auf Facebook:

Und jetzt karren die Zürcher Restaurations-Öko-Päpste anstelle Wasserflaschen halt einfach Kohlensäure-Flaschen quer durch die Schweiz, brauchen Atomstrom zur Kühlung und verwenden wohl auch eine in China produzierte und über die Weltmeere geschipperte “Wasseraufbereitungsmaschine” (graue Energie, irgendjemand?).

Und natürlich fliegen die WFW-NGO-Lölis mindestens zwei Mal im Jahr mit dem Flieger nach Afrika, um den Fortschritt ihres Feigenblatt-Projektes zu begutachten. Flick fort.

Kritik auf den Artikel: Zürcher Wirte verbannen Marken-Mineralwasser

Tags: , , , ,
Labels: Schweiz

Keine Kommentare | neuen Kommentar verfassen

Samstag, 8. Oktober 2016

iOS 10 Keyboard stürzt periodisch ab

Seit ich iOS 10.0.0 respektive 10.0.1 auf meinem iPhone SE installiert habe, “stürzt” die Tastatur des iPhones sporadisch ab.

Das Problem zeigt sich meistens in iMessage: Ich bin in einem Chat mit meiner Frau, Familienmitglieder oder einem Kollegen, wenn die Tastatur plötzlich einfriert und keine Touch-Events mehr registriert. iMessage läuft weiterhin, denn ich kann mittels Wisch-Bewegungen weiterhin durch die Nachrichten-Historie durchscrollen. Das bedeutet, dass nur der Tastaturbereich vom Absturz betroffen ist (vermutlich, weil die Tastatur ein eigenständiges Programm ist, welches in einer Art Sandbox ausgeführt wird, korrekt?)

Wenn ich nun iMessage mit einem Klick auf den Home-Button verlasse, funktioniert das iPhone für einige Sekunden oder Minuten ordnungsgemäss. Doch wenn ich nun beispielsweise zu Spotlight wechsle und in das Suchfeld etwas eingeben will, friert das ganze iPhone-Interface ein.

In einem solchen Fall bleibt mir nichts anderes mehr übrig, als das iPhone mittels eines Soft-Resets neu zu starten: Den Home-Button und den Power-Button ca. 5 Sekunden lang gedrückt halten. iOS lädt dann neu, wobei es kein vollständiger Reboot ist, weil ich den PIN meiner SIM-Karte nicht erneut eingeben muss.

Der Bug nervt, und ich bin ernüchtert, denn offenbar scheint das Problem nicht viele Leute zu betreffen, sonst hätte man mehr darüber gehört.

Meldungen anderer Betroffener

Folgende Hinweise zum Bug habe ich mittels einer Google-Suche im Internet gefunden:

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

1 Kommentar | neuen Kommentar verfassen

Samstag, 8. Oktober 2016

Wenn iOS 10 partout “usegfunge” zu “Umseglungen” korrigiert

Seit dem Umstieg auf iOS 10 sah ich mich beim Erfassen von berndeutschen iMessages mit dem Problem konfrontiert, dass die berndeutschen Wörter permanent in ähnlich klingende deutsche Wörter umgewandelt wurden.

Aus “usegfunge” (dt. herausgefunden) wurde so stets “Umseglungen”.

Bravo, Apple! Am Donnerstag regte ich mich derart über dieses “Feature” auf, dass ich ihm genauer auf den Grund ging.

Unter Settings > General > Keyboard war die Eigenschaft “Auto-Correction” für “All Keyboards” längst deaktiviert. Als deutschsprachiger Schweizer ist das wohl eine der ersten Konfigurationsanpassungen, die man an einem jungfräulichen iOS vornimmt.

Doch wieso wurden meine Texte trotzdem reproduzierbar korrigiert?

Nach einigen Google-Suchen dann die Erkenntnis: Ich schreibe meine Texte auf dem iPad in der Regel mit einer Hardware-Tastatur; in meinem Fall mit einer Logitech Type+ for iPad Air.

In iOS 10 gibt es für Hardware-Tastaturen gesonderte Einstellungen (welche erscheinen, wenn die Tastatur verbunden ist)! Diese lassen sich unter Settings > General > Keyboard > Hardware Keyboard anpassen.

Ich deaktivierte so auch an dieser Stelle Auto-Capitalization und Auto-Correction.

iOS 10 General Settings Keyboard Hardware Keyboard Auto-Correction
image-6984

Zurück in iMessage zeigte sich der erhoffte Effekt aber nicht: “usegfunge” wurde weiterhin zu “Umseglungen” ersetzt. Erst als ich iMessage zwangsweise beendete (Doppelklick auf den Home-Button, das iMessage-Fenster dann nach oben wischend) und neu startete konnte ich endlich wieder sauberes, unkorrigiertes Berndeutsch schreiben.

Via: Disable Autocorrect for External BlueTooth Keyboard – iOS 9.2

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

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 28. September 2016

WhatsApp kann nicht auf iCloud backupen

Nachdem ich meinen Mac mini endlich auf OS X 10.11 El Capitan gelüpft hatte, konnte ich endlich auch iCloud Drive über all meine Geräte (Mac mini, MacBook Air, iPhone SE, iPad Air 2, iPad 4) aktivieren.

Leider aber bockt WhatsApp auf meinem iPhone SE und will partout nicht nach iCloud backupen:

whatsapp-iphone-se-ios-10-backing-up
image-6949

Uploading: 0 bytes of 456.0 MB (0%)

Und genau in diesem Zustand verweilt die Anzeige, minuten- und stundenlang, ohne dass ein einziges Byte in die iCloud hochgeladen wird.

Gestern und heute habe ich ein, zwei Stunden investiert, um dem Problem auf den Grund zu gehen. Leider habe ich die Lösung (noch?) nicht gefunden.

Ein Blick auf dem iPhone SE unter Settings > iCloud > iCloud Drive zeigt, dass iCloud aktiviert ist, WhatsApp der Zugriff auf iCloud erlaubt ist und das iPhone auch über das Mobilfunknetz mit iCloud kommunizieren darf:

iphone-se-icloud-drive-top
image-6950

iphone-se-icloud-drive-bottom
image-6951

Soweit so gut. Spannend wird es, wenn ich den iCloud Speicherverbrauch genauer anschaue. Hierzu gehe ich zu Settings > iCloud > Storage > Manage Storage, wo ich unter der Rubrik “DOCUMENTS & DATA” den Eintrag

WhatsApp Messen… 2.1MB

entdecke:

iphone-se-icloud-manage-storage
image-6952

Gestern reagierte das iPhone nicht, als ich diesen Eintrag antippte.

Versuch unter iCloud Web

Als nächste loggte ich mich auf die Web-Oberfläche von iCloud ein und versuchte es dort mit einer Bereinigung. Unter Einstellungen fand ich folgendes Dialogfeld:

Apple iCloud Web Reset Documents and Data
image-6953

Leider klappte das auch nicht:

Apple iCloud Web Could not reset Documents and Data
image-6954

Versuch unter macOS

Man kann übrigens auch versuchen, das WhatsApp-Backup unter OS X zu entfernen — doch gestern schlug auch das fehl:

os-x-icloud-manage-storage
image-6955

os-x-icloud-manage-storage-whatsapp
image-6956

os-x-icloud-manage-storage-whatsapp-delete-documents-and-data
image-6957

os-x-icloud-manage-storage-whatsapp-delete-documents-and-data-failed-try-again-later
image-6958

In der Console las ich die nichtssagende Fehlermeldung:

com-apple-preferences-icloud-remoteservice-js_log-error-deletedate-returned-error-code-500
image-6959

Erneuter Versuch auf dem iPhone

Doch heute gelange ich auf dem iPhone schnurstracks in die Detailansicht:

iphone-se-icloud-manage-storage-whatsapp
image-6960

Edit angetippt, dann erscheint die Möglichkeit, die Daten zu löschen:

iphone-se-icloud-manage-storage-whatsapp-edit
image-6961

iphone-se-icloud-manage-storage-whatsapp-delete-all
image-6962

Dies habe ich soeben getan, und tatsächlich, WhatsApp erscheint nun nicht mehr in der Liste. Immerhin ein Fortschritt zu gestern — wobei ich felsenfest überzeugt war, dass wenn einmal dieses veraltete Backup weg ist das Backup funktionieren wird. Falsch gedacht; WhatsApp hängt immer noch bei 0 Bytes.

Ein kompletter Neustart des Gerätes änderte schlussendlich alles! Als ich den Button Back Up Now anklickte, lud das iPhone nach ein paar Sekunden “Preparing” Daten in irrer Geschwindigkeit nach iCloud:

whatsapp-chat-backup-preparing-28
image-6963

whatsapp-chat-backup-uploading-433-2-mb
image-6964

whatsapp-chat-backup-last-backup-today-at-19-53
image-6965

Seither kann ich endlich beruhigt sein, bei einem Verlust meines Telefons garantiert noch alle WhatsApp-Mitteilungen als Sicherung auf iCloud zu besitzen:

Die Lösung?

Leider für mich immer noch ein Mysterium. Doch was ich gestern gemacht habe: iCloud Drive auf all meinen Geräten ausgeschaltet, die Geräte heruntergefahren, neugestartet und erst dann wieder eingeschaltet.

Update 2016-11-17: Ich vermute mittlerweile, dass das iOS-Upgrade meines ehrwürdigen iPad 4 das Problem gelöst hat. Meine Hypothese: Da auf dem Gerät noch iOS 9 installiert war, verhinderte das Gerät so, dass meine iCloud upgegradet werden kann. Sobald das Gerät auf iOS 10 migriert war, konnte die von Apple durchgeführte, transparente Migration endlich losgetreten werden.

iCloud Drive-Zugang über iCloud.com

Während dem Debugging-Prozess ist mir aufgefallen, dass ich weder über meinen Mac mini, noch mein iPad Air 2 auf das (webbasierte) iCloud Drive unter iCloud.com zugreifen kann. Folgende Fehlermeldung erscheint:

icloud-com-icloud-drive-there-was-a-problem-loading-the-contents-of-this-folder
image-6966

There was a problem loading the content of this folder.

Der nette Herr von der Apple Support-Hotline konnte mir heute mit diesem Problem leider auch nicht weiterhelfen. Seine einzige Empfehlung: Cookies löschen und den Mac mini neu starten. Immerhin hat mich Apple angerufen und so den Anruf auf das Mobilfunknetz bezahlt.

Er beharrte zudem darauf, dass ich diesen Screen auf meinem iPad nicht anzeigen lassen könne — doch, kann ich, wenn ich in Safari lange auf dem Reload-Button verharre und dann “Request Desktop Site” auswähle.

iCloud Drive-Ablage auf dem lokalen Mac

Im Laufe der Untersuchung kam ich zudem auf die Idee, den WhatsApp-Ordner auf iCloud über meinen Mac zu löschen. Das iCloud Drive wird auf meinem Mac mini unter OS X 10.11 in folgendem Verzeichnis gecached:

~/Library/Mobile Documents/

Mit dem Tool Plain Cloud erhält man eine Übersichtsliste in Form eines GUIs:

plain-cloud-whatsapp
image-6967

Dort habe ich dann auch WhatsApp wiedergefunden, welches im folgenden Pfad liegt (lag):

~/Library/Mobile Documents/57T9237FN3~net~whatsapp~WhatsApp

Der Inhalt gestern (vor rm -rf):

57t9237fn3netwhatsappwhatsapp
image-6968

Dieses Verzeichnis auf der Kommandozeile von Hand zu löschen brachte gestern leider nicht den gewünschten Erfolg.

brctl

Apple stellt mit brctl ein Kommandozeilentool zur Verfügung (Kommentar von Mendel Kucharzeck vom 11.07.16 um 22:08 Uhr), welches beim Debugging eventuell auch noch weiterhelfen könnte. Hier der Output für gestern:

$ brctl log
[note]    0.000 [2016-09-27 02:40:22.115] sqlite.clientTruth             sync-down.periodic-sync BRCPeriodicSyncOperation.m:137
        scheduled a useless periodic sync
[note]  28798.505 [2016-09-27 10:40:20.620] sqlite.clientTruth             sync-down.periodic-sync BRCPeriodicSyncOperation.m:137
        scheduled a useless periodic sync
[ERROR] 32416.649 [2016-09-27 11:40:38.764] cloudkit.operation.callback    sync.down            BRCSyncDownOperation.m:201
        fetch operation 57T9237FN3.net.whatsapp.WhatsApp error: <CKError 0x7ff7cd9f6220: "Server Rejected Request" (15/6000); server message = "Zone migration failed"; Retry after 43200.0 seconds; uuid = 1CFAE291-105A-4BA7-B0DA-663C5F5EA27F; conta
[note]  56254.108 [2016-09-27 18:17:56.223] brc.sync                       container.scheduler  BRCContainerScheduler.m:819
        received a push for container 57T9237FN3~net~whatsapp~WhatsApp
[note]  56254.412 [2016-09-27 18:17:56.527] brc.sync                       container.scheduler  BRCContainerScheduler.m:808
        received a push for the container-metadata zone
[note]  56261.563 [2016-09-27 18:18:03.677] brc.sync                       container.scheduler  BRCContainerScheduler.m:808
        received a push for the container-metadata zone
[WARN]  56318.506 [2016-09-27 18:19:00.621] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd6392c0; recordType=AppContainer, recordID=iCloud.com.microsoft.lync2013.iphone:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=3>
[WARN]  56318.506 [2016-09-27 18:19:00.621] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd68bb00; recordType=AppContainer, recordID=iCloud.com.kayak.travel:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=4>
[WARN]  56318.507 [2016-09-27 18:19:00.621] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd6caad0; recordType=AppContainer, recordID=iCloud.com.reddit.alienblue:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=5>
[WARN]  56318.507 [2016-09-27 18:19:00.622] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd631250; recordType=AppContainer, recordID=LWL9XTYF8Q.com.syniumsoftware.macfamilytree7:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=6>
[WARN]  56318.507 [2016-09-27 18:19:00.622] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd6392c0; recordType=AppContainer, recordID=iCloud.QW9YDLAY9G.com.hotels.HotelsNearMe:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=7>
[WARN]  56318.508 [2016-09-27 18:19:00.622] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd6caad0; recordType=AppContainer, recordID=ZKENARDFWN.com.ifolor.ifolor-designer:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=8>
[WARN]  56318.508 [2016-09-27 18:19:00.623] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd631250; recordType=AppContainer, recordID=iCloud.com.getdropbox.Dropbox:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=9>
[WARN]  56318.509 [2016-09-27 18:19:00.623] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd68b2e0; recordType=AppContainer, recordID=com.apple.mobilemail:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=a>
[WARN]  56318.509 [2016-09-27 18:19:00.623] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd6392c0; recordType=AppContainer, recordID=L996Q9B5UB.com.landi.weather:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=b>
[WARN]  56318.509 [2016-09-27 18:19:00.624] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd68b2e0; recordType=AppContainer, recordID=iCloud.com.apple.iBooks:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=c>
[WARN]  56318.509 [2016-09-27 18:19:00.624] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd68bb00; recordType=AppContainer, recordID=F6266T9T75.com.apple.iMovie:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=d>
[WARN]  56318.510 [2016-09-27 18:19:00.625] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7ca980b30; recordType=AppContainer, recordID=com.apple.Numbers:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=e>
[WARN]  56318.510 [2016-09-27 18:19:00.625] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7c860c6c0; recordType=AppContainer, recordID=com.apple.QuickTimePlayerX:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=f>
[WARN]  56318.511 [2016-09-27 18:19:00.625] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7c8610550; recordType=AppContainer, recordID=com.apple.Preview:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=g>
[WARN]  56318.511 [2016-09-27 18:19:00.626] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd906ac0; recordType=AppContainer, recordID=com.apple.Notes:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=h>
[WARN]  56318.511 [2016-09-27 18:19:00.626] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7c860c6c0; recordType=AppContainer, recordID=8YE23NZS57.com.kayak.travel:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=i>
[WARN]  56318.512 [2016-09-27 18:19:00.626] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7c8610550; recordType=AppContainer, recordID=com.apple.Pages:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=j>
[WARN]  56318.512 [2016-09-27 18:19:00.627] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7c860c6c0; recordType=AppContainer, recordID=iCloud.com.tinyspeck.chatlyio:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=k>
[WARN]  56318.512 [2016-09-27 18:19:00.627] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7c8610550; recordType=AppContainer, recordID=com.apple.mail:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=l>
[WARN]  56318.513 [2016-09-27 18:19:00.627] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd9e2800; recordType=AppContainer, recordID=com.apple.TextEdit:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=m>
[WARN]  56318.513 [2016-09-27 18:19:00.628] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7c8610550; recordType=AppContainer, recordID=57T9237FN3.net.whatsapp.WhatsApp:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=n>
[WARN]  56318.513 [2016-09-27 18:19:00.628] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7c860c6c0; recordType=AppContainer, recordID=37GSA6A9EQ.com.benkazez.FlightTrack:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=o>
[WARN]  56318.514 [2016-09-27 18:19:00.628] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7c8611e30; recordType=AppContainer, recordID=CZF32S63U5.com.phaidon.wallpaperParis:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=p>
[WARN]

Spannend ist insbesondere dieser Eintrag mit dem Fehler “Zone migration failed”:

[ERROR] 32416.649 [2016-09-27 11:40:38.764] cloudkit.operation.callback    sync.down            BRCSyncDownOperation.m:201
        fetch operation 57T9237FN3.net.whatsapp.WhatsApp error: <CKError 0x7ff7cd9f6220: "Server Rejected Request" (15/6000); server message = "Zone migration failed"; Retry after 43200.0 seconds; uuid = 1CFAE291-105A-4BA7-B0DA-663C5F5EA27F; conta
[note]  56254.108 [2016-09-27 18:17:56.223] brc.sync                       container.scheduler  BRCContainerScheduler.m:819
        received a push for container 57T9237FN3~net~whatsapp~WhatsApp
[note]  56254.412 [2016-09-27 18:17:56.527] brc.sync                       container.scheduler  BRCContainerScheduler.m:808
        received a push for the container-metadata zone
[note]  56261.563 [2016-09-27 18:18:03.677] brc.sync                       container.scheduler  BRCContainerScheduler.m:808
        received a push for the container-metadata zone

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

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 27. September 2016

Mit PowerShell alle Mitglieder einer Active Directory-Gruppe auflisten

$group = "MEINEGRUPPE" 
 
# https://technet.microsoft.com/en-us/library/ff730967.aspx
$strFilter = "(&(objectCategory=Group)(name=$group))"

$objDomain = New-Object System.DirectoryServices.DirectoryEntry

$objSearcher = New-Object System.DirectoryServices.DirectorySearcher
$objSearcher.SearchRoot = $objDomain
$objSearcher.PageSize = 1000
$objSearcher.Filter = $strFilter
$objSearcher.SearchScope = "Subtree"
 
$colProplist = "name","member"
foreach($i in $colPropList) {
    $objSearcher.PropertiesToLoad.Add($i)
} 

$colResults = $objSearcher.FindAll()

foreach($objResult in $colResults) {
    $objItem = $objResult.Properties
    # PHP-Style var_dump():
    #echo $objItem | %{echo $_;}

    $members = $objItem.member
    Write-Output $members
} 

$filename = "$group.txt"

$membersReadable = $members | Out-String
"$group" | Out-File -FilePath $filename 
"$membersReadable" | Out-File -FilePath $filename -append

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

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 21. September 2016

Irrtümlich gelöschte Google Kalender-Einträge wiederherstellen

Das geht ganz einfach: Auf der Web-Oberfläche klickt man auf den Pfeil-Button, um ein Dropdown mit den Eigenschaften des Kalenders anzuzeigen:

google-kalender-eigenschaften
image-6941

Dort klickt man auf “Papierkorb ansehen” und erhält eine Liste der in den letzten 30 Tagen gelöschten Einträge:

google-kalender-papierkorb
image-6942

Einzelne Einträge kann man mit Klick auf die Checkbox links und dem Button “Ausgewählte Termine wiederherstellen” am Ende der Liste wiederherstellen.

Tags: , , , , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen

Montag, 19. September 2016

Videos in der Facebook iOS-App mit AirPlay auf einen Apple TV streamen

Stephanie speichert in der Facebook-App regelmässig Videos, welche sie mir am Abend über den Apple TV 4 auf dem Plasma-Fernseher zeigen möchte. Leider will die Facebook iOS-App partout nicht mit AirPlay auf den Apple TV streamen; und auch wenn man den ganzen Bildschirm spiegelt (“mirroring”) klappt die Wiedergabe nicht zuverlässig.

Keine Ahnung, was in Mark gefahren ist.

Gestern fand ich dann die Lösung des Problems:

It’s not the most convenient way, but it works:

  1. First airplay a video from youtube to your Apple TV
  2. As soon as the video start playing on your ATV go to facebook and start playing the video you want to airplay to Apple TV
  3. Voilà – Now you can play any facebook video on your Apple TV

Quelle: Trick: How to Airplay facebook videos to Apple TV natively.

Man öffnet die YouTube-Applikation, öffnet ein Video, lässt es mit AirPlay auf den Apple TV streamen, verlässt die YouTube App und öffnet Facebook. Nun streamen auch diese Videos anstandslos auf den Apple TV.

Tags: , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen