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 - czechsys

Stran: [1] 2 3 ... 38
1
Sítě / Re:LG TV a obcházení NextDNS
« kdy: 29. 08. 2025, 15:39:39 »
Nastavit dns v tv. Pokud ten router umi nastavovat dns per network/ssid, tak to lze tam. Jinak by to vyzadovalo vlastni dhcp/slaac apod. konfigurace mimo router.

2
Software / Re:Doporučte správce hesel pro rodiče
« kdy: 11. 08. 2025, 09:17:51 »
Je nějaký problém s ukládáním hesel přímo v prohlížeči?

Problem je to velky. Kdejaky malware/etc si ta hesla vytahne, pripadne si to uzivatel ulozi nekde jinde a dostane se k tomu zase nekdo jiny.

3
Distribuce / Debian 13 a /tmp jako tmpfs
« kdy: 01. 08. 2025, 17:02:57 »
Cau,

ma nekdo zkusenosti s provozem serveru, kdy /tmp je tmpfs a ne prostor na disku? Debian 13 to tak bude jako standard, da se to sice snadno vypnout/zmenit, ale zajimaly by mne zkusenosti. Me to uplne nevoni - sam /tmp pouzivam pri sitovem prenosu cehokoli bez ohledu na velikost. Kdyz si predstavim, ze mam v infrastrukture spousta VM se < 8 GB RAM, tak zakladni omezeni na 50% RAM zni...no nepouzitelne a dost riskantne.

Diky.

4
Ahoj,

uz nevim kudy. Elasticsearch 8.x, zkousim zkopirovat uzivatele z jednoho clusteru do druheho bez pouziti snapshotu. Nasel jsem spousta navodu na elasticdump:

Dump:
Kód: [Vybrat]
# node_modules/.bin/elasticdump --debug --input=https://restore_user:SOMEPWD@SRC:9200/.security-7 --output=/tmp/.security.json

Restore
Kód: [Vybrat]
node_modules/.bin/elasticdump --debug --output=https://restore_user:SOMEPWD@DEST:9200/.security-7 --input=/tmp/.security.json

...
{
  _index: '.security-7',
  _id: 'user-SOMEUSER',
  status: 403,
  error: {
    type: 'security_exception',
    reason: 'action [indices:data/write/bulk[s]] is unauthorized for user [restore_user] with effective roles [restore_role] on restricted indices [.security-7], this action is granted by the index privileges [create_doc,create,delete,index,write,all]'
  }
}
Fri, 11 Jul 2025 08:43:10 GMT | sent 63 objects, 0 offset, to destination elasticsearch, wrote 0
Fri, 11 Jul 2025 08:43:10 GMT | Total Writes: 0
Fri, 11 Jul 2025 08:43:10 GMT | dump complete

To
Kód: [Vybrat]
indices:data/write/bulk[s] jsem nasel jako acl v Opensearch, ale v ES nic takoveho neni. Vi nekdo, jak na to? Zkousel jsem tomu dat veskere mozne role (samozrejme i all/superuser atd.), ktere nejsou aplikacne specificke (napr. kibana_* atd.)
Pro testovani migrace pres snapshot jeste nemam zprovoznene sitove uloziste. Testovani pripojenim serveru "noveho" do "stareho" ES a nejakym typem replikace se mi zdaji zatim jeste slozitejsi, tak jsem to zaitm vynechal. V principu jde o to, ze nejakym zpusobem budu potrebovat nakonec ten ES zalohovat/obnovovat, takze snapshot, nebo dump.

DIky

5
Server / Re:Jaký DNS resolver pro LAN a VPN?
« kdy: 01. 07. 2025, 08:55:04 »
Idealni pripad by byl, kdyby klientska stanice neleakovala informace ani jednim smerem (tj. dotazy na nase jmena nesli ven, ale taky nechci videt, ci zpracovavat jine dotazy a narusovat soukromi klientu, ani co se dns tyce, ani co se dat tyce).

