Příspěvky

31

Server / Re:Monitoring

« kdy: 06. 02. 2017, 13:03:58 »

BTW dva starší případy: na webu parlamentu ČR byly k dispozici pirátské firmy a porno, zřejmě si nějaký admin zřídil server.

Ano, to byl hezký příklad. Prostě nějaký diletant si na server Parlamentu ČR nahrával soukromá data. Otázkou je, co takový člověk na takové pozici vůbec dělá, kdo ho přijal, zda ten server kontroloval apod. Jako vždy v případě ČR ten případ vyšel do ztracena.

Mimochodem, teď se "řeší" ten hack na MZV. Krásný komentář k tomu napsal někdo na blogu.nic.cz

http://blog.nic.cz/2017/02/06/hacknuti-mzv-jak-na-zavolanou/

Tam je řečeno vše. Jestli si stát myslí, že nás ochrání nějaké krabičky u ISP, tak proč nejde příkladem a proč nezačne u sebe?

32

Server / Re:Monitoring

« kdy: 06. 02. 2017, 12:54:03 »

IT se poměrně rychle mění, takže nehraje moc roli, jestli dotyčný manager řekněme před 20 lety prováděl deployment Windows 95 a Wordu 95. Výroba bot začátkem dvacátého stolení se měnila výrazně pomaleji, i když 20 let je pořád dlouhá doba.

To že manager nezná detaily té které práce není nijak na závadu. Nebo myslíte že kvalifikací pro managera ve Škoda Auto je to že má svářečský průkaz, pracoval jako lakýrník, montoval pneumatiky na vůz na lince, vozil krabice ve skladu, řešil aerodynamické problémy karoserií, navrhoval inovace spalovacích motorů, a k tomu uklízel dílny na konci směny a chodil mazákům pro svačinu?

Nemyslím že by u vyšších pozic bylo nutné přístup na internet paušálně zakazovat. Souhlasím že pokud nejde o vyloženě rutinní činnost, nikdo nevydrží pracovat prakticky non-stop 8 hodin každý den.

Tohle jsou přesně ty managerské kecy. Vedoucí, který si v roce 1991 hrál s Perlem bude mít jistě lepší náhled do IT, než vedoucí, co umí tak maximálně clicking a doublecliking.

Manager, který umí svařovat je jistě lepší, než manager, který neumí nic, protože ten první se minimálně umí vžít do role těch lidí, kteří si třeba stěžují na kvalitu odvětrávání a bezpečnostních pomůcek.

A jak píše Mirek, přece tu práci těch lidí taky musí někdo zkontrolovat. A ten by z titulu své funkce jaksi měl vědět, jak se to dělá.

Prostě ne, tohle se ukecat nedá. Monitoring má svůj význam v kritických provozech a tzv sledovaném pásmu. Tam je kolikrát člověk rád, že jej někdo neustále sleduje na kameře, protože jde i o jeho život. Ale ne u kancelářských krys. Obecně se dá říct, že pokud někdo nasazuje monitorning na své zaměstnance tak to je známkou toho, že něco silně zanedbal a monitoring mu stejně nepomůže.

33

Server / Re:Monitoring

« kdy: 06. 02. 2017, 11:18:23 »

A vy jste schopný odhadnout jestli nějaký úkol trvá 4, 6 nebo 8 hodin?

Dřív bylo normální (dřív třeba za Bati), že na vedoucí pozice se člověk propracoval až po té, co si vyzkoušel všechny předchozí činnosti, hezky odspodu. Takže ano, takový vedoucí potom ví, jak asi co dlouho trvá, protože to už někdy v životě dělal a má do toho náhled.

Dneska jsou vedoucí, kteří o dané věcí neví absolutně vůbec nic a někteří to dokonce považují za svou výhodu. Někteří dokonce ani neví, co ten jejich podnik dělá.

To za prvé. Za druhé by mě velmi zajímalo jaká je vaše definice práce. Chtít po někom v IT, aby měl trvale 8h denně ruce na klávesnici je asi to nejhorší možné pracovní prostředí, protože nejlepší nápady často vznikají při zcela jiných činnostech a většinou i zcela mimo pracoviště (třeba taková cesta na oběd je často k nezaplacení).

