Re: unknown USB vendor

[Rob Schmersel]

On Fri, 24 May 2024 11:51:49 +0200
Mizsei Zoltán  wrote:

> Probably https://wikidevi.wi-cat.ru/AMPAK_AP6212
> 
> Peter J. Philipp írta 2024. máj.. 24, P-n 11:39 órakor:
> > Hi,
> >
> > I got a "are you a human?" on google so I switched to qwant.com for 
> > searching
> > but the search is not as good.  I'm looking for the USB vendor of
> > this USB
> > vendor id.  0x02d0, and the device id is 0xa9a6.  Afaict this is a 
> > ure(4)
> > device with a builtin usb hub.  But there is no other markings on
> > the outside, related to manufacturer.  It does not get detected by
> > default on an April
> > kernel code.  It does have a micro-USB cable for the raspberry pi
> > zero 2 that
> > I wanted to use this with.
> >
> > Anyone have any details on these vendor and device id's?
> >
> > Best Regards,
> > -pjp
> >
> > -- 
> > ** all info about me:  lynx https://callpeter.tel, dig loc
> > delphinusdns.org **  
> 

From an RPI 4 dmesg:
...
bwfm0 at sdmmc0 function 1
manufacturer 0x02d0, product 0xa9a6 at sdmmc0 
...

Re: unknown USB vendor

[Mizsei Zoltán]

Probably https://wikidevi.wi-cat.ru/AMPAK_AP6212

Peter J. Philipp írta 2024. máj.. 24, P-n 11:39 órakor:
> Hi,
>
> I got a "are you a human?" on google so I switched to qwant.com for 
> searching
> but the search is not as good.  I'm looking for the USB vendor of this 
> USB
> vendor id.  0x02d0, and the device id is 0xa9a6.  Afaict this is a 
> ure(4)
> device with a builtin usb hub.  But there is no other markings on the 
> outside, related to manufacturer.  It does not get detected by default 
> on an April
> kernel code.  It does have a micro-USB cable for the raspberry pi zero 
> 2 that
> I wanted to use this with.
>
> Anyone have any details on these vendor and device id's?
>
> Best Regards,
> -pjp
>
> -- 
> ** all info about me:  lynx https://callpeter.tel, dig loc delphinusdns.org **

-- 
--Z--

unknown USB vendor

[Peter J. Philipp]

Hi,

I got a "are you a human?" on google so I switched to qwant.com for searching
but the search is not as good.  I'm looking for the USB vendor of this USB
vendor id.  0x02d0, and the device id is 0xa9a6.  Afaict this is a ure(4)
device with a builtin usb hub.  But there is no other markings on the outside, 
related to manufacturer.  It does not get detected by default on an April
kernel code.  It does have a micro-USB cable for the raspberry pi zero 2 that
I wanted to use this with.

Anyone have any details on these vendor and device id's?

Best Regards,
-pjp

-- 
** all info about me:  lynx https://callpeter.tel, dig loc delphinusdns.org **

Re: silence logging of dhcpd deny unknown-clients

[Evan Sherwood]

> Is there any way to silence these logs? I only want to hand out a
> small number of IPv4 addresses on my IPv6 network to those machines
> that won't function properly without them. That leaves many machines
> on my network constantly requesting IPv4 addresses, and dhcpd is
> clogging my /var/log/daemon file:
>
>> ... dhcpd[13399]: DHCPDISCOVER from xx:xx:xx:xx:xx:xx via igc3
>> ... dhcpd[13399]: no free leases on subnet 192.168.3.0
> 
> ... over and over and over again.
> 
> I didn't see any logging options in dhcpd(8) or dhcpd.conf(5).

I wasn't able to figure out how silence specific messages from a given
daemon at a specific level. I read up on syslog.conf(5) and saw that I
could silence all warnings from dhcpd, but I don't want to do that—just
those for this specific directive.

In the meantime, I realized that my list of machines that need IPv4
addresses is so small I'm probably better off statically-assigning those
machines their addresses instead of running dhcpd at all, so I've done
that.

If there is a way to silence a log message from a "facility" at a given
"level" without affecting other messages at the same "facility" and
"level," I'd be curious to know, as I'm sure I'll run into this issue
again with something else.

silence logging of dhcpd deny unknown-clients

[Evan Sherwood]

Is there any way to silence these logs? I only want to hand out a small
number of IPv4 addresses on my IPv6 network to those machines that won't
function properly without them. That leaves many machines on my network
constantly requesting IPv4 addresses, and dhcpd is clogging my
/var/log/daemon file:

> ... dhcpd[13399]: DHCPDISCOVER from xx:xx:xx:xx:xx:xx via igc3
> ... dhcpd[13399]: no free leases on subnet 192.168.3.0

... over and over and over again.

I didn't see any logging options in dhcpd(8) or dhcpd.conf(5).

Re: unknown warning option '-Wno-unused-but-set-variable'

[Jan Stary]

The current amd64 snapshot already contains clang 13.


On Dec 19 15:23:34, y...@v007.vaio.ne.jp wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> > Kernel Makefiles were adjusted to compile with clang 13. Either take
> > out the warnings so you can compile with old-clang, or rebuild clang.
> 
> I'm trying to rebuild clang now.
> I believe the steps are:
> 
>   # cd /usr/src/gnu/usr.bin/clang/
>   # make clean && make obj && make
>   # make install
> 
> (compilation on my machine ongoing...)
> 
> why not adding an entry to www.openbsd.org/faq/current.html ?
> 
>  -- yozo.
> 
> 
> -BEGIN PGP SIGNATURE-
> 
> iQGzBAEBCgAdFiEEXaBuNN3EAffFuoZQoSJsq/akOnEFAmG+z6EACgkQoSJsq/ak
> OnEURQv9F9T5665BXEorsFEkWKvXWQpgl91J3qxJrhTsYlSWGnby9mx6FeAsbvbH
> QHcbihe6cDZYgfT4Dzq+UMZ9D7F4w+mjqOSuMwLXhcXiJRUkGW35BwCTQQaMUHGJ
> CoCG4Uggb7ukn86AQhVFkjnjcHnXEkuoPjKSpMjFNg3oBi6WO+lC+JqvUYbQ8941
> gLx6AO6bOln7EV7cEDzxfpNByPzsIZquY85H0mfKllRfRiFdomb3Npq4cI/65O8D
> WsvpOH7wlT1CYY3xZSa/D87tOkZscF5Z21tW2/ZLASb3Q2Gv8taYogOMQ4xyfbtm
> 5rl5PaoDP/jmdDllFkeeIw8PjeY3XBkoPcNxuYrMfnY4FUQNDwvozgczNYPinDVL
> qYn13FJl+m+y0Eamosw3RjL8O2JwBJ7aANjFv1rk1KyvH8eGmf738DZBFM1M7jRM
> /ooSte2a7Bkhdt1Vg9xGh7Abubhb7R3OmGD0+rw6sfKnG17/hoZlV8j05Sfb7sNF
> PEfkmlLf
> =HRZ2
> -END PGP SIGNATURE-
> 
> 

Re: unknown warning option '-Wno-unused-but-set-variable'