Nesmysl. DNS leakuje vsemi moznymi aplikacemi, a to i proto, ze po odpojeni/padu VPN jsou ty aplikace casto stale aktivni a pak se dotazuji verejnych rekurzoru.

Nemluve o tom, ze v dobe MFA, ZTNA apod. principu se na split-horizon muzete slusne vybodnout. Slozitost konfigurace firewallu a siti tim jen narusta. A jeste v dobe ipv6.

Pokud chcete "omezit" dotazy pres "security by obscurity" na "lan/vpn domeny", tak si pred sve verejne dns dejte balancer s acl (napr. dnsdist). Ale google/microsoft/etc uz o vasich domenach davno vi.

6
Server / Re:Jaký DNS resolver pro LAN a VPN?
« kdy: 30. 06. 2025, 14:19:01 »
Co si vyberete v ramci veskerych pozadavku, co mate.
Lokalni unbound, dnsmasq, systemd-resolved, atd.
Z centralnich ja pouzivam dlouhodobe powerdns recursor ve firemnim prostredi.

7
Server / Re:Startování služeb přes systemd
« kdy: 13. 06. 2025, 10:26:49 »
Je k dispozici systemd-analyze.

Pokud neni k dispozici backport kernel, tak pak uz jen jedine poridit spravnou kartu.

8
Server / Re:Hotový systém na prehliadanie údajov z DB?
« kdy: 29. 05. 2025, 08:18:34 »
Snipe-IT

9
Server / Re:Geograficky redundantní NAS
« kdy: 20. 05. 2025, 10:14:16 »
Nekdo se zkusenostmi se Starwinds VSAN? Maji relativne slusne reference a jde to pouzit s DIY HW.

pouze lokálně, nikdy jsem to neviděl nasazené na delší vzdálenost mezi 2 lokalitami. Pokud máš dva servery kousek od sebe a umíš je spojit přes L2 ne víc než přes jeden hop, je tohle naprosto skvělé a levné řešení, jak zajistit redundanci a live migraci virtuálů třeba s pomocí kvm.

Vůbec nikdy jsem to ale neviděl nasazené na větší vzdálenost. Není to bezstavové, na každém serveru potřebuješ mít jejich kontrolní službu, který to celé řídí a spojuje se s controllerem na druhé straně. Dobře tam je i řešení výpadků, kdy mají jednotlivé nody svoji prioritu a při pádu spojení, jen ten s nejvyšší prioritou může přijímat zápisy, tím se dá vyhnout split-brainu při zachování provozu z jednoho nodu. Mají tam heartbeat mezi nody a tady si myslím, že bude velká citlivost na latency, sice můžeš mít pomalé (asynchronní) replikace, ale node musí být pořád online.

Diky. Kolega sitar by L2 pres dedikovanou optiku nemel problem sestavit. SAN jsme ale sestavili pres L3 (vzdy preferuji pred L2). No poslu jim tam teoreticky PoC k posouzeni.

10
Server / Re:Geograficky redundantní NAS
« kdy: 20. 05. 2025, 10:11:24 »
Dobrý den,
máme dvě instance, jednu pro dožívající Vmware Essential plus jako SDS na 3 nodách Dell a druhý nový pro Hyper-v Cluster dvou nodový Think Server.
Nemáme s ním problém podpora funguje velmi dobře a nadstandardně dohlíží na to jak je řešení nainstalované a radí při návrhu řešení, v angličtině tedy.
Obě instance jsou full flash a duální 10GBE. Prostor je 30TB Datastore výsledný. V režimu 3 nody, převážná většina v režimu dva servery jde buď witness server nebo priorita, scénářů je hodně možných.
Storage máme připojen ke konzumentům přes iSCSI.
Umí i repliky do cold storage, mohou být synchronní nebo snapšoty dle planovače co se přenesou.

Hardware je dobré s nimi konzultovat předem než je posadit k hotovému.