34

Software / Re:Velkost sifrovacieho kluca

« kdy: 15. 01. 2017, 11:04:50 »

Napríklad "password" = 8 bajtov = 64 bitov... Potom ako mám chápať tých 256 bitov?

Každá symetrická šifra potřebuje mít klíč pevně dané délky. Takže jako klíč se použije něco, co se odvodí z hesla - buď jeho rozšířením nebo zkrácením. Většinou se na to používá nějaká kryptograficky bezpečná hashovací fce, která pro libovolně dlouhý vstup dá vždy fixně dlouhý výstup.

Takže například heslo pro aes-256 můžete prohnat přes sha2-256 a dostanete tak 256b klíč pro použití v aes. (Což je teda dost zjednodušený příklad, v praxi se používají jiné způsoby, jak to heslo co nejvíc zamotat a získat z toho kvalitní a těžce získatelný klíč. Viz výše uvedený odkaz na KDF.)

35

Vývoj / Re:Co zpomaluje Javu? A co překlad do nativního kódu?

« kdy: 15. 11. 2016, 16:27:18 »

Tohle nelze v C++ dosáhnout. Zdrojové kódy nejsou dostupné, dodává se pouze hotový zkompilovaný program.

No ja ti nevim, Factorio je v C++ a modding scena je celkem aktivni. Ditto pro Skyrim. Ano, pocitali s tim (maji oficialni API), ale rozhodne to neni tak, ze kdyby Mojang nechtel, tak to nejde.

To není ani tak o tom, že by to nešlo, ale o tom, že by šlo pouze to, co by Mojang povolil. Změnu textur, změnu mapy, to půjde vždy - to je prostě změna datových souborů. Ale nějaké důkladnější změny (já hraju zejména technické packy), které z toho dělají de facto úplně novou hru (na stejném jevišti), tak to si nejsem jist, zda by tady bylo, kdyby existovalo nějaké officiální api. Možná jo, možná by jej vyvíjeli společně s  modařema a nakonec by to api umožňovalo vše, co se teď dělá změnou class souborů - akorát lépe dokumentovaně.

To je taky vidět i na tom Skyrimu. Mění se hlavně textury a modely. (Dneska už bych vanilla skyrim nehrál; zkoušel jsem Special Edition, jako je to pěkný, ale stejně jsem si hned nahrál nějaké mody z nexusu - zejména textury a modely postav). Na nějaký mód, který by kompletně měnil skyrim na něco jiného jsem nenarazil. A třeba takový SKSE potřebuje injektovat do paměti hry. To už přes jeho api udělat nelze.

Factorio jsem zatím nehrál.

36

Vývoj / Re:Co zpomaluje Javu? A co překlad do nativního kódu?

« kdy: 15. 11. 2016, 11:34:54 »

Ale prosímtě, minecraft v Javě je z hlediska výkonu dost tragédie, C++ verze je násobně rychlejší:

Nějak nám ty super hyper hotspot runtime optimalizace moc nefungují, že?

Aniž bych se chtěl vlamovat do dobře rozjetého flamu, tak tohle nelze srovnávat, protože:

MC v roce 2010 byl úplně jiný než MC dnes. Vyvíjel se. Dnes už se ví, co je potřeba a co není a jak by to mělo být a jak by to nemělo být. Pokud někdo přijde k hotovému a jen to přepíše (do libovolného jazyka), tak to bude výkonnější, protože ví, do čeho jde a může si to navrhnout lépe. První dema MC (se ještě ani nejmenoval MC) měla s dnešním MC společného tak akorát voxelovost. Toť vše.

Ovšem hlavním hybatelem v popularitě MC byla odpočátku možnost téměř neomezené modovatelnosti. Dodnes nemá mod API a je to dobře. I bez mod api už od alpha verzí MC vznikaly skvělé mody jen díky tomu, že je možné v jaru nahradit jednu třídu jinou, na libovolné místo dát hooky a zpětná volání apod. Tedy tím mod api byl samotný jar.

