Entries from Software

Seafile: Upgrade von 6.1.2 auf 6.2.2 fehlgeschlagen

Das Upgrade des Seafile Servers von 6.1.x auf 6.2.2 auf meinem Raspberry Pi schlug erwartungsgemäß fehl. Wie in den Anmerkungen zum Paket angegeben, nahm ich die Anpassungen in Nginx (sudo nano /etc/nginx/sites-available/seahub) vor, scheiterte dann aber beim Upgrade Befehl: upgrade_6.1_6.2.sh . Ich erhielt dabei immer nur folgende Fehlermeldung:

QUOTE:

Updating seafile/seahub database ...

[INFO] You are using SQLite3
[INFO] updating seahub database...
Traceback (most recent call last):
File "/home/.../seafile/seafile-server-6.2.1/upgrade/db_update_helper.py", line 363, in
main()
File "/home.../seafile/seafile-server-6.2.1/upgrade/db_update_helper.py", line 358, in main
db_updater.update_db()
File "/home/.../seafile/seafile-server-6.2.1/upgrade/db_update_helper.py", line 259, in update_db
super(SQLiteDBUpdater, self).update_db()
File "/home/.../seafile/seafile-server-6.2.1/upgrade/db_update_helper.py", line 120, in update_db
self.update_seahub_sql(seahub_sql)
File "/home/.../seafile/seafile-server-6.2.1/upgrade/db_update_helper.py", line 283, in update_seahub_sql
self.apply_sqls(self.seahub_db, sql_path)
File "/home/.../seafile/seafile-server-6.2.1/upgrade/db_update_helper.py", line 273, in apply_sqls
conn.execute(line)
sqlite3.OperationalError: no such table: sysadmin_extra_userloginlog

Failed to upgrade your database


Na, toll.
Also frickelte ich mir einen zurecht und passte erst die "seahub.sql" im Upgrade Verzeichnis des Pakets unter sql/6.2.0/sqlite3/ an, indem ich folgende Zeilen hinzufügte:

QUOTE:

CREATE TABLE "sysadmin_extra_userloginlog" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "username" varchar(255) NOT NULL, "login_date" datetime NOT NULL, "login_ip" varchar(128) NOT NULL);
CREATE INDEX "sysadmin_extra_userloginlog_14c4b06b" ON "sysadmin_extra_userloginlog" ("username");
CREATE INDEX "sysadmin_extra_userloginlog_28ed1ef0" ON "sysadmin_extra_userloginlog" ("login_date");


Ich speicherte die Änderungen und startete das Upgrade per sudo ./upgrade_6.1_6.2.sh erneut. Doch wieder erhielt ich die Fehlermeldung. Also machte ich mich daran, die drei Zeilen direkt in die Datenbank zu schreiben und dabei unterlief mir ein Denkfehler, denn ich bearbeitete die seahub.db im sqlite3 Verzeichnis des Upgrade Ordners. Ich erhielt erneut dieselbe Fehlermeldung, bis ich drauf kam! Die relevante und zu bearbeitende Datenbank liegt natürlich im Seafile Verzeichnis und muss, da schreibgeschützt, mit erweiterten Rechten bearbeitet werden.

Also zurück nach /home/seafile, zu root gewechselt und per nano seahub.db die Datenbank um obige drei Zeilen ergänzt. Das ganze dann gespeichert, von root wieder zum Pi User zurükgewechselt und das Upgrade ausgeführt, das nun endlich erfolgreich durchlief.

Abschließend startete ich seafile.sh und seahub.sh wieder, wobei der Start von seahub.sh nach den Änderungen in Nginx jetzt nicht mehr per ./seahub.sh start-fastcgi erfolgte, sondern nur noch per ./seahub.sh start.

Mein Client war danach auch direkt wieder verbunden, aber das Web Interface bringt mir noch eine "Bad URL in request" Meldung. Diesen Fehler muss ich jetzt im zweiten Schritt beheben. Doch soweit so gut schonmal.


OneNote 2013 verlangt ein Kennwort (hinter Proxy)

