Příspěvky

511

Software / Re:Dohledový systém

« kdy: 06. 01. 2021, 16:40:27 »

jo, zabbix je také dobrý služebník, za mě je dost rozsáhlý na konfiguraci, přidávání vlastních grafů a dashboardů není zrovna snadné. Nemá svůj backend pro ukládní historických dat, takže k němu musíš stejně přidat něco, kde to vše bude uložené, pokud ti nestačí pouze current monitoring. Někomu může vadit frontend v php a s tím spojené těžkosti při upgrade a provozu.

Také to je ale dobrá volba.

512

Software / Re:Dohledový systém

« kdy: 06. 01. 2021, 15:01:08 »

krátce, možností je pořád spousta, nagios a cacti ještě žije, ale mrkni třeba na prometheus, prometheus alertmanager, systemd-exporters, grafana, je s tím více práce, ale funguje to dobře.

V enteprise poslední dobou nagios odstraňujeme a jedeme buď splunk a několik pluginů nebo elk stack s logstashem, beatem na alerty, část věcí pak jde do front v kafce, kde nad tím může být nějaký IPS/IDS/Alerting.

Cest je ale hodně, ani nagios není špatný, když s ním umíš.

513

Hardware / Re:NAS hardware pro cca 56TB (TrueNAS)

« kdy: 06. 01. 2021, 10:05:49 »

podle dotazu mi to evokuje domácí uložiště a nikoliv do firmy, proto věci jako multi-tentant/tier/volume, iSCSI nepovažuji za potřebné. Těch možností opravdu celá spousta, když není znám cíl a potřebné vlastnosti, těžko něco doporučovat, můžeme jen hádat. Ve firmách málokdy dostávám poptávku po "NAS", spíše chtějí nějaké uložiště pro něco nebo chtějí něco s vysokou dostupností, termín "NAS" subjektivně slyším více u spotřebitelů.

Hlučnost je na domácí použití podstatná vlastnost, do firmy irelevantní. Riziko požáru jsem jen zmínil bokem, nechtěl jsem ho rozmazávat. Ne ke všem bezpečnostním doporučením máš nějakou statistiku k dispozici, odvolávat se na ní je absurdní.

Vycházím z toho, že se autor ptal jaké auto používáte a za jakou cenu se tak dá sehnat. Zmiňovat u takového dotazu enterprise grade funkce, které cenu posunout o řád výš asi není nejvhodnější.

514

Hardware / Re:NAS hardware pro cca 56TB (TrueNAS)

« kdy: 05. 01. 2021, 14:07:14 »

kazdy tu pise, co ma doma a v praci. Nikoho tu nenapadne dat zakladnu otazku: Aky je ucel stavby toho NASu?

Zdravim,
Chtel jsem se zeptat "jaky hardware" tady ucastnici pouzivaji pro NAS s TrueNAS OS nebo alternativnim open source OS.

Vždyť se tazatel právě ptal na to, co používají ostatní. Otázka k účelu tady přímo či nepřímo padla několikrát.

515

Vývoj / Re:Mají smysl daily standupy?

« kdy: 05. 01. 2021, 11:49:10 »

Mě by zajímalo kolik lidí tu poznalo víc způsobů vývoje a kolik zná jen ten jeden? Já jsem poznal za život asi 4 a za sebe můžu říct, že self organizing teams bylo to nejlepší, s čím jsem se setkal. Scrum + daily standup je takový typický korporátní způsob řízení vývoje, který sice podává nějaký výsledky, ale většinou totálně zabije chuť a kreativitu těch, kteří by toho dokázali udělat mnohem víc než jen "to co mají ve sprintu" - těmto lidem obvykle záleží i na tom jak ten kód vypadá.

Ale jinak je mi to asi jedno - Scrum je skoro všude a firmám ta neefektivita očividně nevadí

typický korporátní způsob to je ale jen v posledních letech, kdy to frčí i v korporátech a zatím jsem v českém prostředí neviděl správně použitý scrum, hlavně, že mají svoje "kmeny".

Pokud vývojáři ví co mají dělat, je asi super je nechat se organizovat samostatně, pokud ale potřebuješ každý dva týdny zadávat podrobně úkoly vývojářům a potřebuješ přesně kontrolovat (a dále procesovat) jejich výstupy, moc dobře to nefunguje, nemusíš se totiž potkat.

Asi bych to negeneralizoval, zkazit se dá každý proces jeho špatnou volbou nebo nedůslednou implementací. Self organised team není zrovna nejlepší, pokud třeba máš QA, potřebuješ zaškolit uživatele a podporu, musíš přetisknout brožury a materiály.

Naopak například při implementaci CI/CD, logávání, monitoringu, IPS/IDS či jiných vyloženě technických věcí je využití scrup, daily stand up většinou naprostá katastrofa a self organized team, který spolu stejně komunikuje celý den, nejlepší. Ta ty úkoly není možné často tak rozsekat do sprintů, není možné úkol označit za dokončený, když existují cyklické závislosti, hodně času se zabíjí vůbec vysvětlování terminologií a fungováním scrum masterovi/product ownerovi atd.

