29. Juni 2015

Fedora und ich – eine Hassliebe

29. Juni 2015 23:47

Mit Fedora bin ich noch nie so richtig zurecht gekommen.
Wenn es mal soweit war, dass es funktionierte, kam ein paar Tage oder Wochen später die Ernüchterung, und wieder war es futsch, mehr oder weniger.
Für mich ist ein System, bei dem ich beim Herunterfahren mit Crash rechnen muss, nicht gut, und wenn ich den Deckel des Notebook nicht zumachen kann, um es schlafen zu schicken, und mich darauf verlassen kann, dass es wieder korrekt aufwacht, dann bleib ich lieber bei den bewährten: Mac OS X, Ununtu und openSUSE haben damit seit vielen vielen Jahren keine Probleme.
Nun aber wieder Fedora.
Ich kann es ja nicht lassen, probiere es immer wieder aus. Immerhin ist es in USA die beliebteste Distribution.
Also, Fedora 22, sieht gut aus, aber: Deckel-zu-Deckel-auf geht nicht, und beim Herunterfahren oder Abmelden jedesmals (ja, immer!) ein Totalcrash.
So nicht.
Heute bin ich auf die Idee gekommen, im Anmeldebildschirm mal auf Wayland umzuschalten.
Und siehe da: ohne den alten, aber bewährten X11-Client geht zumindest Herunterfahren ohne Probleme, auch Abmelden/Neuanmelden.
Sogar Deckel-zu-Deckel-auf geht – ich hab es aber nur einmal probiert.
Wayland, das angeblich noch nicht so richtig serienreif ist, besser als X11?
Zumindest bei meinem Notebook (DX1302 von Tuxedo) auf jeden Fall!
Jetzt werde ich es eine Zeit lang testen. Ob es sich bewährt.
Ich bin gespannt!

22. Juni 2015

GoPro Hero 4 silver – Update Probleme lösen

22. Juni 2015 17:27

Meine bewährte GoPro Hero 3 silver liegt seit Mai auf dem Grund des Atlantik – da hab ich dem Kopfgurt wohl zuviel zugemutet in der Brandung.

Nun bekam ich – Dank an den großzügigen Spender – eine Hero 4 silver als Ersatz – geschenkt! Super.

Die kam mit der Firmware 1.00.00, aktuell ist aber 2.00.00. Da heißt es updaten.
Es gibt (soweit mir bekannt) 4 Wege zum Update:

1. über Browser (GoPro über USB an Mac anschließen, dann die Update-Seite von GoPro benutzen).
Das mag ich nicht, da muss man ein bestimmtes Java installieren, sehr mühsam und voller Sicherheitslöcher.

2. über die Mac-App “GoPro Studio”.
Das klingt sympathisch, aber leider, es hat nicht funktioniert. Zwar meldet das Programm beim Anstecken der GoPro nach einigen Sekunden, dass es die Version 2.00.00 gibt, während auf der Kamera nur Version 1.00.00 installiert sei – also alles korrekt – und es lädt die Firmware auch brav herunter vom gopro.com, aber dann meldet es “Uploading Files to Camera” oder so ähnlich, und das stundenlang.
Glücklicherweise geht die bestehende Firmware dadurch nicht kaputt, die Hero funktioniert auch wenn ich das dann abbreche, was man eigentlich nicht tun darf.
Nix kaputt, aber auch kein Update. Beim Booten erscheint die Firmware-Version kurz auf dem kleinen Display, und bleibt beharrlich auf 1.00.00.
So also auch nicht. (Man findet leicht andere Hero 4 silver User, die dasselbe Problem haben, und keine Lösung.)

3. über die iOS App GoPro
Noch sympathischer: das ist der drahtlose Weg, nix USB, nix Kabel.
Einfach die GoPro mit der App auf dem iPad koppeln, und laufen lassen.
Dann das iPad wieder mit dem Internet verbinden, dann lädt laut Anleitung das iDevice das Update aus dem Internet, und beim nächsten Koppeln des iPads mit der Hero bietet die App dann an, die Cam zu updaten. Klingt sehr genial, hat nur einen kleinen Nachteil: funktioniert nicht. Nämlich: überhaupt nicht. Die App merkt bei mir keineswegs, dass ein Update ansteht. Es tut sich schlicht – nix!
So also auch nicht.

4. manuelles Update
Das ging ja wohl schon immer, von der ältesten GoPro weg.
Das geht so: Von http://gopro.com nach Zwangsregistrierung (na ja, ist auszuhalten) die Datei update.zip herunterladen.
Die muss man dann entzippen, dazu reicht auf Mac OS X ein Doppelklick, und den entstehenden Ordner muss man auf die Speicherkarte der GoPro ins Wurzelverzeichnis kopieren.
Einfach genug und DAU-kompatibel beschrieben auf der GoPro-Update Seite.
Ich wollte das aber mit Linux machen, nur mein verlässliches openSUSE kann out-of-the-box das von GoPro bei 64GB-Karten verwendete Dateisystem EXFAT nicht lesen geschweige denn schreiben.
Da habe ich es mit meinem neuesten Linux probiert, dem gerade installierten Fedora 22. Fehlanzeige.
Dort habe ich im Firefox mal gesucht nach “Fedora exfat support” und eine RPM gefunden, die hieß ‘fuse-exfat…-…-….rpm’. Die für Fedora 64bit passende habe ich angeklickt und schon wurde sie installiert, und dann konnte ich den Ordner “update” auf die Speicherkarte kopieren. So hat Fedora gleich mal was gutes gemacht, und als ich die Speicherkarte in die GoPro gesteckt habe und diese eingeschaltet habe, hat sie mit viel Gepiepse und viel Geblinke brav auf Firmware 2.00.00 aufgerüstet.
Jetzt ist die Hero 4 silver auf dem neuesten Stand.

