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 - martinus26

Stran: [1] 2 3 4
1
Odstránil som {'194.36.144.87', hostname='ns29.de.dns.opennic.glue', ca_file='/etc/ssl/certs/ca-certificates.crt'}

a už 3 dni všetko funguje bez chybovych hlaseni  . ( ziadba tls_cl chyba, ziadny crash knot resolvera,m, ziadny double free)

Tak to vyzera ze to opennic ma nejaky problem s certifikatmi/nastavenim.

Ďakujem za radu.


2
po restart kresd1.service sa prva chyba [tls_cl] objavi po 15 minutach prevadzky.

3
Citace
Zřejmě máte TLS_FORWARD kde nakonfigurované jméno služby neodpovídá jménu certifikátu který ta služba pošle.  Tam aktualizace ca-certificates nemůže pomoct, protože nesedí jméno.  Takže... prostě nastavte správné jméno, za předpokladu že mu stále věříte, apod.

Kde/ako (v ktorom konfigu) mám správne nastaviť to meno ?

Ja mám k /etc/knot-resolver/kresd.conf nasledujuce nastavenie TLS
Kód: [Vybrat]
policy.add(policy.all(policy.TLS_FORWARD({
  {'9.9.9.9', hostname='dns.quad9.net', ca_file='/etc/ssl/certs/ca-certificates.crt'},
  {'149.112.112.112', hostname='dns.quad9.net', ca_file='/etc/ssl/certs/ca-certificates.crt'},
  {'194.36.144.87', hostname='ns29.de.dns.opennic.glue', ca_file='/etc/ssl/certs/ca-certificates.crt'}
})))


Tiez som si všimol ze sa Knot obsac sam od seba restartne, , vypis z /var/log/syslog

