Spotlight Index bzw. Suche auf iOS 8.1.2 bzw. 8.1 defekt: Keine Suchergebnisse für Apps im iPhone oder iPad

Nur eine kurze Notiz, ggf. ist das noch für andere hilfreich: Bei meinem iPhone (ist ein iPhone 5) hatte ich nun seit einiger Zeit keine Suchergebnisse mehr für Apps erhalten. So ungefähr sah das aus:

broken

Nachdem ich dann einige Zeit erfolglos versucht habe, einen Weg zum Reset bzw. Neuerzeugen des Suchindex zu finden, habe ich doch mal bei Apple geschaut, ob das zufällig ein bekannter Bug ist, für den es eine Lösung gibt. Und siehe da: Dem ist so, die Lösung schaut so aus:

update

…und das Ergebnis ist: Danke des Updates auf iOS 8.1.3 ist das Problem behoben und die Suche funktioniert wieder komplett – sehr erfreulich:

fixed

Apple-spezifische Dateien wie .AppleDouble, .DS_Store etc. löschen (mittels find)

Wie im etwas längeren Artikel zu den Mac-spezifischen Dateien (.AppleDouble, .DS_Store etc.) und Veto Files angekündigt:

Haben sich einmal Mac-User mit dem Server verbunden, bevor deren Rechner oder der Server richtig konfiguriert worden sind, hat man den Salat: Alle Verzeichnisse sind voll mit den lustigen Finder-Metadaten.

Diese kann man finden mittels…

find \( -name ".AppleDouble" -or -name ".DS_Store" -or -name ".Trashes" -or -name "._*" -or -name ".TemporaryItems" \)

…und löschen mittels…

find \( -name ".AppleDouble" -or -name ".DS_Store" -or -name ".Trashes" -or -name "._*" -or -name ".TemporaryItems" \) -execdir rm -Rv {} \;

Veto Files, .DS_Store, .AppleDouble & Co.: Notizen zu Mac OSX Clients am Linux Server mit Samba

Die Leser, die schon länger OSX Clients mit einem Samba Server bedienen, werden die Besonderheiten kennen: Der Dateimanager des Mac OS (Finder) speichert eine ganze Menge an Metadaten zu Dateien und Ordnern in versteckten Dateien namens .DS_Store, .AppleDouble u.a.

Die Dateien beginnen alle mit einem Punkt und sind daher standardmäßig auf OSX, Windows und ebenso in der Linux-GUI versteckt bzw. unsichtbar. Spätestens wenn man aber per Terminal auf dem Server unterwegs ist, sieht man die Dateien, ebenso wenn man die Anzeige versteckter Dateien auf dem Client aktiviert hat: Das ganze Serverlaufwerk wird mit den Metadateien o.g. „versorgt“, was gerade Mac-Anwendern in heterogenen Netzen vermutlich nicht allzu viele Freunde machen dürfte 😉

Da in den Metadaten nur Dinge wie z.B. die letzte Sortierung o.ä. belanglose Dinge gespeichert werden, kann man deren Erstellung ohne mir bekannte Nachteile deaktvieren.

In meiner Agentur (die Internetagentur dimensional aus Köln) hatten wir das Thema vor vielen Jahren schonmal behandelt. Damals – zu Zeiten älterer Finder-Versionen – hatten wir über die Option veto files im Samba den Rundumschlag gemacht und alles Mac-spezifische verboten. Seinerzeit war da noch etwas mehr nötig als heute:

Aus der alten Samba Konfiguration (smb.conf):

Unerwünschte Dateien verbieten:
(Achtung, alt – richtige/aktuelle Konfiguration folgt weiter unten!)
veto files = /.?Desktop/.finderinfo/*Desktop DB*/resource.frk/.bin/Network Trash Folder/OpenFolderList*/TheVolumeSettingsFolder/.DS_Store/._*

Unerwünschte Dateien verstecken:
(Achtung, alt – richtige/aktuelle Konfiguration folgt weiter unten!)
hide files = /.*/DesktopFolderDB/Trash-For%m/resource.frk/*Desktop DB*/*Desktop DF*/*OpenFolderList*/*Network Trash Folder*/Network Trash Folder*/Icon*/.AppleDouble/TheVolumeSettingsFolder/.index-formatierung

Und noch das Löschen von Ordnern ermöglichen, die ggf. noch solche Dateien enthalten:
(Achtung, alt – richtige/aktuelle Konfiguration folgt weiter unten!)

delete veto files = yes

