Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - František Ryšánek

Stran: 1 ... 18 19 [20] 21 22 ... 84
286
Server / Re:Mailová domena na dvou serverech
« kdy: 22. 07. 2022, 22:28:58 »
Tohle jsem před lety zdědil ve firmě, kde pracuju. Mezitím už tohle uspořádání padlo (organizační změnou) ale dlouhá léta naši doménu obsluhovaly dva SMTP servery ve dvou kancelářích (postfix). Prakticky to znamená, že musíte mít na obou serverech "překladové seznamy" aliasů pro jednotlivé uživatele, konkrétně
Kód: [Vybrat]
virtual_alias_maps = hash:/etc/postfix/virtual
kde si překládáte adresy příjemců z "virtuální" domény na fyzická FQDN serverů (resp. domény třetí úrovně) křížem mezi oběma servery. Např.:

Soubor /etc/postfix/virtual na serveru cz.example.com:
Kód: [Vybrat]
vojcek@example.com   vojcek@pl.example.com
venca@example.com   venca
venca@cz.example.com  venca

Soubor /etc/postfix/virtual na serveru pl.example.com:
Kód: [Vybrat]
vojcek@example.com   vojcek
vojcek@pl.example.com   vojcek
venca@example.com   venca@cz.example.com

Na pravé straně vidíte "cílové" adresy. Může se jednat zas jenom o alias, nebo o lokálního uživatele. Co se se zprávou pro lokálního uživatele děje dál, to už záleží na konfiguraci lokálního doručovatele (= další kousek skládačky, na Vašem problému nezávislý).

V tomtéž souboru můžete zařídit "mailing-listy" = jeden alias vlevo lze rozeslat více příjemcům vpravo, můžete vpravo míchat místní a vzdálené příjemce (v rámci jednoho řádku=pravidla).

Tzn. oba servery považují doménu druhé úrovně za "svou", a až na úrovni aliasů pro jednotlivé uživatele si zprávy navzájem rozhazují. V DNS můžete mít primární MX na jeden server a sekundární MX na druhý.

Související drobností k dořešení může být adresa odesilatele v odchozí poště. Pokud poštu píšete v klientovi na nějakém dalším počítači (desktop/noťas apod. prostě mimo samotný server) tak si samozřejmě předepíšete adresu ve "virtuální" doméně druhé úrovně. Pokud byste zprávy psali v klientovi lokálně na serveru (mutt, (al)pine apod.) tak v defaultním nastavení bude v odchozí adrese vidět doména třetí úrovně (resp. FQDN serveru - u nás to bylo totéž). Buď musíte říct klientovi, aby jako odchozí uváděl "virtuální" adresu s doménou druhé úrovně, nebo se to tuším dá pořešit letmo přepisovacím pravidlem v konfiguraci serveru (postfix).

Nemám tohle schéma ze své hlavy, tuším to u nás vytvořil před mým příchodem kvolaa pokud ho někdo znáte :-)

287
Vývoj / Re:Ako sa naucit rozmyslat?
« kdy: 21. 07. 2022, 10:04:54 »
Syn si chce kupit seriu knih The art of programming. Myslite, ze je to dobra investicia a nieco ho ta kniha nauci? Pytam sa preto, ze je to vacsia investicia a bola by som nerada, ak by zapadali prachom na policke.

Jestli vas trapi jen tohle, tak si nejaky dil pujcte na prazdniny v knihovne :-)

Tesat. Hele je to třicet let, ale mě knihovna formovala dost zásadně. Já bych doporučil zřídit průkazku do knihovny. V dnešní době tam budou spíš všelijaké návody ke komerčním produktům co zrovna letí... mezi vykopávkami bych namátkou zmínil s odpuštěním Kernighan+Ritchie C. Tuším u nás kdysi vyšel slovenský překlad. Je tam hezky vysvětlená stavba toho jazyka. I tak je to někde od prostředka, já začínal s páječkou a po pár základech v Basicu mě daleko víc zajímal x86 assembler... A zrovna ta Knuthova encyklopedie je zřejmě vážně dost hutná - řekl bych nepříliš záživná třeba i pro vysokoškoláka. Našel jsem někde válet vzorovou kapitlou. Řekněme pokud už člověk má za sebou začátky v nějakém programovacím jazyce a něco si přečetl, a má určitou toleranci vůči vědátorskému slohu, může být zajímavé, přečíst si, co k tomu na mnoha stovkách stran sepsal pan profesor.

