Forum: PC Hard- und Software NAS mit Virtualisierung - Systemarchitektur?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Seb A. (aslmx)


Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Mal wieder ein NAS Thread... aber das Thema ist auch beliebig komplex...

Mein 7 Jahre alte Synology NAS muss bald in Rente gechickt werden. Da 
ich in der Zwischenzeit mit meinen Clients auf Linux gewechselt bin und 
sich hier eine kleine Raspberry "Serverfarm" angesammelt hat, dachte 
ich, baue ich mir lieber was eigenständiges - und weiß dann am Ende 
hoffentlich Bescheid darüber ;)

Die ganzen Funktionen die man von Synology/QNAP oder so bekommt, brauche 
ich eigentlich gar nicht und die paar, die ich brauche, würde ich am 
liebsten selbst basteln.

Ich schieb das ganze schon vor mir her, da ich nicht so der Hardware typ 
bin. Ich dachte für die Hardware nehme ich mir einen Bauvorschlag, z.b. 
von der c't oder von anderen NAS Blogs.

Was mir gerade erstmal mehr Sorgen bereitet ist die Software sache. Ich 
habe eigentlich nicht so viel Zeit, dass ich groß rumexperimentieren 
kann, daher möchte ich es am liebsten direkt richtig machen.

Vielleicht mal kurz ein Überblick was ich mir vorgestellt habe:

Ein Host System mit genug Plattenspeicher, CPU und RAM.
Das Host System kann ja auf einer kleinen bis mittleren SSD laufen. 
Dachte an UbuntuServer oder an ein Debian.

Auf dem Host System bräucht eich dann ca. 4 VMs
1. NAS VM, die soll Fileserver, ggf. DLNA und ein Fotoalbum 
bereitstellen
 Momentan habe ich 2TB Speicherplatz mit 2*2TB im RAID 1 (Synoloy), ich 
würde wenigstens gerne verdreifachen um Zukunftssicherheit zu haben. 
Würde liebend gerne mehr Backups der Clients auf dem NAS speichern.

2. NextCloud für die wichtigsten Dateien, Kalender und Kontakte
Das kann eine kleine VM sein, mit Apache und ~30-50GB Speicherplatz

3. "Application" Server für Prosody/XMPP, und ggf. andere
Das muss auch keine große VM sein, ~20GB reichen dicke...

4. Spielplatz - zum rumspielen halt
Dachte an 50-100GB Plattenplatz und dann mal schauen was drauf läuft...

Nun wie soll ich Anfangen? Ich könnte VM 2. - 4. ja von der SSD laufen 
lassen und dann die geplanten 3-4 * 4TB HDDs an die NAS VM durchreichen.

Die Frage die ich mir nun stelle:

Macht es Sinn die NAS FUnktionalität in eine VM auszulagern, und kann 
ich dann ein BTRFS Volume über 3 Platten (das ggf. erweiterbar sein 
soll) welches über irgendein RAID (das ist die nächste Frage...)
Oder wäre es vllt. einfacher (aber unflexibler?) den Samba/NFS Server 
einfach auf dem Host system zu betreiben und irgendwas ONTOP (Fotoalbum 
/ DLNA) einfach auszulagern? (oder auch gleich mit auf dem Host System 
zu betreiben?)

Meine Vorstellung war halt, dass das Host System nur die Platform 
bereitstellt und ich dann die ganzen VMs mit LUKS(?) betreiben kann 
damit die Daten verschlüsselt sind. So kann ich bei einem Reboot des 
Hosts mich auf ihm per SSH einloggen udn dann die VMs starten. USV ist 
vorhanden, sollte also hoffentlich selten vorkommen.


Raid? Welches nehmen? Gibt es eine Konfiguration die mir möglichst wenig 
Speicherplatz nimmt wenn die Plattengröße unterschiedlich ist und die 
mir möglichste Flexibilität erlaubt?


In dem anderen Thread von letzter Woche 
(Beitrag "Hilfe: FreeNAS oder Debian") habe ich schon einige 
Erkenntnisse gewinnen können. Z.b. kannte ich ProxMox noch nicht und das 
sieht eigentlich so aus, als könnte ich damit wenigstens umsetzen das 
alles in einer eigenen VM läuft und ich mich um das Host System nicht zu 
sehr kümmern muss.


Vor nem knappen Jahr dachte ich an OMV oder FreeNas, aber ich glaube das 
geht schon wieder zu viel in RIchtung Synology. Das mag zwar sehr 
einfach und schnell einzurichten sein, aber ich mag diese "Abhängigkeit" 
nicht. Vielleicht bin ich zu sehr durch Synology geschädigt (da war es 
jedenfalls für mich nicht so einfach irendwelche Programme die ich haben 
wollte, die es aber in deren "Appstore" nicht gab zu installiere) und 
bei FreeNas und OMV ist das besser als ich es mir vorstelle.