Jetzt aktuell hatte ich auf meinem Fileserver zu Hause einige eigentümliche Probleme, die m.E. mit der unfassbar grottenschlechten nicht so gelungenen Samba Implementation von Mac OS X und deren Zusammenspiel mit dem Samba Server liegen. Das Hauptproblem war, dass das Kopieren von Dateien auf den Server mit seltsamen Fehlermeldungen fehlschlug. Ein weiteres grundsätzlicheres Problem mit der SMBX genannten „Apple-eigenen“ Samba Implementation sind extrem geringe Transferraten beim Kopieren.

Ich habe mir daher den Server und speziell das Samba File Sharing vorgenommen und einfach mal „Inventur“ gemacht. Rausgekommen an Aufgaben ist:

Der Übersichtlichkeit halber werde ich die Infos auf die o.g. 4 Artikel verteilen.

Update: einer der o.g. Artikel ist schonmal da……weiteres Update folgt!

Audio Ausgabe (Audio Output/Audio Device) in Mac OS X umschalten

Nur eine kurze Notiz, ggf. ist diese Kleinigkeit noch für andere hilfreich…

Ich dachte (bzw. nahm es an, wirklich gedacht hatte ich nicht), dass man die Audioausgabe (d.h. Audio Output bzw. das verwendete Audio Device) bei Mac OS X nur in den Systemeinstellungen unter „Ton“ ändern könne. Das fand ich leidlich unkomfortabel, weil ich im Büro häufig zwischen den angeschlossenen Boxen und dem Headset wechsele. Zum Umschalten von den Lautsprechern auf den Kopfhörerausgang rief ich also jahrelang die Systemeinstellungen/Ton auf.

Wie eingangs bemerkt: Wenn man keine Ahnung hat, einfach mal eine Suchmaschine nutzen…

Man muss nämlich nur auf das Lautstärke-Control in der Menüleiste klicken und dabei die ALT-Taste gedrückt halten und schon bekommt man ein erweitertes Menü, über das man direkt zwischen Ein- und Ausgabegeräten umschalten kann:

audio

OpenVPN mit dem iPhone oder iPad (d.h. mit iOS)….endlich!

Sehr gute Nachrichten für alle, deren VPN auf OpenVPN basiert und die gerne auch mit ihren iOS Geräten (also Apple iPhone, Apple iPad, ggf. auch iPod Touch?) auf dieses Netzwerk zugreifen wollen.

Bisher ging das nur mittels Jailbreak – was kein Hexenwerk ist, aber dennoch für den Durchschnittsuser oder die im Unternehmen befindlichen Devices kein wirklich schöner Weg ist (nicht nur, aber auch wegen der dann nicht mehr vorhandenen Updatefähigkeit).

Hielt man sich an das, was Apple seinen Nutzern ins iOS Device eingebaut hat, hatte man nur die Wahl zwischen L2TP/IPSec, PPTP, RSA SecurID oder CryptoCard – was aus meiner Sicht nur die Wahl zwischen Pest und Cholera war.

Da bisher weit und breit keine OpenVPN App in Sicht war und auch Apple nichts dergleichen in Aussicht stellte, hatten wir bereits in den saueren Apfel gebissen: Wir haben vor einigen Monaten extra einen Mac abgestellt, um ein Apple-verträgliches VPN neben unserer OpenVPN basierten Firewall einzurichten – was nun obsolet wird:

Es gibt seit kurzem die OpenVPN Connect App (die kostenlos im App Store erhältlich ist).

Na gut, schalten wir unser zusätzliches L2TP-VPN halt wieder ab und freuen uns über gesparte Stromkosten, weniger Administrationsaufwand und natürlich die dabei gelernten Dinge 😉

Die Installation der App erfolgt über den App Store, also per Klick. Die App folgt jetzt nicht gerade den Apple Design Guidelines (= sie schaut schlimm aus), das ist aber egal, hier geht es um die Funktion: Und die scheint nach dem ersten Test ganz prima zu sein.

Die VPN Konfiguration kann einfach über iTunes zur App synchronisiert werden, was bei mir problemlos klappte, nachdem ich die bei mir openvpn.conf genannte Konfiguration zu .ovpn umbenannt habe.

Dann per Drag & Drop in Itunes ziehen (bei den Dateieinstellungen des iPhones oder iPads), fertig – die App erkennt den Sync der Konfigurationsdateien und bietet dann an, diese zu importieren.

Mehr war bei mir nicht nötig, um meine „orginale VPN Konfiguration“ vom MacBook auf mein iPhone 5 zu bringen.

Herzlichen Dank an den Autor bzw. die Autoren!

