Posts by elle

Moin,

habe etwas aehnliches kuerzlich bei jemandem gemacht mit einer DS215+:
- Windows Server 2012 wird per Veeam auf die DS gesichert
- 2 Linux VMs per rsync

Die DS hat morgens einen Cronjob laufen, der die 3 Verzeichnisse per rsync (script, das vom task scheduler des DSM gestartet wird) auf externe Laufwerke, die einmal woechentlich getauscht und ausser Haus gebracht werden, sichert. Zunaechst hatten wir USB3 Laufwerke fuer's externe Sichern im Einsatz, hier war die Performance grottig und die DS wurde ziemlich warm - ich habe dann irgendwo gelesen, dass das USB Interface der Synologies nicht wirklich der Knaller ist; nun sind eSATA Laufwerke im Einsatz, die deutlich performanter sind, aber warm wird die Kiste immer noch.

Nach dieser Erfahrung ist der Gen8 Server besser, da ihn USB Transfers nicht so jucken sollten - allerdings nur, wenn du XPenology voll vertraust ...

Das Script macht nichts anderes als die externe Platte zu unmounten, falls sie gemountet sein sollte (DSM mountet die automatisch beim anstecken), dann den rsync durchzufuehren und die Platte wieder abzuhaengen.

Gruss

/elle

P.S.: das bei den Platten mitgelieferte eSATA Kabel musste am Steckergehaeuse auf Seiten der Synology leicht abgefraest werden, da der Stecker sonst nicht vernuenftig Kontakt bekam...

Quote from g3joker

Hi zusammen,

kurz: ich suche für einen Kunden eine einfache und sichere Backup-Möglichkeit. Im Moment findet die Sicherung quasi nicht statt (wenn dort der Buchhaltungs-PC also hopps geht können die erstmal den Laden zu machen...).

Ich dachte nun an eine Mischung aus Veeam zum sichern und dann an ein NAS um Speicher zur Verfügung zu stellen. Der Kunde wird mit Sicherheit nichts manuell machen können.

So dachte ich entweder an eine Synology DS216+ mit 2x 2 TB oder an einen Gen8 auch mit erstmal 2x2 TB und dann mit XPEnology als System.

Preislich sollte der Gen8 im Vorteil liegen...war es das auch? Ich selber will möglichst wenig Aufwand beim Kunden auch möchte ich nicht ständig da hinwollen. Die Daten sollten dann vom Kunden selber (unter meiner Anleitung per Fernwartung) monatlich auf eine weitere externe 2TB-Platte gesichert werden. Ich würde wenn das entsprechende Gerät als Raid1 laufen lassen.

Kritik? Vorschläge?

Es werden 3PCs und eine CNC-Maschine per Veeam gesichert.

Danke im Vorraus

g3joker

Display More

Quote from MegaX

Hi elle

kannst du mal schreiben was du genau gemacht hast?

Hi,

ich versuch's mal komplett aus dem Gedaechtnis zusammenzuschreiben:

• MLD lt. Beschreibung auf der Website auf der SD Karte installieren
• Server: NFS System installieren (da kommt IIRC noch der portmapper und ein oder zwei rpc daemons mit) - die OS Installations eines solchen Servers ist ein eigenes Thema
  
  
  Code

  Debian: apt-get install nfs-kernel-server

• Server: Verzeichnis anlegen, auf dem die NFS Root liegen soll - da ich plane, dort auch noch andere abzulegen, habe ich die MLD fuer den PI in ein eigenes Unterverzeichnis unter dem Share gelegt
  
  
  Code

  mkdir -p /srv/nfsroots/mld

• Server: ein share fuer die NFS roots in /etc/exports definieren - der Stern unten bestimmt, welche Clients den Share mounten duerfen
  
  
  Code

  /srv/nfsroots *(rw,async,wdelay,insecure,no_root_squash,no_subtree_check,sec=sys,rw,no_root_squash,no_all_squash)

• Server: ein share in /etc/exports fuer das VDR Aufnahmeverzeichnis definieren - der Stern unten bestimmt, welche Clients den Share mounten duerfen (mein video_dir ist /srv/VDR)
  
  
  Code

  /srv/VDR *(rw,no_root_squash,no_subtree_check)

• Server: die exports neu laden
  
  
  Code

  exportfs -rav

• Client: Mounten des MLD Verzeichnisses im NFS Share nach /mnt2 (auf dem MLD Client ist /mnt in Benutzung):
  
  
  Code

  mkdir /mnt2 && mount <ServerIP>:/srv/nfsroots/mld /mnt2

• Client: Kopieren des Inhalts der Rootpartition auf den Server:
  
  
  Code

  rsync -avx / /mnt2 # Das x sorgt dafuer, dass rsync in dem einen Filesystem bleibt, dadurch wird der Inhalt von /dev /sys usw. nicht mitkopiert