516

Vývoj / Re:Mají smysl daily standupy?

« kdy: 03. 01. 2021, 23:12:49 »

Většinou je to nutné jen tam, kde je hodně lidí co sami od sebe nic neudělají a potřebují dohled. Ještě jsem neviděl aby to bylo nutné v teamu, kde lidi dokážou komunikovat a řešit případné problémy hned sami od sebe.

Metodiky jako Scrum a Kanban právě stojí na takových mini setkáváních, není to o hodně lidech v týmu (zpravidla tady jsou 4 až , ale o způsobu práce na úkolech a organizaci práce, zároveň to slouží jako vstup pro další zúčastnené (product owner, scrum master).

Neřikám, že tyhle metodiky jsou kdovíjak boží, ale fungují na určitých principech a tyhle stand upy mají smysl.

Pokud takový denní stand up slouží jen jako povídání o ničem, většinou moc prospěšný není a zažívám to skoro denně.

517

Hardware / Re:NAS hardware pro cca 56TB (TrueNAS)

« kdy: 03. 01. 2021, 20:56:56 »

Riziko pozaru je nemale? Za me je riziko pozaru uplne minimalni.

minimální? Naopak, právě vznícení počítačů či související elektroniky je poměrně časté. Ve firmách z bezpečnostních důvodů nám třeba hasiči nepovolují, aby servery byly umístěny mimo skříně (racky), které brání rozšíření požárů do okolí, stejně tak máme povinnost mít poblíž hasící přístroje.

Požárů od stolních počítačů doma, kdy se elelektrickým výbojem vznítí prach uvnitř nejsou zrovna ojedinělé (nemám ale statistiky).

Takže jinak řečeno sis to tvrzení jen vycucal z prstu.

Hasiši takovouhle statistiku nevedou.

Jakékoliv elektrické zařízení, které běží nonstop bez dozoru a může se v něm kumulovat prach je nebezpečné a nesmí kolem být žádné hořlavé materiály. To nás učili na škole.

518

Hardware / Re:NAS hardware pro cca 56TB (TrueNAS)

« kdy: 03. 01. 2021, 18:58:48 »

Riziko pozaru je nemale? Za me je riziko pozaru uplne minimalni.

minimální? Naopak, právě vznícení počítačů či související elektroniky je poměrně časté. Ve firmách z bezpečnostních důvodů nám třeba hasiči nepovolují, aby servery byly umístěny mimo skříně (racky), které brání rozšíření požárů do okolí, stejně tak máme povinnost mít poblíž hasící přístroje.

Požárů od stolních počítačů doma, kdy se elelektrickým výbojem vznítí prach uvnitř nejsou zrovna ojedinělé (nemám ale statistiky).

519

Vývoj / Re:Mají smysl daily standupy?

« kdy: 03. 01. 2021, 18:47:06 »

pokud se to dělá tak jak to vídám v bankách, tak rozhodně nemají.

V případně třeba metodiky Kanban jsou skoro životně důležité, jejich hlavní cíl je vyčistit bariéry a zajistit, aby slíbená práce pro celý den neměla žádné překážky a mohla být dokončena, jakmile jsi ve stavu, kdy nejsou daily stand up potřeba, znamená to, že nemáš bariéry k dokončování úkolů, tj. ideální cílový stav. Jejich forma musí být ale krátká, cca minutu na člověka, slouží pouze jako rekapitulace cílů a dokončených úkolů pro zbytek týmu.

520

Hardware / Re:NAS hardware pro cca 56TB (TrueNAS)

« kdy: 03. 01. 2021, 12:52:10 »

s hlučností to je dobrá poznámky, rackové servery jsou opravdu hlučné a dá chvilku práce ty větráky vyladit (oddělat, vyměnit atd.). Stejně tak doporučuji tyhle NAS věci s hodně disky mít v nějaké rackové skříni, protože riziko požárů je nemalé (zkrat a prach se umí snadno vznítit, větráky u serverů rádi oheň rozeženou po okolí a je na problém na světě).

521

Sítě / Re:Subdomény na stejné IP

« kdy: 02. 01. 2021, 19:22:19 »

asi se motám v tom jak to máš a co chceš. Chápu správně, že ta subdoména má běžet někde jinde než na tom banana pi a na ten banani pi míří provoz z veřejné ip adresy?

V první řadě nasměruji A DNS záznam pro subdoménu na tvoji veřejnou adresu, provoz by měl končit na tvém nginxu na BPi.

Pak stačí přidat konfiguraci do nginx a díky SNI hlavičkám u http paketů to umí sám spárovat:

Kód: [Vybrat]

server {
    listen 80;
    server_name subdomena.example.com;
    root /var/www/subdomena.example.com/html;
}

Pokud bys naopak chtěl obsluhovat subdoménu jinde než na BPi, třeba na RPi, musíš na BPi udělat pro nginx pravidlo, aby provoz forwardovalo (reverzní proxy):

Kód: [Vybrat]

upstream rpi {
    server rpi_ip_address:80;
}

server {
    listen 80;
    server_name subdomena.example.com;

    location / {
        proxy_pass http://rpi$request_uri;
    }
}

Na tvém RPi poté přidat konfiguraci pro nginx, jak kdyby tam provoz mířil přímo:

Kód: [Vybrat]

server {
    listen 80;
    server_name subdomena.example.com;
    root /var/www/subdomena.example.com/html;
}

522

Software / Re:Nástroj na skenování zranitelnosti webu

« kdy: 02. 01. 2021, 11:41:11 »

zial, github nevyhovuje bodu 2.
mohli by ste prosim konkretne menovat "jiné nástroje"?

no, ale to není přece problém, aplikaci nahraješ do privátního repositáře a využiješ poměrně solidní databázi na známá CVE podle závislostí, stejnou službu nabízí i gitlab, azure/aws/google.

Těch aplikací je dost a zároveň málo, jaký k tomu máš účel? Proč to potřebuješ?

Korporátní svět ujíždí na automatických nástrojích na kontrolu zabezpečení aplikací a ve výsledku to je spíše vynucování code style a vlastní nastavení pravidel, ten nástroj sám od sebe neodhalí většinou nic moc, ale dokáže ti udržet kvalitu kódu a sjednotit chování aplikací. Rozhodně nečekej, že použiješ nějaký nástroj a oni to rovnou řekne, kde máš díry a co opravit, naoak na tebe vyhodí obrovské množství chyb.

Primárně bys měl hledat nástroje kolem frameworku, který používáš, protože ty ti nejlépe řeknou, co je špatně.

Pro začátek bych ti doporučil zdarma dostupný v javě napsaný (funguje na linuxu i windowsu) nástroj udržovaný pod OWASP community https://github.com/zaproxy/zaproxy. Jeden z mnoha tutoriálů je třeba tady https://medium.com/volosoft/running-penetration-tests-for-your-website-as-a-simple-developer-with-owasp-zap-493d6a7e182b, proskenuje ti to lokální aplikaci a zjistí, jetli nemá základní nedostatky.

na kali linuxu vlastně není nic víc než je běžně repositářích jednotlivých distribucí, jen to tam je již předinstalované, většina těch nástrojů jsou ale poměrně složité a těžké na ovládání, takže je lepší se jim v počátku vyhnout než člověk ví přesně co chce.

523

Software / Re:Nástroj na skenování zranitelnosti webu

« kdy: 01. 01. 2021, 23:02:25 »

github a jiné nástroje umí skenovat a kontrolovat závislosti. Poté automatické testy na code style. OWASP i zmíněný Nessus dělá testy takový nemastný, sice to chytne základní konfigurační chyby, ale že by to řeklo, že aplikace není zranitelná, většinou moc ne.

524

Hardware / Re:NAS hardware pro cca 56TB (TrueNAS)

« kdy: 01. 01. 2021, 22:55:44 »

doma na svoje věci používám 4 x hpe microserver gen8, spojené je mám přes 20Gbe infiniband, běhá to velice slušně, hlavně to nezabare moc místa a ani proudu.

U sebe v DC mám naopak hpe dl380 s 20 x 2.4TB plotnovými disky, pořizovací cena asi 40tis přes ebay. Pro klienty většinou nasazujeme nové 2U servery (ať už hpe dl380, hpe apollo 4000, dell x20).

Pokud chceš nízkou cenu, klidně bych se nebál vzít něco jako repasovaný Dell PowerEdge R510/610 (pro 8 LLF disků), s 32GB ram a dvěmi ssd disky pro OS ho koupíš kolem 10tis, k tomu někde eshopu vezmeš něco jako 8 x Seagate IronWolf 6TB (celkem za cca asi 25 tis) a máš storage do 35 tis, což není špatné.

U FreeNAS dá trochu práce ho vyladit, někdy to chce trochu experimentování, ale i ve výchozím stavu poskytuje dobré služby.

525

Vývoj / Re:BASH - echo "/!/"

« kdy: 31. 12. 2020, 13:52:41 »

tohle je rychlejší než využívat šipky, proč bych listoval seznamem, když mohu příkaz spustit rovnou? Vykřičník mi umožní s příkazem pracovat a třeba ho zkopírovat do schránky či uložit do souboru, šipky to sami o sobě neumožní. Často využívám např. "echo !-2 >> commands.sh" pro uložení posledního příkazu do souboru, abych ho mohl použít příště.

Každopádně těch cest je více, je možné si namapovat na klávesy (klidně na šipky) vlastní příkazy přes inputrc.

Začni více pracovat v terminálu a výhody tohoto chování pochopíš, práce s tím je pak obrovsky rychlá, přes terminál jsem násobně rychlejší v častých operacích než kdokoliv, kdo má v ruce myč a musí to někde klidat.