Samba4 AD-re váltás

Linux-haladó

Sziasztok!

Samba 3-at használok, szeretnék váltani négyesre, és classicupgrade-del AD-t használni. Openldap adatbázissal használom, van három DC-m. A PDC mellett van egy BDC fájlszerverként, és egy további DC egy másik telephelyen, ami használja a központi ldap-t slave-ként, és egyben fájlszerver is.
Az olvastam a SaMBa AD DC HOWTO intrójában, hogy nem ajánlatos a DC-t egyben fájlszerverként is használni. Bár le van írva, hogy miért, Én azt nem értem. Milyen problémát okozna a gyakorlatban, hogy mégis használnám fájlszerverként is a DC-t?
Egyrészt a központban is némi macera lenne külön választani a fájlszervert, de a második telephelyen különösen az lenne, a szűkös erőforrások miatt. Milyen problémát jelent a gyakorlatban, ha a DC-t fájlszerverként is használom? Vannak-e tapasztalataitok esetleg ezzel kapcsolatban?

  • 3025 megtekintés

( freeoli v | 2015. 04. 29., sze – 11:36 )

A Samba4-es DC-nk egyben fájlszerverünk is és semmilyen negatívumot nem tapasztaltam. (Zentyal 3-4)

Nekem Debian7-el van sernet Samba4 fájlszerver és AD egyben. 30 kliens. Semmi probléma. Sőt, eddig nem is tudtam hogy ez nem javallot megoldás. Annó még a Windows NT4 kapcsán olvasva láttam, hogy nem tanácsos egy gépre rakni a két funkciót, de az ugye tán 20 éve is volt már. :)
Ahol 3-as Sambáim vannak ott meg várok az LTS életciklus végéig, aztán próbálok migrálni. Nem sürgős. :)

--
Rózsár Gábor (muszashi)

( hzsolt94 v | 2015. 04. 29., sze – 13:15 )

Alaposan gondold át az összes samba-hoz köthető dolgot mielőtt nekiálsz egy upgradenek. Mi nagyon beleszaladunk a pofonos fába, én egy olyan gány NT4 domaint örököltem ahol a classicupgrade gondolata is öngyilkosság volt... Végül több hónapos párhuzamos üzem alatt tértünk át, mindent kézzel migrálva.

Van olyan külső alkalmazásotok ami LDAP-ba authentikál? El fog törni. Teljesen más a samba4 belső ldap felépítése.
Konzisztens a Windows->Linux user mapping az összes beléptetett linuxon? Ha nem akkor el fog törni. Ha igen akkor migrálni kell (ezt részben megoldja a classicupgrade). Minden tartományi gép SID-je egyedi? Ha imagelve vannak akkor külön figyelve van a SID-ek átírására? A felhasználók jelszavai jók lesznek samba4-be? A fájlszerver támogatja a user_xattr-t? A fájlok futtatási joga helyesen van beállítva? (Ezt a samba4 már nem hagyja figyelmen kívül) Kvóták? A hálózat DNS-ébe hogy illeszkedik a samba? Kerberos?

Közvetlen hátrányát mi az azonos AD és fájlszerver felállásnak nem láttuk, de az AD-t rengetegszer kellett újraindítsuk a kezdetekben. Ha ő a fájlszerver is, akkor ez fájdalmas. Ha csak AD akkor a legtöbben észre sem veszik az újraindulást.