[Yozo TODA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

> Kernel Makefiles were adjusted to compile with clang 13. Either take
> out the warnings so you can compile with old-clang, or rebuild clang.

I'm trying to rebuild clang now.
I believe the steps are:

  # cd /usr/src/gnu/usr.bin/clang/
  # make clean && make obj && make
  # make install

(compilation on my machine ongoing...)

why not adding an entry to www.openbsd.org/faq/current.html ?

 -- yozo.


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEXaBuNN3EAffFuoZQoSJsq/akOnEFAmG+z6EACgkQoSJsq/ak
OnEURQv9F9T5665BXEorsFEkWKvXWQpgl91J3qxJrhTsYlSWGnby9mx6FeAsbvbH
QHcbihe6cDZYgfT4Dzq+UMZ9D7F4w+mjqOSuMwLXhcXiJRUkGW35BwCTQQaMUHGJ
CoCG4Uggb7ukn86AQhVFkjnjcHnXEkuoPjKSpMjFNg3oBi6WO+lC+JqvUYbQ8941
gLx6AO6bOln7EV7cEDzxfpNByPzsIZquY85H0mfKllRfRiFdomb3Npq4cI/65O8D
WsvpOH7wlT1CYY3xZSa/D87tOkZscF5Z21tW2/ZLASb3Q2Gv8taYogOMQ4xyfbtm
5rl5PaoDP/jmdDllFkeeIw8PjeY3XBkoPcNxuYrMfnY4FUQNDwvozgczNYPinDVL
qYn13FJl+m+y0Eamosw3RjL8O2JwBJ7aANjFv1rk1KyvH8eGmf738DZBFM1M7jRM
/ooSte2a7Bkhdt1Vg9xGh7Abubhb7R3OmGD0+rw6sfKnG17/hoZlV8j05Sfb7sNF
PEfkmlLf
=HRZ2
-END PGP SIGNATURE-

Re: unknown warning option '-Wno-unused-but-set-variable'

[Patrick Wildt]

Kernel Makefiles were adjusted to compile with clang 13.  Either take
out the warnings so you can compile with old-clang, or rebuild clang.

What should have been done was to add no-op arguments for these warnings
into clang 11 to ease the transition to clang 13, but somehow no one did
it, huh.

Patrick

Am Fri, Dec 17, 2021 at 07:23:06PM +0100 schrieb Jan Stary:
> This is current/i386 on an ALIX.1E (dmesg below).
> The kernel does not build with the current cvs:
> 
> cat /usr/src/sys/arch/i386/i386/genassym.cf 
> /usr/src/sys/arch/i386/i386/genassym.cf |  sh /usr/src/sys/kern/genassym.sh 
> cc -no-integrated-as -g -Werror -Wall -Wimplicit-function-declaration  
> -Wno-pointer-sign  -Wframe-larger-than=2047 -Wno-address-of-packed-member 
> -Wno-constant-conversion  -Wno-unused-but-set-variable 
> -Wno-gnu-folding-constant  -ffreestanding -fno-pie -mretpoline -O2  -pipe 
> -nostdinc -I/usr/src/sys -I/usr/src/sys/arch/i386/compile/GENERIC/obj 
> -I/usr/src/sys/arch  -I/usr/src/sys/dev/pci/drm/include
> -I/usr/src/sys/dev/pci/drm/include/uapi  -I/usr/src/sys/dev/pci/drm/i915 
> -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DPOOL_DEBUG 
> -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DUVM_SWAP_ENCRYPT -DFFS -DFFS2 
> -DFFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT 
> -DNFSSERVER -DCD9660 -DUDF -DMSDOSFS -DFIFO -DFUSE -DSOCKET_SPLICE -DTCP_ECN 
> -DTCP_SIGNATURE -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX 
> -DMROUTING -DMPLS -DBOOT_CONFIG -DUSER_PCICONF -DAPERTURE -DMTRR -DNTFS 
> -DHIBERNATE -DPCIVERBOSE -DEISAVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL 
> -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS="6" -DX86EMU 
> -DONEWIREVERBOSE -DMAXUSERS=80 -D_KERNEL -MD -MP -MF assym.P > assym.h.tmp
> error: unknown warning option '-Wno-unused-but-set-variable'; did you mean 
> '-Wno-unused-const-variable'? [-Werror,-Wunknown-warning-option]
> *** Error 1 in /usr/src/sys/arch/i386/compile/GENERIC (Makefile:1286 
> 'assym.h')
> 
> 
>   Jan
> 
> 
> OpenBSD 7.0-current (GENERIC) #345: Thu Dec 16 13:19:22 MST 2021
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> real mem  = 259207168 (247MB)
> avail mem = 238182400 (227MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 07/19/10, BIOS32 rev. 0 @ 0xfa950
> apm0 at bios0: Power Management spec V1.2 (slowidle)
> pcibios0 at bios0: rev 2.1 @ 0xf/0xdfb4
> pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf30/128 (6 entries)
> pcibios0: PCI Exclusive IRQs: 5 10 11
> pcibios0: no compatible PCI ICU found: ICU vendor 0x1022 product 0x2090
> pcibios0: Warning, unable to fix up PCI interrupt routing
> pcibios0: PCI bus #0 is the last bus
> bios0: ROM list: 0xc/0x8000 0xc8000/0xa800 0xef000/0x1000!
> cpu0 at mainbus0: (uniprocessor)
> cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 
> 499 MHz, 05-0a-02
> cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
> mtrr: K6-family MTRR support (2 registers)
> amdmsr0 at mainbus0
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
> vga1 at pci0 dev 1 function 1 "AMD Geode LX Video" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
> vr0 at pci0 dev 13 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, 
> address 00:0d:b9:0e:9e:f4
> ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
> 0x004063, model 0x0034
> glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit 
> 3579545Hz timer, watchdog, gpio, i2c
> gpio0 at glxpcib0: 32 pins
> iic0 at glxpcib0
> pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0 
> wired to compatibility, channel 1 wired to compatibility
> wd0 at pciide0 channel 0 drive 0: 
> wd0: 1-sector PIO, LBA48, 15279MB, 31293360 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
> pciide0: channel 1 ignored (disabled)
> auglx0 at pci0 dev 15 function 3 "AMD CS5536 Audio" rev 0x01: irq 11, CS5536 
> AC97
> ac97: codec id 0x414c4770 (Avance Logic ALC203 rev 0)
> ac97: codec features headphone, 20 bit DAC, 18 bit ADC, No 3D Stereo
> audio0 at auglx0
> ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 5, version 
> 1.0, legacy support
> ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 5
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interf

unknown warning option '-Wno-unused-but-set-variable'

[Jan Stary]

This is current/i386 on an ALIX.1E (dmesg below).
The kernel does not build with the current cvs:

cat /usr/src/sys/arch/i386/i386/genassym.cf 
/usr/src/sys/arch/i386/i386/genassym.cf |  sh /usr/src/sys/kern/genassym.sh cc 
-no-integrated-as -g -Werror -Wall -Wimplicit-function-declaration  
-Wno-pointer-sign  -Wframe-larger-than=2047 -Wno-address-of-packed-member 
-Wno-constant-conversion  -Wno-unused-but-set-variable 
-Wno-gnu-folding-constant  -ffreestanding -fno-pie -mretpoline -O2  -pipe 
-nostdinc -I/usr/src/sys -I/usr/src/sys/arch/i386/compile/GENERIC/obj 
-I/usr/src/sys/arch  -I/usr/src/sys/dev/pci/drm/include  
-I/usr/src/sys/dev/pci/drm/include/uapi  -I/usr/src/sys/dev/pci/drm/i915 -DDDB 
-DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DPOOL_DEBUG -DCRYPTO 
-DSYSVMSG -DSYSVSEM -DSYSVSHM -DUVM_SWAP_ENCRYPT -DFFS -DFFS2 -DFFS_SOFTUPDATES 
-DUFS_DIRHASH -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT -DNFSSERVER -DCD9660 -DUDF 
-DMSDOSFS -DFIFO -DFUSE -DSOCKET_SPLICE -DTCP_ECN -DTCP_SIGNATURE -DINET6 
-DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX -DMROUTING -DMPLS -DBOOT_CONFIG 
-DUSER_PCICONF -DAPERTURE -DMTRR -DNTFS -DHIBERNATE -DPCIVERBOSE -DEISAVERBOSE 
-DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD 
-DWSDISPLAY_DEFAULTSCREENS="6" -DX86EMU -DONEWIREVERBOSE -DMAXUSERS=80 
-D_KERNEL -MD -MP -MF assym.P > assym.h.tmp
error: unknown warning option '-Wno-unused-but-set-variable'; did you mean 
'-Wno-unused-const-variable'? [-Werror,-Wunknown-warning-option]
*** Error 1 in /usr/src/sys/arch/i386/compile/GENERIC (Makefile:1286 'assym.h')


Jan


OpenBSD 7.0-current (GENERIC) #345: Thu Dec 16 13:19:22 MST 2021
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem  = 259207168 (247MB)
avail mem = 238182400 (227MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 07/19/10, BIOS32 rev. 0 @ 0xfa950
apm0 at bios0: Power Management spec V1.2 (slowidle)
pcibios0 at bios0: rev 2.1 @ 0xf/0xdfb4
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf30/128 (6 entries)
pcibios0: PCI Exclusive IRQs: 5 10 11
pcibios0: no compatible PCI ICU found: ICU vendor 0x1022 product 0x2090
pcibios0: Warning, unable to fix up PCI interrupt routing
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0xa800 0xef000/0x1000!
cpu0 at mainbus0: (uniprocessor)
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 499 
MHz, 05-0a-02
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
mtrr: K6-family MTRR support (2 registers)
amdmsr0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
vga1 at pci0 dev 1 function 1 "AMD Geode LX Video" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 13 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address 
00:0d:b9:0e:9e:f4
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit 
3579545Hz timer, watchdog, gpio, i2c
gpio0 at glxpcib0: 32 pins
iic0 at glxpcib0
pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 1-sector PIO, LBA48, 15279MB, 31293360 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
auglx0 at pci0 dev 15 function 3 "AMD CS5536 Audio" rev 0x01: irq 11, CS5536 
AC97
ac97: codec id 0x414c4770 (Avance Logic ALC203 rev 0)
ac97: codec features headphone, 20 bit DAC, 18 bit ADC, No 3D Stereo
audio0 at auglx0
ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 5, version 1.0, 
legacy support
ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 5
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev 2.00/1.00 
addr 1
isa0 at glxpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
wbsio0 at isa0 port 0x2e/2: W83627HF rev 0x41
lm1 at wbsio0 port 0x290/8: W83627HF
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "AMD OHCI root hub" rev 1.00/1.00 
addr 1
dt: 451 probes
umass0 at uhub0 port 4 configuration 1 interface 0 "JMicron USB to ATA/ATA

Re: acme-client error: unknown SAN entry

[David Higgs]

On Sun, Feb 7, 2021 at 4:49 PM Stuart Henderson  wrote:

> On 2021-02-07, David Higgs  wrote:
> >  acme-client: /etc/ssl/primary.example.com.crt: unknown SAN entry:
> > alternate.example.com
> > acme-client: bad exit: revokeproc(55821): 1
> >
> > (My real domain is legitimate, and not example.com.)
> >
> > I recently decommissioned one of the aliases for my servers, but my
> nightly
> > acme-client run threw an error.  Although I removed the alias from
> > acme-client.conf, it is obviously still present in my certificate and
> seems
> > to be confusing the renewal process.
> >
> > Does anyone know how to resolve this?  I tried force-renewal (-F) without
> > success but haven't tried revoking yet.  Is it possible to fix without
> > revocation?
> >
> > Thanks.
> >
> > --david
> >
>
> Update to -current, or move /etc/ssl/primary.example.com.crt out the way.
>

For the archives: I moved the cert as suggested, manually ran my nightly
script, and everything worked great.

Thanks!

--david

Re: acme-client error: unknown SAN entry

[Stuart Henderson]

On 2021-02-07, David Higgs  wrote:
>  acme-client: /etc/ssl/primary.example.com.crt: unknown SAN entry:
> alternate.example.com
> acme-client: bad exit: revokeproc(55821): 1
>
> (My real domain is legitimate, and not example.com.)
>
> I recently decommissioned one of the aliases for my servers, but my nightly
> acme-client run threw an error.  Although I removed the alias from
> acme-client.conf, it is obviously still present in my certificate and seems
> to be confusing the renewal process.
>
> Does anyone know how to resolve this?  I tried force-renewal (-F) without
> success but haven't tried revoking yet.  Is it possible to fix without
> revocation?
>
> Thanks.
>
> --david
>

Update to -current, or move /etc/ssl/primary.example.com.crt out the way.

acme-client error: unknown SAN entry

[David Higgs]

 acme-client: /etc/ssl/primary.example.com.crt: unknown SAN entry:
alternate.example.com
acme-client: bad exit: revokeproc(55821): 1

(My real domain is legitimate, and not example.com.)

I recently decommissioned one of the aliases for my servers, but my nightly
acme-client run threw an error.  Although I removed the alias from
acme-client.conf, it is obviously still present in my certificate and seems
to be confusing the renewal process.

Does anyone know how to resolve this?  I tried force-renewal (-F) without
success but haven't tried revoking yet.  Is it possible to fix without
revocation?

Thanks.

--david

Re: Unknown process modifying routing table

[Jan Stary]

On Feb 06 12:18:40, ja...@jmp-e.com wrote:
> I've disabled my VPN on the machine as well as dhclient, connecting via a
> fixed static IP address and DNS servers.

That would be a much aeasier environment to debug this.
So please show your hostname.if, mygate and your routing table
right after boot, and the log of

script -c 'route -n monitor' route.log

at least up to the first change.

Re: seeing carp interface state change for unknown reason ; cluestick hunting

[Markus Wernig]

On 2/7/21 1:38 AM, Bryan Stenson wrote:


   31 RTM_IFINFO: iface status change: len 168, if# 3, name cnmac2,
link: no carrier, mtu: 1500,



Just grasping for something here...my next steps are to swap this unit
out with the other one (to try and eliminate hardware failure of THIS
unit).  Any other suggestions?


Check the switch interface for any errors and messages.

Re: seeing carp interface state change for unknown reason ; cluestick hunting

[Bryan Stenson]

Thanks for the response.  I've mounted a ramdisk at /mnt and have run
"doas route -n monitor > /mnt/route.monitor" in a tmux session for a
few days.  Here are some details:

erl3-01$ grep carp1 route.monitor  | sort | uniq -c
  91 RTM_ADD: Add Route: len 192, priority 146, table 0, if# 6, name
carp1, pid: 0, seq 0, errno 0
 428 RTM_ADD: Add Route: len 192, priority 18, table 0, if# 6, name
carp1, pid: 0, seq 0, errno 0
  43 RTM_DELETE: Delete Route: len 192, priority 146, table 0, if# 6,
name carp1, pid: 0, seq 0, errno 0
 478 RTM_DELETE: Delete Route: len 192, priority 18, table 0, if# 6,
name carp1, pid: 0, seq 0, errno 0
  31 RTM_IFINFO: iface status change: len 168, if# 6, name carp1,
link: backup, mtu: 1500,
flags:
  31 RTM_IFINFO: iface status change: len 168, if# 6, name carp1,
link: invalid, mtu: 1500, flags:
  31 RTM_IFINFO: iface status change: len 168, if# 6, name carp1,
link: master, mtu: 1500,
flags:
   1 RTM_RESOLVE: Route created by cloning: len 192, priority 146,
table 0, if# 6, name carp1, pid: 0, seq 0, errno 0
 385 RTM_RESOLVE: Route created by cloning: len 192, priority 18,
table 0, if# 6, name carp1, pid: 0, seq 0, errno 0

erl3-01$ grep vlan100 route.monitor  | sort | uniq -c
  31 RTM_IFINFO: iface status change: len 168, if# 8, name vlan100,
link: active, mtu: 1500,
flags:
  31 RTM_IFINFO: iface status change: len 168, if# 8, name vlan100,
link: no carrier, mtu: 1500,
flags:

erl3-01$ grep cnmac2 route.monitor  | sort | uniq -c
  57 RTM_ADD: Add Route: len 192, priority 3, table 0, if# 3, name
cnmac2, pid: 0, seq 0, errno 0
  57 RTM_DELETE: Delete Route: len 192, priority 3, table 0, if# 3,
name cnmac2, pid: 0, seq 0, errno 0
  31 RTM_IFINFO: iface status change: len 168, if# 3, name cnmac2,
link: active, mtu: 1500,
flags:
  31 RTM_IFINFO: iface status change: len 168, if# 3, name cnmac2,
link: no carrier, mtu: 1500,
flags:

It looks like the underlying cnmac2 interface is flapping...so, that's a bummer.

As generally underpowered as this machine is, might the kernel be
overwhelmed with other tasks, and have a watchdog timeout mark the
cnmac2 interface as down (due to some expired timeout)?

Just grasping for something here...my next steps are to swap this unit
out with the other one (to try and eliminate hardware failure of THIS
unit).  Any other suggestions?

On Mon, Feb 1, 2021 at 3:04 AM David Gwynne  wrote:
>
>
>
> > On 1 Feb 2021, at 6:02 pm, Bryan Stenson  wrote:
> >
> > Hi all -
> >
> > I'm trying to setup a pair of ERL3 octeon routers in master/standby
> > mode via carp/pfsync to route traffic from my internal lan to the
> > internet.  I've seen strange behavior wrt carp on these machines, so
> > in an attempt to reduce the problem, I've removed one completely.
> >
> > Even with only a single box (ERL3-01) on the network configured as a
> > carp member, the carp interface state periodically changes (as seen
> > from ifstated(8)).
> >
> > I'm wondering if disconnecting the other ERL3 device is a valid isolated 
> > test.
> > 1.  Will/might this cause issues with the carp device, as it cannot
> > determine state from any other host?
>
> If carp state flaps around while it is the only device on the network, that 
> would imply the parent device is flapping around.
>
> > 2.  Will/might this cause issues as it cannot send/receive pfsync
> > updates (the other node is disconnected).
>
> pfsync doesn't really care about carp state.
>
> > 3.  Is there something else in my setup causing carp to fail here?
>
> I'd be running "route monitor" and looking for link state changes on the carp 
> parent interface.
>
> > 4.  Could this be hardware/temperature related to this ERL3?  Wouldn't
> > I see an additional error in dmesg if the physical device (cnmac2)
> > failed periodically?
> >
> > I'd appreciate any pointers here...I feel like I'm missing something dumb.
>
> My first ideas are above. If it turns out the carp parent is stable we can 
> try come up with something else.
>
> dlg
>
> >
> > Thanks in advance.
> >
> > Bryan
> >
> > Here are some of my configs.  If I've missed including something
> > critical to help describe my setup, please let me know and I'll add
> > it.
> >
> > ## Help me OBSD-Misc Kenobi.  You're my only hope. ##
> >
> > erl3-01# uname -a
> > OpenBSD erl3-01.siliconvortex.com 6.8 GENERIC#522 octeon
> >
> > erl3-01# dmesg
> > ...
> > carp1: state transition: BACKUP -> MASTER
> > carp1: state transition: BACKUP -> MASTER
> > carp1: state transition: BACKUP -> MASTER
> > carp1: state transition: BACKUP -> MASTER
> > carp1: state transition: BACKUP -> MASTER
> > carp1: state transition: BACKUP -> MASTER
> >
> > erl3-01# tail mbox
> > Mon, 1 Feb 2021 06:49:26 + (UTC)
> > From: Charlie Root 
> > Date: Mon, 1 Feb 2021 06:49:25 + (UTC)
> > To: root@localhost
> > Subject: carp master changed
> > Message-ID: <515eb74cff427...@erl3-01.siliconvortex.com>
> > Status: RO
> >
> > master is now erl3-01.siliconvortex.com
> >
> >
> > erl3-01# sysctl -a | grep carp
> > 

Re: Unknown process modifying routing table

[Claudio Jeker]

On Sat, Feb 06, 2021 at 02:16:20PM +0100, Otto Moerbeek wrote:
> On Sat, Feb 06, 2021 at 12:18:40PM +, James wrote:
> 
> > I've disabled my VPN on the machine as well as dhclient, connecting via a
> > fixed static IP address and DNS servers. My routing table is still being
> > modifed by PID 0 (which I assume to be the kernel) every 30 minutes or so.
> > Ntpd is also disabled.
> > 
> > I have also caught my machine communicating to one the of the IPs via TCP
> > and have a pcap dump from wireshark. No actual data was sent other than a
> > TCP timestamp.
> > 
> > > If your default route is a VPN,
> > > please show how you establish the VPN to be your default route.
> > > 
> > The default route is established mannually in a script that is run after the
> > VPN starts. Essentially it does the following:
> > 
> >     route add $VPN_HOST $DEFAULT_GW
> > 
> >     route change default $VPN_HOST
> > 
> > 
> > I do not belive the VPN to be the cause of this problem.
> > 
> > 
> > Any tips on debugging the kernel to track the cause of these route changes
> > would be greatly appreciated.
> > 
> > 
> > Thanks,
> > 
> 
> The kernel uses the routing table to store things like PMTU discovery
> data and ARP entries,
> 

Also showing the route -n monitor output will help to identify what is
going on.

-- 
:wq Claudio

Re: Unknown process modifying routing table

[James]

I've disabled my VPN on the machine as well as dhclient, connecting via 
a fixed static IP address and DNS servers. My routing table is still 
being modifed by PID 0 (which I assume to be the kernel) every 30 
minutes or so. Ntpd is also disabled.


I have also caught my machine communicating to one the of the IPs via 
TCP and have a pcap dump from wireshark. No actual data was sent other 
than a TCP timestamp.



If your default route is a VPN,
please show how you establish the VPN to be your default route.

The default route is established mannually in a script that is run after 
the VPN starts. Essentially it does the following:


    route add $VPN_HOST $DEFAULT_GW

    route change default $VPN_HOST


I do not belive the VPN to be the cause of this problem.


Any tips on debugging the kernel to track the cause of these route 
changes would be greatly appreciated.



Thanks,

Re: Unknown process modifying routing table

[Otto Moerbeek]

On Sat, Feb 06, 2021 at 12:18:40PM +, James wrote:

> I've disabled my VPN on the machine as well as dhclient, connecting via a
> fixed static IP address and DNS servers. My routing table is still being
> modifed by PID 0 (which I assume to be the kernel) every 30 minutes or so.
> Ntpd is also disabled.
> 
> I have also caught my machine communicating to one the of the IPs via TCP
> and have a pcap dump from wireshark. No actual data was sent other than a
> TCP timestamp.
> 
> > If your default route is a VPN,
> > please show how you establish the VPN to be your default route.
> > 
> The default route is established mannually in a script that is run after the
> VPN starts. Essentially it does the following:
> 
>     route add $VPN_HOST $DEFAULT_GW
> 
>     route change default $VPN_HOST
> 
> 
> I do not belive the VPN to be the cause of this problem.
> 
> 
> Any tips on debugging the kernel to track the cause of these route changes
> would be greatly appreciated.
> 
> 
> Thanks,
> 

The kernel uses the routing table to store things like PMTU discovery
data and ARP entries,

-Otto

Re: Unknown process modifying routing table

[Jan Stary]

On Jan 26 15:10:03, ja...@jmp-e.com wrote:
> 
> Hi all,
> 
> My routing table is being modified by an unknown process.
> 
> I have system accounting enabled and I'm monitoring route changes
> but the PID of the process reported by `route monitor` is always 0
> for these unknown changes.
> 
> I've seen my default route (VPN) being deleted and new routes being
> added for specific IPs. I'm out of ideas how to find out what process
> is modifying my routing table.

If your default route is a VPN,
please show how you establish the VPN to be your default route.

> Here are the logs:
> 
> bash-5.0# route -n show
> Routing tables
> 
> Internet:
> DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
> default10.0.0.1   UGS   15  635 - 8 pair1
> 224/4  127.0.0.1  URS00 32768 8 lo0
> 10.0.0/24  10.0.0.2   UCn10 - 4 pair1
> 10.0.0.1   xx:xx:xx:xx:xx:xx  UHLch 20   76 - 3 pair1
> 10.0.0.2   xx:xx:xx:xx:xx:xx  UHLl   0  251 - 1 pair1
> 10.0.0.255 10.0.0.2   UHb00 - 1 pair1
> 10.2.0.1   10.0.0.1   UGHD   1  599 - L   8 pair1
> 13.35.193.117  10.0.0.1   UGHD   1  616 - L   8 pair1
> 13.224.227.64  10.0.0.1   UGHD   1  611 - L   8 pair1
> 52.48.109.111  10.0.0.1   UGHD   1  614 - L   8 pair1
> 52.84.91.7 10.0.0.1   UGHD   1  574 - L   8 pair1
> 99.84.5.23010.0.0.1   UGHD   1  620 - L   8 pair1
> 104.16.9.251   10.0.0.1   UGHD   0  289  1350 8 pair1
> 104.16.241.18  10.0.0.1   UGHD   1  610 - L   8 pair1
> 104.18.26.20   10.0.0.1   UGHD   1  609 - L   8 pair1
> 104.21.22.28   10.0.0.1   UGHD   1  617 - L   8 pair1
> 108.177.120.13610.0.0.1   UGHD   1  625 - L   8 pair1
> 127/8  127.0.0.1  UGRS   00 32768 8 lo0
> 127.0.0.1  127.0.0.1  UHhl   8 7322 32768 1 lo0
> 140.82.121.3   10.0.0.1   UGHD   1  636 - L   8 pair1
> 142.250.186.12910.0.0.1   UGHD   1  604 - L   8 pair1
> 157.230.120.63 10.0.0.1   UGHD   1  596 - L   8 pair1
> 172.67.203.118 10.0.0.1   UGHD   1  607 - L   8 pair1
> 172.217.169.86 10.0.0.1   UGHD   1  632 - L   8 pair1
> 185.199.111.15410.0.0.1   UGHD   2  633 - L   8 pair1
> 216.58.206.132 10.0.0.1   UGHD   1  624 - L   8 pair1
> 216.58.212.227 10.0.0.1   UGHD   1  629 - L   8 pair1

> The routes for 216.58.212.227, 216.58.206.132, 185.199.111.154,
> 172.217.169.86, 172.67.203.118, 157.230.120.63, 142.250.186.129,
> 140.82.121.3, 108.177.120.136, 104.21.22.28, 104.18.26.20,
> 104.16.241.18, 104.16.9.251, 99.84.5.230, 52.48.109.111, 52.84.5.230,
> 13.224.227.64, 13.35.193.117 are completely unknown and not added by
> myself.

These are probably added by your VPN setup.

Jan

Unknown process modifying routing table

[James]

Hi all, 

My routing table is being modified by an unknown process. 


I have system accounting enabled and I'm monitoring route changes
but the PID of the process reported by `route monitor` is always 0
for these unknown changes.

I've seen my default route (VPN) being deleted and new routes being
added for specific IPs. I'm out of ideas how to find out what process
is modifying my routing table.

Here are the logs:

bash-5.0# route -n show
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default10.0.0.1   UGS   15  635 - 8 pair1
224/4  127.0.0.1  URS00 32768 8 lo0
10.0.0/24  10.0.0.2   UCn10 - 4 pair1
10.0.0.1   xx:xx:xx:xx:xx:xx  UHLch 20   76 - 3 pair1
10.0.0.2   xx:xx:xx:xx:xx:xx  UHLl   0  251 - 1 pair1
10.0.0.255 10.0.0.2   UHb00 - 1 pair1
10.2.0.1   10.0.0.1   UGHD   1  599 - L   8 pair1
13.35.193.117  10.0.0.1   UGHD   1  616 - L   8 pair1
13.224.227.64  10.0.0.1   UGHD   1  611 - L   8 pair1
52.48.109.111  10.0.0.1   UGHD   1  614 - L   8 pair1
52.84.91.7 10.0.0.1   UGHD   1  574 - L   8 pair1
99.84.5.23010.0.0.1   UGHD   1  620 - L   8 pair1
104.16.9.251   10.0.0.1   UGHD   0  289  1350 8 pair1
104.16.241.18  10.0.0.1   UGHD   1  610 - L   8 pair1
104.18.26.20   10.0.0.1   UGHD   1  609 - L   8 pair1
104.21.22.28   10.0.0.1   UGHD   1  617 - L   8 pair1
108.177.120.13610.0.0.1   UGHD   1  625 - L   8 pair1
127/8  127.0.0.1  UGRS   00 32768 8 lo0
127.0.0.1  127.0.0.1  UHhl   8 7322 32768 1 lo0
140.82.121.3   10.0.0.1   UGHD   1  636 - L   8 pair1
142.250.186.12910.0.0.1   UGHD   1  604 - L   8 pair1
157.230.120.63 10.0.0.1   UGHD   1  596 - L   8 pair1
172.67.203.118 10.0.0.1   UGHD   1  607 - L   8 pair1
172.217.169.86 10.0.0.1   UGHD   1  632 - L   8 pair1
185.199.111.15410.0.0.1   UGHD   2  633 - L   8 pair1
216.58.206.132 10.0.0.1   UGHD   1  624 - L   8 pair1
216.58.212.227 10.0.0.1   UGHD   1  629 - L   8 pair1

Internet6:
DestinationGatewayFlags   Refs  
Use   Mtu  Prio Iface
::/96  ::1UGRS   0  
  0 32768 8 lo0
::1::1UHhl  10  
 32 32768 1 lo0
:::0.0.0.0/96  ::1UGRS   0  
  0 32768 8 lo0
2002::/24  ::1UGRS   0  
  0 32768 8 lo0
2002:7f00::/24 ::1UGRS   0  
  0 32768 8 lo0
2002:e000::/20 ::1UGRS   0  
  0 32768 8 lo0
2002:ff00::/24 ::1UGRS   0  
  0 32768 8 lo0
fe80::/10  ::1UGRS   0  
  0 32768 8 lo0
fec0::/10  ::1UGRS   0  
  0 32768 8 lo0
fe80::1%lo0fe80::1%lo0UHl0  
  0 32768 1 lo0
ff01::/16  ::1UGRS   5  
  5 32768 8 lo0
ff01::%lo0/32  fe80::1%lo0Um 0  
  1 32768 4 lo0
ff02::/16  ::1UGRS   5  
  5 32768 8 lo0
ff02::%lo0/32  fe80::1%lo0Um 0  
  1 32768 4 lo0


The routes for 216.58.212.227, 216.58.206.132, 185.199.111.154,
172.217.169.86, 172.67.203.118, 157.230.120.63, 142.250.186.129,
140.82.121.3, 108.177.120.136, 104.21.22.28, 104.18.26.20,
104.16.241.18, 104.16.9.251, 99.84.5.230, 52.48.109.111, 52.84.5.230,
13.224.227.64, 13.35.193.117 are completely unknown and not added by
myself. 


bash-5.0# route monitor
got message of size 176 on Tue Jan 26 13:13:16 2021
RTM_DELETE: Delete Route: len 176, priority 8, table 0, if# 8, name pair1, pid: 
0, seq 0, errno 0
flags:
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: 
 172.67.203.118 10.0.0.1 xx:xx:xx:xx:xx:xx 10.0.0.2
got message of size 176 on Tue Jan 26 13:13:16 2021
RTM_DELETE

Re: seeing carp interface state change for unknown reason ; cluestick hunting

[David Gwynne]

> On 1 Feb 2021, at 6:02 pm, Bryan Stenson  wrote:
> 
> Hi all -
> 
> I'm trying to setup a pair of ERL3 octeon routers in master/standby
> mode via carp/pfsync to route traffic from my internal lan to the
> internet.  I've seen strange behavior wrt carp on these machines, so
> in an attempt to reduce the problem, I've removed one completely.
> 
> Even with only a single box (ERL3-01) on the network configured as a
> carp member, the carp interface state periodically changes (as seen
> from ifstated(8)).
> 
> I'm wondering if disconnecting the other ERL3 device is a valid isolated test.
> 1.  Will/might this cause issues with the carp device, as it cannot
> determine state from any other host?

If carp state flaps around while it is the only device on the network, that 
would imply the parent device is flapping around.

> 2.  Will/might this cause issues as it cannot send/receive pfsync
> updates (the other node is disconnected).

pfsync doesn't really care about carp state.

> 3.  Is there something else in my setup causing carp to fail here?

I'd be running "route monitor" and looking for link state changes on the carp 
parent interface.

> 4.  Could this be hardware/temperature related to this ERL3?  Wouldn't
> I see an additional error in dmesg if the physical device (cnmac2)
> failed periodically?
> 
> I'd appreciate any pointers here...I feel like I'm missing something dumb.

My first ideas are above. If it turns out the carp parent is stable we can try 
come up with something else.

dlg

> 
> Thanks in advance.
> 
> Bryan
> 
> Here are some of my configs.  If I've missed including something
> critical to help describe my setup, please let me know and I'll add
> it.
> 
> ## Help me OBSD-Misc Kenobi.  You're my only hope. ##
> 
> erl3-01# uname -a
> OpenBSD erl3-01.siliconvortex.com 6.8 GENERIC#522 octeon
> 
> erl3-01# dmesg
> ...
> carp1: state transition: BACKUP -> MASTER
> carp1: state transition: BACKUP -> MASTER
> carp1: state transition: BACKUP -> MASTER
> carp1: state transition: BACKUP -> MASTER
> carp1: state transition: BACKUP -> MASTER
> carp1: state transition: BACKUP -> MASTER
> 
> erl3-01# tail mbox
> Mon, 1 Feb 2021 06:49:26 + (UTC)
> From: Charlie Root 
> Date: Mon, 1 Feb 2021 06:49:25 + (UTC)
> To: root@localhost
> Subject: carp master changed
> Message-ID: <515eb74cff427...@erl3-01.siliconvortex.com>
> Status: RO
> 
> master is now erl3-01.siliconvortex.com
> 
> 
> erl3-01# sysctl -a | grep carp
> net.inet.carp.allow=1
> net.inet.carp.preempt=1
> net.inet.carp.log=2
> 
> erl3-01# cat /etc/hostname.carp1
> #carp for lan side
> 192.168.122.1/23 carpdev vlan100 vhid 1 pass somethinglongandsecret
> 
> erl3-01# cat /etc/hostname.vlan100
> vnetid 100 parent cnmac2
> up
> 
> erl3-01# cat /etc/hostname.cnmac2
> inet 192.168.1.253 255.255.254.0
> 
> erl3-01# cat /etc/hostname.pfsync0
> up syncdev cnmac1
> 
> erl3-01# cat /etc/hostname.cnmac1
> inet 10.10.200.1 255.255.255.252
> 
> erl3-01# cat /etc/ifstated.conf
> # Initial State
> init-state auto
> 
> # Macros
> if_carp_up="carp1.link.up"
> if_carp_down="!carp1.link.up"
> 
> state auto {
>  if $if_carp_up {
>set-state master
>  }
> 
>  if $if_carp_down {
>set-state backup
>  }
> }
> 
> state master {
>  init {
>run "echo master is now `hostname` | mail -s 'carp master changed'
> root@localhost"
> }
> 
>  if $if_carp_down {
>set-state backup
>  }
> }
> 
> state backup {
>  init {
>run "echo backup is now `hostname` | mail -s 'carp master changed
> root@localhost"
>  }
> 
>  if $if_carp_up {
>set-state master
>  }
> }
> 
> erl3-01# cat /etc/pf.conf
> # adopted from https://www.openbsd.org/faq/pf/example1.html
> wan_dev = cnmac0
> lan_dev = cnmac2
> carp_dev = vlan100
> pfsync_dev = cnmac1
> table  { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16 \
>172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
>192.168.0.0/16 198.18.0.0/15 198.51.100.0/24\
>203.0.113.0/24 }
> 
> # carp
> pass quick on $lan_dev proto carp keep state (no-sync)
> 
> # pfsync
> pass quick on $pfsync_dev proto pfsync keep state (no-sync)
> 
> set block-policy drop
> set loginterface $wan_dev
> set skip on lo0
> 
> match in all scrub (no-df random-id max-mss 1440)
> 
> # redirect DNS queries to localhost
> pass in quick on { $carp_dev $lan_dev } proto { udp tcp } from any to
> any port domain rdr-to 192.168.1.253 port domain
> 
> # NAT to the world
> match out on $wan_dev inet from !($wan_dev:network) to any nat-to ($wan_dev:0)
> 
> antispoof quick for { $wan_dev }
> 
> # martians
> block in quick on $wan_dev from  to any
> block return out quick on $wan_dev from any to 
> 
> block all
> 
> # manage buffer bloat
> queue outq on $wan_dev flows 1024 bandwidth 3M max 3M qlimit 1024 default
> queue inq on $lan_dev flows 1024 bandwidth 45M max 45M qlimit 1024 default
> 
> pass out quick inet
> 
> pass in on { $carp_dev $lan_dev } inet
> 

seeing carp interface state change for unknown reason ; cluestick hunting

[Bryan Stenson]

Hi all -

I'm trying to setup a pair of ERL3 octeon routers in master/standby
mode via carp/pfsync to route traffic from my internal lan to the
internet.  I've seen strange behavior wrt carp on these machines, so
in an attempt to reduce the problem, I've removed one completely.

Even with only a single box (ERL3-01) on the network configured as a
carp member, the carp interface state periodically changes (as seen
from ifstated(8)).

I'm wondering if disconnecting the other ERL3 device is a valid isolated test.
1.  Will/might this cause issues with the carp device, as it cannot
determine state from any other host?
2.  Will/might this cause issues as it cannot send/receive pfsync
updates (the other node is disconnected).
3.  Is there something else in my setup causing carp to fail here?
4.  Could this be hardware/temperature related to this ERL3?  Wouldn't
I see an additional error in dmesg if the physical device (cnmac2)
failed periodically?

I'd appreciate any pointers here...I feel like I'm missing something dumb.

Thanks in advance.

Bryan

Here are some of my configs.  If I've missed including something
critical to help describe my setup, please let me know and I'll add
it.

## Help me OBSD-Misc Kenobi.  You're my only hope. ##

erl3-01# uname -a
OpenBSD erl3-01.siliconvortex.com 6.8 GENERIC#522 octeon

erl3-01# dmesg
...
carp1: state transition: BACKUP -> MASTER
carp1: state transition: BACKUP -> MASTER
carp1: state transition: BACKUP -> MASTER
carp1: state transition: BACKUP -> MASTER
carp1: state transition: BACKUP -> MASTER
carp1: state transition: BACKUP -> MASTER

erl3-01# tail mbox
Mon, 1 Feb 2021 06:49:26 + (UTC)
From: Charlie Root 
Date: Mon, 1 Feb 2021 06:49:25 + (UTC)
To: root@localhost
Subject: carp master changed
Message-ID: <515eb74cff427...@erl3-01.siliconvortex.com>
Status: RO

master is now erl3-01.siliconvortex.com


erl3-01# sysctl -a | grep carp
net.inet.carp.allow=1
net.inet.carp.preempt=1
net.inet.carp.log=2

erl3-01# cat /etc/hostname.carp1
#carp for lan side
192.168.122.1/23 carpdev vlan100 vhid 1 pass somethinglongandsecret

erl3-01# cat /etc/hostname.vlan100
vnetid 100 parent cnmac2
up

erl3-01# cat /etc/hostname.cnmac2
inet 192.168.1.253 255.255.254.0

erl3-01# cat /etc/hostname.pfsync0
up syncdev cnmac1

erl3-01# cat /etc/hostname.cnmac1
inet 10.10.200.1 255.255.255.252

erl3-01# cat /etc/ifstated.conf
# Initial State
init-state auto

# Macros
if_carp_up="carp1.link.up"
if_carp_down="!carp1.link.up"

state auto {
  if $if_carp_up {
set-state master
  }

  if $if_carp_down {
set-state backup
  }
}

state master {
  init {
run "echo master is now `hostname` | mail -s 'carp master changed'
root@localhost"
}

  if $if_carp_down {
set-state backup
  }
}

state backup {
  init {
run "echo backup is now `hostname` | mail -s 'carp master changed
root@localhost"
  }

  if $if_carp_up {
set-state master
  }
}

erl3-01# cat /etc/pf.conf
# adopted from https://www.openbsd.org/faq/pf/example1.html
wan_dev = cnmac0
lan_dev = cnmac2
carp_dev = vlan100
pfsync_dev = cnmac1
table  { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16 \
172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
192.168.0.0/16 198.18.0.0/15 198.51.100.0/24\
203.0.113.0/24 }

# carp
pass quick on $lan_dev proto carp keep state (no-sync)

# pfsync
pass quick on $pfsync_dev proto pfsync keep state (no-sync)

set block-policy drop
set loginterface $wan_dev
set skip on lo0

match in all scrub (no-df random-id max-mss 1440)

# redirect DNS queries to localhost
pass in quick on { $carp_dev $lan_dev } proto { udp tcp } from any to
any port domain rdr-to 192.168.1.253 port domain

# NAT to the world
match out on $wan_dev inet from !($wan_dev:network) to any nat-to ($wan_dev:0)

antispoof quick for { $wan_dev }

# martians
block in quick on $wan_dev from  to any
block return out quick on $wan_dev from any to 

block all

# manage buffer bloat
queue outq on $wan_dev flows 1024 bandwidth 3M max 3M qlimit 1024 default
queue inq on $lan_dev flows 1024 bandwidth 45M max 45M qlimit 1024 default

pass out quick inet

pass in on { $carp_dev $lan_dev } inet

Re: search contains unknown domain in resolv.conf

[Otto Moerbeek]

On Tue, Oct 27, 2020 at 11:44:21PM +0300, Andreas X wrote:

> ignore domain-search;
> supersede domain-name mail.myserver.tld;
> supersede domain-search mail.myserver.tld;
> 
> None of these lines have worked in dhclient.conf

The domain name need to be quoted.

What did you do exactly? Did you restart dhclient? Anything in logs?
What are the contents of resolv.conf after re-aquiring a lease?

-Otto

> 
> Anything else I could try?
> 
> Thank you.
> 
> 
> 
> 27 Ekim 2020 Salı tarihinde Otto Moerbeek  yazdı:
> 
> > On Tue, Oct 27, 2020 at 02:32:46PM +0300, Andreas X wrote:
> >
> > > Greetings. On OpenBSD 6.8, I have unbound enabled in my server, (server
> > > gets its IP via DHCP from my server provider)
> > > In resolv.conf I have a "search your-server.de" line and I don't know
> > what
> > > hostname is that.
> > > My own hostname is something different.
> > >
> > > That seems the older hostname during setup (I forgot to set hostname
> > during
> > > installation). I changed hostname, removed it from resolv.conf, rebooted,
> > > it's back again (DHCP - generated by re0 dhclient) How can I
> > remove/change
> > > that line?
> > >
> > > P.S: I have unbound enabled, therefore I created dhclient.conf and added:
> > > supersede domain-name-servers 127.0.0.1, my.server.provider.IP;
> > >
> > > openbsdl# cat /etc/resolv.conf
> > > # Generated by re0 dhclient
> > > search your-server.de
> > > nameserver 127.0.0.1
> > > lookup file bind
> > >
> > > Thanks.
> >
> > You can tell dhclient to ignore things.
> >
> > something like
> >
> > ignore domain-search;
> >
> > in dhclient.conf. See dhclient.conf and dhcp-options man pages.
> >
> > -Otto
> >

Re: search contains unknown domain in resolv.conf

[Andreas X]

ignore domain-search;
supersede domain-name mail.myserver.tld;
supersede domain-search mail.myserver.tld;

None of these lines have worked in dhclient.conf

Anything else I could try?

Thank you.



27 Ekim 2020 Salı tarihinde Otto Moerbeek  yazdı:

> On Tue, Oct 27, 2020 at 02:32:46PM +0300, Andreas X wrote:
>
> > Greetings. On OpenBSD 6.8, I have unbound enabled in my server, (server
> > gets its IP via DHCP from my server provider)
> > In resolv.conf I have a "search your-server.de" line and I don't know
> what
> > hostname is that.
> > My own hostname is something different.
> >
> > That seems the older hostname during setup (I forgot to set hostname
> during
> > installation). I changed hostname, removed it from resolv.conf, rebooted,
> > it's back again (DHCP - generated by re0 dhclient) How can I
> remove/change
> > that line?
> >
> > P.S: I have unbound enabled, therefore I created dhclient.conf and added:
> > supersede domain-name-servers 127.0.0.1, my.server.provider.IP;
> >
> > openbsdl# cat /etc/resolv.conf
> > # Generated by re0 dhclient
> > search your-server.de
> > nameserver 127.0.0.1
> > lookup file bind
> >
> > Thanks.
>
> You can tell dhclient to ignore things.
>
> something like
>
> ignore domain-search;
>
> in dhclient.conf. See dhclient.conf and dhcp-options man pages.
>
> -Otto
>

Re: search contains unknown domain in resolv.conf

[Otto Moerbeek]

On Tue, Oct 27, 2020 at 02:32:46PM +0300, Andreas X wrote:

> Greetings. On OpenBSD 6.8, I have unbound enabled in my server, (server
> gets its IP via DHCP from my server provider)
> In resolv.conf I have a "search your-server.de" line and I don't know what
> hostname is that.
> My own hostname is something different.
> 
> That seems the older hostname during setup (I forgot to set hostname during
> installation). I changed hostname, removed it from resolv.conf, rebooted,
> it's back again (DHCP - generated by re0 dhclient) How can I remove/change
> that line?
> 
> P.S: I have unbound enabled, therefore I created dhclient.conf and added:
> supersede domain-name-servers 127.0.0.1, my.server.provider.IP;
> 
> openbsdl# cat /etc/resolv.conf
> # Generated by re0 dhclient
> search your-server.de
> nameserver 127.0.0.1
> lookup file bind
> 
> Thanks.

You can tell dhclient to ignore things. 

something like 

ignore domain-search;

in dhclient.conf. See dhclient.conf and dhcp-options man pages.

-Otto

Re: search contains unknown domain in resolv.conf

[Tommy Nevtelen]

On 27/10/2020 12.32, Andreas X wrote:


Greetings. On OpenBSD 6.8, I have unbound enabled in my server, (server
gets its IP via DHCP from my server provider)
In resolv.conf I have a "search your-server.de" line and I don't know what
hostname is that.
My own hostname is something different.

That seems the older hostname during setup (I forgot to set hostname during
installation). I changed hostname, removed it from resolv.conf, rebooted,
it's back again (DHCP - generated by re0 dhclient) How can I remove/change
that line?

P.S: I have unbound enabled, therefore I created dhclient.conf and added:
supersede domain-name-servers 127.0.0.1, my.server.provider.IP;

openbsdl# cat /etc/resolv.conf
# Generated by re0 dhclient
search your-server.de


This tells me you run on Hetzner and their default domain names for VMs is just 
that.
"search" is not your hostname it is the search domain. This might be something 
they
push since you're in their environment.
But you probably need to log into the portal and change it there. Also don't
forget the PTR/Reverse DNS record. Or just configure your IP and hostname 
statically.

Hope this helps.


nameserver 127.0.0.1
lookup file bind

Thanks.


/T

search contains unknown domain in resolv.conf

[Andreas X]

Greetings. On OpenBSD 6.8, I have unbound enabled in my server, (server
gets its IP via DHCP from my server provider)
In resolv.conf I have a "search your-server.de" line and I don't know what
hostname is that.
My own hostname is something different.

That seems the older hostname during setup (I forgot to set hostname during
installation). I changed hostname, removed it from resolv.conf, rebooted,
it's back again (DHCP - generated by re0 dhclient) How can I remove/change
that line?

P.S: I have unbound enabled, therefore I created dhclient.conf and added:
supersede domain-name-servers 127.0.0.1, my.server.provider.IP;

openbsdl# cat /etc/resolv.conf
# Generated by re0 dhclient
search your-server.de
nameserver 127.0.0.1
lookup file bind

Thanks.

deny unknown-clients

[myml...@gmx.com]

Hi All,

I'm running openbsd current and running dhcpd, on all of my subnets I
use "deny unknown-clients;" and comment out the range.

I have a wireless access point defined in one subnet (192.168.0.0/24),
but not in another (192.168.1.0/24).   When I move the ethernet cable
from the interface where it's defined to the other interface, where it's
not defined, it still picks up an address, is this by design?

Clients that are not defined anywhere in the dhcpd.conf do get denied
addresses.

subnet 192.168.0.0 netmask 255.255.255.0 {
option routers 192.168.0.254;
option domain-name-servers 192.168.0.254;
#   range 192.168.0.33 192.168.0.127;
    deny unknown-clients;

host eap245 { hardware ethernet 78:da:d4:35:33:d0; fixed-address
192.168.0.1; }

}

subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.254;
option domain-name-servers 192.168.1.254;
#   range 192.168.1.33 192.168.1.127;
    deny unknown-clients;

}

Thanks in advance.

Re: Static IPv6, router tries to reach system with unknown fe80 address

[Stefan Hagen]

Denis Fondras wrote:

On Sat, Jul 13, 2019 at 12:15:30PM +0200, Stefan Hagen wrote:

Am I missing something?


OpenBSD has RFC7217 enabled by default. This means your LL address does not
embed your MAC address. Use "ifconfig vio0 -soii" to disable that behavior (see
ifconfig(8) for details).


Thank you very much! This didn't catch my eye when reading ifconfig(8).

Best Regards,
Stefan

Re: Static IPv6, router tries to reach system with unknown fe80 address

[Denis Fondras]

On Sat, Jul 13, 2019 at 12:15:30PM +0200, Stefan Hagen wrote:
> Hello,
> 
> I have a question regarding the IPv6 behavior of OpenBSD compared to
> Linux/FreeBSD. I tried to configure a static IPv6 address on my VPS.
> 
> From my provider, I got the following data:
> 
> IP Address: 2a01:4f8:c2c:76ef::/64
> Gateway: fe80::1
> 
> So I configured my interface:
> 
> $ cat /etc/hostname.vio0
> inet6 2a01:4f8:c2c:76ef::1 128
> 
> $ cat /etc/mygate
> fe80::1%vio0
> 
> Which results in:
> vio0: flags=8843 mtu 1500
>lladdr 96:00:00:2a:a9:8b
>index 1 priority 0 llprio 3
>groups: egress
>media: Ethernet autoselect
>status: active
>inet6 fe80::72f2:b265:b89c:b4ec%vio0 prefixlen 64 scopeid 0x1
>inet6 2a01:4f8:c2c:76ef::1 prefixlen 128
> 
> $ route -n show
> Internet6:
> Destination Gateway  Flags Refs Use Mtu Prio Iface
> default fe80::1%vio0 UGS  0  26   -8 vio0
> [...]
> 
> $ ndp -an
> Neighbor   Linklayer Address Netif ExpireS Flags
> 2a01:4f8:c2c:76ef::1   96:00:00:2a:a9:8b  vio0 permanent R l
> fe80::1%vio0   d2:74:7f:6e:37:e3  vio0 8h32m58s  S R
> fe80::3452:7ff:fe83:fa7b%vio0  d2:74:7f:6e:37:e3  vio0 10h9m34s  S R
> fe80::72f2:b265:b89c:b4ec%vio0 96:00:00:2a:a9:8b  vio0 permanent R l
> 
> While this configuration (just setting IP and gateway) leads to a
> working IPv6 connectivity on Linux and FreeBSD, it does not on OpenBSD
> and it took me while to figure out why.
> 
> While pinging an IPv6 only address, tcpdump revealed the following line
> repeating over and over again:
> 
> $ tcpdump -i vio0 ip6
> [...]
> 21:50:58.688256 fe80::3896:ecff:fe78:2702 > ff02::1:ff2a:a98b: \
>icmp6: neighbor sol: who has fe80::9400:ff:fe2a:a98b
> [...]
> 
> I then added the address fe80::9400:ff:fe2a:a98b as alias to my
> interface.
> 
> Now IPv6 works like a charm:
> 
> $ ifconfig vio0
> vio0: flags=8843 mtu 1500
>lladdr 96:00:00:2a:a9:8b
>index 1 priority 0 llprio 3
>groups: egress
>media: Ethernet autoselect
>status: active
>inet 116.203.83.222 netmask 0x
>inet6 fe80::72f2:b265:b89c:b4ec%vio0 prefixlen 64 scopeid 0x1
>inet6 2a01:4f8:c2c:76ef::1 prefixlen 128
>inet6 fe80::9400:ff:fe2a:a98b%vio0 prefixlen 64 scopeid 0x1
> 
> $ ndp -an
> Neighbor   Linklayer Address Netif ExpireS Flags
> 2a01:4f8:c2c:76ef::1   96:00:00:2a:a9:8b  vio0 permanent R l
> fe80::1%vio0   d2:74:7f:6e:37:e3  vio0 8h20m39s  S R
> fe80::3452:7ff:fe83:fa7b%vio0  d2:74:7f:6e:37:e3  vio0 9h57m15s  S R
> fe80::72f2:b265:b89c:b4ec%vio0 96:00:00:2a:a9:8b  vio0 permanent R l
> fe80::9400:ff:fe2a:a98b%vio0   96:00:00:2a:a9:8b  vio0 permanent R l
> 
> My assumption is, that the gateway definition of fe80::1 instructs the OS to
> "look around for a router". The router then offers(?) a new fe80 Address to
> communicate with my interface. But my interface doesn't know
> about it and ignores the request.
> 
> My assumption is probably wrong. Can someone help me to understand this
> scenario and how to make it work in OpenBSD without having to play with
> tcpdump?
> 
> Wasn't the router supposed to talk to me via fe80::72f2:b265:b89c:b4ec?
> Or should OpenBSD have assigned fe80::9400:ff:fe2a:a98b automatically as
> alias?
> 
> Compared with FreeBSD on a VM next to the OpenBSD one:
> 
> $ ifconfig vtnet0
> vtnet0: flags=8843 metric 0 mtu 1500
>options=[...line too long...]
>ether 96:00:00:2a:c9:de
>inet6 2a01:4f8:c2c:70f1::1 prefixlen 64
>inet6 fe80::9400:ff:fe2a:c9de%vtnet0 prefixlen 64 scopeid 0x1
>inet 116.203.86.85 netmask 0x broadcast 116.203.86.85
>media: Ethernet 10Gbase-T 
>status: active
>nd6 options=21
> 
> Here I see fe80::9400:ff:fe2a:c9de%vtnet0 set as local alias
> automatically. I'm not sure how this address is being generated and/or
> communicated between the OS and the router. But apparently there is a
> mismatch between router and OpenBSD, but not on Linux and FreeBSD.
> 
> Am I missing something?
> 

OpenBSD has RFC7217 enabled by default. This means your LL address does not
embed your MAC address. Use "ifconfig vio0 -soii" to disable that behavior (see
ifconfig(8) for details).

Static IPv6, router tries to reach system with unknown fe80 address

[Stefan Hagen]

Hello,

I have a question regarding the IPv6 behavior of OpenBSD compared to 
Linux/FreeBSD. I tried to configure a static IPv6 address on my VPS.



From my provider, I got the following data:


IP Address: 2a01:4f8:c2c:76ef::/64
Gateway: fe80::1

So I configured my interface:

$ cat /etc/hostname.vio0
inet6 2a01:4f8:c2c:76ef::1 128

$ cat /etc/mygate
fe80::1%vio0

Which results in:
vio0: flags=8843 mtu 1500
   lladdr 96:00:00:2a:a9:8b
   index 1 priority 0 llprio 3
   groups: egress
   media: Ethernet autoselect
   status: active
   inet6 fe80::72f2:b265:b89c:b4ec%vio0 prefixlen 64 scopeid 0x1
   inet6 2a01:4f8:c2c:76ef::1 prefixlen 128

$ route -n show
Internet6:
Destination Gateway  Flags Refs Use Mtu Prio Iface
default fe80::1%vio0 UGS  0  26   -8 vio0
[...]

$ ndp -an
Neighbor   Linklayer Address Netif ExpireS Flags
2a01:4f8:c2c:76ef::1   96:00:00:2a:a9:8b  vio0 permanent R l
fe80::1%vio0   d2:74:7f:6e:37:e3  vio0 8h32m58s  S R
fe80::3452:7ff:fe83:fa7b%vio0  d2:74:7f:6e:37:e3  vio0 10h9m34s  S R
fe80::72f2:b265:b89c:b4ec%vio0 96:00:00:2a:a9:8b  vio0 permanent R l

While this configuration (just setting IP and gateway) leads to a
working IPv6 connectivity on Linux and FreeBSD, it does not on OpenBSD
and it took me while to figure out why.

While pinging an IPv6 only address, tcpdump revealed the following line
repeating over and over again:

$ tcpdump -i vio0 ip6
[...]
21:50:58.688256 fe80::3896:ecff:fe78:2702 > ff02::1:ff2a:a98b: \
   icmp6: neighbor sol: who has fe80::9400:ff:fe2a:a98b
[...]

I then added the address fe80::9400:ff:fe2a:a98b as alias to my
interface.

Now IPv6 works like a charm:

$ ifconfig vio0
vio0: flags=8843 mtu 1500
   lladdr 96:00:00:2a:a9:8b
   index 1 priority 0 llprio 3
   groups: egress
   media: Ethernet autoselect
   status: active
   inet 116.203.83.222 netmask 0x
   inet6 fe80::72f2:b265:b89c:b4ec%vio0 prefixlen 64 scopeid 0x1
   inet6 2a01:4f8:c2c:76ef::1 prefixlen 128
   inet6 fe80::9400:ff:fe2a:a98b%vio0 prefixlen 64 scopeid 0x1

$ ndp -an
Neighbor   Linklayer Address Netif ExpireS Flags
2a01:4f8:c2c:76ef::1   96:00:00:2a:a9:8b  vio0 permanent R l
fe80::1%vio0   d2:74:7f:6e:37:e3  vio0 8h20m39s  S R
fe80::3452:7ff:fe83:fa7b%vio0  d2:74:7f:6e:37:e3  vio0 9h57m15s  S R
fe80::72f2:b265:b89c:b4ec%vio0 96:00:00:2a:a9:8b  vio0 permanent R l
fe80::9400:ff:fe2a:a98b%vio0   96:00:00:2a:a9:8b  vio0 permanent R l

My assumption is, that the gateway definition of fe80::1 instructs the 
OS to "look around for a router". The router then offers(?) a new fe80 
Address to communicate with my interface. But my interface doesn't know

about it and ignores the request.

My assumption is probably wrong. Can someone help me to understand this 
scenario and how to make it work in OpenBSD without having to play with

tcpdump?

Wasn't the router supposed to talk to me via fe80::72f2:b265:b89c:b4ec?
Or should OpenBSD have assigned fe80::9400:ff:fe2a:a98b automatically as 
alias?


Compared with FreeBSD on a VM next to the OpenBSD one:

$ ifconfig vtnet0
vtnet0: flags=8843 metric 0 mtu 1500
   options=[...line too long...]
   ether 96:00:00:2a:c9:de
   inet6 2a01:4f8:c2c:70f1::1 prefixlen 64
   inet6 fe80::9400:ff:fe2a:c9de%vtnet0 prefixlen 64 scopeid 0x1
   inet 116.203.86.85 netmask 0x broadcast 116.203.86.85
   media: Ethernet 10Gbase-T 
   status: active
   nd6 options=21

Here I see fe80::9400:ff:fe2a:c9de%vtnet0 set as local alias
automatically. I'm not sure how this address is being generated and/or 
communicated between the OS and the router. But apparently there is a 
mismatch between router and OpenBSD, but not on Linux and FreeBSD.


Am I missing something?

Best Regards,
Stefan

Re: amd64 cc error unknown argument '-msave-args'

[Theo de Raadt]

Anthony J. Bentley  wrote:

> Once again, the alternative is simple and well
> documented: build -stable from -stable, build -current from snaps.

Well said.

Re: amd64 cc error unknown argument '-msave-args'

[Theo de Raadt]

Jyri Hovila [Turvamies.fi]  wrote:

> > And since you are doing this with -current *ALL OVER THE PLACE*
> > there are instructions that if you have trouble you should upgrade
> > to a snapshot.
> 
> Theo, with all due respect, there are many situations where upgrading to a 
> snapshot really isn't an option.

Jyri,

That is incorrect.  The use of -current is "developer participation".
Snapshots are part of the developer "conversation".  They are built to
ensure we aren't making mistakes, and to help get over the hump when we
introduce incompatibilities which prevent build-over.  Many of the peopl
using them are testers helping ensure our FUTURE CODE DROP TO USERS --
which we release -- are in good shape.

RELEASES are used by "users".

SNAPSHOTS are used by developers, or people helping the development process.

These usage patterns are DISTINCT.

Everything you are saying is your DESIRE TO IMPOSE A DIFFERENT PROCESS
upon the developers, which is about 100 people already doing a hard
task, unlike you -- who are here carrying only "an opinion".

> > Those instructions to exist the noise on the list everytime we
> > make a change and people don't notice or understand it and suddenly
> > they are in over their heads
> 
> Again with all due respect, should all users of OpenBSD constantly
> watch the development in order to be able to use it?
> 
> Yes, I know: the CURRENT is not for production use, etc. etc. etc.

So you know the difference, but you wish to preach to us that we should
completely change our development process.

You really should just shut up.

> Then again: using RELEASE is a huge pain from the perspective of a
> server administrator with many [often virtual] hosts to maintain. The
> pain is so big that it actually drove me away from using OpenBSD for
> almost a decade.

Yes, life is hard.  Grow up or run something else.

> > *even our own developers* have to do that, from time to time
> 
> I'd say issues like this are the ones that prevent OpenBSD from being
> embraced by many otherwise potential users.

You are allowed to have incorrect opinions which don't matter to us,
but preaching to us is quite impolite.

Re: amd64 cc error unknown argument '-msave-args'

[John Rigg]

On Tue, Feb 05, 2019 at 07:23:59AM +0200, Jyri Hovila [Turvamies.fi] wrote:
> I must ask though: is it really so difficult to at least
> try and help people out, instead of lashing them?

As the OP I found the replies to my post helpful. I made
a mistake (missed out the release tag on the cvs command
when trying to update to -stable) and the replies immediately
alerted me to the problem.

> Then again: using RELEASE is a huge pain from the
> perspective of a server administrator with many [often
> virtual] hosts to maintain. The pain is so big that it
> actually drove me away from using OpenBSD for almost a
> decade.

Syspatch and the existence of third-party packagers like
m:tier have made it much less painful. Meanwhile, other
OS's, eg. Systemd/Linux, have become much more painful
(I say this after 20 years of Linux use).

John

Re: amd64 cc error unknown argument '-msave-args'

[Anthony J. Bentley]

Jyri Hovila [Turvamies.fi] writes:
> Theo, with all due respect, there are many situations where upgrading
> to a snapshot really isn't an option.

In such a situation, you shouldn't expect to be able to build -current
all the time. And the advice you'll always get is: update to a snapshot,
because that makes the build problems magically go away.

> > Those instructions to exist the noise on the list everytime we
> > make a change and people don't notice or understand it and suddenly
> > they are in over their heads
>
> Again with all due respect, should all users of OpenBSD constantly watch the 
> development in order to be able to use it?

The point of upgrading to a snapshot before building -current is you
don't have to be intimately familiar with what's going on in -current
that might affect a build.

> Then again: using RELEASE is a huge pain from the perspective of a server adm
> inistrator with many [often virtual] hosts to maintain. The pain is so big th
> at it actually drove me away from using OpenBSD for almost a decade.

This thread started with someone mistakenly building -current from
-stable. The OP intended to build -stable from -stable. The solution is
simple and documented: build -stable from -stable, build -current from
a snapshot, or even better, don't install from source if you can help it.

Is your suggestion that OpenBSD focus development effort on making it
possible to build -current from any conceivable post-6.4 checkout?
That seems an impossible task, one that would take time away from other
development efforts. Once again, the alternative is simple and well
documented: build -stable from -stable, build -current from snaps.

-- 
Anthony J. Bentley

Re: amd64 cc error unknown argument '-msave-args'

[Peter J. Philipp]

On Tue, Feb 05, 2019 at 07:23:59AM +0200, Jyri Hovila [Turvamies.fi] wrote:
> 
> > And since you are doing this with -current *ALL OVER THE PLACE*
> > there are instructions that if you have trouble you should upgrade
> > to a snapshot.
> 
> Theo, with all due respect, there are many situations where upgrading to a 
> snapshot really isn't an option.
> 
> > Those instructions to exist the noise on the list everytime we
> > make a change and people don't notice or understand it and suddenly
> > they are in over their heads
> 
> Again with all due respect, should all users of OpenBSD constantly watch the 
> development in order to be able to use it?

I watch the source changes with great interest sometimes and with lesser 
interest other times.  Sometimes life happens and it just flies past me, 
but other times I'm grateful that I watched source changes.   

What I like particularily is well-written commit messages that give me a 
good idea what the change was without having to go back to cvsweb to see 
the actual change.  Theo is probably _the_ person with the best described 
messages, and i put trust in those messages.

I ask you, if I can read source changes, why can't you?  I'm only a user 
as well.

> Yes, I know: the CURRENT is not for production use, etc. etc. etc.
> 
> Then again: using RELEASE is a huge pain from the perspective of a server 
> administrator with many [often virtual] hosts to maintain. The pain is so big 
> that it actually drove me away from using OpenBSD for almost a decade.
> 
> > *even our own developers* have to do that, from time to time
> 
> I'd say issues like this are the ones that prevent OpenBSD from being 
> embraced by many otherwise potential users.
> 
> It's your project and you're free to handle it as you will. You're world 
> famoous for "being difficult" in the sense that you don't seem to much care 
> about the opinions and experiences of the "normal" users, so it obviously 
> doesn't make sense to try and convert you from that -- that attitude is 
> almost as part of the trademark already.
> 
> I must ask though: is it really so difficult to at least try and help people 
> out, instead of lashing them?
> 
> I'd like to keep using OpenBSD, but I keep getting headaches due to the 
> "stick it up yours" attitude when problems arise.

I didn't get the feeling that the devs have this attitude.  Everyone is human
everyone has a bad day, and you must realise that developers have bigger
problems that we, the users, are let in on.  They are after all able to
meet regularily around the globe and identify the problems as well as ponder
about how to solve them.

> John, I'm getting the same problem with the amd64 version of CURRENT. 
> Updating to a snapshot is not an option in my scenario, so I'll try and 
> figure out how to get past the issue.
> 
> Theo, I honestly do appreciate you and the work you've done not just for 
> OpenBSD but also OpenSSH etc. I just can't understand why you're ruining the 
> [also commercial] potential by ignoring the needs of the users and by being 
> so god damn hostile against pretty much anyone who's not willing to humbly 
> submit to your idea of how things should be done.
> 
> -j.

I understand that OpenBSD is in it for themselves.  Us, the users who
follow the development do so for self-interest, and sometimes we get the
same result as the devs and we didn't do anything for that.  I find your
words to Theo somewhat pushy on a whole community, hence I'm writing this
to you.  It's just an instance where I don't agree, I like reading source
changes.

Regards,
-peter

Re: amd64 cc error unknown argument '-msave-args'

[Jyri Hovila [Turvamies.fi]]

> And since you are doing this with -current *ALL OVER THE PLACE*
> there are instructions that if you have trouble you should upgrade
> to a snapshot.

Theo, with all due respect, there are many situations where upgrading to a 
snapshot really isn't an option.

> Those instructions to exist the noise on the list everytime we
> make a change and people don't notice or understand it and suddenly
> they are in over their heads

Again with all due respect, should all users of OpenBSD constantly watch the 
development in order to be able to use it?

Yes, I know: the CURRENT is not for production use, etc. etc. etc.

Then again: using RELEASE is a huge pain from the perspective of a server 
administrator with many [often virtual] hosts to maintain. The pain is so big 
that it actually drove me away from using OpenBSD for almost a decade.

> *even our own developers* have to do that, from time to time

I'd say issues like this are the ones that prevent OpenBSD from being embraced 
by many otherwise potential users.

It's your project and you're free to handle it as you will. You're world 
famoous for "being difficult" in the sense that you don't seem to much care 
about the opinions and experiences of the "normal" users, so it obviously 
doesn't make sense to try and convert you from that -- that attitude is almost 
as part of the trademark already.

I must ask though: is it really so difficult to at least try and help people 
out, instead of lashing them?

I'd like to keep using OpenBSD, but I keep getting headaches due to the "stick 
it up yours" attitude when problems arise.

John, I'm getting the same problem with the amd64 version of CURRENT. Updating 
to a snapshot is not an option in my scenario, so I'll try and figure out how 
to get past the issue.

Theo, I honestly do appreciate you and the work you've done not just for 
OpenBSD but also OpenSSH etc. I just can't understand why you're ruining the 
[also commercial] potential by ignoring the needs of the users and by being so 
god damn hostile against pretty much anyone who's not willing to humbly submit 
to your idea of how things should be done.

-j.

Re: amd64 cc error unknown argument '-msave-args'

[John Rigg]

On Sun, Feb 03, 2019 at 02:51:08PM -0700, Theo de Raadt wrote:
> John Rigg  wrote:
> 
> > I'm trying to compile a GENERIC.MP kernel on amd64
> > 6.4 -stable.
> 
> No way, you are not.  Only -current has that, as of a few days ago.

I used the wrong cvs command and didn't spot it. Stupid mistake.
Sorry for the noise.

John

Re: amd64 cc error unknown argument '-msave-args'

[Theo de Raadt]

And since you are doing this with -current *ALL OVER THE PLACE*
there are instructions that if you have trouble you should upgrade
to a snapshot.

Those instructions to exist the noise on the list everytime we
make a change and people don't notice or understand it and suddenly
they are in over their heads

*even our own developers* have to do that, from time to time



> John Rigg  wrote:
> 
> > I'm trying to compile a GENERIC.MP kernel on amd64
> > 6.4 -stable.
> 
> No way, you are not.  Only -current has that, as of a few days ago.
> 
>  I've followed the instructions in the
> > FAQ for building a custom kernel, but the 'make'
> > step fails with an unknown argument: '-msave-args'
> > error. I've copied the compiler messages and dmesg
> > below. Suggestions for a cure or workaround would
> > be appreciated.=20
> > 
> > John
> > 
> > 
> > cat /usr/src/sys/arch/amd64/amd64/genassym.cf /usr/src/sys/arch/amd64/amd64=
> > /genassym.cf |  sh /usr/src/sys/kern/genassym.sh cc -no-integrated-as -g -W=
> > error -Wall -Wimplicit-function-declaration  -Wno-uninitialized -Wno-pointe=
> > r-sign  -Wframe-larger-than=3D2047 -Wno-address-of-packed-member -Wno-const=
> > ant-conversion -mcmodel=3Dkernel -mno-red-zone -mno-sse2 -mno-sse -mno-3dno=
> > w  -mno-mmx -msoft-float -fno-omit-frame-pointer -ffreestanding -fno-pie -m=
> > save-args -O2 -pipe -nostdinc -I/usr/src/sys -I/sys/arch/amd64/compile/GENE=
> > RIC.MP/obj -I/usr/src/sys/arch -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DK=
> > MEMSTATS -DPTRACE -DPOOL_DEBUG -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DUVM=
> > _SWAP_ENCRYPT -DFFS -DFFS2 -DFFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA -DEXT2FS=
> >  -DMFS -DNFSCLIENT -DNFSSERVER -DCD9660 -DUDF -DMSDOSFS -DFIFO -DFUSE -DSOC=
> > KET_SPLICE -DTCP_ECN -DTCP_SIGNATURE -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DE=
> > FLATE -DPIPEX -DMROUTING -DMPLS -DBOOT_CONFIG -DUSER_PCICONF -DAPERTURE -DM=
> > TRR -DNTFS -DHIBERNATE -DPCIVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DW=
> > SDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS=3D"6" -DX86EMU -DONEWIREV=
> > ERBOSE -DMULTIPROCESSOR -DMAXUSERS=3D80 -D_KERNEL -MD -MP -MF assym.P > ass=
> > ym.h.tmp
> > cc: error: unknown argument: '-msave-args'
> > *** Error 1 in /sys/arch/amd64/compile/GENERIC.MP (Makefile:1010 'assym.h')
> > 
> > 
> > dmesg
> > _
> > 
> > OpenBSD 6.4 (GENERIC.MP) #6: Sat Jan 26 20:37:44 CET 2019
> > r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENE=
> > RIC.MP
> > real mem =3D 4007526400 (3821MB)
> > avail mem =3D 3876790272 (3697MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (57 entries)
> > bios0: vendor Award Software International, Inc. version "F5" date 06/18/20=
> > 08
> > bios0: Gigabyte Technology Co., Ltd. GA-MA78GM-S2H
> > acpi0 at bios0: rev 0
> > acpi0: sleep states S0 S1 S4 S5
> > acpi0: tables DSDT FACP SSDT HPET MCFG APIC
> > acpi0: wakeup devices USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3)=
> >  USB6(S3) SBAZ(S4) P2P_(S5) PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PC=
> > E7(S4) PCE9(S4) [...]
> > acpitimer0 at acpi0: 3579545 Hz, 32 bits
> > acpihpet0 at acpi0: 14318180 Hz
> > acpimcfg0 at acpi0
> > acpimcfg0: addr 0xe000, bus 0-255
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: AMD Athlon(tm) Dual Core Processor 4850e, 2505.72 MHz, 0f-6b-02
> > cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE=
> > 36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,RDTSCP,LONG,3DNOW2=
> > ,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
> > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/l=
> > ine 16-way L2 cache
> > cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> > cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
> > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> > cpu0: apic clock running at 200MHz
> > cpu1 at mainbus0: apid 1 (application processor)
> > cpu1: AMD Athlon(tm) Dual Core Processor 4850e, 2505.33 MHz, 0f-6b-02
> > cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE=
> > 36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,RDTSCP,LONG,3DNOW2=
> > ,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
> > cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/l=
> > ine 16-way L2 cache
> > cpu1: ITLB 32 4KB 

Re: amd64 cc error unknown argument '-msave-args'

[Theo de Raadt]

John Rigg  wrote:

> I'm trying to compile a GENERIC.MP kernel on amd64
> 6.4 -stable.

No way, you are not.  Only -current has that, as of a few days ago.

 I've followed the instructions in the
> FAQ for building a custom kernel, but the 'make'
> step fails with an unknown argument: '-msave-args'
> error. I've copied the compiler messages and dmesg
> below. Suggestions for a cure or workaround would
> be appreciated.=20
> 
> John
> 
> 
> cat /usr/src/sys/arch/amd64/amd64/genassym.cf /usr/src/sys/arch/amd64/amd64=
> /genassym.cf |  sh /usr/src/sys/kern/genassym.sh cc -no-integrated-as -g -W=
> error -Wall -Wimplicit-function-declaration  -Wno-uninitialized -Wno-pointe=
> r-sign  -Wframe-larger-than=3D2047 -Wno-address-of-packed-member -Wno-const=
> ant-conversion -mcmodel=3Dkernel -mno-red-zone -mno-sse2 -mno-sse -mno-3dno=
> w  -mno-mmx -msoft-float -fno-omit-frame-pointer -ffreestanding -fno-pie -m=
> save-args -O2 -pipe -nostdinc -I/usr/src/sys -I/sys/arch/amd64/compile/GENE=
> RIC.MP/obj -I/usr/src/sys/arch -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DK=
> MEMSTATS -DPTRACE -DPOOL_DEBUG -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DUVM=
> _SWAP_ENCRYPT -DFFS -DFFS2 -DFFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA -DEXT2FS=
>  -DMFS -DNFSCLIENT -DNFSSERVER -DCD9660 -DUDF -DMSDOSFS -DFIFO -DFUSE -DSOC=
> KET_SPLICE -DTCP_ECN -DTCP_SIGNATURE -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DE=
> FLATE -DPIPEX -DMROUTING -DMPLS -DBOOT_CONFIG -DUSER_PCICONF -DAPERTURE -DM=
> TRR -DNTFS -DHIBERNATE -DPCIVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DW=
> SDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS=3D"6" -DX86EMU -DONEWIREV=
> ERBOSE -DMULTIPROCESSOR -DMAXUSERS=3D80 -D_KERNEL -MD -MP -MF assym.P > ass=
> ym.h.tmp
> cc: error: unknown argument: '-msave-args'
> *** Error 1 in /sys/arch/amd64/compile/GENERIC.MP (Makefile:1010 'assym.h')
> 
> 
> dmesg
> _
> 
> OpenBSD 6.4 (GENERIC.MP) #6: Sat Jan 26 20:37:44 CET 2019
> r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENE=
> RIC.MP
> real mem =3D 4007526400 (3821MB)
> avail mem =3D 3876790272 (3697MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (57 entries)
> bios0: vendor Award Software International, Inc. version "F5" date 06/18/20=
> 08
> bios0: Gigabyte Technology Co., Ltd. GA-MA78GM-S2H
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP SSDT HPET MCFG APIC
> acpi0: wakeup devices USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3)=
>  USB6(S3) SBAZ(S4) P2P_(S5) PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PC=
> E7(S4) PCE9(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpihpet0 at acpi0: 14318180 Hz
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xe000, bus 0-255
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD Athlon(tm) Dual Core Processor 4850e, 2505.72 MHz, 0f-6b-02
> cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE=
> 36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,RDTSCP,LONG,3DNOW2=
> ,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/l=
> ine 16-way L2 cache
> cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 200MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD Athlon(tm) Dual Core Processor 4850e, 2505.33 MHz, 0f-6b-02
> cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE=
> 36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,RDTSCP,LONG,3DNOW2=
> ,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
> cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/l=
> ine 16-way L2 cache
> cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins, remapped
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 3 (P2P_)
> acpiprt2 at acpi0: bus -1 (PCE2)
> acpiprt3 at acpi0: bus -1 (PCE3)
> acpiprt4 at acpi0: bus -1 (PCE4)
> acpiprt5 at acpi0: bus -1 (PCE5)
> acpiprt6 at acpi0: bus -1 (PCE6)
> acpiprt7 at acpi0: bus -1 (PCE7)
> acpiprt8 at acpi0: bus -1 (PCE9)
> acpiprt9 at acpi0: bus 2 (PCEA)
> acpiprt10 at acpi0: bus -1 (PCEB)
> acpiprt11 at acpi0: bus -1 (PCEC)
> acpiprt12 at acpi0: bus 1 (AGP_)
> acpicpu0 at acpi0: C1(@1 halt!), PSS
> acpicpu1 at acpi0: C1(@1 halt!

amd64 cc error unknown argument '-msave-args'

[John Rigg]

I'm trying to compile a GENERIC.MP kernel on amd64
6.4 -stable. I've followed the instructions in the
FAQ for building a custom kernel, but the 'make'
step fails with an unknown argument: '-msave-args'
error. I've copied the compiler messages and dmesg
below. Suggestions for a cure or workaround would
be appreciated.=20

John


cat /usr/src/sys/arch/amd64/amd64/genassym.cf /usr/src/sys/arch/amd64/amd64=
/genassym.cf |  sh /usr/src/sys/kern/genassym.sh cc -no-integrated-as -g -W=
error -Wall -Wimplicit-function-declaration  -Wno-uninitialized -Wno-pointe=
r-sign  -Wframe-larger-than=3D2047 -Wno-address-of-packed-member -Wno-const=
ant-conversion -mcmodel=3Dkernel -mno-red-zone -mno-sse2 -mno-sse -mno-3dno=
w  -mno-mmx -msoft-float -fno-omit-frame-pointer -ffreestanding -fno-pie -m=
save-args -O2 -pipe -nostdinc -I/usr/src/sys -I/sys/arch/amd64/compile/GENE=
RIC.MP/obj -I/usr/src/sys/arch -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DK=
MEMSTATS -DPTRACE -DPOOL_DEBUG -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DUVM=
_SWAP_ENCRYPT -DFFS -DFFS2 -DFFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA -DEXT2FS=
 -DMFS -DNFSCLIENT -DNFSSERVER -DCD9660 -DUDF -DMSDOSFS -DFIFO -DFUSE -DSOC=
KET_SPLICE -DTCP_ECN -DTCP_SIGNATURE -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DE=
FLATE -DPIPEX -DMROUTING -DMPLS -DBOOT_CONFIG -DUSER_PCICONF -DAPERTURE -DM=
TRR -DNTFS -DHIBERNATE -DPCIVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DW=
SDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS=3D"6" -DX86EMU -DONEWIREV=
ERBOSE -DMULTIPROCESSOR -DMAXUSERS=3D80 -D_KERNEL -MD -MP -MF assym.P > ass=
ym.h.tmp
cc: error: unknown argument: '-msave-args'
*** Error 1 in /sys/arch/amd64/compile/GENERIC.MP (Makefile:1010 'assym.h')


dmesg
_

OpenBSD 6.4 (GENERIC.MP) #6: Sat Jan 26 20:37:44 CET 2019
r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENE=
RIC.MP
real mem =3D 4007526400 (3821MB)
avail mem =3D 3876790272 (3697MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (57 entries)
bios0: vendor Award Software International, Inc. version "F5" date 06/18/20=
08
bios0: Gigabyte Technology Co., Ltd. GA-MA78GM-S2H
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP SSDT HPET MCFG APIC
acpi0: wakeup devices USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3)=
 USB6(S3) SBAZ(S4) P2P_(S5) PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PC=
E7(S4) PCE9(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) Dual Core Processor 4850e, 2505.72 MHz, 0f-6b-02
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE=
36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,RDTSCP,LONG,3DNOW2=
,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/l=
ine 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Athlon(tm) Dual Core Processor 4850e, 2505.33 MHz, 0f-6b-02
cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE=
36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,RDTSCP,LONG,3DNOW2=
,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/l=
ine 16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins, remapped
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (P2P_)
acpiprt2 at acpi0: bus -1 (PCE2)
acpiprt3 at acpi0: bus -1 (PCE3)
acpiprt4 at acpi0: bus -1 (PCE4)
acpiprt5 at acpi0: bus -1 (PCE5)
acpiprt6 at acpi0: bus -1 (PCE6)
acpiprt7 at acpi0: bus -1 (PCE7)
acpiprt8 at acpi0: bus -1 (PCE9)
acpiprt9 at acpi0: bus 2 (PCEA)
acpiprt10 at acpi0: bus -1 (PCEB)
acpiprt11 at acpi0: bus -1 (PCEC)
acpiprt12 at acpi0: bus 1 (AGP_)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpicpu1 at acpi0: C1(@1 halt!), PSS
acpibtn0 at acpi0: PWRB
acpicmos0 at acpi0
"PNP0C14" at acpi0 not configured
cpu0: PowerNow! K8 2505 MHz: speeds: 2500 2400 2200 2000 1800 1000 MHz
pci0 at mainbus0 bus 0
0:0:0: mem address conflict 0xe000/0x2000
pchb0 at pci0 dev 0 function 0 "AMD RS780 Host" rev 0x00
ppb0 at pci0 dev 1 function 0 "AMD RS780 PCIE" rev 0x00
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 5 function 0 "ATI Radeon HD 3200" rev 0x00
drm0 at radeondrm0
radeondrm0: apic 2 int 18
azalia0 at pci1 dev 5 function 1 "ATI RS780 H

Re: c++: error: unknown argument: '-fno-ret-protector' when compiling CURRENT userland

[Stuart Henderson]

On 2018-07-06, Jyri Hovila [iki]  wrote:
> Stuart,
>
> thank you so much for the info!
>
>> Your compiler is old (from 6.3 at a quick guess based on the date),
>> you either need to install a snapshot and move from there, or follow
>> http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/www/faq/current.html?rev=1.918=text/html#r20180606
>
> I've been following this "usual" version of the above document only:
>
> https://www.openbsd.org/faq/current.html
>
> There, it doesn't say a thing about the change in the compiler.
>
> Human error?
>
> Thanks again, Stuart!
>
> Yours,
>
> Jyri
>
>

It was added at the time of the change, then intentionally removed in r1.919,
the link I gave was before that removal. It's been readded now in r1.921
(http://cvsweb.openbsd.org/cgi-bin/cvsweb/www/faq/current.html) so will
show on the normal page again.
 

Re: c++: error: unknown argument: '-fno-ret-protector' when compiling CURRENT userland

[Jyri Hovila [iki]]

Stuart,

thank you so much for the info!

> Your compiler is old (from 6.3 at a quick guess based on the date),
> you either need to install a snapshot and move from there, or follow
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/www/faq/current.html?rev=1.918=text/html#r20180606

I've been following this "usual" version of the above document only:

https://www.openbsd.org/faq/current.html

There, it doesn't say a thing about the change in the compiler.

Human error?

Thanks again, Stuart!

Yours,

Jyri

c++: error: unknown argument: '-fno-ret-protector' when compiling CURRENT userland

[Jyri Hovila [iki]]

Hi!

Been following CURRENT for quite a while, experiencing zero problems.

However, now there's a problem compiling the 64-bit CURRENT on two servers -- 
one virtual, one full iron.

OpenBSD 6.3-current (GENERIC.MP) #19: Thu Jul  5 12:23:55 UTC 2018
***@***.turvamies.fi:/sys/arch/amd64/compile/GENERIC.MP

# cd /usr/src

# make obj
=> everyhing good

# make build
=> results in:
...
===> gnu/usr.bin/clang
===> gnu/usr.bin/clang/include/llvm/Config
printf "LLVM_ASM_PARSER(X86)\n#undef LLVM_ASM_PARSER\n" >AsmParsers.def
printf "LLVM_ASM_PRINTER(X86)\n#undef LLVM_ASM_PRINTER\n" >AsmPrinters.def
printf "LLVM_DISASSEMBLER(X86)\n#undef LLVM_DISASSEMBLER\n" >Disassemblers.def
printf "LLVM_TARGET(X86)\n#undef LLVM_TARGET\n" >Targets.def
===> gnu/usr.bin/clang/libLLVMSupport
c++ -O2 -pipe  -std=c++11 -fvisibility-inlines-hidden -fno-exceptions -fno-rtti 
-Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual  
-Wno-missing-field-initializers -pedantic -Wno-long-long  
-Wdelete-non-virtual-dtor -Wno-comment -fno-pie  -MD -MP  
-I/usr/src/gnu/usr.bin/clang/libLLVMSupport/../../../llvm/include/llvm/Support 
-I/usr/src/gnu/usr.bin/clang/libLLVMSupport/../../../llvm/include 
-I/usr/src/gnu/usr.bin/clang/libLLVMSupport/../include 
-I/usr/src/gnu/usr.bin/clang/libLLVMSupport/obj  
-I/usr/src/gnu/usr.bin/clang/libLLVMSupport/obj/../include -DNDEBUG 
-fno-ret-protector -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS  
-D__STDC_FORMAT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE="amd64-unknown-openbsd6.3" 
-DLLVM_HOST_TRIPLE="amd64-unknown-openbsd6.3" -DLLVM_PREFIX="/usr" 
-DLLVM_NATIVE_ARCH="X86" -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser 
-DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter 
-DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler 
-DLLVM_NATIVE_TARGET=LLVMInitializeX86Target 
-DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo 
-DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -c 
/usr/src/gnu/usr.bin/clang/libLLVMSupport/../../../llvm/lib/Support/APFloat.cpp 
-o APFloat.o
c++: error: unknown argument: '-fno-ret-protector'
*** Error 1 in gnu/usr.bin/clang/libLLVMSupport (:69 'APFloat.o': 
@c++ -O2 -pipe  -std=c++11 -fvisibility-inlines-hidden -fno-ex...)
*** Error 1 in gnu/usr.bin/clang (:48 'all')
*** Error 1 in gnu/usr.bin (:48 'all')
*** Error 1 in gnu (:48 'all')
*** Error 1 in . (:48 'all')
*** Error 1 in . (Makefile:95 'do-build')
*** Error 1 in /usr/src (Makefile:74 'build')

# c++ -v
OpenBSD clang version 6.0.0 (tags/RELEASE_600/final) (based on LLVM 6.0.0)
Target: amd64-unknown-openbsd6.3
Thread model: posix
InstalledDir: /usr/bin

# ls -la /usr/bin/c++*
-r-xr-xr-x  6 root  bin  46453496 Apr 25 10:10 /usr/bin/c++
-r-xr-xr-x  1 root  bin 10008 Apr 25 10:10 /usr/bin/c++filt

# /usr/bin/c++ -v
OpenBSD clang version 6.0.0 (tags/RELEASE_600/final) (based on LLVM 6.0.0)
Target: amd64-unknown-openbsd6.3
Thread model: posix
InstalledDir: /usr/bin

Can't figure out what's wrong.

Do I have an outdated version of c++ in the system for some reason?

Yours,

Jyri
--
jyri.hov...@iki.fi
+358-404-177133 (24/7)

Re: "fuse: unknown option gid=1000" with sshfs

[Helg Bredow]

This is fixed in the latest snapshot. Before this commit, even if gid or uid 
options were recognised, they would not have had an effect.


Please let me know if you find any other bugs - there are many :)


From: azarus <aza...@posteo.net>
Sent: Monday, 18 December 2017 8:11:52 PM
To: misc@openbsd.org
Cc: h...@openbsd.org
Subject: "fuse: unknown option gid=1000" with sshfs

Hi, list!

Since OpenBSD 6.0 removed the ability to mount filesystems as user, I've
been having issues getting directories mounted with sysutils/sshfs-fuse
to be accessible by users. I've tried setting

> -o uid=,gid=

when I mount the directory with this complete command line:

> doas sshfs -o uid=,gid= user@server:/dir /mnt

only to get this back:

> fuse: unknown option uid=1000

respectively, when gid is the first option:

> fuse: unknown option gid=1000

I've seen some recent changes regarding libfuse in the source tree, for
example this one:
https://marc.info/?l=openbsd-cvs=151299546729095=2
which would affect me, as I'm running -current:

OpenBSD 6.2-current (GENERIC.MP) #296: Sun Dec 17 16:43:20 MST 2017

Help would be greatly appreciated.

--
azarus
email: aza...@posteo.net
xmpp:  aza...@azarus.ch
PGP:   3A79D6CFD2567CF9

"fuse: unknown option gid=1000" with sshfs

[azarus]

Hi, list!

Since OpenBSD 6.0 removed the ability to mount filesystems as user, I've
been having issues getting directories mounted with sysutils/sshfs-fuse
to be accessible by users. I've tried setting

> -o uid=,gid=

when I mount the directory with this complete command line:

> doas sshfs -o uid=,gid= user@server:/dir /mnt

only to get this back:

> fuse: unknown option uid=1000

respectively, when gid is the first option:

> fuse: unknown option gid=1000

I've seen some recent changes regarding libfuse in the source tree, for
example this one:
https://marc.info/?l=openbsd-cvs=151299546729095=2
which would affect me, as I'm running -current:

OpenBSD 6.2-current (GENERIC.MP) #296: Sun Dec 17 16:43:20 MST 2017

Help would be greatly appreciated.

-- 
azarus
email: aza...@posteo.net
xmpp:  aza...@azarus.ch
PGP:   3A79D6CFD2567CF9

Re: fd0 at fdc0 drive 0: density unknown

[bofh]

On Sat, Sep 9, 2017 at 5:58 AM, Stuart Henderson 
wrote:

> On 2017-09-08, Tony Montana  wrote:
> >> booting. I agree that it's a bit ugly, but it makes booting about 5
> seconds
> >> faster.
> >
> > It's not just a bit ugly... It's horrible. It has to go. I'm surprised
> > noone has reverted this crazy change yet.
>
> Disable the floppy drive controller in your VM config then. (I'd be
> surprised if you see this on a physical machine, I can't find any where
> this shows up, even back to the oldest x86 I have in production which
> is from 2002).
>

But but but... that'd require the user to actually think about what they
are doing...

Re: fd0 at fdc0 drive 0: density unknown

[Stuart Henderson]

On 2017-09-08, Tony Montana  wrote:
>> The old behavior was that the kernel would wait after the "fdc0 ..." line 
>> until fd0 attaches. Now it does the waiting in the background and continues 
>> booting. I agree that it's a bit ugly, but it makes booting about 5 seconds 
>> faster.
>
> It's not just a bit ugly... It's horrible. It has to go. I'm surprised
> noone has reverted this crazy change yet.

Disable the floppy drive controller in your VM config then. (I'd be
surprised if you see this on a physical machine, I can't find any where
this shows up, even back to the oldest x86 I have in production which
is from 2002).

Re: fd0 at fdc0 drive 0: density unknown

[Theo de Raadt]

> > The old behavior was that the kernel would wait after the "fdc0 ..." line 
> > until fd0 attaches. Now it does the waiting in the background and continues 
> > booting. I agree that it's a bit ugly, but it makes booting about 5 seconds 
> > faster.
> 
> It's not just a bit ugly... It's horrible. It has to go. I'm surprised
> noone has reverted this crazy change yet.

usb devices attach late all the time also.

Tony, your opinion counts for very little around here -- quite a few
rungs below my cats...

Re: fd0 at fdc0 drive 0: density unknown

[Tony Montana]

> The old behavior was that the kernel would wait after the "fdc0 ..." line 
> until fd0 attaches. Now it does the waiting in the background and continues 
> booting. I agree that it's a bit ugly, but it makes booting about 5 seconds 
> faster.

It's not just a bit ugly... It's horrible. It has to go. I'm surprised
noone has reverted this crazy change yet.

Re: fd0 at fdc0 drive 0: density unknown

[Stefan Fritsch]

On Thursday, 7 September 2017 19:15:31 CEST Arfnokill wrote:
> Using snapshots on amd64. Since two days ago the kernel prints this fd0 at
> fdc0 drive 0: density unknown very late during boot.
> 
> It starts reordering libraries, and BAM... fd0 at fdc0 drive 0: density
> unknown in blue background. It's just cosmetic I guess, but it's
> uncomfortable.
> 
> Anybody else seeing this with recent snapshots?

The old behavior was that the kernel would wait after the "fdc0 ..." line 
until fd0 attaches. Now it does the waiting in the background and continues 
booting. I agree that it's a bit ugly, but it makes booting about 5 seconds 
faster.

fd0 at fdc0 drive 0: density unknown

[Arfnokill]

Using snapshots on amd64. Since two days ago the kernel prints this fd0 at fdc0 
drive 0: density unknown very late during boot.

It starts reordering libraries, and BAM... fd0 at fdc0 drive 0: density unknown 
in blue background. It's just cosmetic I guess, but it's uncomfortable.

Anybody else seeing this with recent snapshots?

Re: FastCGI sent in stderr: "PHP message: PHP Warning: Unknown: Unable to create temporary file, Check permissions in temporary files directory.

[Martijn van Duren]

nv vars to /tmp and see if that works. 
>>
>> Todd
>>
>> On Tue, Jul 25, 2017 at 09:03:38AM +0200, Stephane HUC "PengouinBSD" wrote:
>>> Hi all.
>>>
>>> I have this error on my,OpenBSD server (6.1) :
>>>
>>> FastCGI sent in stderr: "PHP message: PHP Warning:  Unknown: Unable to
>>> create temporary file, Check permissions in temporary files directory.
>>> in Unknown on line 0
>>>
>>> I use nginx+php70_fpm !
>>>
>>> The php-fpm.conf for the instance:
>>>
>>>  file ***
>>> [blog.stephane-huc.net]
>>> prefix = /var/www
>>>
>>> user = user_blog
>>> group = www
>>>
>>> listen.owner = www
>>> listen.group = www
>>> listen.mode = 0660
>>>
>>> listen = run/php-fpm.$pool.sock
>>> listen.allowed_clients = 127.0.0.1
>>>
>>> chroot = $prefix
>>> chdir = /
>>>
>>> env[HOSTNAME] = $HOSTNAME
>>> ;env[PATH] = /usr/local/bin:/usr/bin:/bin
>>> env[TMP] = /var/www/tmp
>>> env[TMPDIR] = /var/www/tmp
>>> env[TEMP] = /var/www/tmp
>>>
>>> php_admin_value[upload_tmp_dir] = /tmp
>>> php_admin_value[upload_max_filesize] = 8M
>>> *** EOF ***
>>>
>>> Rights on /var/www/tmp:
>>>
>>> $ ls -al /var/www/
>>>
>>>
>>> total 68
>>> drwxr-xr-x  17 root  daemon   512 Jul  5 04:59 ./
>>> drwxr-xr-x  25 root  wheel512 Jul  5 19:50 ../
>>> drwxr-xr-x  10 www   daemon   512 Jul  9 10:31 .ht/
>>> drwxr-xr-x  11 root  daemon   512 Jul  9 10:31 acme/
>>> drwxr-xr-x   2 root  daemon   512 Jun 25 13:51 bin/
>>> drwx-T  16 www   daemon   512 Jul  9 10:31 cache/
>>> drwxr-xr-x   2 root  daemon   512 Apr  1 21:38 cgi-bin/
>>> drwxr-xr-x  10 root  daemon   512 Jul  9 10:31 conf/
>>> drwxr-xr-x   3 root  daemon   512 Jun 25 13:48 etc/
>>> drwxr-xr-x  12 root  daemon   512 Jul  9 10:29 htdocs/
>>> drwxr-xr-x   2 root  daemon   512 Jun 24 22:59 html/
>>> drwxr-xr-x  11 root  daemon  1024 Jul 23 00:00 logs/
>>> drwxr-xr-x   2 root  daemon   512 Jun 28 18:11 modules/
>>> drwxr-xr-x  11 root  daemon  1024 Jul 25 08:39 run/
>>> drwxr-xr-x  10 www   www 2048 Jul  9 10:31 tmp/
>>> drwxr-xr-x   3 root  daemon   512 Jun 24 20:44 usr/
>>> drwxr-xr-x   3 root  daemon   512 Jun 24 21:17 var/
>>>
>>>
>>> where is the problem?
>>>
>>>
>>> -- 
>>> ~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<<
>>> 
>>> Stephane HUC as PengouinBSD or CIOTBSD
>>> b...@stephane-huc.net
>>>
>>
>>
> 

Re: FastCGI sent in stderr: "PHP message: PHP Warning: Unknown: Unable to create temporary file, Check permissions in temporary files directory.

[Stephane HUC "PengouinBSD"]

Hi, all.

Sorry for the latence!

Yes, i'm sure all ENV* variables are absolute to the system root.
As explain on the php-fpm.conf, only few directives are relative to be
chroot.

[quote]
(...)
; Per pool prefix
; It only applies on the following directives:
; - 'access.log'
; - 'slowlog'
; - 'listen' (unixsocket)
; - 'chroot'
; - 'chdir'
; - 'php_values'
; - 'php_admin_values'
; When not set, the global prefix (or /usr/local) applies instead.
; Note: This directive can also be relative to the global prefix.
(...)
[/quote]

I modified the php-fpm.conf_user as:

env[TMP] = /var/www/tmp/$pool
env[TMPDIR] = /var/www/tmp/$pool
env[TEMP] = /var/www/tmp/$pool
(...)
php_admin_value[upload_tmp_dir]=/tmp/$pool

I created the directory /var/www/tmp/$pool, and chowned user_blog:www on
this!

In facts, i was wrong user.

Now, it's run correctly! ;)

Thank you all.


Le 07/26/17 à 01:50, Todd Mortimer a écrit :
> Hi Stephane,
> 
> Are you sure that the env[TMP], env[TMPDIR] and env[TEMP] variables are
> supposed to be relative to the real system root, or relative to the
> chroot? If I were to guess, I would bet that php is trying to create a
> file after chrooting itself, and inside the chroot, /var/www/tmp doesn't
> exist. Try setting those env vars to /tmp and see if that works. 
> 
> Todd
> 
> On Tue, Jul 25, 2017 at 09:03:38AM +0200, Stephane HUC "PengouinBSD" wrote:
>> Hi all.
>>
>> I have this error on my,OpenBSD server (6.1) :
>>
>> FastCGI sent in stderr: "PHP message: PHP Warning:  Unknown: Unable to
>> create temporary file, Check permissions in temporary files directory.
>> in Unknown on line 0
>>
>> I use nginx+php70_fpm !
>>
>> The php-fpm.conf for the instance:
>>
>>  file ***
>> [blog.stephane-huc.net]
>> prefix = /var/www
>>
>> user = user_blog
>> group = www
>>
>> listen.owner = www
>> listen.group = www
>> listen.mode = 0660
>>
>> listen = run/php-fpm.$pool.sock
>> listen.allowed_clients = 127.0.0.1
>>
>> chroot = $prefix
>> chdir = /
>>
>> env[HOSTNAME] = $HOSTNAME
>> ;env[PATH] = /usr/local/bin:/usr/bin:/bin
>> env[TMP] = /var/www/tmp
>> env[TMPDIR] = /var/www/tmp
>> env[TEMP] = /var/www/tmp
>>
>> php_admin_value[upload_tmp_dir] = /tmp
>> php_admin_value[upload_max_filesize] = 8M
>> *** EOF ***
>>
>> Rights on /var/www/tmp:
>>
>> $ ls -al /var/www/
>>
>>
>> total 68
>> drwxr-xr-x  17 root  daemon   512 Jul  5 04:59 ./
>> drwxr-xr-x  25 root  wheel512 Jul  5 19:50 ../
>> drwxr-xr-x  10 www   daemon   512 Jul  9 10:31 .ht/
>> drwxr-xr-x  11 root  daemon   512 Jul  9 10:31 acme/
>> drwxr-xr-x   2 root  daemon   512 Jun 25 13:51 bin/
>> drwx-T  16 www   daemon   512 Jul  9 10:31 cache/
>> drwxr-xr-x   2 root  daemon   512 Apr  1 21:38 cgi-bin/
>> drwxr-xr-x  10 root  daemon   512 Jul  9 10:31 conf/
>> drwxr-xr-x   3 root  daemon   512 Jun 25 13:48 etc/
>> drwxr-xr-x  12 root  daemon   512 Jul  9 10:29 htdocs/
>> drwxr-xr-x   2 root  daemon   512 Jun 24 22:59 html/
>> drwxr-xr-x  11 root  daemon  1024 Jul 23 00:00 logs/
>> drwxr-xr-x   2 root  daemon   512 Jun 28 18:11 modules/
>> drwxr-xr-x  11 root  daemon  1024 Jul 25 08:39 run/
>> drwxr-xr-x  10 www   www 2048 Jul  9 10:31 tmp/
>> drwxr-xr-x   3 root  daemon   512 Jun 24 20:44 usr/
>> drwxr-xr-x   3 root  daemon   512 Jun 24 21:17 var/
>>
>>
>> where is the problem?
>>
>>
>> -- 
>> ~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD "  +=<<<
>> 
>> Stephane HUC as PengouinBSD or CIOTBSD
>> b...@stephane-huc.net
>>
> 
> 

-- 
~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<<

Stephane HUC as PengouinBSD or CIOTBSD
b...@stephane-huc.net



signature.asc
Description: OpenPGP digital signature

Re: FastCGI sent in stderr: "PHP message: PHP Warning: Unknown: Unable to create temporary file, Check permissions in temporary files directory.

[Todd Mortimer]

Hi Stephane,

Are you sure that the env[TMP], env[TMPDIR] and env[TEMP] variables are
supposed to be relative to the real system root, or relative to the
chroot? If I were to guess, I would bet that php is trying to create a
file after chrooting itself, and inside the chroot, /var/www/tmp doesn't
exist. Try setting those env vars to /tmp and see if that works. 

Todd

On Tue, Jul 25, 2017 at 09:03:38AM +0200, Stephane HUC "PengouinBSD" wrote:
> Hi all.
> 
> I have this error on my,OpenBSD server (6.1) :
> 
> FastCGI sent in stderr: "PHP message: PHP Warning:  Unknown: Unable to
> create temporary file, Check permissions in temporary files directory.
> in Unknown on line 0
> 
> I use nginx+php70_fpm !
> 
> The php-fpm.conf for the instance:
> 
>  file ***
> [blog.stephane-huc.net]
> prefix = /var/www
> 
> user = user_blog
> group = www
> 
> listen.owner = www
> listen.group = www
> listen.mode = 0660
> 
> listen = run/php-fpm.$pool.sock
> listen.allowed_clients = 127.0.0.1
> 
> chroot = $prefix
> chdir = /
> 
> env[HOSTNAME] = $HOSTNAME
> ;env[PATH] = /usr/local/bin:/usr/bin:/bin
> env[TMP] = /var/www/tmp
> env[TMPDIR] = /var/www/tmp
> env[TEMP] = /var/www/tmp
> 
> php_admin_value[upload_tmp_dir] = /tmp
> php_admin_value[upload_max_filesize] = 8M
> *** EOF ***
> 
> Rights on /var/www/tmp:
> 
> $ ls -al /var/www/
> 
> 
> total 68
> drwxr-xr-x  17 root  daemon   512 Jul  5 04:59 ./
> drwxr-xr-x  25 root  wheel512 Jul  5 19:50 ../
> drwxr-xr-x  10 www   daemon   512 Jul  9 10:31 .ht/
> drwxr-xr-x  11 root  daemon   512 Jul  9 10:31 acme/
> drwxr-xr-x   2 root  daemon   512 Jun 25 13:51 bin/
> drwx-T  16 www   daemon   512 Jul  9 10:31 cache/
> drwxr-xr-x   2 root  daemon   512 Apr  1 21:38 cgi-bin/
> drwxr-xr-x  10 root  daemon   512 Jul  9 10:31 conf/
> drwxr-xr-x   3 root  daemon   512 Jun 25 13:48 etc/
> drwxr-xr-x  12 root  daemon   512 Jul  9 10:29 htdocs/
> drwxr-xr-x   2 root  daemon   512 Jun 24 22:59 html/
> drwxr-xr-x  11 root  daemon  1024 Jul 23 00:00 logs/
> drwxr-xr-x   2 root  daemon   512 Jun 28 18:11 modules/
> drwxr-xr-x  11 root  daemon  1024 Jul 25 08:39 run/
> drwxr-xr-x  10 www   www 2048 Jul  9 10:31 tmp/
> drwxr-xr-x   3 root  daemon   512 Jun 24 20:44 usr/
> drwxr-xr-x   3 root  daemon   512 Jun 24 21:17 var/
> 
> 
> where is the problem?
> 
> 
> -- 
> ~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD "   +=<<<
> 
> Stephane HUC as PengouinBSD or CIOTBSD
> b...@stephane-huc.net
> 

Re: FastCGI sent in stderr: "PHP message: PHP Warning: Unknown: Unable to create temporary file, Check permissions in temporary files directory.

[Johannes Paasila]

On 25 July 2017 5:03:38 pm AEST, "Stephane HUC "PengouinBSD"" 
<b...@stephane-huc.net> wrote:
>Hi all.
>
>I have this error on my,OpenBSD server (6.1) :
>
>FastCGI sent in stderr: "PHP message: PHP Warning:  Unknown: Unable to
>create temporary file, Check permissions in temporary files directory.
>in Unknown on line 0
>
>I use nginx+php70_fpm !
>
>The php-fpm.conf for the instance:
>
> file ***
>[blog.stephane-huc.net]
>prefix = /var/www
>
>user = user_blog
>group = www
>
>listen.owner = www
>listen.group = www
>listen.mode = 0660
>
>listen = run/php-fpm.$pool.sock
>listen.allowed_clients = 127.0.0.1
>
>chroot = $prefix
>chdir = /
>
>env[HOSTNAME] = $HOSTNAME
>;env[PATH] = /usr/local/bin:/usr/bin:/bin
>env[TMP] = /var/www/tmp
>env[TMPDIR] = /var/www/tmp
>env[TEMP] = /var/www/tmp
>
>php_admin_value[upload_tmp_dir] = /tmp
>php_admin_value[upload_max_filesize] = 8M
>*** EOF ***
>
>Rights on /var/www/tmp:
>
>$ ls -al /var/www/
>
>
>total 68
>drwxr-xr-x  17 root  daemon   512 Jul  5 04:59 ./
>drwxr-xr-x  25 root  wheel512 Jul  5 19:50 ../
>drwxr-xr-x  10 www   daemon   512 Jul  9 10:31 .ht/
>drwxr-xr-x  11 root  daemon   512 Jul  9 10:31 acme/
>drwxr-xr-x   2 root  daemon   512 Jun 25 13:51 bin/
>drwx-T  16 www   daemon   512 Jul  9 10:31 cache/
>drwxr-xr-x   2 root  daemon   512 Apr  1 21:38 cgi-bin/
>drwxr-xr-x  10 root  daemon   512 Jul  9 10:31 conf/
>drwxr-xr-x   3 root  daemon   512 Jun 25 13:48 etc/
>drwxr-xr-x  12 root  daemon   512 Jul  9 10:29 htdocs/
>drwxr-xr-x   2 root  daemon   512 Jun 24 22:59 html/
>drwxr-xr-x  11 root  daemon  1024 Jul 23 00:00 logs/
>drwxr-xr-x   2 root  daemon   512 Jun 28 18:11 modules/
>drwxr-xr-x  11 root  daemon  1024 Jul 25 08:39 run/
>drwxr-xr-x  10 www   www 2048 Jul  9 10:31 tmp/
>drwxr-xr-x   3 root  daemon   512 Jun 24 20:44 usr/
>drwxr-xr-x   3 root  daemon   512 Jun 24 21:17 var/
>
>
>where is the problem?

Your tmp directory isn't group writable.

FastCGI sent in stderr: "PHP message: PHP Warning: Unknown: Unable to create temporary file, Check permissions in temporary files directory.

[Stephane HUC "PengouinBSD"]

Hi all.

I have this error on my,OpenBSD server (6.1) :

FastCGI sent in stderr: "PHP message: PHP Warning:  Unknown: Unable to
create temporary file, Check permissions in temporary files directory.
in Unknown on line 0

I use nginx+php70_fpm !

The php-fpm.conf for the instance:

 file ***
[blog.stephane-huc.net]
prefix = /var/www

user = user_blog
group = www

listen.owner = www
listen.group = www
listen.mode = 0660

listen = run/php-fpm.$pool.sock
listen.allowed_clients = 127.0.0.1

chroot = $prefix
chdir = /

env[HOSTNAME] = $HOSTNAME
;env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /var/www/tmp
env[TMPDIR] = /var/www/tmp
env[TEMP] = /var/www/tmp

php_admin_value[upload_tmp_dir] = /tmp
php_admin_value[upload_max_filesize] = 8M
*** EOF ***

Rights on /var/www/tmp:

$ ls -al /var/www/


total 68
drwxr-xr-x  17 root  daemon   512 Jul  5 04:59 ./
drwxr-xr-x  25 root  wheel512 Jul  5 19:50 ../
drwxr-xr-x  10 www   daemon   512 Jul  9 10:31 .ht/
drwxr-xr-x  11 root  daemon   512 Jul  9 10:31 acme/
drwxr-xr-x   2 root  daemon   512 Jun 25 13:51 bin/
drwx-T  16 www   daemon   512 Jul  9 10:31 cache/
drwxr-xr-x   2 root  daemon   512 Apr  1 21:38 cgi-bin/
drwxr-xr-x  10 root  daemon   512 Jul  9 10:31 conf/
drwxr-xr-x   3 root  daemon   512 Jun 25 13:48 etc/
drwxr-xr-x  12 root  daemon   512 Jul  9 10:29 htdocs/
drwxr-xr-x   2 root  daemon   512 Jun 24 22:59 html/
drwxr-xr-x  11 root  daemon  1024 Jul 23 00:00 logs/
drwxr-xr-x   2 root  daemon   512 Jun 28 18:11 modules/
drwxr-xr-x  11 root  daemon  1024 Jul 25 08:39 run/
drwxr-xr-x  10 www   www 2048 Jul  9 10:31 tmp/
drwxr-xr-x   3 root  daemon   512 Jun 24 20:44 usr/
drwxr-xr-x   3 root  daemon   512 Jun 24 21:17 var/


where is the problem?


-- 
~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<<

Stephane HUC as PengouinBSD or CIOTBSD
b...@stephane-huc.net



signature.asc
Description: OpenPGP digital signature

full disk encryption "unknown error" on current

[mymlact]

Hi,

I followed the FAQ for encrypting external disks, but unfortunately it's 
failing.


I'm trying to encrypt a 32Tb raid 6 drive on a lsi 9265-8i with 8 x 6Tb 
drives and it's failing with an "unknown error".


I was able to encrypt the 256Gb system disk without error during 
installation.


I was able to create and mount the drive without encryption.

Errors and dmesg below.

Thanks


# disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: MR9265-8i
duid: 8c5fe961450f150a
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 4377192
total sectors: 70319603712
boundstart: 64
boundend: 70319603649
drivedata: 0

16 partitions:
#size   offset  fstype [fsize bsize   cpg]
  a:  70319603585   64RAID
  c:  703196037120  unused
# disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: MR9265-8i
duid: 8c5fe961450f150a
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 4377192
total sectors: 70319603712
boundstart: 64
boundend: 70319603649
drivedata: 0

16 partitions:
#size   offset  fstype [fsize bsize   cpg]
  a:  70319603585   64RAID
  c:  703196037120  unused
# fdisk sd0
Disk: sd0   Usable LBA: 64 to 70319603648 [70319603712 Sectors]
   #: type [   start: size ]

   3: OpenBSD  [  64: 70319603585 ]


# fdisk -iy -g sd0
Writing MBR at offset 0.
Writing GPT.
# disklabel -E sd0
Label editor (enter '?' for help at any prompt)
> p
OpenBSD area: 64-70319603649; size: 70319603585; free: 65
#size   offset  fstype [fsize bsize   cpg]
  a:  70319603520   64  4.2BSD   8192 65536 52270
  c:  703196037120  unused
> d a
> a a
offset: [64]
size: [70319603585]
FS type: [4.2BSD] RAID
> w
> q
No label changes.

# bioctl -v -c C -l sd0a softraid0
New passphrase:
Re-type passphrase:
Deriving key using bcrypt PBKDF with 16 rounds...
bioctl: unknown error


dmesg follows:

OpenBSD 6.1-current (GENERIC.MP) #54: Thu May 11 19:20:09 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34333851648 (32743MB)
avail mem = 33287512064 (31745MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9d000 (51 entries)
bios0: vendor American Megatrends Inc. version "2.1" date 03/17/2012
bios0: Supermicro X8DT3
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG SLIT SLIC OEMB SRAT HPET SSDT
acpi0: wakeup devices NPE1(S4) NPE2(S4) NPE3(S4) NPE4(S4) NPE5(S4) 
NPE6(S4) NPE7(S4) NPE8(S4) NPE9(S4) NPEA(S4) P0P1(S4) PS2K(S4) USB0(S4) 
USB1(S4) USB2(S4) USB5(S4) [...]

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) Xeon(R) CPU E5620 @ 2.40GHz, 2400.32 MHz
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,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 2400324600 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.00 MHz
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,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 18 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.01 MHz
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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 9, package 0
cpu3 at mainbus0: apid 20 (application processor)
cpu3: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.00 MHz
cpu3: 
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,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 10, 

Re: unknown hostname on ssh tunnel end causes 'administratively prohibited: open failed'

[Jiri B]

> The code in sshd where the response is composed doesn't know what the
> reason for the failure is.  I suspect thid dates back to the original
> Protocol 1 code becuase Protocol 1 didn't (I think) have a reason field.
> This passes the reason back up the stack and sends it to the client.

Sorry for delay, I can't reproduce previous behaviour with your diff.
(Used host is incorrectly non-resolvable via socks5 tunnel.)

But, is following output OK (see '')?

j.

$ ssh -vvv -D localhost
OpenSSH_7.3, LibreSSL 2.5.1
...
Authenticated to localhost ([127.0.0.1]:22).
debug1: Local connections to LOCALHOST: forwarded to remote address socks:0
debug3: channel_setup_fwd_listener_tcpip: type 2 wildcard 0 addr NULL
debug1: Local forwarding listening on 127.0.0.1 port .
...
debug1: Connection to port  forwarding to socks port 0 requested.
debug2: fd 10 setting TCP_NODELAY
debug3: fd 10 is O_NONBLOCK
debug3: fd 10 is O_NONBLOCK
debug1: channel 3: new [dynamic-tcpip]
debug2: channel 3: pre_dynamic: have 0
debug2: channel 3: pre_dynamic: have 3
debug2: channel 3: decode socks5
debug2: channel 3: socks5 auth done
debug2: channel 3: pre_dynamic: need more
debug2: channel 3: pre_dynamic: have 0
debug2: channel 3: pre_dynamic: have 45
debug2: channel 3: decode socks5
debug2: channel 3: socks5 post auth
debug2: channel 3: dynamic request: socks5 host 
jbelka-vm3.rhev.lab.eng.brq.example.com port 443 command 1
debug3: send packet: type 90
debug3: receive packet: type 92
channel 3: open failed: connect failed: no address associated with name
    ?
debug2: channel 3: zombie
debug2: channel 3: garbage collecting
debug1: channel 3: free: direct-tcpip: listening port  for 
jbelka-vm3.rhev.lab.eng.brq.example.com port 443, connect from 127.0.0.1 port 
10407 to 127.0.0.1 port , nchannels 4
debug3: channel 3: status: The following connections are open:
  #2 client-session (t4 r0 i0/0 o0/0 fd 7/8 cc -1)

debug1: Connection to port  forwarding to socks port 0 requested.
debug2: fd 10 setting TCP_NODELAY
debug3: fd 10 is O_NONBLOCK
debug3: fd 10 is O_NONBLOCK
...

Re: unknown hostname on ssh tunnel end causes 'administratively prohibited: open failed'

[Darren Tucker]

On Wed, Nov 23, 2016 at 01:35:17PM -0500, Jiri B wrote:
> I was using ssh socks5 tunnel (-D) today and I saw many:
> 
>   channel 4: open failed: administratively prohibited: open failed
> 
> messages. It seems non-resolvable hostnames on my gw (ie. end of ssh
> socks5 tunnel) is passed to client as "prohibited" event.
> 
> This seems odd and confusing. GW is an older 6.0-current amd64.

The code in sshd where the response is composed doesn't know what the
reason for the failure is.  I suspect thid dates back to the original
Protocol 1 code becuase Protocol 1 didn't (I think) have a reason field.
This passes the reason back up the stack and sends it to the client.

Index: channels.c
===
RCS file: /cvs/src/usr.bin/ssh/channels.c,v
retrieving revision 1.356
diff -u -p -r1.356 channels.c
--- channels.c  18 Oct 2016 17:32:54 -  1.356
+++ channels.c  24 Nov 2016 04:36:58 -
@@ -3038,7 +3038,7 @@ channel_input_port_open(int type, u_int3
}
packet_check_eom();
c = channel_connect_to_port(host, host_port,
-   "connected socket", originator_string);
+   "connected socket", originator_string, NULL, NULL);
free(originator_string);
free(host);
if (c == NULL) {
@@ -3995,7 +3995,8 @@ channel_connect_ctx_free(struct channel_
 
 /* Return CONNECTING channel to remote host:port or local socket path */
 static Channel *
-connect_to(const char *name, int port, char *ctype, char *rname)
+connect_to(const char *name, int port, char *ctype, char *rname, int *reason,
+char **errmsg)
 {
struct addrinfo hints;
int gaierr;
@@ -4036,7 +4037,12 @@ connect_to(const char *name, int port, c
hints.ai_family = IPv4or6;
hints.ai_socktype = SOCK_STREAM;
snprintf(strport, sizeof strport, "%d", port);
-   if ((gaierr = getaddrinfo(name, strport, , )) 
!= 0) {
+   if ((gaierr = getaddrinfo(name, strport, , ))
+   != 0) {
+   if (errmsg != NULL)
+   *errmsg = ssh_gai_strerror(gaierr);
+   if (reason != NULL)
+   *reason = SSH2_OPEN_CONNECT_FAILED;
error("connect_to %.100s: unknown host (%s)", name,
ssh_gai_strerror(gaierr));
return NULL;
@@ -4076,7 +4082,8 @@ channel_connect_by_listen_address(const 
return permitted_opens[i].downstream;
return connect_to(
permitted_opens[i].host_to_connect,
-   permitted_opens[i].port_to_connect, ctype, rname);
+   permitted_opens[i].port_to_connect, ctype, rname,
+   NULL, NULL);
    }
}
error("WARNING: Server requests forwarding for unknown listen_port %d",
@@ -4093,7 +4100,8 @@ channel_connect_by_listen_path(const cha
if (open_listen_match_streamlocal(_opens[i], path)) {
return connect_to(
permitted_opens[i].host_to_connect,
-   permitted_opens[i].port_to_connect, ctype, rname);
+   permitted_opens[i].port_to_connect, ctype, rname,
+   NULL, NULL);
    }
}
error("WARNING: Server requests forwarding for unknown path %.100s",
@@ -4103,7 +4111,8 @@ channel_connect_by_listen_path(const cha
 
 /* Check if connecting to that port is permitted and connect. */
 Channel *
-channel_connect_to_port(const char *host, u_short port, char *ctype, char 
*rname)
+channel_connect_to_port(const char *host, u_short port, char *ctype,
+char *rname, int *reason, char **errmsg)
 {
int i, permit, permit_adm = 1;
 
@@ -4128,9 +4137,10 @@ channel_connect_to_port(const char *host
if (!permit || !permit_adm) {
logit("Received request to connect to host %.100s port %d, "
"but the request was denied.", host, port);
+   *reason = SSH2_OPEN_ADMINISTRATIVELY_PROHIBITED;
return NULL;
}
-   return connect_to(host, port, ctype, rname);
+   return connect_to(host, port, ctype, rname, reason, errmsg);
 }
 
 /* Check if connecting to that path is permitted and connect. */
@@ -4162,7 +4172,7 @@ channel_connect_to_path(const char *path
"but the request was denied.", path);
return NULL;
}
-   return connect_to(path, PORT_STREAMLOCAL, ctype, rname);
+   return connect_to(path, PORT_STREAMLOCAL, ctype, rname, NULL, NULL);
 }
 
 void
Index: channels.h
===
RCS

unknown hostname on ssh tunnel end causes 'administratively prohibited: open failed'

[Jiri B]

I was using ssh socks5 tunnel (-D) today and I saw many:

  channel 4: open failed: administratively prohibited: open failed

messages. It seems non-resolvable hostnames on my gw (ie. end of ssh
socks5 tunnel) is passed to client as "prohibited" event.

This seems odd and confusing. GW is an older 6.0-current amd64.

j.

Firefox with SOCKS5 tunnel (ssh -D $gw). Than I opened an url,
ie. wiki.brq.example.com:

~~~
debug1: Connection to port  forwarding to socks port 0 requested.
debug2: fd 11 setting TCP_NODELAY
debug3: fd 11 is O_NONBLOCK
debug3: fd 11 is O_NONBLOCK
debug1: channel 4: new [dynamic-tcpip]
debug2: channel 4: pre_dynamic: have 0
debug2: channel 4: pre_dynamic: have 3
debug2: channel 4: decode socks5
debug2: channel 4: socks5 auth done
debug2: channel 4: pre_dynamic: need more
debug2: channel 4: pre_dynamic: have 0
debug2: channel 4: pre_dynamic: have 26
debug2: channel 4: decode socks5
debug2: channel 4: socks5 post auth
debug2: channel 4: dynamic request: socks5 host wiki.brq.example.com port 80 
command 1
debug3: send packet: type 90
debug3: receive packet: type 92
channel 4: open failed: administratively prohibited: open failed
   ^
debug2: channel 4: zombie
debug2: channel 4: garbage collecting
debug1: channel 4: free: direct-tcpip: listening port  for 
wiki.brq.example.com port 80, connect from 127.0.0.1 port 30421 to 127.0.0.1 
port , nchannels 5
debug3: channel 4: status: The following connections are open:
  #2 client-session (t4 r0 i0/0 o0/0 fd 7/8 cc -1)
  #3 direct-tcpip: listening port  for www.google.com port 443, connect 
from 127.0.0.1 port 24731 to 127.0.0.1 port  (t4 r1 i0/0 o0/0 fd 10/10 cc 
-1)
~~~

part of auth.log:

~~~
Nov 23 19:24:04 gw sshd[20891]: error: connect_to wiki.brq.example.com: unknown 
host (no address associated with name)


~~~

my sshd_config part:

~~~
Match Address 
192.168.1.0/24,192.168.2.0/24,192.168.254.0/24,2xx.0.0.0/8,2001:470:::/64 
User jirib
  PasswordAuthentication no
  AuthenticationMethods publickey
  AuthorizedKeysFile /etc/ssh/authorized_keys.d/%u
  AllowTcpForwarding yes
  PermitTunnel yes
  AllowAgentForwarding yes
  GatewayPorts yes
  X11Forwarding yes
~~~

Re: upgrade OpenBSD 5.8 to 5.9 daemon: unknown class

[Stuart Henderson]

On 2016-04-28, Ultramedia Libertad  wrote:
> with this file that comes by default it worked perfectly, I think the
> login.conf file does not work without the first line or comments, or I had
> some syntax error'll never know something like that happened to someone in
> this thread the which along with their answers of you helped me solve it.

login.conf is fragile, it's not hard to get the format wrong and it's
easy to lock yourself out after a bad edit. I recommend leaving a
spare root shell open when editing it, and test that it works - make
sure you can still login (if it's remote) or su (if it's local) before
closing the shell.

Re: upgrade OpenBSD 5.8 to 5.9 daemon: unknown class

[Ultramedia Libertad]

gin.conf" was blank
>>> >
>>> > the date on that file would shed a clue as to when it happened.
>>> >
>>> > > now I put this old file 5.7, which had a backup:
>>> >
>>> > closer, but that's still two releases old.
>>> > ...
>>> >
>>> > > and now new errors:
>>> > > /(failed) sshdsu couldn't resolve "tc"/
>>> > > /(failed) smtpdsu couldn't resolve "tc"
>>> >
>>> > "sshdsu"???  smtpdsu??
>>> > you have a very messed up system there.  And I'd guess it has to
>>> do with
>>> > the /etc directory.
>>> >
>>> > If you can't clean it up easily (maybe with the help of a clean and
>>> > fresh 5.9 install), I'd suggest a reload, as obviously something
>>> > seriously wrong happened on this system (and as I indicated, I
>>> suspect
>>> > it was unrelated to the upgrade), and trying to fix it may be very
>>> > difficult if you don't know what happened.
>>> >
>>> > > ...
>>> > > /
>>> > >
>>> > > Thank for all
>>> > > 2016-04-22 19:28 GMT+02:00 Ultramedia Libertad <
>>> meloa...@gmail.com <mailto:meloa...@gmail.com>
>>> > > <mailto:meloa...@gmail.com <mailto:meloa...@gmail.com>>>:
>>> > >
>>> > > many thanks,
>>> > >
>>> > > His answer reminds me that two days ago ago, update OpenBSD
>>> 5.7 to
>>> > > 5.8 and then packages:
>>> > > /pkg_add -u/
>>> > > and then made a
>>> > > /sysmerge/
>>> > >
>>> > > There was understood that after OpenBSD 5.7 to 5.8 upgrade is
>>> > > sysmerge first and then pkg_add -u.
>>> >
>>> > no.  NOTHING NEW here.  it has always been complete your base
>>> system
>>> > upgrade, THEN upgrade packages.  sysmerge upgrades the base system.
>>> >
>>> > AFTER the base system is upgraded, THEN you can do your pkg_add -u.
>>> > Think about it, it only makes sense.  And it is all we've ever
>>> > suggested.
>>> >
>>> > Now...if you make your own procedure and you get away with it and
>>> it
>>> > breaks for a new release, that's not an OpenBSD problem. :)
>>> >
>>> > >
>>> > > Another aspect that pkg_add -u in OpenBSD 5.8 dovecot some
>>> > > /etc/login.conf wonder, then surely I chose something wrong
>>> here.
>>> >
>>> > I do not believe pkg_add ever touches login.conf, though many
>>> > applications will make suggestions of changes to login.conf -- but
>>> you
>>> > have to make them.
>>> >
>>> > Nick.
>>> >
>>> >
>>> > > and order a remote console to my datacenter to enter and
>>> verify the
>>> > > file /etc/login.conf
>>> > >
>>> > > Thanks, I will report what happens with this.
>>> > >
>>> > > 2016-04-22 6:28 GMT-05:00 Nick Holland <
>>> n...@holland-consulting.net <mailto:n...@holland-consulting.net>
>>> > > <mailto:n...@holland-consulting.net
>>> > <mailto:n...@holland-consulting.net>>>:
>>> > >
>>> > > On 04/21/16 21:25, Ultramedia Libertad wrote:
>>> > > > hello
>>> > > >
>>> > > > I am upgrade OpenBSD 5.8 to 5.9 and after to reboot
>>> > > >
>>> > > > i have follow errors in remote console :
>>> > >
>>> > > ...[deleting big block of blank lines]...
>>> > >
>>> > > > *init: daemon: unknown class (failed)syslogdsu: daemon:
>>> > unknown class
>>> > > > (failed)pflogdsu: daemon: unknown class (failed)ntpdsu:
>>> > daemon: unknown
>>> > > > class (failed)starting RPC daemons:.savecore: no core
>>> > dumpcheckin quotas:
>>> > > > done.clearing /tmpkern.securelevel: 0 -> 1creating
>>> > runtime link editor
>>> > > > directory cache.preserving editor files.startings
>>> > networks daemons: sshdsu:
>>> > > > daemon: unknown class (failed)smtpdsu: daemon: unknown
>>> class
>>> > > > (failed)sndiodsu: daemon: unknown class
>>> (failed).Thu apr
>>> > > 21 20:06:24
>>> > > > CDI 2016*
>>> > > >
>>> > > >
>>> > > > y more
>>> > > >
>>> > > > please help me attach image
>>> > >
>>> > > both the lists and I block images images...
>>> > >
>>> > > > [demime 1.01d removed an attachment of type image/png
>>> > which had a name of Screenshot_2016-04-21_21-14-18.png]
>>> > > >
>>> > >
>>> > > sounds like somewhere along the line you deleted or
>>> > mangled your
>>> > > /etc/login.conf file.  I'm guessing it had nothing to do
>>> > with the
>>> > > upgrade, but probably more with the reboot (i.e., you
>>> > hosed the file
>>> > > some time ago, if you had rebooted without an upgrade,
>>> you
>>> > would
>>> > > have
>>> > > seen the same problem).
>>> > >
>>> > > sysmerge may help.
>>> > >
>>> > > Nick.
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > editor de sueños
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > editor de sueños
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > editor de sueños
>>>
>>>
>>
>>
>> --
>> editor de sueños
>>
>
>
>
> --
> editor de sueños
>



--
editor de sueños

Re: 5.9: sndiod won't start: unknown user _sndiop: FIXED

[Mark Carroll]

I should add, in further investigation on other OpenBSD 5.9 systems I've
found one with,

/etc/group:_sndiop:*:110:
/etc/master.passwd:_sndiop:*:110:110::0:0:sndio privileged 
user:/var/empty:/sbin/nologin

so that does seem to be a clue. Rerunning sysmerge I seem to be getting
all this sorted now. Sorry for the noise, I'll remember to retry that
next time I run into such a puzzle! (It's even possible I lost track of
where I was up to with each machine and omitted it altogether, sigh.)

-- Mark

5.9: sndiod won't start: unknown user _sndiop

[Mark Carroll]

Since upgrading to 5.9 I noticed that sndiod wasn't starting:

# ps awux | grep snd
root 17168  0.0  0.0   336  1028 p0  S+p6:22PM0:00.00 grep snd
# rcctl start sndiod
sndiod(failed)

Sound still generally seems to work in a basic way at least.

I didn't see anything about it in /var/log/ but,

# sndiod -d
sndiod: unknown user _sndiop

made me wonder about http://www.openbsd.org/plus59.html -

> Add the _sndiop user and group in preparation of the sndiod(8)
> privsep.

I am guessing that I just missed some docs somewhere or messed up a
sysmerge or something? I certainly can't find a mention of _sndiop in
/etc/ nor in the manpage or obvious online docs. Or perhaps that's
irrelevant to why my sndiod doesn't start?

Possibly it just means that I didn't previously have to configure sndiod
but for some reason I now do? (I don't set any sndiod_flags.)

(Incidentally, thank you for the inteldrm improvements!)

-- Mark


OpenBSD 5.9 (GENERIC.MP) #1888: Fri Feb 26 01:20:19 MST 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17043365888 (16253MB)
avail mem = 16522633216 (15757MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xa2ee7000 (53 entries)
bios0: vendor Intel Corporation version "RYBDWi35.86A.0350.2015.0812.1722" date 
08/12/2015
bios0: Intel Corporation NUC5i3RYB
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI LPIT SSDT ASF! SSDT 
SSDT SSDT DMAR
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
PS2K(S3) PS2M(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) 
PXSX(S4) RP04(S4) [...]
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) i3-5010U CPU @ 2.10GHz, 2095.45 MHz
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,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 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.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 2095.16 MHz
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,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 2095.16 MHz
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,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 2095.16 MHz
cpu3: 
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,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimadt0: bogus nmi for apid 3
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus 1 (RP01)
acpiprt5 at acpi0: bus -1 (RP02)
acpiprt6 at acpi0: bus -1 (RP03)
acpiprt7 at acpi0: bus 2 (RP04)
acpiprt8 at acpi0: bus -1 (RP05)
acpiprt9 at acpi0: bus -1 (RP06)
acpiprt10 at acpi0: bus -1 (RP07)
acpiprt11 at acpi0: bus -1 (RP08)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x31), 
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x31), 
C1(1000

Re: upgrade OpenBSD 5.8 to 5.9 daemon: unknown class

[Nick Holland]

On 04/21/16 21:25, Ultramedia Libertad wrote:
> hello
> 
> I am upgrade OpenBSD 5.8 to 5.9 and after to reboot
> 
> i have follow errors in remote console :

...[deleting big block of blank lines]...

> *init: daemon: unknown class (failed)syslogdsu: daemon: unknown class
> (failed)pflogdsu: daemon: unknown class (failed)ntpdsu: daemon: unknown
> class (failed)starting RPC daemons:.savecore: no core dumpcheckin quotas:
> done.clearing /tmpkern.securelevel: 0 -> 1creating runtime link editor
> directory cache.preserving editor files.startings networks daemons: sshdsu:
> daemon: unknown class (failed)smtpdsu: daemon: unknown class
> (failed)sndiodsu: daemon: unknown class (failed).Thu apr 21 20:06:24
> CDI 2016*
> 
> 
> y more
> 
> please help me attach image

both the lists and I block images images...

> [demime 1.01d removed an attachment of type image/png which had a name of 
> Screenshot_2016-04-21_21-14-18.png]
> 

sounds like somewhere along the line you deleted or mangled your
/etc/login.conf file.  I'm guessing it had nothing to do with the
upgrade, but probably more with the reboot (i.e., you hosed the file
some time ago, if you had rebooted without an upgrade, you would have
seen the same problem).

sysmerge may help.

Nick.

Re: upgrade OpenBSD 5.8 to 5.9 daemon: unknown class

[Daniel Gillen]

On 22.04.2016 03:25, Ultramedia Libertad wrote:
> hello
> 
> I am upgrade OpenBSD 5.8 to 5.9 and after to reboot
> 
> i have follow errors in remote console :
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *init: daemon: unknown class (failed)syslogdsu: daemon: unknown class
> (failed)pflogdsu: daemon: unknown class (failed)ntpdsu: daemon: unknown
> class (failed)starting RPC daemons:.savecore: no core dumpcheckin quotas:
> done.clearing /tmpkern.securelevel: 0 -> 1creating runtime link editor
> directory cache.preserving editor files.startings networks daemons: sshdsu:
> daemon: unknown class (failed)smtpdsu: daemon: unknown class
> (failed)sndiodsu: daemon: unknown class (failed).Thu apr 21 20:06:24
> CDI 2016*
> 
> 
> y more
> 
> please help me attach image
> 
> --
> editor de sueños
> 
> [demime 1.01d removed an attachment of type image/png which had a name of 
> Screenshot_2016-04-21_21-14-18.png]
> 

Could it have something to do with a damaged /etc/login.conf file?

Can you please post the content of that file.

-- 
Unix _IS_ user friendly - it's just
selective about who its friends are!

upgrade OpenBSD 5.8 to 5.9 daemon: unknown class

[Ultramedia Libertad]

hello

I am upgrade OpenBSD 5.8 to 5.9 and after to reboot

i have follow errors in remote console :
















*init: daemon: unknown class (failed)syslogdsu: daemon: unknown class
(failed)pflogdsu: daemon: unknown class (failed)ntpdsu: daemon: unknown
class (failed)starting RPC daemons:.savecore: no core dumpcheckin quotas:
done.clearing /tmpkern.securelevel: 0 -> 1creating runtime link editor
directory cache.preserving editor files.startings networks daemons: sshdsu:
daemon: unknown class (failed)smtpdsu: daemon: unknown class
(failed)sndiodsu: daemon: unknown class (failed).Thu apr 21 20:06:24
CDI 2016*


y more

please help me attach image

--
editor de sueños

[demime 1.01d removed an attachment of type image/png which had a name of 
Screenshot_2016-04-21_21-14-18.png]

Re: hotmail rejecting messages relay=mx4.hotmail.com., dsn=5.1.2, stat=Host unknown (Unknown error: 275)

[Peter van Oord van der Vlies]

 Op 23 mei 2015 om 17:54 heeft Peter Fraser p...@thinkage.ca het volgende 
 geschreven:
 
 Any message sent to send mail seems to be rejected. The mx4 name changes, but 
 the rejection is always the same.
 It would be nice to know what the unknown error is
 
 Does anyone have any idea what is causing the problems

Since friday we have the same problem on different servers. 
I am happy to see this is a global issue...
 
 I am currently using OpenBSD 5.5 with sendmail
 (I know I should update it but I haven't got around to it yet)
 
I am with openbsd 5.5 too, lower versions also but havent checked yet.

Re: hotmail rejecting messages relay=mx4.hotmail.com., dsn=5.1.2, stat=Host unknown (Unknown error: 275)

[Peter Fraser]

I received a private message saying the problem was
a bug in libc's resolver that make it fail if there are more than 16 addresses 
for a name.

hotmail recently added a 17th IP address to their servers.

and that the bug has been fixed in OpenBSD 5.7.
there is supposedly a back port to OpenBSD 5.5 

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/asr/gethostnamadr_async.c.diff?r1=1.34r2=1.35

I did not try the back port, since I intended to move to 5.7. which I did and 
messages again are going to Hotmail

I don't know why the original sender just sent a private message.


-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Peter 
van Oord van der Vlies
Sent: Saturday, May 23, 2015 1:44 PM
To: Peter Fraser
Cc: misc@openbsd.org
Subject: Re: hotmail rejecting messages relay=mx4.hotmail.com., dsn=5.1.2, 
stat=Host unknown (Unknown error: 275)

 Op 23 mei 2015 om 17:54 heeft Peter Fraser p...@thinkage.ca het volgende 
 geschreven:
 
 Any message sent to send mail seems to be rejected. The mx4 name changes, but 
 the rejection is always the same.
 It would be nice to know what the unknown error is
 
 Does anyone have any idea what is causing the problems

Since friday we have the same problem on different servers. 
I am happy to see this is a global issue...
 
 I am currently using OpenBSD 5.5 with sendmail (I know I should update 
 it but I haven't got around to it yet)
 
I am with openbsd 5.5 too, lower versions also but havent checked yet.

Re: hotmail rejecting messages relay=mx4.hotmail.com., dsn=5.1.2, stat=Host unknown (Unknown error: 275)

[Bryan Steele]

On Sat, May 23, 2015 at 07:31:27PM +0200, Matthieu Herrb wrote:
 On Sat, May 23, 2015 at 03:52:38PM +, Peter Fraser wrote:
  Any message sent to send mail seems to be rejected. The mx4 name changes, 
  but the rejection is always the same.
  It would be nice to know what the unknown error is
  
  Does anyone have any idea what is causing the problems
  
  I am currently using OpenBSD 5.5 with sendmail
  (I know I should update it but I haven't got around to it yet)
  
 hotmail recently added a 17th IP address to ther servers.
 There is a bug in libc's resolver that make it fail if there are more
 then 16 adresses for a name.
 
 This bug has been fixed in OpenBSD 5.7.
 I recently backported the commit to 5.5 for the very same reason
 (hotmail became unreachable) without trouble.
 
 http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/asr/gethostnamadr_async.c.diff?r1=1.34r2=1.35
 
 -- 
 Matthieu Herrb

I've committed a fix to 5.6 -stable, this bug was introduced when eric@
switched to the new async resolver (asr) in OpenBSD 5.4.

OpenBSD 5.6 and 5.7 are the two currently supported releases of OpenBSD,
so when possible, you should upgrade to 5.7 or at least 5.6-stable.

If you wish to prolong the inevitable, well, then you can do as Matthieu
suggests and backport this yourself.

:-)

-Bryan.

Re: hotmail rejecting messages relay=mx4.hotmail.com., dsn=5.1.2, stat=Host unknown (Unknown error: 275)

[Peter Fraser]

I should add that all the mx names resolve with nslookup and a 
telnet mx4.hotmail 25 does work

-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Peter 
Fraser
Sent: Saturday, May 23, 2015 11:53 AM
To: 'misc@openbsd.org'
Subject: hotmail rejecting messages relay=mx4.hotmail.com., dsn=5.1.2, 
stat=Host unknown (Unknown error: 275)

Any message sent to send mail seems to be rejected. The mx4 name changes, but 
the rejection is always the same.
It would be nice to know what the unknown error is

Does anyone have any idea what is causing the problems

I am currently using OpenBSD 5.5 with sendmail (I know I should update it but I 
haven't got around to it yet)

Re: hotmail rejecting messages relay=mx4.hotmail.com., dsn=5.1.2, stat=Host unknown (Unknown error: 275)

[Matthieu Herrb]

On Sat, May 23, 2015 at 03:52:38PM +, Peter Fraser wrote:
 Any message sent to send mail seems to be rejected. The mx4 name changes, but 
 the rejection is always the same.
 It would be nice to know what the unknown error is
 
 Does anyone have any idea what is causing the problems
 
 I am currently using OpenBSD 5.5 with sendmail
 (I know I should update it but I haven't got around to it yet)
 
hotmail recently added a 17th IP address to ther servers.
There is a bug in libc's resolver that make it fail if there are more
then 16 adresses for a name.

This bug has been fixed in OpenBSD 5.7.
I recently backported the commit to 5.5 for the very same reason
(hotmail became unreachable) without trouble.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/asr/gethostnamadr_async.c.diff?r1=1.34r2=1.35

-- 
Matthieu Herrb

hotmail rejecting messages relay=mx4.hotmail.com., dsn=5.1.2, stat=Host unknown (Unknown error: 275)

[Peter Fraser]

Any message sent to send mail seems to be rejected. The mx4 name changes, but 
the rejection is always the same.
It would be nice to know what the unknown error is

Does anyone have any idea what is causing the problems

I am currently using OpenBSD 5.5 with sendmail
(I know I should update it but I haven't got around to it yet)

unknown product for Atheros AR9287

[Clementine Duvalier]

Hi,

After installing an Atheros mini-PCIe wireless card I get the following in
dmesg:

OpenBSD 5.7 (GENERIC) #0: Fri May  8 22:18:03 EDT 2015
[...]
vendor Atheros, unknown product 0xff1c (class network subclass ethernet,
rev 0x01) at pci4 dev 0 function 0 not configured

The card's chip has AR9287-BL1A written on it and athn(4) lists AR9287 as
supported.

In sys/dev/pci/pcidevs the chip indeed has a different number:
product ATHEROS AR9287  0x002e  AR9287

What could be wrong here?

Thanks

Clementine

Re: pkg_add vs. cvs -up, and pkg_check telling me about unknown files directories

[Marc Espie]

On Wed, Feb 25, 2015 at 05:35:43PM +0900, Joel Rees wrote:
 So the file system is the package management system?

File system == base system + xenocara + pkg system + user files

We now have mostly accurate information for all of these, which is
what the end run of pkg_check tries to do.

 Is, perhaps, pkg_check trying to do too many things, maybe?

Nah, it's just not finished yet, but we don't have any tools being able
to clean up the base system. And since there is stuff in /etc that actually
belongs to the pkg system, I see no way around that.

Also, assuming you only have base systems and packages installed, knowing
when to remove old shared libraries is something we have information for...

So, yeah, it's the correct place to do things.  You can't do it without
having all the packaging information.

Re: pkg_add vs. cvs -up, and pkg_check telling me about unknown files directories

[Joel Rees]

On Wed, Feb 25, 2015 at 12:17 AM, Marc Espie es...@nerim.net wrote:
 For instance, here's what pkg_check says on a somewhat older machine
 I haven't cleansed in a while, along with my commentary.

 (warning, long post).

Indeed.

 Like they said, the devil lies in the details.   There are about 10 (or more)
 special cases I haven't taken care of yet...

 Not found:
 /.install_started
 (fun, old bsd.rd stuff)
 /basename.core
 (fun, a core)
 /bin/badsh
 (okay, my bad, pie fuckup)
 /bin/rcp
 /bin/rmail
 /bin/sum
 (now, those are old things)
 /boot

Okay, I think I see that I don't need to worry about the unknown
files/directories it reports.

 (that one should be an exception)
 /bsd
 /bsd.120320
 /bsd.120828
 /bsd.120927
 /bsd.121106
 /bsd.130423
 /bsd.130430
 /bsd.130514
 /bsd.130711
 /bsd.130723
 /bsd.131015
 /bsd.131113
 /bsd.131210
 /bsd.140715
 /bsd.150121
 /bsd.rd
 /bsd.sp
 (should I ignore everything as bsd* ?)

Depends on the purpose, I'd guess.

 /dos

Is that a mount point in your system, too?

 /etc/X11/app-defaults/Beforelight
  [...]

So the file system is the package management system?

Is, perhaps, pkg_check trying to do too many things, maybe?

Anyway, now I'm pretty sure I can safely assume that, since pkg_info
is working again, I don't have to scratch my ports partition and
re-populate it from scratch.

Still not sure why pkg_info and pkg_add were geting stuck until I used
pkg_check.

Thanks,

Joel Rees

Re: pkg_add vs. cvs -up, and pkg_check telling me about unknown files directories

[Marc Espie]

On Sun, Feb 22, 2015 at 10:46:36PM +0900, Joel Rees wrote:
 I then tried using pkg_check to see if I could clear whatever I had
 done, and it tells me about unknown directories and files, a long list
 of files and directories which should have nothing to do with
 packages, I think, including such things as /boot, /bsd, about 30
 files in /etc, the pkg_check_out.text I produced in my /root directory
 to try to understand the output and a bunch of other stuff. It does
 not output my entire file system tree.
[...]
 Marc or anyone care to enlighten me on what the output from pkg_check
 is supposed to mean? (I'm thinking it may have something to do with
 mtree, but I'm not remembering what to look at for that.)

That part of pkg_check is not totally finished. It does check the full
fs, and remove anything it knows about (thanks to the various locate(8)dbs
and to /var/db/pkg) plus a few well known positives, but I haven't gotten
around to teaching it the few important exceptions that remain.

And also, some packages create ghost data. On my todo list to register
properly with pkgs.

You can usually use it to remove some older stuff, older gcc and perl modules
that no longer exist in base show up as a sore thumb.

I guess THAT specific functionality is mostly developer material for now.
When you already know the system well, it can be very useful.

pkg_add vs. cvs -up, and pkg_check telling me about unknown files directories

[Joel Rees]

I recently tried, for fun, or because I wasn't thinking, I'm not sure
which, doing a cvs -up in /usr/ports. It told me P or U for
archivers/cabextract, net/isc-bind, and www/drupal6/views, none of
which should be installed on my system. (I don't remember which was P
and which U.) Since they are not supposed to be installed, I did not
run make in any of their directories in /usr/ports.

I tried to use pkg_info and pkg_add -n to figure out if they were
installed after all, and pkg_add started hanging, and then pkg_info
started hanging.

I then tried using pkg_check to see if I could clear whatever I had
done, and it tells me about unknown directories and files, a long list
of files and directories which should have nothing to do with
packages, I think, including such things as /boot, /bsd, about 30
files in /etc, the pkg_check_out.text I produced in my /root directory
to try to understand the output and a bunch of other stuff. It does
not output my entire file system tree.

After using pkg_check several times, pkg_add and pkg_info are no
longer hanging. And pkg_add -u seems to do what it is supposed to do.

Marc or anyone care to enlighten me on what the output from pkg_check
is supposed to mean? (I'm thinking it may have something to do with
mtree, but I'm not remembering what to look at for that.)

Joel Rees

Re: pkg_add vs. cvs -up, and pkg_check telling me about unknown files directories

[Jérémie Courrèges-Anglas]

Joel Rees joel.r...@gmail.com writes:

 I recently tried, for fun, or because I wasn't thinking, I'm not sure
 which, doing a cvs -up in /usr/ports. It told me P or U for
 archivers/cabextract, net/isc-bind, and www/drupal6/views, none of
 which should be installed on my system. (I don't remember which was P
 and which U.) Since they are not supposed to be installed, I did not
 run make in any of their directories in /usr/ports.

cvs operations have little to do with the packages you have installed /
ports you have built.

  man cvs | less +'/ U '

pkg_check is known to report false positives.  I doubt there is enough
data to tell whether your pkg_add / pkg_info glitches are real issues or
just local, transient errors.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: unknown ethernet: intel dual-port gig copper

[Chris Cappuccio]

Jim Rowan [j...@computing.com] wrote:
 
 That's really odd... I cut/paste that line directly from the serial
 console.. I don't know how it got to be showing 0x8096 instead of 0x8086.
 
 Sorry for the false alarm!   (I'll still have to track down what's wrong
 with flashrd... as I want to use it.)

Growing the GENERIC kernel (such as by adding a ramdisk) can write beyond
the intended area. Raising NKPTP on i386 isn't always enough. I don't
understand the problem well enough to provide an immediate solution. It 
has been a while since I've seen problems on i386 or amd64, but GENERIC
keeps getting bigger :)

Chris

unknown ethernet: intel dual-port gig copper

[Jim Rowan]

Hi,

On 5.6 (I haven't tried this with anything older yet) my network card  
isn't recognized.   It's an intel dual-port gig-e card.


unknown vendor 0x8096 product 0x1010 (class network subclass ethernet,  
rev 0x11) at pci0 dev 8 function 0 not configured


Can I do something to use this card?



Here's the full dmesg:

OpenBSD 5.6-stable (FLASHRD) #72: Sat Oct 11 13:37:21 MDT 2014
r...@mina.nmedia.net:/usr/src/sys/arch/i386/compile/FLASHRD
cpu0: VIA C7 Processor 1000MHz (CentaurHauls 686-class) 1 GHz
cpu0:  
FPU 
,V86 
,DE 
,PSE 
,TSC 
,MSR 
,PAE 
,MCE 
,CX8 
,SEP 
,MTRR 
,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,NXE,SSE3,EST,TM2,xTPR

real mem  = 518418432 (494MB)
avail mem = 496074752 (473MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 01/22/08, BIOS32 rev. 0 @  
0xfb180, SMBIOS rev. 2.3 @ 0xf0800 (33 entries)
bios0: vendor Phoenix Technologies, LTD version 6.00 PG date  
01/22/2008

bios0: Neoware Inc. Thin Client
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP
acpi0: wakeup devices PCI0(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3)  
USB4(S3) USB5(S3) USB6(S3) USB7(S3) LAN0(S5) AC97(S5) UAR1(S5)

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0
acpibtn0 at acpi0: PWRB
bios0: ROM list: 0xc/0xda00
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: RNG AES AES-CTR SHA1 SHA256 RSA
cpu0: unknown Enhanced SpeedStep CPU, msr 0x08100a1308000a13
cpu0: using only highest and lowest power states
cpu0: Enhanced SpeedStep 998 MHz: speeds: 1333, 1067 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 VIA CN700 Host rev 0x00
viaagp0 at pchb0: v3
agp0 at viaagp0: aperture at 0xe800, size 0x1000
pchb1 at pci0 dev 0 function 1 VIA CN700 Host rev 0x00
pchb2 at pci0 dev 0 function 2 VIA CN700 Host rev 0x00
pchb3 at pci0 dev 0 function 3 VIA PT890 Host rev 0x00
pchb4 at pci0 dev 0 function 4 VIA CN700 Host rev 0x00
pchb5 at pci0 dev 0 function 7 VIA CN700 Host rev 0x00
ppb0 at pci0 dev 1 function 0 VIA VT8377 AGP rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 VIA S3 Unichrome PRO IGP rev 0x01
vga1: aperture needed
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
unknown vendor 0x8096 product 0x1010 (class network subclass ethernet,  
rev 0x11) at pci0 dev 8 function 0 not configured
pciide0 at pci0 dev 15 function 0 VIA VT82C571 IDE rev 0x06: ATA133,  
channel 0 configured to compatibility, channel 1 configured to  
compatibility

wd0 at pciide0 channel 0 drive 0: TS2GCF133
wd0: 1-sector PIO, LBA, 1911MB, 3915072 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4
pciide0: channel 1 disabled (no drives)
uhci0 at pci0 dev 16 function 0 VIA VT83C572 USB rev 0x81: irq 11
uhci1 at pci0 dev 16 function 1 VIA VT83C572 USB rev 0x81: irq 11
uhci2 at pci0 dev 16 function 2 VIA VT83C572 USB rev 0x81: irq 5
uhci3 at pci0 dev 16 function 3 VIA VT83C572 USB rev 0x81: irq 5
ehci0 at pci0 dev 16 function 4 VIA VT6202 USB rev 0x86: irq 10
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 VIA EHCI root hub rev 2.00/1.00 addr 1
viapm0 at pci0 dev 17 function 0 VIA VT8237 ISA rev 0x00: SMI
iic0 at viapm0
spdmem0 at iic0 addr 0x50: 512MB DDR2 SDRAM non-parity PC2-5300CL5 SO- 
DIMM

auvia0 at pci0 dev 17 function 5 VIA VT8233 AC97 rev 0x60: irq 10
ac97: codec id 0x56494161 (VIA Technologies VT1612A)
ac97: codec features headphone, 18 bit DAC, 18 bit ADC, KS Waves 3D
audio0 at auvia0
vr0 at pci0 dev 18 function 0 VIA RhineII-2 rev 0x78: irq 11,  
address 00:e0:c5:48:89:d1
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 10: OUI  
0x004063, model 0x0032

usb1 at uhci0: USB revision 1.0
uhub1 at usb1 VIA UHCI root hub rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 VIA UHCI root hub rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 VIA UHCI root hub rev 1.00/1.00 addr 1
usb4 at uhci3: USB revision 1.0
uhub4 at usb4 VIA UHCI root hub rev 1.00/1.00 addr 1
isa0 at mainbus0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
wbsio0 at isa0 port 0x2e/2: W83697HF rev 0x12
lm1 at wbsio0 port 0x290/8: W83697HF
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
uhidev0 at uhub1 port 1 configuration 1 interface 0 CHICONY USB  
Keyboard rev 1.10/1.03 addr 2

uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub1 port 1 configuration 1 interface 1 CHICONY USB  
Keyboard rev 1.10/1.03 addr 2

uhidev1: iclass 3/1
ums0

Re: unknown ethernet: intel dual-port gig copper

[Jonathan Gray]

On Sat, Oct 25, 2014 at 07:35:46PM -0500, Jim Rowan wrote:
 Hi,
 
 On 5.6 (I haven't tried this with anything older yet) my network card  
 isn't recognized.   It's an intel dual-port gig-e card.
 
 unknown vendor 0x8096 product 0x1010 (class network subclass ethernet,  
 rev 0x11) at pci0 dev 8 function 0 not configured
 
 Can I do something to use this card?

I can't find any mention of any other Intel device with a 0x8096
vendor id.  0x8086 0x1010 is 82546EB Copper, what does the chip
have printed on it?

Re: unknown ethernet: intel dual-port gig copper

[Jim Rowan]

On Oct 25, 2014, at 9:47 PM, Jonathan Gray wrote:


On Sat, Oct 25, 2014 at 07:35:46PM -0500, Jim Rowan wrote:

Hi,

On 5.6 (I haven't tried this with anything older yet) my network card
isn't recognized.   It's an intel dual-port gig-e card.

unknown vendor 0x8096 product 0x1010 (class network subclass  
ethernet,

rev 0x11) at pci0 dev 8 function 0 not configured

Can I do something to use this card?


I can't find any mention of any other Intel device with a 0x8096
vendor id.  0x8086 0x1010 is 82546EB Copper, what does the chip
have printed on it?


That's what it is.  I had been using the flashrd 5.6 image earlier..  
and apparently this weirdness has something to do with that.  Booting  
from a fresh 5.5 install recognizes it properly and shows this message:


em0 at pci0 dev 8 function 0 Intel 82546EB rev 0x01: irq 11, address  
00:11:0a:5f:eb:34
em1 at pci0 dev 8 function 1 Intel 82546EB rev 0x01: irq 10, address  
00:11:0a:5f:eb:35


That's really odd... I cut/paste that line directly from the serial  
console.. I don't know how it got to be showing 0x8096 instead of  
0x8086.


Sorry for the false alarm!   (I'll still have to track down what's  
wrong with flashrd... as I want to use it.)

Re: Unknown bgp issue

[Andy]

If you were trying to ping both of your BGP peers (and failing), I'm 
guessing both are on directly connected subnets as per eBGP rules.


As they are directly connected, routing protocols shouldn't have been 
an issue so it was probably the firewall.


If I remember correctly, if you block outbound pings you get a 'no 
route to host'. So it sounds like it could have been a PF resource 
problem.


Do you run PF and how many states do you have usually?


On Sat 12 Apr 2014 18:54:11 BST, Randhir Prakash wrote:

Hi,

I have been using Openbgpd on Openbsd from last 3 years without any issue.
We are having two upstream providers with full route. Suddenly last week, i
observed that our network became unreachable from internet and sometimes
fluctuating in terms of reachability. I checked the bgp session using
bgpctl show summary which was showing bgp session alive and
PrfRcvd(Received prefix) from our peers was fine.

When i tried to ping to both peers WAN IP or any inetrnet ip, it was
telling no route to host.

When i connected peers wan ip to standalone system and tried pinging, it
was pinging.

I was not able to figure out the issue and after 45-60 minutes,
automatically everything got rectified and became normal.

I am not having any idea about this issue and want to explore to avoid such
situations in production environment. Kindly assist.

Unknown bgp issue

[Randhir Prakash]

Hi,

I have been using Openbgpd on Openbsd from last 3 years without any issue.
We are having two upstream providers with full route. Suddenly last week, i
observed that our network became unreachable from internet and sometimes
fluctuating in terms of reachability. I checked the bgp session using
bgpctl show summary which was showing bgp session alive and
PrfRcvd(Received prefix) from our peers was fine.

When i tried to ping to both peers WAN IP or any inetrnet ip, it was
telling no route to host.

When i connected peers wan ip to standalone system and tried pinging, it
was pinging.

I was not able to figure out the issue and after 45-60 minutes,
automatically everything got rectified and became normal.

I am not having any idea about this issue and want to explore to avoid such
situations in production environment. Kindly assist.


-- 
Thanks and regards,
*Randhir Prakash*

Re: Dovecot bsdauth(user): unknown user

[Атанас Владимиров]

Oof.  I didn't notice this earlier, but you're running -current, and
this has seen some changes in the last week.  You might want to take a
look at this thread: http://marc.info/?t=13910782254r=1w=2

I don't have an easy way to test (not running -current or using
passwd/bsdauth), and it's not clear from the discussion whether the
changes that fixed dovecot in Brad's testing were committed or not.
However, it looks like one more fix to getpwent.c was committed after
your last update, and it's probably worth trying.

Based on the info you provided, today I made another `make release`.
Now everything is working as it should be. Sorry for making a fuss
and thanks for the help.

Atanas Vladimirov

Re: Dovecot bsdauth(user): unknown user

[Атанас Владимиров]

 # pwd_mkdb
 usage: pwd_mkdb [-c] [-p | -s] [-d directory] [-u username] file
 # pwd_mkdb -c /etc/master.passwd
 #

 It seems that everything is OK, isn't it?.

Did the problems with unknown user persist afterward?

Yes, the problem persist.

$ sudo doveadm auth test vlado
Password:
passdb: vlado auth failed
extra fields:
  user=vlado
$ sudo pwd_mkdb
usage: pwd_mkdb [-c] [-p | -s] [-d directory] [-u username] file
$ sudo pwd_mkdb -c /etc/master.passwd
$ sudo doveadm auth test vlado
Password:
passdb: vlado auth failed
extra fields:
  user=vlado

$ tail /var/log/maillog
Mar 10 08:08:16 ns dovecot: auth-worker(21267): bsdauth(vlado):
unknown user (given password: K4*x9)
Mar 10 08:08:51 ns dovecot: auth-worker(21267): bsdauth(vlado):
unknown user (given password: Qa*we00)
Mar 10 08:09:41 ns dovecot: auth-worker(21267): bsdauth(vlado):
unknown user (given password: K*rx9)
Mar 10 08:10:18 ns dovecot: auth-worker(21267): bsdauth(vlado):
unknown user (given password: K*x9)

If I enter wrong password error for the account that is working
normaly, error is password mismatch. With correct password for the
same account the log is silent as it should to be.


$ sudo doveadm auth test jul
Password:
passdb: jul auth failed
extra fields:
  user=jul

$ tail /var/log/maillog

Mar 10 09:50:38 ns dovecot: auth-worker(836): bsdauth(jul): Password
mismatch (given password: Qazxsw)

Re: Dovecot bsdauth(user): unknown user

[Matthew Weigel]

On 03/10/2014 02:57 AM, Атанас Владимиров wrote:


Yes, the problem persist.


Oof.  I didn't notice this earlier, but you're running -current, and 
this has seen some changes in the last week.  You might want to take a 
look at this thread: http://marc.info/?t=13910782254r=1w=2


I don't have an easy way to test (not running -current or using 
passwd/bsdauth), and it's not clear from the discussion whether the 
changes that fixed dovecot in Brad's testing were committed or not. 
However, it looks like one more fix to getpwent.c was committed after 
your last update, and it's probably worth trying.

--
 Matthew Weigel
 hacker
 unique  idempot . ent

Re: Dovecot bsdauth(user): unknown user

[Alexander Hall]

On 03/08/14 23:30, Атанас Владимиров wrote:

Hi,
I have a very strange problem with one user. After upgrade from home made
release today dovecot stoped authenticating my account. Root and other
accounts are working well. I also made two new accounts which worked as
they should. It seems that for dovecot my account (vlado) not exists.
Thanks for any help.


Do the two new accounts have the same login class (=staff)? I would 
check the various auth= and auth-*= settings in /etc/login.conf.


/Alexander

In case the error message is a bit misleading



#
/var/log/maillog:

Mar  8 23:40:20 ns dovecot: auth-worker(2646): bsdauth(vlado): unknown user
(given password: Qazxswe00)
Mar  8 23:42:12 ns dovecot: auth-worker(6589): bsdauth(vlado): unknown user
(given password: Qzxswe00)
Mar  8 23:42:40 ns dovecot: auth-worker(6589): bsdauth(vlado): unknown user
(given password: Qawe00)
Mar  8 23:43:15 ns dovecot: auth-worker(6589): bsdauth(vlado): unknown user
(given password: Qaze00)
Mar  8 23:43:36 ns dovecot: auth-worker(6589): bsdauth(vlado): unknown user
(given password: dsd)

#
/etc/passwd

_dovecot:*:518:518:Dovecot Account:/nonexistent:/sbin/nologin
_dovenull:*:666:666:Dovecot Login User:/nonexistent:/sbin/nologin
_netflow:*:575:575:flow-tools user:/var/empty:/sbin/nologin
_nfcapd:*:649:649:nfcapd user:/nonexistent:/sbin/nologin
vlado:*:1000:1000:Atanas Vladimirov:/home/vlado:/bin/ksh


#
/etc/master.passwd
_netflow:*:575:575:daemon:0:0:flow-tools
user:/var/empty:/sbin/nologin
_nfcapd:*:649:649:daemon:0:0:nfcapd
user:/nonexistent:/sbin/nologin
vlado:$2a$06$iVr1p*hmfMLW:1000:1000:staff:0:0:Atanas
Vladimirov:/home/vlado:/bin/ksh

#
$ dovecot -n

# 2.2.10: /etc/dovecot/dovecot.conf
# OS: OpenBSD 5.5 i386
auth_debug = yes
auth_verbose = yes
auth_verbose_passwords = plain
first_valid_uid = 1000
imap_client_workarounds = delay-newmail tb-extra-mailbox-sep tb-lsub-flags
mail_debug = yes
mbox_write_locks = fcntl
mmap_disable = yes
namespace inbox {
   inbox = yes
   location =
   mailbox Drafts {
 special_use = \Drafts
   }
   mailbox Junk {
 special_use = \Junk
   }
   mailbox Sent {
 special_use = \Sent
   }
   mailbox Sent Messages {
 special_use = \Sent
   }
   mailbox Trash {
 special_use = \Trash
   }
   prefix =
}
passdb {
   driver = bsdauth
}
pop3_client_workarounds = outlook-no-nuls oe-ns-eoh
ssl = required
ssl_cert = /etc/ssl/dovecotcert.pem
ssl_key = /etc/ssl/private/dovecot.pem
userdb {
   driver = passwd
}

#
dmesg:

OpenBSD 5.5-current (GENERIC.MP) #0: Sat Mar  8 14:41:24 EET 2014
 r...@i386.bsdbg.net:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ (AuthenticAMD
686-class, 512KB L2 cache) 2.31 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,NXE,MMXX,FFXSR,LON
G,3DNOW2,3DNOW,SSE3,CX16,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
real mem  = 2129096704 (2030MB)
avail mem = 2081988608 (1985MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 06/02/10, BIOS32 rev. 0 @ 0xf2030,
SMBIOS rev. 2.4 @ 0xf (70 entries)
bios0: vendor Phoenix Technologies, LTD version ASUS M2NPV-VM ACPI BIOS
Revision 5005 date 06/02/2010
bios0: ASUSTek Computer INC. M2NPV-VM
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP MCFG APIC
acpi0: wakeup devices HUB0(S5) XVRA(S5) XVRB(S5) XVRC(S5) UAR1(S5) UAR2(S5)
PS2M(S4) PS2K(S4) USB0(S4) USB2(S4) AZAD(S5) MMAC
(S5) MMCI(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ (AuthenticAMD
686-class, 512KB L2 cache) 2.31 GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,NXE,MMXX,FFXSR,LON
G,3DNOW2,3DNOW,SSE3,CX16,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 11, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 4
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (HUB0)
acpicpu0 at acpi0
acpicpu1 at acpi0
acpitz0 at acpi0: critical temperature is 75 degC
acpibtn0 at acpi0: PWRB
aibs0 at acpi0 RTMP RVLT RFAN
aibs0: FSIF: misformed package: 3/5, assume 5
bios0: ROM list: 0xc/0xec00 0xd4000/0x1000 0xd5000/0x1000
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
NVIDIA C51 Host rev 0xa2 at pci0 dev 0 function 0 not configured
NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 2 not configured
NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 3 not configured
NVIDIA C51 Memory rev 0xa2 at pci0 dev 0

Re: Dovecot bsdauth(user): unknown user

[Атанас Владимиров]

No, they had default login class. I'm still trying to find out some pattern
when and why this behavior occurs. When I create new account with `useradd
accountname` then set a password with `passwd accountname` and then
`doveadm auth test accountname`, everything seems good. Then `usermod -L
default accountname` and doveadm auth failed. When I created new account
with adduser - doveadm failed.
An old account on the system works fine no matter in which loggin class I
move it. I tried to move my account to other class without any luck.
Here is my login.conf. I can provide other info, too. Thanks for your time.

$ cat /etc/login.conf
# $OpenBSD: login.conf.in,v 1.6 2012/02/06 21:25:13 sobrado Exp $

#
# Sample login.conf file.  See login.conf(5) for details.
#

#
# Standard authentication styles:
#
# krb5-or-pwd   First try Kerberos V password, then local password file
# passwdUse only the local password file
# krb5  Use only the Kerberos V password
# chpassDo not authenticate, but change users password (change
#   the YP password if the user has one, else change the
#   local password)
# lchpass   Do not login; change user's local password instead
# radiusUse radius authentication
# rejectUse rejected authentication
# skey  Use S/Key authentication
# activ ActivCard X9.9 token authentication
# cryptoCRYPTOCard X9.9 token authentication
# snk   Digital Pathways SecureNet Key authentication
# tis   TIS Firewall Toolkit authentication
# token Generic X9.9 token authentication
# yubikey   YubiKey authentication
#

# Default allowed authentication styles
auth-defaults:auth=passwd,skey:

# Default allowed authentication styles for authentication type ftp
auth-ftp-defaults:auth-ftp=passwd:

#
# The default values
# To alter the default authentication types change the line:
#   :tc=auth-defaults:\
# to be read something like: (enables passwd, myauth, and activ)
#   :auth=passwd,myauth,activ:\
# Any value changed in the daemon class should be reset in default
# class.
#
default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin
/usr/local/sbin:\
:umask=022:\
:datasize-max=512M:\
:datasize-cur=512M:\
:maxproc-max=256:\
:maxproc-cur=128:\
:openfiles-cur=512:\
:stacksize-cur=4M:\
:localcipher=blowfish,6:\
:ypcipher=old:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:

#
# Settings used by /etc/rc and root
# This must be set properly for daemons started as root by inetd as well.
# Be sure reset these values back to system defaults in the default class!
#
daemon:\
:ignorenologin:\
:datasize=infinity:\
:maxproc=infinity:\
:openfiles-cur=128:\
:stacksize-cur=8M:\
:localcipher=blowfish,8:\
:tc=default:

dovecot:\
:openfiles-cur=512:\
:openfiles-max=2048:\
:tc=daemon:

#
# Staff have fewer restrictions and can login even when nologins are set.
#
staff:\
:datasize-cur=2048M:\
:datasize-max=infinity:\
:maxproc-max=512:\
:maxproc-cur=128:\
:ignorenologin:\
:requirehome@:\
:tc=default:

#
# Authpf accounts get a special motd and shell
#
authpf:\
:welcome=/etc/motd.authpf:\
:shell=/usr/sbin/authpf:\
:tc=default:

#
# Override resource limits for certain daemons started by rc.d(8)
#
bgpd:\
:openfiles-cur=512:\
:tc=daemon:





2014-03-09 15:19 GMT+02:00 Alexander Hall alexan...@beard.se:

On 03/08/14 23:30, Àòàíàñ Âëàäèìèðîâ wrote:

 Hi,
 I have a very strange problem with one user. After upgrade from home
 made
 release today dovecot stoped authenticating my account. Root and other
 accounts are working well. I also made two new accounts which worked as
 they should. It seems that for dovecot my account (vlado) not exists.
 Thanks for any help.


 Do the two new accounts have the same login class (=staff)? I would
 check the various auth= and auth-*= settings in /etc/login.conf.

 /Alexander

 In case the error message is a bit misleading



 #
 /var/log/maillog:

 Mar  8 23:40:20 ns dovecot: auth-worker(2646): bsdauth(vlado): unknown
 user
 (given password: Qazxswe00)
 Mar  8 23:42:12 ns dovecot: auth-worker(6589): bsdauth(vlado): unknown
 user
 (given password: Qzxswe00)
 Mar  8 23:42:40 ns dovecot: auth-worker(6589): bsdauth(vlado): unknown
 user
 (given password: Qawe00)
 Mar  8 23:43:15 ns dovecot: auth-worker(6589): bsdauth(vlado): unknown
 user
 (given password: Qaze00)
 Mar  8 23:43:36 ns dovecot: auth-worker(6589): bsdauth(vlado): unknown
 user
 (given password: dsd)

 #
 /etc/passwd
 
 _dovecot:*:518:518:Dovecot Account:/nonexistent:/sbin/nologin
 _dovenull:*:666:666:Dovecot Login User:/nonexistent:/sbin/nologin
 _netflow:*:575:575:flow-tools

Re: Dovecot bsdauth(user): unknown user

[Matthew Weigel]

On 03/09/2014 12:47 PM, Атанас Владимиров wrote:
 No, they had default login class. I'm still trying to find out some pattern
 when and why this behavior occurs. When I create new account with `useradd
 accountname` then set a password with `passwd accountname` and then
 `doveadm auth test accountname`, everything seems good. Then `usermod -L
 default accountname` and doveadm auth failed. When I created new account
 with adduser - doveadm failed.
 An old account on the system works fine no matter in which loggin class I
 move it. I tried to move my account to other class without any luck.
 Here is my login.conf. I can provide other info, too. Thanks for your time.

What happens if you just run pwd_mkdb -c /etc/master.passwd as root?
What about just pwd_mkdb? It looks like the error you're seeing in the
log (bsdauth(vlado): unknown user...) comes down to a failure in
getpwent_r(), and would be causing problems before the user's login
class is relevant.
-- 
 Matthew Weigel
 hacker
 unique  idempot . ent

Re: Dovecot bsdauth(user): unknown user

[Атанас Владимиров]

What happens if you just run pwd_mkdb -c /etc/master.passwd as root?
What about just pwd_mkdb? It looks like the error you're seeing in the
log (bsdauth(vlado): unknown user...) comes down to a failure in
getpwent_r(), and would be causing problems before the user's login
class is relevant.

# pwd_mkdb
usage: pwd_mkdb [-c] [-p | -s] [-d directory] [-u username] file
# pwd_mkdb -c /etc/master.passwd
#

It seems that everything is OK, isn't it?.

Re: Dovecot bsdauth(user): unknown user

[Matthew Weigel]

On 03/09/2014 03:25 PM, Атанас Владимиров wrote:
 What happens if you just run pwd_mkdb -c /etc/master.passwd as root?
 What about just pwd_mkdb? It looks like the error you're seeing in the
 log (bsdauth(vlado): unknown user...) comes down to a failure in
 getpwent_r(), and would be causing problems before the user's login
 class is relevant.
 
 # pwd_mkdb
 usage: pwd_mkdb [-c] [-p | -s] [-d directory] [-u username] file
 # pwd_mkdb -c /etc/master.passwd
 #
 
 It seems that everything is OK, isn't it?.

Did the problems with unknown user persist afterward?
-- 
 Matthew Weigel
 hacker
 unique  idempot . ent

Dovecot bsdauth(user): unknown user

[Атанас Владимиров]

Hi,
I have a very strange problem with one user. After upgrade from home made
release today dovecot stoped authenticating my account. Root and other
accounts are working well. I also made two new accounts which worked as
they should. It seems that for dovecot my account (vlado) not exists.
Thanks for any help.

#
/var/log/maillog:

Mar  8 23:40:20 ns dovecot: auth-worker(2646): bsdauth(vlado): unknown user
(given password: Qazxswe00)
Mar  8 23:42:12 ns dovecot: auth-worker(6589): bsdauth(vlado): unknown user
(given password: Qzxswe00)
Mar  8 23:42:40 ns dovecot: auth-worker(6589): bsdauth(vlado): unknown user
(given password: Qawe00)
Mar  8 23:43:15 ns dovecot: auth-worker(6589): bsdauth(vlado): unknown user
(given password: Qaze00)
Mar  8 23:43:36 ns dovecot: auth-worker(6589): bsdauth(vlado): unknown user
(given password: dsd)

#
/etc/passwd

_dovecot:*:518:518:Dovecot Account:/nonexistent:/sbin/nologin
_dovenull:*:666:666:Dovecot Login User:/nonexistent:/sbin/nologin
_netflow:*:575:575:flow-tools user:/var/empty:/sbin/nologin
_nfcapd:*:649:649:nfcapd user:/nonexistent:/sbin/nologin
vlado:*:1000:1000:Atanas Vladimirov:/home/vlado:/bin/ksh


#
/etc/master.passwd
_netflow:*:575:575:daemon:0:0:flow-tools
user:/var/empty:/sbin/nologin
_nfcapd:*:649:649:daemon:0:0:nfcapd
user:/nonexistent:/sbin/nologin
vlado:$2a$06$iVr1p*hmfMLW:1000:1000:staff:0:0:Atanas
Vladimirov:/home/vlado:/bin/ksh

#
$ dovecot -n

# 2.2.10: /etc/dovecot/dovecot.conf
# OS: OpenBSD 5.5 i386
auth_debug = yes
auth_verbose = yes
auth_verbose_passwords = plain
first_valid_uid = 1000
imap_client_workarounds = delay-newmail tb-extra-mailbox-sep tb-lsub-flags
mail_debug = yes
mbox_write_locks = fcntl
mmap_disable = yes
namespace inbox {
  inbox = yes
  location =
  mailbox Drafts {
special_use = \Drafts
  }
  mailbox Junk {
special_use = \Junk
  }
  mailbox Sent {
special_use = \Sent
  }
  mailbox Sent Messages {
special_use = \Sent
  }
  mailbox Trash {
special_use = \Trash
  }
  prefix =
}
passdb {
  driver = bsdauth
}
pop3_client_workarounds = outlook-no-nuls oe-ns-eoh
ssl = required
ssl_cert = /etc/ssl/dovecotcert.pem
ssl_key = /etc/ssl/private/dovecot.pem
userdb {
  driver = passwd
}

#
dmesg:

OpenBSD 5.5-current (GENERIC.MP) #0: Sat Mar  8 14:41:24 EET 2014
r...@i386.bsdbg.net:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ (AuthenticAMD
686-class, 512KB L2 cache) 2.31 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,NXE,MMXX,FFXSR,LON
G,3DNOW2,3DNOW,SSE3,CX16,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
real mem  = 2129096704 (2030MB)
avail mem = 2081988608 (1985MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 06/02/10, BIOS32 rev. 0 @ 0xf2030,
SMBIOS rev. 2.4 @ 0xf (70 entries)
bios0: vendor Phoenix Technologies, LTD version ASUS M2NPV-VM ACPI BIOS
Revision 5005 date 06/02/2010
bios0: ASUSTek Computer INC. M2NPV-VM
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP MCFG APIC
acpi0: wakeup devices HUB0(S5) XVRA(S5) XVRB(S5) XVRC(S5) UAR1(S5) UAR2(S5)
PS2M(S4) PS2K(S4) USB0(S4) USB2(S4) AZAD(S5) MMAC
(S5) MMCI(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ (AuthenticAMD
686-class, 512KB L2 cache) 2.31 GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,NXE,MMXX,FFXSR,LON
G,3DNOW2,3DNOW,SSE3,CX16,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 11, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 4
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (HUB0)
acpicpu0 at acpi0
acpicpu1 at acpi0
acpitz0 at acpi0: critical temperature is 75 degC
acpibtn0 at acpi0: PWRB
aibs0 at acpi0 RTMP RVLT RFAN
aibs0: FSIF: misformed package: 3/5, assume 5
bios0: ROM list: 0xc/0xec00 0xd4000/0x1000 0xd5000/0x1000
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
NVIDIA C51 Host rev 0xa2 at pci0 dev 0 function 0 not configured
NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 2 not configured
NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 3 not configured
NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 4 not configured
NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 5 not configured
NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 6 not configured
NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 7 not configured
vga1 at pci0 dev 5 function 0 NVIDIA

Re: The unknown in i386-unknown-openbsd5.4

[Brad Smith]

On 02/02/14 1:50 PM, Adam Jensen wrote:

On Sun, 2 Feb 2014 18:18:06 + (UTC)
na...@mips.inka.de (Christian Weisgerber) wrote:


Miod Vallat m...@online.fr wrote:


i386-donatetoopenbsdfoundationtoday-openbsd5.4?


or i386-bikeshed-openbsd.


What is the string equivalent of goatse or tubgirl?



Maybe something simple that distinguishes compilers:

i386-gcc-openbsd5.4
i386-clang-openbsd5.4


Or something more elaborate signifies the origin:

Locally compiled:
i386-srcbld-openbsd5.4
i386-portbld-openbsd5.4

Upstream binary releases:
i386-dist-openbsd5.4
i386-package-openbsd5.4


Enough is enough. Just drop it. Of course people are
going to start making fun of this non issue.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: The unknown in i386-unknown-openbsd5.4

[Adam Jensen]

On Mon, 03 Feb 2014 05:15:39 -0500
Brad Smith b...@comstyle.com wrote:

 Enough is enough. Just drop it. Of course people are
 going to start making fun of this non issue.
 

How bizarre. I'm sorry the discussion has offended you but I
don't think your commands have any authority. If it's a delicate
topic, perhaps you could ignore the thread?

Re: The unknown in i386-unknown-openbsd5.4

[Claudio Jeker]

On Mon, Feb 03, 2014 at 11:18:30AM -0500, Adam Jensen wrote:
 On Mon, 03 Feb 2014 05:15:39 -0500
 Brad Smith b...@comstyle.com wrote:
 
  Enough is enough. Just drop it. Of course people are
  going to start making fun of this non issue.
  
 
 How bizarre. I'm sorry the discussion has offended you but I
 don't think your commands have any authority. If it's a delicate
 topic, perhaps you could ignore the thread?
 

Great, you tell a developer with almost 10'000 OpenBSD commits to have no
authority.

Fuck off.
-- 
:wq Claudio

Re: The unknown in i386-unknown-openbsd5.4

[Andy]

Claudio is one of the main developers and contributers to OpenBSD and 
does what he does for free for fun like all the devs, so we can go to 
work and get paid..


Please realise who you are talking to and learn to treat this community 
with respect whether they're a first time user, or a lead dev..


He was just trying to end a moot point.


On Mon 03 Feb 2014 16:34:36 GMT, Claudio Jeker wrote:

On Mon, Feb 03, 2014 at 11:18:30AM -0500, Adam Jensen wrote:

On Mon, 03 Feb 2014 05:15:39 -0500
Brad Smith b...@comstyle.com wrote:


Enough is enough. Just drop it. Of course people are
going to start making fun of this non issue.



How bizarre. I'm sorry the discussion has offended you but I
don't think your commands have any authority. If it's a delicate
topic, perhaps you could ignore the thread?



Great, you tell a developer with almost 10'000 OpenBSD commits to have no
authority.

Fuck off.

Re: The unknown in i386-unknown-openbsd5.4

[Adam Jensen]

On Mon, 03 Feb 2014 16:57:28 +
Andy a...@brandwatch.com wrote:

 Please realise who you are talking to and learn to treat this
 community with respect whether they're a first time user, or a
 lead dev..
 

Despite the contextual irony, that seems like a good point.
Thanks!