Ez egy Kecs.es blog webfejlesztési ötletek, tanácsok, észrevételek

7jan/120

iOmega StorCenter ix2-200 NFS Share csatolása routeren keresztül Citrix XenServer 6.0 kiszolgálóra

A feladat nem tűnik bonyolultnak, viszont abban a pillanatban, hogy a két eszköz közé egy routert teszünk, máris nem olyan barátságos, hiszen a változó RPC (rpc.mountd, rpc.statd, rpc.rquotad) portokat fixálni kell. Valamint az sem elhanyagolható tényező, hogy a megosztásunk a lehetőségekhez mérten a legbiztonságosabb legyen. Tehát a cikk erre is megpróbál majd kitérni.

NFS Share létrehozása az iOmega StorCenter ix2-200 eszközön:

  1. Lépjünk be a webfelületre (http://<IPofNAS>)
  2. Kapcsoljuk be az NFS megosztását (Network -> Protocols ->NFS = ON)
  3. Hozzunk létre egy új megosztást (Storage -> Shares ->Add a Share)
  4. Mivel még nem kapcsoltuk be a Security-t emiatt jelenleg az összes megosztás elérhető NFS protokoll segítségével
  5. Az NFS nagyon sok portot használ, amelyeket random választ ki a port mapper. Ez nekünk nem jó, mert egy cím fordított (NAT) hálózaton keresztül szeretnénk elérhetővé tenni az NFS megosztást. Emiatt kell a portmaper-t átkonfigurálni. Ehhez mindenképp SSH hozzáférésre lesz szükségünk, amelyet már leírtam, hogyan szerezhetünk meg. Ha beléptünk, akkor az 'rpcinfo -p' parancs segítségével állapíthatjuk meg, hogy jelenleg a mely portokon hallgatnak az RPC szolgáltatások, amelyeket át kell állítani.Az átállításhoz az következő parancsok lesznek segítségünkre:
    - rpc.mountd -p <port>
    - rpc.rquotad -p <port>
    - rpc.statd -p <port>

    Ezzel csak annyi a gond, hogy a következő újraindításig jegyzi meg a beállítást, tehát nem valami életképes a megoldás. Sajnálatos módon, a hivatalos konfigurációs állomány a /etc/sysconfig/nfs nem létezik és ha kézzel létrehozzuk, sem használja a rendszer így másik megoldáshoz kell folyamodnunk. Gondoltam, hogy akkor meglovagolom a rendszerindítást. Először is ezért le kell menteni a parancsokat egy fájlba:
    cat <<EOF > /etc/rc.nfs
    rpc.mountd -p <port>
    rpc.rquotad -p <port>
    rpc.statd -p <port>
    EOF

  6. Ez az ötletem sem nyert, mert hiába vannak meg a /etc/rc.local és /etc/rc<x>.d/ könyvtárak, akkor sem futott le a rendszerindítás után a parancsom...  Csak két megoldást sikerült kitalálnom, amelyek közül az egyik rosszabb mint a másik, de ez van. Nem valami szép megoldás, de legalább működnek. Az első, hogy eltávolítjuk a merevlemezeket és egy linux alapú rendszerre felcsatoljuk, ugyanis az md0 kötet rejti a /mnt/apps könyvtárat, amely tartalmazza a rendszerpartíciót, ahol módosítani kellene a betöltést. De ezt nem tudjuk az iOmega eszközben megtenni, mivel a partíció read only és újracsatolni sem tudjuk, mert device is busy. Ehhez egy leírást itt találtok.Mivel én nem szeretem megbontani az eszközt és piszkálni a rendszer, ami garancia vesztéshez vezethet, így inkább egy másik megoldást kerestem a problémára, ami talán egy picit humánusabb. Újraindítottam a rendszert és megnéztem, hogy mi zajlik le a boot folyamat során. Hátha találok egy olyan állományt, ami később inicializálódik mint az RPC (hiszen csak ezután lehet a portokat átállítani) és az az állomány talán egy szerkeszthető  partíción lesz. Ennek megállapításához a '/var/log/messages' állományt használtam. meg is találtam benne, hogy az RPC inicializálódása után az egyetlen folyamat ami elindul még az a stls_all.sh állomány. Ezt meg is kerestem, hol található:

    find / -name 'stls_all.sh' 2>/dev/null

    Megtaláltam, hogy az otthona a  /mnt/system/opt/apps/axis/stls/stls_dist/bin/ könyvtárban leledzik.

    Így már gyorsan módosítható is a fájl. Először az állomány legvégén hívtam meg a beállításomat, de rá kellett jönnöm, hogy korábban kilép a szkript, így ott nem hajtódik végre. Emiatt a legelejére betettem, hogy /etc/rc.nfs.
    Tehát most már minden rendszerindításnál meghívásra kerül az állományom, és az összes szolgáltatás már fix porton hallgat. Így képes leszek a port-forwarding konfigurálásra a routeren.

  7. Kapcsoljuk be a Security-t hogy tényleg csak azt osszuk meg amit szeretnénk és kontrollálni tudjuk azt, ki férhet hozzá a megosztáshoz. Ehhez navigáljunk a System -> Security felületre és kapcsoljuk be (ON). Adjuk meg az rendszergazdai fiók nevét valamint a jelszavát. Javaslom, hogy a titkosítást is pipáljuk be.
  8. Hozzunk létre a rendszerünk számára a megfelelő felhasználói accountokat. (Common -> Users)
  9. A megosztásnál tiltsuk meg a publikus megosztást. Ehhez navigáljunk a Storage -> Shares alá, ahol válasszuk ki a megosztást és az Access Permissions alatt az Everyone user read és write jogán vonjuk meg.
  10. Engedélyezzük, hogy a megosztáshoz csak és kizárólag a Citrix XenServer férhessen hozzá. Ehhez maradjunk ahol voltunk, csak az Access Permissions alatt található NFS blokkot válasszuk ki. Itt kattintsunk az Add an NFS Rule gombra. A Hostname mezőbe pedig beírható, hogy mely állomásokról engedélyezzük a hozzáférést. A minta lehet IP vagy domain, de akár egy teljes címtartomány, ha <IP>/<MASZK> módban írjuk le. A rendszer elfogadja a teljes 255.255.255.0 maszkot illetve a /24 formát is.
  11. Opcionális észrevétel, ha több megosztást is használunk, akkor mindenhol tiltsuk le a hozzáférést az Everyone felhasználónak, ugyanis ha az bármelyik megosztás esetében bent marad, akkor az távolról NFS segítségével szabadon felcsatolható. Valamint jelen pillanatban a megosztást lokálisan nem lehet elérni, mert nincs senkinek sem joga hozzá. Így érdemes egy felhasználót / csoportot hozzáadni az Access Permissions alatt, aki lokálisan is képes a Repository-t szerkeszteni.
  12. Az NFS szervert állítsuk be, hogy minden felhasználót kezeljen vendégként, azaz ne legyen teljes hozzáférése. Ehhez navigáljunk a Network -> Protocols alá, majd az NFS mellett található fogaskerékre kattintsunk, amellyel lekérhető a beállítása (settings). Itt pedig válasszuk ki a 'Treat client users as guest (all_squash)' lehetőséget.

NFS Port-Forwarding konfigurálása routeren:

  1. Jelentkezz be a routered admin felületén
  2. Keresd meg a port-forwarding opciót, vagy a portrange-forwarding lehetőséget, ha van
  3. Állítsd be a portokat:
    - 111 TCP & UDP -> IPofNAS (portmap)
    - 2049  TCP & UDP -> IPofNAS (NFS)
    - TCP & UDP RPC.Mountd -> IPofNAS
    - TCP & UDP RPC.Statd-> IPofNAS
    - UDP RPC.Rquotad -> IPofNASSzemély szerint javaslom, hogy az RPC portokat 2050-2052 közé állítsd be, mert akkor az NFS portal együtt, mint portrange forwarding lehet beállítani, így 1 db bejegyzéssel leírható, a normális 4db helyett.
  4. Hogy kívülről is hozzá tudjunk férni hálózatunkhoz, szükségünk lesz egy FIX IP címre. Ha ilyet nem tudunk / nek akarunk bérelni a szolgáltatótól, akkor pedig a routeren egy DDNS accountot kell készíteni. Ennek menetét nem írom le, de javaslom a dyndns.org használatát.

NFS Share csatolása a Citrix XenServer 6.0 szerveren:

  1. Csatlakozzunk a szerverhez / poolhoz a XenCenter segítségével.
  2. Hozzunk létre egy új Storage-t (Storage tab -> New SR)
  3. A varázsló segítségével adjuk meg, milyen storage-ot szeretnénk csatolni (ISO Library or NFS VHD)
  4. Adjunk nevet a megosztásnak.
  5. Majd a Location résznél a megosztás elérhetőségét kell megadni. Ez két részből áll. Első a szerver elérhetősége IP címmel vagy domain névvel. A második az NFS megosztás elérhetősége a szerveren.
    <PublicIPofNAS>:<NFSLocation>
    Az IP címet vagy tudjuk, vagy dyndns segítségével naprakészen tartjuk. Az NFS megosztás helyét pedig az iOmega eszköz pontosan megadja, csak navigáljunk a webes felületen a Storage -> Shares alá. Itt válasszuk ki a megosztásunk nevét, majd alatta lesz egy NFS block, amelyre ha kattintunk, előjön a megosztás helye.
    Locaton:<NFSLocation>
  6. A megszerzett információkkal sikeresen csatolható az NFS megosztás.
6jan/120

Citrix XenServer 5.6 SP2 frissítése 6.0 kiadásra

Ez a post is a szerver üzemeltetőknek kedvez, de ez van :)

