Entries from June 2014

Seafile: Can not connect the server

Beim Versuch, Dateien auf den eigenen Seafile Server hochzuladen, erhält man im Upload Dialog im Webinterface die Meldung: "Can not connect the server". Der Windows Client hingegen zeigt den Uploadfehler lediglich mit einem "!" an.
Die Ursache dafür könnte sein, dass der jeweilige User seine Upload-Quota erreicht hat oder dass schlichtweg kein Platz mehr auf dem Datenträger zur Verfügung steht, auf dem Seafile die hochgeladenen Dateien speichert.

QUOTA
---------

Falls es an der Quota liegt, lässt sich diese in der Verwaltung im Webinterface für jeden User einzeln einstellen. Soll sie global für alle User eingestellt werden, macht man dies in der "seafile.conf" mit folgendem Eintrag:

[quota]
default = x (x steht hier für einen numerischern Wert. Z.B.: 5 = 5 GB, 1 = GB, 10 = 10 GB)


Die seafile.conf befindet sich im Seafile Installationsverzeichnis oder, wenn man bei der Installation nicht drauf geachtet hat, sogar auf dem Speichermedium, auf dem Seafile die hochgeladenen Dateien speichert:

cd /mountpoint/speichermedium (mountpoint steht hier für den für Seafile angelegten Mountpoint (z.B. storage) und speichermedium für den Storagenamen (z.B. 2TB-HDD))


SPEICHERPLATZ ERSCHÖPFT
------------------------------------

Liegt es nicht an der Quota, ist der freie Speicherplatz auf dem Speichermedium erschöpft. Um dies zu prüfen, bietet sich das kleine Tool "NCurses Disk Usage" an, das in der Konsole "grafisch" anzeigt, welche Verzeichnisse wieviel Speicher verbrauchen.
Die Installation erfolgt per

sudo apt-get install ncdu

Danach wechselt man einfach in den Pfad zum Speichermedium

cd /mountpoint/speichermedium (s.o.)

und führt ncdu aus:

ncdu

Jetzt sieht man ziemlich schnell was wieviel belegt.
Es kann sein, dass direkt im Root des Speichermediums das Verzeichnis "blocks" liegt, das den Löwenanteil ausmacht. Bis zu Seafile 3.x wurde "blocks" noch dort abgelegt, wanderte dann aber mit einem Upgrade auf 3.x "storage", das sich im Root des Speichermediums befindet.
Hat man die Version 3.0.x von Seafile installiert, kann man somit bedenkenlos das "blocks"-Verzeichnis unter /mountpoint/speichermedium löschen, wenn man zuvor sichergestellt hat, dass sich unter /mountpoint/speichermedium/storage das neue "blocks"-Verzeichnis befindet:

rm -rf blocks

Sollten sich auch noch alte Datenbanken wie z.B. "seafile.db.20131026223259" darin befinden, können auch diese gelöscht werden.

Führt man danach ncdu wieder aus, sieht man wie sich der Speicherplatz drastisch reduziert hat. Danach ist der Upload wieder problemlos möglich.
Zudem kann man noch das verbliebene blocks-Verzeichnis entrümpeln, was hier beschrieben ist: https://github.com/haiwen/seafile/wiki/Garbage-Collecting-Unused-Blocks-on-Seafile-Server

Das "Blocks"-Verzeichnis unter "Storage", das dort seit Version 3.x zu finden ist, lässt sich wie folgt entrümpeln:

QUOTE:
Seafile uses storage de-duplication technology to reduce storage usage. The underlying data blocks will not be removed immediately after you delete a file or a library. As a result, the number of unused data blocks will increase on Seafile server.

To release the storage space occupied by unused blocks, you have to run a "garbage collection" program to clean up unused blocks on your server.

The GC program cleans up two types of unused blocks:
Blocks that no library references to;
If you set history length limit on some libraries, the out-dated blocks in those libraries will also be removed.

Before running GC, you must shutdown the Seafile program on your server if you use the community edition. For professional edition, from version 3.1.11, online GC operation is supported. If you use Professional edition, you don't need to shutdown the Seafile program if you are using MySQL or PostgreSQL as database. This is because new blocks written into Seafile while GC is running may be mistakenly deleted by the GC program.
Run GC in version 3.1.2 and later

To run GC program
./seaf-gc.sh run

If you want to do sanity check before actually removing any data, you can use the --dry-run option
./seaf-gc.sh dry-run

It will show you the total block number vs. the number of blocks to be removed.

To check data integrity after running GC, you can use seaf-fsck


Raspberry PI: Komfortables Kopieren zwischen (Netzwerk-)Datenträgern

An meinem RPi hängt eine externe 3,5" 2 TB Platte, auf der TV-Aufnahmen, ein bissel Musik und Fotos gespeichert sind. Diese wollte ich auf die externe 3,5" HDD meines Vaters kopieren, aber am Raspberry ist kein Anschluss mehr frei. Also steckte ich sie kurzerhand an den zweiten USB-Anschluss an der Fritz!Box, gab sie frei und startete die Kopierorgie. Nachteil: die Dauer. Windows berechnte zwei Tage dafür. *LOL* Da mir das zu langsam war, ich mein Notebook nicht so lange laufen lassen und die andere Platte nicht vom RPi abklemmen wollte, löste ich das ganze einfach so:

1. Platte an der Fritz!Box freigeben (Einstellungen in der Fritz!Box) (war ja schon erledigt)
2. Per SSH auf den RPi und die Freigabe unter Wheezy wie folgt mounten (habe hier cifs verwendet):

sudo mount -t cifs //192.168.xxx.xxx/freigabe /mnt -o user=myusername,domain=arbeitsgruppe

Danach war die Eingabe des Passworts des Users für die Freigabe erforderlich und fertig.

3. Kopieren der Daten vom bestehenden Mountpoint für die 2 TB Platte am RPi auf den neuen für die 1 TB Platte:

cd /media/exthdd/TV-Aufnahmen
cp *.* /mnt/WD-ExtHDD1000-01


So, jetzt können die Dinger laufen und der Kopiervorgang von mir aus eine Woche in Anspruch nehmen. Läuft ja alles schön im Hintergrund und ohne weiteres Zutun. :-)

Abmelden != Herunterfahren oder Sperren !

Ich frage mich nahezu täglich was so schwer daran zu verstehen ist, wenn ich einen Anwender bitte sich an Windows ABZUMELDEN !
Nur in den allerwenigsten Fällen schaffen es die User ebendies zu tun. In den allermeisten Fällen hingegen fahren sie den Rechner herunter oder sperren den Bildschirm - was noch unnötiger ist, vor allem nach der Vergabe zusätzlicher Berechtigungen, die erst nach einer Ab- und Neuanmeldung greifen.
Klar, wenn man auf den START-Knopf klickt, steht da gleich: "Herunterfahren". Aber das sagte ich ja nicht. Den kleinen Pfeil neben dem Knopf zu finden ist jedoch offenbar einfach zu schwer. *seufz*

Windows 7: Druckerinstallation bringt Fehler 0x0000007e

Beim Hinzufügen eines Druckers unter Windows 7 erhält man den Fehlercode 0x0000007e - wenn folgende Voraussetzungen erfüllt sind:

- Windows 7 64-Bit
- Drucker von HP
- Der Speicherort des Druckertreibers (z.B. auf einem Druckserver) weicht vom Standardort ab

Um den Fehler zu beheben, kann man einen Hotfix ausführen, der einen Regkey auf dem Rechner löscht, der den Drucker zur Verfügung stellt. Natürlich lässt sich der Key aber auch manuell löschen.
Gut beschrieben wird das Problem hier:

QUOTE:

I consulted with an HP print driver developer, he was the one who suggested deleting the key. That was in 2005. It has not caused a problem since.

The hot fix corrects an issue when the print driver changes the default file location and the spooler does not reset and loses track of where the next file is. The issue you are hitting is a setting on the printer that points to a 32bit version of a driver file which the 64 client bit machine (your client should be 64 bit) will not download.

HP does not setup the pointer to the file when installing the printer using the 64bit version of the driver on the server so they have addressed this when installing the printer on 64bit.

The reg key on the machine sharing the printer is

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Printers\PRINTERNAME\CopyFiles\BIDI

there will be an entry for spool\DRIVERS\W32X86\3\hpcpn6de.dll which you can delete so the clients can connect.

Quelle: Microsoft Technet

Da ich von den Printadmins den Key nicht einfach löschen lassen konnte, weil bisher nur eine Userin betroffen war, löste ich das Problem anders.
Zunächst vergab ich der Anwenderin lokale Adminrechte auf ihren Rechner. Danach lud ich von der HP Website den passenden Treiber (ohne Installer) herunter und kopierte den extrahierten (EXE mit 7-Zip entpackt) Ordner auf ihren Rechner. Danach fügte ich über "START/Geräte und Drucker/Drucker hinzufügen" einen Netzwerkdrucker hinzu, wählte "Das gesuchte Gerät ist nicht aufgeführt", trug die IP des Druckers ein und entfernte den Haken beim Feld, dass der Treiber vom Server gezogen werden soll. Im nächsten Schritt wählte ich den passenden Treiber aus dem von mir zuvor kopierten Ordner aus und die Einrichtung wurde erfolgreich abgeschlossen.

Raspberry PI als DLNA Server

Bisher sahen wir uns unsere Filme an, indem wir den kleinen ACER Revo mit Windows 8 anschmissen, XBMC starteten und den gewünschten Film abspielten. Da ich aber keinen Rechner mehr starten möchte, da der TV ja DLNA fähig ist, suchte ich nach einer Lösung und entschied mich dafür, den kleinen Raspberry Pi in seinem Funktionsumfang (bisher Cloudserver und Samba) zu erweitern. Sicher, man hätte auch einen Rechner laufen lassen können, auf dem XBMC als DLNA Server fungiert, aber wenn man schon einen Minirechner hat, der ohnehin immer läuft und dazu kaum Strom verbraucht, weshalb dann noch einen zweiten nutzen ?
Und so entschied ich mich für "MiniDLNA". Alternativ hätte es auch der XBMC sein können, aber MiniDLNA ist wie der Name schon sagt: klein, leicht und ruckzuck konfiguriert.