Köszönöm a részletes választ. A PDC-t átmásoltam Virtualboxba, természetesen elszeparált hálózaton van, és ott teszteltem a classicupgrade-et. Első próbálkozásom vagy két éve volt tesztkörnyezetben, állandóan elhasalt ezen. Most ott tartok, hogy végre gond nélkül lefutott a classicupgrade, a wikiben található leírásban szereplő dolgokat leteszteltem, Win7-tel csatlakozni tudtam rá.
Közvetlen ldap auth nincs, csak ntlm hitelesítés van Apache-ból. Régebben squid is autentikált ntlm-mel, de azt kikapcsoltam már egy ideje.
"Konzisztens a Windows->Linux user mapping az összes beléptetett linuxon?"
Csak a PDC/BDC-k vannak beléptetve linuxos gépek közül. Itt idmap-ként szintén az ldap van beállítva. Vagy még ekkor is lehet gond?
"Természetesen" klónozva van egy csomó gép, és nincsenek átírva a SID-ek, úgyhogy ezek nem egyediek...
Felhasználói jelszavak: arra gondolsz, hogy a korlátozásoknak megfelelnek-e?
Kvótákat nem állítottam be.
DNS: Bind-et használtam, és ezentúl is ezzel akarom, a tesztszerveren beállítottam már. Kerberos eddig nem volt, most a wiki leírása alapján van beállítva és tesztelve.
DC újraindítgatása: A Fájlszerver a DC2 lenne, és igen, annak újraindítgatása fájdalmas lenne. Beállítások módosításával szűnt meg később ez az állapot? Mert az, ha az elején kell ezt többször tennem, remélhetőleg még nem gond, suliban dolgozom, ha nyáron jól haladok, és időben megy az AD, akkor nem okoz akkora gondot néhány újraindítás.

> Közvetlen ldap auth nincs, csak ntlm hitelesítés van Apache-ból. Régebben squid is autentikált ntlm-mel, de azt kikapcsoltam már egy ideje.

NTLM-ről nem tudok nyilatkozni, de rendes Kerberos alapú kézfogásos hitelesítés megy samba4+apache párossal, érdemes utánanézned hogyan kell bekonfigolni arra az esetre ha az NTLM megszűnne működni.

> Itt idmap-ként szintén az ldap van beállítva. Vagy még ekkor is lehet gond?
Ez a legszerencsésebb felállás, elvileg így nem lesz gond.

> "Természetesen" klónozva van egy csomó gép, és nincsenek átírva a SID-ek, úgyhogy ezek nem egyediek...
Ez itt akkor egy go/no-go kulcspont lesz, azonos siddel nem tudsz 2 gépet samba4-es (meg úgy általában) windowsos AD-ben tartani, úgyhogy változtatnod kell a klónozási módszeren, és a most beléptetett gépek nem fognak bent maradni :-/ Nagyjából két lehetőséged van:
a) Klónozás után lépteted be gépeket tartományba (az image nincs beléptetve) és a meglévőeket ki-be lépteted kézzel. Ilyenkor _elvileg_ a Windows rendbeteszi a SID-eket.
b) Megfelelően alkalmazod a Microsoft féle sysprep toolt imageléshez, és az kezeli (tartomány nélkül is) a SID-ek megfelelő beállítását

> Felhasználói jelszavak: arra gondolsz, hogy a korlátozásoknak megfelelnek-e?
Egyrészt arra (kisbetű,nagybetű,szám) másrészt arra hogy van-e bármilyen szolgáltatás (pam, webes sso, miegyéb) ami esetleg függhet a jelszó tárolási formátumától. Illetve érdemes annak is utána nézni hogy a classicupgrade hogyan hozza át a jelszavakat, (sambában van plaintext mód is) és nem-e érdemes lecseréltetni őket hogy megfelelő biztonsági szint mellett legyenek tárolva. Sajnos ezzel nem teljesen vagyok képben, nálunk végül "kézzel" lett migrálva.

> Kvótákat nem állítottam be.
Ennyivel is kevesebb a problémád :-)

> DNS: Bind-et használtam, és ezentúl is ezzel akarom, a tesztszerveren beállítottam már.
BIND9_DLZ backendnek nézz utána, ha megy akkor rendben vagy.
> Kerberos eddig nem volt, most a wiki leírása alapján van beállítva és tesztelve.

> Beállítások módosításával szűnt meg később ez az állapot? Mert az, ha az elején kell ezt többször tennem, remélhetőleg még nem gond, suliban dolgozom, ha nyáron jól haladok, és időben megy az AD, akkor nem okoz akkora gondot néhány újraindítás.