Minap megpróbáltam frissíteni egy Citrix XenServer 5.6 SP2 kiadást a 6.0 verzióra, mondván vannak benne olyan új funkciók amelyeket ki tudnék alkalmazni. Majd amikor elkezdtem keresni a frissítést jöttem rá, hogy ez nem a megszokott töltsd le a .xsupdate állományt, hanem annál egy kicsit bonyolultabb.

Nézzük sorra, mit kell csinálni, hogy te is sikerrel járj:

  1. Amennyiben csak 1 hostod van, akkor állítsd le vagy hibernáld az összes virtuális gépet. Amennyiben több és pool-ba kapcsoltad őket, akkor a XenMotion elvileg megoldja hogy folyamatosan átkapcsolja egy aktív node-ra a virtuális gépeket ameddig az aktuális host frissít.
  2. Készíts mentést minden virtuális gépről (biztos ami biztos).
  3. Töltsd le a XenCenter 6.0 Windows Management Console alkalmazást a www.citrix.com oldalról.
  4. Csatlakozz a szerverhez vagy pool-hoz, majd a Tools menüpont alól válaszd ki a Rolling Pool Update varázslót.
  5. Válaszd ki a poolt vagy a hostot.
  6. Határozd meg a frissítés módját. Ami lehet automatikus vagy manuális. Személy szerint automatikussal végeztem el.
  7. A következő lapon futtassuk le a tesztet, ha minden rendben van akkor indítható a frissítés. Ha nem akkor a hibaüzenet alapján kezdjük meg az elhárítást. Nálam csak egy patch-et kellett feltelepíteni.
  8. Adjuk meg a telepítés forrását. Ezt lehet NFS/FTP/HTTP. Gyakorlatilag ez annyit jelent, hogy a XenServer-6.0.0-install-cd.iso lemez tartalmát a korábban említett 3 protokoll segítségével a hálózaton keresztül elérhetővé kell tenni.
  9. Ha mindent jól csináltunk a szerver sikeresen frissíti magát 6.0 verzióra.
  10. Ellenőrizzük a szerver verzióját, a General fül alatt található Version details boxban. A XenServer version: 6.0 értéket kell viszontlátni!