Tohle nelze v C++ dosáhnout. Zdrojové kódy nejsou dostupné, dodává se pouze hotový zkompilovaný program. A zatímco mod v javě napíše každý druhý hráč, tak injektovat nějaký vlastní kód do paměťového prostoru hry nebude dělat skoro nikdo. Oficiální mod api (až ho MS vydá) příliš nepomůže, protože bude dovolovat pouze to, co povolí tvůrci.

Takže díky za MC v Javě, nebýt tohoto, tak po něm dneska ani pes neštěkne a MS nekoupí Mojang.

37

Sítě / Re:Cvičení CyberCzech 2016

« kdy: 19. 10. 2016, 16:22:30 »

To se rovnou můžeme bavit o tom, zda má vůbec smysl samotný NCKB a CSIRT, zda jejich požadavky směrem k veřejným úřadům dávají smysl a zda nejsou někdy spíše kontraproduktivní (aneb mysleli jsme to dobře, ale dopadlo to jako vždycky).

Krátká odpověď je: NCKB vykazuje činnost.

38

Server / Re:Nastavení ulimit pro Apache httpd

« kdy: 15. 10. 2016, 15:56:49 »

P.S. Bylo by dobré na této diskusi prodloužit dobu přihlášení, protože než jsem stihl napoprvé příspěvek napsat a odeslat, tak mě systém odhlásil a já jsem o něj přišel.

To je v pohodě, to jsem tady hlásil už v roce 2014. To je ještě brzo na nějakou opravu.

39

Vývoj / Re:Aplikácia pre evidenciu dát v PHP

« kdy: 08. 08. 2016, 12:40:36 »

Nevím jak ty, ale většina lidí (včetně mě) peníze potřebuje pro uspokojení svých základních potřeb a zadarmo nic v žádném obchodu nedostane.

Většina lidí z IT má ty základní potřeby dávno zajištěné, a zbývá jim hromada prostředků na to se věnovat také něčemu jinému, než jen vydělávání peněz. Třeba na řešení zajímavých problémů, čímž se současně vzdělávají a zdokonalují. (Z jistého pohledu je to stále obchod - někdo dostane produkt který potřebuje, druhý dostane zaplaceno v podobě nových schopností. Není potřeba si neustále vyměňovat malé zelené papírky.)

40

Server / Re:Serverhousing v CZ

« kdy: 06. 08. 2016, 14:56:49 »

To by měl také zajímalo. V Master DC Brno je v létě 40C, v Master Praha vypadává elektřina (a ještě dělají z lidí blbce), v Casablance prší (a taky dělá z lidí blbce), v Faster Brno vypadlo napájení při přepojování na solár (protože green je přece důležitější, než dostupnost) a v posledních týdnech mají problém se sítí (v DC asi ne, ale u připojených zakošů na optice po Brně).

Takže, nevím.

41

Software / Re:systemd: FIFO socket jako stdin bez socket activation

« kdy: 27. 07. 2016, 10:57:18 »

Tak zdá se, že problém s právy u Exec* bude vyřešen v systemd 231:

CHANGES WITH 231:

        * In service units the various ExecXYZ= settings have been extended
          with an additional special character as first argument of the
          assigned value: if the character '+' is used the specified command
          line it will be run with full privileges, regardless of User=,
          Group=, CapabilityBoundingSet= and similar options. The effect is
          similar to the existing PermissionsStartOnly= option, but allows
          configuration of this concept for each executed command line
          independently.

42

Software / Re:systemd: FIFO socket jako stdin bez socket activation

« kdy: 26. 07. 2016, 14:47:46 »

Pravděpodobně to nikdo zatím nepožadoval (nic podobného jsem v issue trackeru systemd nenašel). Osobně ani neznám službu, která by se ovládala přes stdin, ale poskytovala další služby někde jinde, takže by měla mít socket a běžet bez socket activation.

Tak nepožadoval. Já to také nepožaduju, jen hledám vhodnější řešení spouštění těchto divných procesů. FIFO na STDIN je přesně to co hledám. Kdyby to systemd neuměl, tak se hold pojede dál postaru. Jsem rád, že to tam je. Jen bych to chtěl bez té aktivační části.

