gewoon maar afwachten? Debian sid, 64-bit time_t transition
Goedenmorgen, Wat is julie advies aangaande de tientallen updates die staan te wachten op verdere afwikkeling van de time_t overstap? Dit is in Debian Sid. Gewoon maar wachten tot het allemaal klaar is, vermoed ik? Voorbeeldje: laatst ik dacht atop te installeren, maar dat zou heel veel andere applicaties verwijderen. Of de emergency update voor Emacs? Grt! G
Re: Booten vanaf USB steeds trager
Ik lees Geert zijn reactie en dacht toen aan hoe ik zelf eerder mijn kernels moest verkleinen? dat was met modules=dep in /etc/initramfs-tools/conf.d/module
Opgelost (maar heel anders) Re: sshd Match regel
hallo Het ging om een versie van Curl .. dan sftp://file-server wilde doen met alleen rsa/dsa. De SSH op dezelfde host ondersteunen ecdsa en zo gewoon. Allebei MotioneyeOS, voor het laatst opgewaardeed in 2020. Ik zag geen manier om Curl te vertellen ecdsa te doen. Dus ... Ik heb het transport omgedraaid.. ik haal nu de files op vanaf de file server, dat kan met een cron job.
Re: sshd Match regel
On 19 February 2024 18:26 Rik Theys, wrote: > Beste, > > On Mon, Feb 19, 2024 at 5:53 PM Gijs Hillenius wrote: > >> >> >> Iets als, onderaan sshd_config dit: >> >> , >> | Match User webcams >> | PubkeyAcceptedKeyTypes ssh-rsa,ssh-dss >> ` >> >> ssh lijkt dat te willen snappen. Desondanks verschijnt dezelfde >> foutmelding in auth.log. De clients bevestigen: "unable to exchange >> encryption keys." >> >> Als ik op de server doe: >> >> ssh localhost -Q HostKeyAlgorithms >> >> >> daar zie ik toch ssh-dss en ssh-rsa staan. >> >> Maar ... niet de "oude"? >> >> Wie heeft een tip >> >> > De -Q optie geeft een lijst van ondersteunde algorithms, daarom niet > degene die actief zijn? Ik zou eens proberen met een Match op het IP > adres ipv de gebruikersnaam. Mogelijk is de uitwisseling van de > gebruikersnaam pas na het tot stand komen van de encryptie? Ow! dank voor het meedenken, dat helpt. Idd, ik zie in de ssh logs niet die username. Maar , | Match Address 192.168.123.42 | PubkeyAcceptedKeyTypes ssh-rsa,ssh-dss ` geeft helaas dezelfde melding in de log.
sshd Match regel
Hoi Ik heb sinds een inbraak in 2019 enige simpele (zelfgebouwde) embedded webcameraatjes draaien. Put, koe, inderdaad. Maar dat terzijde. Nou blijken die cameraatjes sinds enige tijd alweer hun filmpjes niet te kopieren naar de file server op zolder. Op die server Debian stable, draait openssh 1:9.2p1-2+deb12u2, en de logs laten zien: no matching host key type found. Their offer: ssh-rsa,ssh-dss [preauth] ssh dus te oud, op die webcammetjes. Updaten van die cammetjes dat blijkt een heel gedoe.. en... nou leek het me voor de korte termijn een oplossing om op de ssh server voor de webcammetjes een uitzondering te maken. Iets als, onderaan sshd_config dit: , | Match User webcams | PubkeyAcceptedKeyTypes ssh-rsa,ssh-dss ` ssh lijkt dat te willen snappen. Desondanks verschijnt dezelfde foutmelding in auth.log. De clients bevestigen: "unable to exchange encryption keys." Als ik op de server doe: ssh localhost -Q HostKeyAlgorithms ssh-ed25519 ssh-ed25519-cert-...@openssh.com sk-ssh-ed25...@openssh.com sk-ssh-ed25519-cert-...@openssh.com ecdsa-sha2-nistp256 ecdsa-sha2-nistp256-cert-...@openssh.com ecdsa-sha2-nistp384 ecdsa-sha2-nistp384-cert-...@openssh.com ecdsa-sha2-nistp521 ecdsa-sha2-nistp521-cert-...@openssh.com sk-ecdsa-sha2-nistp...@openssh.com sk-ecdsa-sha2-nistp256-cert-...@openssh.com webauthn-sk-ecdsa-sha2-nistp...@openssh.com ssh-dss ssh-dss-cert-...@openssh.com ssh-rsa ssh-rsa-cert-...@openssh.com rsa-sha2-256 rsa-sha2-256-cert-...@openssh.com rsa-sha2-512 rsa-sha2-512-cert-...@openssh.com ssh localhost -Q sig ssh-ed25519 sk-ssh-ed25...@openssh.com ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 sk-ecdsa-sha2-nistp...@openssh.com webauthn-sk-ecdsa-sha2-nistp...@openssh.com ssh-dss ssh-rsa rsa-sha2-256 rsa-sha2-512 daar zie ik toch ssh-dss en ssh-rsa staan. Maar ... niet de "oude"? Wie heeft een tip Dank G
Re: Fail2ban, grote logfiles
On 10 January 2024 09:06 Paul van der Vlis, wrote:
> Hoi,
>
> Sinds kort heb ik er last van dat fail2ban erg grote logfiles heeft,
> nu is hij bijvoorbeeld alweer 5,9GB. Volgens mij gaat het om SSH
> aanvallen. Ik heb maar weinig machines waar SSH openstaat voor de
> wereld, daarom kan ik niet goed vergelijken. Mijn pogingen om de logs
> minder verbose te maken hielpen niet, er is iets anders aan de hand
> denk ik.
>
> Dit soort dingen staan er in:
> -
> 2024-01-10 08:58:03,574 fail2ban.filter [790516]: HEAVY
> Looking for failregex 20 - '^(?P(?PAccepted
> \\w+)) for (?P\\S+) from
> (?:\\[?(?:(?:::f{4,6}:)?(?P(?:\\d{1,3}\\.){3}\\d{1,3})|(?P(?:[0-9a-fA-F]{1,4}::?|::){1,7}(?:[0-9a-fA-F]{1,4}|(?<=:):)))\\]?|(?P[\\w\\-.^_]*\\w))(?:\\s|$)'
>
>
> Zegt jullie dit misschien iets?
Dag Paul!
Ik zie deze ^^^ meldingen niet in mijn logs. Maar dat zegt weinig.
bij mij is het loglevel = INFO
Wat ik niet goed begrijp uit je post: is de maat van de log file een
probleem? Lost logrotate dat niet op?
Mijn servertje had lang geleden moeitje met de groeiende maat van de
Sqlite3 file, die werd te zwaar voor het geheugen van de host. Ik heb
(toen) in fail2ban.conf de purge op 24 uur aangezet, dat houdt het
beperkt: dbpurgeage = 86400
du -h /var/lib/fail2ban/fail2ban.sqlite3 -> 187M
Re: wegvallen / uitvallen van IPv6
On 29 December 2023 22:02 Richard Lucassen, wrote: > On Fri, 29 Dec 2023 10:57:54 +0100 > Geert Stappers wrote: > >> > Misschien dat je router advertisements op 546/udp niet accepteert? >> > >> > iptables -A INPUT -s fe80::/10 -p udp --dport 546 -j ACCEPT >> > >> > Ik roep maar wat hoor. >> >> Die aanvulling zou aanleiding moeten zijn >> om het bericht (met kletskoek) niet te versturen. > > Lees het eens anders: > > dat je router advertisements op 546/udp niet accepteert? > > "je" is het onderwerp, "je router" is dat niet. 't Is wat onduidelijk > inderdaad. Wellicht was diet beter geweest: > > dat je router-advertisements op 546/udp niet accepteert? > > Als je Linuxdoos achter een router die SLAAC doet die pakketten > weggooit krijg je dit soort problemen. Oh, dank! Dat is een richting waar ik naar ga kijken. Het is een mesh wifi netwerk, een maand terug hier neergezet door Proximus. Twee repeaters verbonden met een internetbox die met een ethernet kabel verbonden is met een router, die aan de fiber hangt. En in sommige hoeken valt IPv6 om. (Zal je net zien: het is nu alweer een paar dagen niet voorgekomen. Ik had het eerder op deze lijst moeten melden :-) ) Dank!
Re: is dit goed ? nameserver met netwerk device eraanvast?
[snip alles] Dank Wilfried en Geert! Ik zal avahi uitzetten, en zien wat dat doet. Echter, ik vermoed dat ik (hier) op een dood spoor rijd. Wat ik eigenlijk wil oplossen is het geregeld wegvallen / uitvallen van IPv6. Het eerste wat ik zag in logs is die avahi melding.. Grt Gijs -- Take your dying with some seriousness, however. Laughing on the way to your execution is not generally understood by less advanced life forms, and they'll call you crazy. -- "Messiah's Handbook: Reminders for the Advanced Soul"
Re: is dit goed ? nameserver met netwerk device eraanvast?
On 28 December 2023 14:43 Winfried Tilanus, wrote: > On 28-12-2023 13:49, Gijs Hillenius wrote: > > Hoi, > > Debian testing laptop. Resolv.conf is managed by Network manager. Daar > heb ik niet zo een regel. man resolv.conf geeft ook niet aan dat dit > een optie is. Dus ik denk een configuratie misser. > > groet, > > Winfried > >> Hallo! >> Mijn Debian unstable workstation (een laptop) toon in >> /etc/resolv.conf deze gekke regel >> nameserver fe80::b25b:99ff:fea9:a10%wlp0s20f3 >> Met in syslog : avahi-daemon[107712]: Failed to parse address >> 'fe80::b25b:99ff:fea9:a12%wlp0s20f3', ignoring. >> die wlp0dinges dat is het netwerk device >> wlp0s20f3: flags=4163 mtu 1500 >> inet 192.168.129.6 netmask 255.255.254.0 broadcast 192.168.129.255 >> inet6 fe80::b721:ca42:fdde:7c30 prefixlen 64 scopeid 0x20 >> inet6 2a02:a03f:6b1e:ff01:836e:4236:5dbf:1ba6 prefixlen 64 >> scopeid 0x0 >> ether 94:e6:f7:67:05:9d txqueuelen 1000 (Ethernet) >> RX packets 1716685 bytes 2026968353 (1.8 GiB) >> RX errors 0 dropped 298 overruns 0 frame 0 >> TX packets 349178 bytes 106812929 (101.8 MiB) >> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >> Is dat een configuratie misser? Of heeft iedereen dit? >> Dank Het lijkt op een misverstand in network-manager, IPv6 link-local en DNS. Ik zal eens testen of hiermee: [main] dns=none in /etc/NetworkManager/NetworkManager.conf dat euvel oplost. Als het al een euvel is, eigenlijk.
is dit goed ? nameserver met netwerk device eraanvast?
Hallo! Mijn Debian unstable workstation (een laptop) toon in /etc/resolv.conf deze gekke regel nameserver fe80::b25b:99ff:fea9:a10%wlp0s20f3 Met in syslog : avahi-daemon[107712]: Failed to parse address 'fe80::b25b:99ff:fea9:a12%wlp0s20f3', ignoring. die wlp0dinges dat is het netwerk device wlp0s20f3: flags=4163 mtu 1500 inet 192.168.129.6 netmask 255.255.254.0 broadcast 192.168.129.255 inet6 fe80::b721:ca42:fdde:7c30 prefixlen 64 scopeid 0x20 inet6 2a02:a03f:6b1e:ff01:836e:4236:5dbf:1ba6 prefixlen 64 scopeid 0x0 ether 94:e6:f7:67:05:9d txqueuelen 1000 (Ethernet) RX packets 1716685 bytes 2026968353 (1.8 GiB) RX errors 0 dropped 298 overruns 0 frame 0 TX packets 349178 bytes 106812929 (101.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Is dat een configuratie misser? Of heeft iedereen dit? Dank Gijs -- History repeats itself. That's one thing wrong with history.
Re: muis /sys/devices/platform/i8042/serio1/ "speed" ontbreekt
On 31 August 2023 10:19 Paul van der Vlis, wrote: > Op 31-08-2023 om 09:53 schreef Gijs Hillenius: >> [...] >> >>> >>> Standaard staat hij tegenwoordig wel erg langzaam inderdaad. >> xinput --set-prop "TPPS/2 Elan TrackPoint" "libinput Accel Speed" 1 >> Als het een Elan Trackpoint is dan is - volgens mij - op dit moment >> het >> enige wat ik kan instellen. In Gnome toont ie dan in de settings: >> "fast". > > Dit blijkt een ALPS trackpoint te zijn, dus inderdaad een andere. Exact! dat is de andere. Die is echt supersnel/soepel. > Overigens had ik eerder gezegd dat ik testte met een Thinkpad T480s, > dat was een vergissing, het is een T490. Wat voor machine gebruik jij? Een X1 Carbon uit 2020 (7th Gen).
Re: muis /sys/devices/platform/i8042/serio1/ "speed" ontbreekt
[...] > > Standaard staat hij tegenwoordig wel erg langzaam inderdaad. xinput --set-prop "TPPS/2 Elan TrackPoint" "libinput Accel Speed" 1 Als het een Elan Trackpoint is dan is - volgens mij - op dit moment het enige wat ik kan instellen. In Gnome toont ie dan in de settings: "fast". Het mag echt nog wel sneller, om een kromme muisvinger te voorkomen, maar affijn. Er zijn belangrijker dingen Mocht je het willen weten: Ik heb met deze trackpad ook af en toe last van een wegdrijvende muis-aanwijzer (Lenovo erkent dat dit gebeurt... er zijn wel eens bugfixes voor die "Fixed long drift issue of ELAN TrackPoint". Dat is dat de muispointer helemaal vanzelf en zeer halstarrig naar links (of rechts) schuift. Moet je ff wachten tot het stopt, of naar een andere desktop springen. Mijn backup-laptop, vorige generatie uit dezelfde serie, heeft een andere Trackpoint. Die is zo snel .. -- It is better to have loved and lost -- much better.
muis /sys/devices/platform/i8042/serio1/ "speed" ontbreekt
Goedenmorgen! Ik probeer mijn Thinkpad trackpoint te versnellen. Dat ging vroeger met iets als: echo 255 > /sys/devices/platform/i8042/serio1/speed en ook echo 200 > /sys/devices/platform/i8042/serio1/sensitivity maar "speed" bestaat niet (meer). sensitivy verhogen, dat helpt al iets maar wat mij betreft mag het nog sneller. Ik doe nu: xinput --set-prop "TPPS/2 Elan TrackPoint" "libinput Accel Speed" 1 maar da's echt nog niet genoeg. Iemand een idee? Ik heb Duckduckgo en Google gebruikt, maar .. dat levert vooral verouderde informatie. Dank G
Re: proposed updates
On 4 August 2023 15:03 Paul van der Vlis, wrote: > Hoi Gijs, > > Op 04-08-2023 om 10:34 schreef Gijs Hillenius: >> De handleiding: >> https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.en.html#proposed-updates >> 4.2.9. The proposed-updates section >> If you have listed the proposed-updates section in your APT >> source-list >> files, you should remove it before attempting to upgrade your system. >> This is a precaution to reduce the likelihood of conflicts. > > Nu heb je het over proposed-updates, en niet over release-updates. > "Proposed" betekent "voorgesteld", proposed-updates is bedoeld om de > updates te testen voordat ze gereleased worden. Right. Dank. hier https://wiki.debian.org/StableUpdates staat: "All packages from stable-updates will be included in point releases." en "This path will be used for updates which many users may wish to install on their systems before the next point release is made, such as updates to virus scanners and timezone data." Dat klinkt niet alsof dit gaat om "cyrus-imap met een majeure update". -- He who loses, wins the race, And parallel lines meet in space. -- John Boyd, "Last Starship from Earth"
proposed updates (was: Debian Bookworm en Cyrus? Stap nog ff niet over)
De handleiding: https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.en.html#proposed-updates 4.2.9. The proposed-updates section If you have listed the proposed-updates section in your APT source-list files, you should remove it before attempting to upgrade your system. This is a precaution to reduce the likelihood of conflicts. -- In the stairway of life, you'd best take the elevator.
Re: Debian Bookworm en Cyrus? Stap nog ff niet over
On 3 August 2023 23:43 Paul van der Vlis, wrote: > Hoi Gijs, > > Op 29-07-2023 om 08:36 schreef Gijs Hillenius: >> On 28 July 2023 19:10 Wouter Verhelst, wrote: >> >>> On Wed, Jul 19, 2023 at 01:10:04PM +0200, Gijs Hillenius wrote: >>>> On 19 July 2023 09:20 Paul van der Vlis, wrote: >>>> >>>> >>>> [...] >>>> >>>>> Het officiele relocate script zit ook in Debian, als ik het goed >>>>> begrijp: /usr/lib/cyrus/bin/relocate_by_id >>>> >>>> Yep. Maar dat werkt niet (meer) op de nieuwe lege inboxen. >>>> >>>>> Manual: >>>>> https://www.cyrusimap.org/imap/reference/manpages/systemcommands/relocate_by_id.html >>>>> >>>>> Dit is ook interessant: >>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007965 >>>>> https://cyrus.topicbox.com/groups/info/T3e85440ddbb44ec6-Maf769decd0dd45d4572145b8 >>>> >>>> Volgens een van de Debian packagers: (in de bug report >>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037346) "the patch >>>> needed to update to 3.6 is included in version 3.2.6-2+deb11u2." >>>> >>>> Ik heb die aanwijzing nog niet teruggevonden; al is het voor mij mosterd >>>> na het zinken van het schip. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037346#55 > >>> https://packages.debian.org/bullseye/cyrus-imapd >>> >>> Basically: je moet er eerst voor zorgen dat je bullseye-installatie >>> helemaal up to date is. Zoals altijd. >> Yep. Dat was geheel het geval; netjes de handleiding gevolgd. FWIW, >> op >> de cyrus mailinglist kwamen er 1 of 2 andere Debian cyrus admins voorbij >> die hun systeem zagen uitgleiden. Dat script uit de bugmelding lost het >> weer op, maar het is geen doen voor systemen met veel gebruikers. > Ik ben het nog aan het bestuderen, ik wil niet dat het bij mij ook > misgaat ;-) > > Zou het kunnen dat de regel met "bullseye-updates" bij jou mistte in > /etc/apt/sources.list van Debian 11? Die cyrus-imapd update met patch > was namelijk geen security update, maar een minor-update in Debian > 11.4: > https://www.debian.org/News/2022/20220709 Ik volg tamelijke nauwgezet alle updates, en point releasese, en bij mij draaide Cyrus 3.2.6-2+deb11u2. "grep cyrus upgrade-bookwormstep.script" geeft onder meer: "Unpacking cyrus-imapd (3.6.1-4) over (3.2.6-2+deb11u2)" en daarin zit de patch: ,[ changelog ] | cyrus-imapd (3.2.6-2+deb11u2) bullseye; urgency=medium | | * Ensure that ctl_cyrusdb -r and reconstruct now ensure the "uniqueid" field | is present in and synchronised between mailboxes.db and cyrus.header. | Required before 3.6.x upgrade ` Maar volgens Ellie's antwoord gisteren was dat onvoldoende. Ze noemt onder meer: relocate_by_id .. Wellicht is er een alternatieve route via snapshot? http://snapshot.debian.org/binary/cyrus-imapd/ > Moraal van het verhaal: vergeet niet die "*-updates" in sources.list. > Naast security updates zijn er soms ook nog andere updates! > > Ik vraag me af waarom dit een aparte regel is eigenlijk, waarom die > updates niet gewoon in de Debian-versie komen bij een minor update. StableUpdates: official Debian repository for changes that cannot wait for the next point release, packages are also added to StableProposedUpdates for inclusion in the next point release Ik bestudeer nu apt/sources.list en ik zie dat die regel er wel staat voor Debian 8, 9, en 10, maar niet voor 11 (omgebouwd voor) 12 (verdikkeme). Maar het is dus niet perse nodig? Graag advies! >> Omzichtig: de (zeer-gewaardeerde) packagers gebruiken kennelijk zelf >> geen cyrus (meer), en gingen lijkt het af op de aanwijzing van upstream. >> Ik vermoed dat er een stap mist - relocate_by_id of zo.. Het kan ook >> zijn dat "autocreate" verboden had moeten zijn. > Het is sowieso een moeilijke update als ik het zo lees, er kan meer > misgaan: https://www.cyrusimap.org/3.6/imap/download/upgrade.html > > De link is van de officiele documentatie, eigenlijk is de Debian > documentatie leading. Is de Debian documentatie van een pakket > eigenlijk al ergens te lezen voor je dat pakket installeert? je kan de deb downloaden en uitpakken..
Re: Debian Bookworm en Cyrus? Stap nog ff niet over
On 28 July 2023 19:10 Wouter Verhelst, wrote: > On Wed, Jul 19, 2023 at 01:10:04PM +0200, Gijs Hillenius wrote: >> On 19 July 2023 09:20 Paul van der Vlis, wrote: >> >> >> [...] >> >> > Het officiele relocate script zit ook in Debian, als ik het goed >> > begrijp: /usr/lib/cyrus/bin/relocate_by_id >> >> Yep. Maar dat werkt niet (meer) op de nieuwe lege inboxen. >> >> > Manual: >> > https://www.cyrusimap.org/imap/reference/manpages/systemcommands/relocate_by_id.html >> > >> > Dit is ook interessant: >> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007965 >> > https://cyrus.topicbox.com/groups/info/T3e85440ddbb44ec6-Maf769decd0dd45d4572145b8 >> >> Volgens een van de Debian packagers: (in de bug report >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037346) "the patch >> needed to update to 3.6 is included in version 3.2.6-2+deb11u2." >> >> Ik heb die aanwijzing nog niet teruggevonden; al is het voor mij mosterd >> na het zinken van het schip. > > https://packages.debian.org/bullseye/cyrus-imapd > > Basically: je moet er eerst voor zorgen dat je bullseye-installatie > helemaal up to date is. Zoals altijd. Yep. Dat was geheel het geval; netjes de handleiding gevolgd. FWIW, op de cyrus mailinglist kwamen er 1 of 2 andere Debian cyrus admins voorbij die hun systeem zagen uitgleiden. Dat script uit de bugmelding lost het weer op, maar het is geen doen voor systemen met veel gebruikers. Omzichtig: de (zeer-gewaardeerde) packagers gebruiken kennelijk zelf geen cyrus (meer), en gingen lijkt het af op de aanwijzing van upstream. Ik vermoed dat er een stap mist - relocate_by_id of zo.. Het kan ook zijn dat "autocreate" verboden had moeten zijn. > Het zou wel beter geweest zijn als de cyrus-imapd preinst een controle > doet en heel luid lawaai maakt als de oudere versie te oud is, maar da's > een andere... -- A hermit is a deserter from the army of humanity.
Re: Debian Bookworm en Cyrus? Stap nog ff niet over
On 19 July 2023 09:20 Paul van der Vlis, wrote: [...] > Het officiele relocate script zit ook in Debian, als ik het goed > begrijp: /usr/lib/cyrus/bin/relocate_by_id Yep. Maar dat werkt niet (meer) op de nieuwe lege inboxen. > Manual: > https://www.cyrusimap.org/imap/reference/manpages/systemcommands/relocate_by_id.html > > Dit is ook interessant: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007965 > https://cyrus.topicbox.com/groups/info/T3e85440ddbb44ec6-Maf769decd0dd45d4572145b8 Volgens een van de Debian packagers: (in de bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037346) "the patch needed to update to 3.6 is included in version 3.2.6-2+deb11u2." Ik heb die aanwijzing nog niet teruggevonden; al is het voor mij mosterd na het zinken van het schip. -- You don't have to be crazy to be a member of the project, but you will be.. <=:]
Re: Debian Bookworm en Cyrus? Stap nog ff niet over
On 18 July 2023 16:15 Paul van der Vlis, wrote: > Hoi Gijs en anderen, > > Op 18-07-2023 om 10:47 schreef Gijs Hillenius: >> Paul en anderen >> Als je systemen beheert met Cyrus imapd gebruiker, stap dan nog even >> niet over naar Debian Bookworm. Alle Cyrus gebruikers verliezen dan - op >> dit moment - toegang tot hun mail. >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037346 > > Wat er nu aan de hand is, begrijp ik eigenlijk nog steeds niet. Onder meer een compleet ander files storage systeem. En zonder tussen-versie is de stap te groot. In Cyrus Bullseye zit de mail in /var/spool/cyrus/mail/a/user/aap /var/spool/cyrus/mail/n/user/noot /var/spool/cyrus/mail/g/user/gijs en dan zag je in de folder /var/spool/cyrus/mail/m/user/mies ook alle subfolders: mailvanteun, mailvanwim, spam, boekhouder, Sent, Trash, etcetera In Cyrus Bookworm is die logica verdwenen en vraag je om de locatie van iemands mailbox met mpath user.vuur en dan krijg je iets als /var/spool/cyrus/mail/uuid/h/f/hfvmgnikes2mcawo3dq1bhbg ditto voor subfolders : mpath user.vuur.mailvanteun /var/spool/cyrus/mail/uuid/4/a/4art11kgg10v22mb6p49k9t1 ! En je ziet niet langer de subfolders in de "inbox" folder. > Blijkbaar kunnen de mensen na upgrade niet meer bij hun mail... De migratie mislukt. Op mijn systeem werden vier gebruikers automatisch opnieuw aangemaakt - die hadden allemaal een fonkelnagelnieuwe inbox (leeg). Anderen (bij mij 8) werd overgeslagen. Hun inkomende mail werd geweigerd: "mailbox does not exist" (of ziets). Het script, bij elkaar gezet door 2 wakkere admins met ditzelfde distro-update probleem, dat maakt een lijst van de oorspronkelijke mailboxen (die staan nog op het systeem), maakt die mailboxen (als het ware opnieuw) aan in de nieuwe hierarchie, en linkt dan ieder bericht afzonderlijk tussen de 'oude' en 'nieuwe' folder. Script(scripts) is(gaan) niet zonder struikelfouten. Mappen met een ' in de naam gaan mis, niet alle subfolders worden opgepikt.. etcetera. Dus veel nakijken en met de hand toevoegen. Submappen met submappen? Gebruiker raakt mail kwijt. Krijg je wel weer terug, maar ... Gebruikers die niet waren gemis-migreerd, die moet je opnieuw aanmaken. En dan met die scripts de mail files weer aan elkaar linken. En dan heb je alleen je mail. Als je, zoals ik, ook nog Cyrus sieve gebruikt voor server-side mail filters, dan eh. Nou ik weet dus nog niet hoe ik dat terugzet. -- All warranty and guarantee clauses become null and void upon payment of invoice.
Debian Bookworm en Cyrus? Stap nog ff niet over
Paul en anderen Als je systemen beheert met Cyrus imapd gebruiker, stap dan nog even niet over naar Debian Bookworm. Alle Cyrus gebruikers verliezen dan - op dit moment - toegang tot hun mail. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037346 Die bug komt met een fix (niet van het Debian cyrus team) , maar dat geeft heel veel gedoe. Het is eveneens al te laat voor de tussenstap via Bullseye-backports, die versie is al te hoog, zie hier https://www.cyrusimap.org/3.6/imap/download/upgrade.html#versions-to-upgrade-from Wellicht dat je via Debian snapshot problemen kan voorkomen. Ik heb het snel ff opgesomd op https://hillenius.net/post/cyrus-debian-bookworm/ (maar daar hoef je nu niet meer heen) Grt G -- Oliver's Law: Experience is something you don't get until just after you need it.
Re: apt search dotfiles
On 9 January 2023 21:34 Geert Stappers, wrote: > Hoi, > > > Wat is zoal jullie favoriete tool om "dotfiles" te beheren? > > > Groeten > Geert Stappers > > > |$ apt search dotfiles > |Bezig met sorteren... Klaar > |Volledige tekst doorzoeken... Klaar > |homesick/testing 1.1.6-3 all > | keep your dotfiles (configs) in git > | > |rcm/testing 1.3.4-1 all > | tool to manage rc files (dotfiles) > | > |yadm/testing 3.2.1-1 all > | Yet Another Dotfiles Manager > | > |$ Ik heb mijn belangrijkste dotfiles in git en als ik andere de soep indraai, daar heb ik dan borgbackup voor. of bedoel je wat anders?
Re: markdown, logo en JPG via pandoc naar PDF
[...] enorme knip > Waarschijnlijk is het beter om alle, echte alle pandoc compomenten > van de verschillende gebruikte system te vergelijken en dan recht > trekken. (En dan zorgen dat ze qua versie gelijk blijven.) Ja, zoiets zal het zijn. Die collega is juist bezig om via Nix af te dwingen dat de gebruikte software identiek is, of je de markdown nou voorbereidt op deze of een andere Linux machine. Ik heb een reserve-laptop, ook Debian sid; en daar gaat het wel goed. Beide up-to-date. Collega is ergens wel blij met de edge-case. Hij heeft het commando en de Nix receptuur aangepast, om dit gedonder te voorkomen. Maar wat het nou veroorzaakt(e), daar ben ik nog niet achter. Ik dee op beide machines dpkg --get-selections >> laptop-[1,2] en als ik weer tijd vrij heb ga ik met diff kijken of me iets opvalt. Er zijn daarnaast verschillen in de locales van de twee machines. De tips van Paul en Rob waren me welkom.
wat zijn de side-effects van LC_ALL="C"
Hoi! Een collega op het werk helpt me met het combineren van super-eenvoudig te schrijven serietje van MarkDown regeltjes, die je dan met een enkel commando: , | nix run git+https://url...dinges-theme/#pandoc-presentation --refresh -- presentation.md ` omzet in een PDF. Het werkt vlekkeloos op zijn machine (100% nix). Het werkt bijna vlekkeloos op een VM ingericht met yum (rpm). Daar moeten we dat commando dan beginnen als: LC_ALL="C" nix run git Op mijn Debian Sid machine krijgen we gekke neven-effecten. Het werkt, net als op die Yum vm niet zonder LC_ALL="C". Maar met LC_ALL="C" verschuift op alle PDF pagina's het logootje, zo gauw als we ook maar een enkel plaatje (JPG) invoeren. Ik heb net https://wiki.debian.org/Locale bestudeerd. /etc/environment is leeg ssh een sshd config bevatten die SendEnv LANG LC_* en AcceptEnv LANG LC_* .. Iemand nog een ander idee?
swap (nog steeds) is het de lvm boot-volgorde ?
Ik graaf/vraag verder over de raid partitie die niet gemount wordt. Vooraf: hier al eerder gemeld, NAS raid1 server ge(her)installeerd. Ik heb een swap raid-partitie die bij het booten niet in werking wordt gesteld. Ik probeer uit te vinden waarom niet, en hoe ik het kan fixen. Ik zie (nu pas) dat de (her)installatie een prima log bijhield (in /var/log/installer/ ). Daaruit maak ik op dat de swap partitie goed is aangemaakt: Bijvoorbeeld in /var/log/installer/syslog "Adding 1950716k swap on /dev/md1. Priority:-2 extents:1 across:1950716k FS" en verderop in de log, zie ik mijn tweede (of derde) installatie poging: , | Wiping swap signature on /dev/mapper/md1_crypt. | partman-lvm: Physical volume "/dev/mapper/md1_crypt" successfully created. | partman-lvm: Volume group "earplug-raid1-swap-vg" successfully created | partman-lvm: Logical volume "swap-lv" created. ` of deze: "debug: /dev/mapper/earplug--raid1--swap--vg-swap--lv: is active swap" en dan bijna helemaal onderin, als de installer klaar is: , | finish-install: dpkg-divert: warning: diverting file '/sbin/start-stop-daemon' from an Essential package with rename is dangerous, use --no-rename | in-target: update-initramfs: Generating /boot/initrd.img-5.10.0-18-amd64 | in-target: cryptsetup: WARNING: md1_crypt: couldn't determine device type, assuming | in-target: default (plain). | in-target: cryptsetup: WARNING: Resume target md1_crypt uses a key file | finish-install: info: Running /usr/lib/finish-install.d/15cdrom-detect ` Maar dan, als de machine "echt" herstart, gaat het mis: journalctl -xe , | systemd[1]: dev-mapper-earplug\x2d\x2draid1\x2d\x2dswap\x2d\x2dvg\x2dswap\x2d\x2dlv.device: Job dev-mapper-earplug\x2d\x2draid1\x2d\x2dswap\x2d\x2dvg\x2dswap\x2d\x2dlv.device/start timed> | systemd[1]: Timed out waiting for device /dev/mapper/earplug--raid1--swap--vg-swap--lv ` en ook systemd-cryptsetup[805]: Failed to load LUKS superblock on device /dev/md1: Invalid argument die Luks superblock foutmelding, die wordt veroorzaakt door een commando dat wordt aangeroepen door systemd. Ik weet inmiddels welke: Ik doe: /lib/systemd/system-generators/systemd-cryptsetup-generator dat schrijft naar /tmp/ een aantal bestanden, waaronder systemd-cryptsetup@md1_crypt.service In dat bestand staat (onder meer) ExecStart=/lib/systemd/systemd-cryptsetup attach 'md1_crypt' '/dev/md1' '/dev/urandom' 'cipher=aes-xts-plain64,size=256,discard' dat kan ik dus ook vanaf de commandline herhalen, en dan krijg je dus die failed Luks superblock melding. Ik weet niet waar dat commando vandaan komt, maar ik neem aan uit de Debian installer. De enige link op het Internet waar ik wat mee kon, tot nog toe, is deze: https://forums.gentoo.org/viewtopic-t-1103832-start-0.html die doet vermoeden dat het iets te maken heeft met een race tussen crypt en het klaar zetten van de raid1. Of de lvm-dinges (zie verder). Maar helaas, zelfs als ik een langere pauze ingeef dan op dat blog (0.3) ExecStartPre=/bin/sleep 120 ^^ twee minuten, dus komt het niet goed. Ik vind sleep 300 ook ok, maar ik vermoed dat dit het probleem niet is. En dan is er nog deze link, waar een Debian user iets dergelijks meldt https://other.debian.org/debian-user/2020/03/msg00620.html "It looks like cryptsetup is started before LVM." helaas gaat die thread niet verder.
Re: swap disk
> On Sat, Oct 22, 2022 at 09:53:25AM +0200, Gijs Hillenius wrote: >> >> De raid1 herinstallatie is grotendeels gelukt. Maar als er iemand tips >> heeft over de swap file? >> >> Ik loop (waarschijnlijk) tegen een race aan tussen het proces dat de >> raid1 swap file met een random wachtwoord versleuteld, en het proces dat >> de partitie beschikbaar wil maken. >> >> Ik zeg waarschijnlijk, want het kan ook best wat anders zijn. >> >> Ik vond dit issue, (wat niet of wel in system te fixen is) >> >> https://github.com/systemd/systemd/issues/10179 > > Titel: Setting up crypted swap partition sometimes fails (racey) > > > >> uit mijn syslog: >> >> Failed to start Cryptography Setup for md1_crypt. >> Dependency failed for Local Encrypted Volumes. >> cryptsetup.target: Job cryptsetup.target/start failed with result >> 'dependency'. >> Reached target Block Device Preparation for /dev/mapper/md1_crypt. >> >> cat /etc/crypttab >> md1_crypt /dev/md1 /dev/urandom cipher=aes-xts-plain64,size=256,discard >> >> uit /etc/fstab >> /dev/mapper/earplug--raid1--swap--vg-swap--lv none swap sw 0 0 >> >> Ik heb nu eerst het systeem gereboot met deze ^^ regel in /etc/fstab >> uit: # /dev/mapper/earplug--raid1--swap--vg-swap--lv none (etcetera) >> >> dan zie ik in de dmesg >> >> dmesg | grep md1 >> >> [5.142438] md/raid1:md1: not clean -- starting background reconstruction >> [5.142446] md/raid1:md1: active with 2 out of 2 mirrors >> [5.142508] md1: detected capacity change from 0 to 1997537280 >> >> en nu? >> >> cryptdisks_start md1_crypt >> >> dat gaat ogenschijnlijk ok, maar ik moet ergens (via systemctrl?) die >> /dev/mapper/earplug--raid1--swap--vg-swap--lv aanzetten, ik weet niet >> hoe. >> >> systemctl toont: >> >> systemd-cryptsetup@md1_crypt.service loaded failed failed Cryptography Setup >> for md1_crypt >> >> ok. dan probeer ik dit >> >> systemctl restart systemd-cryptsetup@md1_crypt.service >> >> dat geeft: >> >> systemctl status systemd-cryptsetup@md1_crypt.service >> ● systemd-cryptsetup@md1_crypt.service - Cryptography Setup for md1_crypt >> Loaded: loaded (/etc/crypttab; generated) >> Active: active (exited) since Sat 2022-10-22 09:51:41 CEST; 7s ago >>Docs: man:crypttab(5) >> man:systemd-cryptsetup-generator(8) >> man:systemd-cryptsetup@.service(8) >> Process: 23788 ExecStart=/lib/systemd/systemd-cryptsetup attach >> md1_crypt /dev/md1 /dev/urandom cipher=aes-xts-plain64,size=256,discard >> (code=exited, status=0/SUCCESS) >>Main PID: 23788 (code=exited, status=0/SUCCESS) >> CPU: 33ms >> >> Oct 22 09:51:40 earplug systemd[1]: Starting Cryptography Setup for >> md1_crypt... >> Oct 22 09:51:41 earplug systemd-cryptsetup[23788]: Volume md1_crypt already >> active. >> Oct 22 09:51:41 earplug systemd[1]: Finished Cryptography Setup for >> md1_crypt. >> >> maar >> >> systemctl status dev-mapper-crypt_swap.device >> ● dev-mapper-crypt_swap.device - /dev/mapper/crypt_swap >> Loaded: loaded >> Active: inactive (dead) >> >> als iemand tips heeft over de volgende stap of test, dank! > > > Maak een tekening (en/of beschrijving) van wat gewenst is. > ( Ik heb wensen van RAID1 gezien, en zie (denk te zien) dat > dat crypted swap gewenst is. ) , | lsblk --fs | NAME FSTYPEFSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT | sda | ├─sda1 | ├─sda2linux_raid_member 1.2 earplug:0 bdc53305-43ac-a2cc-1814-7e48b8cb777c | │ └─md0 ext2 1.0 3bf333db-2bf6-4bb8-b8cc-7557acc86e19 4.2G 2% /boot | ├─sda3linux_raid_member 1.2 earplug:1 82e66aac-d53c-2320-3c5d-011bbba97aa5 | │ └─md1 | │ └─md1_crypt
swap disk (was: D A N K ! Re: vraag over raid1 - Debian 11 (her)installatie .. wanneer definieer ik swap en /boot en / (root)?)
De raid1 herinstallatie is grotendeels gelukt. Maar als er iemand tips heeft over de swap file? Ik loop (waarschijnlijk) tegen een race aan tussen het proces dat de raid1 swap file met een random wachtwoord versleuteld, en het proces dat de partitie beschikbaar wil maken. Ik zeg waarschijnlijk, want het kan ook best wat anders zijn. Ik vond dit issue, (wat niet of wel in system te fixen is) https://github.com/systemd/systemd/issues/10179 uit mijn syslog: Failed to start Cryptography Setup for md1_crypt. Dependency failed for Local Encrypted Volumes. cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'. Reached target Block Device Preparation for /dev/mapper/md1_crypt. cat /etc/crypttab md1_crypt /dev/md1 /dev/urandom cipher=aes-xts-plain64,size=256,discard uit /etc/fstab /dev/mapper/earplug--raid1--swap--vg-swap--lv none swap sw 0 0 Ik heb nu eerst het systeem gereboot met deze ^^ regel in /etc/fstab uit: # /dev/mapper/earplug--raid1--swap--vg-swap--lv none (etcetera) dan zie ik in de dmesg dmesg | grep md1 [5.142438] md/raid1:md1: not clean -- starting background reconstruction [5.142446] md/raid1:md1: active with 2 out of 2 mirrors [5.142508] md1: detected capacity change from 0 to 1997537280 en nu? cryptdisks_start md1_crypt dat gaat ogenschijnlijk ok, maar ik moet ergens (via systemctrl?) die /dev/mapper/earplug--raid1--swap--vg-swap--lv aanzetten, ik weet niet hoe. systemctl toont: systemd-cryptsetup@md1_crypt.service loaded failed failed Cryptography Setup for md1_crypt ok. dan probeer ik dit systemctl restart systemd-cryptsetup@md1_crypt.service dat geeft: systemctl status systemd-cryptsetup@md1_crypt.service ● systemd-cryptsetup@md1_crypt.service - Cryptography Setup for md1_crypt Loaded: loaded (/etc/crypttab; generated) Active: active (exited) since Sat 2022-10-22 09:51:41 CEST; 7s ago Docs: man:crypttab(5) man:systemd-cryptsetup-generator(8) man:systemd-cryptsetup@.service(8) Process: 23788 ExecStart=/lib/systemd/systemd-cryptsetup attach md1_crypt /dev/md1 /dev/urandom cipher=aes-xts-plain64,size=256,discard (code=exited, status=0/SUCCESS) Main PID: 23788 (code=exited, status=0/SUCCESS) CPU: 33ms Oct 22 09:51:40 earplug systemd[1]: Starting Cryptography Setup for md1_crypt... Oct 22 09:51:41 earplug systemd-cryptsetup[23788]: Volume md1_crypt already active. Oct 22 09:51:41 earplug systemd[1]: Finished Cryptography Setup for md1_crypt. maar systemctl status dev-mapper-crypt_swap.device ● dev-mapper-crypt_swap.device - /dev/mapper/crypt_swap Loaded: loaded Active: inactive (dead) als iemand tips heeft over de volgende stap of test, dank!
Re: D A N K ! Re: vraag over raid1 - Debian 11 (her)installatie .. wanneer definieer ik swap en /boot en / (root)?
On 18 October 2022 12:00 Paul van der Vlis, wrote: > Hoi Gijs en anderen, > > Op 18-10-2022 om 11:22 schreef Gijs Hillenius: >> Wauw Paul, >> Gedaan zoals je schreef... >> Het werkt! >> (nou bijna dan. Ik denk dat ik een foutje maakte met de swap, maar >> de >> rest draait.) > > Fijn om te horen! > > Swap kun je meestal wel repareren, daarvoor hoef je het niet opnieuw > te doen. > > Dit staat er bij mij in /etc/fstab : > /dev/mapper/vol1-swap none swapsw 0 0 hier is het : /dev/mapper/earplug--raid1--swap--vg-swap--lv none swap sw 0 0 (herhaalde spaties verwijderd) Echter, ik vermoed dat ik bij de installatie een stap oversloeg, of vergeten ben op 'finish partition' te muisklikken(™): lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:00 3.6T 0 disk ├─sda1 8:101M 0 part ├─sda2 8:20 4.7G 0 part │ └─md0 9:00 4.7G 0 raid1 /boot ├─sda3 8:30 1.9G 0 part │ └─md1 9:10 1.9G 0 raid1 └─sda4 8:40 3.6T 0 part └─md2 9:20 3.6T 0 raid1 └─md2_crypt 253:00 3.6T 0 crypt └─earplug--raid1--root--vg-root--lv 253:10 3.6T 0 lvm / sdb 8:16 0 3.6T 0 disk ├─sdb1 8:17 01M 0 part ├─sdb2 8:18 0 4.7G 0 part │ └─md0 9:00 4.7G 0 raid1 /boot ├─sdb3 8:19 0 1.9G 0 part │ └─md1 9:10 1.9G 0 raid1 └─sdb4 8:20 0 3.6T 0 part └─md2 9:20 3.6T 0 raid1 └─md2_crypt 253:00 3.6T 0 crypt └─earplug--raid1--root--vg-root--lv 253:10 3.6T 0 lvm / Hierboven, daar zou ik dit verwachten te zien sda3 -> md1 -> md1_crypt -> earplug--raid1--swap--vg--lv Hoe doe ik dat alsnog? > De volume group heet "vol1" en het logical volume "swap". > > Formatteren gaat met iets als: > mkswap /dev/mapper/vol1-swap > > Met iets als dit kun je het aanzetten: > swapon /dev/mapper/vol1-swap > > Kijk ook even in: > /etc/initramfs-tools/conf.d/resume > Als je daar iets wijzigt moet wellicht nog iets met initramfs doen: > update-initramfs -u > > Groet, > Paul -- Oh, yeah, life goes on, long after the thrill of livin' is gone. -- John Cougar, "Jack and Diane"
Vooruitgant! Re: vraag over raid1 - Debian 11 (her)installatie .. wanneer definieer ik swap en /boot en / (root)?
Met veel (!) dank aan Paul, Ik heb de Debian installer vanmorgen vroeg een vierde keer gedaan; en .. TADA .. ik heb de NAS draaiend. Het moederbord (AD2550B-ITX) ondersteunt (volgens de specificaties in 2012) geen 64 bits, iets met (Due to lack of Intel® 64-bit VGA driver ... powerVR SGX545), maar ik heb vanmorgen de 64 bits installer gedaan: firmware-11.5.0-amd64-netinst.iso. En succes! En die 64 bits dee ik omdat iemand me online vertelde dat 32 bits (besturingssystemen) geen 4 TB schijven aan kunnen. Dat was wellicht de reden van de grub error gisteren; en het was een poging waard. Inmiddels kreeg ik ook weer meer ervaring met de partition manager :-/ Maar toch nog niet genoeg: er is iets mis met de swap: , | dev-mapper-earplug\x2d\x2draid1\x2d\x2dswap\x2d\x2dvg\x2dswap\x2d\x2dlv.device: | Job | dev-mapper-earplug\x2d\x2draid1\x2d\x2dswap\x2d\x2dvg\x2dswap\x2d\x2dlv.device/start | timed out. | | Timed out waiting for device | /dev/mapper/earplug--raid1--swap--vg-swap--lv. | | Dependency failed for /dev/mapper/earplug--raid1--swap--vg-swap--lv. | | Dependency failed for Swap. ` Daar moet ik nog even goed naar kijken. In het ergste geval de installatie nog eens doen. dit is het nu: fdisk -l /dev/sda Disk /dev/sda: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: TOSHIBA HDWG440 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 447BC77F-6A03-464E-BB27-335E9731189C DeviceStartEndSectors Size Type /dev/sda1 2048 4095 20481M BIOS boot /dev/sda2 409697689599764864 4.7G Linux RAID /dev/sda3 9768960 136744953905536 1.9G Linux RAID /dev/sda4 13674496 7814035455 7800360960 3.6T Linux RAID fdisk -l /dev/sdb Disk /dev/sdb: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: WDC WD40EFZX-68A Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: CA7F1DA3-B3D7-4369-AD94-599D9DC78130 DeviceStartEndSectors Size Type /dev/sdb1 2048 4095 20481M BIOS boot /dev/sdb2 409697689599764864 4.7G Linux RAID /dev/sdb3 9768960 136744953905536 1.9G Linux RAID /dev/sdb4 13674496 7814035455 7800360960 3.6T Linux RAID
Re: vraag over raid1 - Debian 11 (her)installatie .. wanneer definieer ik swap en /boot en / (root)?
On 17 October 2022 18:46 Diederik de Haas, wrote: > On maandag 17 oktober 2022 16:19:44 CEST Paul van der Vlis wrote: >> > Het BIOS is van 2012/2014, en al heeft het UEFI in de naam (16Mb AMI >> > UEFI Legal BIOS with GUI support) zal dat wel de reden zijn dat mijn >> > huis-nas voorlopig niet wil booten. >> >> Ja, je hebt volgens mij UEFI en GPT nodig om te kunnen booten vanaf een >> grote disk. Het gaat niet om de partitie, maar om de disk. > > Ik weet het niet 100% zeker, maar volgens mij heb je alleen GPT nodig, maar > niet (per se) UEFI. > https://superuser.com/questions/1393198/what-is-the-maximum-size-of-hard-drive-used-mbr-partitioning Installatie helemaal opnieuw gedaan. Grub geinstalleerd op /dev/sda en /dev/sdb vol goede hoop: maar bij het opstarten error: disk lvmid/A2weNY-Or4m-o6O2-sBnb-XFf2-syPz-1E4yml/poWL7U-Ry2d-a67B-C6xJ-0MGN-MP kc-gwk3IV not found grub-rescue > Ik vermoed dat ik dit moederbordje te oud is. Hieronder nog veel te veel info over de partitie. Disk sda: 3.65 TiB, 4000787030016 bytes, 7814037168 sectors Disk identifier: 447BC77F-6A03-464E-BB27-335E9731189C StartEndSectors Size Type sda1 2048 4095 20481M BIOS boot sda2 4096 980991 976896 477M Linux filesystem sda3 98099248865273905536 1.9G Linux RAID sda4 4886528 7814035455 7809148928 3.7T Linux RAID Disk sdb: 3.65 TiB, 4000787030016 bytes, 7814037168 sectors Disk identifier: CA7F1DA3-B3D7-4369-AD94-599D9DC78130 StartEndSectors Size Type sdb1 2048 4095 20481M BIOS boot sdb2 4096 980991 976896 477M Linux filesystem sdb3 98099248865273905536 1.9G Linux RAID sdb4 4886528 7814035455 7809148928 3.7T Linux RAID == Boot Info Summary === => Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector 2048 of the same hard drive for core.img. core.img is at this location and looks for (lvmid/A2weNY-Or4m-o6O2-sBnb-XFf2-syPz-1E4yml/poWL7U-Ry2d-a67B-C6xJ-0MGN-MP kc-gwk3IV)/boot/grub. It also embeds following components: modules --- fshelp ext2 diskfilter lvm biosdisk --- => Grub2 (v2.00) is installed in the MBR of /dev/sdb and looks at sector 2048 of the same hard drive for core.img. core.img is at this location and looks for (lvmid/A2weNY-Or4m-o6O2-sBnb-XFf2-syPz-1E4yml/poWL7U-Ry2d-a67B-C6xJ-0MGN-MP kc-gwk3IV)/boot/grub. It also embeds following components: signature.asc Description: PGP signature
Re: vraag over raid1 - Debian 11 (her)installatie .. wanneer definieer ik swap en /boot en / (root)?
[...] knip >> En nu moet ik die herbouwen, met twee nieuwe en grotere schijven. >> Ik weet niet (meer) in welke stap ik de / /boot en swap partities >> definieer. >> Maak ik 1 raid partitie op beide schijven, en verdeel ik daarna met >> lvm+encryptie de schijf in 3 partities? >> Of moet ik elke harde schijf in 3 verdelen, en van elke 2 gelijke >> partities dan één raid1 partitie maken? > > Als je grotere schijven wilt kunnen gebruiken dan 2TB dan moet je UEFI > gebruiken en dan heb je GPT en een "BIOS boot" partitie nodig. Vaak is > die maar 1 MB groot. Ik zou hem maken op zowel sda1 als sdb1. Alleen > die op sda1 zal worden gebruikt, maar ik zou later als de boel klaar > is met dd de inhoud van sda1 kopieren naar sdb1, en op sdb ook grub > installeren. Ah, Paul, dank voor die uitleg! Het BIOS is van 2012/2014, en al heeft het UEFI in de naam (16Mb AMI UEFI Legal BIOS with GUI support) zal dat wel de reden zijn dat mijn huis-nas voorlopig niet wil booten. Wellicht kan ik booten vanaf een USB-dingetje. Gisteren prikte ik twee 4TB schijven in de kast. Met de Debian 11 installer heb ik daar 1 4TB raid1 device van gemaakt. Vervolgens liep ik helemaal vast in het instellen van de LVM/encrypted ; ergste was nog dat ik de indeling niet ongedaan kreeg. Maar ... De automatische optie in het menu blijkbaar wel: Raid device #0 #1 1.0 MB K biosgrub #2 512.0 MB ext #3 4.0 TB (hey, waar is de swap?) Maar bij het installeren van grub ging dat alsnog mis, het wilde niet in /dev/sdax noch /dev/sdbx. Dus ik ben terug bij af. Wat doe ik eerst: De 4 TB schijven opdelen in 2 of meer raid devices? Of is het 1 4TB raid device, waaroverheen LVM/crypt zijn gang gaat? Dank voor het meedenken!
vraag over raid1 - Debian 11 (her)installatie .. wanneer definieer ik swap en /boot en / (root)?
Hallo Acht jaar geleden installeerde ik deze raid1: lsblk --fs NAME FSTYPELABEL MOUNTPOINT sdb ├─sdb1 linux_raid_member harde-schijf:0 │ └─md0ext4/boot ├─sdb2 linux_raid_member harde-schijf:2 │ └─md2 │ └─md2_crypt (dm-1) swap[SWAP] └─sdb3 linux_raid_member harde-schijf:1 └─md1crypto_LUKS └─md1_crypt (dm-0) ext4/ sda ├─sda1 linux_raid_member harde-schijf:0 │ └─md0ext4/boot ├─sda2 linux_raid_member harde-schijf:2 │ └─md2 │ └─md2_crypt (dm-1) swap[SWAP] └─sda3 linux_raid_member harde-schijf:1 └─md1crypto_LUKS └─md1_crypt (dm-0) ext4/ En nu moet ik die herbouwen, met twee nieuwe en grotere schijven. Ik weet niet (meer) in welke stap ik de / /boot en swap partities definieer. Maak ik 1 raid partitie op beide schijven, en verdeel ik daarna met lvm+encryptie de schijf in 3 partities? Of moet ik elke harde schijf in 3 verdelen, en van elke 2 gelijke partities dan één raid1 partitie maken?
Re: Scrollbar terug in Firefox
On 29 September 2022 16:40 Cecil Westerhof, wrote: > Ik ben net gemigreerd van Firefox 91.13 naar 102.3. Bij de oude had ik > een echte scrollbar, maar bij de nieuwe een hele smalle, die ook maar > heel even zichtbaar is. > Is er een mogelijkheid om de oude functionaliteit terug te krijgen? ja. in settings: always show scrollbars aanvinken. > Er zijn trouwens andere programma's die dit 'altijd' al hebben gehad. > Bijvoorbeeld Thunar. Is daar iets aan te doen? Gewoon Emacs Dired gebruiken :)
spamhaus spamassassin-dqs
Ik geef een update, met een nieuw onderwerp-regel. Als het te lang is, excuses! Mijn kleine server - Debian stable - draait onder meer Exim en Spamassassin. Enige tijd terug begon Spamhuis aangeroepen via Exim mail te bouncen van onder meer een grote internetzoekmachine, een internet-betalingen-dienstaanbieder, en enkele andere grote commerciële domeinen. Was erg onhandig, ivm enkele internet-bestellingen. Ik heb om te beginnen in Exim de blocklists uitgezet; daarmee komen die mails weer gewoon aan. En ik doe een poging om van Spamhaus de DQS plugin te gebruiken: https://github.com/spamhaus/spamassassin-dqs- "Data Query Service (DQS) is a set of DNSBLs, updated in real-time, operated by Spamhaus Technology" Daar heb ik onder meer unbound voor geinstalleerd. En de firewalld aangepast voor DNS. De installatie en configuratie van de plugin zelf is recht toe recht aan. (Maar: ik lees gehaast als altijd vaak over de belangrijke details heen.) Affijn: tot nog toe worden alle test-mails, die je kan laten verzenden via blt.spamhaus.com door spamassassin gewoon als OK doorgelaten. Als ik doe spamassassin -D < testmail als user Debian-spamd, want zo draait spamd op mijn systeem, en met testmail een van de testmails van blt.spamhaus.com (gekopieerd vanuit mijn eigen Inbox naar /tmp/testmail. In zo'n mail zit dan bijvoorbeeld een domain waarop spamassassin moet aanslaan.. zrdtest.com hieronder). zie ik in de enorme output onder meer: plugin: loading Mail::SpamAssassin::Plugin::SH from /etc/spamassassin/SH.pm dus die plugin lijkt me correct geïnstalleerd. ik zie ook heel veel meldingen die me vertellen dat er verkeer van spamassassin naar "mijn" spamhaus account gaat: async: query 17181/IN/A/zrdtest.com.my-key-here.dbl.dq.spamhaus.net already done, re-using for SH:zrdtest.com.my-key-here.dbl.dq.spamhaus.net, callback SHPlugin: _finish_lookup on zrdtest.com / SH_DBL_ABUSED_FULLHOST / ^127.0.1.10[2-6]$ Mij lijkt het alsof hierdoor (SH_DBL_ABUSED_FULLHOST) de spam waarde omhoog moet met 6, want de plugin komt met een bestand "sh_scores.cf" en daarin: "score SH_DBL_ABUSED_FULLHOST 6" Maar .. de spam waarde is uiteidelijke netjes 0.989 Vraag: zou ik SH_DBL_ABUSED_FULLHOST moeten terugzien in dit gedeelte, bijna onderin, van de output van "spamassassin -d < testmail" check: is spam? score=0.989 required=3.5 check: tests=`SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY,URIBL_ZRD
Re: verouderde instellingen exim en spamhaus? + DNS ??
Ha Geert Ik, tien dagen terug: >> >> Mijn exim4.conf.templat bevat >> >> .ifndef CHECK_RCPT_IP_DNSBLS >> >> CHECK_RCPT_IP_DNSBLS = \ >> >> cbl.abuseat.org : \ >> >> virbl.dnsbl.bit.nl : \ >> >> zen.spamhaus.org >> >> .endif mijn posts op de lijst (hieronder) gaan niet meer over wat hierboven staat. [...] te grote knip > Mij ontgaat hoe een eigen tussenschakel kan helpen > bij het probleem van > een twijfelachtige CHECK_RCPT_IP_DNSBLS configuratie. Klopt. Ik ben nu bezig met die spamassassin dqs. Ik maak ergens morgen (of de dag erna) een nieuwe post.
Re: verouderde instellingen exim en spamhaus?
> Op 28-08-2022 om 09:44 schreef Gijs Hillenius: >> On 27 August 2022 20:43 Paul van der Vlis, wrote: >> >>> >>> Op 18-08-2022 om 12:20 schreef Gijs Hillenius: >>>> Mijn exim4.conf.templat bevat >>>> .ifndef CHECK_RCPT_IP_DNSBLS >>>> CHECK_RCPT_IP_DNSBLS = \ >>>> cbl.abuseat.org : \ >>>> virbl.dnsbl.bit.nl : \ >>>> zen.spamhaus.org >>>> .endif >>>> maar .. ik krijg het idee dat deze regels achterhaald zijn. >>>> die eerste (cbl) is blijkbaar al een paar jaar terug vervangen door >>>> xbl.spamhaus.org, lees ik nu net op https://www.abuseat.org/cutover.html >>>> Zou dit verklaren waarom ik de laatste tijd meldingen krijg over >>>> bounces van bendel.debian.org en van lists.gnu.org? >>>> voorbeeld: >>>> 2022-08-18 12:10:01 H=lists.gnu.org [209.51.188.17] >>>> X=TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256 CV=no >>>> F= rejected RCPT >>>> : 209.51.188.17 is listed at cbl.abuseat.org >>>> (127.255.255.254: Error: open resolver; >>>> https://www.spamhaus.org/returnc/pub/2400:cb00:71:1024::a29e:52ca) >>> >>> Je gebruikt wellicht de verkeerde DNS, let op dat "open resolver": >>> >>> https://www.spamhaus.com/resource-center/if-you-query-spamhaus-projects-dnsbls-via-cloudflares-dns-move-to-the-free-data-query-service/ >>> >>> Jij gebruikt blijkbaar Exim, dat ken ik niet zo goed. >> Toen ik begon met Debian was dat de default. Het is maar een mini >> servertje, voor een handvol actieve mail-ontvangers/verzenders. >> >>> Ik gebruik Postfix, belangrijk daarbij is dat je na wijzigen DNS >>> Postfix echt uitzet en weer opnieuw start, anders gebruikt het nog de >>> oude DNS. >>> >>> Ik had hier ook problemen mee bij een klant, toen ben ik eigen DNS >>> gaan draaien daar. >> Dank! En daar (ik moet aan de DNS) lijkt het op! >> Enkele jaren terug deed ik al eens een echt poging met Bind; en dat >> samen met iemand die er best verstand van heeft. Dat lukte ons toen in >> een paar uur worstelen toch niet. >> Ik zit nu naar Unbound te kijken. Dat lijkt minder complex? Is dit >> *echt* alles ? >> https://unbound.docs.nlnetlabs.nl/en/latest/getting-started/configuration.html > > Ik gebruik Bind9. Gewoon installeren, starten en de machine zo > instellen dat de DNS 127.0.0.1 is. Zolang hij niet verantwoordelijk is > voor bepaalde zone's is het simpel. Dus goed mogelijk dat Unbound ook > heel simpel is. Doh! (Dat van die zones was inderdaad het probleem.) Ik heb vanmorgen unbound geinstalleerd, en de (spamassassin) tests die hier worden beschreven gaan allemaal goed: https://cwiki.apache.org/confluence/display/SPAMASSASSIN/CachingNameserver Maar nou moet ik nog goed kijken naar de logs (en het antwoord/hint van Geert).
Re: verouderde instellingen exim en spamhaus?
On 27 August 2022 20:43 Paul van der Vlis, wrote: > > Op 18-08-2022 om 12:20 schreef Gijs Hillenius: >> Mijn exim4.conf.templat bevat >> .ifndef CHECK_RCPT_IP_DNSBLS >> CHECK_RCPT_IP_DNSBLS = \ >> cbl.abuseat.org : \ >> virbl.dnsbl.bit.nl : \ >> zen.spamhaus.org >> .endif >> maar .. ik krijg het idee dat deze regels achterhaald zijn. >> die eerste (cbl) is blijkbaar al een paar jaar terug vervangen door >> xbl.spamhaus.org, lees ik nu net op https://www.abuseat.org/cutover.html >> Zou dit verklaren waarom ik de laatste tijd meldingen krijg over >> bounces van bendel.debian.org en van lists.gnu.org? >> voorbeeld: >> 2022-08-18 12:10:01 H=lists.gnu.org [209.51.188.17] >> X=TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256 CV=no >> F= rejected RCPT >> : 209.51.188.17 is listed at cbl.abuseat.org >> (127.255.255.254: Error: open resolver; >> https://www.spamhaus.org/returnc/pub/2400:cb00:71:1024::a29e:52ca) > > Je gebruikt wellicht de verkeerde DNS, let op dat "open resolver": > > https://www.spamhaus.com/resource-center/if-you-query-spamhaus-projects-dnsbls-via-cloudflares-dns-move-to-the-free-data-query-service/ > > Jij gebruikt blijkbaar Exim, dat ken ik niet zo goed. Toen ik begon met Debian was dat de default. Het is maar een mini servertje, voor een handvol actieve mail-ontvangers/verzenders. > Ik gebruik Postfix, belangrijk daarbij is dat je na wijzigen DNS > Postfix echt uitzet en weer opnieuw start, anders gebruikt het nog de > oude DNS. > > Ik had hier ook problemen mee bij een klant, toen ben ik eigen DNS > gaan draaien daar. Dank! En daar (ik moet aan de DNS) lijkt het op! Enkele jaren terug deed ik al eens een echt poging met Bind; en dat samen met iemand die er best verstand van heeft. Dat lukte ons toen in een paar uur worstelen toch niet. Ik zit nu naar Unbound te kijken. Dat lijkt minder complex? Is dit *echt* alles ? https://unbound.docs.nlnetlabs.nl/en/latest/getting-started/configuration.html
Re: verouderde instellingen exim en spamhaus?
[...] grote knip >> >> Via het fediverse wees iemand me op: >> https://github.com/spamhaus/spamassassin-dqs > > Uit de README.md van die URL: > > | What is DQS? > | > | Data Query Service (DQS) is a set of DNSBLs, updated in real-time, > | operated by Spamhaus Technology > >> Heeft iemand hier ervaring met die plugin? [...] grote knip > ik vermoed ook wel dat de plugin actief is. Hoe ik de spamhaus > melding lees: > > Your Mail eXchange server is *not* configured for using some block list. > > Wat er ontbreekt aan de configuratie is mij niet duidelijk. mijn mail.log vertelt me dat bijna alle DSN verzoeken die iets met Spamassassin te maken hebben worden afgebroken. Voorbeeld: , | dns: reply to 3760/IN/A/hillenius.net.(hiermijnspamhausnummer).dbl.dq.spamhaus.net truncated (EDNS 4096 bytes), 0 answer records ` maar ook, af en toe: , | dns: bgread: received 78 bytes from 2606:4700:4700:: | dns: dns reply 59471 is OK, 1 answer records ` Is dat een probleem met mijn firewall? Of is dat omdat ik geen DNS infra draai op mijn server host? Of wat anders? Die eerste mogelijkheid leek me eenvoudig te verhelpen (maar...) firewall-cmd --permanent --zone=public --add-service=dns systemctl restart firewalld.service Affijn, nog steeds is het antwoord "truncated" in mail.log
Re: verouderde instellingen exim en spamhaus?
On 18 August 2022 19:52 Richard Lucassen, wrote: > On Thu, 18 Aug 2022 12:20:23 +0200 > Gijs Hillenius wrote: > >> Mijn exim4.conf.templat bevat >> >> .ifndef CHECK_RCPT_IP_DNSBLS >> CHECK_RCPT_IP_DNSBLS = \ >> cbl.abuseat.org : \ >> virbl.dnsbl.bit.nl : \ >> zen.spamhaus.org >> .endif > > Volgens mij is virbl.dnsbl.bit.nl al jaren terug gestopt. > Dank! Ik heb het hele block maar even uitgezet. Via het fediverse wees iemand me op: https://github.com/spamhaus/spamassassin-dqs Heeft iemand hier ervaring met die plugin? Mijn vraag: maakt deze plugin het overbodig om in Exim te wijzen naar Spamhaus? Ik dee wat tests, en die gaan "fout" waarbij Spamhaus met vertelt: This email was delivered, but should have been rejected during the SMTP session. Your MX is not configured to use SMPT-level block listing for the block list for this test. Ik dacht dat we dit met die plugin juist aan Spamassassin overdragen? -- Je ziet het pas als je het doorhebt - Johan Cruijff
verouderde instellingen exim en spamhaus?
Mijn exim4.conf.templat bevat .ifndef CHECK_RCPT_IP_DNSBLS CHECK_RCPT_IP_DNSBLS = \ cbl.abuseat.org : \ virbl.dnsbl.bit.nl : \ zen.spamhaus.org .endif maar .. ik krijg het idee dat deze regels achterhaald zijn. die eerste (cbl) is blijkbaar al een paar jaar terug vervangen door xbl.spamhaus.org, lees ik nu net op https://www.abuseat.org/cutover.html Zou dit verklaren waarom ik de laatste tijd meldingen krijg over bounces van bendel.debian.org en van lists.gnu.org? voorbeeld: 2022-08-18 12:10:01 H=lists.gnu.org [209.51.188.17] X=TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256 CV=no F= rejected RCPT : 209.51.188.17 is listed at cbl.abuseat.org (127.255.255.254: Error: open resolver; https://www.spamhaus.org/returnc/pub/2400:cb00:71:1024::a29e:52ca) (en mails misloop die worden verzonden door diverse grote mail verzenders) Iemand er meer kennis van?
debconf (online)
Ik volgde vanmorgen met veel plezier de lezing over Debian bij Siemens. Zit ik toch weer heel anders in de trein, dus. Het was een presentatie op de Debconf, de lezingen in de hoofd-zaal zijn te volgen met: mpv https://onsite.live.debconf.org/live/drini.m3u8 -- Clones are people two.
Re: Debian-fasttrack was: Re: een "backport" van package hutsefluts
Dank! is ook nieuw voor mij. On 8 February 2022 13:47 Paul van der Vlis, wrote: > Hoi, > > Hadden jullie al eens gehoord van Debian-fasttrack? Ik niet: > https://wiki.debian.org/FastTrack > https://fasttrack.debian.net/ > > Groeten, > Paul > > Op 08-02-2022 om 11:33 schreef Paul van der Vlis: >> Op 07-02-2022 om 21:25 schreef Geert Stappers: >>> Hoi, >>> >>> Als het meezit, dan ben ik een zinvolle tip aan het doorsturen. >>> >>> - Forwarded message from Daniel Gröber - >>> >>> Date: Mon, 7 Feb 2022 10:30:25 +0100 >>> From: Daniel Gröber >>> To: David Pottage >>> Cc: debian-backpo...@lists.debian.org >>> Subject: Re: Backport restic to bullseye? >>> >>> On Mon, Feb 07, 2022 at 09:06:55AM +, David Pottage wrote: On 2022-02-05 18:54, Jan De Luyck wrote: You don't need to wait for a backport if you don't want to. The restic downloadable is a single statically linked binary, so it is very easy to download and install without the need for a distro package. >>> >>> Alternatively it's also pretty easy to use the restic Debian package from >>> sid right on stable because it if like me you dont particularily trust >>> upstream binaries. >>> >>> Just add an entry for sid in sources.list and do some APT pinning: >>> >>> /etc/apt/preferences: >>> >>> # Don't install things from sid by default >>> Package: * >>> Pin: release a=unstable >>> Pin-Priority: -10 >>> >>> # Except for restic. >>> Package: restic >>> Pin: release a=unstable >>> Pin-Priority: 999 >>> >>> That being said I looked into backporting restic a while back too and it >>> seemed like a PITA because a fair number of go dependencies would have to >>> be backported too. >>> >>> --Daniel >>> >>> >>> - End forwarded message - >>> >>> Laat maar weten of dat ook zo is. >> Soms is het inderdaad heel lastig (Pine In The Ash) om een backport >> te maken omdat er voor het bouwen veel afhankelijkheden zijn. >> Ik vraag me wel eens af waarom het bouwen van een pakket perse op >> dezelfde versie van Debian moet. Bijvoorbeeld onlangs bij de nieuwe >> versie van Firefox gaf dit grote problemen. >> Bovenstaande lijkt me inderdaad een noodoplossing om een pakket uit >> unstable te installeren en up-to-date te houden. Of het werkt en >> blijft werken lijkt me niet zeker, er zou bijvoorbeeld een nieuwere >> versie van libc6 nodig kunnen zijn, of in de toekomst worden. >> Interessant vind ik ook deze opmerking: "(..) if like me you dont >> particularily trust upstream binaries." Wat hij in feite zegt is >> dat hij upstream binaries niet helemaal vertrouwd en het fijn vind >> dat er een DD tussenzit die de boel een beetje in de gaten >> houdt. Dat vind ik namelijk ook. Bijvoorbeeld: compileert de >> sourcecode wel tot de aangeboden binary. Voor mij is dat een reden >> sommige applicaties toch niet zo graag te gebruiken, omdat de makers >> er niemand tussen willen hebben. Of dat de ontwikkeling zo hard >> gaat, dat dat praktisch niet mogelijk is. Maar of DD's deze >> controlerende taak serieus nemen, dat zal niet altijd zo zijn. En >> wilicht is de maker ook de packager, dan is die controle er veel >> minder. >> Groeten, >> Paul >> -- Negativity Bias: Paying more attention to bad news and feedback than good NewScientist 28 July 2018
Re: Agenda software
On 13 December 2021 07:58 Martijn van de Streek, wrote: > Geert Stappers schreef op zo 12-12-2021 om 19:36 [+0100]: >> Wat gebruiken jullie zoal aan agenda software? Emacs: een combinatie van diary, calendar en Org-Mode. En dan een read-only kopie op de smartphone (voor onderweg, maar dat was meer iets van voor begin 2020).
Re: laptop start niet meer op na suspend
On 6 December 2021 11:38 richard lucassen, wrote: > On Mon, 06 Dec 2021 11:06:26 +0100 > Frank Voncken wrote: > >> Ik moet daar helaas op terugkomen: het wordt na >> >>echo mem > /sys/power/state >> >> niet meer wakker... :-( > > Tsja, voordat je uitvindt wat het is... > >> > echo disk > /sys/power/state >> >> Het vreemde is dat ongeveer 15 seconden na invoeren van echo disk > >> /sys/power/state de laptop spontaan weer wakker wordt met in de >> terminal de volgende foutmelding: >> >>bash: echo: schrijffout: Geen ruimte meer over op apparaat >> >> Vreemd... > > Wellicht is je swapfile of swap partitie te klein. Bij hibernate maakt > de kernel een kopie van het werkgeheugen naar swap. Als-ie weer opstart > ziet-ie dat er een image op de swap staat en dan laadt-ie het weer in. > Misschien kun je opstarten in een niet-X omgeving (gewoon een tty) en > dan nog eens proberen om te testen. Dan heb je veel minder memory in > gebruik. > > Geen idee of het ook met een swapfile werkt ipv een swappartitie. Ik > gebruik namelijk alleen een aparte partitie. Mijn laptop (Thinkpad X1 7th Gen) met Debian Sid heeft (of meer, *had*) problemen met wakker worden uit slaapstand. Nu het hierboven ineens gaat over schijf/swap ruimte... Kan het zijn dat een te grote kernel slecht slaapt? Ik had (op deze lijst meegedeeld) recent problemen met een te krappe boot partitie (op een verdere versleutelde schijf). Ik lostte dat op met "MODULES=dep" in /etc/initramfs-tools/conf.d/modules, gevolgd door "update-initramfs -k all u". Verhielp dat soms ook het suspend issue? Of heeft dit niets met elkaar te maken?
(ssh-1 ongefixst maar probleem anders opgelost) Re: Debian 11, openssh server, ssh-1 toegang voor 1 client, hoe?
Wellicht wijst iemand me binnenkort terecht terecht dat ik niet moet peuteren aan de veiligheidsknoppen van SSH. Ik heb mijn onderliggende probleem (met een legacy Android app) inmiddels op een andere manier opgelost. Dank voor het meeluisteren Gijs
Debian 11, openssh server, ssh-1 toegang voor 1 client, hoe?
Hallo! Ik heb een app op mijn mobiel die sinds Debian 11 niet meer bij de ssh server mag. De server log: , | sshd[1646154]: Unable to negotiate with 2a01:4f8:200:546b:1::3 port | 48559: no matching key exchange method found. Their offer: | diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffi | e-hellman-group-exchange-sha1 [preauth] ` De (open source) app wordt allang niet meer onderhouden, de ontwikkelaar gaf het op, en ik ben nog lang niet zo ver dat ik het kan overnemen. Wat ik wel kan, denk ik, is de ssh server vertellen dat vanaf dat ene IP address ssh-1 toegestaan is? Ik ben aan het puzzelen met de man page en zoekmachines. Maar de juiste oplossing heb ik nog niet, verslag van mijn pogingen: 1) Een bestandje geheten "mobileapp.conf", in de directory /etc/sshd_config.d/ (op de server) met als inhoud: , | Match Address 2a01:4f8:200:546b:1::3/80 | HostKeyAlgorithms=diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1 ` maar daarin verslikte zich de ssh server: , | systemd[1]: ssh.service: Start request repeated too quickly. | Nov 17 16:55:04 metonym systemd[1]: ssh.service: Failed with result 'exit-code'. | Subject: Unit failed | Defined-By: systemd | Support: https://www.debian.org/support | | The unit ssh.service has entered the 'failed' state with result 'exit-code'. | systemd[1]: Failed to start OpenBSD Secure Shell server. | Subject: A start job for unit ssh.service has failed | Defined-By: systemd | Support: https://www.debian.org/support | | A start job for unit ssh.service has finished with a failure. | | The job identifier is 265795 and the job result is failed. ` een tweede variant, waarin ik HostKeyAlgorithms verving door KexAlgorithms zette de ssh server ook al op slot. verder lezen leerde me dat een Match block op het eind van de config moet staan. Die twee regels van hierboven op het einde van sshd_config, dat geeft diezelfde fout. Als iemand weet wat ik wel moet doen?
Re: /boot is vol .. (en niet met kernels)
On 15 October 2021 09:43 Gijs Hillenius, wrote: > [...] > >> | >> >>> Ik ga dat vandaag proberen >> >> En hoe ging het? > > O potverknikkertjes, heb ik dat niet teruggekoppeld? > > Schep een bestand met de naam modules in > /etc/initramfs-tools/conf.d/modules waarin: > > MODULES=dep > > En dan > > update-initramfs > > voor /dev/nvme0n1p2 237M101M124M45% /boot > na/dev/nvme0n1p2 237M42M 183M19% /boot > > Nu is het even wachten tot Debian Unstable met een nieuwe kernel komt, ... deze zaterdag morgen Gelukt! ls /lib/modules 5.14.0-2-amd64 5.14.0-3-amd64
Re: /boot is vol .. (en niet met kernels)
[...] > | > >> Ik ga dat vandaag proberen > > En hoe ging het? O potverknikkertjes, heb ik dat niet teruggekoppeld? Schep een bestand met de naam modules in /etc/initramfs-tools/conf.d/modules waarin: MODULES=dep En dan update-initramfs voor/dev/nvme0n1p2 237M101M124M45% /boot na /dev/nvme0n1p2 237M42M 183M19% /boot Nu is het even wachten tot Debian Unstable met een nieuwe kernel komt, (ja, ik kan ook zelf even de vorige terughalen uit snapshot.debian) Ik neem aan dat het gaat lukken.
Re: /boot is vol .. (en niet met kernels)
On 10 October 2021 20:32 Martijn van de Streek, wrote: > Winfried Tilanus schreef op zo 10-10-2021 om 15:19 [+0200]: >> On 10-10-2021 10:41, Gijs Hillenius wrote: >> >> > Even gegrepd in de term.log van apt... sinds Maart heb ik bij >> > iedere nieuwe kernel: >> >> Het is mij wel eens opgevallen dat mkinitramfs tijdens het proces >> meer ruimte gebruikt dan er uiteindelijk nodig is. Heb het nooit >> verder onderzocht, maar na een tijdje klooien /boot vergroot... > > In /etc/initramfs-tools/initramfs.conf kun je in plaats van de > standaard "MODULES=most", "MODULES=dep" opgeven. Standaard is de > initramfs-image bij mij zo'n 38 MiB, met "MODULES=dep" is daar nog maar > 9 MiB van over > > Let op dat omdat niet alle modules in initramfs zitten, sommige > bootproblemen lastiger te debuggen zijn omdat je niet al je hardware > kunt aanspreken vanuit een shell in initramfs. Ook kán het zijn dat je > installatie niet gelijk werkt als je de schijf in een andere machine > stopt (maar AHCI en NVMe zijn zo standaard dat de modules hiervoor > altijd wel aanwezig zullen zijn; ik denk niet dat dat een heel groot > probleem is?) en inderdaad! https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929424 Ik ga dat vandaag proberen Dank! G
Re: /boot is vol .. (en niet met kernels)
Goedenmorgen! [...] Snip! Ik vergiste me: >> >> df -h: >> , >> | /dev/nvme0n1p2 237M 101M 124M 45% /boot >> | /dev/nvme0n1p1 511M 4.7M 507M 1% /boot/ef >> ` >> >> Wat is de beste aanpak? >> >> 1) Kan ik die efi partitie opschonen? Zit het vol met "firmware >> updates"? >> >> ls /boot/efi/EFI/debian/ >> BOOTX64.CSV fbx64.efi fw fwupdx64.efi grub.cfg grubx64.efi >> mmx64.efi shimx64.efi > > Daar herken ik niet de 'Het zit vol met "firmware updates"' Ik las df output (weer eens) verkeerd: /boot/efi is 1% vol. Dus dat is het probleem niet. En de nieuwe firmware update lukte me (nu 20 minuten terug) wel. [...] Snip! > > Ander ding, hier aan deze kant van het Internet: > > |$ ls -lh /boot/ > |totaal 124M > |-rw-r--r-- 1 root root 231K 2 mrt 2021 config-5.10.0-4-amd64 > |-rw-r--r-- 1 root root 231K 27 mrt 2021 config-5.10.0-5-amd64 > |drwxr-xr-x 5 root root 1,0K 1 apr 2021 grub > |-rw-r--r-- 1 root root 55M 15 mrt 2021 initrd.img-5.10.0-4-amd64 > |-rw-r--r-- 1 root root 55M 1 apr 2021 initrd.img-5.10.0-5-amd64 > |drwx-- 2 root root 12K 30 mrt 2015 lost+found > |-rw-r--r-- 1 root root 83 2 mrt 2021 System.map-5.10.0-4-amd64 > |-rw-r--r-- 1 root root 83 27 mrt 2021 System.map-5.10.0-5-amd64 > |-rw-r--r-- 1 root root 6,5M 2 mrt 2021 vmlinuz-5.10.0-4-amd64 > |-rw-r--r-- 1 root root 6,6M 27 mrt 2021 vmlinuz-5.10.0-5-amd64 > > Een volgende kernel zal iets van 55M+7M+0,3M, 63M diskruimte claimen. > > En als je weet hebt van >> | /dev/nvme0n1p2 237M 101M 124M 45% /boot > Dan zou je mogen verwachten dat het past Inderdaad, het verbaast mij (ook): Even gegrepd in de term.log van apt... sinds Maart heb ik bij iedere nieuwe kernel: , | processing triggers for initramfs-tools (0.139) ... | update-initramfs: Generating /boot/initrd.img-5.10.0-4-amd64 | cat: write error: No space left on device | update-initramfs: failed for /boot/initrd.img-5.10.0-4-amd64 with 1. | ESC[1mdpkg:ESC[0m error processing package initramfs-tools (--configure): | installed initramfs-tools package post-installation script subprocess returned error exit status 1 | Errors were encountered while processing: | initramfs-tools ` deze is van 2021-10-04: , | update-initramfs: Generating /boot/initrd.img-5.14.0-2-amd64 | | gzip: stdout: No space left on device | E: mkinitramfs failure gzip 1 | update-initramfs: failed for /boot/initrd.img-5.14.0-2-amd64 with 1. | ESC[1mdpkg:ESC[0m error processing package initramfs-tools (--configure): ` Ik kijk nog wel even verder Dank! G
/boot is vol .. (en niet met kernels)
Hoi! Mijn Debian unstable workstation (een nieuwe machine geïnstalleerd met Debian unstable ergens in December 2019) heeft een te krappe boot partitie. Bij updates kan ik nog slechts één kernel installeren (de 'running kernel' moet er dan eerst af). En firmware updaten, dat wil ie nu niet meer. df -h: , | /dev/nvme0n1p2 237M 101M 124M 45% /boot | /dev/nvme0n1p1 511M 4.7M 507M 1% /boot/ef ` Wat is de beste aanpak? 1) Kan ik die efi partitie opschonen? Zit het vol met "firmware updates"? ls /boot/efi/EFI/debian/ BOOTX64.CSV fbx64.efi fw fwupdx64.efi grub.cfg grubx64.efi mmx64.efi shimx64.efi 2) Opstarten vanaf Debian rescue en dan de root partitie / (/dev/mapper/inauditus--vg-root) verkleinen, en daarmee /boot vergroten? 3) De root partitie / verkleinen en en nieuwe partitie aanwijzen als /boot, spullen overzetten? dank voor tips G
Re: update krijg Wireguard niet naar verwachting aan de gang met IPv6
On 26 September 2021 10:59 Geert Stappers, wrote: (knip!) > telnet -4 salsa.debian.org 2309 ik doe op de client telnet 6 salsa.debian.org 2309 dan toon de server tcpdump -ni any port 2309 tcpdump: data link type LINUX_SLL2 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 15:18:28.147092 wg0 In IP6 fd42:42:42::2.33414 > 2607:f8f0:614:1::1274:44.2309: Flags [S], seq 4140354248, win 65280, options [mss 1360,sackOK,TS val 1089390879 ecr 0,nop,wscale 7], length 0 15:18:28.147116 eth0 Out IP6 fd42:42:42::2.33414 > 2607:f8f0:614:1::1274:44.2309: Flags [S], seq 4140354248, win 65280, options [mss 1360,sackOK,TS val 1089390879 ecr 0,nop,wscale 7], length 0 15:18:29.166704 wg0 In IP6 fd42:42:42::2.33414 > 2607:f8f0:614:1::1274:44.2309: Flags [S], seq 4140354248, win 65280, options [mss 1360,sackOK,TS val 1089391898 ecr 0,nop,wscale 7], length 0 15:18:29.166719 eth0 Out IP6 fd42:42:42::2.33414 > 2607:f8f0:614:1::1274:44.2309: Flags [S], seq 4140354248, win 65280, options [mss 1360,sackOK,TS val 1089391898 ecr 0,nop,wscale 7], length 0 15:18:31.182594 wg0 In IP6 fd42:42:42::2.33414 > 2607:f8f0:614:1::1274:44.2309: Flags [S], seq 4140354248, win 65280, options [mss 1360,sackOK,TS val 1089393914 ecr 0,nop,wscale 7], length 0 15:18:31.182612 eth0 Out IP6 fd42:42:42::2.33414 > 2607:f8f0:614:1::1274:44.2309: Flags [S], seq 4140354248, win 65280, options [mss 1360,sackOK,TS val 1089393914 ecr 0,nop,wscale 7], length 0 15:18:35.278501 wg0 In IP6 fd42:42:42::2.33414 > 2607:f8f0:614:1::1274:44.2309: Flags [S], seq 4140354248, win 65280, options [mss 1360,sackOK,TS val 1089398010 ecr 0,nop,wscale 7], length 0 15:18:35.278521 eth0 Out IP6 fd42:42:42::2.33414 > 2607:f8f0:614:1::1274:44.2309: Flags [S], seq 4140354248, win 65280, options [mss 1360,sackOK,TS val 1089398010 ecr 0,nop,wscale 7], length 0
Re: update krijg Wireguard niet naar verwachting aan de gang met IPv6
Dank voor het geduld en meedenken On 25 September 2021 23:24 Geert Stappers, wrote: > On Sat, Sep 25, 2021 at 09:04:26AM +0200, Gijs Hillenius wrote: >> Goedenmorgen! >> >> Tijd voor een update. Er zit een (klein) beetje schot in, maar ik ben er >> nog niet. >> >> /me veegt lei schoon, huidige configuratie onderaan. >> >> >> A) IPv4 lijkt het te doen. >> >> Met ping4 kom ik voorbij de server. En, ik kan (als voorbeeld) met ssh >> -4 een-vri...@shell.xs4all.nl bereiken, en dan toont het me dat ik kom >> vanaf 144.76.204.189, zoals de bedoeling is. >> >> Mijn conclusie: masquerading werkt, >> en de firewalld doet zijn werk. Voor IPv4. > > Ja, er zal sprake zijn van masquerading. > Waar het gebeurd heeft het verhaal nog niet vertelt. > Is het misschien iets wat "ADSL modem router" doet? Goede vraag. Belgacom/Proximus doet inderdaad NAT voor IPv4 en IPv6, en roteert (ongeveer 1 keer per jaar) de IP addressen. Als ik op de client Wireguard *niet* aanzet, dan is het antwoord van ssh -4 shell.xs4all.nl dat het verkeert komt vanaf 109.146.128.183 zet ik Wireguard aan, dan komt het dus van mijn servertje. >> b) IPv6 gaat gedeeltelijk goed. >> >> Zowel client en server kan ik nu heen en weer met ping6 bereiken. Maar >> ik kom niet vanaf de client voorbij de server, niet met ping6, maar ook >> niet met ssh. Bijvoorbeeld >> >> ssh -6 weer-die-vri...@shell.xs4all.nl >> (knip) >> debug1: Connecting to shell.xs4all.nl [2001:888:0:1::9] port 22. >> >> en dan stilte, tot ik ^C doe. > > Er zal ook masquerading nodig zijn. Dan wel iets anders zodat "local > addresses" ( fc80:: ) niet meer lokale adressen zijn. > > > > >> De configuratie van de client - let op, er staan twee mogelijke IPv[4,6] >> reeksen, ze doen het beiden (niet tegelijk, uiteraard). >> >> , >> | [Interface] >> | Address= 10.93.15.2/24, fc80::b85f:d925:971e:110f/64 >> | # een alternatief, werkt ook: Address = 10.66.66.2/24,fd42:42:42::2/64 >> | PrivateKey = >> | >> | [Peer] >> | PublicKey = P3GrgaFCxj6gc6CnOUPo8vxBtKaOcKa7wa8LoL1oUl0= >> | Endpoint = [2a01:4f8:200:546b::9e15:1]:51820 >> | AllowedIPs = 0.0.0.0/0, ::/0 >> | PersistentKeepalive = 25 >> ` >> >> en die van de server: >> >> , >> | Interface] >> | Address = 10.93.15.1/24, fc80::b85f:d925:971e:109f/64 >> | # alternatief, ook goed: Address = 10.66.66.1/24,fd42:42:42::1/64 >> | PrivateKey = >> | ListenPort = 51820 >> | >> | [Peer] >> | PublicKey = nRwfI98C+AFDaLZuaF1i7YWrj7yQDHrQO07XvivGn2U= >> | # alternatief: AllowedIPs = 10.66.66.2/32,fd42:42:42::2/128 >> | AllowedIPs = 10.93.15.2/32, fc80::b85f:d925:971e:110f/128 >> ` >> >> In de spaarzame vrije tijd heb ik van alles nagelopen. >> > ... IPv4 ... >> >> Dan spelde ik https://wiki.debian.org/NetworkConfiguration: mist mijn >> static configured ethernet device (die van de oops) soms "accept_ra 2" >> (ik begrijp het helaas nog niet helemaal) >> >> sysctl net.ipv6.conf.all.accept_ra=2 getest >> >> Maar het maakt voor WireGuard niets uit. >> >> Ik zie ook /niets/ relevants in de logs (mezelf kennende zal het er toch >> wel staan). >> >> Hier een paar van de huidige IPv6 instellingen op de server: >> >> sysctl -a | grep -E 'ipv6.*\.(forwarding|accept_ra) =' >> net.ipv6.conf.all.accept_ra = 1 >> net.ipv6.conf.all.forwarding = 1 >> net.ipv6.conf.default.accept_ra = 1 >> net.ipv6.conf.default.forwarding = 1 >> net.ipv6.conf.eth0.accept_ra = 0 >> net.ipv6.conf.eth0.forwarding = 1 >> net.ipv6.conf.lo.accept_ra = 1 >> net.ipv6.conf.lo.forwarding = 1 >> net.ipv6.conf.wg0.accept_ra = 1 >> net.ipv6.conf.wg0.forwarding = 1 > > > Met de diverse 'forwarding = 1' ben ik het mee eens. > > Wat ik hier van de "accept router advertizing" moet vinden, > weet ik nog niet. > > > >> Waarom doe ik al die moeite om Wireguard ook via IPv6 te doen? Tja: ik >> wil het gewoon in orde hebben, het is net als het strijken van je >> overhemden. In België wordt IPv6 gewoon goed ondersteund, het werkt goed >> op mijn LAN, het doet het uitstekend in Debian. WireGuard kan het, dus >> waarom zou ik het niet doen? > > Met alle respect: "Your logic is flawed" ... zeer wel mogelijk > Weet dat ik het ook een uitdagend probleem vind. > Mijn insteek is wel "Waar gaat het kapot?" (vermoeden: Geen NAT) > > Gijs zijn insteek is meer "Hoe krijg ik het werkend?&q
update (nog geen fix) Re: krijg Wireguard niet naar verwachting aan de gang met IPv6
Goedenmorgen! Tijd voor een update. Er zit een (klein) beetje schot in, maar ik ben er nog niet. /me veegt lei schoon, huidige configuratie onderaan. Vraag: Hoe tover ik op de wireguard server informatie tevoorschijn die toont waarom het IPv6 verkeer stopt bij de server. Iemand suggesties? Tips zijn (zeer) welkom! A) IPv4 lijkt het te doen. Met ping4 kom ik voorbij de server. En, ik kan (als voorbeeld) met ssh -4 een-vri...@shell.xs4all.nl bereiken, en dan toont het me dat ik kom vanaf 144.76.204.189, zoals de bedoeling is. Mijn conclusie: masquerading werkt, en de firewalld doet zijn werk. Voor IPv4. b) IPv6 gaat gedeeltelijk goed. Zowel client en server kan ik nu heen en weer met ping6 bereiken. Maar ik kom niet vanaf de client voorbij de server, niet met ping6, maar ook niet met ssh. Bijvoorbeeld ssh -6 weer-die-vri...@shell.xs4all.nl (knip) debug1: Connecting to shell.xs4all.nl [2001:888:0:1::9] port 22. en dan stilte, tot ik ^C doe. De configuratie van de client - let op, er staan twee mogelijke IPv[4,6] reeksen, ze doen het beiden (niet tegelijk, uiteraard). , | [Interface] | Address= 10.93.15.2/24, fc80::b85f:d925:971e:110f/64 | # een alternatief, werkt ook: Address = 10.66.66.2/24,fd42:42:42::2/64 | PrivateKey = | | [Peer] | PublicKey = P3GrgaFCxj6gc6CnOUPo8vxBtKaOcKa7wa8LoL1oUl0= | Endpoint = [2a01:4f8:200:546b::9e15:1]:51820 | AllowedIPs = 0.0.0.0/0, ::/0 | PersistentKeepalive = 25 ` en die van de server: , | Interface] | Address = 10.93.15.1/24, fc80::b85f:d925:971e:109f/64 | # alternatief, ook goed: Address = 10.66.66.1/24,fd42:42:42::1/64 | PrivateKey = | ListenPort = 51820 | | [Peer] | PublicKey = nRwfI98C+AFDaLZuaF1i7YWrj7yQDHrQO07XvivGn2U= | # alternatief: AllowedIPs = 10.66.66.2/32,fd42:42:42::2/128 | AllowedIPs = 10.93.15.2/32, fc80::b85f:d925:971e:110f/128 ` In de spaarzame vrije tijd heb ik van alles nagelopen. Ik heb bijvoorbeeld last van een kernel oops, getrigged door ip4/ip_forward, de logs roepen dan: "netdevice: eth0: failed to disable LRO!: Daar wordt aan gewerkt: https://www.mail-archive.com/virtualization@lists.linux-foundation.org/msg48170.html Ik kan niet zien of het iets met IPv6 forwarding te maken heeft. Dan spelde ik https://wiki.debian.org/NetworkConfiguration: mist mijn static configured ethernet device (die van de oops) soms "accept_ra 2" (ik begrijp het helaas nog niet helemaal) sysctl net.ipv6.conf.all.accept_ra=2 getest Maar het maakt voor WireGuard niets uit. Ik zie ook /niets/ relevants in de logs (mezelf kennende zal het er toch wel staan). Hier een paar van de huidige IPv6 instellingen op de server: sysctl -a | grep -E 'ipv6.*\.(forwarding|accept_ra) =' net.ipv6.conf.all.accept_ra = 1 net.ipv6.conf.all.forwarding = 1 net.ipv6.conf.default.accept_ra = 1 net.ipv6.conf.default.forwarding = 1 net.ipv6.conf.eth0.accept_ra = 0 net.ipv6.conf.eth0.forwarding = 1 net.ipv6.conf.lo.accept_ra = 1 net.ipv6.conf.lo.forwarding = 1 net.ipv6.conf.wg0.accept_ra = 1 net.ipv6.conf.wg0.forwarding = 1 Waarom doe ik al die moeite om Wireguard ook via IPv6 te doen? Tja: ik wil het gewoon in orde hebben, het is net als het strijken van je overhemden. In België wordt IPv6 gewoon goed ondersteund, het werkt goed op mijn LAN, het doet het uitstekend in Debian. WireGuard kan het, dus waarom zou ik het niet doen? op de server: ip -6 route , | ::1 dev lo proto kernel metric 256 pref medium | 2a01:4f8:200:546b::/64 dev eth0 proto kernel metric 256 pref medium | fd42:42:42::/64 dev wg0 proto kernel metric 256 pref medium | fe80::/64 dev eth0 proto kernel metric 256 pref medium | default via 2a01:4f8:200:546b::3 dev eth0 metric 1024 onlink pref medium ` Mij valt op dat ssh -6 hierboven wel weet welk IP address ie moet hebben. /etc/resolf.conf op de server (wg0 is up) nameserver 2606:4700:4700:: nameserver 1.1.1.1 op de client (wg0 is eveneens up) search home nameserver 192.168.1.1 dank voor de aandacht!
Re: krijg Wireguard niet naar verwachting aan de gang met IPv6
On 19 September wilden Paul en Geert >> On Sun, Sep 19, 2021 at 10:03:28AM +0200, Gijs Hillenius wrote: >>> >>> en ping4 en ping6 vallen nu beiden stil (!) >>> >> ... resultaat van `ping4 -c 3` en `ping6 -c 3` ... >>> >>> Lijkt me dat ik op de goede weg ben. >>> >> Ja. >> Doe ook ping testen binnen het VPN. >> En dan gewoon het Virtual Private Network gebruiken. > > Precies, ping eens naar 10.93.15.1 en 2a01:4f8:200:546b:0:9e15:9e15:1 . Er gaat geen pakket de deur uit! ping 10.93.15.1 PING 10.93.15.1 (10.93.15.1) 56(84) bytes of data. ^C --- 10.93.15.1 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1011ms root@inauditus:~# ping4 10.93.15.1 PING 10.93.15.1 (10.93.15.1) 56(84) bytes of data. ^C --- 10.93.15.1 ping statistics --- 9 packets transmitted, 0 received, 100% packet loss, time 8178ms root@inauditus:~# ping6 2a01:4f8:200:546b:0:9e15:9e15:1 PING 2a01:4f8:200:546b:0:9e15:9e15:1(2a01:4f8:200:546b:0:9e15:9e15:1) 56 data bytes ^C --- 2a01:4f8:200:546b:0:9e15:9e15:1 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4075ms onderstaande is met wg0 up op client en server op de server route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 10.219.216.14 0.0.0.0 UG0 00 eth0 10.93.15.0 0.0.0.0 255.255.255.0 U 0 00 wg0 10.219.216.14 0.0.0.0 255.255.255.255 UH0 00 eth0 route -A inet6 Kernel IPv6 routing table DestinationNext Hop Flag Met Ref Use If localhost/128 [::] U256 2 0 lo 2a01:4f8:200:546b::/64 [::] U256 1 0 eth0 2a01:4f8:200:546b::/64 [::] U256 1 0 wg0 fe80::/64 [::] U256 1 0 eth0 [::]/0 2a01:4f8:200:546b::3 UGH 1024 3 0 eth0 localhost/128 [::] Un 0 4 0 lo 2a01:4f8:200:546b::/128[::] Un 0 3 0 eth0 2a01:4f8:200:546b::/128[::] Un 0 3 0 wg0 hillenius.com/128 [::] Un 0 5 0 eth0 2a01:4f8:200:546b:0:9e15:9e15:1/128 [::] Un 0 2 0 wg0 fe80::/128 [::] Un 0 3 0 eth0 fe80::5054:ff:fe49:7447/128[::] Un 0 4 0 eth0 ff00::/8 [::] U256 3 0 eth0 ff00::/8 [::] U256 1 0 wg0 [::]/0 [::] !n -1 1 0 lo op de client route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG60000 wlp0s20f3 10.93.15.0 0.0.0.0 255.255.255.0 U 0 00 wg0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 00 wlp0s20f3 192.168.1.0 0.0.0.0 255.255.255.0 U 60000 wlp0s20f3 route -A inet6 Kernel IPv6 routing table DestinationNext Hop Flag Met Ref Use If [::]/0 [::] U1024 9 0 wg0 localhost/128 [::] U256 2 0 lo 2a01:4f8:200:546b::/64 [::] U256 4 0 wg0 2a02:a03f:6b2d:b400::/64 [::] U600 1 0 wlp0s20f3 2a02:a03f:6b2d:b400::/56 _gateway UG 600 2 0 wlp0s20f3 fe80::/64 [::] U600 1 0 wlp0s20f3 [::]/0 _gateway UG 600 9 0 wlp0s20f3 localhost/128 [::] Un 0 11 0 lo inauditus/128 [::] Un 0 2 0 wg0 inauditus/128 [::] Un 0 4 0 wlp0s20f3 inauditus/128 [::] Un 0 3 0 wlp0s20f3 ff00::/8 [::] U256 10 0 wlp0s20f3 ff00::/8 [::] U256 1 0 wg0 [::]/0 [::] !n -1 1 0 lo
Re: krijg Wireguard niet naar verwachting aan de gang met IPv6
Goedenmorgen! [...] knip >> >> Iets om te proberen: >> Onder 2a01:4f8:200:546b/64 bijvoorbeeld 2a01:4f8:200:546b:4653/80 >> hangen. Aan wireguard server geef je 2a01:4f8:200:546b:4653::1 >> Aan wireguard client geef je 2a01:4f8:200:546b:4653::2 [2] Ik ben een stapje verder, hoop ik. Dank zover voor de assistentie. Teruggezocht welk IPv6 addressen ik voorhanden had toen ik nog openvpn gebruikte. Zoals gezegd, OpenVPN werkte niet meer na de overstap naar Bullseye. Ik neem de IPv6 addressen over van de openvpn configuratie. Weet niet zeker of ik dat goed doe. Ik heb nu wg0.conf op de client: , | [Interface] | Address= 10.93.15.2/24, 2a01:4f8:200:546b:0:9e15:9e15:2/64 | PrivateKey = | | [Peer] | PublicKey = P3GrgaFCxj6gc6CnOUPo8vxBtKaOcKa7wa8LoL1oUl0= | Endpoint = [2a01:4f8:200:546b::9e15:1]:51820 | AllowedIPs = 0.0.0.0/0, ::/0 | | PersistentKeepalive = 25 ` en op de server , | [Interface] | Address = 10.93.15.1/24, 2a01:4f8:200:546b:0:9e15:9e15:1/64 | PrivateKey = | ListenPort = 51820 | | [Peer] | PublicKey = nRwfI98C+AFDaLZuaF1i7YWrj7yQDHrQO07XvivGn2U= | AllowedIPs = 10.93.15.2/32, 2a01:4f8:200:546b:0:9e15:9e15:2/128 ` als ik nu beiden aanzet: client: wg-quick up wg0 [#] ip link add wg0 type wireguard [#] wg setconf wg0 /dev/fd/63 [#] ip -4 address add 10.93.15.2/24 dev wg0 [#] ip -6 address add 2a01:4f8:200:546b:0:9e15:9e15:2/64 dev wg0 [#] ip link set mtu 1420 up dev wg0 [#] wg set wg0 fwmark 51820 [#] ip -6 route add ::/0 dev wg0 table 51820 [#] ip -6 rule add not fwmark 51820 table 51820 [#] ip -6 rule add table main suppress_prefixlength 0 [#] ip6tables-restore -n [#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820 [#] ip -4 rule add not fwmark 51820 table 51820 [#] ip -4 rule add table main suppress_prefixlength 0 [#] sysctl -q net.ipv4.conf.all.src_valid_mark=1 [#] iptables-restore -n server: wg-quick up wg0 [#] ip link add wg0 type wireguard [#] wg setconf wg0 /dev/fd/63 [#] ip -4 address add 10.93.15.1/24 dev wg0 [#] ip -6 address add 2a01:4f8:200:546b:0:9e15:9e15:1/64 dev wg0 [#] ip link set mtu 1420 up dev wg0 en ping4 en ping6 vallen nu beiden stil (!) ping4 ping.xs4all.nl PING (194.109.6.8) 56(84) bytes of data. ^C --- ping statistics --- 9 packets transmitted, 0 received, 100% packet loss, time 8186ms root@inauditus:/etc/wireguard# ping6 ping.xs4all.nl PING ping.xs4all.nl(ping.xs4all.nl (2001:888:0:5::1)) 56 data bytes ^C --- ping.xs4all.nl ping statistics --- 8 packets transmitted, 0 received, 100% packet loss, time 7147ms Lijkt me dat ik op de goede weg ben.
Re: krijg Wireguard niet naar verwachting aan de gang met IPv6
OW! Dommoor - ik maakte een fout in de wg0.conf op de server, vergat er de AllowedIPs reeks aan te passen. Als ik dat alsnog doe: AllowedIPs = 10.93.15.2/32, 2a01:4f8:200:546b:4653::2/128 (waarom /128, overigens?) blijft de client klagen: wg-quick up wg0 [#] ip link add wg0 type wireguard [#] wg setconf wg0 /dev/fd/63 [#] ip -4 address add 10.93.15.2/24 dev wg0 [#] ip -6 address add 2a01:4f8:200:546b:4653::2/64 dev wg0 RTNETLINK answers: Network is unreachable nog meer data: ifconfig als wg0 aan is op de server wg0: flags=209 mtu 1420 inet 10.93.15.1 netmask 255.255.255.0 destination 10.93.15.1 inet6 2a01:4f8:200:546b:4653::1 prefixlen 64 scopeid 0x0 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 On 18 September 2021 17:19 Gijs Hillenius, wrote: > On 18 September 2021 10:48 Geert Stappers, wrote: > >> On Sat, Sep 18, 2021 at 09:42:13AM +0200, Geert Stappers wrote: >>> On Sat, Sep 18, 2021 at 08:51:32AM +0200, Gijs Hillenius wrote: >> [...] knip >>> > client >>> > , >>> > | [Interface] >>> > | Address = 10.93.15.2/24, fdab:9205:cf78:f608::2/64 >>> > | PrivateKey = >>> > | >>> > >> >>> > >>> > en dan testen met ping >>> > ping6 ping.xs4all.nl >>> > PING ping.xs4all.nl(ping.xs4all.nl (2001:888:0:5::1)) 56 data bytes >>> > ^C >>> > --- ping.xs4all.nl ping statistics --- >>> > 5 packets transmitted, 0 received, 100% packet loss, time 4077ms >>> > >> >> Netwerkpakketten vanaf fdab:9205:cf78:f608::2 bereiken >> misschien wel 2001:888:0:5::1, maar pakketen van 2001:888:0:5::1 >> vinden niet hun weg terug naar fdab:9205:cf78:f608::2. >> >> [1] >> >> Iets om te proberen: >> Onder 2a01:4f8:200:546b/64 bijvoorbeeld 2a01:4f8:200:546b:4653/80 >> hangen. Aan wireguard server geef je 2a01:4f8:200:546b:4653::1 >> Aan wireguard client geef je 2a01:4f8:200:546b:4653::2 [2] > > > Met andere woorden, je wilt dat ik dit probeer. (spoiler: het wil niet, > zie onder) > > > wg0 op de client > > , > | [Interface] > | Address= 10.93.15.2/24, 2a01:4f8:200:546b:4653::2/64 > | PrivateKey = > | > | [Peer] > | PublicKey = P3GrgaFCxj6gc6CnOUPo8vxBtKaOcKa7wa8LoL1oUl0= > | Endpoint = [2a01:4f8:200:546b::9e15:1]:51820 > | AllowedIPs = 0.0.0.0/0, ::/0 > | > | PersistentKeepalive = 25 > ` > > wg0 op de server > > , > | [Interface] > | Address = 10.93.15.1/24, 2a01:4f8:200:546b:4653::1/64 > | PrivateKey = > | ListenPort = 51820 > | > | [Peer] > | PublicKey = nRwfI98C+AFDaLZuaF1i7YWrj7yQDHrQO07XvivGn2U= > | AllowedIPs = 10.93.15.2/32, fdab:9205:cf78:f608::2/128 > ` > > Beiden aangezet, maar de client moppert meteen: > > server > > wg-quick up wg0 > [#] ip link add wg0 type wireguard > [#] wg setconf wg0 /dev/fd/63 > [#] ip -4 address add 10.93.15.1/24 dev wg0 > [#] ip -6 address add 2a01:4f8:200:546b:4653::1/64 dev wg0 > [#] ip link set mtu 1420 up dev wg0 > [#] ip -6 route add fdab:9205:cf78:f608::2/128 dev wg0 > > > dan de client: > > wg-quick up wg0 > [#] ip link add wg0 type wireguard > [#] wg setconf wg0 /dev/fd/63 > [#] ip -4 address add 10.93.15.2/24 dev wg0 > [#] ip -6 address add 2a01:4f8:200:546b:4653::2/64 dev wg0 > RTNETLINK answers: Network is unreachable > [#] ip link set mtu 1420 up dev wg0 > [#] wg set wg0 fwmark 51820 > [#] ip -6 route add ::/0 dev wg0 table 51820 > [#] ip -6 rule add not fwmark 51820 table 51820 > [#] ip -6 rule add table main suppress_prefixlength 0 > [#] ip6tables-restore -n > [#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820 > [#] ip -4 rule add not fwmark 51820 table 51820 > [#] ip -4 rule add table main suppress_prefixlength 0 > [#] sysctl -q net.ipv4.conf.all.src_valid_mark=1 > [#] iptables-restore -n > > Network unreachable, maar eigenwijs toch ping6 geprobeerd: > > ping6 ping.xs4all.nl > PING ping.xs4all.nl(ping.xs4all.nl (2001:888:0:5::1)) 56 data bytes > ^C > --- ping.xs4all.nl ping statistics --- > 13 packets transmitted, 0 received, 100% packet loss, time 12294ms > > -- I've no idea when Linus is going to release 2.0.24, but if he takes too long Im going to release a 2.0.24unoff and he can sound off all he likes. -- Alan Cox
Re: krijg Wireguard niet naar verwachting aan de gang met IPv6
On 18 September 2021 10:48 Geert Stappers, wrote: > On Sat, Sep 18, 2021 at 09:42:13AM +0200, Geert Stappers wrote: >> On Sat, Sep 18, 2021 at 08:51:32AM +0200, Gijs Hillenius wrote: > [...] knip >> > client >> > , >> > | [Interface] >> > | Address = 10.93.15.2/24, fdab:9205:cf78:f608::2/64 >> > | PrivateKey = >> > | >> > > >> > >> > en dan testen met ping >> > ping6 ping.xs4all.nl >> > PING ping.xs4all.nl(ping.xs4all.nl (2001:888:0:5::1)) 56 data bytes >> > ^C >> > --- ping.xs4all.nl ping statistics --- >> > 5 packets transmitted, 0 received, 100% packet loss, time 4077ms >> > > > Netwerkpakketten vanaf fdab:9205:cf78:f608::2 bereiken > misschien wel 2001:888:0:5::1, maar pakketen van 2001:888:0:5::1 > vinden niet hun weg terug naar fdab:9205:cf78:f608::2. > > [1] > > Iets om te proberen: > Onder 2a01:4f8:200:546b/64 bijvoorbeeld 2a01:4f8:200:546b:4653/80 > hangen. Aan wireguard server geef je 2a01:4f8:200:546b:4653::1 > Aan wireguard client geef je 2a01:4f8:200:546b:4653::2 [2] Met andere woorden, je wilt dat ik dit probeer. (spoiler: het wil niet, zie onder) wg0 op de client , | [Interface] | Address= 10.93.15.2/24, 2a01:4f8:200:546b:4653::2/64 | PrivateKey = | | [Peer] | PublicKey = P3GrgaFCxj6gc6CnOUPo8vxBtKaOcKa7wa8LoL1oUl0= | Endpoint = [2a01:4f8:200:546b::9e15:1]:51820 | AllowedIPs = 0.0.0.0/0, ::/0 | | PersistentKeepalive = 25 ` wg0 op de server , | [Interface] | Address = 10.93.15.1/24, 2a01:4f8:200:546b:4653::1/64 | PrivateKey = | ListenPort = 51820 | | [Peer] | PublicKey = nRwfI98C+AFDaLZuaF1i7YWrj7yQDHrQO07XvivGn2U= | AllowedIPs = 10.93.15.2/32, fdab:9205:cf78:f608::2/128 ` Beiden aangezet, maar de client moppert meteen: server wg-quick up wg0 [#] ip link add wg0 type wireguard [#] wg setconf wg0 /dev/fd/63 [#] ip -4 address add 10.93.15.1/24 dev wg0 [#] ip -6 address add 2a01:4f8:200:546b:4653::1/64 dev wg0 [#] ip link set mtu 1420 up dev wg0 [#] ip -6 route add fdab:9205:cf78:f608::2/128 dev wg0 dan de client: wg-quick up wg0 [#] ip link add wg0 type wireguard [#] wg setconf wg0 /dev/fd/63 [#] ip -4 address add 10.93.15.2/24 dev wg0 [#] ip -6 address add 2a01:4f8:200:546b:4653::2/64 dev wg0 RTNETLINK answers: Network is unreachable [#] ip link set mtu 1420 up dev wg0 [#] wg set wg0 fwmark 51820 [#] ip -6 route add ::/0 dev wg0 table 51820 [#] ip -6 rule add not fwmark 51820 table 51820 [#] ip -6 rule add table main suppress_prefixlength 0 [#] ip6tables-restore -n [#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820 [#] ip -4 rule add not fwmark 51820 table 51820 [#] ip -4 rule add table main suppress_prefixlength 0 [#] sysctl -q net.ipv4.conf.all.src_valid_mark=1 [#] iptables-restore -n Network unreachable, maar eigenwijs toch ping6 geprobeerd: ping6 ping.xs4all.nl PING ping.xs4all.nl(ping.xs4all.nl (2001:888:0:5::1)) 56 data bytes ^C --- ping.xs4all.nl ping statistics --- 13 packets transmitted, 0 received, 100% packet loss, time 12294ms
Re: krijg Wireguard niet aan de gang met IPv6
[...] knip >> >> Op IRC werd ik gewezen op een bug: >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993716 > > Package: bridge-utils > Titel: IPv6 network bridge fails after upgrading Buster to Bullseye > >> ik ben er nog niet helemaal zeker van of dat is wat me hier overkomt. > > Mijn inschatting is van niet. > > > In configuration van de client staat "ListenPort = 21841". > Er is geen reden voor de client om te luisteren. Ow! Da's alvast een ding! En ik maar braaf internethandleidingen volgen. > Althans niet in de set-up die ik succesvol ingebruik heb. huidige confs: (ik laat de regels met comments weg). client , | [Interface] | Address = 10.93.15.2/24, fdab:9205:cf78:f608::2/64 | PrivateKey = | | [Peer] | PublicKey = P3GrgaFCxj6gc6CnOUPo8vxBtKaOcKa7wa8LoL1oUl0= | Endpoint = [2a01:4f8:200:546b::9e15:1]:51820 | AllowedIPs = 0.0.0.0/0, ::/0 | | PersistentKeepalive = 25 ` server , | [Interface] | Address = 10.93.15.1/24, fdab:9205:cf78:f608::1/64 | PrivateKey = | ListenPort = 51820 | | [Peer] | PublicKey = nRwfI98C+AFDaLZuaF1i7YWrj7yQDHrQO07XvivGn2U= | AllowedIPs = 10.93.15.2/32, fdab:9205:cf78:f608::2/128 ` > > De client configuratie regel > Endpoint = 2a01:4f8:200:546b::9e15:1:51820 > vind ik erg vreemd. Helemaal mee eens! Ik was (gewoon) onder de indruk van software die al die : uit elkaar wist te houden. > Mijn (te korte??) websearch leverde > geen voorbeeld op dat het zo zou kunnen werken. > > Een websearch op "IPv6 port syntax" > ( https://duckduckgo.com/?q=IPv6+port+syntax ) > leert dat > Endpoint = [2a01:4f8:200:546b::9e15:1]:51820 > een grotere kans van slagen heeft. Eveneens aangepast. Maar ik ben er nog niet. > Hoe er rekening mee dat na die twee veranderingen > het geheel nog niet compleet hoeft te zijn. > In dat geval a.u.b. de bijgewerkte versie van beide configuraties laten > zien, alleen de Private key verborgen, de Public keys wel laten zien. ook > de output van `sudo wg` van beide kanten. De `wg` output in zijn geheel > laten zien, want de private key wordt verborgen gehouden. > Plus wat tekst hoe het kapot gaat danwel wat er zou moeten werken > maar dat net niet doet. Op de client dee ik net: wg-quick up wg0 [#] ip link add wg0 type wireguard [#] wg setconf wg0 /dev/fd/63 [#] ip -4 address add 10.93.15.2/24 dev wg0 [#] ip -6 address add fdab:9205:cf78:f608::2/64 dev wg0 [#] ip link set mtu 1420 up dev wg0 [#] wg set wg0 fwmark 51820 [#] ip -6 route add ::/0 dev wg0 table 51820 [#] ip -6 rule add not fwmark 51820 table 51820 [#] ip -6 rule add table main suppress_prefixlength 0 [#] ip6tables-restore -n [#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820 [#] ip -4 rule add not fwmark 51820 table 51820 [#] ip -4 rule add table main suppress_prefixlength 0 [#] sysctl -q net.ipv4.conf.all.src_valid_mark=1 [#] iptables-restore -n en dan testen met ping ping6 ping.xs4all.nl PING ping.xs4all.nl(ping.xs4all.nl (2001:888:0:5::1)) 56 data bytes ^C --- ping.xs4all.nl ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4077ms ping4 ping.xs4all.nl PING (194.109.6.8) 56(84) bytes of data. 64 bytes from ping.xs4all.nl (194.109.6.8): icmp_seq=1 ttl=56 time=11.3 ms 64 bytes from ping.xs4all.nl (194.109.6.8): icmp_seq=2 ttl=56 time=11.3 ms Nog steeds op de client: /etc/wireguard# wg interface: wg0 public key: nRwfI98C+AFDaLZuaF1i7YWrj7yQDHrQO07XvivGn2U= private key: (hidden) listening port: 48540 fwmark: 0xca6c peer: endpoint: [2a01:4f8:200:546b::9e15:1]:51820 allowed ips: 0.0.0.0/0, ::/0 latest handshake: 4 seconds ago transfer: 11.93 KiB received, 24.81 KiB sent persistent keepalive: every 25 seconds Op de server: wg-quick up wg0 [#] ip link add wg0 type wireguard [#] wg setconf wg0 /dev/fd/63 [#] ip -4 address add 10.93.15.1/24 dev wg0 [#] ip -6 address add fdab:9205:cf78:f608::1/64 dev wg0 [#] ip link set mtu 1420 up dev wg0 Gek of niet? Di's veel korter dan op de client, niets over routes en sysctl als root, de output van wg interface: wg0 public key: P3GrgaFCxj6gc6CnOUPo8vxBtKaOcKa7wa8LoL1oUl0= private key: (hidden) listening port: 51820 peer: endpoint: [2a02:a03f:6b2d:b400:5fb2:6d1d:1a9a:dc69]:48540 allowed ips: 10.93.15.2/32, fdab:9205:cf78:f608::2/128 latest handshake: 50 seconds ago transfer: 106.50 KiB received, 249.61 KiB sent ^^^ die received sent cijfers groeien als ik ping4 doe. Ze groeien OOK als ik ping6 doe.
Re: krijg Wireguard niet aan de gang met IPv6
On 17 September 2021 11:02 Martijn van de Streek, wrote: > Gijs Hillenius schreef op vr 17-09-2021 om 08:41 [+0200]: >> Goedenmorgen >> >> Mijn servertje ging van Debian 10 naar 11, en OpenVPN stopte met >> werken. (iets met IPv6, dacht ik, maar niet goed gekeken). Geen punt >> want ik wilde toch al naar Wireguard. >> >> Ik krijg het aan de gang via IPv4, maar niet IPv6. Forwarding wil >> niet? >> Gebruik ik de verkeerde IPv6 reeks? Maak ik een tikfout? Is het iets >> met >> IPv6 in Bullseye? internetspeurtochten leveren aanwijzingen voor van >> alles. > > [knip] > >> Als iemand een tip heeft waar ik moet kijken, dank! > > Je zou eens kunnen kijken in /proc/sys/net/ipv6/conf/all/forwarding (of > die voor de specifieke interface(s) waartussen forwarding voor actief > moet zijn) > > Dat geeft soms een duidelijker antwoord dan verschillende firewall- > tools :) Dank! die ene forwarding staat toch echt aan. Op IRC werd ik gewezen op een bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993716 ik ben er nog niet helemaal zeker van of dat is wat me hier overkomt.
krijg Wireguard niet aan de gang met IPv6
Goedenmorgen Mijn servertje ging van Debian 10 naar 11, en OpenVPN stopte met werken. (iets met IPv6, dacht ik, maar niet goed gekeken). Geen punt want ik wilde toch al naar Wireguard. Ik krijg het aan de gang via IPv4, maar niet IPv6. Forwarding wil niet? Gebruik ik de verkeerde IPv6 reeks? Maak ik een tikfout? Is het iets met IPv6 in Bullseye? internetspeurtochten leveren aanwijzingen voor van alles. * configuratie client: --- [Interface] Address = 10.93.15.2/24, fdab:9205:cf78:f608::2/64 PrivateKey = ListenPort = 21841 [Peer] PublicKey = Endpoint = 2a01:4f8:200:546b::9e15:1:51820 AllowedIPs = 0.0.0.0/0, ::/0 # This is for if you're behind a NAT and # want the connection to be kept alive. PersistentKeepalive = 25 --- * configuratie server --- [Interface] Address = 10.93.15.1/24, fdab:9205:cf78:f608::1/64 PrivateKey = ListenPort = 51820 [Peer] PublicKey = AllowedIPs = 10.93.15.2/32, fdab:9205:cf78:f608::2/128 -- in sysctrl.conf: net.ipv6.conf.all.forwarding=1 firewalld: masquerade: yes forward: no <--- is dat het? of ligt het aan de opzet: ik gebruik nu wg-quick up wg0 op zowel server als client, ik las op de Debian wikis dat dit de route-tabellen verandert? Als iemand een tip heeft waar ik moet kijken, dank!
Re: Video wil niet afspelen
On 16 April 2021 10:51 Paul van der Vlis, wrote: > Hallo, > > Ik krijg bij een video de melding: > - > Kan bestand niet afspelen > video/x-asf-unknown decoder is vereist voor het afspelen van het > bestand, maar is niet geïnstalleerd. > - > > Iemand een idee hoe ik erachter kom wat er precies in die > asf-container zit? Andere .asf-bestanden kan ik wel afspelen. > > Het lijkt erop dat er iets nodig is als w64codecs. Heb ik geprobeerd > met mplayer maar de hele computer liep vast. Iemand hierover tips? openen met VLC ?
Re: foutgelopen update
On 10 February 2021 00:25 Geert Stappers, wrote: > On Tue, Feb 09, 2021 at 10:04:22PM +0100, Jean-Marie van den Steenhoven wrote: >> Hallo, >> >> Bij de laatste update van mijn Debian omgeving (Buster 10.8) is er iets >> misgegaan, waardoor Debian niet meer vanuit Grub opstart. (van >> 4.19.0-13-amd64 naar 4.19.0-14-amd64) >> >> Het probleem is dat in de boot dir initrd.img-4.19-0-14-amd ontbreekt en in >> het Grub-script de stap 'laden van de initiele RAM-schijf...' ontbreekt ( >> /initrd '/initrd.img-4.19.0-14-amd64). Opstarten van versie 13 lukt nog wel. >> >> Is er een procedure/tip om dit probleem op te lossen? >> >> De bootdisk is bijna vol (geen ruimte meer voor een extra initrd.img) en >> bevat versie 10 t/m 13. > > > Opstarten van 13 > Versie 10 11 en 12 verwijderen om ruimte op bootdisk te krijgen dat ^^^ doe je middels apt autoremove > `apt install` inderdaad zonder package naam, het idee is dat > apt dan alles naloopt en herstelt wat hersteld moet worden.
Re: Opschonen /var/cache/apt/archives
On 5 November 2020 22:22 Cecil Westerhof, wrote: > Ik had een /var van 9.2G waarbij 8.5G werd gebruikt en 178M vrij was. > Het bleek dat /var/cache/apt/archives/ erg groot was: 2,4G. Ik > probeerde apt autoclean, maar dat had geen effect. Dus heb ik maar apt > clean gebruikt. Nu heb ik 6.0G gebruikt en is 2.8G vrij. > > Is dit normaal? etc/apt/apt.conf.d/ ik zou ergens kijken wat je hebt ingesteld: bijvoorbeeld: echo 'Binary::apt::APT::Keep-Downloaded-Packages "1";' | sudo tee /etc/apt/apt.conf.d/10apt-keep-downloads https://unix.stackexchange.com/questions/499035/disable-auto-clean-in-apt
Re: Kan screensaver settings niet openen
On 16 September 2020 21:49 Cecil Westerhof, wrote: > Ik werk met Debian 10 en Xfce. > Ik kan de xscreensaver settings niet aanpassen. > > Wanneer ik handmatig opstart: > xscreensaver-demo > > Dan krijg ik als melding: > (xscreensaver-demo:3604): libglade-WARNING **: 21:43:33.041: Could not > load support for `gnome': libgnome.so: cannot open shared object file: No > such file or directory > Aborted > > Echter op een ander Debian 10 systeem met Xfce krijg ik precies > dezelfde melding minus Aborted En kan ik zonder problemen de > instellingen van mijn screensaver aanpassen. > > Wat zou hier aan de hand kunnen zijn? Dit is wellicht te grof geschut: dpkg --get-selections vergelijken?
is alsa-ucm-conf een vereist pakket in Debian ... voor pulseaudio?
Goedenmorgen Weet iemand hier of alsa-ucm-conf per default geinstalleerd wordt op een verse Debian installatie voor de doorsnee desktop, bijvoorbeeld Gnome? En alsa-topology-conf? En alsa-utils? Dat waren de enige drie alsa- Debian pakketten op mijn laptop, ik heb ze verwijderd. Daarna gaf pavucontrol een compleet ander beeld van mijn geluidskaart. https://wiki.debian.org/PulseAudio vertelt me dat Pulse werkt 'on top of Alsa'. Dus ik vraag me nu af of er alsa-dingen vereist zijn. Dank Gijs Achterliggende vraag: ik kreeg de ingebouwde microfoon op de laptop niet aan de praat. Dat ding doet het nu (maar heel heel zachtjes). En verder is het nog steeds nogal een gehannes om de laptop te vertellen dat ie de ingebouwde speakers mag gebruiken, of de HDMI speakers, of de headset. De ene keer lukt het 'zomaar' de andere keer is er geen keuze te maken.
oplossing (soort van) (was: exim, spfquery, antwoord is altijd "none" (met lange uittro))
Nou, dan praat ik wel met mezelf ;-)
Dit is een soort van oplossing, maak expliciet dat je versie 1 van
spfquery wilt. En pas dan tegelijk even de syntax aan. Met die "-v 1"
optie komt het goede antwoord op de warn regel.
Nog beter zou zijn als ik die syntax aan versie 2 aanpas. Dat volgt, wellicht.
condition = ${run{/usr/bin/spfquery -v 1 --ip \"$sender_host_address\" -s
\"$sender_address\" --helo-id \"$sender_helo_name\"}\
{no}{${if eq {$runrc}{1}{yes}{no}}}}
On 17 June 2020 09:57 Gijs Hillenius, wrote:
> Goedenmorgen
>
> Is er hier iemand die Debian's Exim macro's kan spellen?
>
> Al jaren terug stelde ik de standaard regeltjes voor SPF in, maar het
> val me nu pas op dat de check altijd "none" oplevert.
>
> Kan iemand die regel met me meelezen? Is het omdat de query meer
> teruggeeft dan 1 woord? De query geeft 4 regels terug, maar de eerste
> regel is het "gezochte" antwoord.
>
> Hier het blok in exim4.conf.template
>
>
> # Use spfquery to perform a pair of SPF checks
> # This is quite costly in terms of DNS lookups (~6 lookups per mail). Do
> not
> # enable if that's an issue.
> # required:
> # apt install spf-tools-perl
> # and (for monolithic conf file, set CHECK_RCPT_SPF=true in
> exim4.conf.localmacros
> .ifdef CHECK_RCPT_SPF
> deny
> message = [SPF] $sender_host_address is not allowed to send mail from
> ${if def:sender_address_domain {$sender_address_domain}{$sender_helo_name}}.
> \
> Please check your SPF set-up
> log_message = SPF check failed.
> condition = ${run{/usr/bin/spfquery --ip \"$sender_host_address\"
> --mail-from \"$sender_address\" --helo \"$sender_helo_name\"}\
> {no}{${if eq {$runrc}{1}{yes}{no
>
> defer
> message = Temporary DNS error while checking SPF record. Try again later.
> condition = ${if eq {$runrc}{5}{yes}{no}}
>
> warn
> condition = ${if <={$runrc}{6}{yes}{no}}
> message = :at_start:Received-SPF: ${if eq {$runrc}{0}{pass}\
>{${if eq {$runrc}{2}{softfail}\
>{${if eq {$runrc}{3}{neutral}\
>{${if eq {$runrc}{4}{unknown}\
>{${if eq {$runrc}{6}{none}{error}\
>} client-ip=$sender_host_address; \
> ${if def:sender_address_domain \
>{envelope-from=${sender_address}; }{}}\
> helo=$sender_helo_name
>
> warn
> log_message = Unexpected error in SPF check.
> condition = ${if >{$runrc}{6}{yes}{no}}
> .endif
>
>
>
>
> En dan nog dit: Ik ben mijn SPF regeltjes aan het bijschaven.
>
> De afgelopen dagen geleerd dat Debian's versie van Exim nog geen SPF
> ondersteuning meelevert, maar Ubuntu wel. En ook dat Debian's Exim macro
> verwijst naar een externe tool die niet meer in Debian zit
> (libmail-spf-query-per ipv spf-tools-perl). Dit is al aangepast in de
> Wiki, gelukkig.
>
> Dat de standaard filter (uit spec.text.gz) verwijst naar
> http://www.openspf.org/Why?scope= ... die website is nu ongeveer 1,5
> jaar terug uit de lucht.
>
> Het commentaar hierboven verwijst daarom niet meer naar die SPF site; en
> da's ook verwijderd uit de deny regel.
>
> Ik voegde een :at_start: toe aan de warn regel, en ook een berichtje om
> te testen dat deze header echt het resultaat is van die warn check. Maar
> de if 0 if 2 if 3 levert altijd none als antwoord. Als ik de spfguery
> nakijk, voor bijvoorbeeld gmail, is het antwoord "pass".
>
--
It's amazing how many people you could be friends with if only they'd
make the first approach.
exim, spfquery, antwoord is altijd "none" (met lange uittro)
Goedenmorgen
Is er hier iemand die Debian's Exim macro's kan spellen?
Al jaren terug stelde ik de standaard regeltjes voor SPF in, maar het
val me nu pas op dat de check altijd "none" oplevert.
Kan iemand die regel met me meelezen? Is het omdat de query meer
teruggeeft dan 1 woord? De query geeft 4 regels terug, maar de eerste
regel is het "gezochte" antwoord.
Hier het blok in exim4.conf.template
# Use spfquery to perform a pair of SPF checks
# This is quite costly in terms of DNS lookups (~6 lookups per mail). Do not
# enable if that's an issue.
# required:
# apt install spf-tools-perl
# and (for monolithic conf file, set CHECK_RCPT_SPF=true in
exim4.conf.localmacros
.ifdef CHECK_RCPT_SPF
deny
message = [SPF] $sender_host_address is not allowed to send mail from ${if
def:sender_address_domain {$sender_address_domain}{$sender_helo_name}}. \
Please check your SPF set-up
log_message = SPF check failed.
condition = ${run{/usr/bin/spfquery --ip \"$sender_host_address\"
--mail-from \"$sender_address\" --helo \"$sender_helo_name\"}\
{no}{${if eq {$runrc}{1}{yes}{no
defer
message = Temporary DNS error while checking SPF record. Try again later.
condition = ${if eq {$runrc}{5}{yes}{no}}
warn
condition = ${if <={$runrc}{6}{yes}{no}}
message = :at_start:Received-SPF: ${if eq {$runrc}{0}{pass}\
{${if eq {$runrc}{2}{softfail}\
{${if eq {$runrc}{3}{neutral}\
{${if eq {$runrc}{4}{unknown}\
{${if eq {$runrc}{6}{none}{error}\
} client-ip=$sender_host_address; \
${if def:sender_address_domain \
{envelope-from=${sender_address}; }{}}\
helo=$sender_helo_name
warn
log_message = Unexpected error in SPF check.
condition = ${if >{$runrc}{6}{yes}{no}}
.endif
En dan nog dit: Ik ben mijn SPF regeltjes aan het bijschaven.
De afgelopen dagen geleerd dat Debian's versie van Exim nog geen SPF
ondersteuning meelevert, maar Ubuntu wel. En ook dat Debian's Exim macro
verwijst naar een externe tool die niet meer in Debian zit
(libmail-spf-query-per ipv spf-tools-perl). Dit is al aangepast in de
Wiki, gelukkig.
Dat de standaard filter (uit spec.text.gz) verwijst naar
http://www.openspf.org/Why?scope= ... die website is nu ongeveer 1,5
jaar terug uit de lucht.
Het commentaar hierboven verwijst daarom niet meer naar die SPF site; en
da's ook verwijderd uit de deny regel.
Ik voegde een :at_start: toe aan de warn regel, en ook een berichtje om
te testen dat deze header echt het resultaat is van die warn check. Maar
de if 0 if 2 if 3 levert altijd none als antwoord. Als ik de spfguery
nakijk, voor bijvoorbeeld gmail, is het antwoord "pass".
Re: linux-image
[...] > had per ongeluk de boot dir weggersync'd En de /var/cache/apt/archives is natuurlijk leeg. Ik herken het probleem. echo 'Binary::apt::APT::Keep-Downloaded-Packages "1";' | sudo tee /etc/apt/apt.conf.d/10apt-keep-downloads https://unix.stackexchange.com/questions/499035/disable-auto-clean-in-apt
Re: linux-image
On 27 May 2020 12:47 Richard Lucassen, wrote: > On Wed, 27 May 2020 11:58:23 +0200 > henk van ballegooijen wrote: > >> Moeten hier wel ergens te vinden zijn denk ik: >> >> https://snapshot.debian.org/ > > Idioot, had per ongeluk de boot dir weggersync'd, de laatste 5.6.0-1 > staat er inmiddels weer op, maar volgens het package management zit > deze er ook in: > > linux-image-5.5.0-2-amd64 > > maar die is in geen velden of wegen te bekennen. Zoek ik verkeerd of > zijn het de kaboutertjes? Van die twee is het de eerste optie, misschien. http://snapshot.debian.org/package/linux-signed-amd64/5.5.17%2B1/#linux-image-5.5.0-2-amd64_5.5.17-1
Re: Wetransfer of alternatief om bestanden via terminal te versturen.
>> > Er zijn verschillende online diensten zoals wetransfer.com die je >> > toelaten om bestanden met elkaar te delen. Op de website moet je >> > vervolgens je emailadres, ontvanger-email invullen en vervolgens het >> > bestand selecteren. Mijn vraag is: hoe kun je dit automatiseren zodat >> > alles vanuit terminal kan ingevoerd worden en in een script kan >> > geplaatst worden. >> >> Coquelicot > > https://coquelicot.potager.org/ sterker nog apt install coquelicot
Re: Wetransfer of alternatief om bestanden via terminal te versturen.
> Er zijn verschillende online diensten zoals wetransfer.com die je > toelaten om bestanden met elkaar te delen. Op de website moet je > vervolgens je emailadres, ontvanger-email invullen en vervolgens het > bestand selecteren. Mijn vraag is: hoe kun je dit automatiseren zodat > alles vanuit terminal kan ingevoerd worden en in een script kan > geplaatst worden. Coquelicot kan je het in eigen beheer doen, en het komt met een cli dingetje het wordt echter niet meer onderhouden
Re: Thunderbird reageert soms niet
On 5 February 2020 15:55 Paul van der Vlis, wrote: > Hoi, > > Heb sinds een paar dagen een raar probleem met Thunderbird. Het > reageert soms enige tijd niet. De machine heeft dan een hoge load, > Thunderbird op 100%. Andere applicaties reageren gewoon. Na een paar > minuten werkt alles weer goed en snel. zijstraatjes: - relatie met een of andere recente update (da's bij mij meestal het geval)? - IPv6 IPv4 timeout? - Laat TB iets nuttigs zien als je het vanaf de commandline start? - Iets te zien in de log van de mail server? - Wellicht de cache dir en of dirs opzij zetten?
nftables: van Strech naar Buster, firewall van iptables naar nftables
Hallo!
In de hoop dat de verzamelde kennis hier me een beetje op weg wil
helpen:
De overstap naar Debian 10 vraagt een nieuwe aanpak van de
firewall. De default iptables is vervangen door nftables. De firewall
die ik heb ondersteund nftables niet. Op dit moment doet de firewall het
wel voor IPv4 maar niet voor IPv6.
Ik kan iptables terugzetten. Of proberen snel naar nftables over te gaan.
Deze wiki bestudeerd: https://wiki.debian.org/nftables en diverse
voorbeelde bekeken. De huidige (...) iptables regels vertaalt (daar is
een script voor).
Ik heb nu een eerste set, maar die zit vol vragen.
Bijvoorbeeld de { en spaties: is het {80, 443} of moet het zijn { 80,
443 }, of is het identiek?
Ik zie voor poort 80 en 443 dit: ct state new,established. Waarom kom ik
dat tegen als advies voor die poorten, en niet voor bijvoorbeeld poort
25 (en anderen)?
Schrijfwijze, poort nummer of naam? Met een voorbeeld:
Is:
# HTTP (ports 80 & 443)
# tcp dport { http, https } accept
beter dan
# WWW server: count and accept traffic in 80/tcp and 443/tcp in new and
establised state
# nft add rule inet filter input tcp dport {80, 443} ct state new,established
counter accept comment "WWW"
Is het slim of overbodig om bij alle regels /comment/ te gebruiken?
(Zoals hierboven comment "www". Ik neem aan dat ik dat later in de logs
zie). Maar ik kijk niet echt vaak naar de logs.
Tot slot, wie weet hoe openvpn en nftables te combineren?
Hieronder mijn huidige klad nftables regels. Echt klad, en onbruikbaar.
# WARNING this is untested and not at all ready to be used
#
# verder te bekijken
# https://ral-arturo.org/2017/04/07/openvpn-debian-stretch.html
# De eerste 9 regels zijn gekopieerd uit een voorbeeld. Essentieel?
table inet filter {
chain input {
type filter hook input priority 0;
# accept any localhost traffic
iif lo accept
# accept traffic originated from us
ct state established,related accept
# de volgde regels kom ik her en der tegen, zie ook PING en PING alternatief
hieronder
# accept neighbour discovery otherwise connectivity breaks
ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit,
echo-request, nd-router-advert, nd-neighbor-advert } accept
# SSH server
nft add rule ip filter input tcp dport 22 ct state new counter
accept comment "SSH"
# is het {80, 443} of moet het zijn { 80, 443 }, of is het identiek?
# WWW server: count and accept traffic in 80/tcp and 443/tcp
in new and establised state
nft add rule inet filter input tcp dport {80, 443} ct state
new,established counter accept comment "WWW"
# vraag, wat doet/betekent die new,stablished hierboven en is dat wellicht ook
nodig voor hieronder?
# alternatieve schrijfwijze https://wiki.archlinux.org/index.php/Nftables
#
# SSH (port 22)
# tcp dport ssh accept
#
# # HTTP (ports 80 & 443)
# tcp dport { http, https } accept
# MAIL server, accept traffic for
# SMTP SMTPS 25/tcp, 465/tcp and 587
# POP3 POP3S 110/tcp, 995/tcp
# IMAP IMAPS 143/tcp, 993/tcp
nft add rule inet filter input tcp dport {25, 110, 143, 465,
587, 993, 995} counter accept comment "MAIL"
# PING
nft add rule inet filter input icmp type echo-request accept
comment "PING"
# alternatief voor PING https://wiki.archlinux.org/index.php/Nftables
# accept ICMP & IGMP
ip6 nexthdr icmpv6 icmpv6 type { destination-unreachable,
packet-too-big, time-exceeded, parameter-problem, mld-listener-query,
mld-listener-report, mld-listener-reduction, nd-router-solicit,
nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert,
ind-neighbor-solicit, ind-neighbor-advert, mld2-listener-report } accept
ip protocol icmp icmp type { destination-unreachable,
router-solicitation, router-advertisement, time-exceeded, parameter-problem }
accept
ip protocol igmp accept
# OpenVPN
# add rule ip filter udp dport 1194 counter accept comment "OpenVPN"
# FIXME wat moet ik hiermee
# add chain ip filter ovpn-fw
# add chain ip filter ovpn-net
# add chain ip filter ovpn-ovpn
# add chain ip filter ovpn_frwd
# en dan nog Fail2ban
# add chain ip filter f2b-blocklist
# add chain ip filter f2b-sshd
# add chain ip filter f2b-exim4
# count and drop any other traffic
counter drop
}
}