• Client: Unmount des Datenverzeichnisses
  
  
  Code

  umount /mnt/data

• Client: Erstellen des Aufnahmeverzeichnisses bzw. Mountpoints:
  
  
  Code

  mkdir /mnt/data/tv

• Client oder Server: Anpassen der geteilten fstab (nicht die des Servers!!!!) - auskommentieren des bisherigen Eintrags fuer das rootfs und einbinden des Serververzeichnisses; auf dem Server
  
  Code

  vi /srv/nfsroots/mld/etc/fstab

  auf dem Client

  Code

  vi /mnt2/etc/fstab

  Code

  #UUID=<eine lange UUID>    /    btrfs   errors=remount-ro      0        1
  <ServerIP>:/srv/nfsroots/mld      /      nfs        defaults       0         0
  #UUID=<eine lange UUID>    /mnt/data       nfs       defaults      0       0
  <ServerIP>:/srv/VDR      /      nfs        defaults       0         0

• Client: Aendern der /boot/cmdline fuer DHCP
  
  
  Code

  root=/dev/nfs rootfstype=nfs nfsroot=<ServerIP>:/srv/nfsroots/mld quiet splash=quiet ip=dhcp nodialog smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0

  
  fuer static IP

  Code

  root=/dev/nfs rootfstype=nfs nfsroot=<ServerIP>:/srv/nfsroots/mld quiet splash=quiet ip=<clientIP>:<serverIP>:<gateway>:<netmask> nodialog smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0

• Client: Aendern der /boot/config.txt - dort den Eintrag fuer die initramfs entfernen oder mit einem # auskommentieren

Ich hoffe, ich habe nichts vergessen ...

Ruhig fragen, falls Du Fragen hast - wie gesagt, bin nicht sicher, ob ich alles richtig aus dem Gedaechtnis zusammenbekommen habe...
Gruss

/elle

Hi,

kaum macht man's richtig ...

Danke! Hat geklappt - nur bin ich mir im Moment gar nicht sicher, ob ich das wirklich will - durch die 100MBit Schnittstelle bootet er deutlich langsamer als von SD Karte - auf der anderen Seite - wann bootet man nen Pi schon?

Gruss

/elle

Hi,

dann werde ich das heute abend mal probieren und Dich wissen lassen, wie's ausgegangen ist ...

Gruss

/elle

Quote from clausmuus

Hi,

ich hab mich bisher noch nicht mit dem thema befasst. Von daher erst mal ein paar Fragen.
- Kann wirklich der Kernel selber den nfs Mount machen? Ist das also wirklich eine Kernel Funktion, oder übernimmt das üblicherweise die initramfs?
- Müsste dazu nicht erst einmal das Netzwerk Interface eingerichtet sein?
- Wenn der Kernel das selbständig kann, müsstest Du in der /boot/config.txt die initramfs Zeile entfernen

Die initramfs der MLD kann den nfs Mount nicht übernehmen, da diese keine Netzwerk Funktionalität mitbringt.

Claus

Hallo Claus,

wie Johns bereits schrieb, kann der Kernel das selbst; m.W. sollte das aber unabhaengig davon, ob eine initramfs geladen wird oder nicht funktionieren - bin mir da aber nicht sicher.

Werde das heute abend mal probleren - bin im Moment nicht zu Hause und habe hier keinen Pi, mit dem ich es probieren koennte.

Waere es eventuell denkbar, einfach zum Test einen anderen Kernel zu verwenden oder hat der MLD Kernel irgendwelche Spezialitaeten eingebaut, sodass MLD mit einem anderen Kernel nicht laufen wuerde?

Johns - die U-Boot Geschichte brauche ich doch nur, wenn ich auch den Kernel ueber's Netz laden moechte. Den lade ich hier aber nach wie vor von der SD-Karte.

Danke + Gruss

/elle

Hallo zusammen,

bin gerade dabei, mit einem Raspberry Pi 2 herum zu experimentieren. Nachdem das System problemlos von SD Karte laeuft, wuerde ich gerne root ueber NFS mounten, um eben die SD Karte etwas zu schonen. Der Server laeuft eh ...

Nun bekomme ich aber beim Booten die Meldung (quiet und splash=quiet habe ich aus /boot/cmdline rausgenommen, um die Meldungen lesen zu koennen), dass der NFS share ein

Unknown root device

ist.

Der NFS Server laeuft, von meinem Laptop aus kann ich den Share auch problemlos mounten, aber auf dem Pi lande ich in der Busybox der initrd. Wenn ich dort manuell versuche zu mounten bekomme ich die Meldung, dass die Verbindung verweigert wird (connection refused).