Jasně že se programovací knížky nedají číst od začátku do konce jako beletrie. A člověk nemusí/nemůže hned pečlivě zkoušet všechny příklady. Středoškolák to taky nemůže všecko pobrat na první dobrou. Navíc v knížkách v "pokročilých" kapitolách bývají spíš všelijaké speciality a slepé vývojové větve, "vata". Člověk musí umět "přeskakovat pasáže, kterým zatím nerozumím" (protože nejsem tak daleko, nebo protože je autor odflákl, nebo mě to prostě nezajímá). Popravdě hodně důležitá schopnost je "řídké čtení" = být schopen najít kapitolu/pasáž, která mě zajímá, kus si přečíst, mrknout se letmo kolem co je ještě zajímavého k vidění, a pravděpodobně knihu odložit. Vyhledávání klíčových slov v elektronických textech to zvedá ještě o level jinam :-) Najít jehlu v kupce sena - najít kýženou jednu větu nebo položku v tabulce v několika desítkách / stovkách stran nějakého manuálu... Orientovat se v textu, který je vycpaný vatou, a hledat v něm sladká tajemství, často mezi řádky...

Člověk nemuže přečíst všechno. Znám jednoho, který o sobě tvrdí, že má nutkavou potřebu, když už začne číst knihu nebo nějaký návod, přečíst ho úplně do konce (údajně porucha autistického spektra) a je hrozně naštvanej, když se příjemně plynoucí čtení zvrhne v nesrozumitelnou haťmatilku...

K vlastnímu programátorskému hraní schází samoukovi při školní docházce témata. Cíl - co vlastně programátorsky pojednat, jakou úlohu vyřešit. Příklady z učebnice jsou dobré a zajímavé spíš v naprostých začátcích. Tohle se obrátí naruby, jakmile si člověk najde práci :-)

Ohledně postesků starých borců "nekopírovat každou blbost z examplů na internetu" - jasně, člověk se musí naučit používat vlastní mozek, kriticky posuzovat cizí příklady. Ale i tady má nezastupitelnou úlohu pokus/omyl. Něco se dočtete z knížek, nebo Vás před tím varují ve škole, ale ve spoustě věcí si člověk musí čumák namočit sám :-) a začít od cizího examplu je jako rychlý start docela dobré. Jasně, hned tam vidíte blbosti, neošetřené větve a chyby po návratu hnihovních funkcí apod.
Kromě toho, velká část prográtorské činnosti spočívá v práci s hotovými knihovnami / API a tady je Vám často dobrý každý zdroj, který dokážete najít: hrubé základy najdete v referenční příručce / manuálu, pak najdete pár tutorialů a výukových examplů, a když nic jiného nepomůže, ponoříte se do zdrojáků softwaru, který s použitím té knihovny už napsal někdo druhý. Případně do zdrojáků samotné knihovny, pokud jsou k dispozici.

Takže moje doporučení: dopřát to mladému všechno dohromady. Knihovna, vlastní počítač (nebo dva), internet. Pokud nemá staršího kámoše/mentora tak ať si zřídí účet tady na rootu. "Programovacích jazyků" a prostředí je k dispozici fůra zadarmo. Ať se pustí vlastní cestou. Obor "IT" je hrozně široký. A nezanedbávat "nepočítačové" činnosti. Nenutit do vrcholového sportu apod., ať si volný čas řeší po svém, ale ať se trochu vyvětrá / přijde na jiné myšlenky / mezi živé lidi.

288
Sítě / Re:Více bran při víc IP, ale jedna MAC
« kdy: 19. 07. 2022, 18:03:44 »
Ohledně kombinace "network namespace + macvlan", mám-li být konkrétnější, nedávno jsem potřeboval cosi otestovat, a nasimulovat větší počet klientských instancí jednoho... "programu", který se nerad spouští opakovaně na tomtéž fyzickém síťovém rozhraní. Takže jsem ho potřeboval zavřít na jeho vlastní "lehce virtuální" pískoviště. Přitom ale aby všechny ty instance jely ven do světa přes totéž fyzické rozhraní. Prostě takový generátor specifického bordelu na síti, proti testované "servisce". Velice mi pomohl článek Dana Ohnesorga tady na rootu.

Níže se pokusím přiložit výpisy dvou skriptů + malého sdíleného konfiguráku.

Soubor cfg.sh :
Kód: [Vybrat]
IPNET_BASE="192.168.4."
IPNET_SLASH="24"
IP_ADDR_BASE="20"

PHYNET=eth1
COUNT=20

Soubor start.sh :
Kód: [Vybrat]
#!/bin/bash

. cfg.sh

echo Bringing up interface $PHYNET
ip link set dev $PHYNET up

for (( idx = 0; idx<$COUNT; idx++)) do
        IP_ADDR_LAST_BYTE=$(($IP_ADDR_BASE + $idx))
        IP_ADDR="${IPNET_BASE}${IP_ADDR_LAST_BYTE}"
        CFGFILE=my_program${idx}.conf
        NAMESPACE=mycustomns$idx
        NETIF=macvlan$idx
        echo Adding $NAMESPACE $NETIF $IP_ADDR $CFGFILE
        ip link add $NETIF link $PHYNET type macvlan mode private
        ip netns add $NAMESPACE
        ip link set $NETIF netns $NAMESPACE
        ip netns exec $NAMESPACE ip addr add dev $NETIF $IP_ADDR/$IPNET_SLASH
        # "netif up" must be done *after* the netif gets assigned to a namespace
        ip netns exec $NAMESPACE ip link set $NETIF up
        # Note: it takes a moment for the interface to transition from NO-CARRIER to LOWER_UP
        #ip netns exec $NAMESPACE ip link show $NETIF
        ip netns exec $NAMESPACE ip addr show $NETIF
        # Create a per-instance config file
        cp master.conf $CFGFILE
        echo "something or another" >> $CFGFILE

        echo "Starting instance $idx of my_program in the background"
        nohup ip netns exec $NAMESPACE my_program -c $CFGFILE > nohup${idx}.out &
done

Soubor stop.sh :
Kód: [Vybrat]
#!/bin/bash

. cfg.sh

killall my_program

for (( idx = 0; idx<$COUNT; idx++)) do
        IP_ADDR_LAST_BYTE=$(($IP_ADDR_BASE + $idx))
        IP_ADDR="${IPNET_BASE}${IP_ADDR_LAST_BYTE}"
        CFGFILE=my_program${idx}.conf
        NAMESPACE=mycustomns$idx
        NETIF=macvlan$idx
        echo Removing $NAMESPACE $NETIF $IP_ADDR $CFGFILE
        ip netns exec $NAMESPACE ip addr delete dev $NETIF $IP_ADDR/$IPNET_SLASH
        ip netns exec $NAMESPACE ip link delete $NETIF
        ip netns delete $NAMESPACE
        rm $CFGFILE
        #echo  leaving nohup${idx}.out in place for your reference
        rm nohup${idx}.out
done

echo Shutting down interface $PHYNET
ip link set dev $PHYNET down

Pro jistotu nechci být konkrétní, co to bylo zač - takže ten skript je následně maličko upravený, bez finálního otestování.

Každé virtuální macvlan rozhraní dostane nějakou vygenerovanou MAC adresu. Popravdě jsem je nezkoumal, takže nevím, jak vlastně vypadají. Ani jsem je nezkoušel nastavit natvrdo. Asi bych zkusil něco jako

Kód: [Vybrat]
ip nents exec $NAMESPACE ip link set $NETIF address 02:01:b0:0b:13:55

...a následně zkontrolovat pomocí

Kód: [Vybrat]
ip nents exec $NAMESPACE ip link show $NETIF

To je jenom taková malá ochutnávka, jak zabydlet namespace - buď jednotlivě, nebo taky hromadně větším počtem instancí téhož softíku.

289
Sítě / Re:Podivné DHCP dotazy
« kdy: 18. 07. 2022, 13:29:12 »
Tohle chce používat "nehloupé" aktivní prvky. Managed switch se schopností port mirroringu, jako wifinu něco rozumného co umí čmuchat (OpenWRT nebo tuším Mikrotik). Nebo mít pasivní odposlechové sondy na všechna média - ale třeba wifina šifrovaná WPA moc odposlouchávat nejde (se člověk dozví jenom MAC adresu). Nakonec souhlasím s RDa: všecko vypnout a postupně přifázovat (nebo si pomoci půlením intervalu, začít od podezřelých apod).

290
Sítě / Re:Více bran při víc IP, ale jedna MAC
« kdy: 18. 07. 2022, 13:17:15 »
Co je cílem?

Aby jeden router měl víc uplinků = víc default routů do divokého internetu, a klient aby si volbou subnetu v LAN mohl zvolit, kterým uplinkem chce ven?

Víc uplinků do divokého internetu především znamená, nějak rozpoltit "routing process" do více instancí. Dá se to několika způsoby. Byla tu zmínka o network namespaces, vrf, já bych dodal ještě policy-based routing .

A ano, macvlan + network namespaces jsou asi nejlehčí tonáž, pomocí které lze zařídit "kontejnerizaci" networking stacku, včetně přidělení dedicated MAC adresy, tak aby to ven koukalo sdíleným fyzickým L2 rozhraním.

291
Windows a jiné systémy / Re:Skusit BSD?
« kdy: 09. 07. 2022, 19:25:25 »
Obecně po BSD lze sáhnout např. v rovině bezpečnosti - pokud se chcete vyhnout monokultuře (do kteréžto kategorie i Linux už nějakou dobu může spadat).

Tradiční rysy tří variant svobodného BSD:

OpenBSD: krutopřísně bezpečné, ale podpora pro nový PC hardware může být spíš smutná.

FreeBSD: asi relativně nejbližší náhrada Linuxu, relativně nejshovívavější s uživatelem, relativně rychle přebírá smysluplné technické novoty z Linuxu (před lety třeba SMP), relativně dostupné ovladače pro nově vznikající PC hardware - ale i tady můžete narazit u hodně nového hardwaru.

NetBSD: brutálně multiplatformní / portovatelné. Nejširší paleta CPU architektur. Historicky je z tohoto důvodu relativně populární jako základ všelijakých "embedded" počítačů.

Pokud se týče "podpory nového PC hardwaru" tak jde především o ovladač diskového řadiče a síťovky - případně grafiky, pokud potřebujete grafický desktop, a taky třeba USB HCI. Samotný procesor je obecně bez problému, starší BSD poběží na novějším procesoru. Modulo ovšem věci jako NUMA, big.LITTLE (Alder Lake), tipnul bych postupný vývoj verzí MPS/ACPI/UEFI apod.

292
Windows a jiné systémy / Re:Skusit BSD?
« kdy: 09. 07. 2022, 19:09:23 »
Taktéž jsem si všiml lepších výsledků a méně problémů s řadiči Areca v kombinaci se šifrovanými disky (Ultrastar), které používám dlouhé roky a se síťovkami Mellanox - přenos do nového železa.

Toto mě zajímá, a vysvětlivku jsem nepobral... nešla by ta zkratka prosím trochu rozvést? :-)

293
Sítě / Re:Pokrytí WiFi na chalupě
« kdy: 06. 07. 2022, 09:02:41 »
Dává nějaký smysl, vyměnit RouterOS za wrt?  :o

Je to věc osobních preferencí a v mém případě zvrhlých pohnutek, nebo něco jako "známka punku"...

OpenWRT má 802.11r - RouterOS už ho má? Ne že by na 802.11r nějak extra záleželo, handover funguje i "sám od sebe" čistě v režii slava.

A mám za sebou zkušenost třeba před dvěma lety, že ze sbírky jablíček (telefonů a noťasů) mi část proti RouterOS zaboha nechodila, po flashnutí OpenWRT bez problému. RouterOS má "svoje" wifi ovladače a jabko je zřejmě taky částečně "svoje" a mají poměrně dlouhou historii vzájemných nekompatibilit. Už mi tu před pár dny někdo tvrdil, že má doma jenom jablíčka (po mém soudu dost nová) a nemá proti RouterOS žádný problém.

OpenWRT má samozřejmě svoje vlastní zádrhele.

Jinak nemám s RouterOS žádný religiózní problém - naopak ho s gustem použiju, když mi řeší zadání (v mém případě třeba point-to-point spoje, kde potřebuju 4-adresní režim). Hlavně si každá instance RouterOS vystačí sama, pokud toto žádáte. A to přibalené GUI - v mnoha ohledech prvotřídní. To říkám jako člověk, který jinak nad GUI spíš ohrne nos a drží se příkazového řádku (což v RouterOS mohu taky.)

Pokud nemáte problém s OpenWRT (vím že tak Vaše otázka nezněla) a naopak hledáte hardware pro OpenWRT, který by byl opakovaně dostupný (což třeba řešívám já), tak je na tom Mikrotik s dlouhodobou dostupností ozkoušených modelů líp, než veškerá SoHo konkurence, snad výjimkou dávného WRT54G, kde existoval model s dlouhodobou dostupností. Výhodou může být také mechanická "stavebnicovost" některého hardwaru Mikrotik/RouterBoard.

Důležité je mít MESH, to znamená, že se wifina automaticky přepíná mezi nejbližším bodem. Já třeba používám TP Link Deco. Mají víc druhů, jsou levnější i dražší a výkonnější, tuším, že nějaké ty rozumné stojí 3x AP asi 3.000 Kč. Dá se to nakonfigurovat za 20 minut.

Jestli správně chápu: MESH je mezi APčky v LAN, netýká se slavů. Roaming slavů si jede po svém (s případnou dopomocí 802.11r, pokud je přítomno). MESH řeší to, že APčka v roli čistých repeaterů (rádio-rádio) se "automaticky dynamicky organizují" do stromu podle vzájemných dostupností. Prostě je rozhodíte do prostoru, dáte jim jenom napájení, a starejte se hoši.
Tzn. MESH je pomůcka do prostředí s proměnlivou konfigurací překážek, nebo kde se repatery pohybují, nebo to jako admin chcete mít bez složité plánovací a ladící práce.
Pokud máte statické prostředí (chalupa, APčka přibijete ke stropu a už na ně nesaháte) a chcete přivést každému APčku zvlášť ethernetový drát ze switche, tak Vám MESH řeší neexistující problém, je to tak?

294
Sítě / Re:Pokrytí WiFi na chalupě
« kdy: 05. 07. 2022, 21:15:53 »
@ja. mě poňouknul, budu se opakovat: na cAP AC i na uAP-AC lite mi běží OpenWRT. Roaming "just works" na bázi svobodné vůle klientů, případně se dá nakonfigurovat i 802.11r pro rychlejší/bezvýpadkovější handover. Ze dvou uvedených zařízení UBNT uAP AC lite má procesor jednojádro, cAP AC má čtyřjádro a o generaci mladší platformu čipsetu vč. wifiny.

295
Sítě / Re:Prehladavanie zariadeni v subnetoch
« kdy: 05. 07. 2022, 21:00:07 »
Jinak to trochu smrdí :-)
V zasade je to poziadavka zakaznika, aby si mohol pridat zariadenie, ktore je v inom subnete.

Je to v c# a broadcast cez udp
To ti neprojde pres router. Pokud je síť routovaná tak se na ni nedostanes.
Samozrejme, v tomto pripade nie.

trochu to tu opat obnovim, nakolko sme to zacali aktivne riesit. tak ako som spominal, riesime to cez UDP broadcast, zariadenia maju nejaku port, na ktory sa posiela sprava a prijata odpoved je dane zariadenie. Cize napr. 10.42.8.255 atd. Dopatral som sa k jednej moznosti a to konkretne directed broadcast. Myslite, ze to je mozna cesta?

Jsou dvě varianty broadcastu:

A) globální broadcast = cílová adresa 255.255.255.255 .
Toto podle mého neproleze routerem, nejspíš to ani není konfigurovatelné (na Ciscu).
V rámci L2 LAN globální broadcast funguje velmi dobře. Pokud hledaná zařízení ještě ani nemají IP adresu ve správném subnetu (mají nějaký default), můžete použít broadcast pro dotaz i odpověď, případně pro druhou transakci, ve které nastavíte žádanou unikátní IP adresu a masku, aby se dál už dalo bavit unicastem v rámci legitimního subnetu.

B) lokální = per subnet = "directed" broadcast, např. 192.168.3.255/24 (vymyslel jsem si).
Toto lze na routerech zapnout - přinejmenším na Ciscu. Příkaz "no ip directed-broadcast" býval v začátečnických kursech Cisco mezi zcela základními bezpečnostními pravidly, od verze 12 se jedná o default (který není vidět v "show running") - ale dá se stále povolit.
Pokud routeru předáte paket s cílovou adresou, která je lokálním broadcastem v některém "directly connected" subnetu, tak ji přeloží na L2 broadcast s kýženým výsledkem.
Pozor, pokud se pokusíte broadcastem oslovit subnet, který router *nezná* jako "directly connected", tak se directed broadcast mine účinkem (skončí na default routu, nebo na nějakém specifickém routu který není "directly connected", pokud takový existuje v konfiguraci).
V rámci L2 segmentu (bez průchodu routerem) samozřejmě můžete "directed broadcast" používat zcela svobodně, pokud vám Vaše programovací prostředí dovolí. Ale jste omezen znalostí lokálního subnetu, a musí s ním umět pracovat i oslovené slave zařízení = musí být už nakonfigurované na správný subnet a mít přidělenou IP adresu (a jenom se znuděně ozve "jo jasně, tady jsem", klidně unicastem). Ještě jsem uvažoval tím směrem, že by slave mohl poslouchat na raw socketu (nebo lipbcap), aby vzal úplně všechno bez ohledu na subnet, a pokud vidí directed broadcast (= "konkrétní IP adresu" ale na L2 broadcast FF:FF:FF:FF:FF:FF) tak se ho může "chytit" - ovšem pokud nemá zatím přidělenu IP adresu z dotyčného subnetu, tak by si nemělo žádnou konkrétní svévolně vzít, tzn. jako řešení vidím jedině, použít v odpovědi opět "directed broadcast" adresu, a to jako cíl i jako zdroj. Možná by v tom případě bylo jednodušší, aby si slave prostě po zapnutí líznul DHCP. Pak může chytat directed broadcasty normálně přímo, bez blbnutí s raw socketem apod.

A pak mě ještě napadá, zkusit to multicastem :-) Ale je s tím spíš práce navíc, má to svoje problémy a bugy a konfigurace na routerech (a switchích!) apod. Radši se držte broadcastu, ten by měl prolézt aspoň v rámci L2 všude.

Tzn. docela důležitou otázkou zůstává: je to skrz router, nebo jenom v rámci L2 média? ...

296
Server / Re:Připojení k sambě až napodruhé
« kdy: 04. 07. 2022, 09:13:58 »
Ještě něco jsem našel, ale nemám čas to celé študovat.

Jinak bych zkusil zvednout debug level v Sambě, např
Kód: [Vybrat]
log level = 3 acls:5 rpc_srv:5 auth:4
a koukat do logů, a taky Wireshark má dissector pro SMB protokol a možná by tam byl vidět nějaký chybový kód nebo co...

297
Server / Re:Připojení k sambě až napodruhé
« kdy: 04. 07. 2022, 01:45:28 »
Toto jsem před lety řešil ve Windowsech - už si nepamatuju příčinu. Google mi teď našel tuto zmínku. A skutečně ve svém smb.conf vidím tuto dvojici řádků:

Kód: [Vybrat]
idmap config * : range = 1000-1999999
#idmap config * : range = 500-1999999

Go figure.
Nemám zdaleka jistotu, že je to ono - prostě jenom nápad.

298
Bazar / Re:Sháním - SAS řadič s externím portem
« kdy: 01. 07. 2022, 18:57:36 »
LSI SAS9200-16E

Souhlas, požadavkům to odpovídá.

Ještě jsem našel Dell PERC H200e HBA (03DDJT), údajně čip LSI SAS 2008. Patrně vidím podporu v Linuxu v driveru mpt3sas.

299
Bazar / Re:Sháním - SAS řadič s externím portem
« kdy: 30. 06. 2022, 16:45:43 »
Takový hardware nemám. (Mám tu 1 kus LSI SAS 9212-4i, který jsem šťastně sehnal a flashnul, prodat nehodlám a požadavkům neodpovídá :-)
Ale mám představu, jaké objednací kódy cca googlit:
LSI SAS 9207-4i4e  = HBA (IT firmware z výroby, netřeba složitě flashovat)
LSI SAS 9217-4i4e  = IR firmware = low-end RAID, je třeba flashnout IT firmware
LSI SAS 9212-4i4e  = IR firmware = low-end RAID, je třeba flashnout IT firmware
...bejvala taky Areca ARC-1300-4x, čipset tuším Marvell. V našich končinách asi dost exot - berte radši nějaké LSI.
Ty LSIčka jsou často k nalezení se samolepkou HP, snad i jiných velkých značek.

Důležitý je přívlastek "4e" v objednacím kódu, to je ten x4 multilane externí SFF-8088. Pozor, u jiných generací SAS HBA se vyskytovaly i jiné konektory (starší SFF-8470, novější SFF-8644).
Jak tak kolem toho trochu googlím (namátkou výsledky: 1 2 3), potkal jsem zmínky, že cross-flashnout konkrétně 9217 na IT firmware může být trochu porod - ale to mohlo taky být rukama.

300
Lidičky, odpusťte mi.  Asi se nudím, nebo je to příznak blížícího se mentálního důchodu... ale zamýšlím se nad takovou napohled primitivní a povrchní otázkou. Odtud toto téma.

Ukládání věcí ve firmě do souborů. Jak v tom udělat nějaký pořádek. Třeba nedokonalý, ale systém.
Asi se tím zhruba zabývá obor "document management" - možná komplet, možná zase jenom nějakou fasetou. Nepochybuju, že jsou na trhu softwarové produkty, které se snaží tvářit, že Vám to jednou provždy "vyřeší".

Jasně, máme provozní systém (účto nebo ERP nebo tak něco, podle toho jak je firma velká). Do kterého patří nějaké věci. Kromě toho v organizaci putují různé další soubory. Něco člověk stáhne z netu a je to pro něj užitečné a chce si to nechat (a do databáze ERP to nepatří), něco člověk třeba sám tvoří: interní dokumentaci (sesbíraná data a poznámky) k nějakému "případu", archivní ovladače pro konkrétní model či rodinu hardwaru, nebo nějaký content na web, nebo data k projektu (libovolný ne-IT obor), nebo třeba softwarový projekt nebo tak něco na ten způsob...

Prostě fůra souborů, které člověk buď někde získá, nebo sám vytvoří, a nerad by o ně přišel.
A člověk pracuje ve firmě/organizaci, a v kolektivu třeba sypou některé druhy takto získaných dat "na společnou hromádku" (sdílejí tu hromádku dat v pravém slova smyslu). A potřebují se v tom kolektivně orientovat, nastavit nějaká pravidla, jak strukturovat strom adresářů apod.

Teď ponechme stranou, že jsou v kolektivu lamy, které mají mentální problém pobrat stromovou strukturu adresářů jakožto velmi základní a obecný koncept. A sypou svoje data kam je zrovna napadne, tak jako že šli zrovna okolo. Sdílený fileserver pak vypadá jako předměstí v banánové republice bez svozu odpadků.

Na druhé straně jsme krasoduchové jako já, kteří se tím snažíme zabývat koncepčně, v rovině "datového modelování a metamodelování" - a nejsme z toho o moc moudřejší než početná "střední vrstva" všelijakých kolegů a šéfů, kteří jsou mentálně někde mezi = nevidí tu hrůzu v celé koncepční hloubce a bojují s tím jak umí, tzn. částečně ad hoc, mají sklon podlehnout reklamě dodavatelů NASů, softwarů na "geniální document management" apod.

V zásadě je problém v tom, že naprostá většina konvenčních filesystémů prezentuje uživateli "strom adresářů". Ten strom je vlastně index, pro jednoznačnou (a jedinou?) adresaci přístupu k datovým objektům (souborům). A problém je v tom, že koncepčně můžeme mít mentální problém říct, který aspekt/atribut/kritérium souboru má být určujícím pro třídění = pro formování té stromové struktury. Příklady možností:
- per uživatel (jasně, máme home adresáře)
- per zákazník
- per "projekt"
- per značka/model/rodina hardwaru
- per oddělení/oblast interních činností ve firmě
Který aspekt zvolit jako primární? Je vůbec některý z nich "nepochybně obecně primární"?

Můžu uvažovat tím směrem, že si prostě jeden aspekt jako primární zvolím, a tento použiji pro zatřídění do stromu souborového systému. A následně se budu snažit použít třeba symlinky nebo "extended attributes" nebo třeba klikatelné indexy v HTML formátu, abych zařídil "sekundární odkazy", které neznamenají "vlastnictví" objektu ve stromě (tím je primární umístění). Bohužel operační systémy mi tuto bohulibou "anotační činnost nad primárním souborovým systémem" nijak neusnadňují, znamenalo by to používat nějaký dodatečný software, řešit multiplatformnost (bye bye symlinky a xattr) apod.

Výrobci OS dokáží ještě tak propašovat do OS "indexační engine", který pravidelně ráno po spuštění počítače sežere na hodinu 100% disk IO kvůli reindexaci...

Anebo prostě cpát BLOBy do databáze a dávat jim nějaké tagy, podle kterých jsou dohledatelné. Ať už ty bloby jsou primárně umístěné jako soubory na disku v mělké/tupé adresářové struktuře, nebo přímo v RDBMS.

Interní dokumentaci lze spravovat třeba v nějakém Wiki-based enginu... prostě hypertext. Což je ale práce navíc, a nakonec to stejně moc neřeší, "kam sypat bloby všeho druhu a jak v nich udržovat pořádek".

Pokud se vrátím na zem k obyčejné adresářové struktuře, tak řekněme, že lidi dostanou home adresáře na fileserveru, do kterých si tradičně navzájem nevidí (za normálních okolností), a pak bude existovat nějaký "sdílený share", kam můžou všichni, případně mají nějak rozparcelováno uživatelskými právy, kdo smí kde zapisovat/mazat apod. A pak se podrobněji uplatní nějaká kritéria, jak věci podrobněji třídit.

A teď si vemte, že ten sdílený share je někde na fileserveru. A lidi mají každý noťas, s ním cestují, a třeba taky chtějí pracovat offline, nechtějí být závislí na internetové konektivitě (protože VPN). To znamená, že si chtějí některé věci zrcadlit na lokální disk v noťasu. Ale jaksi nejde, aby si každý ve firme synchronizoval na své noťasy celý fileserver - prostě z kapacitních důvodů. Řekněme, že lze realizovat synchronizaci "home adresáře". Nojo, ale co věci na sdíleném sharu? Synchronizovat jednotlivé foldry, které si uživatel nějak označí? To už zase vyžaduje netriviální pozornost. Nebo mít pravidlo "pracuju na noťasu, a co vytvořím v tomhle adresáři, to se syncne na server, ale nikoli naopak"? Co když na jedné věci pracuje víc lidí, a třeba se naštěstí nepotkávají nad jedním souborem (není třeba řešit slučovací konflikty) ale hodilo by se, synchronizovat množinu souborů?

Jasně, existují specializované "softwarové systémy" pro konkrétní použití: podnikové aplikace (na škále mezi účtem a ERP), existují systémy pro správu verzí zdrojáků (GIT a jeho poddaní), řadil bych sem i kanonické "document management systémy" třeba na ISO dokumentaci, nebo třeba obyčejnou DokuWiki apod.

Zůstaňme ale ještě chvíli u "holých souborů v adresářovém stromě". Realita je taková, že se zvolí nějaké kompromisní uspořádání, a ono to nějak (kompromisně) funguje.

Ďábel se ovšem skrývá v detailu a občas se ohavně zasměje - třeba ve chvíli, kdy šéf prohlásí "potřebujeme zlepšit zálohy". A má představu, že zařídíte zálohu toho kompostu na celofiremním sdíleném svazku, nejlíp se zachycením chronologie. Toto na prostoru, kam lidi ještě s bídou mentálně zvládnou sypat čerstvá data, ale nejsou už mentálně schopni, třeba jednou za čas uklízet = odmazávat nepotřebné staré verze dočasných imagů toho či onoho apod. Nemluvě o vysloveném odpadu, který tam nikdy nepatřil. Třeba narazíte na to, že někdo už pár let do GITu ukládá archiv surových videosekvencí z nějakého přístroje pro kontrolu jakosti... nebo někdo navrhne, že se do ERP mají archivovat instalátory ovladačů a doprovodného softwaru toho či onoho... (a zálohy ERP jsou ty nejpečlivější, co máme).

