FreeBSD mit ZFS und Samba in AD-Domäne

M

morpheus

Well-Known Member
Hallo,

nachdem ich nun dank einiger sehr guter Anleitungen hier aus dem Forum meinen Server mit ZFS aufgesetzt habe, stehe ich nun vor dem Problem, den Datenspeicher in unserer Windows-Domäne verfügbar zu machen. Es wimmelt im Netz zwar von Anleitungen zu diesem Thema, viele sind aber veraltet oder gehen von anderen Voraussetzungen aus.

Gibt es irgendwo eine vernünftige aktuelle Anleitung, mit der ich den ZFS-Server als funktionierenden Dateiserver in unsere Active-Directory-Domäne integriert bekomme? Muss man bei ZFS noch irgendetwas Besonderes beachten?

Gruß, Morpheus
 
Evtl. ein Cache-Device (SSD) für ZFS. Dazu gibt es hier ein paar Threads im Forum. Zweitens würde ich den Storage als iSCSI exportieren und auf einem Fileserver, falls es den schon gibt einbinden. Das sollte dann aber schon gut gemacht sein mit "teaming" für die Netzwerkkarten ectl. Oder du machst das direkt als Samba Share auf dem FreeBSD Server. Das hat den Vorteil, dass du die Daten auch direkt unter FreeBSD lesen kannst. Bei einem iSCSI Export, wird das Device mit einem Dateisystem formatiert. (NTFS vermutlich.)
 
ZIL (gespiegelt) und L2ARC sind eingerichtet. Als ISCSI-Device wollte ich es eigentlich nicht einbinden, da ich auch die Datensicherung mit FreeBSD übernehmen möchte. Daher suche ich ja nach einer brauchbaren Anleitung, wie ich mit FreeBSD und Samba die Integration in eine AD-Domäne bewerkstelligen kann.
 
Das ist mal wieder so eine Frage, wo ich mir nur die Finger verbrennen kann und deshalb lieber mein Maul halten sollte.
So weiß ich natürlich nicht, was eine AD-Domäne meint und was daran besonderes ist.
Aber, ich habe auf meinem Fileserver auch einen SAMBA-Server laufen und diverse Freigaben dort organisiert. DIe man-Pages zu samba haben mir dazu alles erklärt, ich glaube, es gab auch ein Example-Config File. Besonders angenehm fand und finde ich aber die Konfiguration über Web-Interface, das sogenannte SWAT. Ist das aktiviert, dann lauscht es auf Port 901 und du kannst da meiner Meinung nach fast alles einstellen, was wichtig ist. Bei wenigen Punkten, kam ich da nicht so weiter, wie ich es mir vorgestellt hatte.
Auch recht unkompliziert und wirksam ist die Einrichtung von zusätzlichen Usern und eigenen Passworten mit smbpasswd. Das alles geht auch schon bei meiner etwas alten Samba-Version über SWAT.

Vielleicht hilft dieser Hinweis. Wenn nicht, schweigen wir ihn einfach tot, passend zur ARD-Themen-Woche.
 
Hi

Code: 
mightychicken# cd samba36/
mightychicken# make showconfig
===> The following configuration options are available for samba36-3.6.9:
     LDAP=on: With LDAP support
     ADS=on: With Active Directory support
     CUPS=on: With CUPS printing support
     WINBIND=on: With WinBIND support
     SWAT=on: With SWAT WebGUI
     ACL_SUPPORT=on: With ACL support
     AIO_SUPPORT=on: With Asyncronous IO support
     FAM_SUPPORT=on: With File Alteration Monitor
     SYSLOG=on: With Syslog support
     QUOTAS=on: With Disk quota support
     UTMP=on: With UTMP accounting support
     PAM_SMBPASS=on: With PAM authentication vs passdb backends
     DNSUPDATE=on: With dynamic DNS update(require ADS)
     AVAHI=on: With Bonjour service discovery support
     PTHREADPOOL=off: With pthread pool
     EXP_MODULES=off: With experimental modules
     POPT=on: With system-wide POPT library
     IPV6=on: With IPv6 support
     MAX_DEBUG=off: With maximum debugging
     SMBTORTURE=off: With smbtorture
===> Use 'make config' to modify these settings

Code: 
[global]
	workgroup = MEINE-GMBH
	realm = MEINE-GMBH.LOCAL
	server string = %h server
	security = ADS
	load printers = No
	printcap name = /dev/null
	disable spoolss = Yes
	template shell = /usr/local/bin/zsh
	winbind use default domain = Yes
	idmap config * : range = 10000-20000
	idmap config * : backend = tdb
	printing = bsd
	print command = lpr -r -P'%p' %s
	lpq command = lpq -P'%p'
	lprm command = lprm -P'%p' %j

[netlogon]
	path = /usr/home/samba/netlogon/
	browseable = No

[homes]
	comment = Home Directories
	valid users = %U
	read only = No
	create mask = 0600
	directory mask = 0700
	browseable = No

[profiles]
	comment = Roaming Profiles
	path = /usr/home/samba/profiles
	valid users = %U
	read only = No
	create mask = 0600
	directory mask = 0700
	profile acls = Yes
	store dos attributes = Yes
	browseable = No
	csc policy = disable

[profiles.V2]
	copy = profiles

