Příspěvky

1

Sítě / Re:Zkušenosti s kabelovým interntem od Vodafone

« kdy: 05. 08. 2025, 12:59:38 »

U me v ramci moznosti dobry mam 1gb/250mb a tu rychlost to dava. Vypadky sem tam vetsinou v radu vterin ale vim o nich jen diky tomu ze mi to unify reportuje.
Jejich Vodafone Station je tragedie ale tunel na tom nastavit jde.
Torenty netaham takze tohle nereknu ale mam verejnou ipv4 (ex zakaznik UPC) a nevnimam zadna omezeni, provozuju na tom nake sluzby na 443, wireguard.. funguje..

2

Software / Re:Headless prohlížeč pro získání HTML

« kdy: 30. 01. 2025, 17:17:25 »

Všechny tyhle headless technologie (selenium,cypress, playwright) používají technologií webdriver nikdy sem na takhle nízké úrovni nepracoval ale vypadá to snadno..

https://developer.chrome.com/docs/chromedriver/get-started

Šel by h touto cestou...

3

Server / Re:Hosting pro Python à la PHP hosting

« kdy: 31. 12. 2024, 11:46:15 »

Tady je problém že na to koukáš hrozně jednostranně myslíš si že problém se dá vyřešit aktualizovaným apachem / nakou proxi.
Typický u těch HTTP requestu to fakt žádný proxi server nevyřeší (jediné bys implementoval naky WAF/IDS ale to hosting za pár korun fakt moc dělat nebude) ten "zlý" request je totiž request jako jakýkoli jiný jen například obsahuje znak přes který verzi X přeteče paměť. Ty tam dáš proxac kde ta paměť nepretece a pošle to dál na tvůj server no a ten udělá co? Přeteče...
Další věc je že nemusí být nutně díra ve webserveru ale v nake sdílené knihovně.. dal i nemusíš útočit na webserver ale až na tvůj Python ( který tranzitivne zase používá sdílenou knihovnu například libressl...) prostě to fakt takto nejde. Mysli na to že z definice je sdílený hosting pro více uživatelů a hosting musí zajistit bezpečí všem... Nemůže to nechat být jen tak. Navíc když už jim naboris server tak ses najednou ve vnitřní sítí a můžeš útočit na další služby..(jasně dá se to řešit ale prostě jedna úroveň obrany padla..)
Takže pokud chceš to co popisujete tak opravdu jen VPS nebo lépe kontejner..

4

Server / Re:Hosting pro Python à la PHP hosting

« kdy: 31. 12. 2024, 08:36:21 »

On ten 1 port často stačí... Vlastně si myslím že se to tak dělá většinou jasně roboti zkouší útoky na SSH ale tam už to dnes zabezpečit není až takový problém (pokud není člověk totální ignorant).
A tím exotickým webservem/ app to je prostě jen security by obscurity dlouhodobě to nefunguje jasně odstrihnes ty nejjednodušší boty ale on si tě časem někdo najde pokud si nenapíšeš úplně vlastní webservem a to neuděláš tak ono těch hotových co se dají v praxi opravdu použít zase tolik není...
Další věc vem si rozvoj AI.. teď útočí jednoduché skripty co zkouší věci z databáze zranitelnosti ale za 15 let? S tím jak brutálně to jde dopředu? Si ani netroufam hádat jaké tipy a druhý útoku budou aktuální jediné čím jsem si jistý že současné postupy stačit nebudou.
A poslední věc je GDPR / NIS2 a podobné... Nevím co máš za app pokud je to tvůj osobní blogisek je to všem sumak ale jestli je to app co řeší osobní údaje (pravděpodobně u každé aspoň trochu užitečné app) nebo se jí týká NIS2 (to asi ne tak velký hádám nejseš) tak máš dokonce povinnost tu app zabezpečit a kdyby ti osobní údaje utekli a někdo se po tobě povozil tak tvůj přístup úřady rozhodně nepotěší a smrdí to flastrem.. ale říkám vždy je to  o rozsahu a analýze rizik. Nicméně ta app prostě za 15 let bezpečná nebude to je fakt. Otázka je jestli to vadí..

5

Odkladiště / Re:Webdesign - funkcia vs forma

« kdy: 26. 11. 2024, 20:25:38 »