Takže můžete nakoupit veliký storage, který Vám bude s nějakou rezervou stačit na aktuální rozměr nahromaděného kompostu. A můžete se snažit o deduplikaci. A prostě to urvat hrubou silou. Proti Vám stojí rostoucí dav bezelstných užovek, které se o pořádek nestarají do chvíle, dokud jim nepřeteče disk - a pak mají sklon řešit problém tím, že žádají disk nový a větší, nebo naopak mažou bezhlavě i věci, které by třeba někdo jiný rozhodně zatím nemazal apod.
A v mnoha případech je pravda, že hardware je levný, zato omylem smazat nějaká unikátně pořízená data (třeba i poměrně objemná) může hodně bolet, i ve finančním vyjádření.

Nebo si přiberete k dosavadnímu popisu práce ještě roli "datového pedanta a uklízečky". Budete pravidelně pročesávat diskový prostor a hledat nápadně velké objemy dat, a prudit jejich vlastníky s dotazem, zda je to ještě potřeba, zda to tam vůbec někdy patřilo, zda to náhodou "podle zavedených konvencí" nepatří ve stromě adresářů někam úplně jinam, nebo aspoň o úroveň níž, apod. Tzn. ono to taky znamená, hrabat se lidem v "soukromém" nepořádku. A při tom neustále koukat na zaplnění záložního storage.

Když za někým přijdete, že byste potřeboval, aby si udělal pořádek v datech, zhruba "dle takových a takových zásad". Víte jak to skončí? U mě většinout tak, že mu ten pořádek musímu udělat já. Za různých okolností jsem se k tomu už párkrát dostal (zálohy, migrace, přetečení disku, disaster recovery). Prostě lidi jsou ještě schopní uklidit si na stole - ale uklidit si na harddisku? :-DDD

Přiznám se, že jsem tohoto "v podnikovém rozměru" naštěstí zůstal zatím převážně ušetřen, protože jsem nikdy nedělal správce fileserveru ve firmě větší než malé - a v malém kolektivu se věci snáz řeší "out of band", když se všichni denně vidíme navzájem... Mohu se komukoli osobně vysmát v odpověď na dotaz "ty Franto neměl bys někde volných pár desítek TB? já bych tady potřeboval něco dočasně odložit / zazálohovat"...

Podle mého je to prostě boj. Je to o osobním sklonu k pořádku (nebo o jeho pravém opaku). A pak ten hlavolam, podle čeho soubory třídit, když si musíte zvolit pouze jednu primární hierarchii, a implementovat "druhotné paralelní hierarchie" je problematické. A připadá mi, že je ten problém posledních 30 let pořád tak nějak stejný - nebo jsem šeredně zaostal.

Takže končím s vynalézáním suché vody (četli jste někdo Neználka?) a jdu zas něco kompromisně rozseknout.

Z toho, že existují a fungují velké firmy, usuzuji, že spousta těch dílčích "problémů", o kterých fantazíruji, je dávno vyřešená (= vynalézám kolo). Ostatně jsem od svých zákazníků tu a tam nějaké rady a postupy z "corporate" prostředí zaslechl :-) Naschvál je nebudu citovat.

K nakousnutí tohoto tématu ve fóru mě poňouklo, že na to téma nevidím nikde nic sepsaného "v kostce" - jako že akademickou publikaci, nebo nějaký "best practices" blogospisek, ani si nepamatuji, že by o tom někdo třeba tady na rootu zeširoka debatoval. Řeší se tu věci jako ZFS nebo CEPH, ale to jsou technologické vrstvy pod VFS, které se snaží "vstřebat cokoli, co na ně užovky nahází a nějak se s tím důstojně vypořádat", se slušnou průchodností, redundancí apod. Mě jde spíš o to, jak zajistit pořádek ve strukturách, které jsou uživatelům viditelné a jimi ovlivnitelné - k čemu je vést, jaká jim stanovovat pravidla, jak uživatelům zjednodušit život v této rovině. Aby příště našli, co dneska někam uložili/zatřídili. A aby to dokázal najít taky někdo jiný.

Koho jsem pohoršil mělkostí této své halucinace, tomu se omlouvám.
Uvítám jakékoli reakce - asi už mě znáte...
A pokud se mi podaří vyprovokovat k věci flame war, tak možná tím líp :-)

Stran: 1 ... 18 19 [20] 21 22 ... 84