Ja Heimgebrauch. Filme streamen + encodieren (mini, JDownloader, TS Server (max 8 User gleichzeitig, eher 2 bis 4), Im Prinzip ein LUXX-NAS. Vielleicht irgendwann mal ne Virtuelle Maschine zu spielen (also nicht zocken, sondern einfach nur rumspielen).
Das ist kein Ding. Das Thema Filme streamen und ARC / L2ARC war vor ein paar Seiten mal dran....Würde mich wundern, wenn du den ARC im RAM mit sowas stark füllst.
Ich mach ähnliches auf meinem mit 16GB (ownCloud, PyLoad, Streaming, Jabber, ....). Da das ja alles nicht wahnsinnig viel I/O verursacht, ist das schon ausreichend.
Ich mach ähnliches auf meinem mit 16GB (ownCloud, PyLoad, Streaming, Jabber, ....). Da das ja alles nicht wahnsinnig viel I/O verursacht, ist das schon ausreichend.
Zuletzt bearbeitet:
Digi-Quick
Urgestein
- Mitglied seit
- 02.09.2009
- Beiträge
- 7.082
Das Märchen mit den 1GB RAM / TB Massenspeicher kursiert nun schon eine Ewigkeit, dabei ist das nur die Halbe Wahrheit!
Man benötigt ca. 1GB RAM / TB Massenspeicher NUR DANN, wenn man Deduplikation verwendet!!!!
Ansonsten Gilt: ZFS läuft ab 2 GB RAM.
Mehr RAM = Mehr ARC/CACHE >>> bessere Performance in Anwendungsszenarien, die von Cache-Hits profitieren - insbesondere wiederholtes Lesen von Daten. Die Gesamtperformance profitiert bei Single User Zugriff nicht in dem Maße vom grösserem Speicher, wie man es eigentlich erwarten würde. Bei Multiuserzugriff ist die Gesamtperformance mit grösserem Speicher besser, da die Festplattenzugriffe besser optimiert werden können.
Ich habe ein NAS mit 19x8TB im Raidz3 = 128 TB Nutzkapazität und 16 GB RAM, reicht!
Man benötigt ca. 1GB RAM / TB Massenspeicher NUR DANN, wenn man Deduplikation verwendet!!!!
Ansonsten Gilt: ZFS läuft ab 2 GB RAM.
Mehr RAM = Mehr ARC/CACHE >>> bessere Performance in Anwendungsszenarien, die von Cache-Hits profitieren - insbesondere wiederholtes Lesen von Daten. Die Gesamtperformance profitiert bei Single User Zugriff nicht in dem Maße vom grösserem Speicher, wie man es eigentlich erwarten würde. Bei Multiuserzugriff ist die Gesamtperformance mit grösserem Speicher besser, da die Festplattenzugriffe besser optimiert werden können.
Ich habe ein NAS mit 19x8TB im Raidz3 = 128 TB Nutzkapazität und 16 GB RAM, reicht!
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 703
Nochmal ne Frage zu der ACL bzw Rechten:
Owner und Root haben ja immer Vollzugriff, zumindest hab ich das so verstanden dass das die "Besonderheit" am Solaris SMB Server ist.
Ist das auch immer noch so wenn ich die Rechte mit ACL bei den Shares eingrenze? Sprich wenn ich statt Everyone=full access hier everyone=modify setze? Oder gilt das mit Vollzugriff bei Root und Owner nur bei Folder ACL ?
Modify bedeutet ja man kann alles außer den Besitzer wechseln und Rechte ändern. Heißt Rechte ändern jetzt dass man gar nix verändern kann? Oder nur dass man bestehende Rechte net abändern kann? Sprich kann ich zusätzliche ACL Einträge noch dranhängen oder ist die ACL quasi komplett "schreibgeschützt" wenn ich nur Modify Rechte habe und weder Owner noch Root bin?
Gibt es ansonsten irgendeine möglichkeit wie man unterbinden kann dass der User bei Ordnern und Dateien die er anlegt selber die Rechte ändern kann? Weil er hat als Owner ja immer Full Access.
Owner und Root haben ja immer Vollzugriff, zumindest hab ich das so verstanden dass das die "Besonderheit" am Solaris SMB Server ist.
Ist das auch immer noch so wenn ich die Rechte mit ACL bei den Shares eingrenze? Sprich wenn ich statt Everyone=full access hier everyone=modify setze? Oder gilt das mit Vollzugriff bei Root und Owner nur bei Folder ACL ?
Modify bedeutet ja man kann alles außer den Besitzer wechseln und Rechte ändern. Heißt Rechte ändern jetzt dass man gar nix verändern kann? Oder nur dass man bestehende Rechte net abändern kann? Sprich kann ich zusätzliche ACL Einträge noch dranhängen oder ist die ACL quasi komplett "schreibgeschützt" wenn ich nur Modify Rechte habe und weder Owner noch Root bin?
Gibt es ansonsten irgendeine möglichkeit wie man unterbinden kann dass der User bei Ordnern und Dateien die er anlegt selber die Rechte ändern kann? Weil er hat als Owner ja immer Full Access.
Zuletzt bearbeitet:
Das hat nichts mit dem SMB Server zu tun sondern liegt an Unix/ZFS
Modify darf Dateien ändern/löschen aber keine ACL verändern
Dafür gibts bei Solaris die ZFS Eigenschaft aclmode.
Damit kann man z.B. verhindern, dass der Erzeuger einer Datei auch Eigentümer wird.
https://docs.oracle.com/cd/E19120-01/open.solaris/817-2271/gbaaz/index.html
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 703
Hab herausgefunden dass es wesentlich eleganter und einfacher über ACL on Shares geht. Statt Everyone=Full, habe ich root=Full und Everyone=modify gesetz. Nun kann keiner mehr Rechte ändern außer root, sogar der Besitzer nicht.
Was hat es eigentlich in napp-it mit den Gruppen "administrators" "Backup operators" "power user" auf sich. Berechtigungen für diese Gruppen lassen sich über napp-it gar nicht setzen, weil sie nicht auftauchen in der Auswahlliste
Was hat es eigentlich in napp-it mit den Gruppen "administrators" "Backup operators" "power user" auf sich. Berechtigungen für diese Gruppen lassen sich über napp-it gar nicht setzen, weil sie nicht auftauchen in der Auswahlliste
Zuletzt bearbeitet:
OmniOS auf HP Z210
Liebe OmniOS-ler,
ich habe am Wochenende versucht auf einer ausrangierten HP Z210 mit XEON E3-1270 3.4GHz und 16GB DDR3/ECC-RAM OmniOS_R151014_LTS zu installieren. Ich dachte eigentlich, daß die Basis ganz gut geeignet ist - mußte dann aber feststellen, daß OmniOS den Chipsatz (Intel® C206) wohl nicht vollständig unterstützt. Sobald der SATA-On-board Kontroller im BIOS auf AHCI/RAID konfiguriert ist, erkennt OmniOS keine einzige Festplatte :-(
Ich habe dann versucht vor der OmniOS-Installation mit
update_drv -a -i 'pci8086' ahci
den korrekten Treiber zu laden, was aber auch fehlschlug. Sobald im BIOS der STAT-Modus wieder auf IDE steht, werden die Platten wieder erkannt. Hier nun meine Fragen:
1. Gibt's einen Weg, den Chipset-Treiber im AHCI-Mode zu laden?
2. Wenn nicht, welche Unterschiede ergeben sich unter OmniOS zwischen IDE und AHCI-Modus?
Bin für alle Tips dankbar.
Lampos
Liebe OmniOS-ler,
ich habe am Wochenende versucht auf einer ausrangierten HP Z210 mit XEON E3-1270 3.4GHz und 16GB DDR3/ECC-RAM OmniOS_R151014_LTS zu installieren. Ich dachte eigentlich, daß die Basis ganz gut geeignet ist - mußte dann aber feststellen, daß OmniOS den Chipsatz (Intel® C206) wohl nicht vollständig unterstützt. Sobald der SATA-On-board Kontroller im BIOS auf AHCI/RAID konfiguriert ist, erkennt OmniOS keine einzige Festplatte :-(
Ich habe dann versucht vor der OmniOS-Installation mit
update_drv -a -i 'pci8086' ahci
den korrekten Treiber zu laden, was aber auch fehlschlug. Sobald im BIOS der STAT-Modus wieder auf IDE steht, werden die Platten wieder erkannt. Hier nun meine Fragen:
1. Gibt's einen Weg, den Chipset-Treiber im AHCI-Mode zu laden?
2. Wenn nicht, welche Unterschiede ergeben sich unter OmniOS zwischen IDE und AHCI-Modus?
Bin für alle Tips dankbar.
Lampos
Ein Mainboard kennt üblicherweise 3 Modi für Sata
- IDE
- AHCI
- Raid
wenn im Bios als Modus AHCI/Raid steht, dann ist wohl Onboard Raid gemeint.
Das geht nur mit den Windows Treibern. Wenn es keinen eigenen AHCI Modus gibt,
(war in älteren Boards oft problematisch) nach einem neueren Bios suchen, sonst IDE nehmen.
OmniOS unterstützt IDE und AHCI (empfohlen).
AHCI ist besser da schneller und Hotplug tauglich,.
- IDE
- AHCI
- Raid
wenn im Bios als Modus AHCI/Raid steht, dann ist wohl Onboard Raid gemeint.
Das geht nur mit den Windows Treibern. Wenn es keinen eigenen AHCI Modus gibt,
(war in älteren Boards oft problematisch) nach einem neueren Bios suchen, sonst IDE nehmen.
OmniOS unterstützt IDE und AHCI (empfohlen).
AHCI ist besser da schneller und Hotplug tauglich,.
UPDATE - Das BIOS-Update bringt nichts. Nachwievor ist die Auswahl auf "IDE" oder "AHCI/RAID" beschränkt. Also wird wohl der M1015 zum Einsatz kommen und die Bootplatten im IDE-Mode betrieben. Ich denke, das ist der best Kompromiß. Danke nochmal für die Hilfe.
BTW, gilt die Aussage bezüglich Hotplug für alle im AHCI.Mode betriebenen Controller/Platte? Und wenn ja, wie nehme ich dann im laufenden Betrieb einen Plattenwechsel vor?
Sata/ AHCI ist von der Konzeption her Hotplugfähig,
das Board muss es aber unterstützen - bei manchem Bios kann man das aktivieren/deaktivieren
und der Treiber oder das OS müssen das auch unterstützen.
Bei OmniOS macht das der Treiber nicht per default,
sollte aber mit der folgenden Einstellung in /etc/system nach Neustart gehen
Ich habe das auch in mein OS Tuningpanel unter napp-it integriert.
set sata:sata_auto_online=1
Die aktuellen LSI HBA (IBM 1015 etc) können Hotplug alle problemlos.
Da kann man im laufenden Betrieb Platten einfach an oder abstecken -
vorrausgesetzt man hat eine Backplane oder Wechselrahmen die das
elektrisch sauber ermöglicht.
Zuletzt bearbeitet:
Digi-Quick
Urgestein
- Mitglied seit
- 02.09.2009
- Beiträge
- 7.082
Jein, Hauptsächlich muss der Treiber das untertützen - da im laufendem Betrieb ein "Re-Init" des betreffenden Ports stattfinden muß. Ansonsten wird u.U, die neu angeschlossene Platte mit den Parametern (Grösse, Dateisystem, Datenstruktur) der vorher angeschlossenen Platte angesprochen = Datensalat.
Eine Backplane/Wechselrahmen ist nicht Vorraussetzung, da der SATA-(Strom)Anschluss bereits für Hot-Plug ausgelegt ist. (Stromanschluss zuerst abziehen / zuletzt stecken)
Stangensellerie
Experte
- Mitglied seit
- 10.10.2015
- Beiträge
- 115
Wenn man einen Server von der Stange hat, wird das schwer mit dem einzeln abziehen. Beispielsweise bei meinem poppeligen Dell T110ii mit H200 hängt am Gegenpart des SFF-8087 auch gleich die Stromversorgung für die Datenträger mit dran. Ich wage auch zu bezweifeln, daß die Spannungsversorgung ein An-/Abstecken in jedem Fall klaglos mitmacht. Es wird schon seinen Grund haben, weshalb meines Wissens Backplanes da ihre eigene Absicherung mitbringen und die Versorgungszuleitungen auch etwas dicker ausfallen. Auch wenn der LSI-HBA das zwar prinzipiell kann, ist Hot-Plug für meinen Server zumindest Bios-seitig nicht vorgesehen.
ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 527
Der C206 samt AHCI ist ja nun schon gut abgehangen und wird von Illumos einwandfrei unterstützt.
Mindestens hier gibt's jemanden, der nen Z210 mit Smartos (Illumos Kern) betreibt: https://wiki.smartos.org/pages/viewpage.action?pageId=755673
Ich würde da mal noch nicht die Flinte ins Korn werfen.
cu
layerbreak
Enthusiast
- Mitglied seit
- 30.12.2010
- Beiträge
- 590
Ich möchte gerne bei meinen Snapshots aufräumen.
Kann ich bei Replicate-Jobs, die Snaps der Quelle und der Snaps der Source gefahrlos löschen und der Datenbestand bleibt auf beiden Servern erhalten?
Kann ich bei den Snap-Jobs auch die Snapshots löschen ohne den Datenbestand zu gefährden? Klar ist mir schon, dass ich dann nicht mehr auf "vorige Version" zurück kann.
Kann ich bei Replicate-Jobs, die Snaps der Quelle und der Snaps der Source gefahrlos löschen und der Datenbestand bleibt auf beiden Servern erhalten?
Kann ich bei den Snap-Jobs auch die Snapshots löschen ohne den Datenbestand zu gefährden? Klar ist mir schon, dass ich dann nicht mehr auf "vorige Version" zurück kann.
ReplikationsSnaps
da muss man mindestens das neueste Pärchen behalten oder die inkrementelle Replikation läuft nicht mehr.
Normale Snaps
kann man löschen wenn man sie nicht mehr braucht.
layerbreak
Enthusiast
- Mitglied seit
- 30.12.2010
- Beiträge
- 590
Danke @gea für die schnelle Antwort.
Wenn ich bei den RepliSnaps auch das Pärchen lösche, wird dann nicht ein neues Paar angelegt und die Dateien auf dem Zielserver einfach überschrieben? Praktisch eine erste Vollsicherung bevor wieder später dann inkrementell gesichert wird.
Nein dann gibts eine Fehlermeldung.
Um eine neue Vollreplikation zu starten muss vorher das Zieldateisystem gelöscht oder umbenannt werden -
das passiert sicherheitshalber nicht automatisch.
Ich kämpfe mal wieder mit ACLs im Zusammenhang mit OmniOS, ZFS und Domaine (Windows Server 2012 R2).
Ich möchte folgendes Ziel erreichen: Es gibt einen Home Share auf der Storage mit jeweils Shares für die Nutzer. Diese Shares sollen dann automatisch bei Login auf den Clients (zunächst Windows) gemountet werde, z.B. nach H:.
Folgendes habe ich getan:
Filesysteme tank_data/Homes, tankt_data/Homes/user1, tank_data/Homes/user2 angelegt. SMB Freigaben nur für user1 und user2 erzeugt.
Unter Windows Server habe ich mich dann als root auf die Freigabe user1 angemeldet. Dann habe ich unter Eigenschaften->Sicherheit den Nutzer 'jeder' entfernt, und den Domainenuser user1 hinzugefügt. Dem user1 habe ich dann die Berechtigung 'Vollzugriff' entzogen und die erweiterten Berechtigungen 'Berechtigungen ändern' und 'Besitz übernehmen' entzogen, damit er keine Veränderungen an dem share vornehmen kann. Anschließend habe ich im Profil des Domainenuser 'user1' den Basisordner auf H: und \\OmniOS\user1 eingestellt.
Alles scheint zu funktionieren. Nun meine Frage:
Ist das der richtige Weg was ich da mache oder ist das Unsinn und es geht viel einfacher?
Wie verhält sich dann Mac OS? Wenn ich mich als Domainennutzer 'user' anmelde, kann ich dann mit gleichen Rechten auf den Share smb://omnios/user1 zugreifen?
Ich möchte folgendes Ziel erreichen: Es gibt einen Home Share auf der Storage mit jeweils Shares für die Nutzer. Diese Shares sollen dann automatisch bei Login auf den Clients (zunächst Windows) gemountet werde, z.B. nach H:.
Folgendes habe ich getan:
Filesysteme tank_data/Homes, tankt_data/Homes/user1, tank_data/Homes/user2 angelegt. SMB Freigaben nur für user1 und user2 erzeugt.
Unter Windows Server habe ich mich dann als root auf die Freigabe user1 angemeldet. Dann habe ich unter Eigenschaften->Sicherheit den Nutzer 'jeder' entfernt, und den Domainenuser user1 hinzugefügt. Dem user1 habe ich dann die Berechtigung 'Vollzugriff' entzogen und die erweiterten Berechtigungen 'Berechtigungen ändern' und 'Besitz übernehmen' entzogen, damit er keine Veränderungen an dem share vornehmen kann. Anschließend habe ich im Profil des Domainenuser 'user1' den Basisordner auf H: und \\OmniOS\user1 eingestellt.
Alles scheint zu funktionieren. Nun meine Frage:
Ist das der richtige Weg was ich da mache oder ist das Unsinn und es geht viel einfacher?
Wie verhält sich dann Mac OS? Wenn ich mich als Domainennutzer 'user' anmelde, kann ich dann mit gleichen Rechten auf den Share smb://omnios/user1 zugreifen?
Zuletzt bearbeitet:
Prinzipiell alles in Ordnung.
Man muss aber darauf achten, wem der Ordner gehört.
Wenn z.B. user1 einen Ordner angelegt hat, und man ihm Berechtigungen entzieht, so kann er zwar nicht mehr direkt darauf zugreifen sich als Eigentümer die Rechte wieder holen.
Also root zum Eigentümer machen oder als root die Struktur anlegen und eventuell per aclmode dafür sorgen dass neue Ordner nicht dem gehören der sie anlegt sondern dass der Eigentümer vererbt wird.
OSX
Die Rechte werden ja von Solaris gemanaget. Auch wenn OSX mit den Windows ACL nicht umgehen kann, beachtet werden sie sehr wohl. Bei der Anmeldung user1@domain.de nehmen, damit klar ist, wo der Benutzer hinterlegt ist (Sonst wird je nach Einstellung versucht gegen einen lokalen Solaris user1 zu authentifizieren - sofern OSX/Windows nicht auch in der Domäne sind).
Man muss aber darauf achten, wem der Ordner gehört.
Wenn z.B. user1 einen Ordner angelegt hat, und man ihm Berechtigungen entzieht, so kann er zwar nicht mehr direkt darauf zugreifen sich als Eigentümer die Rechte wieder holen.
Also root zum Eigentümer machen oder als root die Struktur anlegen und eventuell per aclmode dafür sorgen dass neue Ordner nicht dem gehören der sie anlegt sondern dass der Eigentümer vererbt wird.
OSX
Die Rechte werden ja von Solaris gemanaget. Auch wenn OSX mit den Windows ACL nicht umgehen kann, beachtet werden sie sehr wohl. Bei der Anmeldung user1@domain.de nehmen, damit klar ist, wo der Benutzer hinterlegt ist (Sonst wird je nach Einstellung versucht gegen einen lokalen Solaris user1 zu authentifizieren - sofern OSX/Windows nicht auch in der Domäne sind).
Klasse gea, vielen Dank!
Ich habe vor meine OSX Systeme eh in die Domaine zu nehmen, würdest Du davon abraten und eher über user1@domain.de den mount authentifizieren?
Ich habe vor meine OSX Systeme eh in die Domaine zu nehmen, würdest Du davon abraten und eher über user1@domain.de den mount authentifizieren?
Zuletzt bearbeitet:
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 703
Setze doch einfach Share acl jeder=modify und Root=Full. Das ist doch viel näherliegend. Habe ich so gemacht.
Würde mit den Besitzern nix ändern so kann man später immer nochmal nachvollziehen wer was erstellt hat
Würde mit den Besitzern nix ändern so kann man später immer nochmal nachvollziehen wer was erstellt hat
Zuletzt bearbeitet:
Kann man machen wenn man eine lokale Anmeldung mit Domainaccount haben möchte und damit auch gleichzeitig der Zugriff auf mehrere Server/ Shares freigeschaltet werden soll.
Ich habe bisher nicht gemacht, einerseits weil OSX da auch mal Probleme hatte und es eher alles komplizierter macht.
Zuletzt bearbeitet:
fdiskc2000
Enthusiast
- Mitglied seit
- 30.05.2007
- Beiträge
- 2.230
Leute ich habe gerade ein Brett vorm Kopf, vll. ist es auch die Uhrzeit: ich habe Nappit auf dem ESXI installiert, einen Pool mit 3x4TB als Raidz erstellt und ein ZFS-Filesystem. NFS ist aktiviert und beim Einbinden im ESXI scheint alles tutti. Aber ich darf anscheinend nicht schreiben.
Weder eine Virtuelle Festplatte dort erzeugen, noch etwas mit dem Fileexplorer hochladen. Was habe ich übersehen?
Weder eine Virtuelle Festplatte dort erzeugen, noch etwas mit dem Fileexplorer hochladen. Was habe ich übersehen?
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 703
Habe ein Problem mit Serviio und zwar findet er meine Videos nicht mehr. Ich glaube es liegt daran dass der user serviio keine Leserechte hat.
Ich habe bei meinen SMB Freigaben everybody=modify gelöscht und durch eine eigene SMB Gruppe ersetzt. Habe eine Gruppe die heißt mediausr. Da drin sind alle Nutzer die Zugriff auf die Mediendateien haben sollen. Habe ich dadurch jetzt serviio ausgesperrt?
serviio lässt sich aber nicht in die gruppe mediausr aufnehmen. serviio ist ja auch ein lokaler useraccount der kein SMB Zugriff benötigt, liegt es daran?
Ich habe bei meinen SMB Freigaben everybody=modify gelöscht und durch eine eigene SMB Gruppe ersetzt. Habe eine Gruppe die heißt mediausr. Da drin sind alle Nutzer die Zugriff auf die Mediendateien haben sollen. Habe ich dadurch jetzt serviio ausgesperrt?
serviio lässt sich aber nicht in die gruppe mediausr aufnehmen. serviio ist ja auch ein lokaler useraccount der kein SMB Zugriff benötigt, liegt es daran?
Zuletzt bearbeitet:
Die SMB Gruppen von Solaris werden ausschliesslich von SMB genutzt und werden extra verwaltet um kompatibel zu Windows zu sein (Linux/Unix Gruppen sind das nicht). Ein Solaris Windows User Accout ist aber einfach ein Unix Account bei dem zusätzlich das Passwort im Windows Format gespeichert wird und bei dem zusätzlich zu der uid/gid Unixkennung eine Windows Security ID als erweitertes ZFS Attribut für SMB benutzt wird.
Rechte auf Dateien werden dann über ACL geregelt und das ist unabängig davon wie man darauf zugreift. Wenn ein Programm also auf Dateien zugreifen soll, so muss der dazugehörende Prozess (oder jeder) Zugriff haben.
Rechte auf Dateien werden dann über ACL geregelt und das ist unabängig davon wie man darauf zugreift. Wenn ein Programm also auf Dateien zugreifen soll, so muss der dazugehörende Prozess (oder jeder) Zugriff haben.
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 703
Okay also muss ich zwangsweise "jeder" Zugriff gestatten sonst kann der unix user "serviio" nicht auf meine Mediendaten zugreifen. Allerdings hätte ich über SMB halt gern dass eben nicht jeder drauf zugreifen kann sondern nur user die der gruppe mediausr angehören.
Wenn ich nicht mit Ordner ACL arbeite sondern mit Share ACL sollte das doch klappen oder?
Ordner ACL everybody=modify und Share ACL mediausr=readx
Gibt es noch eine Alternative dazu?
Wenn ich nicht mit Ordner ACL arbeite sondern mit Share ACL sollte das doch klappen oder?
Ordner ACL everybody=modify und Share ACL mediausr=readx
Gibt es noch eine Alternative dazu?