Mě přijde ze se to naopak lepší a lepší je možné že se pohybujete v bublině kde stránku navrhuje grafik to je samozřejmě blbě ale kolem mě to je většinou tak že stránku navrhuje UX designer který si nejprve zjistí pro koho stránka je. Co od ní očekává co na ní hledá. Pak ideálně udělá ještě testování na základě toho udělá skici pro grafika kde už je rozvržení všech prvků často i a texty a následně pak grafik udělá svoje..
Samozřejmě všechno je o penězích je jasné že takovýto postup neprodate frantovy od vedle co spravuje škodovky protože to web prodraží. (A není to nutně špatně / problém každej web má svůj rozpočet a svoje zákazniky je potřeba počítat s návratnosti investice...)

6

Server / Re:Docker container / umožnění či autostart ssh

« kdy: 02. 11. 2024, 11:17:49 »

V čem je prosím tě lepší/bezpečnější/sluníčkovější :-), že vytvořím další kontejner, kterej řeší úplně to stejný co potřebuju? U toho stávajícího Seafile kontejneru mi stačí přidat 2 řádky do entrypoint scriptu, přesně toto:

service ssh start
/opt/seafile/seafile-server-latest/seaf-fuse.sh start /mnt

Lepsi je to v tom ze jste takto sahl do zavadece seafile v tuhle chvili vam to treba funguje ale po zmene nemusi. Muze se v tom zavadeci neco zmenit muze se zmenit adresa /opt/seafile/seafile-server-latest/seaf-fuse.sh muze se stat cokoli vy nad tim nemate kontrolu mozna si rikate ze s kazdou novou verzi seafile budete kontrolovat obsah entrypointu ale to delat urcite nebudete.. bud na to zapomenete nebo vas nekdo vystrida.. autor vam dal otestovany funkcni kus kodu a vy jste sahl na jedno z jeho citlivich mist. v tu chvili jste ztratil veskere zaruky... ztratil jste jednu z vyhod proc se kontjenery pouzivaji.
Mozna to bude fungovat mozna ne mozna se to pokazi tak ze na to prijdete v tom lepsim pripade hned a opravite to snadno v horsim az po case a bude to bolet

7

Server / Re:Docker container / umožnění či autostart ssh

« kdy: 02. 11. 2024, 10:37:15 »

Ok takze jak bych to videl ja data mate predpokladam na Volume to proste musite jinak si koledujete o prusvih.
Seafile si na tom volume dela vlastni file system pres mount fuse tzn z venku to vidite jen jako Blob a vy by jste je chtel zalohovat po souborech ok dava smysl.

Tzn udelam novy kontejner do ktereho nainstaluju ten fuse co pouziva seafile. Do tohoto kontejneru namountuji ten samy volume (idealne Read only tim mam zaruceno ze data nepodelam).

Pustim normalne kontejneru seafilu nemusim se mu hrabat v init skriptech.
Vedlejsi kontejner ma namountovana data a bezi tam SSH pro rsync proc ne.
Komplikace bude udrzovat ten fuse modul ve stejne verzi jako ma seafile proto je tu varianta ze bych pustil znovu cely ten image seafilu (ten uz to ma nainstalovane) ale misto seafilu bych v nem pustil jen a pouze to SSHcko to uz umite...

Vyhoda: kdyz budete upgradovat seafile tak proste jen zmenite verzi image, tim ze jste mu nesahal na entrypoint tak docela urcite nabehne. V "backup" kontejneru taky vzdy jen zmenite verzi na tu samou => budete mit garanci ze FUSE je v te same verzi data uvidite bez problemu.
Sahat do entrypointu budete ale nebude to tolik vadit tim ze v tom backup kontejneru pobezite "SVOJE" sluzby tak si za ne zodpovidate sam vite co se tam deje a mate to pod kontrolou nebudete se hadat s vedlejsimi procesy / nebudete se byt se seafilem

Takto nak bych to videl ja kdybych to chtel udelat jednoduse.. za sebe bych si radeji udelal mensi image pro ten backup a ten fuse tam nainstaloval rucne bude s tim vic jebani ale je to cistejsi a image bude vyrazne stihlejsi. (na druhou stranu ten image uz tam stejne mate kuli seafile samotnemu a docker ma deduplikaci celkem dobre zmaklou). Navic je to takto i bezpecnejsi protoze na data budete sahat jen pro cteni a muzete si kontejnery oddelit i na urovni uzivatelu..