Fedora – nicht meins

22. Juni 2015 17:03

Seit ewigen Zeiten probiere ich es immer mal wieder mit Fedora. Aber so ganz haut das nie hin bei mir.
Zuletzt Fedora 21, nach der Installation ging vieles nicht so, wie es sollte, nach etlichen Updates lief es ganz fein.
Bis es dann plötzlich wieder aus war mit der Herrlichkeit, nach einem weiteren Routine-Update war kein WLAN mehr erreichbar.
Heute habe ich Fedora 22 Workstation per USB-Stick auf mein Notebook gespielt – mitten in der Einrichtung der Festplattenpartitionierung blieb der Installer Barracuda hängen. Nett.
Beim zweiten Versuch, diesmal ohne Volume-Verschlüsselung einzustellen, lief es durch, und startete auch.
Aber es läuft noch lange nicht rund: Deckel-zu-Deckel-auf resultiert in Absturz, ebenso Bildschirm sperren-entsperren. Und ausschalten lässt es sich auch gar nicht, weder über Menü noch mit dem altbewährten Befehl ’shutdown -h now’ als root. Ach ja.
Immerhin kann ich diesen Blogeintrag in Fedora schreiben… und ich konnte meine GoPro manuell updaten. Dazu im nächsten Beitrag mehr.

4. März 2015

ownCloud 8 – Raspberry Pi 2 Model B

4. März 2015 1:23

Mein Raspberry Pi 2 kam und war dann doch nicht so kompatibel: Mein altes Gehäuse passt nicht mehr, da die Stromzuführbuchse (Micro-USB) an einer anderen Stelle, sogar einer anderen Seite der Platine sitzt.
Außerdem konnte ich meine 32 GB SD-Card nicht weiternutzen: der Pi 2 braucht eine Micro-SD-Card. Ach ja.
Also noch schnell eine solche Daumennagelkarte geholt, und los gings.
Mit dem berüchtigten dd-Befehl in Linux war das System schnell aufgespielt. Dann rein in den kleinen Pi und den an Strom und Ethernet angeschlossen – fertig.
Nun die Software.
Vor allem soll ja ownCloud gut drauf laufen, dafür wollte ich das schnellere Teil ja haben.
MySQL, Apache2, ownCloud 8, das kann man alles ganz normal installieren.per apt-get, nur für ownCloud muss man vorher das eigene Repository einrichten, was aber über das Script auf owncloud.org ganz leicht geht.
Vorteil: alle Software ist dann als dpkg-Paket installiert und wird vollautomatisch aktualisiert, mit dem passenden cron-Script natürlich.
Nur wenn ein neues Major-Release von ownCloud kommt, muss man es von Hand aufrufen (mit apt-get dist-upgrade).
Der neue Raspi soll “bis zu 6 mal schneller” sein, heißt es in den Medien.
Meine Erstsynchronisation von zB MacBook hat mit dem Raspi 1 so etwa 12 Stunden gedauert, mit dem Raspi 2 hat es eine Stunde gedauert.
Nicht schlecht, und vor allem fühlt sich die Oberfläche der GUI-Apps auf den Clients jetzt erträglich an, vorher ultra-zäh.
Das Upgrade hat sich also gelohnt.

4. Februar 2015

Kommerzielle Software :-(

4. Februar 2015 16:26

Hab heute für meinen Schwager ein Upgrade für eine bestehende (Avid-) Sibelius-Installation gemacht.
Dafür musste ich einen Account anlegen bei Avid,
die Seriennummer der laufenden Version (finden und) eingeben,
die Seriennummer der ursprünglichen Version (finden und) eingeben,
die SystemID von der Webseite abschreiben,
den Schlüssel von der Webseite abschreiben,
das Programm in Version 7.5 installieren von DVD,
auf “aktivieren” klicken,
SystemID eintippen,
Schlüssel eintippen,
warten bis das in dem eigens gestarteten Aktivierungsprogramm dann durch war (etwa 5 Minuten),
dann noch ein paar Mal okay und nicht registrieren und
dann war es überstanden.
(Dafür muss man fast noch dankbar sein, denn bei Version 5 damals haben wir aktiven Support gebraucht, um das hinzukriegen. Was für ein Sumpf.)
Nachher erst meldete Sibelius, es gäbe ein Update auf 7.5.1 – das haben wir erst mal auf nächste Woche vertagt…

Meine Güte!
Da weiß man wieder mal, wofür Open Source gut ist ;-)
Und mit dieser unmöglichen Prozedur werden die braven, zahlenden Kunden gequält – wer eine Raubkopie verwendet, spart sich den ganzen Mist. Das sollte so eine Softwarefirma mal bedenken, aber es wurde schon so oft bemängelt, und es hat sich nix gebessert.
Keine Hoffnung – außer: Umstieg auf freie Software.