Igen, gyakorlatilag arról van szó hogy a samba szolgáltatást nem nagyon lehet rendesen újraindítani, (legalábbis nem mindig veszi figyelembe) és nem tudhatod hogy a konfig fájlok érvényre jutottak-e, ezen kívül sok olyan corner-case van ahol az AD simán merevrefagy, és vagy hosszasan küzdesz a pkill -9 parancsokkal, vagy újraindítasz. Szóval egy kicsit Windows-feelinges a dolog. Amikor élesbe került fix beállításokkal, gyakorlatilag nem kellett rebootolni.

Én egy gimnázium és általános iskola rendszerét állítottam át két kollégával nyáron, bár nálunk csak 1 AD volt, cserébe 1200 user, jónéhány fájlszerver, alkalmazás, levelezés, stb... ráaggatva. Ha komoly a projekt megkereshetsz privátban is :-)

> "Természetesen" klónozva van egy csomó gép, és nincsenek átírva a SID-ek, úgyhogy ezek nem egyediek...
Ez itt akkor egy go/no-go kulcspont lesz, azonos siddel nem tudsz 2 gépet samba4-es (meg úgy általában) windowsos AD-ben tartani, úgyhogy változtatnod kell a klónozási módszeren, és a most beléptetett gépek nem fognak bent maradni :-/

A classicupgrade-nél még van egy-két ilyen go/no-go dolog, valahol (egy előadás slidejain emlékszem rá, de nem merek megesküdni rá, lehet valahol a levlistán volt) volt egy szép hosszú lista, hogy mikkel találkoztak a fejlesztők, amik miatt ugrott 1-1 classic upgrade (duplikált usernevek, pontot tartalmazó netbios tartománynév, ilyesmik)

Nagyjából két lehetőséged van:
a) Klónozás után lépteted be gépeket tartományba (az image nincs beléptetve) és a meglévőeket ki-be lépteted kézzel. Ilyenkor _elvileg_ a Windows rendbeteszi a SID-eket.
b) Megfelelően alkalmazod a Microsoft féle sysprep toolt imageléshez, és az kezeli (tartomány nélkül is) a SID-ek megfelelő beállítását

Ezt még kiegészíteném egy harmadik lehetőséggel, kipróbálhatod a Microsoft Deployment Toolkit-et, az gyakorlatilag a sysprep-et egy-az-egyben rád is kényszeríti. Kis taknyolással (nézz rá a blogomra) még udp szórásos [mint a Clonezilla] image-lés is megoldható, kicsit szórakozva vele akár alkalmazás-telepítős mókára is alkalmas [ráadásul tényleg kényelmesen használható, a fél világgal összefésülték, így csak task sequence kérdése pl. hogy újratelepítés előtt csinálj a User State Migration Tool-al mentést a userek beállításaitól, aztán egy teljes wim mentést biztos, ami biztos, újrahúzd a gépet és visszaállítsd a beállításokat - már ha nincsenek roaming profilok

(*): Nálunk a géptermekben és a tantermi gépeknél van ez aktívan használva, a CustomSettings-ben minden géphez MAC szintjén hozzá van rendelve, hogy milyen alkalmazás-csomagot kell, hogy kapjon, és van egy Task sequence, ami a kijelölt alkalmazásokat telepíti. Ezt még kiegészítettem egy kis .exe-vel, ami annyi csinál, hogy elindítja önmagát egy másik userként (a usernév, jelszó bele van égetve), aztán ad egy UAC promptot [de mivel a "beégetett" user group policy szerint minden gépen rendszergazda, így az Igen/Nem-es prompt jön be], és elindítja a telepítőt kifejezetten megcímezve a Task sequence-t. A géptermi gépeknél ezt psexec-el indítom (ha már alapból elevated, akkor nem kér prompt-ot), a többi tanári gép asztalára meg kiraktam hozzá egy parancsikont, így ha valamiből nem a legfrissebb van fenn a gépen, akkor sima userek is fel tudják tenni.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( SzBlackY | 2015. 04. 29., sze – 15:13 )

1) ha a classicupgrade-t választod, akkor _várjál_. A 4.2 kapcsán jött elő egy bug, ami classicupgrade-s domaineknél 4.0/4.1 -> 4.2 váltásnál megtörte a tartományt, a bug reportok szerint a legtöbben visszamentek back-upból [valami az SPN-ekkel nem stimmel], előbb-utóbb javítják (Bartlet is beleszólt már a bugba, úgyhogy lehet, hogy lesz vele valami :) )
2) a DC (mondjuk most provision-elt, nem classicupgradelt) nálunk is betölt fájlszerver funkciót [egy ~20 megás mandatory profil és egy nagyobbacska deployment share van rajta], gond nélkül megy bár eléggé tud terhelni (többnyire egyszerre 28 vagy 56 gép húzza be róla a profilt, vagy párhuzamosan 4-8-12 gép telepít a deploy share-ből). Ha azt a szűkszavú figyelmeztetést jól értem a user mapping-re gondolnak, a 4.0/4.1 szériában valóban volt egy AD-szerver specifikus winbind szerver, ezt a 4.2-ben összevonták a rendessel - így szerintem nincs különösebb gond vele [és tippre korábban is csak akkor, hogy közvetlenül a Linux-on, vagy valami nem smb protokollon keresztül is el kellett érni a fájlokat, ott az uid mappel lehettek problémák]. YMMV.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