Soweit Samba läuft und in die Domäne gejoined wurde kannst du PAM konfigurieren das so die Leute sich z.B. an Diensten oder Konten anmelden können.
 
minimike schrieb:
Soweit Samba läuft und in die Domäne gejoined wurde kannst du PAM konfigurieren das so die Leute sich z.B. an Diensten oder Konten anmelden können.
Zum Vergrößern anklicken....


Und da gehen die Probleme jetzt los. Server wurde in die Domäne gejoined, wbinfo -u und -g funktionieren und zeigen mir die Domänenbenutzer und Gruppen an.Wenn ich allerdings getent passwd und getent group eingebe, werden mir nur die lokalen Benutzer und Gruppen auf dem Server angezeigt.

Meine nsswitch.conf sieht so aus:

Code: 
group: compat winbind
group_compat: nis
hosts: files dns
networks: files
passwd: compat winbind
passwd_compat: nis
shells: files
services: compat
services_compat: nis
protocols: files
rpc: files

Woran könnte das liegen?
 
Das ist normal. Ein anderes Verhalten ist mir nicht bekannt. Sofern du von root aus mit su USER wechselst solltest du mit id die uid und gid angezeigt bekommen. Darum includierst du ja Winbind in PAM
Das läuft hier bei uns so zuverlässig. Solange nicht die Falschen an die Richtigen Dateien und anders herum gelangen ist die Welt für mich in Ordnung.
 
Danke, da bin ich schon mal beruhigt. Jetzt muss ich noch PAM konfigurieren. Leider finde ich da im Netz die unterschiedlichsten Anleitungen, die teilweise auch schon recht alt sind oder sich auf Dateien beziehen, die bei mir garnicht vorhanden sind.

Welche Dateien aus /etc/pam.d muss ich denn wie anpassen? Nachdem, was ich bis jetzt gelesen habe, wären das die system und die passwd. Ich habe aber auch schon Anleitungen gefunden, wo man die /etc/pam.d/samba editieren sollte, die aber bei mir garnicht vorhanden ist.

Nachtrag:

Mittlerweile habe ich festgestellt, dass meine nsswitch.conf so falsch ist. Richtig muss es so aussehen:

Code: 
group: files winbind
group_compat: nis
hosts: files dns
networks: files
passwd: files winbind
passwd_compat: nis
shells: files
services: compat
services_compat: nis
protocols: files
rpc: files

Mittlerweile habe ich es hinbekommen, dass zumindest beim ssh-login auch die von mir berechtigten Domänenbenutzer Zugriff haben.
 
Zuletzt bearbeitet:
Hallo,

bei mir hat es so funktioniert "/etc/nsswitch.conf":
Code: 
#group: compat
group: files nis winbind
group_compat: nis
hosts: files dns
networks: files
#passwd: compat
passwd: files nis winbind
passwd_compat: nis
shells: files
services: compat
services_compat: nis
protocols: files
rpc: files
 
hi

zwei sachen sind wichtig .

a: sambas muss mit dem zfs modul installiert sein sonst klappt
es nicht mit den acls .

b: der root von der freigabe muss via facls auf administrator und everybody gesetzt
werden damit man nacher die permissions via windows setzen kannt.

facls siehe

http://www.freebsd.org/doc/handbook/fs-acl.html

holger
 
hi

ja 1x acl
und die experimental modules ( make config in ports )

hierbei wird dann u.a

zfs_acl , vfs_shadow_copy2 aktiviert,

das eine fuer die acls das andere um zfs snaps als shadowcopy zu verwenden.

holger
 
Ja da hat lockdoc recht. Bei Samba36 braucht man dies nicht. Dafür habe ich gelesen, dass man bei ZFS folgende Properties braucht:
Code: 
samba/save  aclmode             passthrough            local
samba/save  aclinherit          passthrough            local
 
Jepp. Da ich mal darauf reingefallen bin, beachtet bitte, dass die Unterstützung von NFS4-ALC durch Tools allgemein eher schlecht ist. Zum Beispiel überträgt rsync sie nicht, tar kann sie nicht packen... Das kann wunderbar Ärger machen, wenn man die Daten unter Erhalt der ACL im laufenden Betrieb auf eine andere Maschine bekommen muss. Ich habe am Ende ein Script zusammengegrützt, was die ACL sichert und auf der anderen Maschine mit setfacl neu setzt.
 
Yamagi schrieb:
Jepp. Da ich mal darauf reingefallen bin, beachtet bitte, dass die Unterstützung von NFS4-ALC durch Tools allgemein eher schlecht ist. Zum Beispiel überträgt rsync sie nicht, tar kann sie nicht packen... Das kann wunderbar Ärger machen, wenn man die Daten unter Erhalt der ACL im laufenden Betrieb auf eine andere Maschine bekommen muss. Ich habe am Ende ein Script zusammengegrützt, was die ACL sichert und auf der anderen Maschine mit setfacl neu setzt.
Zum Vergrößern anklicken....

hi ja , richtig jedoch hat man ja mit zfsd ein paar alternativen zur replication die
im zweifel einfacher sind als rsync.

holger
 
Ja. Waren in dem Fall nur nicht anwendbar... Wollte es nur mal gesagt haben, falls jemand sich später wundert.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben