abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 01:44 | Zajímavý projekt

Kampaň na podporu chytrého telefonu Librem 5, jenž by měl respektovat bezpečnost, svobodu a soukromí uživatelů, úspěšně skončila. Bylo vybráno více než 2,1 milionu dolarů, tj. cíl kampaně byl splněn na více než 141 %. Objednáno bylo cca 3 000 telefonů. Telefon Librem 5 by měl být k dispozici v lednu 2019.

Ladislav Hagara | Komentářů: 1
včera 21:11 | Komunita

Ke zhlédnutí jsou videozáznamy přednášek z konferencí All Systems Go! (media.ccc.de) a GStreamer Conference 2017 (ubicast.tv) konaných o víkendu 21. a 22. října. All Systems Go! v Berlíně a GStreamer Conference 2017 v Praze.

Ladislav Hagara | Komentářů: 0
včera 20:33 | Komunita

MojeFedora.cz informuje (en), že Fedora 27 přináší snadný přístup k Red Hat Enteprise Linuxu. Virtualizační nástroj Boxy nyní umožňuje jednoduše stáhnout a nainstalovat Red Hat Enterprise Linux, který je pro vývojáře zdarma. Vytvořit lze neomezené množství virtuálních mašin s RHEL.

Ladislav Hagara | Komentářů: 1
včera 19:00 | Komunita

Konsorcium Linux Foundation oficiálně představilo licence pro komunitní otevřená data Community Data License Agreement (CDLA). První licence je copyleftová CDLA-Sharing a druhá permisivní CDLA-Permissive. Odpovědi na často kladené otázky ve FAQ.

Ladislav Hagara | Komentářů: 0
včera 13:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. pražský sraz, který proběhne ve čtvrtek 26. října od 18:00 hodin v karlínském Pivovarském klubu. Najdete jej kousek od metra Florenc na adrese Křižíkova 17, Praha 8. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

Ladislav Hagara | Komentářů: 0
včera 06:00 | Zajímavý software

Byla vydána verze 0.56 open source platformy Home Assistant (GitHub) pro monitorování a řízení inteligentní domácnosti naprogramované v programovacím jazyce Python verze 3 a bežící také například na Raspberry Pi. Pro vyzkoušení je k dispozici demo [reddit].

Ladislav Hagara | Komentářů: 0
22.10. 16:55 | Nová verze

Byla vydána verze 1.0 klienta F-Droid určeného pro instalaci aplikací do Androidu ze softwarového repozitáře F-Droid (Wikipedie), alternativy k Google Play, nabízející pouze svobodný a otevřený software. Podrobnosti v přehledu změn [Hacker News].

Ladislav Hagara | Komentářů: 6
22.10. 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 10
21.10. 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

Ladislav Hagara | Komentářů: 0
21.10. 06:00 | Komunita

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (10%)
 (1%)
 (0%)
 (1%)
 (75%)
 (12%)