1jan/120

Virtualizáció és az Openfiler hálózata

Aki komolyabban elmerült már a virtualizációban az szinte biztosan találkozott már az Openfiler névre hallgató ingyenes NAS/SAN Appliance megoldással. Egy nagyon jó termékről van szó, azt az egyedüli problémát leszámítva, hogy virtualizált környezetben néha elég kényes. Főleg arra gondolok, hogyha a virtuális gépet mozgatjuk (másoljuk, áthelyezzük, esetleg mentésből visszaállunk) akkor a hálózat teljesen használhatatlan lesz. Ennek az az oka, hogy a virtualizációs környezet egy új MAC address-t generál a hálókártyának, amely eltér a régitől. Mivel a régi MAC Address el van tárolva az Openfiler konfigurációs állományában, ezért detektálja a turpisságot és közli velünk, hogy gond van. Na innentől az eth0 interfészt többet nem lehet online állapotba kapcsolni, tehát a hálózatnak lőttek. Emiatt sokszor gondot okozhat egy Openfiler rendszerre alapozott környezet kialakítása amit utána ki kell küldeni a hálózat gépeire.

A megoldást több helyről is közelíthetjük. Ha például VMware rendszert használunk, akkor .vmx állományt kézzel is megszerkeszthetjük, hogy statikus MAC címet használjon. Bár ez nehézkes, mert ez rendszerenként eltérhet, sőt nem is lenne valami jó, egy kiküldött image miatt több gép ugyan azt a MAC címet használná...

A másik megközelítés az Openfiler konfigurációs fájl módosítása:

vi /etc/sysconfig/network-scripts/ifcfg-eth0

Első lépésben pedig #-el kommenteljük ki a HWADDR mezőt. Ez gyakorlatilag meg is oldja a problémánkat.

De ha már itt járunk, gondoltam egyszerűbb leírni, hogyan állítsunk be FIX IP címet:

DEVICE=eth0
BOOTPROT=static
IPADDR=192.168.1.201
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
NETWORK=192.168.1.0
BROADCAST=192.168.1.255
ONBOOT=yes
TYPE=Ethernet

Tagged as: , No Comments
1jan/120

Hogyan engedélyezzünk utólagosan Thin Provisioning-et a lokális Storage-on Citrix XenServer 5.5 és 6.0 esetén

Először is szögezzük le, hogy ez az írás nem a webfejlesztéssel kapcsolatos, hanem a virtualizációval. Konkrétan a Citrix által készített XenServer környezethez. A magyarországi kkv-k többsége nem engedheti meg magának, hogy hatalmas szerverparkokat tartson karban, sőt sokszor egy szerveren túl nem tudnak többre beruházni. Tehát az adatokat nem egy külön Storage-ra helyezik, hanem nagy valószínűséggel a szerverben található merevlemezekből készítenek egy tárolót, jó esetben egy RAID5/10 tömbbel. Így ez a kicsinyke leírás főként nekik lesz hasznos, ha elfelejtették volna a thin provisioning-et bekapcsolni.

De mi is ez ha már így szóba került. Alap esetben ha készítünk egy virtuális szervert, akkor annak allokálni kell egy merevlemez kapacitást. Legyen ez mondjuk 10GB. Abban az esetben, ha egy debiant telepítünk fel, akkor kb 1-2 GB helyet használunk fel. Ha pedig egy Windows 7-et, majdnem az egészet. Mindegy melyik történik, alap esetben a 10GB-ot fizikailag lefoglaltuk a tárolóban a virtuális gép számára. Ha kihasználja, ha nem. Ezt nevezzük tick provisioning-nek. Látható, hogy ez csak akkor működik jól, ha pontosan meg tudjuk saccolni mekkora lesz a végső virtuális szerver tárkapacitása.

