Archiv pro rubriku: Servery

Android-sysadmin-tools: Nástroje systém administrátora #1

Android sysadmin-tools ?
Krátce o nástrojích ze života sysadmina.

Nástroje systém administrátora pro Android


Co není v hlavě, musím být v nohách říká klasické pravidlo ! Systém admin je však tvor od přírody líný a proto šetří své podrážky jak to jen jde a pokud může, tak má ve svém kapesním “android stopaři” pár více či méně šikovných “švýcarských nožů”.

Následující minisérie s předem nedefinovaným počtem dílů ukazuje pár užitečným nástrojů, začněme však od konce, ty provařené (ssh klienti, rdp, vnc, nmap, cidr calc, atd.) jsou důvěrně známe a nebudeme nosit sovy do athén.

Pokračování textu Android-sysadmin-tools: Nástroje systém administrátora #1

Objektová úložiště jednou spolknou svět :-).

Objektová úložiště spolknou svět ?


! Nepropadejte panice ! 

Tradiční filesystémy a relační databáze zde budou s námi po mnoho dalších let o tom nemá smysl diskutovat, problém, ale vzniká dnes již na úrovni dat samotných, jsou totiž vysoce nestrukturovaná, bohužel nebo bohudík ?

Odhady říkají, že 80-90% dat kolem nás je nestrukturovaných, přesto se je snažíme popsat strukturou tabulek a relací, v nejhorším případě si uložíme string/json a ten si “žvýkáme” v aplikaci, otázka je zda-li je tento postup správný a nebojujeme proti vlastní “touze” dat být neorganizována.

Připomeňme si známý výrok Billa Jensena z knihy Simplicity.

Množství informací se zdvojnásobuje po každých 1100 dnech, tedy zhruba po třech letech, nicméně, čas, který nám zůstává k zpracování těchto narůstajících informací je stále stejný: 1440 minut denně".

Toto tvrzení bohužel již také není zcela platné, množství informace se zdvojnásobuje za polovinu času. :-(.

Strukturovaná data, ale mají stále a budou mít místo, jsou systémy, které generují “jen” tuto formu dat, senzory, čítače, čtečky, transakce, účto, sklady, … takové vše “bez lidí” z pohledu vývojářů je idylka, vše pevně zaškatulkováno, nikde nic nepřetéká, indexy indexují, ovšem reálný svět takový není.

NEstrukturovaná data jsou opačný extrémní protipól, svět plný chaosu jako kvantové fluktuace, je to náš svět takový jako jsou sami lidé, svět plný textů, audio a video obsahu, emailů, stránek, sociálna … je to “lidský” rozměr dat, pro vývojáře pekelný, nikdo přeci nechce “cpát” profilovou fotku či 100MB video jako blob do tabulky.

Nestrukturovaná data a web aplikace

Tradiční pohled dnešních web aplikací je generování strukturovaného výstupu dat na základě uživatelského vstupu (formuláře/upload) a ukládání na tradiční úložiště (filesystém, relační databáze), doba se však mění a uživatelé k nám budou (chtějí) tlačit data, které nelze jednoduše rozbít do “chlívečků”, protože jejich struktuře nerozumíme, typický zástupce největšího zdroje těchto dat jsou sociální media.

Proč objektová úložiště ?

Studie IDC z roku 2014 o nárůstu nestrukturovaných dat.

Proč “nová” objektová úložiště je zcela legitimní otázka, v první řadě je nutné pochopit (viz studie IDC), že internet je zaplavován masivním nárostem nestrukturovaných dat.

Je nutně změnit tedy přístup k těmto datům, je nutné je umět efektivně obsloužit, zvládnout je ukládat je jedna věc (zde by nebyl problém s klasickým filesystémem), ale většinou požadujeme další vlastnosti, snadný přístup, metadata, škálovatelnost (škálování relačních DB je obecně problém, distribuované FS mají své problémy), redundanci a výkon a flexibilitu (metadata nemohou mít pevnou strukturu tak jako to např. známe z filesystémů).

Objekt jako základ je elementární “struktura”, objekty nejsou na storage organizovány (flat), žádné adresáře ani hierarchie, objekt je reprezentován pouze svým ID, vyšší logiku, smysl, uspořádání zajišťuje aplikace a proto je důležité kvalitní API rozhraní, které je v těsnější integraci přímo s aplikací (aplikace “programuje”/řídí úložiště), z toho pohledu není překvapující, že některá cloud úložiště mají rozhraní přímo přes protokol HTTP/s (všimněte si, že filesystémy nebyly nikdo moc dobře stavěné na přístup přes HTTP/s).

object-storage-object-2016

object-storage-object-archi-2016

Ilustrace filesystému, blokového a objektového úložiště.

object-storage-compare-1200px-2016

Kde to najdu, kde to kvete, AWS S3, Google Cloud Storage a ti druzí …

Začít experimentovat je “snadné”, Amazon Web Services je cloud platforma jejíž součástí je i služba AWS S3 (Simple Storage Service), zajímavou alternativou na testing/vývoj je projekt Minio, což je minimalistický object storage s API kompatibilní s AWS S3.

Dalším zástupce je Google Cloud Storage, nemáme přímé zkušenosti, přednáška byla ovšem dost zajímavá, cenově asi “zatím” stále lépe než AWS, také si zatím hrajeme.

Z opensource možností projekt Ceph, distribuované objektové úložiště umožňující blokovou i file storage, predikuje se velká budoucnost, společnost RedHat koupila projekt Ceph a otevřela ho veřejnosti, předpokládá se integrace s platformou OpenStack a posazení vedle OpenStack Swift object storage, což je další open projekt storage řešení nebo můžete zkusit hodit oko na openio.io.

A to je vše, díky za pozornost.
František Havel, MOJEservery.cz

Linux mini-howto: DHCP Option 82 ?

Linux mini-howto?
Krátce o nástrojích ze života sysadmina.

DHCP Option 82 ?


Ve stručnosti řečeno DHCP volba 82 (option) je “DHCP Relay Agent Information Option”, dobře, máme to, končíme, … ;-), protože nedávno jsme řešili tuto konfiguraci v zákaznické síti tak alespoň slov o této možnosti.

DHCP protokol je technologie pro automatizovanou konfiguraci zařízení připojeným do sítě, používá protokol a porty UDP/68,UDP/69, přiřazení konfigurace má 4 fáze.

Princip a činnost DHCP
Princip a činnost DHCP

 

  1. Discovery – klient se připojí do sítě a pomocí broadcast požádá o konfiguraci sítě.
  2. Offer - DHCP server odpoví, rezervuje si IP adresu pro klienta ze svého adresního rozsahu (pool) nabídne ji klientovi.
  3. Request - klient si vybere IP adresu (DHCP server může nabídnou více IP adres) a informuje server o vybrané IP (opět broadcastem)
  4. Acknowledge - DHCP server potvrdí platnost vybrané IP adresy a zašle další informace, bránu, DNS servery, dobu zápůjčky IP adresy (lease time) a případné další informace dle konfigurace.

K čemu DHCP option 82 ?

Velké a rozsáhle firemní sítě, IPTV implementace, specializované sítě např. pro řízení, monitoring, atp. často vyžadují nějakou formu centralizovaného řízení přiřazování IP adres, DHCP služba má tu nepříjemnost, že komunikuje pomocí broadcast a tudíž by musel být DHCP server na každém segmentu sítě, což je nepraktické, zde nám přichází na pomoc DHCP Relay Agent (služba typicky běží na lokální routeru nebo chytřejším switchi obsluhující dané segmenty LAN), předává unicastem požadavky na centrální DHCP server a zpracovává odpovědi zpět do LAN.

DHCP option 82, relay agent information šikovně doplňuje informaci pro DHCP server o požadavku ( RFC https://tools.ietf.org/html/rfc3046 ), typicky jde o hodnoty Agent CurcuitID  (pro ethernet switche reprezentuje port ze kterého přišel požadavek) a Agent RemoteID (MAC adresa agenta), informaci je možné dále použít v logice rozhodování o přiřazení konfigurace DHCP serverem, bezpečnosti, analýze kdy, kde a co se nám připojuje apod.

Pozn.: Informací které lze předávat může být více, pomocí sub option, vždy je vhodné mít po ruce dokumentaci od aktivního prvku a např. wireshark/tcpdump, protože chcete mít jistotu a vědět a né jen tušit, protože správné naladění Vám chvilku může zabrat.

Co na to ISC DHCP server ?

Předně je ISC DHCP server trochu ďábelský kus software, mohlo by se Vám hodit PDF https://www.isc.org/wp-content/uploads/2014/08/DHCP-4.3.1-Distribution-Documentation-Aug-4-14.pdf , dále notná dávka trpělivost, logování a tcpdump je velmi vhodný, nelze zde popsat všechny možnosti, principiálně jde o “matchování”

Málá ukázka triviální ukázka od které jsem se odpíchli, ukazuje použití match/podmínky if a proměné agent.circuit-id v tomto případě detekuje číslo portu na sw.

dhcpd.conf
---
class "static-port-A1" {
match if(substring(option agent.circuit-id,4,2)=01:01)
} 

class "static-port-A1" {
match if(substring(option agent.circuit-id,4,2)=01:02)
}
 
shared-network group {
subnet 10.1.0.0 netmask 255.255.0.0 {
        pool {
                allow members of        'keep1';
                range 10.1.1.100 10.1.1.200;
                option subnet-mask      255.255.255.0;
        }
        pool {
                allow members of        'keep2'
                range 10.1.2.100 10.1.2.200;
                option subnet-mask      255.255.255.0;
        }
}
}
# Log
if exists agent.circuit-id
{
 log ( info, concat( " Lease for ",
                     binary-to-ascii (10, 8, ".", leased-address),
                     " Switch port: ", 
                     binary-to-ascii (10, 8, ".", option agent.circuit-id), 
                     " Switch MAC: ",
                     binary-to-ascii(16, 8, ".", option agent.remote-id)));
}

http://henrici.biz/projects/downloads/option82_dhcpd.conf 

https://adamkuj.net/blog/2015/10/09/isc-dhcpd-putting-option-82-vendor-codes-to-use/ 

Překvapivě konfigurace není úplně triviální, zabere dost času ale dává další možnosti a kontrolu, zajímavou možností je také v ISC DHCP serveru spustit event při každém novém přiřazení IP adresy, to lze využít, pochopitelně se ve větší nevyhnete dhcp snoopingu a rozdělení portů na trusted/untrusted, port-security případně IP source guard apod. technikám, útok na druhou vrstvu je překvapivě snadný o to více bolestivý, dhcp option 82 je další možnost, kterou je fajn znát.

A to je vše, užívejte moudře a happy hacking.
František Havel, www.mojeservery.cz

Microsoft Exchange: said: “452 4.3.1 Insufficient system resources”

Drobná odbočka do Windows světa ...

Když už narazíte na chybovou hlášku generovanou v reakci na příchozí poštu SMTP serverem Microsoft Exchange a i přes vysvětlení zákazníkovi, že Windows servery neděláte prosí o pomoc, nejhorší vlastnotí je když fušujete to řemesla cizím, Windows admini odpustí, díky.

said: 452 4.3.1 Insufficient system resources (in reply to end of DATA command)

Dle info, se nám toutu hláškou snaží Exchange sdělit, že mu došlo místo na disku, respektive né tak úplně, ale volné místo kleslo pod 4GB a SMTP server přestane akceptovat příchozí emaily, tato vlastnost se jmenuje back pressure.

  • Takže jediné co je v tomto případě potřeba je uvolnit místo na disku a SMTP opět začne přijímat emaily, jednoduché.
  • Nemá smysl hodnotit užitečnost backpressure funkce, ale pro info lze ji úplně zakázat, většina konfiguračních voleb pro transport server je XML, otevřete z instalační cesty (xyz\Exchange server\bin) soubor EdgeTransport.exe.config, najděte klíč EnableResourceMonitoring a value nastavte na false, poté restartujte službu MSExchangeTransport.
  • Přesunutí fronty, mohlo by se Vám hodit, nakonec toto bylo konečné řešení, přesunutí fronty na samostatný disk, opět stejný XML, v sekci AppSettings je klíč QueueDatabasePath a hodnota např.  takto value=”e:\Exchange\Queue\QueueDB”.

A to je vše, užívejte moudře, děkuji za pozornost.
František Havel, MOJEservery.cz

To nejlepší z InstallFest 2016

To nejlepší z InstallFest 2016


Jako vždy podařená akce, zajímavý obsah, lidi, dobrá nálada, velké poděkování krom přednášejících patří organizátorům a partnerům za podporu této akce. Děkujeme.

Menší osobní výběr přednášek z Installfest 2016 toho nej z letošního ročníku akce, znovu opakuji osobní.

Celý kompletní program, slidy, video zde.
http://installfest.cz/if16/program
http://installfest.cz/if16/video

HaveAPI: vytvořte si API k čemukoliv (Jakub Skokan, Pavel Šnajdr)

Knot Resolver (Ondřej Surý)

Softwarově definované rádio (Jan Hrach)

Kontejnery != Docker (Václav Pavlín)

Buildsystemy (Tomáš Chvátal)

Arduino a ESP8266 (Petr Stehlík)

Buildíme Fedoru pro Raspberry Pi po hackersku (Ľubomír Rintel, Richard Marko)

ELK – sežere Vaše logy (Věroš Kaplan)

DNSSEC na vlastní doméně snadno a rychle (Ondřej Caletka)

Monitorování a bezpečnostní analýza v počítačové síti (Tomáš Čejka)

Linux mini-howto: Základní pravidla bezpečnosti serverů

Linux mini-howto?
Krátce o nástrojích ze života sysadmina.

Základní pravidla bezpečnosti serverů

Proč? Základní představa o bezpečnosti serverů je často mylná nebo žádná, tímto soupisem praxí ověřených pravidel se jí pokusme nastínit, v některých případech jde obecná pravidla platná napříč světem IT v jinde cílíme přímo na UNIX systémy, znovu připomínáme jde o takový dobrý základ od čeho se odrazit a v případě zájmu můžeme pokračovat dalším dílem.

Bezpečnost IT systémů není stav, je to neustálý proces a i z toho důvodu je 100% zabezpečení přelud, kterého nelze dosáhnout, ale můžeme se k němu zkusit přiblížit, jediný bezpečný systém je ten který nemáte ala jediné auto které Vám nezestárne je to které jste si nekoupili.

Pokračování textu Linux mini-howto: Základní pravidla bezpečnosti serverů