Kann es sein, dass der MLD Kernel kein NFS root device kann? Lt. der config im GIT scheint es einkompiliert zu sein, aber muss ev. die initrd neu gebaut werden oder bin ich einfach nur zu bloed?

Auf dem Server:

root@helos:~# exportfs -v
<snip>
/srv/nfsroots 	<world>(rw,async,wdelay,insecure,no_root_squash,no_subtree_check,sec=sys,rw,no_root_squash,no_all_squash)
</snip>

cmdline auf Raspberry:

root=/dev/nfs rootfstype=nfs nfsroot=192.168.2.100:/srv/nfsroots/mld ip=dhcp nodialog smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0

Danke + Gruss

/elle

Hallo zusammen,

nachdem mir anscheinend mal wieder eine Satkarte kaputt gegangen ist und ich nur noch einen Tuner in meinem Server zur Verfuegung habe, stehe ich vor der Auswahl eines Ersatzes fuer die kaputte Karte.

Zur Auswahl stehen:

• Octopus + DuoFlex S2
• Cine S2
• DVBSky S952
• Digibit R1 (SAT->IP)
• Octopus Net (SAT->IP)

Leider kann ich nirgends einen Vergleich der Karten finden und weiss nicht, welche ich mir anschaffen soll.

Hat eventuell jemand mal einen Vergleich anstellen koennen?

Ebenfalls interessant waere zu wissen, wie problemlos (oder -behaftet) der Einsatz eines SAT->IP Receivers (e.g. Octopus Net oder Digibit R1) mittlerweile mit VDR ist.

Kann mir da jemand behilflich sein?

Der Server ist headless mit einem AsRock Q1900M Pro3 Mainboard (2x PCIe + 2x PCI) und 8GB RAM und steckt in einem Miditower.

Danke vorab schonmal.

Gruss

/elle

Moin,

ich habe einen VDR Server laufen (bzw. meist eher nicht), der per acpi-wakeup fuer Aufnahmen geweckt wird und per etherwake/wakeonlan bei Bedarf ueber die /etc/rc.local von den Clients geweckt wird. Es gibt keinen Grund, den Server auf Verdacht staendig laufen zu lassen.

Klappt wunderbar - das Einzige, das ein wenig laestig ist, ist, dass die Clients etwas laenger brauchen, bis sie ein Bild anzeigen und der Mount des Aufnahmeverzeichnisses erst etwas spaeter verfuegbar ist.

Gruss

/elle

Sah ganz normal aus - das ist ja das merkwuerdige: Ich konnte keinerlei Unregelmaessigkeiten beobachten ...

Habe die Kiste damals mit munin monitored (via lmsensors) und dabei sind die Temperaturen der Cores nie weit von 40 Grad abgewichen - mal 2 oder 3 Grad mehr aber das war's - aehnlich mit den HDD Temperaturen, die immer so zwischen 28 und 40 Grad lagen (jetzt liegt die eine Platte bei 30 Grad - und das auf dem Speicher bei dem Wetter :-).

Gruss

/elle

Mir faellt gerade noch ein, dass ich schon Crashes inkl. Kernel panic, backtraces und core-Dumps hatte (wahrscheinlich auch noch habe) bei hoher Last - z.B. einer Kernelkompilierung.

Gruss

/elle

Moin,

da gab's bei mir bei 4 verschiedenen Riegeln auch keinerlei Unregelmaessigkeiten ...

Gruss

/elle

Moin,

das ist interessant - aehnliches hatte ich auch bei meinem Server (siehe Sig.), allerdings nicht reproduzierbar und ohne Backtrace o.ae.. Auch zeitlich war alles zwischen 2 Minuten nach Boot sowie mehreren Tagen alles drin. Die Kiste lief damals 24x7 (wenn sie denn lief) und sollte als Server laufen.

Nun laeuft das Ding nur noch on demand (acpi wakeup) mit ausgelagertem NFS und ich habe keine Probleme mehr damit.

Meine Beobachtungen (nach Durchtauschen mehrerer Speicherriegel) haben mich vermuten lassen, dass es ein Temperaturproblem gab. Die Probleme traten weniger haeufig bei geoeffnetem Gehaeuse (so betreibe ich die Kiste im Moment) auf.

Auch habe ich mit verschiedenen DVB Kombinationen, Kerneln usw. experimentiert, aber keinen echten Erfolg gehabt, ausser dass beim backported 3.2.0 Kernel (das System laeuft unter Debian squeeze) das Problem weniger stark zu sein schien.

Gruss

/elle

Hi Miru,

verstehe die Frage nicht ganz - was gibt's denn da zu konvertieren?

Meinst Du die Passworte in der /etc/shadow? Oder hast Du UIDs/GIDs unter < 1000 (= system accounts unter manchen Linuxen ...).

Gruss

/elle

frontend 1/0 timed out while tuning to channel 3, tp 394