Ezzel szemben a thin provisioning lehetővé teszi, hogy virtuálisan allokáljuk a 10GB-ot, de a merevlemezből ténylegesen csak a felhasznált 1-2 GB kerüljön lefoglalásra. Ez sokkal gazdaságosabb, mivel ha van egy 2TB-os Storage-om, akkor ezzel a módszerrel nyugodtan ki lehet ajánlani akár több merevlemez kapacitást a virtuális szervereknek, mint amivel rendelkezünk hiszen csak annyit foglalnak a valós tárolón mint amennyi tényleges adatot foglalna. Így nem lesz baj, ha a későbbi igények növekednek egy virtuális gép esetén, mert nem kell a teljes allokációt újragondolni. Természetesen ennek a megoldásnak nem csak előnyei vannak, hanem egy kicsi árnyoldala, hiszen mindig számon kell tartani a szabad és használt kapacitást a szerveren. Ennek van egy minimális Overhead-je. De ez, a kapott előnyökkel szemben minimális. Tehát ha mindenek előtt a performancia számít, akkor használjunk thick provisionong-et, de ha inkább a gazdaságosság a szempont akkor pedig thin provisioning-et.

De ne szaporítsuk a szót, nézzük hogyan kell utólagosan beállítani a thin provisioning-et Citrix XenServer 5.5 esetén, ha ezt a telepítés során elfelejtettük volna.

1) Állítsunk le minden virtuális gépet és készítsünk róluk másolatot.

Ez azért fontos, mert a lokális Storage-ot meg kell szüntetni, így amit rajta tárolunk az elveszik. Emiatt mindenről készítsünk egy mentést, amelyeket a művelet elvégzése után visszamásolhatunk a Storage-ra.

2) Keressük meg, hogy a Storage Repository melyik partíción található.

cat /etc/xensource-inventory | grep "DEFAULT_SR_PHYSDEVS"
DEFAULT_SR_PHYSDEVS='/dev/sda3'

XenServer 6.0 esetén:
fdisk -l utasítással megkeressük melyik device használ LVM kötetet (alapból ilyen lenne)
fdisk -l | grep "LVM" | awk {'print $1'}
/dev/sda3

3) Szerezzük meg az UUID számát a Storage Repository-nak.

xe sr-list type=lvm
uuid ( RO) : 42080775-542e-5ad9-72a6-a3e483dbd880
name-label ( RW): Local storage
name-description ( RW):
host ( RO): xs-tarenz01
type ( RO): lvm
content-type ( RO): user

4) Szerezzük meg a Physical Block Device UUID azonosítóját, amihez az előbb megismert SR UUID-t használjuk fel.

xe pbd-list sr-uuid=42080775-542e-5ad9-72a6-a3e483dbd880
uuid ( RO) : 8e4c6231-2460-7380-c904-150a31c9bd63
host-uuid ( RO): ba3d140c-3de5-499b-b831-7c40d82958a9
sr-uuid ( RO): 42080775-542e-5ad9-72a6-a3e483dbd880
device-config (MRO): device: /dev/disk/by-id/scsi-SATA_Hitachi_HDT7250_VFA100R1C0GKTB-part3
currently-attached ( RO): true

5) Válasszuk le a PBD eszközt a szerverről, így a XenCenter-ben egy felkiáltó jelet kell majd látnunk a Local Storage mellett.

xe pbd-unplug uuid=8e4c6231-2460-7380-c904-150a31c9bd63

6) Semmisítsük meg a Local Storage-t. (Ehhez már a Local SR UUID-t használjuk)

xe sr-destroy uuid=42080775-542e-5ad9-72a6-a3e483dbd880

