Re: AAAA entry for openbsd.org
No idea what you perceive here as a "rant", my apologies if that seemed like one to you, that's not my intention. FWIW both ftplist1.openbsd.org and ftplist2.openbsd.org have no entry, either. I don't see what I need to prove here. That's 3 hosts already that don't have an DNS record, so if you're on an IPv6-only link, you can't access these. I didn't check ALL the mirrors that the installer has in the list, but the one popping up in my list as ftp.spline.de doesn't have one, either, so that's just number four. With prices for IPv4 addresses are starting to increase, it surprises me that this is still such a heated topic. Nobody asks about removing IPv4-connectivity here. Nobody wants to break functionaly for v4-only users. I did try installing OpenBSD in v6-only networks, yes. On an IPv6-only host it doesn't even suggest a mirror to download from. My initial mail was about this one here, nevertheless: $ ping6 openbsd.org ping6: no address associated with name $ The fact that all the other hosts I mentioned are v4-only doesn't change that situation in any way. ~ Armin On 23-10-22 19:29:28, Philip Guenther wrote: > On Sun, Oct 22, 2023 at 6:53 PM Armin Jenewein wrote: > > > Hi. > > > > On 23-10-22 15:47:45, Kastus Shchuka wrote: > > > On Sun, Oct 22, 2023 at 10:29:08PM +0200, Armin Jenewein wrote: > > > > Hi, > > > > > > > > as I'm almost 100% sure adding IPv6 connectivity to the openbsd.org > > > > host > > > > wouldn't introduce side-effects for IPv4 users: is there any reason > > > > openbsd.org still has no entry at the end of 2023? > > > > > > Why do you need it? > > > > Because it's extremely inconvenient to have manually type in the name of > > a mirror that I know has an entry. The installer won't even be able > > to download the mirror list because of the reason I mentioned. It tries > > to talk to openbsd.org which obviously fails. > > > See, this is why being clear about What Fine Problem You're Trying To Solve > is important: AFAICT the installer tries to fetch the mirror list from > ftplist1.openbsd.org and not from openbsd.org. > > Can you confirm that your _actual_ request is to have the installer be able > to get the mirror list when on an IPv6-only host? > > (Please don't rant at people who try to help, particularly when doing > exactly what you requested would NOT HAVE HELPED, unless you *want* people > to drop you in their kill-file as "not worth trying to help".) > > > Philip Guenther -- ,_^_. \- -/ \_/ \ Armin Jenewein |O o | |_ < ) 3 ) / \ / /-__,__-\
Re: AAAA entry for openbsd.org
On Sun, Oct 22, 2023 at 6:53 PM Armin Jenewein wrote: > Hi. > > On 23-10-22 15:47:45, Kastus Shchuka wrote: > > On Sun, Oct 22, 2023 at 10:29:08PM +0200, Armin Jenewein wrote: > > > Hi, > > > > > > as I'm almost 100% sure adding IPv6 connectivity to the openbsd.org > > > host > > > wouldn't introduce side-effects for IPv4 users: is there any reason > > > openbsd.org still has no entry at the end of 2023? > > > > Why do you need it? > > Because it's extremely inconvenient to have manually type in the name of > a mirror that I know has an entry. The installer won't even be able > to download the mirror list because of the reason I mentioned. It tries > to talk to openbsd.org which obviously fails. See, this is why being clear about What Fine Problem You're Trying To Solve is important: AFAICT the installer tries to fetch the mirror list from ftplist1.openbsd.org and not from openbsd.org. Can you confirm that your _actual_ request is to have the installer be able to get the mirror list when on an IPv6-only host? (Please don't rant at people who try to help, particularly when doing exactly what you requested would NOT HAVE HELPED, unless you *want* people to drop you in their kill-file as "not worth trying to help".) Philip Guenther
Re: AAAA entry for openbsd.org
On 23/10/23 11:51, Armin Jenewein wrote: Why do you need it? > Because it's extremely inconvenient to have manually type in the name of a mirror that I know has an entry. The installer won't even be able to download the mirror list because of the reason I mentioned. It tries to talk to openbsd.org which obviously fails. So the reason is as simple as "Because 2^32 IP addresses are not sufficient for over 8 millian humans.". I see no point in making the life of IPv6-only attached users harder here. Long-term, it may become necessary to do this as IPv4 address depletion bites further… but I think it's a bit disingenuous to equate the number of people to the number of IP addresses available. Humans do not have network interfaces (yet). The vast majority of IPv6-only users actually have some means of accessing IPv4 through carrier-grade NAT64. A short-term solution might be to download the installXX.img or installXX.iso images, which include the install sets so remove any need to select a mirror until such time as you have the system bootstrapped. That'll let you get 90% of the job done without IPv4 access. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: ImageMagick fails on OpenBSD 7.4 fresh install
Ah, sorry for my misreading what you wrote.
Please use 'sendbug' to report the sequence of pkg_add operations that
didn't work.
Philip Guenther
On Sun, Oct 22, 2023 at 5:50 PM Mark wrote:
> It wasn't an upgraded system, that's fresh install, a completely new
> OpenBSD 7.4 amd64.
>
> And the first package I wanted to install, was imagick. And it failed as on
> the screenshot image link.
>
> However, installing the "gtk-update-icon-cache" package, and after, pkg_add
> imagick solved the problem.
>
> That was the suggestion of "quinq", from IRC #openbsd. ("can you try
> installing that package, and then ImageMagick?")
>
> Philip Guenther , 23 Eki 2023 Pzt, 02:54 tarihinde
> şunu
> yazdı:
>
> > Don't know what's wrong with the pkg database (/var/db/pkg/) on your
> > system, but on mine the shared-mime-info-2.2 package includes a
> definition
> > for the update-mime-info tag, so if yours lacks that then something in
> > there got hosed during your upgrade. Could be data loss from disk
> failure,
> > could be something pruned critical info from /var/db/pkg/, could be
> > something I can't think of.
> >
> > So, I would suggest starting with verifying your confidence in your
> > storage (no kernel log error messages about I/O errors? If this machine
> > has suffered any file system issues then maybe backup, verify-backup,
> newfs
> > and restore?)
> >
> > Then I would probably reinstall *all* packages, but since I don't (fully)
> > trust the pkg database, I would probably do it with the
> > 1) pkg_info -mz > manual
> > 2) cd /var/db/pkg && pkg_delete *
> > 3) make sure nothing unexpected has been left behind in /var/db/pkg/ or
> > /usr/local/*
> > 4) pkg_add -l manual
> >
> >
> > Or maybe now's a good time to do a fresh install.
> >
> >
> > Philip Guenther
> >
> >
> > On Sun, Oct 22, 2023 at 3:34 PM Mark wrote:
> >
> >> Tried changing the installurl, an another mirror, but didn't help.
> >>
> >> Here's what actually happens;
> >>
> >> https://i.ibb.co/G0wbGf5/terminal-sshot.png
> >>
> >> Regards.
> >>
> >> Mark , 23 Eki 2023 Pzt, 01:16 tarihinde şunu
> >> yazdı:
> >>
> >> > pkg_add ImageMagick-6.9.12.88p0 gives me;
> >> >
> >> > (after fetching few libraries)
> >> >
> >> > "Can't install ImageMagick-6.9.12.88p0: can't resolve
> >> > djvulibre-3.5.28p1,libheif-1.16.2p0"
> >> >
> >> > and then;
> >> > "Couldn't install ImageMagick-6.9.12.88p0 djvulibre-3.5.28p1
> >> > libheif-1.16.2p0."
> >> >
> >> > This is a fresh OpenBSD 7.4 amd64 release. My installurl is pointed to
> >> > cdn.openbsd.org/pub/OpenBSD.
> >> >
> >> > Any other php packages were installed fine. But both
> >> > pecl80-imagick-3.7.0p1 and ImageMagick fail.
> >> >
> >> > Some idea would be much appreciated!
> >> >
> >> > Regards.
> >> >
> >>
> >
>
Re: AAAA entry for openbsd.org
Hi. On 23-10-22 15:47:45, Kastus Shchuka wrote: > On Sun, Oct 22, 2023 at 10:29:08PM +0200, Armin Jenewein wrote: > > Hi, > > > > as I'm almost 100% sure adding IPv6 connectivity to the openbsd.org > > host > > wouldn't introduce side-effects for IPv4 users: is there any reason > > openbsd.org still has no entry at the end of 2023? > > Why do you need it? Because it's extremely inconvenient to have manually type in the name of a mirror that I know has an entry. The installer won't even be able to download the mirror list because of the reason I mentioned. It tries to talk to openbsd.org which obviously fails. So the reason is as simple as "Because 2^32 IP addresses are not sufficient for over 8 millian humans.". I see no point in making the life of IPv6-only attached users harder here. > > > > > This has likely be discussed in the past and OpenBSD does a good job > > for > > me on both servers and desktops running IPv6, but with IPv4 > > addresses > > becoming more and more expensive, I would love to have the option to > > deploy OpenBSD on IPv6-only hosts, even IPv6 only with NAT64 was no > > problem here - the installer defaults to do auto configuration for > > v4 > > only and by default doesn't even auto-configure v6, which surprised > > me, > > too, though. > > Nothing prevents you from installing ipv6-only hosts, just use mirrors > as installurl. That's simply harder as it needs to be. I'm convinced that the benefits of having entries outrule the disadvantages here - in fact I don't see any. > > Four out of six CDN mirrors listed on https://www.openbsd.org/ftp.html > have ipv6 addresses with appropriate DNS entries. > > -Kastus > I'm not even able to access the list of CDN mirrors on an IPv6-only hosts to find these - that makes not much sense to me. ~ Armin -- ,_^_. \- -/ \_/ \ Armin Jenewein |O o | |_ < ) 3 ) / \ / /-__,__-\
Re: ImageMagick fails on OpenBSD 7.4 fresh install
It wasn't an upgraded system, that's fresh install, a completely new
OpenBSD 7.4 amd64.
And the first package I wanted to install, was imagick. And it failed as on
the screenshot image link.
However, installing the "gtk-update-icon-cache" package, and after, pkg_add
imagick solved the problem.
That was the suggestion of "quinq", from IRC #openbsd. ("can you try
installing that package, and then ImageMagick?")
Philip Guenther , 23 Eki 2023 Pzt, 02:54 tarihinde şunu
yazdı:
> Don't know what's wrong with the pkg database (/var/db/pkg/) on your
> system, but on mine the shared-mime-info-2.2 package includes a definition
> for the update-mime-info tag, so if yours lacks that then something in
> there got hosed during your upgrade. Could be data loss from disk failure,
> could be something pruned critical info from /var/db/pkg/, could be
> something I can't think of.
>
> So, I would suggest starting with verifying your confidence in your
> storage (no kernel log error messages about I/O errors? If this machine
> has suffered any file system issues then maybe backup, verify-backup, newfs
> and restore?)
>
> Then I would probably reinstall *all* packages, but since I don't (fully)
> trust the pkg database, I would probably do it with the
> 1) pkg_info -mz > manual
> 2) cd /var/db/pkg && pkg_delete *
> 3) make sure nothing unexpected has been left behind in /var/db/pkg/ or
> /usr/local/*
> 4) pkg_add -l manual
>
>
> Or maybe now's a good time to do a fresh install.
>
>
> Philip Guenther
>
>
> On Sun, Oct 22, 2023 at 3:34 PM Mark wrote:
>
>> Tried changing the installurl, an another mirror, but didn't help.
>>
>> Here's what actually happens;
>>
>> https://i.ibb.co/G0wbGf5/terminal-sshot.png
>>
>> Regards.
>>
>> Mark , 23 Eki 2023 Pzt, 01:16 tarihinde şunu
>> yazdı:
>>
>> > pkg_add ImageMagick-6.9.12.88p0 gives me;
>> >
>> > (after fetching few libraries)
>> >
>> > "Can't install ImageMagick-6.9.12.88p0: can't resolve
>> > djvulibre-3.5.28p1,libheif-1.16.2p0"
>> >
>> > and then;
>> > "Couldn't install ImageMagick-6.9.12.88p0 djvulibre-3.5.28p1
>> > libheif-1.16.2p0."
>> >
>> > This is a fresh OpenBSD 7.4 amd64 release. My installurl is pointed to
>> > cdn.openbsd.org/pub/OpenBSD.
>> >
>> > Any other php packages were installed fine. But both
>> > pecl80-imagick-3.7.0p1 and ImageMagick fail.
>> >
>> > Some idea would be much appreciated!
>> >
>> > Regards.
>> >
>>
>
Re: X session doesn't survive zzz
I would start by removing X from the picture and verify that suspend and resume are working (or not) when X is not running. Are USB devices failing to reattach or coming back in some weird mode which isn't working? Can you ssh in? If that's working fine, then bring X back into the picture but capture /var/log/Xorg.0.log both before suspending and then after resuming (ssh in if necessary) and see what X is falling over on. Philip Guenther On Wed, Oct 18, 2023 at 4:17 AM Jan Stary wrote: > On Oct 18 11:11:54, h...@stare.cz wrote: > > This is current/amd64 on a PC (dmesg below). > > After a resume from zzz inside a running X session, > > I am greeted with the xenodm login screen > > into which I cannot login: the keyboard does nothing > > (is it the USB keyboard not reattaching properly?). > > > > Loging in on the console, > > To be clear: typing the username and passwd > into the xenodm login screen does nothing, > but on the console the kbd works as expeceted. > > > I see that the X session > > and the X applications (firefox, xterms) are dead. > > On the other hand, the mplayer that has been zzz'ed > > inside a tmux session starts playing again. > > > > After restarting xenodm with rcctl restart xenodm, > > I can log in and everything seems to work again. > > > > See the dmesg below, including the zzz and resume, > > and the full X log up to here. How can I debug this? > > > > Jan > > > > > > OpenBSD 7.4-current (GENERIC.MP) #1406: Sun Oct 15 10:34:05 MDT 2023 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 8285454336 (7901MB) > > avail mem = 8014598144 (7643MB) > > random: good seed from bootblocks > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (36 entries) > > bios0: vendor Award Software International, Inc. version "F3" date > 03/31/2011 > > bios0: Gigabyte Technology Co., Ltd. H67MA-USB3-B3 > > acpi0 at bios0: ACPI 1.0 > > acpi0: sleep states S0 S3 S4 S5 > > acpi0: tables DSDT FACP HPET MCFG ASPT SSPT EUDS MATS TAMG APIC SSDT > > acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) > PEX4(S5) PEX5(S5) PEX6(S5) PEX7(S5) HUB0(S5) UAR1(S3) USBE(S3) USE2(S3) > AZAL(S5) > > acpitimer0 at acpi0: 3579545 Hz, 24 bits > > acpihpet0 at acpi0: 14318179 Hz > > acpimcfg0 at acpi0 > > acpimcfg0: addr 0xf400, bus 0-63 > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > cpu0 at mainbus0: apid 0 (boot processor) > > cpu0: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.09 MHz, 06-2a-07, > patch 002f > > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache > > cpu0: smt 0, core 0, package 0 > > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > > cpu0: apic clock running at 99MHz > > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE > > cpu1 at mainbus0: apid 2 (application processor) > > cpu1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.12 MHz, 06-2a-07, > patch 002f > > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache > > cpu1: smt 0, core 1, package 0 > > cpu2 at mainbus0: apid 4 (application processor) > > cpu2: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.19 MHz, 06-2a-07, > patch 002f > > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > > cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache > > cpu2: smt 0, core 2, package 0 > > cpu3 at mainbus0: apid 6 (application processor) > > cpu3: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.25 MHz, 06-2a-07, > patch 002f > > cpu3: >
Re: ImageMagick fails on OpenBSD 7.4 fresh install
Don't know what's wrong with the pkg database (/var/db/pkg/) on your system, but on mine the shared-mime-info-2.2 package includes a definition for the update-mime-info tag, so if yours lacks that then something in there got hosed during your upgrade. Could be data loss from disk failure, could be something pruned critical info from /var/db/pkg/, could be something I can't think of. So, I would suggest starting with verifying your confidence in your storage (no kernel log error messages about I/O errors? If this machine has suffered any file system issues then maybe backup, verify-backup, newfs and restore?) Then I would probably reinstall *all* packages, but since I don't (fully) trust the pkg database, I would probably do it with the 1) pkg_info -mz > manual 2) cd /var/db/pkg && pkg_delete * 3) make sure nothing unexpected has been left behind in /var/db/pkg/ or /usr/local/* 4) pkg_add -l manual Or maybe now's a good time to do a fresh install. Philip Guenther On Sun, Oct 22, 2023 at 3:34 PM Mark wrote: > Tried changing the installurl, an another mirror, but didn't help. > > Here's what actually happens; > > https://i.ibb.co/G0wbGf5/terminal-sshot.png > > Regards. > > Mark , 23 Eki 2023 Pzt, 01:16 tarihinde şunu > yazdı: > > > pkg_add ImageMagick-6.9.12.88p0 gives me; > > > > (after fetching few libraries) > > > > "Can't install ImageMagick-6.9.12.88p0: can't resolve > > djvulibre-3.5.28p1,libheif-1.16.2p0" > > > > and then; > > "Couldn't install ImageMagick-6.9.12.88p0 djvulibre-3.5.28p1 > > libheif-1.16.2p0." > > > > This is a fresh OpenBSD 7.4 amd64 release. My installurl is pointed to > > cdn.openbsd.org/pub/OpenBSD. > > > > Any other php packages were installed fine. But both > > pecl80-imagick-3.7.0p1 and ImageMagick fail. > > > > Some idea would be much appreciated! > > > > Regards. > > >
Re: AAAA entry for openbsd.org
On Sun, Oct 22, 2023 at 10:29:08PM +0200, Armin Jenewein wrote: > Hi, > > as I'm almost 100% sure adding IPv6 connectivity to the openbsd.org host > wouldn't introduce side-effects for IPv4 users: is there any reason > openbsd.org still has no entry at the end of 2023? Why do you need it? > > This has likely be discussed in the past and OpenBSD does a good job for > me on both servers and desktops running IPv6, but with IPv4 addresses > becoming more and more expensive, I would love to have the option to > deploy OpenBSD on IPv6-only hosts, even IPv6 only with NAT64 was no > problem here - the installer defaults to do auto configuration for v4 > only and by default doesn't even auto-configure v6, which surprised me, > too, though. Nothing prevents you from installing ipv6-only hosts, just use mirrors as installurl. Four out of six CDN mirrors listed on https://www.openbsd.org/ftp.html have ipv6 addresses with appropriate DNS entries. -Kastus
Re: ImageMagick fails on OpenBSD 7.4 fresh install
Tried changing the installurl, an another mirror, but didn't help. Here's what actually happens; https://i.ibb.co/G0wbGf5/terminal-sshot.png Regards. Mark , 23 Eki 2023 Pzt, 01:16 tarihinde şunu yazdı: > pkg_add ImageMagick-6.9.12.88p0 gives me; > > (after fetching few libraries) > > "Can't install ImageMagick-6.9.12.88p0: can't resolve > djvulibre-3.5.28p1,libheif-1.16.2p0" > > and then; > "Couldn't install ImageMagick-6.9.12.88p0 djvulibre-3.5.28p1 > libheif-1.16.2p0." > > This is a fresh OpenBSD 7.4 amd64 release. My installurl is pointed to > cdn.openbsd.org/pub/OpenBSD. > > Any other php packages were installed fine. But both > pecl80-imagick-3.7.0p1 and ImageMagick fail. > > Some idea would be much appreciated! > > Regards. >
ImageMagick fails on OpenBSD 7.4 fresh install
pkg_add ImageMagick-6.9.12.88p0 gives me; (after fetching few libraries) "Can't install ImageMagick-6.9.12.88p0: can't resolve djvulibre-3.5.28p1,libheif-1.16.2p0" and then; "Couldn't install ImageMagick-6.9.12.88p0 djvulibre-3.5.28p1 libheif-1.16.2p0." This is a fresh OpenBSD 7.4 amd64 release. My installurl is pointed to cdn.openbsd.org/pub/OpenBSD. Any other php packages were installed fine. But both pecl80-imagick-3.7.0p1 and ImageMagick fail. Some idea would be much appreciated! Regards.
Re: 7.3 -> 7.4 WireGuard AllowedIPs stopped working
are you certain that you upgraded your userland packages after upgrading? wireguard-tools is critical to update in 7.4 (I think due in part to the wgdescr field being added, which is a sorely missing field imo) (for what its worth, I ran into the same problem, specifically because I’d typo’d pkg_add and didnt pay attention until things stopped working. Doh.) if you want to convert to the ifconfig syntax (away from using wg0.conf), you can put your peers in /etc/hostname.wg0 - Solene’s post about it covers how to do that. https://dataswamp.org/~solene/2021-10-09-openbsd-wireguard-exit.html the gist: PUBKEY=PASTE_PUBKEY_HERE PRIVKEY=$(openssl rand -base64 32) cat < /etc/hostname.wg0 wgkey $PRIVKEY wgpeer $PUBKEY wgaip 192.168.10.0/24 inet 192.168.10.1/24 wgport 4433 up EOF you can have multiple wgpeer lines. look at the wireguard entries in "man ifconfig" for more info. > On Oct 22, 2023, at 8:56 AM, Pierre Peyronnel > wrote: > > Hi there, > > Since upgrading from 7.3 to 7.4 my wireguard setup stopped working. > Now, it might be me. Still here's what I have. > > Stripping down wg0.conf, I have this message as soon as I add a [Peer] > section and its public key: > > bsd# cat /etc/wireguard/wg0.conf >> >> [Interface] >> PrivateKey = (hidden by me) >> ListenPort = 51820 >> >> [Peer] >> PublicKey = (hidden by me) >> #PresharedKey = (hidden by me) >> #AllowedIPs = 10.x.x.10/32 >> > > >> # wg setconf wg0 /etc/wireguard/wg0.conf >> Unable to modify interface: Address family not supported by protocol family >> > > Trying to set it up manually, I get the following result: > >> bsd# ifconfig wg0 wgpeer '(hidden by me)' wgpsk '(hidden by me)' wgaip >> '10.x.x.10/32' >> bsd# wg >> interface: wg0 >> public key: (hidden by me) >> private key: (hidden) >> listening port: 51820 >> >> peer: (hidden by me) >> preshared key: (hidden) >> allowed ips: (none) >> > > I see no way of setting the AllowedIPs anymore. > I did not see any change in 7.4 that cloud explain the behaviour or require > a change in my configuration > I'd be grateful for feedback. > > Thanks ! > Pierre
Re: Delay in starting xterm via ssh after upgrade from 7.3 to 7.4
If this had been observed _during_ 7.4 development then it would have been simpler to isolate what set of changes caused it. Since that didn't happen you'll have to debug this yourself on the affected systems. For starters, I would suggest turning up ssh logging with the -v option and capturing that to a file and comparing the output on working and not working systems. Or ktrace the stuttering processes and see when kdump -T output shows as the operations where the delays occurred. As for your "should I have never been doing these this way?" question, that's unanswerable without knowing _why_ you had written them that way. Using -Y instead of -X to disable XSecurity enforcement? Why tunnel X instead of have the remote client connect directly to the X server? You wrote those to solve some problem, changing that means going back and reopening that question, which is probably a distraction from the "why did the latency change" question. On Sun, Oct 22, 2023 at 7:22 AM Roger Marsh wrote: > On Thu, 19 Oct 2023 17:23:47 + > Roger Marsh wrote: > > > Hi, > > > > After upgrade from 7.3 to 7.4 (on both boxes) the xterm session for this > entry in .fvwmrc (on monitor): > > > > 'Exec exec ssh -Y opendev xterm -title roger@opendev' > > > > takes several seconds to deliver the xterm window, while I did not > notice any delay before upgrade. > > > > For other usernames on opendev the .fvwmrc entry is like (without the > '-X' for most usernames other than grading): > > > > 'Exec exec xterm -title grading@opendev -e ssh -X grading@opendev' > > > > and I do not notice any delay after upgrade compared with before upgrade. > > > > Expressing the 'roger@opendev' entry as: > > > > 'Exec exec xterm -title roger@opendev -e ssh -Y roger@opendev' > > > > fixes the delay problem, but was the delay a predictable consequence of > some change? Or perhaps the entry should never have been expressed in the > way that led to the delay? > > > > Below are dmsesg and pkg_info for both boxes involved. > > > > Roger > > ... > dmesg and pkg_info for monitor and opendev snipped. > ... > > Hi, > > Later I saw opening files with Python's Idle editor suffers the same > pattern of slow response, in terms of serving up the file edit window, as > seen with xterm. Scrolling through an editor window is slower too, and > stutters, compared with what was seen when both boxes were at 7.3 (PgUp and > PgDn buttons are what I used). > > One box (gash) had not been upgraded to 7.4 (because I thought it did not > have OpenBSD disks). It was modified, in particular adding Python Idle and > Chromium, to see what happens when 7.3 has the Xserver role and 7.4 the > Xclient role; and the other way round. > > Idle > XserverXclient Display file window Scrolling > 7.47.3 slow stutter > 7.37.4 quicksmooth > 7.47.4 slow stutter > 7.37.3 quicksmooth (from > memory: confirmed on reverting) >Same 7.4 boxquicksmooth > > Idle is started by 'Exec exec ssh -Y idle3.10' in .fvwmrc file. > Chromium is started by 'Exec exec ssh -X @ chrome' in > .fvwmrc file. > > This behaviour with Python persuades me to revert the OpenBSD 7.4 box > (monitor) in the Xserver role to 7.3 until 7.4 or later provides more > acceptable response times. > > Chromium seemed unaffected except for slow response when typing in the URL > bar on the separate 7.4 Xserver box. I thought I could mostly avoid this > by starting to use bookmarks, but the effect on Python matters more. > > Apologies for going off-topic by discussing Python and Chromium rather > than xterm: but the Python stuff changes my attitude to the problem from > minor annoyance to something which needs an immediate workaround. > > Below are dmesg (most recent reboot only) and pkg_info for the OpenBSD 7.3 > box (gash). > > Roger > > Script started on Sat Oct 21 17:09:38 2023 > gash$ dmesg > syncing disks... done > rebooting... > OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 3967422464 (3783MB) > avail mem = 3827781632 (3650MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe9f80 (85 entries) > bios0: vendor Hewlett-Packard version "786G1 v01.16" date 03/05/2009 > bios0: Hewlett-Packard HP Compaq dc7900 Small Form Factor > acpi0 at bios0: ACPI 1.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC ASF! MCFG TCPA SLIC HPET DMAR > acpi0: wakeup devices PCI0(S4) PEG1(S4) PEG2(S4) IGBE(S4) PCX1(S4) > PCX2(S4) PCX5(S4) PCX6(S4) HUB_(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) > USB5(S3) USB6(S3) EUS1(S3) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0:
Re: Crash on TOSHIBA PORTEGE Z30-A laptop
On Sat, Oct 21, 2023 at 2:27 AM wrote: > Hi Philip, > > Thank you very much for your answer. > > I tried to disable all options (+devices) possible. Same issue. > And what's about disable acpi in the kernel using the bsd.re-config? > As Mike and Theo noted, this will certainly cause problems. > Do you think If I replace the wireless card by somthing else, It could > resolve this issue? > Very unlikely. The problem is the stack depth of the ACPI processing. The crash you saw had the wifi interrupt occur during the ACPI processing but it could just as well happen with some other device interrupting the ACPI processing. If there isn't a newer BIOS that resolves this, I would tend to return the box as not suitable. Phlip Guenther
AAAA entry for openbsd.org
Hi, as I'm almost 100% sure adding IPv6 connectivity to the openbsd.org host wouldn't introduce side-effects for IPv4 users: is there any reason openbsd.org still has no entry at the end of 2023? This has likely be discussed in the past and OpenBSD does a good job for me on both servers and desktops running IPv6, but with IPv4 addresses becoming more and more expensive, I would love to have the option to deploy OpenBSD on IPv6-only hosts, even IPv6 only with NAT64 was no problem here - the installer defaults to do auto configuration for v4 only and by default doesn't even auto-configure v6, which surprised me, too, though. Anything I'm overlooking here? Is there a technical reason to keep these things v4-only? ~ Armin -- ,_^_. \- -/ \_/ \ Armin Jenewein |O o | |_ < ) 3 ) / \ / /-__,__-\
Re: 7.3 -> 7.4 WireGuard AllowedIPs stopped working
On Sun, Oct 22, 2023 at 05:56:28PM +0200, Pierre Peyronnel wrote: > Hi there, > > Since upgrading from 7.3 to 7.4 my wireguard setup stopped working. > Now, it might be me. Still here's what I have. > > Stripping down wg0.conf, I have this message as soon as I add a [Peer] > section and its public key: > > bsd# cat /etc/wireguard/wg0.conf > > > > [Interface] > > PrivateKey = (hidden by me) > > ListenPort = 51820 > > > > [Peer] > > PublicKey = (hidden by me) > > #PresharedKey = (hidden by me) > > #AllowedIPs = 10.x.x.10/32 > > > > > > # wg setconf wg0 /etc/wireguard/wg0.conf > > Unable to modify interface: Address family not supported by protocol family > > > > Trying to set it up manually, I get the following result: > > > bsd# ifconfig wg0 wgpeer '(hidden by me)' wgpsk '(hidden by me)' wgaip > > '10.x.x.10/32' > > bsd# wg > > interface: wg0 > > public key: (hidden by me) > > private key: (hidden) > > listening port: 51820 > > > > peer: (hidden by me) > > preshared key: (hidden) > > allowed ips: (none) > > Maybe this 'wg' tool just doesn't display the config correctly? ifconfig wg0 as root displays wgaip settings just fine here. For automatic setup you can set up wg0 via /etc/hostname.wg0, adding all the ifconfig wg0 commands you need on a single line. There is no need to use any files in /etc/wireguard anymore, nor is there a need for a wireguard config tool from packages. My /etc/hostname.wg0 looks like this (except that the random keys and IPs are in fact different): rdomain 1 wgkey "86oHs/awV8nlLe2KKHkMEAhmsRRIA8nLilzHwnFFP8A=" wgpeer "6e0ZhZs/q4R8JZjNTp973DlO0FDRrkCiHAnMinFfn1U=" wgaip 0.0.0.0/0 wgaip ::/0 wgendpoint 10.10.10.10 443 wgpsk "ksorfAqLmd+CteNrc+aNL/q/5ItL6B2qZDllYNEgvqk=" wgpka 25 wgrtable 0 mtu 1332 inet 10.2.2.4/24 inet6 2001:db8::4/64 !/sbin/route -T1 add -inet default 10.2.2.1 !/sbin/route -T1 add -inet6 default 2001:db8::1
Re: 7.3 -> 7.4 WireGuard AllowedIPs stopped working
Hello Judah, > Silly question perhaps but are you trying to run this with the Allowed > IPs commented out as shown in your example? > If you remove the '#' from the front of that line does it work? It does not hurt to ask. The comment doesn't change a thing. With or without it you get that error message, and the file gets ignored. I left it like that because I found it even more striking to get a message about an address when you have not even specified one. In any case, the command line version shows the issue as well. Now, knowing that it works for you, I'm thinking it may be a driver issue, from an underlying network card, not a wireguard issue per se ? My wg0.conf file contains several peers initially, i just kept the minimum that works and does not work (it works if I remove all [Peer] sections) I have: > ix0 at pci1 dev 0 function 0 "Intel X540T" rev 0x01, msix, 1 queue, address (...) and > rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 5 > re0 at pci3 dev 0 function 0 "Realtek 8168" rev 0x09: RTL8168F/8111F (0x4800), msi, address (...) On Sun, 22 Oct 2023 at 18:35, Judah Kocher wrote: > > Hello Pierre, > > Silly question perhaps but are you trying to run this with the Allowed > IPs commented out as shown in your example? > > If you remove the '#' from the front of that line does it work? I can > confirm that wireguard is working just fine for me after the update to > 7.4 on multiple devices, including one with a practically identical > configuration to what you shared. > > Judah > > On 10/22/23 11:56, Pierre Peyronnel wrote: > > Hi there, > > > > Since upgrading from 7.3 to 7.4 my wireguard setup stopped working. > > Now, it might be me. Still here's what I have. > > > > Stripping down wg0.conf, I have this message as soon as I add a [Peer] > > section and its public key: > > > > bsd# cat /etc/wireguard/wg0.conf > >> [Interface] > >> PrivateKey = (hidden by me) > >> ListenPort = 51820 > >> > >> [Peer] > >> PublicKey = (hidden by me) > >> #PresharedKey = (hidden by me) > >> #AllowedIPs = 10.x.x.10/32 > >> > > > >> # wg setconf wg0 /etc/wireguard/wg0.conf > >> Unable to modify interface: Address family not supported by protocol family > >> > > Trying to set it up manually, I get the following result: > > > >> bsd# ifconfig wg0 wgpeer '(hidden by me)' wgpsk '(hidden by me)' wgaip > >> '10.x.x.10/32' > >> bsd# wg > >> interface: wg0 > >>public key: (hidden by me) > >>private key: (hidden) > >>listening port: 51820 > >> > >> peer: (hidden by me) > >>preshared key: (hidden) > >>allowed ips: (none) > >> > > I see no way of setting the AllowedIPs anymore. > > I did not see any change in 7.4 that cloud explain the behaviour or require > > a change in my configuration > > I'd be grateful for feedback. > > > > Thanks ! > > Pierre > > -- > Judah Kocher > Assistant Chief > Cochranville Fire Company > 484-266-9257 >
Re: relayd and large POST requests
> Actually I can't be sure this the origin of your problem, but the > value of "memory_limit" is wrong. Thank you, I increased php memory limit but the problem persists unfortunately. In fact this 3000M file upload freezes our 16G machine even when there is no other workload, so that's a significant issue. Has anyone else run into this problem?
Re: Dell C400m i830M graphics, works under OpenBSD i386 4.8 & 4.9, freees under current revs
I have no clue about you Dell configuration nor the chipset. However, I can say you my historic mini-pc (among others) has a chipset as well with shared memory *features*. It runs properly under any version of OpenBSD. The only time I experienced these "freees" moments is when I tried to overclock my motherboard over its limits from the Bios (over the limits of the cpu). Most probably your issue has this origin. Double check on the Intel website the spec for the limits of the CPU. Try to take down the amount of memory you allocated for the graphic side, as first, remaining on a nice default (doesn't seems X comes with very high requirements). Do every try one by one. Eventually copy on paper some data and load the defaults as last choice. Hope this help you, but again I don't think this is an OpenBSD issue. -- Daniele Bonini Stephen Harris wrote: > The symptoms of the freeze are similar to those described by i915kms > users, but the C400 laptop (1.2GH Pentium-M, 768M RAM) has the i830M > built-in graphics. > > This freeze also happens with NetBSD, FreeBSD, and several Linuxes. > It works, however, with OpenBSD 4.8 & 4.9. > > The commonality of current distros makes me think it is an X-windows > issue. The i830M is mentioned in the following: > > The Intel 8xx and 9xx families of integrated graphics chipsets have a > unified memory architecture meaning that system memory is used as > video RAM. For the i810 and i815 family of chipsets, operating system > support for allocating system memory is required in order to use this > driver. For the 830M and later, this is required in order for the > driver to use more video RAM than has been pre-allocated at boot time > by the BIOS. > > Which makes e wonder if it is a memory issue. I can bump the Dell > C400 up to 1G RAM if that will help. Is there boot time > configuration(s) I can give the laptop to restrain or expand the RAM > allocated to the i830M?' > > Ideas welcome. > > -Stephen >
Re: 7.3 -> 7.4 WireGuard AllowedIPs stopped working
Hello Pierre, Silly question perhaps but are you trying to run this with the Allowed IPs commented out as shown in your example? If you remove the '#' from the front of that line does it work? I can confirm that wireguard is working just fine for me after the update to 7.4 on multiple devices, including one with a practically identical configuration to what you shared. Judah On 10/22/23 11:56, Pierre Peyronnel wrote: Hi there, Since upgrading from 7.3 to 7.4 my wireguard setup stopped working. Now, it might be me. Still here's what I have. Stripping down wg0.conf, I have this message as soon as I add a [Peer] section and its public key: bsd# cat /etc/wireguard/wg0.conf [Interface] PrivateKey = (hidden by me) ListenPort = 51820 [Peer] PublicKey = (hidden by me) #PresharedKey = (hidden by me) #AllowedIPs = 10.x.x.10/32 # wg setconf wg0 /etc/wireguard/wg0.conf Unable to modify interface: Address family not supported by protocol family Trying to set it up manually, I get the following result: bsd# ifconfig wg0 wgpeer '(hidden by me)' wgpsk '(hidden by me)' wgaip '10.x.x.10/32' bsd# wg interface: wg0 public key: (hidden by me) private key: (hidden) listening port: 51820 peer: (hidden by me) preshared key: (hidden) allowed ips: (none) I see no way of setting the AllowedIPs anymore. I did not see any change in 7.4 that cloud explain the behaviour or require a change in my configuration I'd be grateful for feedback. Thanks ! Pierre -- Judah Kocher Assistant Chief Cochranville Fire Company 484-266-9257
Dell C400m i830M graphics, works under OpenBSD i386 4.8 & 4.9, freees under current revs
The symptoms of the freeze are similar to those described by i915kms users, but the C400 laptop (1.2GH Pentium-M, 768M RAM) has the i830M built-in graphics. This freeze also happens with NetBSD, FreeBSD, and several Linuxes. It works, however, with OpenBSD 4.8 & 4.9. The commonality of current distros makes me think it is an X-windows issue. The i830M is mentioned in the following: The Intel 8xx and 9xx families of integrated graphics chipsets have a unified memory architecture meaning that system memory is used as video RAM. For the i810 and i815 family of chipsets, operating system support for allocating system memory is required in order to use this driver. For the 830M and later, this is required in order for the driver to use more video RAM than has been pre-allocated at boot time by the BIOS. Which makes e wonder if it is a memory issue. I can bump the Dell C400 up to 1G RAM if that will help. Is there boot time configuration(s) I can give the laptop to restrain or expand the RAM allocated to the i830M?' Ideas welcome. -Stephen
7.3 -> 7.4 WireGuard AllowedIPs stopped working
Hi there, Since upgrading from 7.3 to 7.4 my wireguard setup stopped working. Now, it might be me. Still here's what I have. Stripping down wg0.conf, I have this message as soon as I add a [Peer] section and its public key: bsd# cat /etc/wireguard/wg0.conf > > [Interface] > PrivateKey = (hidden by me) > ListenPort = 51820 > > [Peer] > PublicKey = (hidden by me) > #PresharedKey = (hidden by me) > #AllowedIPs = 10.x.x.10/32 > > # wg setconf wg0 /etc/wireguard/wg0.conf > Unable to modify interface: Address family not supported by protocol family > Trying to set it up manually, I get the following result: > bsd# ifconfig wg0 wgpeer '(hidden by me)' wgpsk '(hidden by me)' wgaip > '10.x.x.10/32' > bsd# wg > interface: wg0 > public key: (hidden by me) > private key: (hidden) > listening port: 51820 > > peer: (hidden by me) > preshared key: (hidden) > allowed ips: (none) > I see no way of setting the AllowedIPs anymore. I did not see any change in 7.4 that cloud explain the behaviour or require a change in my configuration I'd be grateful for feedback. Thanks ! Pierre
Re: Delay in starting xterm via ssh after upgrade from 7.3 to 7.4
Let me joke that we clealry hope in 7.5 to slow down things further. -- Daniele Bonini
Re: Delay in starting xterm via ssh after upgrade from 7.3 to 7.4
On Thu, 19 Oct 2023 17:23:47 + Roger Marsh wrote: > Hi, > > After upgrade from 7.3 to 7.4 (on both boxes) the xterm session for this > entry in .fvwmrc (on monitor): > > 'Exec exec ssh -Y opendev xterm -title roger@opendev' > > takes several seconds to deliver the xterm window, while I did not notice any > delay before upgrade. > > For other usernames on opendev the .fvwmrc entry is like (without the '-X' > for most usernames other than grading): > > 'Exec exec xterm -title grading@opendev -e ssh -X grading@opendev' > > and I do not notice any delay after upgrade compared with before upgrade. > > Expressing the 'roger@opendev' entry as: > > 'Exec exec xterm -title roger@opendev -e ssh -Y roger@opendev' > > fixes the delay problem, but was the delay a predictable consequence of some > change? Or perhaps the entry should never have been expressed in the way > that led to the delay? > > Below are dmsesg and pkg_info for both boxes involved. > > Roger ... dmesg and pkg_info for monitor and opendev snipped. ... Hi, Later I saw opening files with Python's Idle editor suffers the same pattern of slow response, in terms of serving up the file edit window, as seen with xterm. Scrolling through an editor window is slower too, and stutters, compared with what was seen when both boxes were at 7.3 (PgUp and PgDn buttons are what I used). One box (gash) had not been upgraded to 7.4 (because I thought it did not have OpenBSD disks). It was modified, in particular adding Python Idle and Chromium, to see what happens when 7.3 has the Xserver role and 7.4 the Xclient role; and the other way round. Idle XserverXclient Display file window Scrolling 7.47.3 slow stutter 7.37.4 quicksmooth 7.47.4 slow stutter 7.37.3 quicksmooth (from memory: confirmed on reverting) Same 7.4 boxquicksmooth Idle is started by 'Exec exec ssh -Y idle3.10' in .fvwmrc file. Chromium is started by 'Exec exec ssh -X @ chrome' in .fvwmrc file. This behaviour with Python persuades me to revert the OpenBSD 7.4 box (monitor) in the Xserver role to 7.3 until 7.4 or later provides more acceptable response times. Chromium seemed unaffected except for slow response when typing in the URL bar on the separate 7.4 Xserver box. I thought I could mostly avoid this by starting to use bookmarks, but the effect on Python matters more. Apologies for going off-topic by discussing Python and Chromium rather than xterm: but the Python stuff changes my attitude to the problem from minor annoyance to something which needs an immediate workaround. Below are dmesg (most recent reboot only) and pkg_info for the OpenBSD 7.3 box (gash). Roger Script started on Sat Oct 21 17:09:38 2023 gash$ dmesg syncing disks... done rebooting... OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3967422464 (3783MB) avail mem = 3827781632 (3650MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe9f80 (85 entries) bios0: vendor Hewlett-Packard version "786G1 v01.16" date 03/05/2009 bios0: Hewlett-Packard HP Compaq dc7900 Small Form Factor acpi0 at bios0: ACPI 1.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC ASF! MCFG TCPA SLIC HPET DMAR acpi0: wakeup devices PCI0(S4) PEG1(S4) PEG2(S4) IGBE(S4) PCX1(S4) PCX2(S4) PCX5(S4) PCX6(S4) HUB_(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) EUS1(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.55 MHz, 06-17-0a cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 6MB 64b/line 24-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 332MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.57 MHz, 06-17-0a cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 6MB 64b/line 24-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa
Re: SSL issues after upgrading from 7.3 to 7.4
On 2023-10-21, Theo Buehler wrote: > On Sat, Oct 21, 2023 at 09:23:51AM +0300, Mark wrote: >> So, no idea on this? > > No. OCSP does work for me on 7.4 when enabled, both with httpd and nginx. > With nginx, you need to have accessed the page at least once so it > fetches and caches the staple and that may depend on the per worker > process. Confirmed here. Also note that, if you have multiple workers configured, the OCSP staple cache does not seem to be shared between them. Check error logs for anything relevant too.