Lange Rede kurzer Sinn: wie konfiguriere ich am besten die 3-4*4TB (oder 
3*8, je nachdem wieviel Knete übrig bleibt ;)), sodass ich ein gewisses 
Maß an Redundanz habe falls mal eine Platte ausfällt und mir dabei auch 
die Flexibilität nicht nehme?

Bei meinem Synology NAS ist das in 7 Jahren immerhin einmal passiert. 
Ging dann zum GLück recht einfach. Gleiche Platte nochmal gekauft (also 
gleiche Größe), eingebaut und Replizierung startete mehr oder weniger 
automatisch.

Achso, das Synology NAS wollte ich dann nochmal neu aufsetzen und das 
kann als Backup Server für Fotos und Aufnahmen etc. dienen (das würde 
ich dann aber mit 2*2=4 TB als eigenständige Volumes machen, statt als 
RAID - mal schauen).


Gar nicht so einfach - werde wohl noch einiges lesen müssen, aber 
vielleicht habt ihr ja den ein oder anderen Vorschlag oder kurze 
Best-Practice Beschreibung aus eurem Umfeld?

danke!
vgs

von Dr. No (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sebastian J. schrieb:
> Macht es Sinn die NAS FUnktionalität in eine VM auszulagern, und kann
> ich dann ein BTRFS Volume über 3 Platten (das ggf. erweiterbar sein
> soll) welches über irgendein RAID (das ist die nächste Frage...)
> Oder wäre es vllt. einfacher (aber unflexibler?) den Samba/NFS Server
> einfach auf dem Host system zu betreiben und irgendwas ONTOP (Fotoalbum
> / DLNA) einfach auszulagern? (oder auch gleich mit auf dem Host System
> zu betreiben?)


Ich betreibe auch seit vielen Jahren einen VM Host mit mehreren VMs bei 
mir. Ich habe den Host immer schlank gehalten und damit gute Erfahrungen 
gemacht. Also ja, nimm die VM und reich die Festplatten per virtio 
durch.
Allenfalls kannst Du überlegen, ob Du das BtrFs- oder 
was-auch-immer-Volume vom Host aus erstellst und dann dieses Volume 
durchreichst. Ich würde das aber komplett trennen, dann kannst Du immer 
schnell die VMs samt Platten auf einen anderen Host umziehen.


> Meine Vorstellung war halt, dass das Host System nur die Platform
> bereitstellt und ich dann die ganzen VMs mit LUKS(?) betreiben kann
> damit die Daten verschlüsselt sind. So kann ich bei einem Reboot des
> Hosts mich auf ihm per SSH einloggen udn dann die VMs starten. USV ist
> vorhanden, sollte also hoffentlich selten vorkommen.


Kannst Du machen, noch sicherer wäre es, das ganze System zu 
verschlüsseln, damit erst gar keiner mitbekommt, was darauf läuft. So 
habe ich das bei mir eingerichtet.


> Raid? Welches nehmen? Gibt es eine Konfiguration die mir möglichst wenig
> Speicherplatz nimmt wenn die Plattengröße unterschiedlich ist und die
> mir möglichste Flexibilität erlaubt?


RAID0 ;)


> In dem anderen Thread von letzter Woche
> (Beitrag "Hilfe: FreeNAS oder Debian") habe ich schon einige
> Erkenntnisse gewinnen können. Z.b. kannte ich ProxMox noch nicht und das
> sieht eigentlich so aus, als könnte ich damit wenigstens umsetzen das
> alles in einer eigenen VM läuft und ich mich um das Host System nicht zu
> sehr kümmern muss.


Also unter Ubuntu musst Du mit KVM auch nicht viel machen. Die 
Einrichtung ist nicht schwer, nur ein paar Änderungen an der Default 
Config. Die Verwaltung dann über virtmanager auf dem Client.


> Gar nicht so einfach - werde wohl noch einiges lesen müssen, aber
> vielleicht habt ihr ja den ein oder anderen Vorschlag oder kurze
> Best-Practice Beschreibung aus eurem Umfeld?


Wie geschrieben: Bei Deinen Anforderungen ein Standard Ubuntu Linux, 
dazu KVM und virtmanager auf dem Client. Das System sowie die VMs auf 
eine SSD, die drei Festplatten über virtio an die NAS-VM durchreichen 
und dort ein RAID5 einrichten, dazu dann NFS, Samba, fertig ist die 
Geschichte.
Mit ein bisschen Erfahrung hast Du das nach einem Tag laufen, mit ein 
bisschen mehr nach einem halben.

