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 - _Tomáš_

Stran: 1 ... 19 20 [21] 22 23 ... 47
301

Ten pohovor není jen test na splnění, takže by pochopitelně následovala otázka na to, jak a proč to asi uvnitř funguje a jestli by ten bash byl opravdu nejlepší řešení.

Zatím to na mě s bashem ale nikdo nezkusil :) Nicméně celé tohle vlákno je o algoritmizaci, takže jazyk opravdu až tak důležitý není. Popravdě jsem za posledních hmm 15 let v projektech viděl C/C++, Python, Javu, Golang... dobrému programátorovi to přeučení zase tak dlouho netrvá.


Ten algoritmus na čtení souboru po zpátku je zajímavý problém a řeší ho nejedna databáze při kontrole WALu nebo to je běžný pattern v event sourcing systemech, kdy se dohledává poslední záznam k události.

tac v tom nedělá velkou logiku, zjistí velikost souboru, rozdělí si ho na 8kb bloky, seekne na poslední blok, hledá v něm separator, pokud najde, pošle vše za separatorem na výstup a tak dále. Důležité je, že velikost bloků mezi separatory může být max. 2 * 8kb + 2, takže udělat tac binárního souboru rádo padá na chybě, že vstup je příliš velký. Perf je správný nástroj na ladění těhle udělátek. Když si místo separátoru představím hledání UTF-8 znaků, koncu řádku či jinou logiku jako nodů v jsonů, avro fieldů atd., mám základní algoritmus a jednotlivé dekodéry mohu přidat podle potřeb použití.

Nj. už není doba pásek, které se četli pozpátku otočením a zvuk šel i pozpátku přehrát. Dnešní počítače jsou až příliš lineární a jakýkoliv průchod pozpátku nebo i přeskakování v cyklech jim dělají nemalé problémy v optimalizaci.

302
je otazka co bych si o tom cloveku myslel, ze je od neho pekne, ze se dokaze zeptat na doplnujici informace,
nebo naopak, ze je natvrdly a potrebuje k tomu dalsi omacku.

To záleží. Pokud se ptá na věci jako "A jak načtu soubor?", tak je to samozřejmě špatně. Zdeněk Tomeš tu dal pěkné příklady smysluplných otázek.

Za mě jsou smysluplné otázky jednoznačné plus, u kandidáta na seniora je dokonce očekávám. Nejhorší jsou lidi, co tři dny kódí podle zadání a pak se zjistí, že ten jejich kód je na vyhození, protože to zadání pochopili blbě (bylo jim něco divného, ale nezeptali se). Nebo naopak stráví den nad něčím, co by se dalo napsat za hodinu, protože oni dělají obecné řešení, zatímco my to potřebujeme pro nějakou podmnožinu případů.

Citace
1) otaci se binarni soubor po bajtech nebo textovy soubor po radcich?
2) jestli textovy soubor, tak resime ruzne konce radku?
3) jestli textovy soubor obecne (tedy ruzne unicode varianty), resime BOM?