Nekdo se zkusenostmi se Starwinds VSAN? Maji relativne slusne reference a jde to pouzit s DIY HW.

Diky, predpokladam tedy komplet reseni vcetne HW od Starwinds. Na cenu se ptat nebudu, tam roli hraje kapacita.

11
Server / Re:Geograficky redundantní NAS
« kdy: 19. 05. 2025, 14:52:24 »
Nekdo se zkusenostmi se Starwinds VSAN? Maji relativne slusne reference a jde to pouzit s DIY HW.

12
Server / Re:Geograficky redundantní NAS
« kdy: 15. 05. 2025, 09:01:28 »
... N-uzlový mesh je ještě další úroveň.
To uz mas jedno. To co vyrabis je defakto zrcadlo, a nehraje zasadni roli (technologicky) jestli mas v tom zrcadle ty "disky" dva nebo jich mas deset. Jen ty naklady nerostou linearne, ale spis exponencelne. Potrebujes treba zajistit propoje vseho se vsim (pokud to teda opravdu ma zvladat vypadek cehokoli)

Jenze tady je podstatny to, ze tazatel zatim vubec nedokazal zduvodnit, nac neco takovyho chce. Ja osobne neznam firmu (a mam ve svy bubline tech konaktu docela dost) kde by treba vypadek storage i na par hodin byl nejakej kritickej problem. Jiste, muze to byt neprijemnost, muze to zpusobit nejake financni skody, ale firmu to nepolozi a jaderna elektrarna kvuli tomu nevybuchne.

Ja treba u nekterych zakazniku umim (a to u tech vetsich) v ramci rekneme 10ti minut nahodit provoz ze sekundarniho storage, a ani to neni nijak automaticke a je to zcela vyhovujici (za poslednich 20 let sem to delal 1x). Defakto nejhorsi scenar kterej muze nastat je nutnost obnovovat zalohy (tzn chciply by obe storage zaroven), coz narazi na limity HW a konektivity. Jenze v takovym pripade si nejak nedovedu predstavit, ze by toho nepochcipalo mnohem vic (treba pozar budovy) a tudiz by nejaka obnova zaloh bylo stejne az to posledni, co by bylo k reseni.

Zakaznici to chteji. Jde o jejich business.

Do 10 minut, to jsi frajer. Ja jsem zazil vypadek primarniho storage 2x, kdy nedoslo k automatickemu prepnuti, protoze se to zaseklo. Nebyt u ntb, tak to do tech 10 minut nevyresim.

13
Server / Re:Geograficky redundantní NAS
« kdy: 15. 05. 2025, 08:51:36 »
Ano, pro master-master to bude chtit nejen tlustsi linku, ale hlavne redundantni.

Na druhou stranu - podle toho popisu mi vychazi ze workload je spis RO, a pokud nekde dochazi k zapisum tak to budou spis logy/databaze a to lze agregovat/distribuovat jinak (u DB by se taky dala udelat segmentace, aby ten rw sdileny obsah byl co nejmensi a zbytek jen ro).

1TB je zde spise vyhoda (a to se pres 10G da pretahnout za 20 min cely).


Jeste jinak - jsi schopen na svych klientech striktne oddelit kam zapisama sahaji ?

(napada me pak reseni mit dve nezavisle NAS s NFS, a na obou NAS pobezi neco navazane na inotify a vsechno co se zmenilo, bude pushnuto pres 10G na druhy breh ... ale je zde velice silnej pozadavek, aby nedochazelo ke konfliktum)

Ke konfliktum treba nedojde, kdyz kazda aplikace (resp. bezici instance) bude bezet pouze na jedne strane, a na druhe se spusti az jedna lokace klekne. Pripadne ty appky musi mit vlastni individualni (lokalni, nesyncovanej) temp a pod.

Tak databaze resit nemusim, u nich mam k dispozici replikaci zabudovanou v db.
Ano, vetsina workloadu nad soubory je RO, takze nam 10G redundantni propoje staci, zatim jsme to nebyly schopni zatizit trvale vic nez par desitek %.