von Daniel A. (daniel-a)


Bewertung
0 lesenswert
nicht lesenswert
Ich nutze auf meinem Server mit Devuan Jessie libvirt+qemu für VMs und 
libvirt-lxc für Container. Container verbrauchen viel weniger Ressourcen 
als VMs, ich habe momentan eine pfSense VM und ~14 Devuan Container, auf 
denen Webserver, Mailserver, NFS Shares, etc. laufen, meine CPU 
Auslastung ist meistens bei etwa 0.1% oder niedriger, und von meinen 62G 
RAM hat mein Server im moment erst für 7GB verwendung gefunden, die 
Caches inklusive.

Hier ist eine Anleitung für libvirt-lxc Container von mir: 
https://dev1galaxy.org/viewtopic.php?id=617

Was Verschlüsselung angeht kommt es beim optimalen Verfahren doch sehr 
auf das eigene threat model an. Will man sich gegen Polizeirads oder 
Diebstahl verteidigen, macht full disk encryption, und eventuell 
zusätzlich ein steganographic file system Layer Sinn. Will man die Daten 
vor Hackerangriffen schützen, und müssen diese vom Server nicht 
weiterverarbeitet werden, kann man stackable filesystem-level encryption 
verwenden, und die Daten nur auf dem Gerät wo sie gebraucht werden 
wieder entschlüsseln.

von dockstar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vetmutlich braucht meine Dockstar für NFS und FTP inklusive
USB-Platte weniger Energie als die brachliegenden 55 GB RAM.

Aber jeder wie er will.

von Seb A. (aslmx)


Bewertung
0 lesenswert
nicht lesenswert
Erstmal Danke an dich und die anderen beiden für die Antworten!


Dr. No schrieb:
> Allenfalls kannst Du überlegen, ob Du das BtrFs- oder
> was-auch-immer-Volume vom Host aus erstellst und dann dieses Volume
> durchreichst. Ich würde das aber komplett trennen, dann kannst Du immer
> schnell die VMs samt Platten auf einen anderen Host umziehen.

Genau das war der Plan. Das Daten und System möglichst unabhängig 
voneinander sind.

> Kannst Du machen, noch sicherer wäre es, das ganze System zu
> verschlüsseln, damit erst gar keiner mitbekommt, was darauf läuft. So
> habe ich das bei mir eingerichtet.

Was machst du bei unerwarteten Powerdown? Musst du dann vor Ort das PW 
eintippen, oder gibts da noch einen Trick?


> RAID0 ;)

das wollte ich jetzt nicht hören ;)

>  Die Verwaltung dann über virtmanager auf dem Client.

Danke für den Tipp! Das sieht ja von der Benutzung dann fast so aus als 
ließe ich VirtualBox lokal laufen :)

> Wie geschrieben: Bei Deinen Anforderungen ein Standard Ubuntu Linux,
> dazu KVM und virtmanager auf dem Client. Das System sowie die VMs auf
> eine SSD, die drei Festplatten über virtio an die NAS-VM durchreichen
> und dort ein RAID5 einrichten, dazu dann NFS, Samba, fertig ist die
> Geschichte.

Hört sich nach einem Plan an. Muss ich jetzt mal anfangen die Hardware 
zusammenzusuchen und zu bestellen.

> Mit ein bisschen Erfahrung hast Du das nach einem Tag laufen, mit ein
> bisschen mehr nach einem halben.

Ich brauche sicher 2...


Aber erstmal kommen noch zwei Reisen und dann im Dezember bzw. Ende 
Dezember habe ich die dann hoffentlich Zeit und hoffentlich bleibt noch 
ein Stündchen übrig um hier davon zu berichten - falls es wen 
interessiert ;)



Daniel A. schrieb:
> Ich nutze auf meinem Server mit Devuan Jessie libvirt+qemu für VMs und
> libvirt-lxc für Container. Container verbrauchen viel weniger Ressourcen
> als VMs,

Das glaub ich dir gerne, aber da habe ich dann wirklich 0,0 Erfahrung 
und wenig Vorstellung davon wie das genauf funktioniert. Denke ich 
versuches mal mit VMs und kann dann ja mal ein paar Projekte als 
Container probieren.


> Was Verschlüsselung angeht kommt es beim optimalen Verfahren doch sehr
> auf das eigene threat model an. Will man sich gegen Polizeirads oder
> Diebstahl verteidigen, macht full disk encryption, und eventuell
> zusätzlich ein steganographic file system Layer Sinn.

