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

Stran: 1 [2] 3 4 5
16
Hardware / Re:Gigabitový router pro OpenWRT
« kdy: 04. 08. 2022, 12:18:39 »
Ja mam rad pfSense (pripadne OPNsense), proto bych sel do neceho takoveho. ServeTheHome k tomu ma par videi, jedno treba zde. Ma to usporny, ale docela vykony CPU. 4x 2.5Gbe porty (podotykam Intel chipset) a je to pasivne chlazene. Je to o neco drazsi nez ty male ARM krabicky, ale zas to zvladne vic i nez jen routovat...

Dal bych tam Proxmox a pfSense provozoval ve virtualce.
Na internetu je spousta navodu (psanych i video), jak to cele zprovoznit.

17
V praci pouzivame Confluence... ale je to hrozny moloch.

Doma jsem sveho casu pouzival jiz zminovanou DokuWiki. Ale celkove mi centralni Wiki pripada jako prezitek. Stejne tam nejsem schopny nic najit. :D

Pro svoje osobni potreby jsem si zvykl na Obsidian. Je to jednoduche a poznamky se pisi v MarkDown. Vyhledavani funguje uspokojive. Synchronizaci mezi zarizenimi lze resit ruzne, ja pouzivam Nextcloud.

Pripadne jsem jeste zkousel Boost Note, coz vypada dospeleji a ma snad i vlastni synchronizaci a umoznuje kolaboraci v tymu/firme a i integraci s dalsimi nastroji... ale prave kvuli mnozstvi funkci jsem hledal neco jednodussiho.

Pripadne dalsi (drive pouzivany) nastroj na poznamky je Zim Wiki. Jednoduche rozhrani, ale za me naprosto funkcni. Jedina nevyhoda, diky ktere jsem hledal jine reseni je, ze nepouziva MarkDown, ale vlastni wiki syntax. Jinak je to klasicka adresarova struktura s plaintext soubory, takze citelna kdekoliv a cimkoliv.

18
Hardware / Re:Hardware pro DYI server Docker + CI + webapps(dev)
« kdy: 17. 02. 2022, 11:04:34 »
Pořád ale nevidím důvod k mirroru.

Tohle mi prijde dost kratkozrake. Ceny SSD (NVME) jsou relativne nizke, takze jeden duvod pro ano.
Ale jako dulezitejsi mi prijde, ze SSD (narozdil od HDD) mohou umrit bez varovani. Takze proc se nepojistit proti vypadku tim, ze dam 2 SSD do mirroru (samozrejme ne ze stejne serie, koupene ve stejnou chvili), abych si usetril ztratu dat a vypadek... Jako bonus dostanu rychlejsi cteni (ac pri zapisu zadne vyhody co se tyce rychlosti nejsou). Ja to vidim jako win-win.

19
Hardware / Re:Hardware pro DYI server Docker + CI + webapps(dev)
« kdy: 01. 02. 2022, 09:23:35 »
Za me mi prijde tvuj vyber jako rozumny. Sam provozuji server s ASRock Rack deskou, akorat se starsim X470 chipsetem. Supermicro si myslim, ze je porovnatelne s desky ASRock Rack. Je to takovy lepsi consumer grade HW, horsi (pocitove, hlavne podporou co se tyce vydavani firmware/BIOS) server grade HW.
Do te desky se vic jak 128GB RAM nacpat neda - 4 sloty po max. 32GB modulech.
Ja bych hodil ty dva NVME disky do ZFS mirroru, vykonu by to melo mit dost a navic stabilni a provereny filesystem.

V Proxmox se da do LXC kontejneru "bind mount" dataset ze ZFS poolu, takze pak ma kontejner pristup primo na ZFS bez prostredniku, mohlo by pomoc s vykonem (bylo by dobre se podivat na ZFS a pripadne "potunit" nastaveni poolu/datasetu na dany workload). Nevim, jak je to u Docker, ale cekal bych, ze to pujde take...

20
Sítě / Re:Propojení dvou domků od jednoho ISP (Starlink)
« kdy: 01. 02. 2022, 09:11:54 »
Na podobnou vzdalenost provozuji spoj ze dvou Ubiquiti zarizeni - Ubiquiti LiteBeam 5AC Gen2 a Ubiquiti NanoBeam 5AC Gen2. Funguje to spolehlive. Spoj ma rychlost cca 300Mbit/s. Na internet (30Mbit/s UP/DOWN) to staci a i na prehravani videa v jednom baraku z NAS v druhem baraku...

Co se tyce topologie, tak mam router v baraku s internetem a jednu sit spolecnou pro obe budovy. Sic VLANy pouzivam, ale na rozdeleni site jako takove, nemam rozdilne VLANy pro kazdy barak. Bezdratove pojitka jsou v rezimu bridge. Slouzi jen jako "vzdusny kabel", nic vic, nic min.

