Příspěvky

31

Software / Re:Šifrování pg_dump pomocí OpenSSL

« kdy: 15. 05. 2024, 14:48:17 »

hm, tohle je dost velká prasárna, nikdy jsem se s tím zatím nesetkal, je ale pravda, že velké archivy s openssl nešifruji snad nikde, všude je gpg či jiný nástroj či formát. Dobré vědět!

Jake jine nastroje krome gpg pouzivas?

Přidej si tam ty checksumy, hned by ti to spadlo na validaci, protože rozbalený šifrovaný archiv by měl jiný checksum než originál. Jak psal Filip, checksum si ukládej vedle do souboru. Vyhneš se všem těmhle hidden truncate problémům nebo třeba OOM chybě při šifrování.

Jak s temi checksumy? Protoze si neumim moc predstavit, jak je pouzit, pokud pouziju roury. Protoze bez vyuziti rour bych nejdrive ulozil na disk komprimovany dump (=X write iops, size Y), pak checksum, pak vytvorit sifrak (+ X read, +X write, +Y size), pak otestovat?? desifrovanim...no vychazi mi z toho mnohem vetsi narocnost na diskovou kapacitu a vykon nez u rour. Asi mi neco uchazi...

Jinak obecne, ma nekdo zkusenosti krome gpg s https://github.com/FiloSottile/age? Vypada to presne na ten jednoduchy use-case, co mam, bez potreby se namahat s keystore apod...Navic to je v debian repozitari a pro starsi servery je k dispozici binarka na githubu...

32

Software / Re:Šifrování pg_dump pomocí OpenSSL

« kdy: 15. 05. 2024, 10:04:29 »

Tak otestovano s pridanym parametrem -stream:

Kód: [Vybrat]

#cat ./db3_15.05.24-00_00.sql.gz | openssl smime -encrypt -aes256 -binary -stream -outform DEM -out ./encrypted.sql.gz.ssl pgdump_backup.pem
-rw-r--r-- 1 root   root     7910422089 May 15 00:28 db3_15.05.24-00_00.sql.gz
-rw-r--r-- 1 root   root     7918147866 May 15 09:36 encrypted.sql.gz.ssl


Kód: [Vybrat]

#openssl smime -decrypt -in ./encrypted.sql.gz.ssl -binary -inform DEM -inkey ./pgdump_backup_key.pem -out ./decrypted.sql.gz
Error reading S/MIME message
4077734DF87F0000:error:038C0100:memory buffer routines:BUF_MEM_grow_clean:malloc failure:../crypto/buffer/buffer.c:128:
4077734DF87F0000:error:068C0100:asn1 encoding routines:asn1_d2i_read_bio:malloc failure:../crypto/asn1/a_d2i_fp.c:209:

#openssl smime -decrypt -in ./encrypted.sql.gz.ssl -binary -stream -inform DEM -inkey ./pgdump_backup_key.pem -out ./decrypted.sql.gz
Error reading S/MIME message
40073BBB2D7F0000:error:038C0100:memory buffer routines:BUF_MEM_grow_clean:malloc failure:../crypto/buffer/buffer.c:128:
40073BBB2D7F0000:error:068C0100:asn1 encoding routines:asn1_d2i_read_bio:malloc failure:../crypto/asn1/a_d2i_fp.c:209:

#free -h
               total        used        free      shared  buff/cache   available
Mem:            47Gi        13Gi       3.2Gi        11Gi        42Gi        33Gi
Swap:          2.7Gi       1.3Gi       1.4Gi

To je sranda. Tak zpatky na zacatek nekam do praveku...

33

Software / Re:Šifrování pg_dump pomocí OpenSSL

« kdy: 15. 05. 2024, 09:07:06 »

Presne podle ocekavani, nejdrive se spustil pg_dump, vystup je  .sql.gz, pak se spustil druhy pg_dump, ale vystup sql.gz se rovnou zasifroval:

Kód: [Vybrat]

-rw-r--r-- 1 postgres postgres 2035990520 May 15 00:04 db2_15.05.24-00_00.sql.gz
-rw-r--r-- 1 postgres postgres 2004624114 May 15 00:33 db2_15.05.24-00_00.sql.gz.ssl
-rw-r--r-- 1 postgres postgres 7910422089 May 15 00:28 db3_15.05.24-00_00.sql.gz
-rw-r--r-- 1 postgres postgres 2004624114 May 15 00:58 db3_15.05.24-00_00.sql.gz.ssl