Taky me napadlo dva nezavisle nfs clustery. Zdrojaky by nahraval gitlab do obou clusteru. Oddeleni od "media,office dat apod." by samozrejme museli resit vyvojari, aby se to dalo dat na nejake "replikovane" reseni. Coz uz pak muzu "replikovat" vse, vzhledem k celkove velikosti zdrojaku/dat.

14
Server / Re:Geograficky redundantní NAS
« kdy: 14. 05. 2025, 15:18:13 »
Asi nepouzivam spravna slova, protoze nektere otazky jsou jako kdybych neco neuvedl "v popisu". Uz to, kdyz zminuji dedikovane optiky, 10Gbps, SAN apod by napovedelo, ze to uplne garazovka neni, ale bohata firma taky ne. Rozhodne ale nez se neco koupi, tak se planuje/vyhodnocuje, proc se to koupi. Ale budiz.

glusterfs apod. rovnou skrtam, to nebylo pouzitelne ani pred 8 lety, kdy jsem nas aktualni nfs cluter, dnes to je prekonane kontejnery popr. ceph.

Zadani od vedeni je klasicky manazerske, tedy v pripade primarniho datacentra chteji provozovat (aspon nektere sluzby, samozrejme tim mysli skoro vse, co je dobre placene) z druhe lokality. Takze se postupne delaji jednotlive kroky - k aktualnimu nfs clusteru se poridil SAN s georedundanci, tim jsme vyresili (blokove) uloziste pro VM.

Chce se tedy neco obdobneho pro soubory, protoze jedeme hlavne linux, tak nfs je prvni volba. Cestu mit zdrojaky primo ve VM jsme tehdy zamitli, to se muze zmenit. Ale zbytek souborovych dat je orisek, mozna by na to bylo vhodnejsi neco typu S3, ale s tim jsem zatim nemel cest. Porad ale reseni nejdrive on-premise.

Webove sluzby ktere poskytujeme, maji jiz zabudovanou redundanci. Tedy vice kopii web/compute serveru, ktere si tahaji zdrojaky, obrazky, dokumenty, videa a dalsi a dalsi z nfs. Bavime se i v nekterych pripadech i o milionech souboru podle velikosti jednotlivych projektu, zatim celkove pod 1TB ciste kapacity. Takze nastesti zadna SAP HANA nebo tak. Kdybych mel k dispozici rozumne admistratovatelny kontejnerizacni system obdoby proxmoxu (vmware is dead), tak bych ty zdrojaky nacpal do kontejneru a mam to o neco jednodussi.

NAS replikace staci async. Jedine misto, kde pouzivam sync, je pripojeni klientu k nfs.

Rozpocet stanovit nemuzu, muzu jen predlozit vedeni cisla, ale vetsinu obchodni jednani vede primo vedeni.

Protoze tu nikdo nema zkusenosti z cloudovych poskytovatelu apod., tak me moc jinych technologii jak resit tyhle veci nenapada. Proto se poptavam, co se pouziva pripadne u koho se daji nechat nacenit reseni, nez se to pripadne bude resit DIY.

15
Sítě / Re:Doporučené postupy k IPv6 pro domácí síť
« kdy: 14. 05. 2025, 11:48:34 »
Dotaz - Jak se na takové síti řeší pravidla firewallu pro jednotlivá zařízení, když se jim IP adresy náhodně "losují z klobouku" a ještě jich má každý interface několik? To musí být docela peklo...

Pokud jsou mysleny ty "anonymizacni" ip adresy, tak funguji jen pro odchozi spojeni. Pro prichozi proste fqdn/prvnich 64b apod. Ale ja mam celou sit ipv6 static, tak si to taky rad prectu, zejmena ve vztahu k SLAAC a aktualizace dns s zivotnosti dns zaznamu :-)

Stran: [1] 2 3 ... 38