Takze budto bezdratovy spoj nebo natahnout optiku. S bezdratem bude nejspis mene prace, zvlast pokud by se optika mela zakopavat do zeme.

21
Server / Re:Hetzner - reálné zkušenosti
« kdy: 24. 11. 2021, 11:35:05 »
Hetzner používám. Nemám tam toho moc, ale to co tam je, tak funguje. Problémy nejsou. Vše běží jak má.
Občas si tam něco otestuji, když potřebuji přístup odkudkoliv. Zatím se mi nestalo, že by cokoliv blokovali/smazali. Za tu cenu a dodané služby mohu za mě doporučit.

22
Server / Re:Docker Swarm mode
« kdy: 20. 08. 2021, 11:00:32 »
V pripade, ze uvazujete o jedinem VPS, tak za me docker swarm nedava smysl. Navic to vypada, ze docker swarm upada v zapomneni - link.
Sel bych cestou docker + docker-compose. To funguje, doma to provozuji na vicero VM.
K8s je uz zase jina liga a pokud se clovek nehodla do tohoto tematu ponorit, tak je to jak s kanonem na komara. Sic si s K8s hraji a neco mi na nem bezi, tak se porad necitim na to, ze bych na nem provozoval neco vic... mozna casem. :) A ac se da K8s (treba v podobe K3s) provozovat jako standalone, tak mi to pripada opet zbytecne komplikovane a prosty docker bude stacit a jednodussi na spravu a setrnejsi na zdroje.
Navic si myslim, ze na uvedenem stroji (1vCPU a 2GB RAM) by K8s vzalo vetsinu zdroju...

23
Server / Re:Lokální DNS server pro služby v dockeru
« kdy: 20. 08. 2021, 10:46:36 »
Na vice mistech resim dvemi zpusoby.

Starsi - jiz navrhovany nginx (balicek v OS + konfigurace), kdy je nastavene, ze nginx posloucha a podle toho, kam smeruje dotaz, tak presmeruje na localhost:port.

Kód: [Vybrat]
sluzba0.doma.lan => localhost:8080
sluzba1.doma.lan => localhost:8081
sluzba2.doma.lan => localhost:8082

Pouzivam vlastni RootCA a certifikaty mam pro kazdou sluzbu.

Novejsi je pro me Traefik v docker. Vyhodou je, ze je to vse v docker a nemusim vystavovat porty jednotlivych kontejneru na localhost, vystavim jen https Traefiku a ten posloucha.

Kód: [Vybrat]
sluzba0.doma.lan => Traefik => kontejner0
sluzba1.doma.lan => Traefik => kontejner1
sluzba2.doma.lan => Traefik => kontejner2

Opet pouzivam vlastni RootCA a certifikaty pro jednotlive sluzby jsou podhozene Traefiku, ktery je pak pouziva.

DNS resim na pfSense, kdy si dam jednotlive zaznamy do DNS resolveru.

24
Server / Re:Ubuntu server - ansible - vault password
« kdy: 05. 08. 2021, 15:36:56 »
..já ale to heslo chci mít zakryptované tak aby mu rozuměl jen ansible a nedalo se nijak zjistit..je to tak složité????

BTW, tenhle pozadavek se mi zda absolutne nerealny. Bud neco zasifruji a zahodim klice, pak se k tomu nikdo nedostane. Nebo budu mit neco zasifrovane a od toho klice (popripade Ansible), ale pokud se k tomu klici dostane kdokoliv jiny, tak se dostane i k zasifrovanemu obsahu. Jedina moznost je, co nejvice stizit moznost uniku klicu do nepovolanych rukou. Pokud ale klice nekde existovat budou (a to musi, abych se k obsahu dostal), tak bude vzdy sance, ze je nekdo zneuzije.
Pak je jeste moznost, ze mi neco unika... :D

25
Server / Re:Ubuntu server - ansible - vault password
« kdy: 05. 08. 2021, 15:22:36 »
Nj, ale tohle Ansible neumi. Kdyz mu clovek udela vault, tak ho taky musi nejak umet rozsifrovat -> dela to heslem, ktere musi nejak dostat. :) Jedina moznost (alespon bez dalsiho sw) je holt mit nekde "schovane" heslo v plain textu a mit ho citelne jen pro uzivatele, ktery ten ansible pousit.

Edit: Napada me jedna moznost, kterou jsem pouzival ve svych scriptech. Je to takova "Security through obscurity". Mit soubor s heslem zasifrovany gpg klicem (ktery vlastni dany uzivatel). A pomoci scriptu ten soubor desifrovat a poustet ansible treba jak jsem uvedl ten posledni prikaz:
Kód: [Vybrat]
ansible-playbook --vault-password-file my-vault-password-client.py