Zkusim kouknout na ty parametry, co poslal NCC1701E. Kazdopadne pokud to tak je, tak je to prasarna od openssl.

34

Software / Re:Šifrování pg_dump pomocí OpenSSL

« kdy: 14. 05. 2024, 12:41:24 »

Ano, uvedene velikosti se tykaji nesifrovaneho i sifrovaneho pg_dump po komprimaci ukladane na ext4.

35

Software / Šifrování pg_dump pomocí OpenSSL

« kdy: 14. 05. 2024, 11:12:43 »

Ahoj,

testuji podle tohoto postupu https://www.imagescape.com/blog/encrypted-postgres-backups/ a na posledni chvili jsem si vsiml:

Kód: [Vybrat]

-rw-r--r-- 1 postgres postgres 1.5M May 14 00:00 db1_14.05.24-00_00.sql.gz.ssl
-rw-r--r-- 1 postgres postgres 3.4K May 14 00:29 globals_only.gz.ssl
-rw-r--r-- 1 postgres postgres 1.9G May 14 00:04 db2_14.05.24-00_00.sql.gz.ssl <---
-rw-r--r-- 1 postgres postgres 1.9G May 14 00:29 db3_14.05.24-00_00.sql.gz.ssl <---
-rw-r--r-- 1 postgres postgres  19M May 14 00:29 db4_14.05.24-00_00.sql.gz.ssl
-rw-r--r-- 1 postgres postgres 1.4K May 14 00:29 postgres_14.05.24-00_00.sql.gz.ssl
-rw-r--r-- 1 root     root       88 May 14 00:00 postgres_db_list_grep.txt
-rw-r--r-- 1 postgres postgres  772 May 14 00:00 template0_14.05.24-00_00.sql.gz.ssl
-rw-r--r-- 1 postgres postgres 1.4K May 14 00:00 template1_14.05.24-00_00.sql.gz.ssl
-rw-r--r-- 1 postgres postgres 154M May 14 00:29 db5_14.05.24-00_00.sql.gz.ssl


Prikaz dle toho webu je pouzit:

Kód: [Vybrat]

/usr/bin/pg_dump --create --exclude-schema=XX --exclude-schema=XY $line | gzip -c | openssl smime -encrypt -aes256 -binary -outform DEM -out $PDIR/'$line'_'$OFP'.gz.ssl /SOMEPATH/local_backup/pgdump_backup.pem

Nesifrovana db2 ma 1.8 GB, nesifrovana db3 ma 7.34 GB. Obe sifrovane maji 1.9 GB. Proc? Na info omezeni velikost ciloveho souboru jsem nenarazil.

Pripadne nejaky jiny tip, jakym postupem sifrovat dumpy?

Diky.

36

Server / Re:ISC DHCP nepřiděluje adresy Androidu

« kdy: 30. 04. 2024, 11:50:13 »

Kea, taktez od ISC. Akorat ta konfigurace v json mi nevoni no...

37

Hardware / Re:Výběr disků do serveru Dell

« kdy: 02. 04. 2024, 13:31:33 »

Take bych asi doporucil spise SATA disky, osvedcily se mi WD Ultrastar nebo Gold a rozhodne, jak uz zaznelo od Brumly, nakoupit od různych dodavatelu, aby pokud mozno nebyly ze stejnych serii. Pokud se nemylim, ma R410 "jen" 4 sachty, volil bych tedy pro jistotu osazeni vsech pozic a RAID 5 s redundanci. Data jsou nejcennejsi. Osvedcilo se mi nahradit optickou mechaniku adapterem na dva 2.5 disky a dat Proxmox na SSD (a kdyz by to slo tak i virtual), idealne na solidni Kingston 480M (a kdyz uz tak uz rovnou na dva v RAID1). Na rotacni disky pak jen data.

Solidní Kingston 480M? Co je na něm solidního? Předpokládám, že myslíš A400 480GB (nic jako 400M neexistuje), který má 160 TBW, což na OS disk pro proxmox je poměrně málo a za rok ti může odejít.

Asi myslel Kingston DC500M 480GB. My je taky pouzivame na PVE OS.

38

Server / Re:HTTPS certifikát v lokální síti

« kdy: 02. 04. 2024, 10:54:58 »

