Beiträge von Manul

    Ich habe sowas ähnliches in Betrieb. Softwäremäßig verwende ich auf dem Pi mpd als Abspieler, ergänzt um upmpdcli, das einige Funktionen nachrüstet. Ich steuere die Wiedergabe ausschließlich über Smartphone oder Tablet mit der App BubbleUPnP. Die hat in der kostenlosen Version ein paar Beschränkungen (Playlist maximal 16 Titel, wenn ich mich recht erinnere) - ich habe sie gekauft, ist nicht teuer.

    Vorteil von upmpdcli ist vor allem, daß die Playlist komplett auf dem Pi liegt - ich kann also das Handy oder Tablet ausschalten und die Musik läuft trotzdem weiter. Man kann das ganze auch zu einem Multiroomsystem erweitern, mit z.B. Fortsetzen der Wiedergabe in einem anderen Raum. Inzwischen geht wohl auch synchrones Abspielen, das habe ich mir aber noch nicht angeschaut.

    Selbst habe ich zwei Pis mit dieser Lösung in Betrieb, einen 1B im Wohnzimmer über HDMI an einem AV-Receiver und einen 2 im Schlafzimmer über eine HifiBerry-Soundkarte an einer Kompaktanlage. Ein dritter für mein Musikzimmer ist in Planung. Mit dem Sound bin ich sehr zufrieden.

    Zu Deinen weiteren Fragen: HDMI auf Cinch geht m.W. nicht, da müsstest Du den Miniklinkenausgang verwenden. Der hat keinen besonders guten Ruf, soll aber von Generation zu Generation besser geworden sein. Ich denke, es spricht nichts dagegen, den erst mal auszuprobieren - wenn Dir der Sound nicht gut genug ist, kannst Du immer noch eine Soundkarte dazukaufen. Ich bin, wie gesagt, mit der HifiBerry sehr zufrieden. Ein Gehäuse würde ich an Deiner Stelle dann erst kaufen, wenn die endgültige Entscheidung gefallen ist.

    Falls das für Dich relevant ist: Beim Pi 3 lassen sich die LEDs nicht komplett deaktivieren, beim Pi 2 geht das noch. Die HifiBerry-Karte hat ebenfalls eine LED, die während des Abspielens an ist. Hat mich anfangs im Schlafzimmer gestört, inzwischen nehme ich's kaum noch wahr bzw. finde es sogar ganz nett: Ich habe ein Holzgehäuse mit Himbeeraussparung im Deckel in Verwendung, die LED projiziert dann quasi diese Form an Wand und Decke.

    edit: Man sollte vor dem Antworten in lange offenen Fenstern unbedingt einen Reload ausführen... Trotzdem:

    Kannst Du mal die Ausgabe von

    Code
    dpkg -V libicu52

    posten?

    Zum apt-get-Problem aus #13: Hast Du denn mal ein "apt-get -f install" ausprobiert?


    Der Vorteil, der mich zu btrfs gebracht hat sind aber die Prüfsummen über die Daten. Es hat bei mir zB schon einmal die Lesefehler einer langsam den Geist aufgebenden Festplatte korrigiert. Ohne Prüfsumme hätte ich möglicherweise lange Zeit unbemerkt kaputte Daten gelesen.

    Hallo smutbert, vielen Dank fürs Teilen Deiner Erfahrungen mit btrfs! Ich hab mir das Dateisystem noch mal näher angeschaut, das klingt ja wirklich alles recht vielversprechend. Darf ich fragen, seit wann und in welchem Umfang Du das im Einsatz hast? Langfristige Zuverlässigkeit ist halt leider etwas, was sich nicht schnell nachweisen lässt... ;) Hast Du Erfahrungen mit der In-Place-Konvertierung von extX nach btrfs?

    Schön, daß es jetzt funktioniert!

    Deine "Lösung" ist allerdings etwas merkwürdig: Die fstab bestimmt lediglich, welche Dateisysteme beim Systemstart automatisch gemountet werden. Für die wird dann eben vom System ein "mount" ausgeführt - da gibt es keinen prinzipiellen Unterschied zu einem mount von Hand. Hast Du vorher vielleicht andere Optionen verwendet? Wie sah denn Dein mount-Befehl und wie sieht jetzt die fstab aus?


    natürlich:

    Code
    osmc@RPI2:~$ cat /etc/fstab
    /dev/mmcblk0p1  /boot    vfat     defaults,noatime    0   0
    /dev/mmcblk0p2  /    ext4      defaults,noatime    0   0

    Interessant - da ist das RAID schon mal nicht dabei. Jetzt würde mich wirklich interessieren, von wem/was/warum das gemountet wird.

    jar: Hast Du denn damals mal versucht, die Platten in einen PC oder so zu schrauben? Ich würde davon ausgehen, daß die ganzen NASen unter der Haube ein Linux-basiertes Software-RAID fahren, das sollte sich doch auch in einer neueren Generation oder eben extern rekonstruieren lassen.

    @Alle: Vielen Dank für die bisherigen Antworten. Ich kann auch noch kurz mein Setup beschreiben: Angefangen habe ich aus Kostengründen mit einer einzigen Platte im NAS und ohne weiteres Backup. Später habe ich dann zwei weitere Platten dazugekauft - eine, um über den USB-Anschluss des NAS ca. monatliche externe inkrementelle Backups zu machen, die ich außer Haus lagere, die andere, um sie intern zu verwenden und die NAS auf RAID1 zu bringen. Erfreulich fand ich, daß die Migration auf RAID1 tatsächlich ohne Datenverlust geklappt hat - da war ich vorher eher skeptisch und hatte schon damit gerechnet, das frische Backup wieder einspielen zu müssen.

    An sich fühle ich mich so für einen Privathaushalt ohne wirklich existenzielle Daten ganz gut abgesichert - bis jetzt habe ich jedenfalls noch nix verloren, toi, toi, toi. Wenn mal ein (vermutlich kleiner) Bereich mit wirklich kritischen Daten dazukommen würde, würde ich wohl speziell dafür ein inkrementelles Backup per rsync auf irgendeinen Onlinespeicher einrichten.

    Ein echtes Killerfeature habe ich bis jetzt hier noch nicht gefunden, finde es aber sehr interessant, Eure teilweise ja wirklich wohldurchdachten Setups kennenzulernen. Vielen Dank an alle fürs Teilen!


    wie Manu schrieb muss ich den Raidverbund nicht selbst mounten, nach einem Neustart wird der Verbund automatisch eingebunden.

    Aber nur, wenn Du irgendeinen Eintrag für das RAID in Deiner /etc/fstab hast - zeigst Du uns den bitte?

    Zitat


    (Bei anlegen des Raid kommt auch "fs created label BTRFS_RAID on /dev/sda1", ich dachte dies bedeutet das "sda1" gemontet wird)

    Nein, das bedeutet erst mal nur, daß auf sda1 (und sdb1) ein Filesystem angelegt wurde. Gemountet ist da noch nichts.

    Zitat


    Danach ist aber der Speicher nicht mehr über SMB erreichbar, erst wenn ich die Speicher wieder "umount" erscheint das Raid-Laufwerk wieder.
    [...]
    Der Raidverbund funktioniert an sich ja schon, daher teste ich gleich über SMB ;)

    Weißt Du denn sicher, daß in der o.g. Situation das Volume auch direkt am Pi nicht mehr zugreifbar war? Wenn ja, woher?

    Das Problem an Deinen Angaben im letzten Post ist für mich, daß nicht ganz klar wird, in welcher Situation die jeweiligen Befehle ausgeführt wurden. Waren da jeweils beide Sticks eingesteckt?

    Ich würde vorschlagen, nochmal kritisch in die /etc/fstab zu schauen. Dann mal rebooten und direkt danach die Ausgaben von "mount", "ls -l /dev/disk/by-uuid", " sudo btrfs filesystem show" und "sudo blkid" anschauen. Zugriff aufs RAID scheint in diesem Zustand ja zu funktionieren, kannst Du aber ruhig auch noch mal ausprobieren. Dann:

    • USB-Stick mit sdb1 ziehen
    • wieder einstecken
    • USB-Stick mit sda1 ziehen
    • wieder einstecken

    Und dabei nach jedem dieser Schritte

    • die 4 Befehle wiederholen
    • Zugriff auf /media direkt am Pi testen
    • Zugriff über SMB testen

    Ich denke, dann wärst Du ein Stück weiter.

    Zitat


    Wie verhält es sich den unter mdadm, dort sind die Laufwerke ja ganz normal mit ext4 formatiert. Wenn ich da ein Laufwerk des Radverbundes (RAID1 vorausgesetzt) an einem anderen PI anschließe, kann ich dann ganz normal drauf zugreifen?

    Nein, nicht ohne weiteres. Ein md-RAID kannst Du übrigens mit jedem beliebigen Dateisystem formatieren, ext4 ist lediglich am weitesten verbreitet.

    Zitat


    Das scheint bei einem btrfs-Raid1 nicht zu gehen, zumindest habe ich es noch nicht hinbekommen bei dem Ausfall von sda1, nur auf sdb1 zuzugreifen.

    Das muß gehen, sonst ist es kein RAID, sondern höchstens ein AID. ;) Daß Du es bis jetzt nicht hinbekommen hast, würde ich lediglich als Indiz werten, daß RAID mit btrfs zwar möglicherweise einfacher aber noch keinesfalls trivial ist. Aber Du schaffst das noch, da bin ich sicher - und würde mich freuen, wenn Du uns auf dem Laufenden hältst.

    Ich nutze zu Hause eine D-Link DNS-320L als NAS, hauptsächlich als Backup-Laufwerk und zum Auslagern nicht so wichtiger (heißt: ersetzlicher) aber großer Dateien. Das Modell habe ich hauptsächlich gewählt, weil ich zu geizig war, was Gscheits zu kaufen. ;) Ich muss aber sagen, daß ich eigentlich erstaunlich zufrieden bin, die NAS läuft stabil und ohne Murren, über eine Zusatzsoftware hat man sogar einen SSH-Zugriff und weitgehende Kontrolle über das zugrundeliegende Linux-System. Trotzdem überlege ich, eine alternative Firmware (Alt-F) zu installieren. Hauptsächlich aus Spieltrieb, ein bißchen auch, weil die Original-FW die Lüfter für meinen Geschmack etwas zu oft laufen lässt. Das nervt manchmal, und ehe ich jetzt in der FW rumbastele, dachte ich, ich könnte auch mal eine Alternative versuchen.

    Features habe ich an der DNS-320L bis jetzt keine vermisst - ich halte es aber durchaus für möglich, daß das daran liegt, daß mir einige nützliche Features für eine NAS im Homebereich gar nicht bekannt bzw. deren Vorzüge nicht bewusst sind. Daher die Frage an Euch: Welche Features Eurer NAS nutzt Ihr, welche sind für Euch unverzichtbar/wichtig/nice-to-have/überflüssig? Ihr dürft auch gerne dazuschreiben, welche NAS Ihr nutzt, hauptsächlich interessiert mich aber, was ich alles an phantastischen Möglichkeiten verpasse. ;)

    Schon mal Danke im voraus für Euren Input!

    "man at" sollte Dir die Dokumentation liefern.

    Ich kann selbst gar kein PHP, aber ich würde es mit

    [code=php]shell_exec('echo pilight-send -p rev2_switch -i E5 -u 0 -t | at "now + 1 hour"');[/php]

    (bzw. zum Testen "now + 1 minute") versuchen. Falls es nicht installiert ist, at gehört übrigens zum Paket "at" ("sudo apt-get install at").

    Schon, aber nach meiner Erfahrung ändern sich die Ausgaben von Kommandos mit der Zeit bzw. neuen Versionen gerne mal, und dann wundert man sich, warum das Skript von vorletztem Jahr plötzlich nicht mehr funktioniert bzw. kann von Glück reden, wenn man sich wenigstens noch erinnert, welches Skript eigentlich die vermisste Funktionalität bereitgestellt hat. Klar, wenn's nicht anders geht, geht's nicht anders - meistens aber doch, wenn man noch mal drüber nachdenkt.

    Wenn das keine einmalige Sache ist, würde ich einen Signalmechanismus im Programm implementieren. Das kann bspw. so aussehen, daß das Programm bei jedem Schleifendurchlauf überprüft, ob eine bestimmte Datei (zb. /tmp/mein_programm.stop) existiert. Ist das der Fall, beendet sich das Programm sauber (und löscht ggfs. die Datei, damit es beim nächsten Start nicht sofort wieder anhält).

    Per ssh kannst Du das Programm dann mit "ssh <hostname> touch <Dateiname>" beenden.

    Mist, ich hatte vorhin schon hier reingeschrieben aber offenbar nur den Vorschaubutton gedrückt. Das kommt davon, wenn man vor dem ersten Kaffee was schreibt...

    Erstmal: Interessantes Projekt, ich bin gespannt!

    Zum Testen würde ich auf jeden Fall smb erst mal außen vor lassen und den lokalen Zugriff testen. Wenn der klappt, sollte es auch über smb gehen und man hat beim Test eine potentielle Fehlerquelle weniger drin.

    Wie mountest Du denn Dein RAID bzw. wie sieht Deine fstab aus? Wie ist die Ausgabe von

    Code
    mount
    ls -l /dev/disk/by-uuid/

    llutz: Das ist so nicht ganz richtig: Laut der von Dir verlinkten Seite muss nur ein Eintrag für die UUID in die fstab, in dem aber beide devices explizit angegeben werden müssen. Das ist laut der von Harald654 verlinkten Anleitung nicht nötig. Da der Blogpost von 2011 ist, die Anleitung aber relativ aktuell zu sein scheint, würde ich es erst mal ohne probieren.

    Harald654: Darf ich aus Neugier fragen, warum Du Dich für btrfs und nicht für ein klassisches Software-RAID via mdadm entschieden hast?

    Ich stimme mit jar überein, daß es hilfreich wäre, wenn sich HG Butte mal wieder zu Wort melden würde. Bis er das tut, spekuliere ich aber gerne ein bißchen weiter - selbst wenn das nicht genau seine Anforderungen trifft, könnte es ja sein, daß mal jemand anderes mit einem ähnlichen Problem über den Thread stolpert, für den es vielleicht besser passt.

    Was ich bis jetzt herausgelesen habe: 6 Leute treffen sich zu gemeinsamer Action - welcher Art auch immer -, produzieren jeweils 20 GB an Daten und wollen später zu Hause jeweils Zugriff auf die gesamten 120 GB haben, um sie zu bearbeiten. Das wollen sie erreichen, ohne nach dem Ende der Action noch lange beisammen bleiben zu müssen. Ab wann "lange" anfängt, ist bis jetzt nicht genau spezifiziert, zwei Stunden sind aber auf jeden Fall schon zu lang.

    Was ebenfalls noch an Information fehlt ist, wie schnell nach dem Ereignis die Daten jedem zu Hause vorliegen sollen. Noch am selben Abend? Reicht am nächsten Tag? Oder gar am übernachsten?

    Eine Lösung, die ich mir beispielsweise vorstellen könnte, wäre:

    Jeder der Freunde besorgt sich einen Pi und eine DDNS Adresse. Der Pi bleibt zu Hause, angeschlossen wird ein Speichermedium, das mindestens 120 GB fasst. Das kann ein USB-Stick, eine SSD oder eine Festplatte sein, völlig wurscht. Auf das Medium kommt ein Filesystem oder eine Storagelösung die Replikation über WAN unterstützt. XtreemFS kann sowas angeblich, ich habe persönlich keine Erfahrungen damit, es gibt sicher noch andere Lösungen. Der Replikation wird so konfiguriert, daß auf jedem der Pis eine Kopie aller Daten zu liegen kommt. Dann kommt eine Softwarelösung drauf, die beim Einstöpseln einer SD-Karte (an einem externen Leser) deren Inhalt automatisch in den Storage kopiert und bei Abschluss eine email-Benachrichtigung verschickt.

    Dann kann man sich nach der Action sofort trennen, wer nach Hause kommt, steckt seine SD in den Pi und wartet dann, bis er 6 mails erhalten hat. Zu diesem Zeitpunkt liegen alle Daten lokal auf dem Pi und können z.B. im Heim-LAN verfügbar gemacht werden. Limitierender Faktor für die Geschwindigkeit ist vermutlich der Uplink des heimischen Internetanschlusses. Wenn wir den mal pessimistisch mit 1 MBit/s annehmen, würde der Upload von 20 GB ca. 56 Stunden, also etwas unter 3 Tage dauern, bei schnellerem Upload entsprechend kürzer. Wie gut das in der Praxis funktioniert, weiß ich nicht, es wäre aber aus meiner Sicht eine technisch interessante Lösung.