Im Büro arbeitete ich lange Zeit mit OneNote 2010 unter Windows 7, daheim bereits mit OneNote 2013 unter Windows 8 und 10. Also stieg ich auch auf der Arbeit auf die aktuellste Version um, hatte aber immer wieder das Problem, dass meine Notizbücher nicht synchronisiert wurden. OneNote wollte permanent ein Kennwort und ich erhielt noch nicht einmal eine Kennwortmaske.
Ich hatte immer den Proxyserver in Verdacht, doch nach einigen Recherchen stellte sich dieser nicht als Problem heraus, sondern vielmehr die Windows Anmeldeinformationsverwaltung, die man in der Systemsteuerung findet.
Nachdem ich aus dieser die beiden Einträge "MicrosoftOffice15_Data:live:cid=..." und "MicrosoftOffice16_Data:live:cid=..." rauslöschte und OneNote startete, erhielt ich eine Benutzer- und Kennwortabfrage - von OneNote und nicht die typische, die man vom Proxy kennt. Nach Eingabe meiner Onedrive Anmeldedaten, synchronisierte OneNote 2013 dann auch wieder fröhlich.

*EDIT*

Heute morgen hatte ich wieder das Problem und das Löschen der Credentials in der Anmeldeinformationsverwaltung brachte diesmal nichts.
Hier half es nur, in OneNote über "Datei/Öffnen" auf "Konto wechseln" zu klicken und in dem sich öffnenden Fenster auf "Abmelden". Danach wieder anmelden und schon blieb auch die Kennwortabfrage wieder aus.

Ziemlich nervig das ganze.


**EDIT**

Und wieder verlangt OneNote nach einem Kennwort und die beiden bisherigen Lösungswege brachten diesmal nichts. Im aktuellen Fall half es, im jeweiligen Notizbuch Synchronisierungsstatus (rechte Maustaste auf das jeweilige Notizbuch) auf den Weblink zu klicken und die Anmeldedaten auf der Live Website einzugeben. Erst danach lief in OneNote die Synchronisierung durch! ^^

NIK Collection kostenlos

Ich weiß, mein letzter Eintrag ist wirklich schon eine Weile her, aber ich kam einfach zu nichts. Und so auch heute wieder: eigentlich wollte ich zwei Grafiken bearbeiten und wollte dazu meine "NIK Collection", eine Sammlung an Filtern und Werkzeugen zur Aufbereitung von Fotos in Photoshop, reaktivieren. Diese kopierte ich einfach aus meinem Photoshop CS2 Ordner in meinen Photoshop CC 2015 Ordner, doch Photoshop startete die Suite nicht. Normalerweise reicht hier Copy & Paste. Hm...

Ich googlete einfach mal, weil es mir als der schnellste Weg erschien, und was soll ich sagen: Die Suite, die seinerzeit mal an die 500,- € kostete und die ich noch für 99,- € in einer Angebotsaktion erwarb, gibt es seit dem 24.3. diesen Jahres kostenlos bei Google!!

Unter https://plus.google.com/+NikCollection/posts/AFGsG2Di7EK findet man das komplette und rund 430 MB große Paket in der letzten Version; gratis!
Eine super Sache und ebenso erfreulich wie die Veröffentlichung der kostenlosen CS2 Versionen seinerzeit von Adobe.

Und somit lud ich mir das Paket eben herunter und stieß die Installation an. Und was diese unter CC 2015 angeht, so findet sich eine hier eine Anleitung: https://youtu.be/vEvOA6a4Gf0

HTTPS für Seafile mit Nginx

Lang, lang ist's her, dass ich meinen letzten Eintrag hier tätigte, aber zum Jahresende gab's so einiges zu tun und ich hatte keine Zeit und Muße zu schreiben. Jetzt aber ist alles wieder ein wenig ruhiger und ich nutze gerade die Zeit, da ich mir 'ne dicke Erkältung eingefangen habe, meinen Seafile-Server auf HTTPS umzustellen. Anleitungen gibt's dazu so einige wie z.B. unter:

http://jankarres.de/2013/06/raspberry-pi-owncloud-alternative-seafile-server-installieren/
oder direkt bei Seafile: http://manual.seafile.com/deploy/deploy_with_nginx.html