Leider schlug die Installation wie so oft gleich fehl. Ich loggte mich per SSH auf dem Pi ein und wollte zunächst ein Update sowie ein Upgrade von Wheezy machen, um danach MiniDLNA installieren zu können:

sudo apt-get update
sudo apt-get upgrade


Tja, leider konnten Repositories und Server nicht gefunden werden. Klasse. Ohne erfolgreiches Update und Upgrade scheitert aber auch die Installation von MiniDLNA.
Auch ein "sudo aptitude full-upgrade" scheiterte. Gut, konnte ich halt nicht weitermachen.
Und so probierte ich es heute, zwei Tage später erneut und siehe da: Update und Upgrade liefen auf einmal erfolgreich durch und zeigten mir auch andere Pfade zu den Repositories an. Da war wohl etwas verschoben und in der Zwischenzeit korrigiert worden.

Nachdem alles durch war, konnte ich MiniDLNA installieren:

sudo apt-get install minidlna

Die Installation an sich war schnell erledigt und das Configfile schnell angepasst:

sudo nano /etc/minidlna.conf

Meine Pfade passte ich der Doku entsprechend an:

media_dir=V,/media/exthdd/TV
media_dir=V,/media/exthdd/Filme


Die Pfadangaben und welche Medien sie enthalten folgen den Schema:

# * "A" for audio (eg. media_dir=A,/var/lib/minidlna/music)
# * "P" for pictures (eg. media_dir=P,/var/lib/minidlna/pictures)
# * "V" for video (eg. media_dir=V,/var/lib/minidlna/videos)


Abschließend trug ich die IP des RPIs unter "listening_ip" ein, ließ die vorgegebene Portnummer zunächst stehen, trug als "presentation_url" einfach "http://meindlna.de:80" ein, vergab einen "friendly_name" und beließ die "serial" bei der Voreinstellung. Auch "model_number" ließ ich in der Voreinstellung, aktivierte aber die automatische Erkennung neuer Dateien per "inotify=yes" und setzte das "notify_interval=895".
Danach speichern und per sudo minidlna -R die Verzeichnisse scannen lassen.
Per sudo service minidlna restart wurde dann MiniDLNA gestartet und mit sudo update-rc.d minidlna defaults den Autostart von MiniDLNA nach einem Reboot aktiviert.

Ausprobieren konnte ich das ganze jetzt noch nicht, da ich die Installation und Konfiguration von unterwegs aus vornahm. Was jedenfalls noch nicht klappte, aber das liegt eher an anderen technischen Eigenheiten, war der Zugriff auf die Medien per "MediaHouse" App von meinem Android Smartphone über eine bestehende VPN-Verbindung mit daheim. Auf die (lokalen) Geräte im Heimnetz kann ich über Freigaben zugreifen, der DLNA-Server wird aber nicht gefunden. Ein Netzwerkscan via FING-App zeigt mir nur die IPs und Geräte innerhalb des WLANs, in dem ich mich zurzeit befand. Auch ein Ping via "Ping&DNS" auf die IP des RPis scheiterte. Aber gut, das liegt eben alles an der Verbindungskonstellation. Werde daher heute abend mal den TV anwerfen und sehen was geht. Die Medienwiedergabe und damit das Streamen der Filme soll jedoch, was ich bisher so gelesen habe, problemlos möglich sein:

Oh and by the way, it streams 1080p to XBoxes, Playstations, Smart TVs and other computers flawlessly...

Und auch der Output über USB 2.0 (Anschluss am RPi) ist laut Erfahrungsberichten groß genug, um Filme ruckelfrei wiedergeben zu können. Selbst 4K-Titel stellen - angeblich - kein Problem dar:

USB 2.0 has a maximum throughput of 280mbits/s. According to this chart, http://en.wikipedia.org/wiki/High-definition_video#HD_on_the_World_Wide_Web.2FHD_streaming, it is more than enough.

According to the Blu-ray wiki, "Hitachi stated that such a disc could be used to store 7 hours of 32 Mbit/s video (HDTV) or 3 hours and 30 minutes of 64 Mbit/s video (Cinema 4K)." So again, USB 2.0 still has enough bandwidth, even for 4K apparently.



Wir werden sehen. ;-)

*EDIT*

Nach ein paar Tests muss ich sagen: es funktioniert alles super ! Ruckelfrei und problemlos. Lediglich fehlende Audio-Codecs auf dem TV verderben einem den Spaß. Je nachdem, welches Tonformat der Film mit bringt, kann der Fernseher damit nichts anfangen und meldet: "Audiocodec nicht erkannt" (oder so ähnlich). Dann kann man leider nichts machen, außer den Film in einem anderen Audioformat abzulegen. Welche Codecs von welchen Geräten unterstützt werden, kann man - irgendwo - auf den Seiten der Hersteller, in deren Handbüchern und im Internet in Foren finden. Eine Googlesuche ist hierbei recht hilfreich. ;-)

Page 1 of 2, totaling 6 entries