2. Februar 2015

Raspberry Pi 2

2. Februar 2015 16:08

Gestern erschienen: Der Nachfolger des feinen, kleinen Raspberry Pi.
Er heißt Raspberry Pi 2, genauer Raspberry Pi 2 Model B, und ist voll kompatibel zum Raspberry Pi Model B +.

Da meine ownCloud zwar sehr praktisch ist hier für die Synchronisation und zentrale Speicherung von Dateien, aber schneckenlangsam, ist das ja sehr verlockend. Rund 6-fache Rechenleistung, da doppelt soviel RAM und 4 Kerne statt nur einem, und sonst alles gleich: Das müsste die vielen Apache-Prozesse, die ownCloud ständig parallel startet, doch gewaltig beschleunigen.
Das die Graphik-Einheit unverändert bleibt, stört mich gar nicht, da ich die ja nicht benutze.

9. Oktober 2014

openSUSE 13.2 ?

9. Oktober 2014 12:18

Gestern kam ein Riesenupdate für openSUSE 13.2Beta1.
Normalerweise kommen so 10-20 Pakete bei den Updates, manchmal auch 30 oder 40.
Diesmal über 1.700!
Dementsprechend lange hat das gedauert, und ich war natürlich nicht in der Lage, diese lange Liste zu kontrollieren, ob ich das wirklich alles haben will.
Dazu musste ich “Lizenzbedingungen” abnicken, aber nicht für Flash, sondern für openSUSE. Das kam mir schon merkwürdig vor, und rein zufällig entdeckte ich ein Paket “openSUSE Produkt” und eines für Yast-Branding openSUSE…
In mir keimte ein Verdacht auf: Sollte das ganze womöglich der fließende Übergang von Beta auf die Vollversion 13.2 sein?
Schnell auf opensuse.org nachgeschaut, aber da stand immer noch “nur noch 27 Tage” bis zum Release. Und keine Bemerkung über evtl. Golden Master Vorabveröffentlichung oder so was.
Als die Installation nach Stunden endlich fertig war, sah ich im KDE Informationszentrum nach:
Betriebssystem openSUSE 13.2. mit noch etlichen Ziffern (Buildnummer?) hinten dran. Kein Wort mehr von Beta.

Was genau machen die in den nächsten vier Wochen noch daran?

Die Problemchen, die ich mit der Beta hatte, nämlich Instabilität und Fensterhelligkeitsverstellung mit Funktionstasten, sind anscheinden behoben, obwohl ich zur Stabilität natürlich erst nach ein paar Wochen ein aussagekräftiges Statement machen kann.
Macht wirklich Freude, diese Version, auf meinem Tuxedo Notebook.

[Update] Gerade habe ich diesen Artikel gefunden, demnach handelt es sich um die Version 13.2RC1, was allerdings nirgends in dem System so steht, zumindest habe ich es nicht gefunden… [/Update]

3. Oktober 2014

13.2 Beta mixed impressions

3. Oktober 2014 12:18

Gestern hab ich noch die richtige Einstellung für “natürliches” Scrollen entdeckt in KDE, die haben das unter “Maus” und Mausrad versteckt. So ein Unsinn, das braucht man ja hauptsächlich für das Touchpad.
Weniger schön: die 13.2 Beta ist bei mir nicht stabil.
Nahezu reproduzierbar stürzt das System (der ganze Computer) hoffnungslos ab, wenige Minuten nach dem Einloggen in die graphische Oberfläche (bei mir KDE).
Gestern hat ein erneutes Hochfahren geholfen, heute nicht mehr, ich muss dann im “Wiederherstellungsmode” starten. Dann aber geht es zuverlässig.
Ich weiß gar nicht, was in diesem Mode anders ist, sichtbare Unterschiede kann ich nicht ausmachen. Aber blöd ist es schon, ich muss beim Hochfahren also immer dran denken, nicht den Default-Eintrag im Grub2 durchzulassen, sondern auf den Wiederherstellungsmode umzuschalten. Lästig.
Wer kann mir sagen, was das Besondere dieses Modus ist?
ownCloud funktioniert inzwischen klaglos, ob das an dem Client-Update liegt, das gestern abend noch hereinkam?

openSUSE 13.2 Beta Screenshot

openSUSE 13.2 Beta Screenshot

2. Oktober 2014

openSUSE 13.2 Beta

2. Oktober 2014 13:19

Das mach ich sonst nie, hab mir die Beta von openSUSE 13.2 geholt und installiert.
Das lief nicht ganz rund, zweimal fiel ich aus der schönen Oberfläche in eine altmodische, um ein Problem zu beheben, konnte danach aber jedesmal wieder ohne Reboot in der begonnen Installation weitermachen, und letzlich hatte ich doch das neues System auf der Platte.
Sieht gut aus, aber im Detail habe ich noch Probleme, zB lässt sich der ownCloud-Client nicht konfigurieren, und ähnliche Kleinigkeiten. Und ich kann die Einstellung für die Umkehrung der Scrollrichtung (”natürliches Scrollen”) nicht finden, halbwegs wichtig am Norebook mit Touchpad.
Insgesamt aber ein gutes Stück weiter, das ganz Projekt, Glückwunsch!