Celkem 235 hlasů
 Komentářů: 8, poslední 22.10. 23:02
    Rozcestník

    OpenAFS – prakticky o volumech a replikaci

    27. 10. 2011 | Michal Švamberg | Návody | 2084×

    Základní znalosti o AFS nám již umožňují, abychom si vyzkoušeli nějaký ucelenější blok příkazů. Dokončíme práci na kořenovém volumu tak, abychom se mohli podívat, jak vypadají ostatní AFS buňky ve světě. Přitom využijeme jednu z nejpoužívanějších vlastností AFS – replikaci volumů. Na závěr si ukážeme jak by měly vypadat konfigurace firewallu a NATu pro AFS.

    Obsah

    Replikace volumů

    link

    O replikaci mluvíme, když z RW volumu vytváříme RO volum(y) jako jeho kopie. Operaci vos release, která replikaci provádí, použijeme vždy, když chceme promítnout jakékoliv změny z RW do RO, a to včetně změny ACL nebo úprav mount pointů uvnitř volumu. Původní obsah RO není nijak zachován. K tomuto účelu se používají zálohovací mechanismy o nichž bude samostatný díl.

    Již dříve jsem psal, že volumy root.afs a root.cell jsou nejdůležitější a rozhodně by měly být replikovány. To zatím ani jeden z nich není, například root.afs má jen RW kopii (vizte řádek 3 a výpis VLDB na řádkách 11-13):

    ~$ vos examine root.afs | nl
         1  root.afs                          536870912 RW          3 K  On-line
         2      afssrv.foo.bar /vicepa 
         3      RWrite  536870912 ROnly          0 Backup          0 
         4      MaxQuota       5000 K 
         5      Creation    Tue Feb 22 22:11:22 2011
         6      Copy        Tue Feb 22 22:11:22 2011
         7      Backup      Never
         8      Last Access Mon Mar  7 08:02:42 2011
         9      Last Update Sun Mar  6 18:09:49 2011
        10      1 accesses in the past day (i.e., vnode references)
           
        11      RWrite: 536870912 
        12      number of sites -> 1
        13         server afssrv.foo.bar partition /vicepa RW Site 
    

    Na každém serveru lze vytvořit pouze jednu RO kopii, více jich stejně postrádá smysl, protože RO má sloužit zvláště jako prostředek pro zvýšení dostupnosti dat a rozložení zátěže mezi servery. Na serveru, který vlastní RW kopii, je vhodné vytvořit RO na stejné partition jako je RW, šetří se tak místem, na disk jsou zapisovány pouze rozdíly.

    Napřed nadefinujeme (s administrátorským oprávněním, takže nezapomenout na  kinit a aklog), na kterou lokaci (server a partition) umístíme RO kopii. My máme pouze jeden server s jednou partition, ale to pro vytvoření a kontrolu stačí:

    ~$ vos addsite -server afsfs.foo.bar -partition vicepa -id root.afs
    Added replication site afsfs.foo.bar /vicepa for volume root.afs
    
    ~$ vos examine root.afs | nl
         1  root.afs                          536870912 RW          3 K  On-line
         2      afssrv.foo.bar /vicepa 
         3      RWrite  536870912 ROnly          0 Backup          0 
         4      MaxQuota       5000 K 
         5      Creation    Tue Feb 22 22:11:22 2011
         6      Copy        Tue Feb 22 22:11:22 2011
         7      Backup      Never
         8      Last Access Mon Mar  7 08:02:42 2011
         9      Last Update Sun Mar  6 18:09:49 2011
        10      1 accesses in the past day (i.e., vnode references)
           
        11      RWrite: 536870912 
        12      number of sites -> 2
        13         server afssrv.foo.bar partition /vicepa RW Site 
        14         server afssrv.foo.bar partition /vicepa RO Site  -- Not released
    

    Oproti minulému výpisu nám přibyl pouze řádek 14, přitom si všimněte, že na řádku 3 je identifikátor RO volumu stále nastaven na nulu. To znamená, že existuje pouze záznam ve VLDB a nemáme žádnou validní RO kopii (přestože číselný identifikátor byl rezervován už při vytvoření RW volumu). Provedeme tedy release a opět zkontrolujeme výpis:

    ~$ $ vos release root.afs 
    Released volume root.afs successfully
    
    ~$ vos examine root.afs | nl
         1  root.afs                          536870912 RW          3 K  On-line
         2      afssrv.foo.bar /vicepa 
         3      RWrite  536870912 ROnly  536870913 Backup          0 
         4      MaxQuota       5000 K 
         5      Creation    Tue Feb 22 22:11:22 2011
         6      Copy        Tue Feb 22 22:11:22 2011
         7      Backup      Never
         8      Last Access Mon Mar  7 08:02:42 2011
         9      Last Update Sun Mar  6 18:09:49 2011
        10      1 accesses in the past day (i.e., vnode references)
           
        11      RWrite: 536870912     ROnly: 536870913 
        12      number of sites -> 2
        13         server afssrv.foo.bar partition /vicepa RW Site 
        14         server afssrv.foo.bar partition /vicepa RO Site 
    

    Nyní je vše v pořádku, máme RW i RO kopie sesynchronizované, což nám dokazují řádky 3, 11, 13 a 14. Vidíme přidělený identifikátor RO kopie; ten je vždy lichý a o jedna vyšší než identifikátor RW volumu.

    Tím nám ale vznikl trochu problém, protože AFS klient se primárně pokouší o přístup k RO volumu root.afs, což znamená, že bychom měli do /afs/ ztratit zápis. Ve skutečnosti klient používá mapovací tabulku s informacemi o volumech, které si typicky obnovuje jednou za hodinu. Pamatuje si, že k našemu RW volumu neexistuje RO, proto bude nejdéle ještě hodinu nabízet RW. Mechanismus mapování opět urychluje přístup k datům, protože se takto vyhneme opakovaným kontaktováním Volume Location serverů. Proto napřed použijeme příkaz fs checkvolumes, který mapování volumů pročistí. Dále uvolníme z klienta informace o volumech příkazem fs flushvolume. Cílem je, aby adresář (mount point) /afs byl brán z volumu root.afs.readonly což si ověříme příkazem fs examine. Při testech se mi stávalo, že to chvilku klientovi trvalo a to obzvláště, když pracovní adresář flush příkazů byl v dotčeném volumu.

    ~$ fs checkvolumes
    All volumeID/name mappings checked.
    
    ~$ fs flushvolume /afs/foo.bar
    
    ~$ fs examine /afs
    File /afs (536870913.1.1) contained in volume 536870913
    Volume status for vid = 536870913 named root.afs.readonly
    Current disk quota is 5000
    Current blocks used are 3
    The partition has 18395132 blocks available out of 19593852
    
    ~$ mkdir /afs/test 
    mkdir: cannot create directory `/afs/test': Read-only file system
    

    Abychom v kořenovém volumu mohli provádět změny, musíme si připojit jeho RW kopii, ale to můžeme udělat pouze v nějakém RW volumu, naštěstí máme ještě volume root.cell, kterému jsme RO repliku nevytvořili, klientovi tak nezbude nic jiného, než nám nabídnout RW. Pro jistotu si vynutíme mount point odkazující na RW (ale není nutné):

    ~$ fs mkmount -dir /afs/foo.bar/root -vol root.afs -rw
    
    ~$ cd /afs/foo.bar/root
    
    /afs/foo.bar/root$ ls -A
    foo.bar
    

    Tím se nám podařilo vytvořit smyčku, kterou nám detekuje také find .. To důležité je, že jsme v RW kopii volumu a můžeme začít provádět změny.

    Zvláště aby si administrátoři ušetřili práci a nemuseli pracně hledat RW volume nebo jej někde po kradmu připojovat jako teď, tak si připravují RW větev své buňky, uživatelům jej schovávají jako skrytý tečkový adresář:

    /afs/foo.bar/root$ fs mkmount .foo.bar root.cell -rw
    
    /afs/foo.bar/root$ ls -A
    .foo.bar  foo.bar
    

    Tuto logicky náročnější operaci se pokusím shrnout. Po vytvoření RO kopie nám ji začal automaticky klient nabízet. Problém nám nastal ve chvíli, kdy jsme chtěli do kořene zapsat. To lze udělat tak, že si vytvoříme nový mount point s vynucenou cestou k RW volumu. Vytvořit mount point lze v libovolném RW volumu a takový máme v podobě volumu root.cell v cestě /afs/foo.bar/. Po připojení RW volumu do /afs/foo.bar/root do něj můžeme zapisovat a to jsme chtěli. V této chvíli tedy máme RO a RW volumy připojeny na různých místech, a to dokonce tak, že nám tvoří smyčku, protože můžeme použít například cestu /afs/foo.bar/root/foo.bar/root/foo.bar/root. Na konci dílu dáme vše do původního stavu, předtím si ještě vytvoříme odkazy na jiné buňky abychom se mohli porozhlédnout po světě.

    Připojujeme si svět

    link

    AFS klienta máme přednastaveného tak, aby se nesnažil při startu zjistit jak to vypadá ve světě, ale použil přímo volume root.afs ze své domovské buňky. Toto je doporučené řešení, protože nezpomaluje start systému snahou o kontaktování ostatních buněk. Problém je, že se nedostaneme nikam jinam, pokud si nevytvoříme statické mount pointy, obvykle v cestě /afs/world/. Existující buňky ve veřejném prostoru jsou dobrovolně registrovány u grand.central.org. Tento seznam známý jako CellServDB se pak přidává do distribucí a my jej použijeme pro vytvoření mount pointů do světa.

    Ze seznamu musíme napřed vypreparovat názvy buněk (označeny prefixem >) a zbavit se všeho ostatního. Pro vytvoření mount pointu použijeme známý fs mkmount s parametry -cell a -fast, jenž nám vypne kontrolu volumu vůči VLDB a významně urychlí tvorbu mount pointů. Celá konstrukce není úplně nejhezčí, ale je funkční:

    /afs/foo.bar/root$ mkdir world && cd world
    
    /afs/foo.bar/root/world$ for i in `cat /etc/openafs/CellServDB | sed -rn 's/^>([^ ]*).*/\1/p'` ; do fs mkmount $i root.cell -cell $i -fast ; done
    
    /afs/foo.bar/root/world$ ls grand.central.org
    archive  cvs  doc  local  project  service  software  user  www
    

    První přístup do adresáře vždy trvá delší dobu, pak už to docela jde. Vytvářet mount pointy na cizí root.afs volumy je také možné, ale v nich většinou naleznete podobné věci jako máme teď my, tedy odkazy do  ostatních buněk.

    Z minula si ještě procvičíme nastavování práv. Přístup do adresáře world dáme pouze našim vlastním uživatelům, ať si každý administrátor své buňky vytváří svůj vlastní rozcestník. Primárně záleží na vaší bezpečnostní politice, zda dáte přístup všem nebo jen vybrané skupině (např. autentizovaným uživatelům v našem případě):

    /afs/foo.bar/root/world$ fs listacl .
    Access list for . is
    Normal rights:
      system:administrators rlidwka
      system:anyuser rl
    
    /afs/foo.bar/root/world$ fs setacl . system:anyuser none system:authuser rl
    
    /afs/foo.bar/root/world$ fs listacl .
    Access list for . is
    Normal rights:
      system:administrators rlidwka
      system:authuser rl
    

    Zrušili jsme oprávnění pro skupinu system:anyuser a místo něj přidali skupinu system:authuser. Příkaz lze rozdělit na dva samostatné, ale setacl umožňuje serializovat oprávnění, tak proč to nevyužít. Od teď musíte mít platný token pro buňku foo.bar pro přístup do adresáře world.

    Nyní volume root.afs musíme releasovat, aby se změny projevily v RO volumu v cestě /afs.

    /afs/foo.bar/root/world$ vos release root.afs
    Released volume root.afs successfully
    
    /afs/foo.bar/root/world$ cd /afs
    
    /afs$ ls -A
    .foo.bar  foo.bar  world
    

    A nyní nezbývá než úklid v podobě zrušení mount pointu na RW kopii volumu root.afs:

    /afs$ fs rmmount /afs/foo.bar/root
    

    Firewall

    link

    Pokud se hodláte otevřít světu, měli byste upravit pravidla pro firewall. Pro klienty je to relativně jednoduché, stačí povolit port 7001 na UDP z celého světa, protože AFS file servery se nás mohou snažit kontaktovat zpátky, tzv. callback. Větší překážkou bývají konfigurace conntracku u NATu, který uzavře spojení předčasně, proto je vhodné zvýšit na firewallu tyto hodnoty v souboru /etc/sysctl.conf

    net.ipv4.netfilter.ip_conntrack_udp_timeout=780
    net.ipv4.netfilter.ip_conntrack_udp_timeout_stream=900
    

    a zavést do systému příkazem sysctl -p.

    Pro přístup klientů k vašemu serveru je třeba nyní povolit UDP porty 7000 (fileserver), 7002 (ptserver), 7003 (vlserver), 7005 (volserver) a 7007 (bosserver). Pokud nechcete být příliš restriktivní, můžete povolit celou skupinu AFS portů v rozmezí od 7000 do 7009 na UDP, a to všem potencionálním klientům. V případě veřejné adresy serveru by to mělo být celému světu.

    Tím naprosto vyřazujeme funkčnost firewallu pro AFS porty včetně klienta. Důvodem u klienta nejsou jen zpětná volání (callbacks) jež se dají řešit nastavením firewallu, ale i možnost ladění a sledování. Součástí AFS je několik nástrojů pro vzdálené sledování jak serverů tak klientů. Pokud si někdo stěžuje na potíže, můžete si vzdáleně přečíst informace o klientovi. A z hlediska správce by byla velká škoda se o takovou možnost připravit.

    Závěr

    link

    Koncept RW a RO volumů se může zdát v této chvíli trochu zmatený, ale berte to z pohledu velké organizace. Potřebujete mít co nejvyšší dostupnost, což vám zajišťují RO kopie rozprostřené přes více serverů, ale jako správci máte potřebu provádět v systému úpravy. Typickým příkladem je například softwarové vybavení, uživatelům nabídnete verzi v RO kopiích volumu, přitom sami můžete připravovat novou verzi v RW volumu. Až to budete mít vyzkoušené, provedete release a všichni uživatelé dostanou připravenou a odzkoušenou verzi programu. Když do toho zapojíte i systém mount pointů můžete mít pro každou verzi samostatné volumy (např. prog1.1, prog1.2) a jen uživatelům vyměňovat mount point. Pokud si někdo bude stěžovat na  problém, můžete jej řešit a ladit v RW části dané verze. Nezřídka se stává, že potřebujete tentýž program provozovat v různých verzích. Nepropadejte panice, v příštích dílech budeme s volumy opět pracovat a časem vám to přijde naprosto samozřejmé.

    Nyní můžete zkoumat, jak to mají vyřešené na jiných AFS buňkách, můžete používat všechny informativní příkazy i na cizí buňky (například vos examine root.cell -cell grand.central.org nebo fs listacl). V příštím díle se vrátíme zpátky k oprávněním, uživatelům a skupinám, přitom budeme stále vylepšovat naši buňku.

    Centrum informatizace a výpočetní techniky pro Západočeskou univerzitu v Plzni buduje a provozuje od roku 1996 prostředí Orion založené na  autentizačním systému Kerberos a distribuovaném síťovém souborovém systému AFS s více než 22 tisíci aktivních uživatelů.
           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    Max avatar 27.10.2011 07:55 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: OpenAFS – prakticky o volumech a replikaci
    Výborný seriál. Měl bych ovšem několik dotazů :-/.
    1) Umí klient pro windows spouštět po přihlášení scripty/programy? Ovšem pokud je stanice v doméně, tak je to samozřejmě zbytečné, ale zajímá mně to.
    2) Lze nějak obnovit smazaný soubor/adresář? Příklad : Netware má takovou mezipaměť, smazaný soubor se většinou nesmaže a zůstane na FS a lze lehce obnovit. Windows zase mají shadow copy, která se může dělat v určitých intervalech (třeba každou hodinu, takže rollback je max hodinu), těchto stínových kopií může být třeba 30, co jen volné místo umožní, takže to lze použít i jako historii.
    3) Přihlásím se na win stanici, všechno ok, disky se namapují atd., ale problém, kromě několika aplikací mi na serveru běží třeba nějaká služba pod nějakým uživatelem (třeba Webserver pod uživatelem ASPNET) a s tou službou potřebuji zapsat soubor na síťový disk. Zápis se většinou volá na UNC cestu. V případě win serveru by se uživatel sám ověřil pomocí NTLM a provedl úspěšně zápis do UNC cesty. Jak by to ovšem vypadalo u OpenAFS?
    Díky
    Zdar Max
    Měl jsem sen ... :(
    27.10.2011 13:21 List | skóre: 27
    Rozbalit Rozbalit vše Re: OpenAFS – prakticky o volumech a replikaci
    Děkuji za pochvalu, avšak nevim, jestli vás potěším. S Windows nedělám, tak jsem alespoň požádal kolegu o jeho zkušenosti.

    1) AFS klient neumí spustit skript po přihlášení, ponechává se to na systému/administrátorovi, že si nějak poradí

    2) obnova není možná, jediná šance je použití backup volumu, jehož frekvenci vytváření můžete nastavit (typicky 1x za 24 hod, nejčastěji o půlnoci), backup volume může být jen jeden. Druhá možnost je vytváření pravidelného dumpu z cronu nebo zálohovacího SW a v případě potíží jej rozbalit. Další způsob je použití 'vos copy' z cronu a vybrané volumy takto klonovat a případně je rovnou připojovat do nějaké adresářové struktury. Zároveň by bylo vhodné napsat i skript, který odpojí a zruší staré volumy. V podstatě záleží na tom, kolik prostoru chcete obětovat a jak moc chcete být user friendly.

    3) v linuxu se to řeší tak, že se vytvoří principal, tomu se vygeneruje klíč do keytabu z nejž si pak skript vyrobi listek a z listku token. Podobně by to mohlo jít i u windows, ale budete k tomu potřebovat Active Directory. A asi to nebude tak jednoduché a průhledné. Druhá, trochu bezbolestnější, ale méně bezpečná, cesta je, nastavit do daného adresáře práva zápisu pro IP adresu serveru (nelze to ale udělat přímo, musí se použít skupina). Místo jména uživatele použijte jeho IP, ale musíte ji zařadit do skupiny a právo nastavit až dané skupině, jinak to nefunguje. Ale pak tam bude mít zápis celý stroj!

    Michal Švamberg
    Max avatar 27.10.2011 13:45 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: OpenAFS – prakticky o volumech a replikaci
    Děkuji za odpověď, opravdu moc nepotěšila :-/. Jde o to, že nyní jedeme na Netware 5.1 a plánujeme se ho zbavit (přeci jen, nějaké mušky má a začíná se u nás šířit nekompatibilita mezi různými službami, co potřebují přistupovat na sdílený disk).
    Cílem je větší server, na který se přenesou všemožné odkladiště, které máme všude možně bokem. Začal jsem si pohrávat s myšlenkou, že už by to chtělo nějaký druh HA, což v podobě MS + FS Cluster není zas tak levné a nemusely by na to být finance.

    Rozhodně přejdeme na Active Directory a poté jsem si pohrával s myšlenkou OpenAFS jako souborový server s tím, že se ušetří many za licence a zbydou tak na pořádný HW, který umožní HA.
    Mno, stejně asi žádná alternativa k MS serveru neprojde a možná je to dobře.
    Zdar Max
    Měl jsem sen ... :(
    27.10.2011 18:04 List | skóre: 27
    Rozbalit Rozbalit vše Re: OpenAFS – prakticky o volumech a replikaci
    Ještě k bodu 3, pokud použijete ověření na základě IP adresy, pak nepotřebujete AD ani token, zkrátka vás tam fileserver pustí na základě IP adresy. Pokud by vás něco zajímalo, klidně se na mě obraťte.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.