Re: nslookup and dig output when using rebound

[Glenn Faustino]

Thanks Ted! :)


Regards,
Glenn

On Thu, Jan 5, 2017 at 2:41 AM, Ted Unangst  wrote:
> Glenn Faustino wrote:
>> Hi,
>>
>> The output of nslookup and dig when using rebound are like these:
>
> this finally annoyed me enough the other day i made a patch.
>
>
> Index: bin/dig/dighost.c
> ===
> RCS file: /cvs/src/usr.sbin/bind/bin/dig/dighost.c,v
> retrieving revision 1.15
> diff -u -p -r1.15 dighost.c
> --- bin/dig/dighost.c   28 Sep 2015 15:55:54 -  1.15
> +++ bin/dig/dighost.c   31 Dec 2016 20:26:11 -
> @@ -2854,7 +2854,7 @@ recv_done(isc_task_t *task, isc_event_t
> * sent to 0.0.0.0, :: or to a multicast addresses.
> * XXXMPA broadcast needs to be handled here as well.
> */
> -   if ((!isc_sockaddr_eqaddr(>sockaddr, ) &&
> +   if (0) if ((!isc_sockaddr_eqaddr(>sockaddr, ) &&
>  !isc_sockaddr_ismulticast(>sockaddr)) ||
> isc_sockaddr_getport(>sockaddr) !=
> isc_sockaddr_getport(>address)) {

Re: VPS default gateway in a different subnet than host

[Jyri Hovila [iki.fi]]

Hi!

A brief, positive update.

> Here is mpi's proposed fix:
> http://marc.info/?l=openbsd-tech=148162020419474=2

The fixed was included in CURRENT on December the 17th, and I can
report that OpenBSD now happily runs under the "default gateway in a
different subnet" scenario used at OVH Hosting.

Great work, Martin and everyone!

I'd also like to give credit to Zion VPS whose superb customer care
helped in locating the reason for the "temporary incompatibility"
between OpenBSD and OVH Hosting's platform. I've been advocating
OpenBSD to them, volunteering in creating the necessary automatic VPS
configuration scripts they need in order to provide the same "purchase
and it's already up" experience, this far available only to their Linux
customers. It may be that Zion VPS soon has OpenBSD as one of the
default choices for OS - this test/fix operation was supported by some
additional manual work by the Zion VPS staff. The service itself is
available already even though the automation is still missing; you'll
just have to ask the Zion VPS customer care to "add a custom ISO" to
your VPS host, and provide them with a link to the latest CURRENT
installation ISO. The installation process itself (as long as it has to
be handled manually) is handled over a browser based VNC session.

Yours,

Jyri

Re: httpd(8) error logging behavior

[Darren S.]

Missing dmesg:

OpenBSD 6.0 (GENERIC.MP) #2: Mon Oct 17 10:22:47 CEST 2016

r...@stable-60-amd64.mtier.org:/binpatchng/work-binpatch60-amd64/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4259938304 (4062MB)
avail mem = 4126359552 (3935MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe69d0 (27 entries)
bios0: vendor Intel Corp. version "MOPNV10N.86A.0400.2010.1019.1048"
date 10/19/2010
bios0: Intel Corporation D510MO
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG HPET SSDT
acpi0: wakeup devices SLPB(S4) PS2M(S4) PS2K(S4) UAR1(S4) UAR2(S4)
P32_(S4) ILAN(S4) PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) UHC1(S3)
UHC2(S3) UHC3(S3) UHC4(S3) EHCI(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.98 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,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 512KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.70 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,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.70 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,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
cpu2: 512KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.70 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,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
cpu3: 512KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 5 (P32_)
acpiprt1 at acpi0: bus 0 (PCI0)
acpiprt2 at acpi0: bus 1 (PEX0)
acpiprt3 at acpi0: bus 2 (PEX1)
acpiprt4 at acpi0: bus 3 (PEX2)
acpiprt5 at acpi0: bus 4 (PEX3)
acpicpu0 at acpi0: C1(1000@3 mwait.1)
acpicpu1 at acpi0: C1(1000@3 mwait.1)
acpicpu2 at acpi0: C1(1000@3 mwait.1)
acpicpu3 at acpi0: C1(1000@3 mwait.1)
acpibtn0 at acpi0: SLPB
"PNP0303" at acpi0 not configured
"PNP0400" at acpi0 not configured
"PNP0501" at acpi0 not configured
"PNP0501" at acpi0 not configured
"PNP0003" at acpi0 not configured
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02
inteldrm0 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x02
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: msi
inteldrm0: 1280x800
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: msi
azalia0: codecs: Realtek ALC662
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: msi
pci1 at ppb0 bus 1
1:0:0: mem address conflict 0xfffe/0x2
re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x03: RTL8168D/8111D
(0x2800), msi, address e0:69:95:24:36:0c
rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 2
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x01: msi
pci2 at ppb1 bus 2
ppb2 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x01: msi
pci3 at ppb2 bus 3
ppb3 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x01: msi
pci4 at ppb3 bus 4
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 8 int 23
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 8 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 8 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 8 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 8 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb4 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe1
pci5 at ppb4 bus 5
puc0 at pci5 dev 0 function 0 "Sunix 40XX" rev 0x01: ports: 4 com
com4 at puc0 port 0 apic 8 int 21: ti16750, 64 byte fifo
com4: probed fifo depth: 32 bytes
com5 at puc0 port 1 apic 8 int 

httpd(8) error logging behavior

[Darren S.]

Hi,

I wanted to validate the behavior of error logging I'm seeing in
httpd(8). What I think I'm seeing is that in some cases no error
logging occurs unless httpd is run with verbose mode (-v) enabled.
Without -v errors that result in 500 status go unlogged. Also in some
cases error logging in verbose mode provides less useful information
than might be possible.

Noted similar-ish behavior here from early 2016:

http://marc.info/?l=openbsd-misc=145429998301127=2


In my case with no modifications to 'log' directive in httpd.conf, so
expecting logging to /var/www/logs/access.log for access logs and
/var/www/logs/error.log for error logging.

With the configuration below, requests for PHP files should be passed
to the php-fpm at the given fastcgi socket, but testing without the
php-fpm daemon started causes a 500 error to be returned to client and
no log file (not in error.log, nor syslog).

Verbosity: off (/usr/sbin/httpd)
Request: http:///phpinfo.php
Logging:
==> /var/www/logs/access.log <==
default 10.0.6.23 - - [04/Jan/2017:13:37:37 -0700] "GET /phpinfo.php
HTTP/1.1" 500 0


Verbosity: on (/usr/sbin/httpd -v)
Request: http:///phpinfo.php
Logging:
==> /var/www/logs/access.log <==
default 10.0.6.23 - - [04/Jan/2017:13:40:25 -0700] "GET /phpinfo.php
HTTP/1.1" 500 0


Verbosity: on 2x (/usr/sbin/httpd -vv)
Request: http:///phpinfo.php
Logging:
==> /var/www/logs/access.log <==
default 10.0.6.23 - - [04/Jan/2017:13:41:31 -0700] "GET /phpinfo.php
HTTP/1.1" 500 0
==> /var/www/logs/error.log <==
server default, client 1 (1 active), 10.0.6.23:55640 -> 10.0.1.2, No
such file or directory (500 Internal Server Error)
server default, client 1 (1 active), 10.0.6.23:55641 -> 10.0.1.2, done


Verbosity: on 3x (/usr/sbin/httpd -vvv)
Request: http:///phpinfo.php
Logging:
==> /var/www/logs/access.log <==
default 10.0.6.23 - - [04/Jan/2017:13:43:15 -0700] "GET /phpinfo.php
HTTP/1.1" 500 0
==> /var/www/logs/error.log <==
server default, client 1 (1 active), 10.0.6.23:55652 -> 10.0.1.2, No
such file or directory (500 Internal Server Error)
server default, client 1 (1 active), 10.0.6.23:55653 -> 10.0.1.2, done


So error log is not written without verbosity being enabled and
increased with -vv. The error that does occur indicates that a file
cannot be found, but doesn't indicate which file (would expect to
indicate that it's the missing socket).


This case also seemed odd to me (this is now after php-fpm is started
and available):

Verbosity: on 3x (/usr/sbin/httpd -vvv)
Request: http:///nosuchfile.php
Logging:
==> /var/www/logs/error.log <==
Access to the script '/htdocs' has been denied (see security.limit_extensions)
==> /var/www/logs/access.log <==
default 10.0.6.23 - - [04/Jan/2017:14:29:14 -0700] "GET
/nosuchfile.php HTTP/1.1" 403 0

I would have expected this to return a 404 from httpd but it almost
seems like PHP is receiving a truncated path (/htdocs) because of the
missing file (referenced configuration comes from
/etc/php-fpm.conf:;security.limit_extensions = .php .php3 .php4
.php5).


Is the above behavior expected/correct?



kern.version=OpenBSD 6.0 (GENERIC.MP) #2: Mon Oct 17 10:22:47 CEST 2016

r...@stable-60-amd64.mtier.org:/binpatchng/work-binpatch60-amd64/src/sys/arch/amd64/compile/GENERIC.MP


### httpd.conf

ext_addr="*"

server "default" {
listen on $ext_addr port 80
listen on $ext_addr tls port 443

location "/pub/OpenBSD/*/*/*" {
directory auto index
}

location "*.php" {
fastcgi socket "/run/php-fpm.sock"
}

location "/cgi-bin/*" {
fastcgi
# The /cgi-bin directory is outside of the document root
root "/"
}

root "/htdocs"
}

-- 
Darren Spruell
phatbuck...@gmail.com

Re: nslookup and dig output when using rebound

[Ted Unangst]

Glenn Faustino wrote:
> Hi,
> 
> The output of nslookup and dig when using rebound are like these:

this finally annoyed me enough the other day i made a patch.


Index: bin/dig/dighost.c
===
RCS file: /cvs/src/usr.sbin/bind/bin/dig/dighost.c,v
retrieving revision 1.15
diff -u -p -r1.15 dighost.c
--- bin/dig/dighost.c   28 Sep 2015 15:55:54 -  1.15
+++ bin/dig/dighost.c   31 Dec 2016 20:26:11 -
@@ -2854,7 +2854,7 @@ recv_done(isc_task_t *task, isc_event_t 
* sent to 0.0.0.0, :: or to a multicast addresses.
* XXXMPA broadcast needs to be handled here as well.
*/
-   if ((!isc_sockaddr_eqaddr(>sockaddr, ) &&
+   if (0) if ((!isc_sockaddr_eqaddr(>sockaddr, ) &&
 !isc_sockaddr_ismulticast(>sockaddr)) ||
isc_sockaddr_getport(>sockaddr) !=
isc_sockaddr_getport(>address)) {

usermod: Invalid password: `*'

[Craig Skinner]

Happy Hogmanay/New Year/etc...,

My rc.firsttime script highlighted a change on 6.0's usermod:

# fgrep operator /etc/master.passwd
operator:*:2:5::0:0:System &:/operator:/sbin/nologin
# usermod -L daemon -p '*' -s /bin/ksh operator
usermod: Invalid password: `*'
 (1) # uname -a
OpenBSD oak.britvault.co.uk 6.0 GENERIC#1917 i386
# pkg_info -I passwdqc
passwdqc-1.3.0p1complexity checker for passwd(1) and password generator


Could this be related to commit 112 of user.c?

Remove the encrypted password length check.  The admin should be
able to put whatever they like in the encrypted password field,
regardless of whether it can be matched or not.  Having this check
just makes it harder to add new encrypted password functions.
This also fixes "usermode -Z" which was the impetus for the change.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/user/user.c.diff?r1=1.111=1.112=h

Or do I need to do it differently now?

Cheers,
-- 
Craig Skinner | http://linkd.in/yGqkv7

Re: The right way to delete elements from ohash

[Ted Unangst]

Maciej Adamczyk wrote:
> The task is simple: remove all elements that satisfy some property.

> * add another layer of looping and keep iterating as long as a pass over 
> the map deleted at least one element.

this should be fast enough. even with looping and resizing, it's
asymptotically linear.

The right way to delete elements from ohash

[Maciej Adamczyk]

Hello,

while debugging resource leaks in my code I found that I used ohash 
incorrectly. I came here to ask what is the best way of doing what I 
need to do.


The task is simple: remove all elements that satisfy some property.

Naively, I wrote:

for (el = ohash_first(map, ); el; el = ohash_next(map, ))

if (condition(el))

ohash_remove(el->key);


This fails, because the hash map may be resized in the middle of the 
loop. If that happens, some elements that meet the condition can be 
moved to a position before the iterator and skipped. It seems to me that 
in order to do a proper deletion, I should either:


* do 2 passes; collect keys to delete in the first and remove them in 
the second, or


* add another layer of looping and keep iterating as long as a pass over 
the map deleted at least one element.


Neither seems to be a good way of doing such a trivial task.

Please note that man is totally unhelpful:

"Those functions are safe to use even while entries are added to/removed 
from the table, but in such a case they don't guarantee that new entries 
will be returned. As a special case, they can safely be used to free 
elements in the table."


In my opinion, the man entry should be clarified.

Regards,

--
Maciej Adamczyk

Re: Watch out for bad options in /var/run/rc.d/$daemon

[Antoine Jacoutot]

> example. It starts up, and backgrounds, and then later, it parses its
> argument,
> figures it got a wrong parameter and exits.

I have a WIP diff to rc.d to fix buggy stuff like this.
But it's not ready yet.

> Then trying to add debug parameter to rc.conf.local, and see it
> not taking the debug parameter into account, because the cached
> values from /var/run/rc.d/... are used.
> It caused me a bit of head scratching before I found these cached values
> there.

It's all documented.

> I guess there might be other daemons that might expose such behaviour
> as well.
> Wondering why the cached parameters take precedence?

Because you want to be able to interact with your currently running daemon if
you happen to change the flags in rc.conf.local while it's still running.

-- 
Antoine

Re: Watch out for bad options in /var/run/rc.d/$daemon

[Sebastian Reitenbach]

On Wednesday, January 4, 2017 08:16 CET, Antoine Jacoutot
 wrote:

> On Tue, Jan 03, 2017 at 11:01:18PM -0700, Andy Bradford wrote:
> > Hello,
> >
> > Since I couldn't find any reference  to this anywhere, I thought I would
> > put out a description of the problem in the event that someone else runs
> > into it with other daemons.
> >
> > At one  point in time,  identd -l had a  different meaning than  it does
> > now. After upgrading,  I noticed that identd was not  running, thanks to
> > the following section in the daily output email:
> >
> > Services that should be running but aren't:
> > identd
> >
> > So I began investigating why it wasn't running and found the following
> > in /var/log/messages:
> >
> > Jan  3 22:46:56 obsd identd[80696]: h/auth: no address associated with
name
> > Jan  3 22:46:56 obsd identd[84721]: child has gone
> >
> > Looking at the output, it seemed  clear that something had changed, so I
> > looked at the man page for identd, and sure enough, -l is now different.
> > Previously, in /etc/rc.conf.local, I had:
> >
> > identd_flags="-elh"
> >
> > Which coincided  with the error message.  Clearly -lh meant that  it was
> > trying to look  up a host named h, which  doesn't exist, whereas before,
> > -l meant to log  to syslog. So, I removed the  -l from identd_flags, and
> > tried to  restart the daemon. Much  to my dismay, it  failed to restart,
> > even though I had corrected the problem in rc.conf.local.
> >
> > As  it turns  out, after  further investigation,  I discovered  that the
> > flags get cached in /var/run/rc.d/identd:
> >
> > $ cat /var/run/rc.d/identd
> > daemon_class=daemon
> > daemon_flags=-elh
> > daemon_rtable=0
> > daemon_timeout=30
> > daemon_user=root
> > pexp=identd: (listen|resolver)
> >
> > There's the offending -l that I thought I had removed!
> >
> > I can see why now:
> >
> >
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/rc.d/rc.subr?annotate=1.116
> >
> > On line 109, the options that are cached in the _RC_RUNFILE override any
> > that were provided before rc_cmd() was called.
> >
> > Not sure  if this is  a bug.  How often does  a command line  option get
> > repurposed for something else?
> >
> > At any rate, I wanted to give a heads up to anyone else who might end up
> > with a daemon which refuses to restart, even after the options have been
> > corrected.
>
> Nice catch, but the real issue comes from identd(8).
>
> # /usr/sbin/identd -elh
> # echo $?
> 0
> # pgrep identd
> #
>
> See, it's not running but the return code was 0 which made rc.d(8) believed
the
> daemon was properly started in which case the variable are cached (so that
we
> can still match the daemon in the process list if the flags are changed in
> rc.conf.local).
>
> Someone fix identd please :-)

I've also hit this in the past with other daemons from ports, i.e. logstash as
an
example. It starts up, and backgrounds, and then later, it parses its
argument,
figures it got a wrong parameter and exits.
Then trying to add debug parameter to rc.conf.local, and see it
not taking the debug parameter into account, because the cached
values from /var/run/rc.d/... are used.
It caused me a bit of head scratching before I found these cached values
there.

I guess there might be other daemons that might expose such behaviour
as well.
Wondering why the cached parameters take precedence?

Sebastian

>
> --
> Antoine

Re: Is it possible to follow -current after missing several versions?

[Panagiotis Liakos]

I managed to go to 5.7, I stopped there because I am now able to
install packages, and I will probably go to 6.0 later on. After
running sysmerge I was advised to "Leave for later" various changes.
Can someone point me to a guide on how to deal with these changes?

Thanks again for all your help.

--Panagiotis

2017-01-03 23:24 GMT+02:00 Kevin :
>
> On Tue, Jan 3, 2017 at 12:45 PM, Theo de Raadt  wrote:
>>
>> > > Upgrade with a snapshot.
>> > >
>> > > You don't stand a chance figuring out what we changed and making your
>> > > way
>> > > through it.
>> >
>> > Do you mean that I can simply boot with a fresh bsd.rd and upgrade my
>> > system?
>> >
>> > Thank you both for your answers.
>>
>> Yes.  Follow the advice someone else provided, to upgrade step by step
>> over
>> sequential releases.
>>
> I had a test machine that was on 5.5 that I just did this exact process on;
> it worked exactly as advertised.
>
> Updating the ports took some time since the machine had a truckload of stuff
> running on it and was so far out of patch, but for me it was worth it vs
> installing clean and restoring data from backup.