Bei mir ist es die permanente Angst, dass mal wer in den Keller 
einsteigt und einfach den Stecker zieht und die Kiste wegnimmt. Das sind 
nur ~2% wirklich persönliche Sachen drauf. Hab zwar einige hundert GB 
Urlaubsfotos, aber das könnte ich verschmerzen. Wichtiger sind mir 
persönliche Dokumente/REchnungen/Briefverkehr...


Was ist denn der Vorteil von diesem "steganographic file system Layer"?
wenn ich Full Disk Encryption mache, was ist der Mehrwert noch einen 
Layer drüber/drunter zu setzen?

> vor Hackerangriffen schützen, und müssen diese vom Server nicht
> weiterverarbeitet werden, kann man stackable filesystem-level encryption
> verwenden, und die Daten nur auf dem Gerät wo sie gebraucht werden
> wieder entschlüsseln.

D.h. man ver/entschlüsselt das auf dem Client und auf dem SHare liegt 
sowas wie ein veschlüsselter Container? Hab ich bisher mit TrueCrypt 
Containern gemacht. War sehr einfach ind er Handhabung, sofern man das 
direkt vom Share übers Neztwerk mounten konnte.


Ich sehe ich hab noch viel zu lesen. Und wie oben schon geschrieben 
erstmal viel Hardware zu kaufen. Danke euch aber schonmal für die 
Anregungen!

vgs

von Daniel A. (daniel-a)


Bewertung
0 lesenswert
nicht lesenswert
Sebastian J. schrieb:
> Was ist denn der Vorteil von diesem "steganographic file system Layer"?
> wenn ich Full Disk Encryption mache, was ist der Mehrwert noch einen
> Layer drüber/drunter zu setzen?

Ein steganographic file system Layer ist sonnvoll, wenn man sich vor 
Polizei raids schützen will; Wenn die Behörden nicht wissen können, dass 
da noch ein Dateisystem versteckt ist, können sie auch kein Passwort zum 
entsperren verlangen.