ShellShock manuell fixen

2. Oktober 2014 13:14

Na, das ging ja dann doch schneller als gedacht, bis Apple ein Update für die ersten Bash-Lücken zur Verfügung gestellt hat. Allerdings muss man das händisch installieren.

Anleitungen findet man in diesem heise.de-Artikel.

26. September 2014

ShellShock woes

26. September 2014 23:40

Nach dem Heartbleed-Desaster nun das Bash-Desaster, genannt ShellShock.

Ist ja einerseits gut, dass der uralte Programmcode nun endlich mal durchgeschaut wird, andererseits schon sehr lästig, dass die Updates so zitzelweise daherkommen.
Aber da die Lücke schon systematisch ausgenutzt wird, ist das wohl notwendig, jedes Unterproblemchen so schnell wie möglich zu fixen.
Mir wäre sonst aber auch nicht langweilig…

Schlimmer: Apple hat noch gar nix anzubieten. Was machen die so lange?

25. September 2014

Distributionen und Tempo der Sicherheits-Updates

25. September 2014 12:14

Da hat die bash, die meistgenutzte Shell in allen Unix-ähnlichen Systemen, einen schweren Sicherheitsfehler. Die Meldungen überschlagen sich.
Auf heise.de erschien die Meldung gestern (Mittwoch) spätnachmittags.
Die drei von mir benutzten Distributionen waren alle anfällig, wie folgender Einzeiler (der angeblich von RedHat stammt) zeigt:
> env x=’() { :;}; echo vulnerable’ bash -c “echo this is a test”
wenn dieser Befehl (u.a.) “vulnerable” ausgibt, ist die benutzte bash betroffen.

Schon wenige Stunden später hat mein Ubuntu das Update eingespielt.
Bei Raspbian, der von Debian abgeleiteten Distribution auf meinem Raspberry Pi, dauerte es bis in die Nachtstunden, bis das Update irgendwann nach Mitternacht erschien. Bevor ich ins Bett ging, war es noch nicht da, am Morgen war es schon gefixt, von meinem nächtlich um 2 Uhr per cron durchgeführten täglichen automatischen Update.
Erst heute Morgen bekam ich es für openSUSE. Immer noch innerhalb weniger als 12 Stunden nach der heise.de-Meldung, wie zeitnah wiederum diese an der Originalveröffentlichung war kann ich natürlich nicht sagen.

Insgesamt also sehr schnell, völlig anders, als was diese Untersuchungen über die Updategeschwindigkeit von diversen Linux-Distris gegen Windows vor ein paar Jahren suggeriert hatten (mit Responsezeiten von Wochen bis Monaten). Hab ich mir immer gedacht, dass die Studien damals völliger Quatsch waren.

23. September 2014

iOS 8 Update – Wunder der Technik

23. September 2014 11:02

Die letzten Tage habe ich unsere 4 iDevices auf iOS 8 aktualisiert.
Klingt einfach?
Jedes der 4 Systeme (2 iPad mini, 1 iPhone 5, 1 iPhone 5s) hat sich anders verhalten.
Das liegt auch an mir, da ich das erste in der Reihe unbedingt über WLAN, also Internet direkt und ohne iTunes, updaten wollte. Das war sehr mühsam, weil ich dazu 5,6 GB Platz machen musste auf dem knappen 16 GB Speicher meines iPhone 5s. Als es dann endlich durch war (der Download dauerte ewig, die Installation war blitzschnell) musste ich noch die Ortungsdienste reaktivieren und dann war es wirklich fertig.
Mein iPad hab ich über iTunes auf ver 8 gebracht, das mag ich nicht, USB-Kabel ist so was von gestern, aber eigentlich hat das noch viel einfacher funktioniert… muss ich zugeben.
Dann das iPhone 5: da habe ich an irgendeiner Stelle im Prozess, ich glaube beim reboot ins neue System, einen Code eingeben sollen. Einen 4-stelligen Sicherheitscode. Den hatte ich aber nicht. Ersatzweise hab ich einen üblichen Code getippt, darauf hin kam sofort wieder die Aufforderung, einen Sicherheitscode einzutippen, diesmal einen 6-stelligen. So was war früher auch mal vorgekommen, damals hatte ich den Code aufgeschrieben. Ich wollte ihn grad suchen, da piepst es, es kommt eine SMS von Apple, mit dem 6-stelligen Sicherheitscode. Den wollte ich nun kopieren und einsetzen, aber oh Wunder, das passierte von selbst, vor meinen Augen wechselte die App zurück zur Sicherheitscodeeingabe, und die schloss sich, alles fertig. Seltsam.
Und beim zweiten iPad? Auch da erschien die Aufforderung, den Sicherheitscode einzugeben, ich wollte ihn schon suchen, da piepste das Handy, und der – neue – Sicherheitscode kam an. Aha, also ist das ein Einmalcode, wird immer neu zugeschickt, okay. War mir nicht so richtig klar bisher.
Und da fiel mir ein, was ich mal über die 2-Faktor-Authorisierung gelesen hatte. Also hat meine Frau die, ich aber nicht.
Später ging ich in die iCloud-Accountverwaltung (kann man zB über iTunes/Store/Mein Konto bequem reinkommen) und wollte dort die 2-Faktor-Auth. für meinen Account aktivieren. Das ließ Apple aber gar nicht zu, zuerst musste ich ein neues, sichereres Passwort definieren. Ja, stimmt, mein altes war nicht gar so toll.
Nun werde ich in Zukunft bei Änderungen an meinem iCloud-Zeugs wohl auch einen 6-stelligen Sicherheitscode zugesmst bekommen… (zum Glück hab ich mein Handy fast immer bei mir. Sonst wäre das blöd.)
Letztens Endes verdanke ich diese neue Sicherheit vermutlich der amerikanischen Promi-Nacktbilderaffäre.
So hat doch alles was Gutes…

