Příspěvky

496

Server / Re:VNC server pre Debian

« kdy: 22. 02. 2022, 23:50:40 »

už som nahodil zálohu a fungujem len neviem ako na VNC server.

Pustíš x11vnc -localhost -forever, ideálně třeba ve startup skriptu desktopového prostředí.

497

Server / Re:Záloha desítek GB u kamaráda

« kdy: 22. 02. 2022, 17:55:20 »

Jen tak v rámci "akademické debaty" - co na serveru zpřístupnit alokovaný soubor nebo rovnou celý oddíl či disk jako iSCSI target a na klientovi připojit (skrz nějaký šifrovaný tunel) jako blokové zařízení, se všemi výhodami i neduhy z toho plynoucími? Nezkoušel někdo nějakou takovou šílenost v praxi? :-)

Vždyť to píšu, já to tak používám. Teda místo iSCSI používám NBD (přes openvpn) nebo sshfs (na kterém je soubor co se připojí přes loopback).

498

Server / Re:VNC server pre Debian

« kdy: 22. 02. 2022, 17:45:15 »

Odinštaloval som x11vnc server, reštartoval PC ale do desktopu sa neviem prihlásiť, po zadaní hesla vytuhne. Terminál a FTP funguje.

Po zadání hesla kde?

499

Server / Re:Záloha desítek GB u kamaráda

« kdy: 22. 02. 2022, 17:43:34 »

Neznate nekdo nejake dobre reseni nejakeho transparentniho sifrovani?

Uděláš si velký prázdný soubor, připojíš ho přes sshfs, naformátuješ jako LUKS oddíl, přimountuješ a zálohuješ do něj rsyncem.

Pokud jsi dobrodruh, můžeš použít NBD, a exportovat LVM LV. Je to trochu rychlejší než sshfs v souboru.

V tom souboru si můžeš udělat btrfs, zapnout kompresi (=rychlejší, úspornější) a dělat snapshoty (=máš i historii).

Jak se pripadne branit pri takove zaloze ransomware?

Nelze.

Nejlepsi by me prisel rsync pres ssh.

Ten není end-to-end šifrovaný.

Ještě můžeš použít encfs v reverzním módu, to pak jde rsyncovat, ale je to ještě dobrodružnější než to NBD.

Proc vymyslite kolo? Kupte si kazdy treba synology