(die Google+ Meldung des Autors ist unter https://plus.google.com/u/0/102486415329787631392/posts/faSspbtGkcW erreichbar)

iPhone mit iOS 6 erhält keine Verbindung zum WLAN / DHCP Lease Time

Das ist ja kaum zu glauben. Im Netzwerk daheim steht ein WLAN Router und Access Point mit DD-WRT. Dort sind für die regelmäßig im Netzwerk verwendeten Geräte statische IPs definiert, damit nicht jedes Mal eine andere IP zugewiesen wird.

Bisher hatte ich das stumpf mit dem größtmöglichen in das Feld passenden Wert konfiguriert, bei dem o.g. DD-WRT war das „999999999 Minutes“. Mit anderen Worten also die Anweisung an die Wireless Geräte: „keine Nachfragen nötig, Deine IP und Deine Daten werden sich niemals ändern“.

Das funktionierte bisher auch mit allen Devices (iPhone 3 mit iOS 3, iPhone 4 mit iOS 5, MacBook, MacMini, Dell Notebook…) ganz problemlos….bis das iOS 6 Update kam. Ab dem Tag wollte das iPhone 4 sich partout nicht mehr mit dem WLAN verbinden. Sinnvolle Fehlermeldungen gibt es natürlich nicht, also bleibt nur probieren. Nachdem ich ziemlich alle Parameter des WLANs mal testweise angepasst hatte, habe ich als letztes mit der Lease Time experimentiert.

Und siehe da: Setzt man das auf einen niedrigeren Wert, klappt die Connection sofort.

In diesem Artikel wird die maximal als Lease Time zulässige Dauer wie folgt beschrieben:

The DHCP specification allows a lease to be up to 232–2 seconds (49,710 days, or about 135 years).

Das scheint Apple wohl nicht zu wissen….naja, auch viel geringere Werte reichen ja völlig, daher habe ich die nach dem o.g. Erlebnis auch mal reduziert auf 1 Tag, entsprechend 1440 Minuten.

SSH Agent Key forwarding auf Mac OS X Systemen

SSH Agent Key Forwarding ist toll, wenn man mit vielen Hosts hantiert. In meinem konkreten Anwendungsfall will ich mich mit meinem SSH Key auf dem Server eines Kunden authentifizieren, wenn ich Daten von einem unserer Server auf das Kundensystem synchronisere.

Der Key wird also in diesem Use Case durchgereicht (mein Rechner –> interner Server –> externer Server), sodass ich sicher auf den externen Server zugreifen kann, ohne Passwörter zu verwenden oder meinen Key auf den internen Server legen zu müssen.

Sehr praktisch – wenn es denn funktioniert. Auf meinem Mac tat es das nie, obwohl ich mittels ssh -A $servername um das Key Forwarding bat. Auch eine Unterstreichung der Bitte über den Eintrag ForwardAgent yes in der SSH-Konfiguration (/etc/ssh_config) brachte leider nicht das erwünschte Ergebnis.

Ich habe mir dann immer damit abgeholfen, dass ich mich stets über ein Linux System eingeloggt habe, wo der Key auch hinterlegt war.

Anscheinend habe ich aber bei der heutigen erneuten Recherche geeignetere Suchbegriffe gewählt und endlich den passenden Hinweis gefunden:

Man muss unter OSX erstmal dem SSH-Agent die RSA- oder DSA-Identität (den Key) manuell bekannt machen.

Dies passiert einfach mittels ssh-add.

Was dann passiert beschreibt die Manpage mit…

ssh-add adds RSA or DSA identities to the authentication agent, ssh-agent(1). When run without arguments, it adds the files ~/.ssh/id_rsa, ~/.ssh/id_dsa and ~/.ssh/identity. After loading a private key, ssh-add will try to load corresponding certificate information from the filename obtained by appending -cert.pub to the name of the private key file.

…und das war es auch schon – der Key wird forgewarded und das Login auf dem externen Server klappt.

OSX86 / HackMac: Dual Screens / 2 Monitore an Radeon HD6870 (hier von Sapphire)

Im letzten Eintrag hatte ich die Hardwareauswahl beschrieben; mittlerweile ist der HackMac zusammengebaut und installiert.

So viel Vorab: Der Rechner macht einen Heidenspaß 😉

Unter Windows 7 (was in erster Linie für Spiele installiert wurde – oder für den seltenen Fall, wo man mal eine native Windows Umgebung braucht) ist die Spieleperformance schonmal beeindruckend, die Grafikkarte scheint also eine gute Wahl gewesen zu sein.

(Grafikkarte ist ja eine SAPPHIRE Radeon HD6870 mit 1024MB RAM)

Das Multi-Monitor Setup wollte allerdings mit der Karte unter Mac OS X 10.7 nicht sofort funktionieren: Während die beiden per DVI an der Grafikkarte angeschlossenen Bildschirme unter Windows sofort funktionierten, war unter Mac OS stets nur ein Display verfügbar.

Nach etwas längerer Suche habe bei InsanelyMac den Tipp gefunden, den zweiten Screen für den HackMac mal per Mini-DVI anzuschließen – Anschlüsse hat die Grafikkarte ja genug…

…und siehe da: Sofort ist der Bildschirm mit voller Auflösung und ganz einwandfrei verfügbar:

Vielleicht kann sich durch den Hinweis ja der eine oder andere etwas Rumprobiererei ersparen…

Apple Mac OS X auf Standard PC Hardware (OSX86 / Hackintosh / HackMac) oder wie man günstig an einen Mac Pro kommt…

Schon seit ein paar Jahren kann ich ich ja privat und am Arbeitsplatzrechner auf umfangreiche Wartungsarbeiten verzichten – weil der Mac OS Rechner in der Tat wenig Ärger macht. Ich kann mich somit zumeist meiner Arbeit widmen, statt Unzulänglichkeiten des Betriebssystems auszubaden.

Als nun ein neuer Rechner für daheim anstand, war das bevorzugte OS also bereits entschieden. Man könnte annehmen, dies sei auch bereits eine Hardwareentscheidung – dem ist aber nicht so, schließlich läuft das Mac OS X auch ganz wunderbar auf normaler PC-Hardware, wenn man die richtigen (also unterstützten) Komponenten auswählt.

Klar, so einfach mit mit „echter Mac Hardware“ geht die Einrichtung natürlich nicht, aber es lohnt sich dennoch, weil…

  • so ein „Hack-Mac“ unterm Strich viel mehr Leistung fürs Geld bietet als echte Mac Hardware (die im folgenden näher beschriebene Konfiguration kostete z.B. insgesamt ca. 1.240 EUR netto, entsprechend ca. 1.470 EUR inkl. Mehrwertsteuer – was in Anbetracht der Leistung mehr als erschwinglich ist)
  • man unter dem Tisch nicht sieht, ob der Rechner in einem hübschen Apple Gehäuse steckt oder nicht
  • man kann sich etwas sehr nettes genau nach den eigenen Vorstellungen zusammenstellen, und bekommt den Rechner, den nicht wenige bei Apple vermissen: das Modell zwischen dem Apple iMac 27 Zollund dem Apple Mac Pro (siehe auch dieser Apple Mac Pro)

weiterlesen »

Whats App Messenger und der Datenschutz – eine klare „Nichtkaufempfehlung“

In den letzten Monaten wurde mir immer mal wieder die „Whatsapp Messenger“ App empfohlen. Diese soll dem Nutzer hohe SMS Gebühren ersparen und plattformübergreifendes Instant Messaging ermöglichen (soweit ich das gelesen habe inkl. Attachments wie Bildern, Videos etc.).

OK, Geld sparen klingt immer erstmal gut – da ich in Sachen App Kauf aber zur sehr sparsamen Fraktion gehöre, hatte ich die App bisher nicht auf Verdacht gekauft. Aktuell steht sie aber kostenlos im iTunes Store zur Verfügung, ich habe also mal den Download gestartet.

Öffnet man die App, so begrüßt einen gleich der folgende Screen:

OK, mein spontaner Reflex ist da natürlich der gleiche wie wenn z.B. Facebook einen Abgleich des Adressbuches vorschlägt: Nein, natürlich will ich das nicht – es wird also auf „verbieten“ geklickt.

Die App wird dann sofort eher trotzig und ermöglicht einem keine Nutzung des Dienstes:

Das gefällt mir in der Tat nicht – ich wollte die App eigentlich nur für die allmorgendliche Abstimmung mit einem Freund und Arbeitskollegen nutzen („und, wann fahren wir heute..?“). Somit möchte ich der App natürlich nicht mehr Zugriffsrechte auf meine Daten einräumen als genau diese eine Telefonnummer oder User-ID.

Ein kompletter Abgleich mit meinem Adressbuch ist weder notwendig noch zumutbar und in der EU nebenbei nichtmals gesetzlich zulässig. Letzteres scheint dem Anbieter auch klar zu sein – zumindest wird in den Bedingungen und in der ihren Namen kaum verdienenden Privacy Policy auch hierauf eingegangen. Hier wird versucht, die Verantwortung für eine Übertragung der Daten aus der EU in die USA unterzuschieben – ob dies zulässig oder möglich ist, vermag ich nicht sicher zu sagen.

Was hier passiert ist ja ohnehin etwas, wo es nicht um meine Daten, sondern diejenigen meiner Kontakte geht – also die privaten Daten Dritter. Diese haben keine Chance, der Datenfreigabe bzw. der Übertragung zu wiedersprechen, also sollte man selber mit diesen Daten besonders verantwortungsvoll (besser: paranoid!) umgehen.

An der Stelle darf ich meine Kontakte auch darum bitten.

Dann mal zur Frage was denn im normalen Betrieb hier wohl passiert – bzw. was passiert wäre, hätte ich dem Adressbuchabgleich zugestimmt:

  • durch den Abgleich mit meinem Adressbuch wären alle (ca. 800) Einträge meines iPhones an die Fa. Whatsapp übertragen worden
  • ob hierbei nur Rufnummern oder stets der komplette Datensatz inkl. Name, ggf. vorhandener Beschreibungen, Photos etc. auf deren Server geht ist unklar; in Ermangelung einer anderen Information gehe ich mal vom schlimmsten aus (kompletter Transfer)
  • die Kontaktdaten (mindestens die Rufnummern) bleiben dauerhaft (!!) auf den Systemen des Anbieters gespeichert (sonst könnte die App ja keinen sofortigen Abgleich für neue User machen)
  • ein Test der App und darauf folgendes Löschen verhindert also nicht, dass das Unternehmen zumindest die Möglichkeit hat, die Adressbuchdaten für immer gespeichert zu lassen

Warum man nicht einfach die seriöse Option verwendet (nämlich ein manuelles Eintragen der gewünschten Kontakte bzw. die manuelle Suche nach schon bei Whatsapp registrierten Usern) ist klar: Vertriebsziele bzw. eine möglichst große und aktive Userbase sind wichtigere Anliegen als der Datenschutz -nicht unüblich bei Internetstartups…

Ich denke es ist klar geworden, dass ich wohl kein Whatsapp User mehr werde.

Nachdem das recht schnell entschieden war, wollte ich mir aber zumindest noch die Frage nach Alternativen stellen. Ich selbst habe zwar einen Handytarif mit „nahezu Flatrate“ (die Anzahl der erlaubten SMS und Telefonminuten überschreite ich niemals), aber das gilt ja nicht unbedingt auch für alle meine Freunde.

Statt Whatsapp könnte man…

  • wie bisher SMS nutzen und sich um eine Flatrate kümmern
  • das sichere Jabber Protokoll verwenden, bei dem man sogar den Server selbst betreiben kann und somit nicht nur die gesamte Kommunikation, sondern auch die Speicherung der Kontaktdaten in der eigenen Hand behalten kann (das machen wir z.B. in der Firma)
  • Skype verwenden und damit zwar auch einige Daten bei einem amerikanischen Unternehmen speichern, aber dies nur sehr selektiv. Gleichzeitig kann man bei Skype ja wunderbar mit Pseudonymen arbeiten. Zentral ist aber das vorgenannte Wort „selektiv“: Man ist bei Skype nicht gezwungen, sein komplettes Adressbuch zu synchronisieren (also auf den Server des Anbieters zu kopieren!) Ich hätte mir nebenbei nicht vorstellen können, Skype mal als ein Positivbeispiel für Datenschutz anzuführen, aber es kommt wohl immer auf das Verhältnis an 😉

Wie absurd eine solche Adressbuchfreigabe ist, hat Stefan Dom in seinem Blog recht deutlich und gleichzeitig anschaulich formuliert. Man merkt ihm die Entrüstung an:

so… und nun stelle man sich vor, dass man auf der strasse angequatscht wird: “hey.. willst du umsonst mit deinen freunden telefonieren? dann gib mir mal dein notizbuch mit all adressen, die du in deinem leben gesammelt hast. ich verschwinde kurz damit um mir das zu kopieren. wenn da einer deiner freunde drin steht, dessen adressbuch ich mir auch schon kopiert habe, dann kannst du mit dem telefonieren, aber sonst mit niemandem”. bescheuert oder? niemand wuerde sowas machen.

 

Fazit:

Natürlich, Sicherheit ist unbequem und Datenschutz führt dazu, dass man auf manches Onlineangebot oder eben manche App besser verzichten sollte.

Nun gut, dann ist das eben so – gerade bei dieser App. Hier geht es schließlich nichtmals um meine persönlichen Daten, sondern um diejenigen meiner Familie, meiner Freunde und nicht zuletzt meiner Geschäftskontakte und -freunde (!).