8

Server / Re:Docker container / umožnění či autostart ssh

« kdy: 02. 11. 2024, 09:54:11 »

Problem toho pristupu ale vubec neni v bezpecnosti a v tom ze tam pobezi SSH to je prave to co nechapes..
Problem je to ze kdyz sahnes do entrypointu tak uz celkem dost sahas nastaveni kontejneru jako takoveho autor ho ma odladeny otestovany a dela tam spoustu veci kterym ON rozumi a ktere tam musi z nakeho duvodu byt.
Ve chvili kdy ten entrypoint prepises tak menis inicializacy celeho toho udelatoru co tam startuje muze to fungovat / nemusi. To samo o sobe jeste problem neni na to prijdes opravi se to a nak to pobezi ale pak autor vyda novou verzi image kde neco zmeni prida tam nake nastaveni ty to pouzijes a ono to v tom lepsim pripade nenabehne. V tom horsim pripade to nabehne ale vlivem toho ze jsi tomu sahnul do initu se bude dit naka velmi nepekna vec na kterou prijdes treba az za pul roku a udela tvuj den nestastnym..

Pripadne prijde naky kolega ktery ma o chlup vetsi znalosti nez ty a bude cekat ze je to vyresene tak jak je to spravne jak se to delat ma tim ze mu narusis tenhle predpoklad mu taky zpusobis nepekne chvilky.

Nerikam ze to nejde ale prave proto ze se v tom tolik neorientujes bych se tuplem drzel doporuceni. To co chces sice jde parkrat jsem to pouzil ale vzdy jako krajni moznost (a vetsinou se mi to dlouhodobe vymstilo prave na maintanance cost).

9

Server / Re:Docker container / umožnění či autostart ssh

« kdy: 02. 11. 2024, 09:17:38 »

Ono totiz to co chces jednoduse NEJDE takze JEDNODUCHOU odpoved tu proste nedostanes.. nekolikrat jsem ti tu rekl ze aby jsi toho dosahl musis editovat Dockerfile a upravit si entrypoint. Ted bych ocekaval ze se podivas na to jak se edituje Dockerfile co je to vlastne ten entrypoint jak se s nim pracuje.. a budes mit pripadne dalsi otazky. Jestli cekas ze to za tebe cele napisu tak promin mam sve prace dost.

Druha vec je ze to co delas proste neni spravne a driv nebo pozdeji se ti to vymsti. Priznavas ze jsi v tom zacatecnik a chtel bys poradit ale kdyz ti rikame takto to neni dobre tak nam vysvetlujes ze presne takle je to spravne.. ok pak ses v tom ale sam.

10

Server / Re:Docker container / umožnění či autostart ssh

« kdy: 02. 11. 2024, 08:24:03 »

Urcite to realizovat jde i primo u nich na foru jsou na to navody ukazky pokud ty data jsou na disku tak to proste z definice jit musi.

Trochu se desim ze si rozbehavas reseni ala seafile kde bych potencialne chtel mit data o ktere NECHCI prijit a plaves v zakladech.

Ten kontejner se ti otaci protoze kontejner NENI VMka.. tim ze tam das command tak on pusti kontejner a pusti command ten command je "init" podobne jako kdyz poustis distro tak prvni proces je "init" (proces s id 1) a vsechny ostatni procesy jsou jeho potomci. Ve chvili kdy skonci / umre INIT tak konci vsechno.

Tzn pokud sis jako command dal "echo whatever" tak ten echo je "init" a ve chvili kdy skonci tak skonci cely kontejner protoze tam proste nema co bezet. musis si napsat vlastni shell skrtip / nainstalovat tam supervisord (pres Dockerfile)
tohle v docker-compose delat nechces (ne ze by to neslo ale bude to zlo budes se skrabat pres 3 ramena a nemam moc jak ti poradit).

11

Server / Re:Docker container / umožnění či autostart ssh

« kdy: 02. 11. 2024, 07:58:12 »

No dve veci
1) pokud chces menit editovat entrypoint je mnohem lepsi sahnout primo do Dockerfile zmenit to tam a zbuildit si upraveny image..