Jednak Synology jsou basliči (např. https://twitter.com/richfelker/status/1357733309737021444) a možná jako nechceš mít další proprietární řešení které se budeš muset učit adminovat, jednak mi není jasné jak „kup si synology“ řeší dotaz na šifrování dat.

nebo pouzivejte uz vytvorene backup systemy typu borg apod.

To vypadá dobře (přečetl jsem si jejich úvodní stránku).

Chystám se něco obdobného taky zprovoznit a chystám se použít toto:

https://duplicity.gitlab.io/duplicity-web/index.html

To mělo problém v tom, že se udělala jedna plná záloha a pak tam byly neustále inkrementy a staré nešly smazat a musela se udělat další plná záloha, což může být při přenosu přes internet obtížné.

500

Server / Re:VNC server pre Debian

« kdy: 22. 02. 2022, 01:25:34 »

narozdil od Jendy pouzivam x11vnc i pro server bez graficke karty, resp. bez pripojeneho LCD

No moment, to jsou dva dost rozdílné případy. Na počítači s grafickou kartou, avšak bez připojeného monitoru, pouštím Xka normálně na té grafické kartě (pomocí autologinu v lightdm). Akorát si pak přidám modeline (cvt -r, xrandr --newmode, xrandr --addmode, xrandr --output HDMI-1 --mode XXX), pokud mi nestačí defaultních 1024x768, do kterých ten integrovaný Intel startuje když nedetekuje monitor s DDC.

Jinak k x11vnc chceš ještě -forever, pokud nechceš aby si systemd myslel že to spadlo a musí to znova nahodit.

501

Server / Re:VNC server pre Debian

« kdy: 21. 02. 2022, 18:36:47 »

Co znamená "s ssh"?

Já používám pro headless (tj. efektivně na počítačích co nemají grafickou kartu) tightvncserver a pro připojení k existující X session (spuštěné na fyzické grafické kartě) x11vnc.

502

Windows a jiné systémy / Re:Posílání paketů na porty: SYN - RST-ACK

« kdy: 21. 02. 2022, 00:52:05 »

To neposílá syn na všechny porty, ale na 9229. To druhé číslo je zdrojový port. Mohlo by to být vidět v netstat -tlpna, když to zkusíš víckrát (ukazuje to jen právě probíhající spojení), a jinak na to lidi myslím používají Little Snitch.

503

Software / Re:Rsync celého disku

« kdy: 19. 02. 2022, 00:42:24 »

Není to žádná chyba, rsync takhle pracuje (a nemůže pracovat jinak).

Pomohlo by, kdyby FS uměl při změně souboru nastavit rekurzivně flag "změněno" (resp. čas změny) nadřazeným adresářům až po /. Pak by rsync nemusel skenovat všechny soubory, ale vyhazoval podstromy, co se nezměnily. Znamenalo by to nějaké zpomalení při zápisu, ale třeba Apple se chlubil, že něco podobného dělá (APFS fast directory sizing).

504

Windows a jiné systémy / Re:Neprístupný adresár na VPN

« kdy: 19. 02. 2022, 00:33:45 »

Jinak moje tipy:

• Vůbec nemáš routu na ten cílový počítač na svém počítači via VPN.
• Mikrotik nepřeposílá provoz do té sítě kde je tplink přes ten tplink (v RouterOS konfiguraci se moc nevyznám, ale v poskytnutém výpise nevidím žádnou specifickou routu).
• tplink neforwarduje provoz do jeho LAN dovnitř
• Mít za VPN stroj s adresou 192.168.0.180 bude problematické, protože rozsah 192.168.0.0/24 používá skoro každý a jakmile do takové sítě přijdeš, tak budeš mít kolizi.
• tplink neposílá odpovědi via mikrotik, případně je nějak blbě znatuje a mikrotik tak neví že to má poslat do VPN tobě.

505

Windows a jiné systémy / Re:Neprístupný adresár na VPN

« kdy: 19. 02. 2022, 00:22:55 »

Nedokážem pingnúť PC kde je zdieľaný adresár.

V tom případě problém vůbec nesouvisí se Sambou a jako první musíš rozchodit toto.

Problém je že neviem pracovať s wireshark

Máš poměrně komplikovaný setup se dvěma/třema routerama a někde po cestě (tam i zpět, takže máš efektivně 4-6 hopů co se musí správně nastavit) je blbě nastavená routa a pakety se ztrácí. Obávám se, že tohle nemáš šanci vyřešit, pokud si sítě nenastuduješ.

Pro sledování propingávání používám typicky tcpdump, návod máš výše -- zkus si třeba "tcpdump -ni eth0 icmp" a v druhém okně "ping root.cz" -- uvidíš pingy a odpovědi. Pak udělej totéž s pingnutím na stroj za VPN -- měl bys vidět jenom výzvy a odpovědi ne, když to nefunguje (pokud nevidíš ani výzvy, máš blbě nastavenou routu už u sebe a musíš to opravit -- dočasně pomocí "ip r a 1.2.3.0/24 via server_ve_vpn", trvale pak přidáním "route 1.2.3.0 255.255.255.0" do konfigu openvpn). Následně se musíš přihlásit na další hop, přes který mají data proudit, a podívat se tam také (stejným tcpdumpem) - pokud má dvě rozhraní (e.g. VPN rozhraní a fyzické rozhraní, protože dělá koncový bod VPN), tak nejdřív na tom prvním a potom na tom druhém. V jednom okamžiku uvidíš, že nechodí ani výzvy, nebo naopak že přišla odpověď, ale neprošla na druhou stranu -- a nebo že přišla odpověď a má blbě nastavenou cílovou adresu, nebo tak něco. No a pak víš kde je problém a musíš vymyslet, jak udělat konfiguraci správně - změnit routing table nebo firewall. Ale tím se velmi posuneme, než "někde v 6 hopech po cestě se to nějak ztratí".

Pokud je navíc po cestě Router"OS", tak ti popřeju hodně štěstí a pevné nervy, protože tam nic jako tcpdump výrobce nedovolí spustit, a musíš si zařídit aby tě ten systém viděl a nastavit si jejich packet sniffer forward a následně to zachytávat lokálně. A nebo to přehrát na openwrt.

506

Hardware / Re:Linux na notebooku s zaheslovaným BIOSem (Lenovo E14)

« kdy: 19. 02. 2022, 00:04:24 »

2. spustit Linux jako aplikaci z Windows, dříve jsem na takové distribuce narážel, třeba by to fungovalo

Musíš buď:

• přinutit ntldr, aby ti zavedl GRUB nebo tak něco. To nějak šlo ve Windows 7 (viz "Wubi ubuntu"), ale teď už to asi nejde. Budeš potřebovat admin oprávnění.
• udělat něco jako kexec. Budeš potřebovat nainstalovat kernelový driver do Windows = admin oprávnění
• dát si do EFI oddílu vlastní binárku a doufat že to nabootuje

Podle mě bude zapnuté TPM, bude šifrovaný disk klíčem z TPM (to jde snadno cracknout, pokud je TPM na desce jako separátní čip a odposlechneš sběrnici; pokud není, tak potřebuješ umět přečíst RAM, což bude trochu hardcore - nevím o žádném opensource HW co by to uměl, a navíc RAM bývá čím dál tím složitěji scramblovaná) a bude zapnutý secure boot, takže máš smůlu. Musíš si počkat na nějaký 0day na Windows a exploitnout to než se to opraví. Slyšel jsem, že jsou Windows docela děravá a záplaty chodí pomalu, takže by to mohlo vyjít.

Btw. při naivně provedeném resetu biosu hrozí, že TPM zapomene klíče.

Osobně bych, pokud by mi firemní IT omezení bránila v produktivitě práce (což případ "nefunguje mi firemní notebook doma" nutně být nemusí; na druhou stranu dělám práci, která skoro nejde dělat na Windows a nedokážu si představit nemít svoji oblíbenou distribuci a roota, takže bych v tomto případě dopadl hodně špatně), pravděpodobně odešel, protože řešit uměle vytvořené problémy nemám zapotřebí.

507

Vývoj / Re:Spinanie relatka z Raspberry Pico

« kdy: 18. 02. 2022, 18:13:16 »

Normálně NPN tranzistorem, ne?

Podle proudu tam asi nebude cívka, kdyby byla, musí se k ní zapojit antiparalelně dioda.

508

Windows a jiné systémy / Re:Neprístupný adresár na VPN

« kdy: 18. 02. 2022, 18:10:13 »

Je potřeba zjistit jestli je stroj dostupný a odpovídá na ping. Dále je potřeba zkusit zda je dostupný samba port (tipuju 139 a 445?), například telnetem. Při uvedeném je vhodné, pokud se zjistí, že ne nefunguje, pustit wireshark nebo tcpdump na obou koncích, případně i po cestě (e.g. "tcpdump -i eth0 icmp" zobrazí jen pingy, takže tam nebude moc bordelu, ve kterém se nedá vyznad). Dále bych doporučil to nejdřív zkusit řádkovým smbclientem (smbclient -L hostname -Uuzivatel -I 192.168.123.123).

509

Vývoj / Re:BASH - komunikace klient-server

« kdy: 16. 02. 2022, 23:39:28 »

Ano, obecně se na to používá expect, ale já se nechci učit další jazyk, takže na to používám Python.

p = subprocess.Popen("./connect.sh", stdin=subprocess.PIPE, stdout=subprocess.PIPE)
p.stdin.write("CONNECT")
ret = p.stdout.readline()
p.stdin.write("SHOW STATUS")
ret = p.stdout.readline()

atd. (psáno po paměti, tak s rezervou)

Možná by se to hodilo dělat asynchronně, tj. čtení v jiném threadu a třeba to cpát do https://docs.python.org/3/library/queue.html.

510

Sítě / Re:(Ne)funkčná VPN

« kdy: 14. 02. 2022, 20:23:43 »

Ako vyriešim 1.)?

Pokud je to na druhé straně povolené (forwarding + NAT), tak jednoduše "ip r a default via router_ve_vpn". Například OpenVPN na to má přímo konfigurační direktivu (redirect-gateway a spol.), nepíšeš jakou VPN jsi použil.

Ta dvojka: no co ti k tomu říct víc než jako obvykle - tcpdump všude po cestě a zjistíš kde se to ztrácí.