18. September 2014

Apple Updates

18. September 2014 14:08

Viel Updates die letzten Tage von Apple:
iTunes
iOS 8
Mavericks 10.9.5
Safari 7.1
Viel Neues, viel Arbeit – wirklich automatisch geht nix davon, auch wenn man das so einsgestellt hat.

14. September 2014

Apper und Zypper…

14. September 2014 23:34

Eine Merkwürdigkeit in openSUSE 13.1 ist, dass alle paar Wochen der Softwareupdate über die KDE-GUI nicht mehr funktioniert. Es zeigt zwar an, wieviel …zig Updates anstehen, aber dann meldet es entweder, die Verbindung zu einem Repository sei derzeit nicht möglich, oder es meldet, die Authorisierung für Adobe Flash sei fehlgeschlagen, obwohl ich in der entsprechenden Dialogbox “Ja” angeklickt hatte…
Dann kann ich entweder rebooten (pfui) oder ich gehe in ein Terminal mit Rootrechten, und tippe dort ein:
zypper ref
zypper up

und das Problem ist erledigt, zypper installiert alles notwendige vollautomatisch, wie es sich gehört.
Kann mir jemand sagen, warum Apper (so heißt wohl das Tool der KDE-GUI, das eigentlich zuständig wäre?) in diesen Fällen nicht weiterkommt und warum ich da auf die Kommandozeile zurückgreifen muss?

1. September 2014

Raspberry Pi selfcare

1. September 2014 12:15

Kürzlich kam das Update von ownCloud server auf Version 7.
Das hab ich eingespielt mit apt-get, ging alles problemlos. Wie es sich für ein Debian-basiertes System gehört.

Später habe ich den kleinen Raspi Server per cron so eingestellt, dass er nun jede Nacht sich selbst updatet, mit den üblichen 2 Befehlen:
apt-get update; atp-get upgrade
Allerdings krieg ich keine Nachricht, ob das gut ausgegangen ist, ein kleiner Nachteil, den ich noch beheben sollte.
[Update: die Nachricht krieg ich doch, als Mail, ich muss nur die Systemmails auf dem Raspi lesen... okay okay, sehr fein.]
Das alles war letzte oder vorletzte Woche… seither läuft das.

Heute fiel mir auf, dass sich die ownCloud am Linux Computer nicht gemeldet hat. Per Browser nachgeschaut:
da kommt ownCloud sofort mit der Meldung, die Server-Installation würde jetzt auf 7.0.2 upgedatet. Nur musste ich das noch per Klick absegnen. Danach war die ownCloud wieder da, neu und zuverlässig wie immer.
Somit ist bewiesen, dass der etwas komplizierte Vorgang des Updatens von ownCloud/Apache etc auch automatisch gut funktionieren kann.

Sehr fein.
Für den Server ist und bleibt Debian (und seine engen Verwandten wie Raspbian) allererste Wahl!

23. Juli 2014

Schock am Abend – EFI Mac Update Problem

23. Juli 2014 0:04

Heute Abend kam ein EFI-Firmware-Update für unsere beiden MacBook Air (”Mitte 2011″).
Das App Store Programm warnte mich brav, dass ein Neustart nötig sein, was mir aber recht war, weil ich wegen des ownCloud-Debuggens eh einen Neustart brauchen konnte. Also Updaten! angeklickt, der Mac fuhr herunter und installierte das Firmware Update… und dann wurde der Bildschirm schwarz.
Ganz schwarz. Kein Lüftergeräusch, kein garnix. Aus, tot.
1 Minute, 2, 3, … 5 Minuten, 8 Minuten… kann das normal sein? nein!
Ich drückte die Einschalttaste kurz, nix, dann etwas länger, nix, dann die Notaus-Tastenfunktion (Einschalttaste laaaaaaaang drücken, dh mehr als 10 Sekunden) – nix.
Tot!
Was soll man sonst mit einem Air machen? Akku raus – geht nicht. Resettaster – gibt’s nicht. Au weh.
Ein ziemlich teurer Block Alu lag da vor mir, und keine Ahnung was damit anzufangen sein könnte.