Jaká je tedy momentálně best practice? Mám Home Assistent běžící v docker kontejneru na Turrisu a chtěl bych ho přepnout na https. Vytvořit si vlastní CA bych zvládl, na Linuxu si ji přidám. Ale když mám několik uživatelů s Androidem, tak musím také obíhat jejich telefony a nějak jim tam přidávat svoji CA? Nebo existuje nějaké víc user-friendly řešení?

Bez centralizovane administrace zarizeni nelze pouzit jiny postup, nez provest akci rucne.
Nebo si proste poridit verejnou domenu.

39

Sítě / Re:Proxmox server, dvě sítové karty a Docker

« kdy: 14. 03. 2024, 09:39:11 »

A proc nekoupit nejaky vhodny levny mikrotik/wifi ap, ktere z toho udela pripojeni pres kabel?

40

Sítě / Re:Proxmox server, dvě sítové karty a Docker

« kdy: 11. 03. 2024, 11:24:45 »

Docker na hypervizor nepatri. Ten patri do VM.

41

Sítě / Re:Wireguard po IPv6 na Mikrotiku

« kdy: 21. 02. 2024, 09:59:35 »

Bohužel návody často IPv6 úplně ignorují.

Ipv6 se nastavuje uplne stejne, jako ipv4. Akorat pri pouziti GUA lze vyhodit veskere NAT apod. blbiny. Tak sem dej wg, fw, route table konfigurace (vse staci pro ipv6) a my se na to muzeme podivat.

42

Hardware / Re:Server backplane, expander vs řadič

« kdy: 16. 02. 2024, 11:12:19 »

Nevim jak u dellu, ale u hp to bylo multiplexovano (tedy expander). Kdyz jsme nasazovali ceph v konfiguraci, kdy jsme chteli pouzit hw raid pro OS, hba kartu pro ceph, tak ten multiplex byl problem.

Primou zkusenost s hba a multiplexem nemam, ale myslim, ze to fungovat bude, jen bude potreba nejaka konfigurace na strane OS, aby vedel, ze je v multipathu.

U 16 port karty zalezi na poctu fyzickych portu (2/4) a dostupne kabelaze.

43

Windows a jiné systémy / Re:Který způsob vzdálené plochy pro Windows

« kdy: 05. 02. 2024, 11:53:55 »

Kolega ted resil neco na spravu a ukazal mi Windows Admin Center, tak mozna by to bylo taky vyuzitelne.

44

Server / Re:Tip na monitoring kontejnerových služeb

« kdy: 31. 01. 2024, 11:06:54 »

Pokud máš ansible a repositář, nemůžeš tu konfiguraci strčit do repa a přes CI nasazovat ansiblem? O jakou vlastně konfigurace jde? Netdata se normálně běžně vůbec nekonfiguruje, sama si čte, vše na co má přístup a nerozumím tomu, proč by vývojáři měli její konfiguraci měnit.

CI jsem ja  nemame Tower, takze se vse spousti manualne. No jde o to, ze chteji videt metriky z redisu, vzhledem k tomu, ze kazdy kontejnerovy redis bude mit jiny port/login/pass, tak se to do konfigurace musi zadat.

45

Server / Re:Tip na monitoring kontejnerových služeb

« kdy: 30. 01. 2024, 16:57:22 »

Co je rootless docker.socket? Podman? Jinak docker vyžaduje kvůli tomu jak funguje root práva.

No to je docker nainstalovany pod obycejnym uzivatelem, ve stylu "dockerd-rootless-setuptool.sh" + "systemctl --user start docker".

Připrav konfigurační soubor (v jakémkoliv formátu), který budou moci uživatelé zapisovat, ten budeš sledovat (či pravidelně zpracovávat) a z něho vytvoříš výslednou konfiguraci pro netdatatu, pokud se něco změní, uděláš restart. Nebo můžeš udělat sudo script, který po spuštění otevře v EDITOR tmp kopii části konfigurace, počkáš na ukončení editoru, zkontrluješ jestli se něco změnilo a případně aktualizuješ netdatu a uděláš její restart (ala jak funguje visudo nebo crontab -e). Zásadně uživatelé nepouštím na vyšší práva.

Takhle nejak jsem uvazoval v prvni fazi. Jen mi tam nevonel pristup ke konfiguraci neceho, co se konfiguruje pres ansible (a k nemu vyvojari pristup nemaji, navic bez Toweru), takze trochu kolizni stav plus nutnost restartovat. To mi ciste neprijde uz vubec :-)

No nic, prinejhorsim skoncime bez real-time.