Implementované to evidentně je, funguje to a funguje i složitější část (spouštění service a předávání socketu), tak proč by neměla být přístupná i ta část bez aktivace? Navíc na ten standard input umí napojit i TTY.

Díky za čas, nechám to takto, pokud na něco přijdu, tak sem napíšu řešení.

43

Software / Re:systemd: FIFO socket jako stdin bez socket activation

« kdy: 26. 07. 2016, 14:14:43 »

Fungovat to tak bude, ExecStopPost se spouští, pokud se hlavní proces služby z libovolného důvodu ukončil či pokud se službu nepodařilo spustit. (Ale vyžaduje plnou cestu k tomu, co spustit.)

S tou poznámkou, že ExecStopPost se spouští pod uživatelem User/Group 

Takže uživatel pro danou službu by musel mít právo na systemctl ...

No, asi to nechám tak jak to je. Je to lepší řešení než přes tmux, stejně ta služba bude běžet neustále, takže se socket activation neuplatní. Data se předávají.

Je ale nějaký technický důvod, proč lze fifo socket předat jen v souvislosti se socket activation? Bylo by fajn, kdyby to uměl i pro normální service.

44

Software / Re:systemd: FIFO socket jako stdin bez socket activation

« kdy: 26. 07. 2016, 11:47:29 »

Do služba.socket:

Kód: [Vybrat]

ExecStartPost=/bin/systemctl start služba.service

Nevidím ale moc rozdíl v tom, když se služba spustí, protože na socket přijde stop, a když se spustí hned a nic nedělá, až dostane první zprávu, která je stop.

Možná jsem to nenapsal srozumitelně. Cílem je mít možnost předat procesu zprávy (textové příkazy) na stdin.

Ta služba běží sama o sobě a většinou s ní není potřeba nijak (po stdin) komunikovat. Je aktivní na síti. Ale občas je třeba tomu nějaký příkaz poslat. Umí se ukončit i na příkaz stop (poslaný na stdin). Korektně se ukončí. Tohle všechno funguje.

Funguje i systemctl start sluzba, systemctl stop sluzba, i když je to spuštěné tímto způsobem (což chci), tak funguje propojení fifo socket na stdin - skvělé.

Ten socket na stdin chci zachovat (k vůli tomu to dělám), ale rád bych vypnul socket activation.

Tedy, pokud danou službu zapnu systemctl start sluzba, aby šlo komunikovat pomocí socketu (to teď jde), ale v momentě, kdy se služba ukončí (ať již sama - proces služby se ukončí, nebo systemctl stop sluzba), tak nechci, aby se opět spustila přes socket.

Teoreticky by šlo dát do sluzba.service:

Kód: [Vybrat]

ExecStopPost=systemctl stop sluzba.socket

Otázka: spustí se ExecStopPost i v případě, kdy se proces korektně sám ukončí? Nebo je v případě, kdy je zavoláno systemctl stop?

45

Software / systemd: FIFO socket jako stdin bez socket activation

« kdy: 26. 07. 2016, 09:58:02 »

systemd umí socket activation a umí předat socket jako stdin daného procesu.

sluzba.service:

Kód: [Vybrat]

[Service]
ExecStart=...
StandardInput=socket

sluzba.socket:

Kód: [Vybrat]

[Socket]
ListenFIFO=/path-to-socket

Tohle funguje a lze předávat data danému procesu na stdin přes daný socket.

Lze (a tady začíná můj dotaz) předat socket na stdin BEZ socket activation?

Jedná se mi o to, že existují programy, které se dají řídit jen přes sekvence v terminálu. Dosud se to řeší přes screen / tmux a send-keys funkce těchto terminal multiplexorů. Což se zase dost špatně řídí jako služba (to by ani tak nevadilo), ale hlavně výstup z daného procesu (stdout a stderr) končí v nenávratnu (zatímco při spuštění systemd se výstupy logují).

Výše uvedené řešení funguje, funguje dobře, ale není příliš vtipné, když se do socketu pošle echo "stop" > sluzba.socket, ona se nastartuje (socket activation) a v momentě, kdy si proces přečte stdin, tak se opět ukončí.
 
Je tedy nějaká možnost, jak tomu předat fifo socket jako stdin bez aktivace?