XenServer 6.0 esetén:
Az sr-destroy utasítás nem működik, mondván VDi merevlemez található a köteten, pedig mindent eltávolítottam. Ezért helyette az sr-forget utasítást használtam.
xe sr-forget uuid=42080775-542e-5ad9-72a6-a3e483dbd880

7) Hozzuk létre a Storage-t újra, csak már Thin Provisioning-el. Ehhez szükség lesz a Host-UUID-re és a Partícióra.

xe sr-create host-uuid=ba3d140c-3de5-499b-b831-7c40d82958a9 content-type=user type=lvm device-config:device=/dev/sda3 shared=false name-label="Local storage" sm-config:allocation=thin

8) Másoljuk vissza a virtuális gépeket, majd ellenőrizzük a tároló kapacitását.

Az eredeti cikk ami alapján ez a leírás is született a xendesktopmaster.com oldalon megtalálható.

28dec/110

Magas rendelkezésre-állású szerverek felügyelete

Mint mindenki, én is szeretek mindent a lehető legolcsóbban megoldani (persze ésszerű keretek között). Ehhez pedig az egyik legjobb eszközt a Pingdom biztosítja. Konkrét feladat az volt, hogy egy szerver esetén garantálni kell az éves 99.9%-os üzembiztonságot. Ehhez pedig megfelelő monitorozó rendszer kell, hogy ha baj van, akkor arról azonnal értesüljünk. Lehet vitatkozni arról hogy a riasztás E-mail vagy SMS, még akkor is amikor Androidos telefonnal rohangálok, az E-mailek gyakran csak félóra átfutással érkeznek meg. Tehát az SMS riasztás elengedhetetlen egy ilyen rendszer esetében. Tehát nézzük az elvárásokat:

Feladattal szemben állított követelmények

  • Minél sűrűbb mintavételezést lehessen elvégezni, hiszen annál pontosabb az érzékelés
  • Email értesítő mellett SMS értesítést is lehessen intézni, méghozzá Magyarországra
  • Online statisztikát biztosítson, hogy a honlapra kihelyezhető legyen
  • Admin felületen átfogó képet adjon mikor mi történt

Nem tartott sokáig ameddig megtaláltam a szerintem tökéletes megoldást a fenti problémákra. Méghozzá teljesen ingyenesen! Jobban mondva, akkor ingyenes, ha beérjük egyetlen hostnév felügyeletével. De elérhető a Basic csomag ami 5 hoszt felügyeletet tartalmaz 9.95$-ért havonta, illetve a Business csomag ami 30 állomást képes monitorozni 39.95$-ért havonta. De nézzük sorra mit tartalmaz az ingyenes hozzáférés:

Ingyenes megoldás a Pingdom kínálatában

  • 1db host/domain felügyelete
  • 1 perces ellenőrzés (ami még néhány fizetős szolgáltatás is maga mögé utasít)
  • 50+ szerver a világ minden pontjáról amelyek random ellenőrzik a host elérhetőségét
  • TCP/UDP/Ping/DNS/HTTP/HTTPS/SMTP/POP3/IMAP ellenőrzés
  • Email/SMS/Twitter értesítés (20 db SMS ingyenesen a regisztráció után egyből rendelkezésre áll)
  • iPhone/Android alkalmazás ami az értesítést is képes fogadni
  • Desktop alkalmazás ami a háttérben figyel és értesít ha gond van
  • Definiálható, hogy hány kiesett ciklus után küldjön értesítőt (elkerülve a fals pozitív eredményeket)
  • Beállítható, hogy értesítsen ha minden helyreállt
  • Szabadon beállítható a port is, tehát custom portokra is működik
  • Támogat HTTP authentikációt
  • A letöltött weboldalban stringet keres és ha nem találja akkor értesít. (Honlap megváltozik, elérhetetlen, esetleg 404 vagy 500-as error)
  • POST adatot is tud küldeni
  • User-Agent szabadon beállítható így a forgalmi statisztikából könnyen kiszűrhető
  • Uptime/Downtime/Response time riportok akár 1 évre visszamenőleg
  • Kiesés esetén részletes hibanapló, melyik szerverről mikor és miért nem volt elérhető.
  • Publikus összesítő amit ki lehet helyezni a honlapra