von Dr. No (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sebastian J. schrieb:
>> Kannst Du machen, noch sicherer wäre es, das ganze System zu
>> verschlüsseln, damit erst gar keiner mitbekommt, was darauf läuft. So
>> habe ich das bei mir eingerichtet.
>
> Was machst du bei unerwarteten Powerdown? Musst du dann vor Ort das PW
> eintippen, oder gibts da noch einen Trick?


Trick nicht, aber dropbear ssh-server wird nach dem Neustart gestartet, 
und dann kann man sich per ssh einloggen und die Passphrase eingeben.
Funktioniert aber nicht per Knopfdruck out-of-the-box, das muss man 
selber einrichten.


> Daniel A. schrieb:
> Ich nutze auf meinem Server mit Devuan Jessie libvirt+qemu für VMs
> und
> libvirt-lxc für Container. Container verbrauchen viel weniger Ressourcen
> als VMs, ich habe momentan eine pfSense VM und ~14 Devuan Container, auf
> denen Webserver, Mailserver, NFS Shares, etc. laufen, meine CPU
> Auslastung ist meistens bei etwa 0.1% oder niedriger, und von meinen 62G
> RAM hat mein Server im moment erst für 7GB verwendung gefunden, die
> Caches inklusive.


Mal abgesehen von der fragwürdigen massiven Überausstattung des Hosts 
sollte man noch etwas erwähnen:
- Es gibt etliche Container-Lösungen für Linux, von denen die meisten 
noch schlanker als LXC sind, z.B. docker, rkt, systemd-nspawn
- Container sind deutlich unsicherer als eine VM. Insbesondere Dienste, 
die nach aussen ins Internet geöffnet sind wie Mailserver und 
insbesondere Webserver würde ich niemals in einem Container auf dem Host 
laufen lassen.
Über mehrere Container in einer VM könnte man diskutieren... Dann aber 
auch mit vernünftiger Absicherung über apparmor, selinux oder Ähnlichem

von Daniel A. (daniel-a)


Bewertung
0 lesenswert
nicht lesenswert
Dr. No schrieb:
> - Es gibt etliche Container-Lösungen für Linux, von denen die meisten
> noch schlanker als LXC sind, z.B. docker, rkt, systemd-nspawn

docker, lxc, libvirt-lxc, etc. sind alles Linux Container (LXC), aber 
libvirt-lxc ist genausowenig lxc (die Software) wie docker lxc ist. Ich 
weiss, es ist verwirrend, dass libvirt-lxc lxc im Namen hat, und dass 
LXC eine Abkürzung eines Konzeptes und der name einer Software 
bestehend aus diversen Tools ist, aber libvirt-lxc hat wirklich nichts 
mit der lxc Software zutun, abgesehen davon, dass beide Linux Container 
verwalten.

von Daniel A. (daniel-a)


Bewertung
0 lesenswert
nicht lesenswert
Dr. No schrieb:
> - Container sind deutlich unsicherer als eine VM. Insbesondere Dienste,
> die nach aussen ins Internet geöffnet sind wie Mailserver und
> insbesondere Webserver würde ich niemals in einem Container auf dem Host
> laufen lassen.

Bei einem Docker Container würde ich da zustimmen, nicht alle Layer von 
Docker images werden so oft aktualisiert wie nötig, und heufig werden 
z.B. ssh keys nicht neu generiert. Andere Container wie libvirt-lxc 
Containern sind zwar immernoch weniger sicher als eine VM, aber es kommt 
selten vor, dass eine Malware mehrere 0days beinhaltet, und um aus einem 
Container auszubrechen reicht ein userspace bug nicht aus, dort braucht 
man zusätzlich einen selteneren Kernel oder Treiber bug. Aber für den 
Notfall habe ich ja noch Backups auf einem separaten PC, der keine 
eingehenden Verbindungen annimmt und für nichts anderes verwendet wird, 
damit verliere ich bei Ransomware angriffen keine Daten.

: Bearbeitet durch User
von Dr. No (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Daniel A. schrieb:
> docker, lxc, libvirt-lxc, etc. sind alles Linux Container (LXC), aber
> libvirt-lxc ist genausowenig lxc (die Software) wie docker lxc ist. Ich
> weiss, es ist verwirrend, dass libvirt-lxc lxc im Namen hat, und dass
> LXC eine Abkürzung eines Konzeptes und der name einer Software
> bestehend aus diversen Tools ist, aber libvirt-lxc hat wirklich nichts
> mit der lxc Software zutun, abgesehen davon, dass beide Linux Container
> verwalten.


Nein, das ist falsch, leider bist Du verwirrt worden...
libvirt ist eine Software (Daemon libvirt-bin, API sowie 
Kommandozeilenwerkzeug virsh) zur Verwaltung und Steuerung der diversen 
Container- und Virtualisierungslösungen, ob dies nun ESX, QEMU/KVM, LXC, 
OpenVZ oder sonstwas ist.
Du nutzt lxc-Container und verwaltest sie mit libvirt. Libvirt-lxc hat 
also sehr wohl etwas mit lxc zu tun, es ist nämlich die Schnittstelle 
zwischen libvirt und lxc.

von Dr. No (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Daniel A. schrieb:
> Bei einem Docker Container würde ich da zustimmen, nicht alle Layer von
> Docker images werden so oft aktualisiert wie nötig, und heufig werden
> z.B. ssh keys nicht neu generiert. Andere Container wie libvirt-lxc
> Containern sind zwar immernoch weniger sicher als eine VM, aber es kommt
> selten vor, dass eine Malware mehrere 0days beinhaltet, und um aus einem
> Container auszubrechen reicht ein userspace bug nicht aus, dort braucht
> man zusätzlich einen selteneren Kernel oder Treiber bug. Aber für den
> Notfall habe ich ja noch Backups auf einem separaten PC, der keine
> eingehenden Verbindungen annimmt und für nichts anderes verwendet wird,
> damit verliere ich bei Ransomware angriffen keine Daten.


Nein, das entscheidende Merkmal ist, dass Container auf dem gleichen 
Kernel wie das Hostsystem laufen und nur durch Namespaces, CGroups, etc. 
abgegrenzt sind. Virtuelle Maschinen laufen aber komplett separiert. Und 
aus eben diesem Grund ist die Sicherheit prinzipbedingt deutlich 
geringer und muss dann eben durch weitere Massnahmen flankiert werden.

von Jan H. (j_hansen)


Bewertung
0 lesenswert
nicht lesenswert
Soweit ich weiß, ist RAID5 bei BTRFS immer noch nicht stabil. Das macht 
aber auch mit anderen Technologien immer wieder Probleme.
Lieber eine HDD mehr kaufen, und mit RAID1(0) sorgenfrei leben.

von Daniel A. (daniel-a)


Bewertung
0 lesenswert
nicht lesenswert
Dr. No schrieb:
> Du nutzt lxc-Container und verwaltest sie mit libvirt. Libvirt-lxc hat
> also sehr wohl etwas mit lxc zu tun, es ist nämlich die Schnittstelle
> zwischen libvirt und lxc.

Das mag ja bei z.B. qemu und einigen anderen Dingen der Fall sein, aber 
es trifft nicht auf libvirt-lxc zu. Bei libvirt+qemu muss man qemu 
installieren, nicht so bei libvirt-lxc. Ich habe die lxc und lxd Packete 
nicht installiert, und es gibt auch keine Pakete für lxc libraries von 
denen das lxc packet abhängt, somit kann libvirt auch keine derartige 
library verwenden. Auch lxc-ls nach der lxc installation zeigt die 
libvirt-lxc container nicht an. Hier ein Auszug aus meinem Terminal, auf 
die Erklärung wie dass mit deiner Aussage zusammenpasst bin ich sehr 
gespannt:
1
root@mouse:~# virsh -c lxc:/// list --title
2
 Id    Name                           State      Title               
3
----------------------------------------------------------------------------------
4
 3432  beaver                         running    Build Server        
5
 4279  butterfly                      running    Tor Gateway + DNS   
6
 5787  snake                          running    APT-Mirror & TOR Webserver
7
 7321  pxeenv                         running    LXC Container for administrating PXE Environment
8
 8491  dog                            running    tftp Server vor PXE Boot
9
 10648 duck                           running    DMZ DNS Server      
10
 12871 rat                            running    SSH Backdoor        
11
 12923 kiwi                           running                        
12
 13785 zebra                          running    NFS, WebDav & SMB Server
13
 14983 kangaroo                       running    Public DNS          
14
 15772 fox                            running    Logging server      
15
 17167 frog                           running    Webserver           
16
 18897 pelican                        running    Mail Server         
17
 19874 leopard                        running    Print Server        
18
19
root@mouse:~# apt-get install lxc
20
Reading package lists... Done
21
Building dependency tree       
22
Reading state information... Done
23
Suggested packages:
24
  lua5.2
25
The following NEW packages will be installed:
26
  lxc
27
0 upgraded, 1 newly installed, 0 to remove and 38 not upgraded.
28
Need to get 0 B/625 kB of archives.
29
After this operation, 2,669 kB of additional disk space will be used.
30
Selecting previously unselected package lxc.
31
(Reading database ... 951362 files and directories currently installed.)
32
Preparing to unpack .../lxc_1.0.6-6+deb8u6_amd64.deb ...
33
Unpacking lxc (1:1.0.6-6+deb8u6) ...
34
Processing triggers for man-db (2.7.0.2-5) ...
35
Setting up lxc (1:1.0.6-6+deb8u6) ...
36
Processing triggers for libc-bin (2.19-18+deb8u10) ...
37
root@mouse:~# lxc-ls
38
root@mouse:~# apt-get remove lxc
39
Reading package lists... Done
40
Building dependency tree       
41
Reading state information... Done
42
The following packages will be REMOVED:
43
  lxc
44
0 upgraded, 0 newly installed, 1 to remove and 38 not upgraded.
45
After this operation, 2,669 kB disk space will be freed.
46
Do you want to continue? [Y/n] 
47
(Reading database ... 951761 files and directories currently installed.)
48
Removing lxc (1:1.0.6-6+deb8u6) ...
49
Processing triggers for man-db (2.7.0.2-5) ...
50
Processing triggers for libc-bin (2.19-18+deb8u10) ...
51
root@mouse:~# apt-cache depends lxc
52
lxc
53
  Depends: init-system-helpers
54
  Depends: libapparmor1
55
  Depends: libc6
56
  Depends: libcap2
57
  Depends: libseccomp2
58
  Depends: libselinux1
59
  Depends: python3
60
  Depends: python3
61
  PreDepends: multiarch-support
62
  Suggests: lua5.2
63
  Recommends: debootstrap
64
  Recommends: openssl
65
  Recommends: rsync
66
  Conflicts: <lxc-dev>
67
  Replaces: <lxc-dev>

von Daniel A. (daniel-a)


Bewertung
0 lesenswert
nicht lesenswert
Dr. No schrieb:
> Nein, das entscheidende Merkmal ist, dass Container auf dem gleichen
> Kernel wie das Hostsystem laufen und nur durch Namespaces, CGroups, etc.
> abgegrenzt sind. Virtuelle Maschinen laufen aber komplett separiert. Und
> aus eben diesem Grund ist die Sicherheit prinzipbedingt deutlich
> geringer und muss dann eben durch weitere Massnahmen flankiert werden.

Schon klar, dennoch gab es auch schon bei VMs Ausbrüche. Aus einem 
Namespace kommt man eventuell etwas leichter, aber auch nicht ohne einen 
0day heraus,  ein häcker müsste also ersteinmal hineinkommen und einen 
0day für den Kernel haben um aus dem Namespace herauszukommen. Ich halte 
das einfach für sehr unwahrscheinlich.

von Dr. No (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jan H. schrieb:
> Soweit ich weiß, ist RAID5 bei BTRFS immer noch nicht stabil.

Das ist korrekt, Probleme kann das bei einem Stromausfall machen. Erst 
kürzlich wurde ein Patch dafür eingereicht.

https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg66472.html

Daher sollte man das noch nicht verwenden. Verwenden kann man die 
Kernel-Raid-Funktionen, verwaltet werden die mit mdadm. Auf das RAID 
dann ein Dateisystem nach Belieben.

von jz23 (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Ich verstehe ehrlich gesagt nicht, warum immer alle Leute RAID auf ihren 
NAS wollen. Es hilft nicht gegen Diebstahl, Überspannung, Viren, eigene 
Dummheit, sondern ausschließlich gegen Festplattendefekt. Mit anderen 
Worten: Ein Backup braucht man sowieso. Wenn ich das habe, kann ich mir 
aber auch gleich das RAID sparen und in mehr Speicherkapazität (Oder 
mehr offline-Backups) investieren - da werde ich wohl mehr von haben auf 
Dauer. RAID ist ja eigentlich nur sinnvoll, wenn eben 100% Verfügbarkeit 
wichtig sind. Prinzipiell kann man aber bei einem Festplattencrash im 
NAS halt auch mal einen Tag verzichten, dafür den Rest der Zeit mehr 
Geld im Portemonaie oder mehr Kapazität im NAS genießen - JustMy2Cents.

von Dr. No (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Daniel A. schrieb:
> Hier ein Auszug aus meinem Terminal, auf
> die Erklärung wie dass mit deiner Aussage zusammenpasst bin ich sehr
> gespannt:


Ganz einfach: Libivrt hat einen eigenen Treiber für LXC, dafür braucht 
es natürlich die Tools aus dem LXC-Paket nicht. Steht aber alles in der 
Doku:
"The libvirt LXC driver has no dependency on the LXC userspace tools"

Ich empfehle Dir dringend, Dich mit den eingesetzten Techniken 
wenigstens ein bisschen auseinanderzusetzen, bevor Du solch sachlich 
falsche Aussagen machst. Andere könnten das glauben...

Zum Lesen z.B.:
https://libvirt.org/drvlxc.html

von Daniel A. (daniel-a)


Bewertung
0 lesenswert
nicht lesenswert
Dr. No schrieb:
> Ganz einfach: Libivrt hat einen eigenen Treiber für LXC, dafür braucht
> es natürlich die Tools aus dem LXC-Paket nicht. Steht aber alles in der
> Doku:
> "The libvirt LXC driver has no dependency on the LXC userspace tools"
>
> Ich empfehle Dir dringend, Dich mit den eingesetzten Techniken
> wenigstens ein bisschen auseinanderzusetzen, bevor Du solch sachlich
> falsche Aussagen machst. Andere könnten das glauben...

Aber das bestätigt doch ausschliesslich meine aussagen, aber nicht 
deine!
Linux Container (LXC), also das Konzept, sind Container auf Linux, und 
das sind eigentlich nur Namespaces und CGroups.
lxc (Die Software), oder hier als LXC Tools bezeichnet, sind Tools um 
Linux Container zu erstellen. Aber docker und libvirt-lxc sind ebenfalls 
tools um Linux Container zu erstellen. Dein oberes Zitat explizit 
bestätigt, dass libvirts LXC Treiber nichts mit den LXC Tools zutun hat, 
was von Anfang an meine Aussage war. Meine Aussagen von oben sind mit 
dem Zitat absolut konsistent:

Daniel A. schrieb:
> docker, lxc, libvirt-lxc, etc. sind alles Linux Container (LXC), aber
> libvirt-lxc ist genausowenig lxc (die Software) wie docker lxc ist. Ich
> weiss, es ist verwirrend, dass libvirt-lxc lxc im Namen hat, und dass
> LXC eine Abkürzung eines Konzeptes und der name einer Software
> bestehend aus diversen Tools ist, aber libvirt-lxc hat wirklich nichts
> mit der lxc Software zutun, abgesehen davon, dass beide Linux Container
> verwalten.

Deine aussage war jedoch:

Dr. No schrieb:
> Du nutzt lxc-Container und verwaltest sie mit libvirt. Libvirt-lxc hat
> also sehr wohl etwas mit lxc zu tun, es ist nämlich die Schnittstelle
> zwischen libvirt und lxc.

Gratulation, du hast dich selbst wiederlegt.

von Seb A. (aslmx)


Bewertung
0 lesenswert
nicht lesenswert
jz23 schrieb:
> Ich verstehe ehrlich gesagt nicht, warum immer alle Leute RAID auf ihren
> NAS wollen. Es hilft nicht gegen Diebstahl, Überspannung, Viren, eigene
> Dummheit, sondern ausschließlich gegen Festplattendefekt.

Persönliche Statistik in knapp 7 Jahren NAS Nutzung:

Diebstähle: 0
Festplattenausfälle: 1

Klar braucht man noch ein Backup. Auch wegen Feuer, Wasser und sonstigen 
unvorhergesehenen Naturkatastrophen wo mir das RAID nicht hilft...

> JustMy2Cents.

So isses. Aber trotzdem danke für deine Meinung zum Thema!

Mir geht es besser mit RAID. Vielleicht ändere ich meine Meinung noch...

Zusätzliches Backup soll ja das Alte NAS werden, sobald das einmal 
zurück gesetzt wurde.al schauen in welchem Raum ich das dann 
unterbringe, damit es nicht gleich daneben steht (von wegen Feuer und 
Diebstahl - hilft nicht bei Feuer oder Dieben mit viel Zeit ;))

von Axel S. (a-za-z0-9)


Bewertung
-1 lesenswert
nicht lesenswert
jz23 schrieb:
> Ich verstehe ehrlich gesagt nicht, warum immer alle Leute RAID auf ihren
> NAS wollen. Es hilft nicht gegen Diebstahl, Überspannung, Viren, eigene
> Dummheit, sondern ausschließlich gegen Festplattendefekt. Mit anderen
> Worten: Ein Backup braucht man sowieso. Wenn ich das habe, kann ich mir
> aber auch gleich das RAID sparen ...

Das ist gar kein Argument. Genauso könnte man gegen Krankenwagen 
argumentieren: "Ich verstehe nicht, warum alle Leute wollen, daß 
Krankenhäuser Krankenwagen haben. Die kommen ja nur dahin, wo es 
fahrbare Wege gibt. Wenn ich im Gebirge verunglücke oder im Meer am 
Ertrinken bin, hilft mir ein Krankenwagen gar nicht. Da brauche ich 
einen Lebensretter. Und wenn ich den habe, dann ist der Krankenwagen 
unnütz ..."

Trotzdem retten Krankenwagen nachweislich Leben. Bei einem RAID ist es 
ganz ähnlich. Das RAID erlaubt mir überhaupt erst, viel Speicher am 
Stück zu haben, ohne daß mir ein Plattenausfall gleich Daten vernichtet. 
Das Backup macht das RAID nicht unnütz, es ist eher anders herum: ohne 
RAID könnte ich gar nicht die Daten speichern, die ich nachher 
(vielleicht mal) in ein Backup tun will.

Dazu kommt noch: nicht alle Daten, die man auf ein RAID tut, sind auch 
backupwürdig. Ich habe hier z.B. ein größeres Multimedia-Archiv. Musik, 
Filme, Urlaubsfotos, Bücher, gescannte Zeitschriften etc. Nur ein Teil 
davon ist backupwürdig. Musik und Filme sind im Zweifel 
wiederbeschaffbar, Urlaubsbilder eher nicht. Entsprechend landet nur ein 
Teil davon auch im Backup. Konkrete Zahlen: mein großes RAID hat 22TB 
(6x 4TB im RAID-6), Davon sind 10TB belegt. Im Backup sind 1.8TB, was 4 
Generationen aus dem Datenbereich und um die 100 Generationen von /home, 
/var (Mail!) und der Betriebssystem-Installation der diversen Rechner 
ist. Das Backup verwendet Hardlinks für alte Versionen. Eine Datei, die 
sich nicht ändert, belegt für 100 Generationen also nur unwesentlich 
mehr Platz als für eine.

Und schließlich noch ein letzter Punkt: worauf willst du denn bitte 
dein Backup machen? Bei wirklich großen Datenmengen? Doch am Ende auch 
wieder auf einer Festplatte. Bzw. besser auf einem RAID, sobald es 
größer wird als eine Einzelplatte. Bandlaufwerke mit adäquater Kapazität 
und Geschwindigkeit sind für den Privatanwender unerschwinglich. Wenn du 
deine offline-Backups bei Amazon oder sonstwo machst, was glaubst du, wo 
deine Daten landen? Auf einem RAID natürlich.

von dockstar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Ich verstehe ehrlich gesagt nicht, warum immer alle Leute RAID auf ihren
> NAS wollen.

Ich auch nicht.
Ungespiegelte Platten gehen nicht kaputt.

I.S.S.O.

Lieber mal hd1 auf hd2 spiegeln und dann hd2 weitermachen lassen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.