Ich warnte meine Frau: Spiel dieses Update nicht ein! Sie holte ihr MacBook Air, öffnete es – nix. Probierte eine Taste – nix. Dann die Einschalttaste – nix.
Mist hoch drei! Hatte dieser Mac das EFI-Update wohl ganz allein gemacht.
Doch plötzlich kam der Einschaltton, und dann fuhr der Mac ganz normal hoch, alle Fenster wurden geöffnet und der Alptraum war vorbei. Für sie, meine Schöne.
Und ich?
Nochmal die Einschalttaste gaaaaaaaanz lang gedrückt. Zwei Sekunden gewartet, und nochmal kurz gedrückt. Bing!
Und auch mein MacBook Air bootete wieder richtig, wie es sich gehört. Puh!!!
So ein Schock am Abend, das muss ja nicht sein…

[Update 23.7.2014] Inzwischen gibt es einen Bericht zu diesen EFI-Update-Problemen, auf heise.de.

22. Juli 2014

ownCloud (4)

22. Juli 2014 23:52

ownCloud ging nach langem Herumprobieren immer noch nicht. Nur bei den Mac Clients, allerdings.
Dagegen in iOS und Linux funktionieren die Clients, und es funktioniert auf dem Mac das Web-Interface und der rohe WebDAV-Zugriff. Was also kann das Problem sein?

Ich bin nochmal die ganzen Einstellungen in Apache auf dem Raspberry Pi Server durchgegangen, und habe mal aus Verzweiflung die Sicherheitseinstellungen für SSL gelockert in der Datei /etc/apache2/mods-available/ssl.conf:

# Allow insecure renegotiation with clients which do not yet support the
# secure renegotiation protocol. Default: Off
SSLInsecureRenegotiation on # uncommented by rm 2014-07-22

# Whether to forbid non-SNI clients to access name based virtual hosts.
# Default: Off
SSLStrictSNIVHostCheck On # uncommented by rm 2014-07-22

nachher Apache2 restart mit: ’sudo service apache2 restart’
und dann gingen die Mac Clients beide wieder!
(Wobei ich nicht weiß, ob beide Änderungen notwendig waren oder nur eine – oder ob irgendwas anderes mystisches die Ursache war und meine beiden Änderungen vollkommen umsonst waren!)

ownCloud auf Raspberry Pi (3)

22. Juli 2014 16:26

oh je, das wird eine never-ending story…

Gestern habe ich mein Java-Source-Directory in das ownCloud Verzeichnis gelegt, das hat ein paar Tausend kleine Dateien. Die Synchronisation (vom Linux-Client auf den Server) lief schleppend langsam, aber war über Nacht fertig. Auf den Macs allerdings blieb das Hinunterladen bei der 1099. Datei in einem bestimmten Ordner hängen, bzw. lud als Endlosschleife stundenlang immer wieder die letzten 10 oder 12 Dateien herunter, immer dieselben, obwohl in dem Ordner über 1300 Dateien liegen.
Ich habe den Mac Client mehrfach neu gestartet, die Einstellungen durchgeschaut, alles umsonst, sogar die Daten der App in der Library gelöscht. Alles umsonst. Auch den Server habe ich mal neu gestartet, obwohl der ja kaum das Problem sein kann, denn der Linux-Client und die iOS-Apps haben gar kein Problem. Nur die Macs.
Und dort konnte ich dann gar nicht mehr verbinden. Der Assistent der Mac-App sagte immer, er könne keine sichere SSL-Verbindung herstellen, ob ich eine unsichere wolle? Will ich aber nicht, hab es aber probiert und es geht genau so wenig. Außerdem kommt diese Meldung sowieso immer, auch wenn nur ein gewöhnliches Netzwerkproblem vorliegt und er den Server gar nicht erreichen kann. Das sagt also gar nix.
Außerdem, im Safari auf denselben Macs, geht die https-Verbindung zum Server einwandfrei, auch zu ownCloud. Und ich kann mir im Safari das SSL-Zertifikat anzeigen lassen. Das ist okay.
Woran kann es also sonst liegen?
Jetzt habe ich den RC1 von der kommenden Version 1.6.2 des Mac Clients geladen und ausprobiert: selbes Problem. Mist!

17. Juli 2014

ownCloud auf Raspberry Pi (2)

17. Juli 2014 22:37