Engem ez a lista meggyőzött így már használom. Szerintem verhetetlen ajánlat. Főleg ingyen. További SMS vásárlása sem drága, teljesen megfizethető. Gondom még nem volt a szolgáltatással, egyedül max annyi, hogy magyarországi szerverrel nem rendelkeznek, így csak a külföldi rendelkezésre állást lehet vele mérni. Ez néha gondot okozhat, ha zavar van a nemzetközi vonalon, illetve a TIER 1 gerinchálózatok routing táblái frissülnek... Nekem már volt ilyen miatt leállási értesítőm, de nem tartott tovább 10 percnél. Ez nem a Pingdom hibája, csak hát azért egy ilyen kellemetlen perceket tud okozni, mikor azt az értesítőt kapod, hogy a szolgáltatás leállt, majd meg szakadsz hogy ellenőrizd, és kiderül, minden rendben, csak a külföldi routing frissül és pár percig még nincs routing feléd...

6szept/090

Outlook mappa, naptár, címjegyzék megosztása

Egyik partneremnél a hétvégén eltöltöttem egy kis időt. Adott volt a probléma, miszerint meg kell osztani a belső hálózaton az Outlook naptárat. És természetesen akinek joga van hozzá, az írhasson bele a másik naptárjába. Alap esetben ez nem lenne probléma, ha van az embernek Exchange szervere. De mivan akkor ha egy kis vállalkozásról beszélünk, akik nem engedhetnek meg maguknak csak emiatt egy több százezer forintos szervert jogtiszta Windows Szerver oprendszerrel? Arról nem is beszélve hogy egy 2-3 munkaállomáshoz gyakorlatilag ágyúval lövök galambra szindróma.

Mit lehet tehát ebben az esetben tenni? Kutakodtam a neten jobbra meg balra, több alkalmazást kipróbáltunk, míg végül a CodeTwo alkalmazása a Public Folders tökéletesnek tűnik. Szemben a konkurensek alkalmazásaival, nem olyan mértékben lassítja a rendszert, így gyengébb gépeken is tökéletesen elmuzsikál, valamint a háttérben zajló realtime szinkronizáció gyorsabb mint bármelyik versenytársé. És ezek mellett még a legolcsóbb license is van. Mindössze 160 Dollár a legkisebb 3 klienst támogató verzió. Ami azért szögezzük le elég baráti ár az Exchange szerverhez képest. De mit is kell nekünk csinálni ha be akarjuk üzemelni?

Nincs más dolgunk, mint a gyártó honlapjáról letölteni a (30 napos) próbaverziót. Minden gépre telepíteni kell a klienst, ami nem több mint egy panel ami beépül az Outlookba (innen lehet a saját mappákat megosztani, és jogosultságokat is kezelni, valamint a megosztott tartalmakra "feliratkozni"). A szerver verziót csak arra a gépre kell telepíteni, melyet úgy gondolunk hogy a legtöbbet fog futni. De vele sem kell nagyon törődni, mert 4 tovább kattintással települ :)

A szerveren gyakorlatilag az összes megosztást lehet menedzselni, mást nem nagyon lehet vele. Igaz nem is kell mást :)
A kliensekbe csak a szerver elérhetőségét kell megadni, hogy működjön a szinkronizáció. Ami lehet IP cím, de a fejlesztők tényleg gondoltak a kis felhasználókra, mert WINS-el is el lehet érni a gépeket a hálózaton, azaz elég a gép nevét megadni, s dinamikus IP mellett is megtalálja a szervert!

Ennél egyszerűbb, alkalmazást rég láttam, s közben teszi a dolgát hiba nélkül. Ilyennek kéne lennie minden programnak!