26
Server / Re:Ubuntu server - ansible - vault password
« kdy: 05. 08. 2021, 14:36:16 »
Bud musis zadat heslo rucne:
Kód: [Vybrat]
ansible-playbook --ask-vault-pass site.yml
Nebo ho mit nekde v souboru, kde si to ansible precte:
Kód: [Vybrat]
ansible-playbook --vault-password-file /path/to/my/vault-password-file site.yml
Dalsi varianta je na to mit vlastni script:
Kód: [Vybrat]
ansible-playbook --vault-password-file my-vault-password-client.py

27
Absolvoval jsem obe, zalozene na RHEL 8.

RHCSA je zamerena na RHEL samotny + nejake veci co prisli v RHEL 8 (ale pokud to clovek neda, tak to neni zasadni). Pokud clovek dela v Linux kazdy den, tak to pro nej nejspis nebude problem udelat, alespon na druhy pokus. :)
RHCE je cela jen o Ansible. Prijde mi, ze to co se v ni chce, tak je dost tezke a kolikrat se v praxi nepouziva ci se resi jinak.
Idealni je, kdyz si clovek muze projit kurzy (online) a podivat se, co tam prezentuji. Pak se aspon muze zorientovat, co se v samotne zkousce bude po nem chtit. Bez toho je to spis nerealne to dat na prvni dobrou, ikdyz Ansible pouziva.

28
DDNS funguje tak, ze nejaka sluzba (nejcasteji) na routeru kontroluje verejny DNS zaznam s IP adresou pridelenou na WAN. Pokud se shoduji, tak je vse v poradku. Paklize ne, tak dojde k nahrazeni IP adresy v zaznamu za novou a vse zase funguje.
Nejsem si jisty, jak je na tom Zyxel, ale tahle sluzba je k dispozici na Mikrotik, OpenWRT, Turris, pfSense, OPNSense a dalsich.
Asi nejjednodussi moznost, pokud mate dynamickou verejnou adresu.

29
Server / Re:Router a Server v jednom
« kdy: 04. 05. 2021, 18:09:04 »
rozdil mezi all-in-one a samostatnym resenim se mi zda maly

Protože tomu nerozumíš, to je vše.

...

Dekuji, ze jste mi to vysvetlil.  8)

Moc nevidim rozdil v bezpecnosti, kdyz budu mit all-in-one reseni, kde bude virtualizovany router, NAS a kdo vi co jeste. Pokud to spravne nastavim a udelam si pravidla jake popisujete, tak jsem na to stejne (predpokladam pravidelne aktualizace a ze ve virtualizaci neni ve vychozim stavu nejaka bezpecnostni dira). Rozdil je IMO v tom, kdyz si rozvrtam hypervisor nebo mi odejde HW, tak se mi rozbije vic veci nez jedna.
Ano, povazuji za spatny napad davat extra sluzby do routeru/FW, protoze ten ma byt bezpecny a cokoliv navic prinasi dalsi cestu dovnitr. Nikdy bych neuvazoval nad resenim nacpat vsechny sluzby do jednoho serveru, aby plnil funkci FW, NAS, web serveru, ... Ano, to si pak dokazu predstavit, ze jedna ze sluzeb umozni proniknuti utocnika dovnitr.

P.S.:Nebudu rozporovat, ze vim prd a predstavivost mam mizernou. :D

30
Server / Re:Router a Server v jednom
« kdy: 04. 05. 2021, 13:31:51 »
Pokud to technologie umoznuje, tak mozne je vse. :) Samozrejme to neznamena, ze to tak je vzdy v poradku. Ale co jsem tim chtel rict. Zkousel jsem mit all-in-one reseni, ale z vlastni zkusenosti jsem prisel na to, ze mi to za to nestoji. Zaprve jsem nebyl schopny nasadit pfSense do Proxmox bez problemu (z nejakeho duvodu jsem mel tak polovicni rychlosti do WAN a vypadaval mi internet kvuli nedostupnosti DNS serveru u klientu). Vedel jsem, ze na samostatnem HW tyhle problemy nejsou. Zadruhe co se stane, kdyz budu delat udrzbu na jedinem stroji a nepojede mi (cele rodine) internet. Jak pak budu hledat reseni na internetu? :) A dalsi vec je, ze cim vic toho budu mit na jednom miste, tak tim vetsi sance si vsechno rozbit...

Potrzeno, secteno. Radeji mit jednu z nejdulezitejsich komponent na siti na dedikovane HW, kde i s obcasnym restartem kvuli update budu mit "rock solid" router, ktery me nezklame. Se zbytkem si pak muzu delat co hrdlo raci a ostatni si niceho nevsimnou (alespon pri koukani na Novinky a YT). Ale jak se rika YMMV.

Co se tyce bezpecnosti, tak tam je to asi jedno. Pokud nekde neco spatne nastavim a utocnik pak bude mit pristup do me infrastruktury, tak rozdil mezi all-in-one a samostatnym resenim se mi zda maly. Rozsah skod muze byt ruzny, ale v kazdem pripade bude mit clovek o praci navic.

Stran: 1 [2] 3 4 5