2) jak uz tu padlo velmi casto je to znamka spatneho navrhu pokud tu resis backup tak od toho tu slouzi spis
Volumes.. namountujes si do kontejneru slozku a backupovat muzes z hosta alternativne pokud to nechces resit na hostu tak muzes ten volume namountovat do druheho kontejneru kde pobezi prave JENOM ssh.  a budes to zalohovat "z boku"

je to mnohem cistejsi reseni. Ale tak nebo tak pristup pres Volume je mnohem cistejsi protoze tim davas na prvni dobrou najevo ktere slozky maji byt persistentni.. oddelis tak bezstavovy kontejner (a ano kontjener CHCES mit bezstavovy) od stavovych dat..

12

Server / Re:Docker container / umožnění či autostart ssh

« kdy: 02. 11. 2024, 04:57:17 »

Problém/vyhoda kontejnerů je že tam by default bezi Jen jeden proces. Takže co potřebuješ je aby ten jeden proces pustil další procesy

Asi nejjednodušší řešení je si do kontejnerů nainstalovat supervisord napsat si entrypoint kterej pustí ten supervisord a přes supervisord už si můžeš pustit kolik dalších věcí potřebuješ (třeba i to ssh) je to jednoduché elegantní...

Trochu nevýhoda je že ten supervisord sám žere asi 30mb RAM což je prd ale když chceš mít úsporné kontejnerů tak se bez něj jde obejít prostě ten ssh sever pustíš v entrypointu ale pustíš ho na pozadí abys pak mohl nahodit další službu. Není tak elegantní protože ten supervisord za tebe dělá i další práci (automaticky restart padnute servisi...)  což si jinak budeš muset v tom entrypointu nak pořešit sám (a nebo se na to vykašlat ono ssh zas tak často nepadne)

13

Hardware / Re:IP kamery bez nutnosti aplikace

« kdy: 27. 10. 2024, 18:02:55 »

Cca mesic zpatky sem si rozbehal synology security station a na jejich NASu (DS920+) celkem spokojenost
plus:
 - rozumne jednoduche
 - vse lokalne
 - funguje v prohlizeci (bez doplnku jen pokud chces h265 tak to myslim neco chtelo tak sem zustal u h264) + apka
minus:
 - cena zalezi jestli ten NAS vyuzijes i na jine veci. Ja si na to beham zalohy. Bezi tam docker takze sem zrusil vsechny raspbery pi a podobne hracky a bezim si na tom veci v kontejneru.
 - plati se tam licence za pocet pripojenych kamer coz je takove... nicmene je to jednorazovy poplatek podle ceny NASu dostanes nake licence zdarma a ta cena neni tragicka (pokud uz mas na to koupis NAS s disky za 20K tak te to nepolozi


 

14

Desktop / Re:Hraní náročnějších her na Linuxu

« kdy: 26. 08. 2024, 05:33:04 »

Já to vyřešil přes GeForce now a hraju v prohlížeči. Pravda povedlo se mi chytnout ještě founders členství teď je to o něco dražší ale pořád když se koukám kolik stojí herní PC a kolik stojí GeForce now tak mi to přijde výhodné. Plus nemusím řešit místo na disku a instalace. Jako jasně na profy hraní CSka to asi není ale byl sem schopný tam odehrát cyberpunk na 12 let starým notebooku s integrovanou grafikou bez nejmenšího problémů. Na ozkoušení mají free plán s hodinovou relaci (ale po skončení můžeš klidně znovu jen té to vykopne) asi si chvíli počkáš na volnej slot ale na ozkoušení dobrý.

15

Odkladiště / Re:Stažení záznamů z obchodního rejstříku

« kdy: 10. 07. 2024, 09:46:17 »

Ta stranka je na strojove zpracovani hell v bashi se utrapis (v jave pres jSoup by to sice slo ale porad to bude fragilni)
Jak uz tu padlo pro male objemy ARES api pokud toho je vic tak stahnout cely dataset a rpacovat lokalne: https://opendata.mfcr.cz/catalog/#/datasets/https:%2F%2Fopendata.mfcr.cz%2Flod%2Fkatalog%2Fares-vystup-pro-vsechna-ico