22-én jött rá egy patch a Bugzilla szerint: https://bugzilla.samba.org/show_bug.cgi?id=10991 [bár SPN-eket írtam az előző kommentben, de szerintem ez volt az a bug... de fene se tudja]

Ha tartják az eddigi kiadási ciklusokat, akkor nagyjából mostanában kellene majd jönnie a 4.2.3-nak (március/április/május volt a .0, .1, .2, ezt már megszakították :( ).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Még mindig csak a tesztelésnél járok. Debianban a 4.1.17-es van (Wheezy backportsból használom). Szerettem volna helyből 4.2-vel dolgozni, ami Sernet Sambával lehetséges lenne, csak egy gondom volt: A Sernet Samba ütközik az openldappal, ami viszont a classicupgrade-hez kell. Rendben, gondoltam akkor megcsinálom a classicupgrade-et a debianos Samba 4.1.17-tel, majd váltok Sernet Samba-ra. Bár van remény az említett bug kiküszöbölésére, mégis jobb lenne eleve 4.2-vel kezdenem, hátha abban már jobb a classicupgrade, merthogy azért a 4.1.17 pl. nem állította be egy rakás "jólismert" csoport uid-jét. Ez egy olyan hiányosság, amire eddig rájöttem, ki tudja, lehet még más is. Persze az is igaz, hogy elismerik, hogy nem hoz át mindent a classicupgrade, de azért az gáz, hogy az általam létrehozott felhasználókat, csoportokat jobban hozza át, mint ezeket a "jólismerteket".
Tud esetleg valaki módszert arra, hogy hogyan lehet a Sernet-es Samba-val classicupgrade-elni ldap backendes Samba3-ról?

Jó is, hogy kijött, szükségem is lesz rá.
Most itt tartok: Virtuális gépen teszteltem a classicupgradet, de ahhoz, hogy a Sernet Sambaval tehessem, az LDAP másik gépen volt. Az egyszerűség kedvéért a PDC-t klónoztam, kapott új nevet, IP-t, beállítottam, hogy az új IP-jén figyeljen az LDAP, majd futtattam a classicupgrade-t. Így lefutott, de utána elindítva a Sambat a logban hibaüzenetet találtam. Kiderült, hogy ez a 10991-es bug miatt van, úgyhogy várom a 4.2.3-as Sernet Sambát, hogy újra próbálkozhassak a classicupgrade-del.