Re: unknown USB vendor
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
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
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
> 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
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'
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'
-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'
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
unknown warning option '-Wno-unused-but-set-variable'
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
Re: acme-client error: unknown SAN entry
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
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
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
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
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
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 > > net.ine
Re: Unknown process modifying routing table
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
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
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
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
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
Re: seeing carp interface state change for unknown reason ; cluestick hunting
> 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
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
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
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
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
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
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
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
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
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
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'
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'
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'
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'
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'
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'
> 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'
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'
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
Re: amd64 cc error unknown argument '-msave-args'
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
amd64 cc error unknown argument '-msave-args'
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 in
Re: c++: error: unknown argument: '-fno-ret-protector' when compiling CURRENT userland
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&content-type=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
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&content-type=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
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
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 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&m=151299546729095&w=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
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&m=151299546729095&w=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
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
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
> > 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
> 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
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
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.
; 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.
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.
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.
On 25 July 2017 5:03:38 pm AEST, "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? 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.
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
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 cac
Re: unknown hostname on ssh tunnel end causes 'administratively prohibited: open failed'
> 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'
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, &hints, &cctx.aitop)) != 0) { + if ((gaierr = getaddrinfo(name, strport, &hints, &cctx.aitop)) + != 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(&permitted_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: chann
unknown hostname on ssh tunnel end causes 'administratively prohibited: open failed'
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
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
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
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
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),
Re: upgrade OpenBSD 5.8 to 5.9 daemon: unknown class
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
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
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)
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.34&r2=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 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)
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.34&r2=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)
> Op 23 mei 2015 om 17:54 heeft Peter Fraser 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)
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.34&r2=1.35 -- Matthieu Herrb
Re: hotmail rejecting messages relay=mx4.hotmail.com., dsn=5.1.2, stat=Host unknown (Unknown error: 275)
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)
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)
"unknown product" for Atheros AR9287
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
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
On Wed, Feb 25, 2015 at 12:17 AM, Marc Espie 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
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.
Re: pkg_add vs. cvs -up, and pkg_check telling me about unknown files & directories
Joel Rees 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
pkg_add vs. cvs -up, and pkg_check telling me about unknown files & directories
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: unknown ethernet: intel dual-port gig copper
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
Re: unknown ethernet: intel dual-port gig copper
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 ethernet: intel dual-port gig copper
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?
unknown ethernet: intel dual-port gig copper
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: 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 i
Re: Unknown bgp issue
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
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 -c>urrent, and >this has seen some changes in the last week. You might w>ant to take a >look at this thread: http://marc.info/?t=13910782254&r=1&w=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
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=13910782254&r=1&w=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
>> # 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 aft>erward? 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
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
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
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
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 : 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):
Re: Dovecot bsdauth(user): unknown user
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 = wd0: 16-sector PIO, LBA48, 76319MB, 156301488 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 pciide0: channel 1 disabled (no drives) pciide1 at pci0 dev 14 function 0 "NVIDIA MCP51 SATA" rev 0xa1: DMA pciide1: using apic 4 int 20 for native-PCI interrupt pciide2 at pci0 dev 15 function 0 "NVIDIA MCP51 SATA" rev 0xa1: DMA pciide2: using apic 4 int 20 for native-PCI interrupt ppb0 at pci0 dev 16 function 0 "NVIDIA MCP51" rev 0xa2 pci1 at ppb0 bus 1 em0 at pci1 dev 8 function 0 "Intel 82540EM" rev 0x02: apic 4 int 16, address 00:07:e9:10:32:a8 em1 at pci1 dev 9 function 0 "Intel 82540EM" rev 0x02: apic 4 int 17, address 00:07:e9:10:2a:20 pchb0 at pci0 dev 24 function 0 "AMD AMD64 0Fh HyperTransport" rev 0x00 pchb1 at pci0 dev 24 function 1 "AMD AMD64 0Fh Address Map" rev 0x00 pchb2 at pci0 dev 24 function 2 "AMD AMD64 0Fh DRAM Cfg" rev 0x00 kate0 at pci0 dev 24 function 3 "AMD AMD64 0Fh Misc Cfg" rev 0x00: core rev BH-G1 isa0 at pcib0 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 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 it0 at isa0 port 0x2e/2: IT8716F rev 1, EC port 0x290 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root scsibus1 at softraid0: 256 targets root on wd0a (b198b672451a33ab.a) swap on wd0b dump on wd0b
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 = wd0: 16-sector PIO, LBA48, 76319MB, 156301488 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 pciide0: channel 1 disabled (no drives) pciide1 at pci0 dev 14 function 0 "NVIDIA MCP51 SATA" rev 0xa1: DMA pciide1: using apic 4 int 20 for native-PCI interrupt pciide2 at pci0 dev 15 function 0 "NVIDIA MCP51 SATA" rev 0xa1: DMA pciide2: using apic 4 int 20 for native-PCI interrupt ppb0 at pci0 dev 16 function 0 "NVIDIA MCP51" rev 0xa2 pci1 at ppb0 bus 1 em0 at pci1 dev 8 function 0 "Intel 82540EM" rev 0x02: apic 4 int 16, address 00:07:e9:10:32:a8 em1 at pci1 dev 9 function 0 "Intel 82540EM" rev 0x02: apic 4 int 17, address 00:07:e9:10:2a:20 pchb0 at pci0 dev 24 function 0 "AMD AMD64 0Fh HyperTransport" rev 0x00 pchb1 at pci0 dev 24 function 1 "AMD AMD64 0Fh Address Map" rev 0x00 pchb2 at pci0 dev 24 function 2 "AMD AMD64 0Fh DRAM Cfg" rev 0x00 kate0 at pci0 dev 24 function 3 "AMD AMD64 0Fh Misc Cfg" rev 0x00: core rev BH-G1 isa0 at pcib0 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 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 it0 at isa0 port 0x2e/2: IT8716F rev 1, EC port 0x290 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root scsibus1 at softraid0: 256 targets root on wd0a (b198b672451a33ab.a) swap on wd0b dump on wd0b
Re: The "unknown" in i386-unknown-openbsd5.4
On Mon, Feb 3, 2014 at 6:20 PM, Andy wrote: > We've all 'written' things that get misinterpreted.. context is often lost > in written language ;) > Which is a good reminder to think before you press send on that email. -- chs
Re: The "unknown" in i386-unknown-openbsd5.4
We've all 'written' things that get misinterpreted.. context is often lost in written language ;) On Mon 03 Feb 2014 17:05:25 GMT, Adam Jensen wrote: On Mon, 03 Feb 2014 16:57:28 + Andy 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!
Re: The "unknown" in i386-unknown-openbsd5.4
On Mon, 03 Feb 2014 16:57:28 + Andy 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!
Re: The "unknown" in i386-unknown-openbsd5.4
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 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
On Mon, Feb 03, 2014 at 11:18:30AM -0500, Adam Jensen wrote: > On Mon, 03 Feb 2014 05:15:39 -0500 > Brad Smith 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