Nun habe ich seit ein paar Monaten ownCloud auf unserem Hausserverchen Raspberry Pi laufen.
Leider haben die Client-Apps auf den Macs nicht funktioniert, während die Client-Apps auf den iOS-Devices (vornehmlich iPads) und die Linux-Clients einwandfrei funktioniert haben.
Heute habe ich nochmal die ganzen Details der Installation und Konfiguration durchgeschaut, letzten Endes aber habe ich keinen wirklichen Fehler gefunden. Die Paketverwaltung apt-get meinte ich solle mit autoremove mal überflüssige Pakete aufräumen, das habe ich gemacht. Und ich las einen Tipp, man sollt in der Directory-Anweisungsliste im Virtualserver-Block in den Apache2-Einstellungen das Kommando “Dav Off” einbauen. Das führte beim anschließenden Server-Restart aber zu einem Fehler, so habe ich das gleich wieder rückgängig gemacht. Anscheinend ist das Apache-Modul, das diese Anweisung versteht (WebDAV), eh nicht geladen…
Aber zum Schluss stellte ich fest: es geht jetzt komplett, auch auf den Macs, die nun brav automatisch synchronisieren, ganz wie bei DropBox, nur eben lokal und sicher vor den Geheimdiensten… vielleicht sicher… ganz genau weiß das ja wohl niemand, was die noch alles inzwischen geknackt und unter Kontrolle haben.
Trotzdem ist ein per SSL abgesicherter eigener Server im eigenen Netz wohl so ziemlich das sicherste, was derzeit überhaupt geht…
Und das funktioniert jetzt, sehr gut.
Auch wenn ich nicht genau weiß warum, es ist jedenfalls fein, dass es nun ganz richtig funktioniert: ownCloud auf Raspberry Pi (mit Apache2 und MySQL – inzwischen habe ich gelesen, dass es andere Möglichkeiten gibt, die weniger rechenintensiv sind, was beim Raspi ja nicht schlecht wäre – aber vorläufig fasse ich das nicht an, erst genieße ich mal den derzeitigen Stand.

13. Juni 2014

hp Drucker Probleme

13. Juni 2014 10:51

Früher galten hp Drucker als “overengineered”, als allzu solide aber auch allzu teuer gebaut…
Die Zeiten ändern sich.
Heutige hp Tintenstrahler haben meist auch nur noch Tintentanks, ohne eingebauten Druckkopf.
Das gilt als umweltschonender, aber letzten Endes ist es für den Anwender eine einzige Verschwendung:
Viel öfter muss man wegen leerer Patronen unbrauchbare Ausdrucke wiederholen, die Druckköpfe reinigen lassen, daher mehr Papier und viel mehr Tinte kaufen/verbrauchen, und wenn es schlimmer wird, öfter einen neuen Drucker kaufen. Wobei die Druckerhersteller ja bekanntlich vor allem vom Tintenverkauf leben…

Mein hp OfficeJet 6500 e701 gehört auch zu der Kategorie “Tintentanks ohne Druckkopf”. Bei uns wird der Drucker nicht täglich, aber zumindest wöchentlich benutzt, ab und zu auch ziemlich ausgiebig, zB wenn monatlich 66 Seiten Protokolle ausgedruckt werden sollen oder wenn ich ein Manuskript ausdrucken muss – letzteres können auch mehrere Hundert Seiten auf einmal sein.
Gestern ist der übliche Ausdruck von 66 Seiten mittendrin von einem Blatt auf das übernächste verblasst, als wenn die schwarze Patrone leer geworden wäre. Der Drucker zeigte diese aber noch als halbvoll an. Dafür blinkte das Warndreieck für die gelbe Patrone, die sei komplett leer. Das wäre aber doch kein Grund, den schwarzen Text zu verweigern?
Druckkopfreinigungsprogramm brachte nichts – mir nicht, hp schon, denn das verbraucht viel der teuren Tinte.
Gelbe Patrone gewechselt, auch gleich die anderen beiden ziemlich leeren Farben, brachte auch nix.
Schwarze Patrone trotz halbvoll-Anzeige getauscht: brachte auch nix.
Nochmal Druckkopfreinigungsprogramm, diesmal dann auch Stufe 2 – brachte auch nix!
Verzweiflung!
Da entdeckte ich einen Hebel und Rahmen außen um die Patronen herum, mit dem konnte ich den ganzen Druckkopfrahmen herausnehmen.
Da war ein dicker, klebriger Batzen vertrocknete schwarze Tinte unten dran. Kein Wunder, dass das Reinigungsprogramm damit nicht fertig geworden war.
Und nun, wie weiter reinigen? Irgendwann hatte ich mal was von der Verwendung von reinem Alkohol gehört im Zusammenhang mit Druckköpfen…
Hab ich aber nicht da.
Aber.
Ich hab doch Vodka in der Hausbar. Und das ist nix anderes als reines Wasser mit reinem Alkohol.
Also hab ich mit einem Strohhalm einen Tropfen auf das Sieb über dem Druckkopf gegeben, einziehen lassen, es färbte sich sofort schwärzlich.
Dann mit dem Finger draufgedrückt, und tatsächlich, kam unten bei der langen Düsenreihe eine schwarze Brühe herausgequollen.
Dann oben und unten saubergewischt, und alles von vorne.
Das habe ich so etwa zehnmal wiederholt, bis kaum noch etwas herauskam.
Nach dem Wiedereinbau meldete der Drucker: Kein Druckkopf eingesetzt oder Druckkopf beschädigt!
Oh je. Da habe ich einfach nochmal fest gerüttelt an dem Rahmen und dem Hebel, und da war der Drucker zufrieden.
Es begann eine Putzorgie wie nach einer Erstinbetriebnahme, etwa 10 Minuten lang, dann sagte der Drucker, er würde jetzt die Düsen ausrichten, und das dauere weitere 7 Minuten. Eilig darf man es da nicht haben.
Aber: es geht wieder. Alle Farben und vor allem Schwarz drucken wieder einwandfrei.
Also doch gut engineered, hp, und ein Lob auf den Vodka.
Allerdings hat mich das ganze viel Zeit und etwa 50€ Druckertinte gekostet…

28. Mai 2014

ownCloud auf Raspberry Pi

28. Mai 2014 17:56

seit ein paar Wochen habe ich nun ownCloud auf dem Raspberry Pi im Heimnetz laufen.
Laufen?
Eher kriechen. Es geht zwar, aber eher ziemlich lästig langsam.
Das muss nun nicht an der Rechenleistung des ARM-basierten Raspi liegen, denn bei der Installation hatte ich ziemliche Probleme, und obwohl jetzt eigentlich alles funktioniert, meldet der ownCloud Server ein Problem, wenn ich mich da einlogge. Möglicherweise ist das der Grund für das zähe Reagieren der PHP5-Software auf dem kleinen braven Rechner da oben im 2. Stock…
Das beste an ownCloud ist aber, dass es nicht nur mit Macs und Linux-Clients funktioniert, sondern auch mit unseren zahlreichen iOS Devices. Und alles bleibt im Haus.
Update:
Leider funktioniert doch nicht alles, die Mac-Clients nämlich weigern sich, mitzuspielen. Ach ja, doch nicht so einfach.

14. Mai 2014

Zugriffsrechte in Mac OS X

14. Mai 2014 12:13

Manchmal gibt es irgendwelche seltsamen Probleme in Mac OS X, die sich mit dem Befehl “Zugriffsrechte reparieren” des Festplattendienstprogramms beheben lassen. Viele schwören auch drauf, diesen Befehl immer vor größeren Systemupdates laufen zu lassen, oder vor Festplattentausch etc.
Dabei frage ich mich immer, ob der Installer von Apple bei dem Upgrade des Betriebssystems nicht selbst schlau genug ist, diese Routine laufen zu lassen? Das wäre doch sehr naheliegend. Aber gut.

Eben habe ich einen interessanten Artikel gelesen, der auch mit Zugriffsrechten zu tun hat: Ganz unten im letzten Teil dieses Artikels geht es um das Richtigstellen der Zugriffsrechte in den normalen Dateien und Ordnern der Anwender. Also das ganze Home-Verzeichnis, das mit dem Häuschen als Icon, wird auf die korrekten Werte rückgesetzt.
Wann braucht man das?
Zum Beispiel, wenn man auf eine nicht ganz richtige Art Daten zurückgesichert hat, oder wenn man beim Migrieren von einem älteren Mac auf einen neueren Mac irgendwas suboptimal gemacht hat… und dann an seine eigenen Dateien nicht dran kann, zumindest nicht schreibend/verändernd.
Und wie geht das?
Das steht in dem Artikel, im Prinzip verwendet man den Recovery-Modus des jeweiligen Mac-Modells bzw. der installierten OS X Version, und wählt dort den Befehl “Passwörter zurücksetzen”. Ja wirklich, obwohl man das ja gar nicht will. Aber dieser Befehl enthält außer der Möglichkeit, das Hauptpasswort zurückzusetzen auch die Möglichkeit, die Benutzerzugriffsrechte zu reparieren, was hier auszuwählen ist.
(Schade, dass das Festplattendienstprogramm das nicht kann, das wäre weniger gefährlich für Leute, die sich wenig auskennen – mit dem Recovery-Modus sollte man nicht herumspielen, da kann man praktisch alles ruinieren!)

1. Mai 2014

eigenen Ersatz für Cloud einrichten?

1. Mai 2014 23:25

Nach den hässlichen Meldungen der letzten Zeit über den so bequemen Cloud-Service Dropbox frage ich mich langsam, ob ich nicht für uns eine ownCloud oder so was ähnliches einrichten sollte. Nicht für große Sachen, nur für den Kleinkram, den man auf jedem Gerät haben will, unkompliziert und sicher.
Dazu bräuchte man (nur) einen durchgehend laufenden Server im LAN.
Aber den hab ich ja: dafür könnte ich doch den Raspberry Pi hernehmen, der läuft sowieso immer. Und hat meistens nichts zu tun. Außer wenn die Eisenbahn im Garten zu steuern ist. Und selbst wenn, das lastet den kleinen Rechner nicht aus.
Und ownCloud auf einem Debian-basierten System installieren, das kann ja wohl nicht schwer sein.
Für ownCloud gibt es Client-Apps für Mac OS X, Linux, iOS, alles was wir so in Gebrauch haben. Klingt doch perfekt.
Mal sehen.
Und wenn die SD-Card mal kaputt geht, ist das auch kein großes Problem, die auszutauschen.
Ein zentraler Speicher ohne irgendwelche mithörenden Fremd”dienste”, klingt wirklich verlockend.

das kleine Loch im großen Plan…

1. Mai 2014 23:17

Tja, da hab ich mich doch zu früh gefreut und etwas wichtiges übersehen bei meinen Tests von Tanglu:
Leider wacht Tanglu aus dem Schlafzustand (Notebook-Deckel zugeklappt) nicht mehr auf.
Zumindest habe ich das noch nicht hingekriegt.
Verdächtig auch, dass Ruhezustand/Schlafzustand oder so ähnlich in den Systemeinstellungen nicht mal vorkommt…
Sehr schade! Das schränkt die Brauchbarkeit auf dem Notebook doch sehr ein.

Immerhin kann ich ja auf ein Update hoffen…