Milyen OS/szoftver kombóval lehet kiváltani egy Mac OS X Server fileszerver részét, úgy, hogy a következő követelményeknek megfeleljen (Windows-os SMB, és Mac-es AFP vagy SMB kliensek, 10.9-es OS-el):
- Active Directory autentikáció
- AD Kerberos SSO
- Szerver oldali Spotlight támogatás a Mac-es kliensek felé
- ACL-ek kezelése a Mac-es kliensek felé
- Az SMB és az AFP protokolon keresztül ugyanazt lássák a kliensek (ACL-ek, ékezetek)
- Nem kerül csiliárdokba
- Virtualizálható legalálisan (HA képes, pl.: vSphere, Xen, Hyper-V)
Amikkel kisérleteztem:
- Linux (CentOS7)+netatalk+samba4: a legnagyobb gond az ACL kezelésből volt (a netatalk-ban nem ugyanazok az ACL-ek látszódnak mint a samba-ban), illetve abból, hogy a samba és a netatalk ugyanazt a user-t két külön UID-el látja.
- FreeBSD 10+netatalk+samba4: ZFS-es filerendszeren az ACL-ek jók, viszont a Spotlight indexelés nem megy, mert a gnome trackerből nincs 0.7 vagy újabb FreeBSD-n
Ami még esetleg szóba jöhet:
- ExtremeZ-IP, ehhez kell egy Windows licensz, illetve maga a szoftver is egy nagyobb kalap pénz
- Helios UF UB64, megy Linux-on, de szintén egy nagyobb vagyon
- Samba 4.2, elméletben van egy olyan patch hozzá, ami támogatja a Spotlight kereséseket, nekem nem sikerült életre kelteni (https://github.com/slowfranklin/samba/tree/spotlight) és igazából stabil megoldás kellene
- Solaris (vagy valamilyen deriváltja) + netatalk + samba4: Nem tudom megy-e a gnome tracker, viszont van ZFS ACL-ekkel. Solaris-al vagy 10 éve nem volt dolgom, létezik belőle ingyenes, de jól működő variáns?
Hozzászólások
subs
AD kell, de Windows nem? Szerintem legyen egy DC es akkor az elso ket dolog kipipalva.
Ha AFP nem muszaj akkor legyen csak SMB.
Szerver oldali spotlite-al meg nem volt dolgom, azt nem tudom.
Gondolom egy Win szerver legalisan virtualizalhato es valoszinu nem csilliardokba kerul.
OSX miert nem kerult szoba egyebkent? Ja, azt kell kivaltani, de miert? :)
---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."
A fenti kitételeknek az OS X Server megfelel, ott vérzik el, hogy nem virtualizálható.
A Windows alapból nem kizáró körülmény, de mivel nem tudja azt a szolgáltatáscsomagot amire szükség van, csak egy meglehetősen drága ExtremeZ-IP-vel, ezért nem jött szóba.
Az AFP nem muszáj, a szerver oldali medata indexelés (és annak kereshetőséeg kliens oldalon) viszont igen, ha ez menne Samba-n akkor nem kellene AFP.
Létező AD infrastruktúrába kell ezt beintegrálni, nem kell neki DC-nek lennie, de tudni kell kapcsolódnia az Active Directory-hoz.
"hogy nem virtualizálható"
Ezt megmagyarázom a betévedőknek azért: az Apple nem engedi hogy NEM Apple hardveren virtualizáld
Due to Apple licensing restrictions, you may only create and run this virtual machine on Apple-labeled hardware. For more information, see Apple's Hardware & Software Product Agreements.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cm…
+1, OSX virtualizalhato Apple hardveren
Itt szepen le is vezetik, vmware eseten:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cm…
[szerk.] Latom a fenti link is vmware, nem baj, ez nem ugyanaz.
---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."
Virtualizálható, csak nem túl értelmes módon. A VMWare egyetlen jelenleg ma kapható Apple gépet sem supportál, ezen felül sem a MacPro, sem a Mac mini nem server hardware. Ezt hagyjuk, a kérdés pont az lenne, hogy az Apple hardware hogyan váltható ki, úgy hogy a felhasználói oldalon ne legyen funkcióvesztés. Ha nem megoldható, akkor marad a Mac mini szerver, de pont ezt lenne a cél elkerülni.
Ezt, mint aktív és elégedett VMware Fusion használó, nem értem.
Ave, Saabi.
Szervereket nem virtualizálunk Fusion-el, nem arra való. A baj az, hogy egy vCenter clustert nem lehet Apple gépeken futtatni, ergo nem lehet rajta virtuális Apple rendszert futtatni.
Ez igaz, de attól még hülyeséget beszélsz, mikor azt mondod, hogy a VMWare nem támogat egy Apple vasat sem. A VMWare ESXi (!!!) nem támogatott Apple vason. Ami nem meglepő, mivel az Apple már nem gyárt servert. (A Mac mini servert valahogy nem tudom annak tekinteni, de jó játékszer, nekem is van itthon) Mindazonáltal találtam blogbejegyzést arról, hogy fut az ESXi Mac minin. De ezt a VMware nem támogatja.
Ave, Saabi.
Nem mondanám hülyeségnek, csak pongyolán fogalmaztam. Mivel az egész thread szerverről szól, ezért bennem fel sem merült hogy félreérthető, de megkövetlek, és elnézésedet kérem, amiért ilyen hülyeséggel traktáltalak.
Ha Mac mini-t (vagy akár Mac Pro-t) kell berakni, akkor a virtualizáció nagyjából értelmét veszti, mert nem azért szeretném virtualizálni, hogy elmondhassam, hogy ez is virtuális, hanem pl.: hogy magas rendelkezésreállású (HA) legyen, elérje a shared storage-et, terhelés függvényében lehessen hostok között mozgatni, snapshotolni lehessen, stb.
De hogy nehogy megint a pongyolaság bűnébe essek, a konkrét feladat az, hogy adott egy x86-os VMWare vCenter, XenServer (de akár lehet más is) HA cluster, amiben a nyitó postban meghatározott szolgáltatásokat nyújtó guestet kell létrehozni. Nem játékra kell, production use, sok felhasználó, sok tárhely.
Igazad van, elnézést kérek az éles reakcióért!
Ave, Saabi.
de pontosan mi a bajod a Mac Mini serverrel?
Mit akarsz virtualizalni? AFS -t? egyeb szolgaltatast... ?
Amugy linuxon ezek kellenek: netatalk avahi-daemon avahi-utils, de -szerintem- ez kókányolás
gondolom az vele a baja hogy beletuszkolja mind az 1 db. 2.5"-os diszket ami belefer, kinevezi fileszervernek, aztan nezi ahogy megall az egesz amikor egy irodanyi user raszabadul, plusz varhato egy kenyelmetlen beszelgetes is a vezetoseggel amikor az az 1 szal diszk kipukkan :)
ja, lehet, de az is kókányolás.
Apple -nek van servere, mármint hardware... ha szolgáltatás kell, azt kell használni.
Ha meg storage, akkor ott a Synology, vagy NetApp, vagy akármi.
szerkesztés: most nézem, tud az raid1 -et ( http://store.apple.com/us/buy-mac/mac-mini?aid=www-k2-mac+mini+-+server… )
Mondjuk serverbe raid1 meg olyan, mint bemenni egy kuplerájba egy ölelésért...
Tudomasom szerint az Apple megszuntette a szerver hardver termekvonalat meg 2011-ben.
A mac mini server valtozat meg tud raid1-et es ket disk belemegy valoban, de azt te is erzed szerintem hogy fileszervernek egy ilyen gepet hasznalni eleg rossz vicc :)
Mac Probol is volt szerver verzió, de a "sima" mac pro is elég komoly hardver.
rejtett up
nem jo a mac pro servernek, se IPMI/ILOM, se redundáns táp, se hot-swap merevlemez, se stb.stb...
(azt hagyjuk is, hogy a fizikai formátuma is eléggé elcseszett servernek.)
Normális serverben az internal dism maximum az OS-nek van ott. Az adatokat általában nagy megbízhatóságű, külső tárolokon tároljuk. Legalábbis egy szint felett. A Mac mininek van egy Thunderbolt interface, aminek a sebessége akár 10Gbps is lehet. Mivel létezik Thunderbolt-FC adapter, a Mac mini nyugodtan megoszthat rendes sebességgel elérhető adatokat.
Amiben én inkább problémát látok, az az, hogy mind a Thunderbolt, mint az Ethernet csatlakozókból csak egyetlennel bír ez a gép, ugyanakkor nem tudok arról, hogy a Mac OS X képes lenne clustert alkotni. Anélkül meg az én ízlésemnek túlságosan sérülékeny. EZ egy normális indok a Mac mini server ellenében, nem a belső diskjei.
Ave, Saabi.
A Mac minivel nekem 2 bajom van, az egyik hogy ez egy otthoni felhasználásra szánt vas, amitől nem várható el, hogy 24/7-ben kibírjon 68.000 órát, mint ahogy az jelenlegi XServe-ek döccenés nélkül ennyit kiszolgáltak. A másik, hogy nem akarok a rackszekrény tetejére (vagy mellé ez mind1) odadobni 2 Minit.
IPFailovert lehett csinálni Server 10.6-ig, de ha egy HA hypervisor-on fut, akkor nem is kell clusterezni (nekem legalábbis nincs rá szükségem)
Szerintem a macminicolo.net létezése cáfolja, hogy ne lenne alkalmas a mini 7x24-ben működni. Az elhelyezésével kapcsolatos problémákat megértem.
Ave, Saabi.
Azért mert a Windows XP-n futtatható az Apache, nem jelenti azt, hogy a Windows XP egy jó platform apache szerver futtatására.
Mint leírtam, ha nincs más marad a Mac mini, de ez egy csomó olyan kompromisszumot jelent, amit nem szívesen vállalnék be.
Ezt én nem is vitatom, csak azt, hogy ne lenne alkalmas 7x24-ben működni. (BTW, nálam ezt csinálja pár hónapja egy meglehetősen öreg mini, szóval a folyamatos működés nem akadály. Sokminden más viszont lehet az.)
Ave, Saabi.
Letezik olyan keret amibe beszerelheto 2 db Macmini egymas melle, azt hiszem 1U magas, ezutan az elhelyezes mar nem problema.
http://www.sonnettech.com/product/rackmacmini.html
---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."
Pontosan az a baj, hogy adott egy normális HA cluster, amiben Linux, Windows, FreeBSD szerverek futnak nagy nyugalomban, hozzájuk való storage-el. Ez alól a Mac kivétel, a fileserver miatt kell tartani egy külön polcon egy Mac mini-t, ami nem server grade.
A szolgáltatásokat amire szükség van leírtam a nyitó postban.
Te, most kapcsolok;
http://appleinsider.com/articles/13/06/11/apple-shifts-from-afp-file-sh…
Magyaran a Mac klinsek mennyenek samban és kész, vegyél egy NFS storageot, mivel innentől már bármi jó.
Innentől, és mivel mindjárt itt a public Yoisemite, szeirntem siman tudnál SMBV2 -n osztott voluemeot csináli.
Tehát egy NetApp Metrocluster épp megoldást is adna a problémádra.
Nem tud Spotlight-ot. Ezért írtam, hogy nem ragaszkodom az AFP-hez, a szerveroldali metadata index viszont nélkülözhetettlen. Úgyszintén annyira nem egyszerű a történet az ACL kezelések terén sem…
áhh, teljesen igaz, bocsánat
A glusterfs osx client tamogatasa beta, esetleg..
De szerintem nem lesz jo, mert as aclekkel szopas lesz gondolom ugyanugy.
Viszont as uid problemazast nem ertem. Nalam OK.
Az a gond az UID-el, hogy ugyanazt az AD usert a netatalk és a samba más uid-el látja el. Azaz Gizike létrehoz egy file-t AFP-n, akkor annak Samba alatt ugyan egy Gizike nevű user lesz a tulajdonosa, de nem ugyanaz a Gizike mint egy Samba alatt ugyanazon a felhasználó által létrehozott filenak. A nevűk egyezik, az UID-jük viszont más.
A probléma technikai oldalról az, hogy az AD UUID-je egy user-nek így néz ki:
xxxxxxxx-yyyy-zzzz-wwww-ssssssssssss
A Mac OS, és a netatalk az xxxxxxxx-ből generál egy UID-et a usernek (ldap-ot használnak rá), a Samba viszont az ssssssssssss-ből (ő meg winbind-el csinálja).
Béta megoldásokkal nem kisérleteznék, és a Spotlight sem fog működni (tudtommal) Gluster FS alatt. Sajnos az összes, a nyító postban felsorolt szolgáltatásnak mennie kell ez felhasználói igény, a virtualizáció kivételével, mert az meg IT igény.
Mitol lesz ez jo FBSD-n?
t
Nekem nem lett jó, de mivel ott az ACL-ek rendben vannak, ezért ott át tudom hidalni ezt a problémát.
Az ACL-ek linux-on is rendben vannak, vagy nem ertem meg mindig. Szoval mi a kulonbseg fbsd es linux kozott?
FreeBSD + ZFS-en van ZFS ACL a netatalk ill sambaval is. Linuxon csak POSIX ACL van, ami lényegesen korlátozottabb (és nem is látszik rendesen a kliensek felöl).
Ahha, utanaolvastam picit, igy mar erthetobb.
BTW, miert nem hasznaltok egy celhardvert?
Nem tudom milyen célhardverre gondolsz. De ha létezik olyan, ami a felsorolt kritériumoknak megfelel, az már jó kiindulási alap, mert abban is valamilyen szoftver fut.
Ha a célhardver egy Mac mini szervert jelent, akkor azt pont szeretném elkerülni, de B tervnek az van.
Feltetelezem van olyan storage, ami tud afp, AD-t es a tobbi dolgot. Netapp, stb?
t
AFP-t jellemzően NAS-ok tudnak, itt azért nem 3 usert kellene kiszolgálni. És ha tudnak is AFP-t metadata indexelést nem csinálnak.
„melynek teste oroszláné, feje oroszláné, de nem ugyanazé az oroszláné” /Woody Allen/
Nekem sikerült ubi alatt OSX-et virtualizálni (nem apple hardveren):
http://logout.hu/bejegyzes/honkydoo/ubuntu_alatt_osx-et.html
Tudom ez nem Server, meg én Virtualbox alatt csináltam, szóval lehet csak lazán kapcsolódik a témához.
Képes vagyok ESXi alatt futtatni virtuális OSX-et. Ezzel az a gond, hogy meg lehet csinálni, csak nem szabad, ezért írtam, hogy legálisan virtualizálhatónak kell lennie.
Elolvasva ujra a temat, itt inkabb az a gond, hogy az Apple-nek nincsenek olyan termekei amik szerver szinten felveszik a versenyt mas gyartokkal.
Szerintem:
- ha nem akarsz funkcio csokkenest kliens oldalon akkor valassz hivatalos Apple megoldast (=macmini server, macpro?)
- valts kliens oldalon is es akkor a szerver oldalon kapsz robusztus, tamogatott megoldast
Gondolom egyik ut sem jarhato, mert:
- Apple hivatalos megoldas nem eleg robusztus
- a felhasznaloknak kellenek a megszokott funkciok + megszokott OS(X)
Esetleg oszd meg a dolgokat, amit csak Apple szerverrel lehet megoldani azt azzal, a tobbit meg massal.
---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."
Nekifogtam Solaris alatt összerakni a cuccot, tanulni kell, de netatalk3, samba4 illetve a gnome tracker is mennek rajta, illetve van ZFS ACL kezelés mind samba, mind netatalk oldalról.
Mi XServer + XSAN-t helyettesítettünk Solaris11.1+netatalk+samba kombóval, AD auth nélkül.
A netatalk 3.0.1 - 3.0.8-ig olyan hibát tapasztaltunk, hogy x idő után (x: 24 és 72 óra között) nagyon belassulnak bizonyos műveletek afp-n keresztül (folder listázás, FinalCut project megnyitás). Ezt egy éjszakai reboottal workaroundoltuk... a netatalk-admins listán volt néhány thread hasonló témában, de egyik sem jutott eredményre.
Mi most a Tiger Techtől próbálunk egy demo vasat, a Promise cuccai elég drágák...
netatalk 3.1.x-ről nincs tapasztalat
Rajtuk gondolkodtunk még, fizetős támogatás:
http://www.netafp.com
Itt írnak még a Spotlightról:
http://www.netafp.com/installation-manual/
Szia!
Szeretnem megkérdezni, hogy hogy alakult a Solaris -os történet?
Mi is hasonlóan keressük az OSX kiváltását.
vmware esxi 5.5 alatt futtatnank valamit, ami jo lenne mac klienseknek fileservernek.
freenas -sal es nas4free -vel kiserletezgettunk (magyaran ejszakakat sz.ptunk vele), de nem all ossze rendesen a dolog.
Ti hogy oldottatok meg? Bevalt a Solaris +netatalk3+samba? ACL kezelest hogy oldjatok meg?
Koszi!
Szeretnem up -polni a temat. :)
Esetleg van-e valakinek valami fejlemenye az ugyben?
Mi is aktivan keressuk a megoldast, kb. 99%-ban ugyan azok az igenyeink, mint a topicnyitonak, s mi is ugyan azokat csinaltuk eddig, mint a topicnyito, annyi kiegeszitessen, hogy FreeNAS (+opendirectory LDAP auth) es nas4free rendszereket is kiprobaltunk mar.
Koszi!
Eddig a legéletképesebb megoldást a FreeBSD 10.2 + Netatalk 3.1.7 + GnomeTracker 1.2.6 + Samba 4.2 adta.
Az ACL-ek mennek, mert a share ZFS-en vannak, és ott működik az ACL kezelés rendesen, még a kliensek felé is jól adja ki. Sebességben kielégítő, sajnos a tracker az folyamatosan leáll. Ez még csak egy teszt szerver, de eddig messze a legbíztatóbb. Mind a netatalkot, mind a tracker-t kézzel kellett fordítani.
Időközben kijött a 4.3-as samba, ami tudja a spotlight-ot, ezt még nem próbáltam, de a jövő erre felé mutat, mert az Apple dobni fogja az AFP-t hamar.
Köszi az infót!
Hétvégén tesztelünk szerintem mi is.
Eddig próbálgattunk FreeNAS-t netatalk+opendirectory auth -tal, meg rajta samba4-et.
Troughput tekintetében egyébként jó a netatalk és a samba4 is SMB2-SMB3 protokollal.
A virtualizációs host erős dual E5-xeon -os gép, 10gbit-en lóg a központi switchen (storage is 10gbit iscsi).
Csináltunk olyan tesztet, hogy egyszerrre 4-5 SSD-s macmini-ről, amik gigabiten csatlakoznak a központi switchre, másolunk fel a serverre.
Samba esetében az aggregált troughput olyan 400-450 megabyte/sec, netatalk esetében pedig 300-320 megabyte/sec volt.
Innen nézve nem is sajnálom, hogy ha a jövő Apple-nél is a friss SMB protokoll lesz, s az AFP-t dobja.
Amúgy a virtualizált FreeNAS-on remekül lehetett látni, hogy több smbd process forkolódott, s párhuzamosan tekertek, míg netatalk esetében mindössze egy darab afpd pörgött 100%-on....
(Ehhez az is kellett egyébként, hogy a virtualizált FreeNAS alá fel kellett heggeszteni a rendes vmware tools -t, s megadni a loader.conf -ba, hogy töltse be a rendes vmxnet3 hálókártya-drivert, ne a FreeNAS-ba épített open-vm-tools -os vmx3 drivert használja.)
Ami nem volt jó a FreeNAS-ban:
Ez a hiba az ACL-ezést ugye teljesen hazavágta.: https://bugs.freenas.org/issues/3242
Na most az LDAP(opendirectory) auth -ról nem mondanánk le, hisz vannak networking home-os és mobile home -os userek is. Ők nem látnák a homedir-jüket LDAP auth nélkül.
Kettő darab mac mini amúgy maradni fog nálunk mindenképp a rack tetején, egy opendirectory master és egy opendirectory slave, de a többi szolgáltatást nem akarom rájuk bízni.
Viszont az opendirectory-ról se mondanék le, mert a hálózatunk egyébként OSX alapú, s talán ha egy windosos gép van, a többi macbook air/mac mini/imac.
Bár már azon is elkezdtem gondolkozni, hogy belövünk egy Windows Server -t, vagy Samba server-t, aztán OD helyett lesz AD, csak az meg milyen már, egy mac-es hálózatban....
Másik probléma a FreeNAS-sal az volt, hogy bizony stabilitási problémákat véltem felfedezni, hogy finoman fogalmazzak.
8GB RAM-ot és 6 vCpu-t kapott a teszt FreeNAS, és bizony volt olyan, hogy lefagyva találtam, mert az oom_killer sorban kilőtt mindent. Mindezt nulla terhelés mellett, hisz csak tesztrendszer volt, s napokig nem is volt piszkálva az előtt, hogy észrevettük, hogy le van fagyva.
Máskor meg egyszerűen hetekig hozzá se nyúltunk, nem is másoltunk rá, fel se lett mountolva, hanem azt vettük észre, hogy nem válaszol pingre. Console-ra lépve merevre fagyva találtuk a FreeNAS-t. Azóta sem derült ki, hogy miért. Csak a hard-reset segített, logokban semmi nem volt.
Harmadik, legsúlyosabb probléma, hogy kb. 2 hete, a hónapok óta jelzett update-re a GUI-ban rápróbáltunk, s le is frissítette magát, de azóta nem indul el. :)
Nem lát egy csomó hw -t, pl. net, watchdog, stb., nem indulnak el a szolgáltatások, a console kulönböző error -okkal hányódik tele, s mikor lefut az init, akkor nem tudok console-on belépni, mert nem érzékeli a billentyűzetet sem. :) Hálózat hiányában ssh sincs rá.
Szóval a FreeNAS engem nem győzött meg. Mivel tesztrendszer volt csak, annyit nem ér az egész, hogy utánna nyomozzak, hogy mit rontott el a beépített frissítési funkció, inkább megy a levesbe a vmfs -ről.
Hétvégén szerintem kipróbáljuk a FreeBSD 10.2-t+Samba 4.3 -at. Kíváncsi leszek arra is hogy Yosemite tud-e a Samba 4.3 által kiadot home direkhez kapcsolódni, vagy ehhez marad a netatalk.
ACL-t honnan állítasz? FreeBSD parancssorból, vagy admin jogokkal rendelkező userrel felmountolva tudsz a Finder "Get Info..." ablakából is?
netatalk 3.1 elvileg kb. tudja amit akarsz.
Lehet a host solaris, vagy Linux is.
Nekünk van Ubunut server netatalk 3.1-el, eddig nem nagyon volt vele probléma. ACL-t támogatja, spotlight-ot gnome trackerrel csinálja, de végülis tökmindegy, működik :)
Kicsit macerás összetákolni, az AD auth az ldap pluginnal megy, az SSO-ról nem tudok nyilatkozni.
ACL _valóban_ működik??? Nem csak sima POSIX ACL-ek vannak Linuxon?
(No meg nem AD auth kéne nekem, hanem opendirectory, de az már "részletkérdés".)
Ha valóban tudja ez a konfig az NFSv4 ACL kezelést, akkor írd le légyszíves, hogy milyen fájlrendszeren van ez megoldva, illetve mit kell varázsolni hozzá.
Bocs, az kimaradt h. POSIX acl-t.
Az NFSv4-es megoldás az Solaris és ZFS természetesen, de az egyik kollégám már összerakott ilyet is.
Alapvetően az ügyfélnek elég volt a Posix ACL mapping, amit a netatalk alapból lefordít OS X acl-re, tehát user szemszögből működik a dolog. Ha nem akarsz bődületes varázslatokat, hanem elegendő egy normális, kiterjesztett jogosultságkezelés, akkor elég a POSIX acl mapping. Nyilván felhasználás kérdése. Náluk fontosabb volt a szerver oldali spotlight, az NFSv4 acl nem volt kifejezetten focus.
ACL ügyfél-általi állítgatásra van-e valami GUI, vagy parancssoros setfacl/getfacl -t használtok?
sub