testovaci ukol znel jasne, reverznout soubor. tyhlety chytre otazky jsou dobre, kdyz se resi opravdovy ukol.
ale kdyz nekomu reknu vypis soubor pozpatku, a on se me zepta na tyhle veci, tak si reknu, ze to je magor,
ktery bude delat z jednoducheho ukolu elektrarnu :-(

Já dávám rád úkoly, u kterých se musí uchazeč doptávat, vidím totiž dva krajní typy seniorních programátorů, jedni chtějí co nejpřesnější zadání nebo účel a druzí si to udělají tiše po svém. Oba jsou v praxi užiteční a mají své místo, člověk by v první řadě měl vědět koho vlastně hledá. Zvykl jsem si nedbát tolik na konkrétní hard skill, spíš ať mi uchazeč předvede co umí nejlépe. Daleko důležitější je pro mě přístup k práci a řešení úkolů, protože vždy do týmu potřebuji nějakou konkrétní roli. Samozřejmě, když se hledá team leader, je potřeba pečlivě dbát na kombinaci hard a soft skills, to pak člověk tomu věnuje více času a filtruje podle znalostí velice brzy.

Jen taková šťouravá otázka, píšeš libovolný programovací jazyk, pokud bych tam přišel s řešením bash -c 'tac ./soubor', bylo by to považováno jako splnění a mohl bych domů?

303
Server / Re:Přístup k logům mailserveru
« kdy: 25. 03. 2022, 00:12:42 »
Skus pozret Vector od datadog https://vector.dev/ je to dost lightweight, vie to transformaciu a posiela to na rozne outputy (aj na viacere naraz)

vector je zajímavý projekt, hlavně mají skvělé testy všech dalších logovátek, což je velice užitečné i samostatně, ale hlavně ty testy ukazují, že ještě tak lightweight nejsou a ještě jim nějaká práce chybí.

Na produkci takový SW dnes nedoporučuji, obsahuje pořád drobné bugy a není vyladěný, viz třeba memory leak https://github.com/vectordotdev/vector/issues/11863, https://github.com/vectordotdev/vector/issues/11821 nebo leak otevřeného descriptoru https://github.com/vectordotdev/vector/issues/11742. To jsou bugy za poslední měsic ve stabilní verzi.

Věnuji se kritické infrastruktuře v enterprise sféře, v labu tyhle nástroje postupně testujeme, ale je to pořád bídá, spíše nestabilní bída. Je potřeba si ty proklamace na webu ověřovat a udělat si testy. Zatím to nepoužívá tolik firem v produkci, aby se ukázaly všechny nedostatky. S logováním je největší problém, že ho člověk kriticky potřebuje v momentě, kdy se dějí nějaké problémy a pokud ty problémy zároveň sestřelí logovací nástroj, mám na stole skoro katastrofu. Aby nástroj na sbírání logů bral více paměti než aplikace, kterou loguje je již na pováženou, stejně když tyhle nástroje obsahují nějakou formu dynamické alokace a GC (např. filebeat), lze čekat problémy s paměti, pauzováním procesu a nestabilními latencemi.

304
zle to neni. Ale jak jsem napsal vyse - z vlastni zkusenosti - obvykle je to takovy to

'Hele, dokaz nam, co umis. My chcem, abys byl nejlepsi. Jen ti to nezaplatime a budes pracovat na spagetach, co s timhle pohovorem a otazkama vlastne vubec nemaj nic spolecnyho'

samozrejme ne vsude to tak je.

To je snad legitimní, že uchazeč musí prokázat svoje znalosti?

Kde bereš přesvědčení, že musíš umět pouze a jen to, co reálně budeš používat? Vždyť obecné znalosti, přehled v oboru jsou naprosto nepodstradatelné věci nato to, abych dokázal dělat vhodná rozhodnutí, vyhnout se chybným rozhodnutím a umět se poučit z jiných řešení ač je nikdy nepoužiji.

IT a programování má trochu nevýhodu, neexistují obecné školy a obory, o které bych se mohl opřít. Neexistují normy a postupy, které by se dalo jednoduše zkouškovat. Je tedy na každé firmě, jak se postaví k přijímání a ověřování uchazečů a je pouze a jen na nich, jaký zvolí postup a je jejich věc, jestli díky nevhodně zacíleným otázkám nepříjmou nejvhodnější uchazeče. Není jejich povinností kohokoliv příjmout, stejně jako není tvojí povinností takový pohovor absolvovat nebo přetrpět.


305
Server / Re:Přístup k logům mailserveru
« kdy: 24. 03. 2022, 09:39:16 »
ten pattern se dělá ale jiný, logy posíláš na syslog daemona (buď socket nebo localhost udp, postfix podporuje), tím daemonem je rsyslogd a ten vytváří soubor, posílá data jinám a routuje to. Hlavní důvod je, že prostě nechceš nechat plný přístup na logy pro aplikaci, v případě průniku by totiž útočník mohl logy promazat, chyba v aplikaci smaže logy atd., to jsou vše rizika a lepší je se jim vyhnout.

Pokud chceš číst soubor, rsyslogd má modul imfile a ten umí pokračovat ve čtení po restartu, viz dokumentace https://www.rsyslog.com/doc/v8-stable/configuration/modules/imfile.html a věta "When rsyslogd is stopped while monitoring a text file, it records the last processed location and continues to work from there upon restart"

20 tis emailů za hodinu není velké číslo, rsyslogem na na produkcích teče tohle množství každou vteřinu. Asi všechny tyhle nástroje zvládnou 20 tis / hod bez komplikací.

306
Server / Re:SSH ověření klíčem a kontrola SSH na firewallu
« kdy: 24. 03. 2022, 09:21:43 »
mluvíš o firewall, ale pro mě je firewall něco co šahá max. do 4. úrovně OSI modelu, ssh je až na 7, na které se přenáší a ověřují host keys. Takže spíše popiš, co vlastně je váš firewall, co má dělat a jak funguje.

Ta chybová hláška nastává, když nesouhlasí host key, který má klient u sebe uložený s tím, co mu druhá strana pošle. Takže pokud tvůj "firewall" posílá svůj host key, tak kontrola selže. Musíš ale asi lépe popsat, co vlastně děláš.

307
Server / Re:Přístup k logům mailserveru
« kdy: 23. 03. 2022, 13:13:57 »
rsyslogd má modul imjournal, který umí číst journald logy a ty případně poslat beztrátově někam ven, tak to i používám. Journald je spíše nástroj na čtení a pohled na logy než jejich dlouhodobé ukládání.

Filebeat se právě s rotováním nevypořádává dobře, viz https://www.elastic.co/guide/en/beats/filebeat/current/file-log-rotation.html, podporuje rotování, která třeba dělá logrorate, kdy se soubor přejmenuje a vytvoří místo něho nový, už ale nepodporuje truncatování souboru, gzipování atd. On to není špatný SW, ale od něčeho, co je pro mě kritické nečekám, že se bude aktualizovat několikrát do roka o nové funkce a rozbíjet ty staré, takže to chce pozorně testovat kažou novou verzi. Těch případů, kdy se data.json při aktualizaci promazal a poslalo to vše znovu nebo po pár dnech přestal logovat jsem už zažil až příliš.

rsyslogd používám tak 15 let, konfiguraci je přenosná, vše se chová stejně a stabilně, nejsou problémy s aktualizacemi a dostupnost je na všech platformách, nevadí tomu být případně spuštění někde v dockeru či standalone.

Na druhou stranu konfiguraci rsyslogd má plnou komentářů, protože do toho šahám tak málo, že si to nepamatuji, naopak tu u filebeat umím zapsat asi zpaměti, protože do toho šaháme pořád, pořád je potřeba něco luštit z dokumentace a debugovat.

Když už máš rád tyhle nové věci, možná ještě mrkni na fluentbit, je to tenké, konfigurace je čitelná, je možné jí různě řetězit, dobře testovat přes sample inputy, má to exporty metrik v prometheu formátu a umíš konfiguraci přímo přikompilovat do kódu, takže můžeš mít jednu distribuční binárku, kterou stačí spustit a obsahuje vše.


308
Server / Re:Přístup k logům mailserveru
« kdy: 23. 03. 2022, 10:55:51 »
nxlog má funkci reliable delivery při přerušení tcp spojení až v placené verzi, to je povětšinou dost zásadní funkce a nechceš ztrácet logy při restartech servové části.

Proč chceš používat tyhle obskurní nástroje (ano, nxlog je prostě takový běžný enterprise SW, u nás ho třeba máme v rajfce) místo poměrně etablovaného a stabilního řešení v podobě rsyslogu? Stejně tak se tady nabízí ještě syslog-ng.

Ty moderní nástroje mají často problém se spolehlivostí, neumí se snadno vypořádat s pády, restarty, rotováním souborů a jinými neduhami.

U postfixu se mi dlouhé roky osvědčuje používat syslog logování, dávat to do rsyslog relay s lokální cache a rovnou posílat na rsyslog server, z kterého se to poté již může distribuovat do různých grafických udělátek. Při výpadku konektivity se logy pošlou dodatečně, mohu jednoduše alertovat, když logy přestanou chodit, mám to jednotné s ostatními nástroji a infrastrukturou.

Z těch placených je poměrně solidní Splunk, umí se totiž asi nejlépe vypořádávat s rotováním souborů, jejich truncování po rotování, s přejmenováním a jinými operacemi, když už teda pustíš aplikaci, aby si mohla sama spravovat logy a sama do nich zapisovat.

309
Server / Re:SSH ověření klíčem a kontrola SSH na firewallu
« kdy: 23. 03. 2022, 08:47:02 »
hledej ssh bastion, existuje velké množství SW, které tohle celé řešení bezpečnou cestou, tohle experimentování bez znalosti protokolu vede pouze k chybám a dírám. Je malá šance, že to uděláte správně.


310
a nemá náhodou ten Asus router také zapnutý DHCP a nepřiděluje ip on?

311
Ahoj,
Nemáte nějakou oblíbenou automatizovanou službu pro účel uvedený v předmětu?
Placenou nebo ne…
Nejlépe včetně doporučení pro prevenci a mitigaci pro známé sady používaných IT prostředků.

Dík
A je nějaká služba bez skenování, která jen hlídá aktuální útoky a zranitelnosti ? Nerad to říkám, ale ptám se kvůli aktuální  situaci na východě.

A co od toho vůbec čekáš? Drtivá většina tzv. útoků je jen přetěžování serverů, to zpravidla kvůli kapacitě musíš řešit s poskytovatelem konektivity. Pak tady máš bambilion strojových útoků, na ty můžeš používat blacklisty ip adres, např. cz.nic poskytuje sada z Turrisů. Pak tady máš cílené útoky, tam to nejtěžší, často ti ukradnou přihlašovací údaje či zneužijí nějakou málo používanou zranitelnost, někdy můžeš být infikovaný měsíce před samotným útokem, tam tě zachrání jen včasná reakce, nonstop monitoring a podrobná analýza logů a hledání anomálií.

Existují služby, které se více méně úspěšně snaží hlídat perimetr DMZ, např. zscaler.com, sonicWall, Imperva a další. S nimi moc reálné zkušenosti nemám, netuším jestli fungují nebo ne.

Nečekej, že koupíš SW a budeš mít vyřešenou bezpečnost, zatím ty řešení tak daleko nejsou. Nějaké pokusy jsou třeba s nemocnicemi a nasazují se chytré FW, ale je to takové nemastné neslané.

312
v práci všude používáme owasp, ten je dostupný na všechny platformy, placený a má na vše doporučení.
Diky moc a který produkt ?

konkrétně Qualys pro skenování systému a SonarQube pro skenování zdrojových kódů.

Žádný takový systém ti ale nezaručí bezpečnost, základem je vědět přesně co používáš, co kam komunikuje a sledovat aktualizace, CVE, changelogy. Tyhle nástroje ti jen poskytnou zpětnou kontrolu, že jsi vše potřebné zajistil, ale nejsou 100%.

313
v práci všude používáme owasp, ten je dostupný na všechny platformy, placený a má na vše doporučení.

314
DRBD je levný SW raid 1 po síti se všemi nevýhodami (výkonnost, latence, zotavování po výpadku atd.). Na extu to můžeš mít pouze jako active-pasive s failoverem. Asi jako hlavní nevýhoda je, že to je trochu poruchové, funguje pouze v privátní síti (nepodporuje šífrování a ani bezpečnou autorizaci) a je výrazně ovlivněno vytížením jednotlivých nodů (není třeba dobrý nápad takhle replikovat data z živé zatížené databáze nebo webového serveru), replikujena úrovni bloků, takže se občas může fs poškodit.

Potřebuješ to synchronně nebo asynchronně? Jaký objem dat a jaké iops? Jak je důležitá latence a doba obnovení?

Já na domácím labu mám cifs, v práci máme enterprise diskové pole a glusterfs. Dobře funguje zfs. Někdy lépe funguje dělat replikaci o úroveň výš, např. v databázi, aplikaci.

315
mna skor zaujima, ze ako sa dostat k praci na ICO pre zahranicne firmy. Samozrejme nemyslim firmy typu Titans, alebo CoolPeople, ktore vam robia pasakov a zarabaju na vas v podstate za nic.

chodí do na linkedin jako spam skoro nepřetržitě.

Stran: 1 ... 19 20 [21] 22 23 ... 47