Die Anleitung von Jan Karres zur Installation und Einrichtung von Nginx und die Anpassung von Seafile ist gut erklärt und führt i.d.R. zum Ziel. Bei mir jedoch hakte die Umstellung ein wenig, da ich den Standardport für Seafile bei mir durch einen anderen ersetzt hatte und so machte ich bei der Umstellung einen Denkfehler und wunderte mich, weshalb das Rewrite von http:// auf https:// nicht klappte und weshalb die Seite partout nicht erreichbar war (502 Bad Gateway seitens Nginx).

Ok, eine zusätzliche Portfreigabe für den neuen Port für https:// hatte ich im Router bereits eingerichtet, doch ich kam bei der Konfiguration von Nginx und dem Starten von Seahub via "fastcgi" durcheinander.
Aber nach einer kleinen Denkpause kam ich auf den Trichter und löste das ganze schließlich so:

Seafile:

QUOTE:
SERVICE_URL in der ccnet.conf lautet nun: https://meinserver:4001 (Port von 4000 http auf 4001 für https geändert)
FILE_SERVER_ROOT in der seahub_settings.py lautet nun: https://meinserver:4001 (Port von 4000 http auf 4001 für https geändert)


In meiner für Seafile angelegten Site für nginx ("seahub") lauten die Einträge nun:

QUOTE:
server {
listen 4000;
server_name meinserver;
rewrite ^/(.*)$ https://$host:4001/$1; # Port mit angegeben, da die Weiterleitung sonst nicht klappt
}

server {
listen 4001;
ssl on;
[...]
fastcgi_pass 127.0.0.1:8000;
[...]
}


Danach startete ich Seahub per ./seahub.sh start-fastcgi und startete den Nginx-Dienst per "sudo service nginx start" neu.
Jetzt ist die Seite via https://meinserver:4001 zu erreichen sowie bisher über http://meinserver:4000, wobei bei letzterer Adresse eine Weiterleitung erfolgt.

Im Client änderte ich die Adresse noch ab und deaktivierte die Zertifikatsprüfung und komme jetzt wieder ins Webinterface und der Client verbindet sich sauber.


Weshalb das Starten von Seahub oder Nginx davor immer fehlschlug, lag daran, dass ich Seahub per "./seahub.sh start-fastcgi 4001" starten wollte und Nginx beim Starten dann meckerte: ""bind() to 0.0.0.0:4001 failed (98: Address already in use)".
Startete ich zuerst den Nginx Dienst und dann Seahub per "./seahub.sh start-fastcgi 4001", wollte Seahub nicht mehr starten.
Die Lösung ist dabei so einfach, wie für mich anfänglich aber nicht klar: In der Nginx Site muss (!) der fastcgi Wert "fastcgi_pass" auf 127.0.0.1:8000 stehen und Seahub muss per: "./seahub.sh start-fastcgi" ohne weitere Portangabe gestartet werden. Danach läuft Nginx sauber, hört auf die angegebenen Ports und leitet Anfragen entsprechend weiter.
Ich hatte mich schlichtweg zu sehr am Port 8000 gestört, den ich partout nicht haben wollte, weil ich ja bewusst einen anderen ausgewählt hatte.

OSMC: Tastaturlayout ändern

Die Alpha 4 von OSMC läuft bisher wirklich rund und macht Spaß. Dass sich der RPi 2 unter OSMC dabei nicht automatisch mit dem jeweiligen WLAN verbindet, ist zwar noch unpraktisch und erfordert manuelles Zutun, aber grundsätzlich kann man das Release schon wirklich gut nutzen. Neben dem WLAN-Problem gibt es aber auch noch eins mit dem Tastaturlayout, denn die in OSMC gewählte Einstellung (z.B. German QWERTZ) wird ignoriert. In OSMC sowie in der Konsole wird nur das englische Layout verwendet. Wer weiß, wo diejeweiligen Zeichen wie \, # usw. liegen, der kommt klar, aber auf Umlaute (Ä, Ö, Ü sowie ß) muss man verzichten. Daher muss man auch (bis jetzt) hier Hand anlegen und das Layout selbst umstellen. Dies sollte eigentlich mit vier Befehlen in der Konsole klappen, was bei mir aber nicht der Fall war.

Um die Befehle in der Konsole abzuseten, beendet man OSMC und drückt die "Esc"-Taste, wenn das Logo wieder erscheint (OSMC startet beim Verlassen den Mediencenter neu). Danach meldet man sich als osmc/osmc (Benutzername und Kennwort) an und gibt nacheinander die folgenden Befehle ein:

sudo apt-get install console-data
sudo apt-get install console-setup
sudo apt-get install console-locales
sudo apt-get install keyboard-configuration


Bei mir klappte dies aber nicht, weil die jeweiligen Datenpakete nicht gefunden werden konnten. Klar, wieso sollte auch mal wieder etwas auf Anhieb klappen ? :-)
Also aktualisierte ich erstmal mit:

sudo apt-get update

Das Update lief eine kurze Weile durch und wurde fehlerfrei abgeschlossen. Danach startete ich OSMC per "reboot"-Befehl neu.
In Abhängigkeit der gewählten Skin findet man in OSMC die OSMC eigenen Einstellungen; sowohl für den RPi ("BIOS" und sonstiges) als auch für OSMC selbst (Update). Diese findet man unter dem Punkt "OSMC" im Hauptmenü der OSMC-Skin oder unter "Programme" in der Confluence-Skin.
In den OSMC Optionen gibt's auch den Punkt "Update", den ich auswählte. OSMC lud daraufhin einige hundert Dateien mit ca. 70 MB Gesamtgröße herunter. Dabei war auch eine "main_locales" und ich dachte, dass hier die Korrektur der Tastaturlayout mitgeliefert wird, aber nach Abschluss der Updates und einem Reboot von OSMC hatte sich nichts geändert. Das deutsche Tastaturlayout wurde weiterhin nicht unterstützt.
Also wechselte ich zurück in die Konsole und setzte die obigen Befehle erneut ab.

sudo apt-get install console-data

führte wieder zu einem Paketdownload, der diesmal auch etwas umfangreicher war als zuvor (sicherlich dank apt-get update).
Nach

sudo apt-get install console-setup

öffnete sich das linux typische Auswahlfenster für die Anpassung der Keymaps. Hier wählte ich: "Select keymap from arch list"

Weiter ging's mit

sudo apt-get install console-locales

und ich erhielt die nächsten Fenster, in denen ich unter "Configuring keyboard-configuration" zunächst "Other" wählte. Im nächsten Screen wählte ich "German" und aus der Liste der folgenden Keyboard Layouts erneut "German".

Danach folgten noch

sudo apt-get install console-locales
sudo apt-get install keyboard-configuration


und ich war fertig.
Die Schriftart in der Konsole änderte sich und ich konnte hier schon mit \, ?, #, Ö, Ü, Ä, usw. arbeiten. Per "reboot" startete ich OSMC schließlich neu und testete das Layout nun, indem ich einen Netzwerkpfad als Quellort von Videodateien eintrug. Soweit klappte auch alles, nur den \ kann ich nicht verwenden, während alle anderen Zeichen (soweit ich sie getestet habe) kein Problemach machen.

Damit bin ich jetzt schonmal einen großen Schritt weiter, aber eben noch nicht am Ende.
Ich werde, vermutlich heute abend, nochmal ansetzen und in der Keyboard Konfiguration auf Kommandozeilenebene statt "German" als Keyboard Layout vielleicht mal "German - German (legacy)" wählen und sehen wie es sich auswirkt.
Oder ich versuche es mit loadkeys de-latin1.map.

Mit dem Befehl loadkeys läßt sich jederzeit in der Konsole eine neue Tastaturtabelle laden; loadkeys us.map beispielsweise schaltet auf amerikanische Tastaturbelegung um, loadkeys de-latin1.map stellt wieder die übliche deutsche Tastaturbelegung her. Die verschiedenen Tastaturtabellen stehen in /usr/lib/kbd/keytables/, eventuell müssen Sie loadkeys den vollen Pfadnamen mitgeben.

Auf die Tastaturbelegung unter X11 hat diese Einstellung jedoch keinen Einfluß; hier stellt man die Tastaturbelegung - auch für einzelne Tasten - mit dem Befehl xmodmap ein. Um die Belegung der Tastatur dauerhaft umzustellen, kann man in der Datei /etc/XF86Config in der Sektion `Keyboard´ den Eintrag `XkbLayout´ ändern.

Update folgt. :-)

Page 1 of 14, totaling 67 entries