Falls mich mein Alzheimer nicht taeuscht, heisst dies doch, dass der VDR nicht auf den Tuner zugreifen kann, oder irre ich mich da?!

Kann es sein, dass tvheadend noch laeuft und somit die Tuner blockiert?

Gruss

/elle

Quote from austen

"exportfs -r" meldet nichts.

Und

sieht irgendwie normal.aus

Auf der Konsole bekomme ich die eine Fehlermeldung erst, wenn ich einen Connect versuche. Vorher kommen keine Hinweise.

Wieso habe ich eigentlich nichts in den Logdateien, wie z.B. syslog? Kann man das aktivieren?

austen

Display More

Versucht Dein Client ev. ueber IPv6 zu mounten und ist daher nicht zugelassen?

Ersetze mal Dein konkretes 192. Netz einfach nur durch * und versuch's dann noch mal. Dass localhost nicht geht, ist bei Deiner exports klar - 127.0.0.1 ist nicht erlaubt.

Gruss

/elle

Ich waere mir da nicht so sicher - ich hatte das Problem auch und musste feststellen, dass aus Clientsicht alle Dateien nobody:nogroup gehoerten und ich nicht darauf schreiben konnte.

Ich musste in der fstab explizit die Option

nfsvers=3

setzen, damit er mit NFS v3 connected und alles wie gehabt funktioniert.

Gruss

/elle

Edit: P.S.: Ich war einfach zu faul, mir NFS v4 anzulesen und den Kram dann umzustellen

Hi Darkstar,

ich denke, dass XBMC fuer die Dockstar doch etwas zu viel des Guten ist - zu hoher RAM Verbrauch, zu hohe Anforderung an CPU usw.

Anscheinend braucht's zum Betrieb des XBMC nach dem Stacktrace zu urteilen auch noch Zugriff auf nen RTC, den die Dockstar nicht hat.

Wenn's nur um Musik auf der Dockstar selber abspielen mit Fernsteuerung via WLAN/LAN geht, solltest Du Dir mpd ansehen (http://mpd.wikia.org/); das habe ich auch laufen und funktioniert wunderbar und bietet Clients/"Apps" fuer jedes gaengige OS und Mobiltelefon an.

Falls Du auf der Dockstar Debian installiert hast - reicht ein

apt-get install mpd ncmpc

auf der Kiste selbst zur Installation aus. Dann noch Dein Musikverzeichnis nach /var/lib/mpd/music verlinken, die Dateien von mpd einlesen lassen und das war's dann ...

Gruss

/elle

Quote

Originally posted by Darkstar
Hi,
ich würde gerne XBMC auf der Dockstar laufen lassen um so über das Webfrontend bzw eine iPhone App Musik abspielen zu können. Nach ein bischen rumprobieren mit Xvfb und xserver-xorg-video-dummy komme ich aber leider nicht weiter, da das ganze immer mit einer "Illegal Instruction (core dumped)" abstürzt. Im crashlog finde ich einen zimelich kurzen Stracktrace der mich aber leider auch nicht wirklich weiter bringt:

Code

Thread 1 (Thread 3231):
#0  0x00262438 in CThread::CThread() ()
#1  0x001f7b48 in CAlarmClock::CAlarmClock() ()
#2  0x001f7bd0 in ?? ()
#3  0x001f7bd0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Hat jemand vielleicht eine Idee wie das ganze laufen könnte?

Gruß Darkstar

Hi,

ich war von einem Standard-Ubuntu oder Debian ausgegangen und mir nicht bewusst, dass die yaVDR-Jungs autofs veraendert haben, sorry.

Quote

Originally posted by ludi

Im yavdr 0.3a gibt es kein /net im auto.master; es gibt aber ein net.yavdr. Und im auto.net.yavdr steht dass die Datei vom Webserver beschrieben wird.

Ich nehme an, diese Änderungen wurden wegen des avahi mounters von den Entwicklern des yavdr durchgeführt. Ich werde es mir morgen näher ansehen.

MfG

Aber vielleicht kriegst Du's ja trotzdem an's rennen ...

Gruss

/elle

Moin,

man koennte es aber auch per autofs machen - dabei gibt es aber mehrere Varianten, hier die einfachste, quasi out-of-the-box Variante:
- apt-get install autofs
- In /etc/auto.master die Zeile mit /net aktivieren
- autofs neu starten
- cd /net/<hostname>/<sharename> mountet automatisch den NFS-Share vom NAS
- nach einer zeit der nichtnutzung wird automatisch unmountet

Gruss

/elle

Geht auch mit SIGTERM:

[pid  7674] --- SIGTERM (Terminated) @ 0 (0) ---
Process 7674 detached
[pid  7675] +++ killed by SIGTERM +++

Gruss

/elle