Kód: [Vybrat]
Aug  1 09:34:37 rpi400 kresd[2312]: [tls_cl] failed to verify peer certificate: The certificate is NOT trusted. The name in the certificate does not match the expected.
Aug  1 09:37:22 rpi400 kresd[2312]: double free or corruption (!prev)
Aug  1 09:37:23 rpi400 systemd[1]: kresd@1.service: Main process exited, code=dumped, status=6/ABRT
Aug  1 09:37:23 rpi400 systemd[1]: kresd@1.service: Failed with result 'core-dump'.
Aug  1 09:37:23 rpi400 systemd[1]: kresd@1.service: Scheduled restart job, restart counter is at 2.
Aug  1 09:37:23 rpi400 systemd[1]: Stopped Knot Resolver daemon.
Aug  1 09:37:23 rpi400 systemd[1]: Starting Knot Resolver daemon...
Aug  1 09:37:23 rpi400 systemd[1]: Started Knot Resolver daemon.
Aug  1 09:38:20 rpi400 kresd[5900]: [tls_cl] failed to verify peer certificate: The certificate is NOT trusted. The name in the certificate does not match the expected.
Aug  1 09:38:44 rpi400 kresd[5900]: message repeated 3 times: [ [tls_cl] failed to verify peer certificate: The certificate is NOT trusted. The name in the certificate doe


4
System na rpi nebol 2 mesiace aktualizovany.

Ja knot resolver som predtym stahoval z stahujem z repozitaru https://download.opensuse.org/repositories/home:/CZ-NIC:/knot-resolver-latest/xUbuntu_20.04/

Najskor som skusil aktualitovat len knot-resolver a knot-resolver-release a systemctl restartol, ale nepomohlo (ani po rebooote).

Ked som potom aktualizoval cely system, tak dns zacalo fungovat.

V systeme teraz mam 2 baliky knot-resolver (5.5.1-cznic.1)  a knot-resolver-release (1.10-1)

Aky je rozdiel medzi knot-resolver a knot-resolve-release ? 

5
este som si vsimol v szslogu dalsiu chybu

Kód: [Vybrat]
kresd[2371]: [tls_cl] failed to verify peer certificate: The certificate is NOT trusted. The name in the certificate does not match the expected.
skusal som update ca-certifikatov

apt-get update
apt-get install ca-certificates
update-ca-certificates --fresh --verbose
openssl rehash -v
reboot

ale knot stale nefunguje.

6
Server / Knot kresd cannot resolve address 'b root-servers.net'
« kdy: 31. 07. 2022, 12:13:53 »
Mam doma na rpi400 pusteny Knot resolver 1.10 na Ubuntu 20.04. Po polroku bezproblemovej prevadzky sa dnes v noci nieco pokazilo

Na niektore weby sa dostanem, na niektore nie weby sa nedostanem
 Rpi400 slisi ako router/firewall a pakety na  53 a 853 presmerovavam na moj Knot resolver von cez dns over tls.

Systemctl status kresd1.service

Kód: [Vybrat]
kresd[3258]: [primin] cannot resolve address 'b.root-servers.net.', type: 1

kresd[3258]: [primin] cannot resolve address 'b.root-servers.net.', type: 28

kresd[3258]: [primin] cannot resolve address 'c.root-servers.net.', type: 28

kresd[3258]: [primin] cannot resolve address 'e.root-servers.net.', type: 1

kresd[3258]: [primin] cannot resolve address 'f.root-servers.net.', type: 1

kresd[3258]: [primin] cannot resolve address 'g.root-servers.net.', type: 1

kresd[3258]: [primin] cannot resolve address 'g.root-servers.net.', type: 28

kresd[3258]: [primin] cannot resolve address 'h.root-servers.net.', type: 1

kresd[3258]: [primin] cannot resolve address 'l.root-servers.net.', type: 28

kresd[3258]: [primin] cannot resolve address 'm.root-servers.net.', type: 28

Neviem niekto poradit ako to opravit ? Dakujem

7
Sítě / Re:Kde je ajťákův ráj na venkově?
« kdy: 27. 01. 2022, 12:10:09 »
Ako človek ktorý v mladosti zažil presťahovanie z mesta na blízku dedinu mám jednoznačný názor.

Podla mna najlepšia kombinácia je dom (nie byt/panelak) v skutočnom meste (nie satelit). Na lokalite tiež dosť záleží. Veľká záhrada je na prítaž. Civilizácia je super, len je potrebná určitá "nárazníkova zóna"

Ludia čo chcú uniknúť pred mestským smogom bývajú prekvapení dedinským smogom (stači jeden debil na ulici ktorý kúri drevotrieskovým odpadom).

Tiež je dobré zistit v prípade prúseru ako dlho by trval príjazd záchranky a pod ktorú nemocnicu patríte. Je roziel byt 5 km od veľkej univerzitnej než 50 km po cestách 3 triedy do malej/slabo vybavenej.







8
Server / Re:Mail u sebe doma
« kdy: 30. 10. 2021, 14:14:35 »
A nie je celý problém len v tom že mailserver postavený na  Postfix/Dovecot je nevhodný ( hlavne časová námaha na konfiguraciu) ak niekto chce domaci email server pre jedneho použivatela ?

Neexistuje nejakí jednoduchší softvér (hoci aj plateny) na "domace použitie pre jedného použivatela ? "  KISS princíp ?

Vyskúšal som volakedy davno (10rokov dozadu) rozbehnúť Postfix + Dovecot doma.  Na antispam filter som už nemal silu.

9
Odkladiště / Re:Počítač bez integrovaných obvodů
« kdy: 08. 10. 2021, 15:31:45 »
A co tak pouzit diskretne suciastky k stavbe exotickejsieho cpu, napriklad  pracujuceho v trojkovej sustave ?

http://xyzzy.freeshell.org/trinary/CPE%20Report%20-%20Ternary%20Computing%20Testbed%20-%20RC6a.pdf

https://www.computer-museum.ru/english/setun.htm

10
Hardware / Re:Balíčky z Aliexpresu
« kdy: 07. 10. 2021, 17:33:11 »
Pred vyse mesiacom som objednal 3 stuple na sluchatka z pamatovej peny. Z cinskeho skladu, cena 1,72USD. Prislo postou na SLovensko do schranky, nic som nedoplacal. Stitok na obalke bol prelepeny, odosielatel bol CAINIAO Belgicko.

Skor ma serie ze inksquid.com z Anglicka prestal posielat celkom kvalitne neoriginalne naplne do tlaciarne na Slovensko.  Fuck EU.

11
Mám  asi mesiac nové Raspberry PI 400 s  Ubuntu20.04 LTS a LxQt použité ako router/firewall z domacej siete do Internetu po VDSL linke. Predtým som pár rokov mal Rpi 3 bez vážnejších problémov.

Nové Rpi 400 nevydrží ísť viac ako 1 deň bez toho aby vypadlo PPPoE spojenie.

Podla výpisu z /var/log/syslog to vyzerá akoby sa sddm neustále reštartuje ( vyše 26000 krát zua sebou). Naposledy problémy začali krátko po polnoci už restart counter mal hodnotu 13000 a ráno som pozrel vypis var/log/syslog a bolo tam 26 000 reštartov.  Na Rpi je možné sa pripojiť cez ssh, VNC spojenie pomocou softvéru NoMachine nefunguje. K tomu RPi400 nemávam normálne pripojený monitor. Systém beží z USB klúča. Skúsil som obnovit /boot particiu zo zálohy. /root a /home oddiely sú btrfs, spustil som btrfs scrub ale neukázal žiadne chyby.

Po reštarte príkazom reboot systém znovu nabehne a vyzerá byt funkčný.

Minulý víkend som skúsil aj aktualizovať systém, ale bez zmeny k lepšiemu.  Predtým GUI sa zaseklo na čiernej obrazovke po aktivácii Screensaveru, tak som ho vypol.


Našiel som aj nejaké riešenie https://www.reddit.com/r/archlinux/comments/jtb1zb/sddm_failed_to_read_display_number_from_pipe/, ale neviem ho aplikovať na Rpi400.

Ide o pridanie modulu grafickej karty do initramfs
https://wiki.archlinux.org/title/Kernel_mode_setting#Early_KMS_start

Problém je že ja neviem aký modul mám pridat, ked mám Rpi400.


opakujuci sa fragment /var/log/syslog
Kód: [Vybrat]
Jun  5 08:18:43 rpi400 systemd[1]: Starting Simple Desktop Display Manager...
Jun  5 08:18:43 rpi400 systemd[1]: Started Simple Desktop Display Manager.
Jun  5 08:18:43 rpi400 sddm[216939]: Initializing...
Jun  5 08:18:43 rpi400 sddm[216939]: Starting...
Jun  5 08:18:43 rpi400 sddm[216939]: Logind interface found
Jun  5 08:18:43 rpi400 sddm[216939]: Adding new display on vt 1 ...
Jun  5 08:18:43 rpi400 sddm[216939]: Loading theme configuration from ""
Jun  5 08:18:43 rpi400 sddm[216939]: Display server starting...
Jun  5 08:18:43 rpi400 sddm[216939]: Running: /usr/bin/X -nolisten tcp -auth /var/run/sddm/{9cf80e0f-8e2d-422e-ab64-1c49d533c1b1} -background none -noreset -displayfd 17 -s>
Jun  5 08:18:44 rpi400 sddm[216939]: Failed to read display number from pipe
Jun  5 08:18:44 rpi400 sddm[216939]: Display server failed to start. Exiting
Jun  5 08:18:44 rpi400 systemd[1]: sddm.service: Main process exited, code=dumped, status=6/ABRT
Jun  5 08:18:44 rpi400 systemd[1]: sddm.service: Failed with result 'core-dump'.
Jun  5 08:18:45 rpi400 pppd[215153]: Timeout waiting for PADO packets
Jun  5 08:18:45 rpi400 pppd[215153]: Unable to complete PPPoE Discovery
Jun  5 08:18:46 rpi400 systemd[1]: sddm.service: Scheduled restart job, restart counter is at 26342.
Jun  5 08:18:46 rpi400 systemd[1]: Stopped Simple Desktop Display Manager.
Jun  5 08:18:46 rpi400 systemd[1]: Starting Simple Desktop Display Manager...
Jun  5 08:18:46 rpi400 systemd[1]: Started Simple Desktop Display Manager.
Jun  5 08:18:46 rpi400 sddm[216950]: Initializing...
Jun  5 08:18:46 rpi400 sddm[216950]: Starting...
Jun  5 08:18:46 rpi400 sddm[216950]: Logind interface found
Jun  5 08:18:46 rpi400 sddm[216950]: Adding new display on vt 1 ...
Jun  5 08:18:46 rpi400 sddm[216950]: Loading theme configuration from ""
Jun  5 08:18:46 rpi400 sddm[216950]: Display server starting...
Jun  5 08:18:46 rpi400 sddm[216950]: Running: /usr/bin/X -nolisten tcp -auth /var/run/sddm/{e564a676-a8ef-4322-b917-b6c938365325} -background none -noreset -displayfd 17 -s>
Jun  5 08:18:46 rpi400 sddm[216950]: Failed to read display number from pipe
Jun  5 08:18:46 rpi400 sddm[216950]: Display server failed to start. Exiting
Jun  5 08:18:47 rpi400 systemd[1]: sddm.service: Main process exited, code=dumped, status=6/ABRT
Jun  5 08:19:27 rpi400 systemd[1]: sddm.service: Failed with result 'core-dump'.
Jun  5 08:19:27 rpi400 systemd[1]: sddm.service: Scheduled restart job, restart counter is at 26343.
Jun  5 08:19:27 rpi400 systemd[1]: Stopped Simple Desktop Display Manager.
Jun  5 08:19:27 rpi400 systemd[1]: Starting Simple Desktop Display Manager...
Jun  5 08:19:27 rpi400 systemd[1]: Started Simple Desktop Display Manager.
Jun  5 08:19:27 rpi400 sddm[216959]: Initializing...
Jun  5 08:19:27 rpi400 sddm[216959]: Starting...
Jun  5 08:19:27 rpi400 sddm[216959]: Logind interface found
Jun  5 08:19:27 rpi400 sddm[216959]: Adding new display on vt 1 ...
Jun  5 08:19:27 rpi400 sddm[216959]: Loading theme configuration from ""
Jun  5 08:19:27 rpi400 sddm[216959]: Display server starting...
Jun  5 08:19:27 rpi400 sddm[216959]: Running: /usr/bin/X -nolisten tcp -auth /var/run/sddm/{6705749d-a570-45b4-9665-bd4a44693b90} -background none -noreset -displayfd 17 -s>
Jun  5 08:19:27 rpi400 sddm[216959]: Failed to read display number from pipe
Jun  5 08:19:27 rpi400 sddm[216959]: Display server failed to start. Exiting

12
Citace
Ono je těžké říct vyvineme si vlastní procesor, když máme v ruce jeden nebo dva od nějakého překupníka

Vtedi aspon mali motivaciu ten procesor vyvinúť/okopírovať. Ešte ťažšie je vyvinúť vlastný procesor keď najlacnejsí procák stojí menej ako dolár.

Dnes sa v celej východnej Európe úplne vykašlali na vývoj/výrobu vlastných polovodičov (nba slovensku oficiálne asi v roku 2009 keď tu skončil On Semi). 


13
Vyhodil som kluce z /ect/crypttab, vymazal stare efi aj kluce a nanovo prešiel celý návod.

Systém už pri štarte pýta heslo (toto som chcel).

Ešte je tu taká drobnosť. Pri zadávaní hesla nie je možné zapnúť NumLock. Po zapnutí PC keď sa objaví uvodna obrazovka UEFI Biosu, Numlock svieti (nastavené v Biose). Numlock potom zhasne a ked EFI vypyta heslo, nie je možne Numlock zapnúť.

Po zadaní hesla a spustení Linux Mintu už znova je možné zapnúť NumLock.

14
Tak to vyzerá že ten návod na uplne šifrovanie disku sa vyvíja v priebehu času. Aktuálna verzia nepoužíva keyfiles. Ja ale mám keyfiles a aj cestu k nim v mojom /etc/crypttab

Je možné aby efi alebo grub nejakým sposobom precítali a ulozili si niekde tieto keyfiles a potom uz nepotrebovali heslo pocas startu systemu ?

Skúsim odstranit moje keyfiles z mojho crypttabu a znovu spustit update-initramfs, grub-update a znovu vytvorit efi.

/etc/crypttab z navodu pre FDE
Kód: [Vybrat]
sda2_crypt UUID=$(sudo blkid -s UUID -o value /dev/sda2) none luks
moj /etc/crypttab
Kód: [Vybrat]
ssd464crypt /dev/md/ssd464raid1 /etc/keys/crypto_keyfile_ssd464.key  luks
hdd3700crypt /dev/md/hdd3700raid1   /etc/keys/crypto_keyfile_hdd3700.key   luks

15
tu je vis efibootmgr -v
Kód: [Vybrat]
efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0005,0004,0003
Boot0000* Mint HD(1,GPT,400aa5ff-07eb-4571-9403-72fe62026f2b,0x800,0x200000)/File(\EFI\MINT\KERNEL.EFI)
Boot0003  Hard Drive BBS(HD,,0x0)..GO..NO........}.S.a.m.s.u.n.g. .S.S.D. .9.7.0. .P.R.O. .5.1.2.G.B....................A.......................................%8Z.........4..Gd-.;.A..MQ..L.S.4.6.3.N.F.0.K.A.3.4.2.0.4.V........BO..NO........q.S.a.m.s.u.n.g. .S.S.D. .9.7.0. .E.V.O. .5.0.0.G.B....................A...........................%8[..T......4..Gd-.;.A..MQ..L.S.4.6.6.N.X.0.K.B.5.1.5.8.5.E........BO..NO........u.W.D.C. .W.D.4.0.E.F.R.X.-.6.8.N.3.2.N.0....................A.................................>..Gd-.;.A..MQ..L. . . . .W. .-.D.C.W.7.C.3.K.N.H.E.6.U.6........BO..NO........u.G.e.n.e.r.i.c.-.U.S.B.3...0. .C.R.W.-.C.F./.M.D.1...0.0....................A.........................................6..Gd-.;.A..MQ..L.2.0.1.8.0.6.1.5.0.0.0.0.1.0.7.9........BO..NO........z.G.e.n.e.r.i.c.-.U.S.B.3...0. .C.R.W.-.S.M./.x.D.1...0.0....................A..............................................6..Gd-.;.A..MQ..L.2.0.1.8.0.6.1.5.0.0.0.0.1.0.7.9........BO..NO........z.G.e.n.e.r.i.c.-.U.S.B.3...0. .C.R.W.-.S.D. .1...0.0....................A..............................................6..Gd-.;.A..MQ..L.2.0.1.8.0.6.1.5.0.0.0.0.1.0.7.9........BO..NO........z.G.e.n.e.r.i.c.-.U.S.B.3...0. .C.R.W.-.M.S. .1...0.0....................A..............................................6..Gd-.;.A..MQ..L.2.0.1.8.0.6.1.5.0.0.0.0.1.0.7.9........BO..NO........z.G.e.n.e.r.i.c.-.U.S.B.3...0. .C.R.W.-.S.D./.M.S.1...0.0....................A..............................................6..Gd-.;.A..MQ..L.2.0.1.8.0.6.1.5.0.0.0.0.1.0.7.9........BO..NO........u.S.T.4.0.0.0.V.N.0.0.8.-.2.D.R.1.6.6....................A.................................>..Gd-.;.A..MQ..L. . . . . . . . . . . . .D.Z.5.H.D.2.7.3........BO
Boot0004* UEFI OS HD(1,GPT,eebe8210-3b89-4854-aef1-e391b25fd246,0x800,0x200000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0005* UEFI OS HD(1,GPT,400aa5ff-07eb-4571-9403-72fe62026f2b,0x800,0x200000)/File(\EFI\BOOT\BOOTX64.EFI)..BO

TPM nepouživam ani som nič s TPM vedome nerobil. Ako zistit ci sa do TPM nejako nahodne neulozili kluce ?


Stran: [1] 2 3 4