Re: ipv6 assistance

[Florian Obser]

On 2024-04-07 10:27 UTC, Stuart Henderson  wrote:
> On 2024-04-06, Florian Obser  wrote:
>> Someone with pull at UPC^W ziggo^W vodafone^W liberty global could 
>> potentially get that situation improved.
>
> Often on an OpenBSD box using one of these connections, you want
> one or more /64s rather than a host address, I don't think there's
> an alternative to DHCPv6-PD for that unless the ISP will do static
> addressing.
>

I was alluding that I would implement DHCPv6-PD in (probably) rad(8) if
ziggo stopped to be stupid. Or their cpe stopped to be stupid. I.e. the
way things get done in OpenBSD: Someone has a use case and the means to
do something about it. I have the means but no use case.

I'm currently using it with slaac so I have a single collision
domain, but all my devices get native IPv6 from a single /64.

They are not speaking DHCPv6 at all. I can login to the CPE and switch
from slaac to dhcp. Which is pretty much nonsensical. The effect is that
slaac stops working and the dhcp server tells me: no lease or something
to that effect.

There are some forum posts, all in Dutch, of people who try to argue the
finer points of IPv6 with ziggo support - which unsurprisingly isn't
going anywhere.

> Though it would be nice if they'd also allow getting a single address
> via slaac. With NAT that's enough for use on a router too ;)
>
>> On 6 April 2024 19:04:52 CEST, Peter Hessler  wrote:
>>>OpenBSD natively supports IPv6 addressing via static configuration and
>>>SLAAC.  We do not have a DHCPv6 client in base, so currently you have to
>>>use a package for that.
>
> A simple daemon that just runs as a PD client would be pretty welcome.
> At least dhcpcd is nicely privilege-separated (and uses pledge on OpenBSD)
> though it does have a lot more features than are needed for this common
> use case.
>
>
> -- 
> Please keep replies on the mailing list.
>

-- 
In my defence, I have been left unsupervised.

Re: ipv6 assistance

[Florian Obser]

Someone with pull at UPC^W ziggo^W vodafone^W liberty global could potentially 
get that situation improved.

On 6 April 2024 19:04:52 CEST, Peter Hessler  wrote:
>OpenBSD natively supports IPv6 addressing via static configuration and
>SLAAC.  We do not have a DHCPv6 client in base, so currently you have to
>use a package for that.
>
>
>On 2024 Apr 06 (Sat) at 13:01:31 -0400 (-0400), Sonic wrote:
>:That works - I didn't realize I needed to install a package to have ipv6
>:work with OpenBSD.
>:
>:Thank you.
>

-- 
Sent from a mobile device. Please excuse poor formatting.

Re: How to exit cu?

[Florian Obser]

On 2024-03-29 08:12 +01, Evan Sherwood  wrote:
> Before I learned about the tilde sequences, I just unplugged the USB
> adapter. That quits cu.
>
> Worked in my case since my device was under its own power. FYI.
>

That's neat, I always just reboot :D Same for quitting vi...

-- 
In my defence, I have been left unsupervised.

Re: rm: #08057459: Operation not permitted

[Florian Obser]

newfs(8), and restore from backup. Your filesystem is fubar.

Or a hexeditor and a steady hand, but then you are very much on your own and 
we'll just watch in amazement.

On 26 March 2024 21:30:14 CET, Peter Fraser  wrote:
>The reason why ls -l faulted has been found and is being worked on.
>
>The next step is trying to delete the files.
>Running as root
>rm fails with Operation not permitted
>so does chmod and chown end chattr
>
>Any ideas on how to get rid of the files
>
>

-- 
Sent from a mobile device. Please excuse poor formatting.

Re: configure rad for ULA addresses

[Florian Obser]

On 2024-03-24 23:33 +01, Evan Sherwood  wrote:
> I'm not sure how to configure rad (or if rad is the right program) to
> help have my devices autoconfigured ULA addresses in a given prefix
> (generated from https://www.unique-local-ipv6.com).
>
> I am debugging a new ISP and need to switch between two ISPs without
> disrupting communication between my network devices. I didn't see
> anything in rad.conf(5) that would help, other than setting a prefix
> option in my interface configuration.
>
> I tried
>
> interface igc1 {
>   prefix fdbf:e79a:8e3e::/48
  
lesser operating systems will refuse to form autoconf addresses if the
prefix length is not 64.

> }
>
> ... and restarted rad but devices that connect don't seem to get
> addresses in that prefix.
>
> Would appreciate any help and guidance I could get. Thanks!
>

-- 
In my defence, I have been left unsupervised.

Re: Request for a check 'relinking in progress' before a reboot

[Florian Obser]

On 2024-03-23 08:47 +01, Dan  wrote:
> Florian, thanks a lot for your effort, really appreciable..
>
>> Could you give this a spin please an report back? See release(8) for
>> details.
>
> Unfortunately I'm still on 7.4 stable and I cant screw down any patch for you.
> Maybe having a storagy with current on it I can be more helpful.. in
> the near future.. thinking.

No worries, take your time, we are not in a hurry.

>
> However, I hope anyoneelse can try the patch here.
>
>
>> It's not perfect. We still need to disable the ddb.console sysctl if it
>> has been activated. But we can't reenable it because of secure level, so
>> this needs some readjustment of the whole boot process.
>> We should also disable panic(9) in the kernel while reorder_kernel is
>> running. Maybe a sysctl?
>
>
> -Dan
>

-- 
In my defence, I have been left unsupervised.

Re: Request for a check 'relinking in progress' before a reboot

[Florian Obser]

On 2024-03-23 00:10 +01, Dan  wrote:
> Hello,
>
> To avoid prbs with the relinking of the kernel happening in background
> I propose to set a little check during the shutdown to avoid to interrup it..
>
> Thnx!

Could you give this a spin please an report back? See release(8) for
details.

It's not perfect. We still need to disable the ddb.console sysctl if it
has been activated. But we can't reenable it because of secure level, so
this needs some readjustment of the whole boot process.
We should also disable panic(9) in the kernel while reorder_kernel is
running. Maybe a sysctl?

diff --git libexec/reorder_kernel/reorder_kernel.sh 
libexec/reorder_kernel/reorder_kernel.sh
index fb1d151f42a..809d1e18e55 100644
--- libexec/reorder_kernel/reorder_kernel.sh
+++ libexec/reorder_kernel/reorder_kernel.sh
@@ -30,6 +30,14 @@ SHA256=/var/db/kernel.SHA256
 # Silently skip if on a NFS mounted filesystem.
 df -t nonfs $KERNEL_DIR >/dev/null 2>&1
 
+# Silently skip if battery is less than 50% remaining.
+# We know nothing of the quality of the powergrid and we do not
+# want the relink to fail halfway through because of power outage.
+(( $(/usr/sbin/apm -l)  < 50 ))
+
+# Disable halt(8) & reboot(8) to prevent interuption of the kernel relink.
+/bin/chmod 000 /sbin/{halt, reboot}
+
 # Install trap handlers to inform about success or failure via syslog.
 ERRMSG='failed'
 trap 'trap - EXIT; logger -st $PROGNAME "$ERRMSG" >/dev/console 2>&1' ERR
@@ -70,5 +78,9 @@ make newbsd
 make newinstall
 sync
 
+# Enable halt(8) & reboot(8) again. In case of a relink error we leave them
+# disabled to give the operator time to investigate.
+/bin/chmod 555 /sbin/{halt,reboot}
+
 echo "\nKernel has been relinked and is active on next reboot.\n"
 cat $SHA256


>
> -Dan
>

-- 
In my defence, I have been left unsupervised.

Re: sysupgrade doesn't work unless monitor is attached

[Florian Obser]

On 2024-03-21 10:33 +01, Christer Solskogen  
wrote:
> Nick Holland reported this with a HP T430 Thin Client already in May
> 2022, and I see the same problem on two of my new firewalls. I was
> hoping a HDMI dummy plug would work as a workaround, but it doesn't.
> I'm not sure when or what marks the bsd.upgrade file as -x, but that
> at least that happens.

that's the bootloader (to prevent upgrade loops, the bootloader will
only consider bsd.upgrade that is +x).

> Is there anything I can do to try to help?
>
> As long as a monitor is attached, sysupgrade works just as intended.
>
> -- 
> chs
>

-- 
In my defence, I have been left unsupervised.

Re: unbound signature expired

[Florian Obser]

They seem to be using extremely short-lived signatures, probably created
by an online-signer.

$ dig +short ns slack.com
ns-1493.awsdns-58.org.
ns-166.awsdns-20.com.
ns-1901.awsdns-45.co.uk.
ns-606.awsdns-11.net.

$ TZ=UTC dig @ns-1493.awsdns-58.org. +norec +dnssec +multiline +nocrypto 
slack.com

; <<>> DiG 9.18.24 <<>> @ns-1493.awsdns-58.org. +norec +dnssec +multiline 
+nocrypto slack.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8196
;; flags: qr aa ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;slack.com. IN A

;; ANSWER SECTION:
slack.com.  60 IN A 18.134.215.41
slack.com.  60 IN A 18.169.120.191
slack.com.  60 IN A 18.168.172.238
slack.com.  60 IN A 18.169.61.189
slack.com.  60 IN RRSIG A 13 2 60 (
20240318194315 20240318174215 8040 slack.com.
[omitted] )

;; Query time: 44 msec
;; SERVER: 2600:9000:5305:d500::1#53(ns-1493.awsdns-58.org.) (UDP)
;; WHEN: Mon Mar 18 18:42:15 UTC 2024
;; MSG SIZE  rcvd: 207

The signature is only valid for an hour.
Wild guess, your time is off.


On 2024-03-18 19:20 +01, Evan Sherwood  wrote:
> I have an unbound server using Quad9 as an upstream DNS provider. I have
> been unable to resolve records from slack.com recently using my local
> unbound.
>
> On the server:
>
> ```
> # dig @::1 slack.com
>
> ; <<>> dig 9.10.8-P1 <<>> @::1 slack.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54174
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; EDE: 7 (Signature Expired): 76 61 6c 69 64 61 74 69 6f 6e 20 66 61
> 69 6c 75 72 65 20 3c 73 6c 61 63 6b 2e 63 6f 6d 2e 20 41 20 49 4e 3e
> 3a 20 73 69 67 6e 61 74 75 72 65 20 65 78 70 69 72 65 64 20 66 72 6f
> 6d 20 32 36 32 30 3a 66 65 3a 3a 66 65 ("validation failure
> : signature expired from 2620:fe::fe")
> ;; QUESTION SECTION:
> ;slack.com. IN  A
>
> ;; Query time: 26 msec
> ;; SERVER: ::1#53(::1)
> ;; WHEN: Mon Mar 18 18:02:25 PDT 2024
> ;; MSG SIZE  rcvd: 116
> ```
>
> But when I try to query Quad9 directly, it works:
>
> ```
> # dig @2620:fe::fe slack.com
>
> ; <<>> dig 9.10.8-P1 <<>> slack.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2705
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ;; QUESTION SECTION:
> ;slack.com. IN  A
>
> ;; ANSWER SECTION:
> slack.com.  10  IN  A   35.81.85.251
> slack.com.  10  IN  A   44.234.235.93
> slack.com.  10  IN  A   54.70.179.16
> slack.com.  10  IN  A   44.237.180.172
> slack.com.  10  IN  A   52.89.90.67
> slack.com.  10  IN  A   54.245.50.245
> slack.com.  10  IN  A   54.188.33.22
> slack.com.  10  IN  A   54.71.95.193
> slack.com.  10  IN  A   35.82.91.193
>
> ;; Query time: 2 msec
> ;; SERVER: 2620:fe::fe#53(2620:fe::fe)
> ;; WHEN: Mon Mar 18 18:05:05 PDT 2024
> ;; MSG SIZE  rcvd: 182
> ```
>
> I've tried
>
> - `unbound-control reload`
> - `unbound-control flush slack.com`
> - `unbound-anchor`
>
> ... and there's no change. All other domains I've tried work.
>
> I am using one of StevenBlack's block lists and I changed that recently
> (from one list to another one), if that's relevant.
>
> I tried removing the block list entirely and saw no change.
>
> Here's my unbound.conf:
>
> ```
> server:
> interface: ::1
> interface: :::::
> do-ip6: yes
> ede: yes
> do-nat64: yes
> access-control: ::0/0 refuse
> access-control: ::1 allow
> access-control: ::::: allow
> access-control: 192.168.1.0/32 allow
> access-control: :::5700::/64 allow
> access-control: :::5702::/64 allow
> do-not-query-localhost: no
> hide-identity: yes
> hide-version: yes
> auto-trust-anchor-file: "/var/unbound/db/root.key"
> val-log-level: 2
> aggressive-nsec: yes
> private-address: ::1/128
> private-address: :::0:0/96
> private-address: fd00::/8
> private-address: fe80::/10
> module-config: "dns64 validator iterator"
> include: /etc/unwind.conf.deny
>
> remote-control:
> control-enable: yes
> control-interface: /var/run/unbound.sock
>
> forward-zone:
> name: "."
> forward-addr: 

Re: Programmatically add default IPv6 route

[Florian Obser]

You can probably steal the code from slaacd(8).

On 23 February 2024 20:58:59 CET, Claudio Jeker  
wrote:
>On Fri, Feb 23, 2024 at 06:25:18PM +0100, Denis Fondras wrote:
>> Hello,
>> 
>> I am trying to add IPv6 support for pppd(8) (IPv6CP) and I encounter a 
>> blocker
>> when adding a default IPv6 route to PPP peer.
>> 
>> Feb 23 17:26:45 rt-01 pppd[64071]: Couldn't add IPv6 default route: Network 
>> is unreachable
>> 
>> Adding the default route from route(8) works when the connection is 
>> established.
>> 
>> From what I see with route(8), it sends the same route message as pppd(8).
>> 
>> From `route -v add -inet6 default fe80::ca4c:75ff:fe16:9f00%ppp0` :
>> 
>> ```
>> RTM_ADD: Add Route: len 168, priority 0, table 0, if# 0, pid: 0, seq 1, 
>> errno 0
>> flags:
>> fmask:
>> use:0   mtu:0expire:0 
>> locks:  inits: 
>> sockaddrs: 
>>  :: fe80::ca4c:75ff:fe16:9f00%ppp0 default
>> ```
>> 
>> From pppd(8) :
>> ```
>> got message of size 168 on Fri Feb 23 17:26:45 2024
>> RTM_ADD: Add Route: len 168, priority 0, table 0, if# 0, pid: 64071, seq 1, 
>> errno 51
>> flags:
>> fmask:
>> use:0   mtu:0expire:0 
>> locks:  inits: 
>> sockaddrs: 
>>  :: fe80::ca4c:75ff:fe16:9f00%ppp0 default
>> ```
>> 
>> However `route monitor -inet6` shows that the message is different when using
>> route(8) :
>> ```
>> got message of size 288 on Fri Feb 23 17:26:22 2024
>> RTM_ADD: Add Route: len 288, priority 56, table 0, if# 7, name ppp0, pid: 
>> 53003, seq 1, errno 0
>> flags:
>> fmask:
>> use:0   mtu:0expire:0 
>> locks:  inits: 
>> sockaddrs: 
>>  :: fe80::ca4c:75ff:fe16:9f00%ppp0 :: ppp0 fe80::d925:b01f:db25:b020%ppp0 
>> fe80::ca4c:75ff:fe16:9f00%ppp0
>> ```
>> 
>> Should I also send the IFP, IFA and BRD sockaddrs from pppd(8) ?
>
>Don't think so.
>
>> How comes message sent from route(8) have more attributes when received by
>> monitor ?
>
>The kernel fills those in.
>
>Make sure you encode the IPv6 link local address correctly. The stupid
>kame hack will hunt you.

-- 
Sent from a mobile device. Please excuse poor formatting.

Re: Automatic OS updates

[Florian Obser]

On 15 February 2024 19:12:11 CET, b...@fea.st wrote:
>So I was curious, am I the only one using automatic OS updates
>in cron to keep the fish fresh and the bits dust free?
>
>I think I read somewhere that it's not recommended but I'm not
>running a server so it seems like a good idea to me.
>
>/etc/crontab: 
>
># Example of job definition:
># . minute (0 - 59)
># |  .- hour (0 - 23)
># |  |  .-- day of month (1 - 31)
># |  |  |  .--- month (1 - 12) OR jan,feb,mar,apr ...
># |  |  |  |  . day of week (0 - 6) (Sunday=0 or 7) OR 
>sun,mon,tue,wed,thu,fri,sat
># |  |  |  |  |
># *  *  *  *  * user-name command to be executed
>  0  3  *  *  * root  sysupgrade 

This will stop working at the next release. Assuming you want to run -current.

>30  3  *  *  * root  pkg_add -u

This will most likely run after package daemons have started. There is an 
example in upgrade.site(5) how to do this differently.

-- 
Sent from a mobile device. Please excuse poor formatting.

Re: slaacd + Thread networks = log spam

[Florian Obser]

On 2024-02-03 12:55 -05, "Stefan R. Filipek"  wrote:
> For some time, my /var/log/messages has been filled with entries like:
>
> Dec 31 14:03:58 odin slaacd[56869]: last solicitation less then 4 seconds ago
> Dec 31 14:04:08 odin last message repeated 2 times
> Dec 31 15:50:07 odin slaacd[56869]: last solicitation less then 4 seconds ago
> Dec 31 15:50:17 odin last message repeated 2 times
> ...
>
> Ad nauseum. The message comes from slaacd/engine.c's
> request_solicitation() function that limits solicitation requests to a
> defined interval.
>
> I think this is occurring in my case so often because of Thread
> networks: short-lived, ad-hoc mesh networks that come and go. It
> doesn't seem to happen all the time, but it's in line with the
> short-lived SLAAC addresses that my server gets, with 2 addresses per
> network that have a 1800s vltime.
>
> In general, it doesn't seem like these should really be warnings. The
> function is doing its job, and the nature of how IPv6 is used today
> means this behavior should be expected more.
>
> Hopefully this following change is agreeable? If anything, let's fix
> the then/than typo. (Apologies for the tabs/spaces...)

Yep.
Committed, thanks!

(There is probably more log_warn(x) in slaacd / unwind / dhcpleased that
should be log_debug)

-- 
In my defence, I have been left unsupervised.

Re: Upgrading from 7.3 to 7.4 with sysupgrade

[Florian Obser]

On 2023-11-18 15:57 +01, m...@emailgroups.net wrote:
> On Sat, Nov 18, 2023, at 11:57, Mark wrote:
>> "> That will never happen."
>> 
>> And some serious reason?
>> 
>> It was a great idea indeed. :/
>
> They don't go out of their way to assist with foot shooting.

Oh, we like foot guns as much as the next person. If they are hilarious
enough.

This one just leads to whining and hard to debug problems, and we
already have enough of each.

-- 
In my defence, I have been left unsupervised.

Re: Upgrading from 7.3 to 7.4 with sysupgrade

[Florian Obser]

On 2023-11-17 16:06 +01, Odd Martin Baanrud  wrote:
> Hello Jan,
>
> Thanks for the tip.
> The upgrade went smoothly.
> I ran “sysupgrade -n”, deleted the game set and the X sets and rebooted.
>
> Perhaps sysupgrade should be enhanced, so one could either choose
> which sets should be upgraded, or even beter, the tool could figure

I still have gsysupgrade lying around somewhere. It's a gtk app. I never
made a port for it because I got sidetracked rewriting it to use qt.

> out which sets are installed, and upgrade just those.
>
> Regards, Martin.
>

-- 
In my defence, I have been left unsupervised.

Re: Require host-name from DHCP clients

[Florian Obser]

On 2023-09-27 01:01 +02, Joel Carnat  wrote:
> Hi,
>
> Because of Apple Private Address feature, my static IP allocations based
> on MAC address (hardware ethernet) doesn't work anymore. Looking at
> dhcpd.leases, some devices provide a client-hostname value ; but not
> every one.
>
> Is there a dhcpd.conf configuration parameter that forces DHCP clients
> to send a client-hostname information in their DHCP request?

My understanding of the dhcp protocol is that this can't work. The
client sends a bunch of things and requests a bunch of stuff. The server
can honour that request or decline it. But it can't say: I'd give you a
lease if you'd give me a hostname.

The server can decline to give a lease without a hostname in the
request, but then the client would be left guessing why it didn't get a
lease.

>
> And if so, can this information be used by dhcpd(8) to apply a
> fixed-address to those device?
>
> Thank you,
> Joel C.
>

-- 
In my defence, I have been left unsupervised.

Re: How Do I Get The OpenBSD Install Procedure To Stop Trashing My Bootloader?

[Florian Obser]

On 2023-07-13 13:53 -05, "Jay F. Shachter"  wrote:
> (Parenthetically, when is OpenBSD going to support ZFS, and join the
> category of operating systems in which I can do serious work, i.e.,

What makes you think that's a goal for the people working on OpenBSD?

An actual, professional clown, who happens to use OpenBSD on their
laptop suggested: "So simple, even a clown can do it."

Now that's a goal I can get behind.

-- 
In my defence, I have been left unsupervised.

Re: unwind[92074]: bad packet: too large?

[Florian Obser]

On 2023-07-04 00:17 +03, Mark  wrote:
> Hi there.
>
> I'm getting this one in daemon/messages log files:
>
> Jul  3 20:52:53 unwind[92074]: bad packet: too large: 65552 -
> 1.0.0.127.bl.blocklist.de. IN A
> Jul  3 20:52:53 last message repeated 4 times
>
> What does that mean?

The nameservers for blocklist.de could not be reached.

>
> This is my mail server and Rspamd running behind, should I worry about
> unwind's message above?

No, this has been fixed in -current. It was an issue with error
reporting. Unwind works correctly in this case.

>
> Best.

-- 
In my defence, I have been left unsupervised.

Re: DHCP and apm suspend/resume

[Florian Obser]

On 2023-05-17 18:02 UTC, l...@fuji.kuistio.me wrote:
> Hi
>
> I have a desktop machine I recently installed OpenBSD 7.3 on. Everything 
> seems to be working fine except that it doesn't obtain a DHCP lease when 
> waking up from suspend. I haven't found any docs saying if it even should 
> do this. However, I also have a laptop running 7.3 and it does automatically 
> connect to a network when waking up from suspend. So I'm a bit confused 
> about why this works on the laptop but not on the desktop.
>
> On both machines I have created a hostname.if file under /etc. The desktop 
> machine does obtain a dhcp lease after the system has booted up, but it 
> doesn't do this after waking up from suspend as explained earlier. The 
> laptop is using wifi and the desktop is using a usb-ethernet adapter.

The USB Ethernet adapter gets disconnected from the USB bus on suspend
and re-discovered on resume. ifconfig will show that it does not have
the autoconf flag set nor does it have any IPv4 addresses configured.

Effectively it becomes a new device on resume.

I'm not aware of any way to fix / work around this. Calling netstart(8)
from apm probably races against the kernel and the USB adapter might not
be there yet when it runs.

>
> Is this kind of behaviour expected? It's not a huge issue, since suspending 
> the desktop machine is not that necessary. I'm just quite puzzled because 
> these two machines behave differently even though the configuration should 
> be almost identical. I tried to resolve the issue by creating a script in 
> /etc/apm/resume that should run /etc/netstart, but for whatever reason this 
> script does not seem to run at all when the machine wakes up.
>
> I'm new to using OpenBSD as a desktop. I've used it a 
> little bit on a headless server before, but I recently decided to start using 
> it 
> as a desktop out of interest. Everything else seems to be working as 
> expected.
>

-- 
In my defence, I have been left unsupervised.

Re: dhcpleased losing route

[Florian Obser]

On 2023-05-11 08:08 +10, David Diggles  wrote:
> On Thu, May 11, 2023 at 07:27:22AM +1000, Jonathan Matthew wrote:
>> 
>> This looks like the thing I ran into a while ago where I had an overly
>> broad nat-to rule for outgoing traffic that applied to traffic from the
>> host as well as the networks behind it.  This meant dhcpleased's unicast
>> packets appeared to come from a high port, so my provider's dhcp server
>> rejected them.  It looks like David is actually using the same provider
>> as me.
>> 
>> If there's a pf rule like 'match out on $iface nat-to ($iface)', making
>> that only apply to traffic received on another interface will probably
>> help.
>
> The nat rule I have 
>
> match out on egress nat-to (egress)
>

Yes, pretty sure this is causing your issue, like Jonathan was
describing.

-- 
In my defence, I have been left unsupervised.

Re: dhcpleased losing route

[Florian Obser]

( this is a good dhcp state diagram to follow along at home: 
https://commons.wikimedia.org/wiki/File:DHCP_Client_State_Diagram_-_en.png )

On 2023-05-10 23:07 +10, David Diggles  wrote:
> I probably should have done numeric tcpdump output. Here's both again.
>
> tcpdump: WARNING: snaplen raised from 116 to 1500
> 22:36:40.276682 0.0.0.0.68 > 255.255.255.255.67: xid:0x74253f08 vend-rfc1048 
> DHCP:REQUEST HN:"sarah" CID:1.220.159.219.40.20.191 
> PR:SM+DG+NS+HN+DN+BR+119+121 RQ:202.63.67.36 [tos 0x10]

dhcpleased starts up and we have a lease file in /var/db/dhcpleased/, we
are in INIT-REBOOT and ask the dhcp server via broadcast if we can use
our previous IP address 202.63.67.36. We go to state REBOOTING.

> 22:36:40.327371 202.63.66.1.67 > 255.255.255.255.68: xid:0x74253f08 
> flags:0x8000 Y:202.63.67.36 S:172.21.116.42 ether dc:9f:db:28:14:bf 
> vend-rfc1048 DHCP:ACK SM:255.255.254.0 DG:202.63.66.1 
> NS:119.40.106.35,119.40.106.36 NTP:125.253.59.254 LT:600 SID:202.63.66.1 
> CID:1.220.159.219.40.20.191 [tos 0xc0]

dhcp server: yeah, that's fine (DHCP:ACK). Lifetime is 600 seconds. We
configure the interface and go into state BOUND.

some time passes

> 22:41:40.422661 202.63.67.36.56480 > 202.63.66.1.67: (request) xid:0xa180ce6b 
> C:202.63.67.36 vend-rfc1048 DHCP:REQUEST HN:"sarah" 
> CID:1.220.159.219.40.20.191 PR:SM+DG+NS+HN+DN+BR+119+121

Time T1 expires, we send a unicast DHCPREQUEST to the dhcpserver: is it
OK to hold on to our IP address? We go into state RENEWING.

> 22:41:40.434534 202.63.66.1.67 > 202.63.67.36.68:  xid:0xa180ce6b 
> C:202.63.67.36 S:172.21.116.42 vend-rfc1048 DHCP:NACK SID:202.63.66.1 
> CID:1.220.159.219.40.20.191 [tos 0xc0]

dhcp server: Absolutely not! DHCP:NACK.

RFC 2131 has this:

  If the client receives a DHCPNAK message, it cannot reuse its
  remembered network address.  It must instead request a new
  address by restarting the configuration process, this time
  using the (non-abbreviated) procedure described in section
  3.1.  This action also corresponds to the client moving to
  the INIT state in the DHCP state diagram.

There is not a lot of wiggle room, we MUST remove our address. We go to
state INIT.

> 22:41:40.442012 0.0.0.0.68 > 255.255.255.255.67:  xid:0x6a13ec33 vend-rfc1048 
> DHCP:DISCOVER HN:"sarah" CID:1.220.159.219.40.20.191 
> PR:SM+DG+NS+HN+DN+BR+119+121 [tos 0x10]

dhcpleased, broadcast: could I please have a lease? go to state SELECTING

> 22:41:41.532272 0.0.0.0.68 > 255.255.255.255.67:  xid:0x6a13ec33 vend-rfc1048 
> DHCP:DISCOVER HN:"sarah" CID:1.220.159.219.40.20.191 
> PR:SM+DG+NS+HN+DN+BR+119+121 [tos 0x10]

dhcpleased, broadcast: could I please have a lease? pretty please? with
sugar on top? stay in state SELECTING

> 22:41:41.653804 202.63.66.1.67 > 255.255.255.255.68: xid:0x6a13ec33 
> flags:0x8000 Y:202.63.67.36 S:172.21.116.42 ether dc:9f:db:28:14:bf 
> vend-rfc1048 DHCP:OFFER SM:255.255.254.0 DG:202.63.66.1 
> NS:119.40.106.35,119.40.106.36 NTP:125.253.59.254 LT:600 SID:202.63.66.1 
> CID:1.220.159.219.40.20.191 [tos 0xc0]

server: ok fine, do you like this one?

> 22:41:41.658881 0.0.0.0.68 > 255.255.255.255.67: xid:0xdafa3da4 vend-rfc1048 
> DHCP:REQUEST HN:"sarah" CID:1.220.159.219.40.20.191 
> PR:SM+DG+NS+HN+DN+BR+119+121 RQ:202.63.67.36 SID:202.63.66.1 [tos 0x10]

dhcpleased: looks, good, is it ok if I use this one? go to state REQUESTING

> 22:41:42.414218 202.63.66.1.67 > 255.255.255.255.68: xid:0xdafa3da4 
> flags:0x8000 Y:202.63.67.36 S:172.21.116.42 ether dc:9f:db:28:14:bf 
> vend-rfc1048 DHCP:ACK SM:255.255.254.0 DG:202.63.66.1 
> NS:119.40.106.35,119.40.106.36 NTP:125.253.59.254 LT:600 SID:202.63.66.1 
> CID:1.220.159.219.40.20.191 [tos 0xc0]

dhcp server: yes, that's fine.
dhcpleased: configure address, go to state BOUND.

This process repeats every 5 minutes.

To me it looks like the server just NACKS all unicast requests. As far
as I remember our broadcast DHCPREQUESTs are exactly the same as our
unicast DHCPREQUESTs, so it's not the contents of the packet.

You were saying this works with other implementations? I would be
interested in seeing a tcpdump for those.

> 22:46:42.512451 202.63.67.36.63976 > 202.63.66.1.67: (request) xid:0x953f83f1 
> C:202.63.67.36 vend-rfc1048 DHCP:REQUEST HN:"sarah" 
> CID:1.220.159.219.40.20.191 PR:SM+DG+NS+HN+DN+BR+119+121
> 22:46:42.525222 202.63.66.1.67 > 202.63.67.36.68:  xid:0x953f83f1 
> C:202.63.67.36 S:172.21.116.42 vend-rfc1048 DHCP:NACK SID:202.63.66.1 
> CID:1.220.159.219.40.20.191 [tos 0xc0]
> 22:46:42.531574 0.0.0.0.68 > 255.255.255.255.67:  xid:0x66009a6e vend-rfc1048 
> DHCP:DISCOVER HN:"sarah" CID:1.220.159.219.40.20.191 
> PR:SM+DG+NS+HN+DN+BR+119+121 [tos 0x10]
> 22:46:43.622162 0.0.0.0.68 > 255.255.255.255.67:  xid:0x66009a6e vend-rfc1048 
> DHCP:DISCOVER HN:"sarah" CID:1.220.159.219.40.20.191 
> PR:SM+DG+NS+HN+DN+BR+119+121 [tos 0x10]
> 22:46:43.762685 202.63.66.1.67 > 255.255.255.255.68: xid:0x66009a6e
> flags:0x8000 Y:202.63.67.36 

Re: pflow(4) and ipv6 flows

[Florian Obser]

On 2023-02-21 14:24 +02, Kapetanakis Giannis  wrote:
> Yes I'm using default netflow version 5.
>
> is IPFIX better in general or the only one that supports ipv6?

Yes, version 5 is not specified for IPv6 flows, only IPFIX can export
IPv6 flows.

>
> thanks
>
> G

-- 
In my defence, I have been left unsupervised.

Re: pflow(4) and ipv6 flows

[Florian Obser]

Yes,

wild guess, you are running with pflowproto 5. It probably works better
with pflowproto 10.

On 2023-02-21 13:12 +02, Kapetanakis Giannis  wrote:
> Hi,
>
> Does pflow(4) support export of ipv6 flows?
>
> I see none recorded.
>
> Thanks,
>
> G
>

-- 
In my defence, I have been left unsupervised.

Re: Possible off-by-one bug in usr.sbin/rad/engine.c

[Florian Obser]

On 2022-12-31 23:54 +01, Ingo Schwarze  wrote:
> Hi Alejandro,
>
> Alejandro Colomar wrote on Sat, Dec 31, 2022 at 05:56:27PM +0100:
>
>> I've started auditing the OpenBSD source code after the discussion on 
>> arc4random_uniform(3) and my suggestion of arc4random_range() on the glibc 
>> mailing list.
>> 
>> I found some cases where it seems like there's an off-by-one bug, which
>> would be solved by providing arc4random_range().  I'll show here one,
>> to confirm that it's a bug, and if you confirm it, I'll continue fixing
>> similar bugs around the OpenBSD tree.
>> 
>> Here's the first one I found, which I hope is fixed by my patch:
>> 
>> 
>> diff --git a/usr.sbin/rad/engine.c b/usr.sbin/rad/engine.c
>> index ceb11d574e3..a61ea3835a6 100644
>> --- a/usr.sbin/rad/engine.c
>> +++ b/usr.sbin/rad/engine.c
>> @@ -641,8 +641,7 @@ iface_timeout(int fd, short events, void *arg)
>>  struct imsg_send_ra  send_ra;
>>  struct timeval   tv;
>> 
>> -   tv.tv_sec = MIN_RTR_ADV_INTERVAL +
>> -   arc4random_uniform(MAX_RTR_ADV_INTERVAL - MIN_RTR_ADV_INTERVAL);
>> +   tv.tv_sec = arc4random_range(MIN_RTR_ADV_INTERVAL, 
>> MAX_RTR_ADV_INTERVAL);
>>  tv.tv_usec = arc4random_uniform(100);
>
> Currently, the code puts a number in the range [200, 600) in tv_sec
> and a random number of microseconds into tv_usec,
> i.e. the timeout will be greater than or equal to 200 seconds
> and strictly less than 600 seconds with a uniform distribution.
>
> Isn't that exactly what is intended?
>
>>  log_debug("%s new timeout in %lld", __func__, tv.tv_sec);
>> 
>> 
>> If I'm correct, it should have been 'min + (max - min + 1)' instead
>> of 'min + (max - min)'.  Please confirm.
>
> With your change, the timeout could go up to 600.99, i.e. almost 601
> seconds.  I don't know the protocol and can't say whether the change
> would matter, but naively, exceeding the MAX_ feels surprising to me.
>
> Really, this doesn't look like a bug to me...

Unfortunately the OP did not explain why they think this is a bug.

>
> Yours,
>   Ingo

-- 
I'm not entirely sure you are real.

Re: dhclient -d run0

[Florian Obser]

On 2022-12-21 15:04 UTC, Rodrigo Readi  wrote:
> Too much innovations, too much daemons ... :)

Things kinda went downhill after CSRG disbanded.

Re: smtpd.comf: '... reject "message"' fails

[Florian Obser]

On 2022-10-20 21:38 -07, "Lyndon Nerenberg (VE7TFX/VE6BBM)"  
wrote:
> My reading of smtpd.conf says that any reject action should be able
> to take a message parameter. Yet the following line is rejected
> with a syntax error message:
>
>   match mail-from rdns regex "\.t-online\.de$" reject "550 5.7.1 you don't 
> accept our mail, so we don't accept yours."
>
> Yet the same line without the string after the reject keyword works.
>
> I spent some time digging in the grammar, but yacc just gives
> me migraines.  Should this in fact work?  Or is the manpage
> wrong.

There are two kinds of matches, you are using this:

 match options reject
 Reject the incoming message during the SMTP dialogue.  The same
 options are supported as for the match action directive.


You need this one:

 filter filter-name phase phase-name match conditions decision
 Register a filter filter-name.  A decision about what to do with
 the mail is taken at phase phase-name when matching conditions.
 Phases, matching conditions, and decisions are described in MAIL
 FILTERING, below.

i.e.

filter dtag phase mail-from match rdns regex "\.t-online\.de$" reject "550 
5.7.1 you don't accept our mail, so we don't accept yours."
listen on egress filter dtag

No, I don't know why things are the way they are.

>
> --lyndon
>

-- 
I'm not entirely sure you are real.

Re: Supposed way to have a login without password but still able to login via ssh?

[Florian Obser]

Set the password hash to 13 * using vipw(8) or usermod -p.

I wonder if we document that somewhere.

On 26 September 2022 20:27:07 CEST, Federico Giannici  
wrote:
>I have a login that I want to be able to access only via ssh with a 
>certificate (in ~/.ssh/authorized_keys).
>
>
>So I have disabled the password ('*') but left a valid shell. Something like 
>this in /etc/master.passwd:
>
>mylogin:*:1001:1001::0:0:My login:/home/mylogin:/bin/sh
>
>
>But in this way every day a receive a mail with the following:
>
>Checking the /etc/master.passwd file:
>Login mylogin is off but still has a valid shell and alternate access files in 
>home directory are still readable.
>
>
>What is the supposed way to define an account without a password but with a 
>valid shell (to access via ssh with a certificate)?
>
>Thanks.
>

-- 
Sent from a mobile device. Please excuse poor formatting.

Re: Changing sysctl hw.sensors names on a T410

[Florian Obser]

On 2022-09-07 15:09 UTC, Stuart Henderson  wrote:
> On 2022-09-07, Lévai  Dániel  wrote:
>> Doesn't hurt anything really, was just wondering if anyone has seen this and 
>> maybe have a tech tale of an explanation for it.
>
> Does it depend on cold/warm boot, or whether it's on battery or plugged in?
>

I think it was my x201 were it would depend on battery or plugged in
during boot.

-- 
I'm not entirely sure you are real.

Re: dhcpleased and ifstated

[Florian Obser]

On 2022-07-13 17:23 -06, "Theo de Raadt"  wrote:
> Christer Solskogen  wrote:
>
>> This happens every time with dhcpleased and my ISP and it didn't with
>> dhclient, and what I do see now, that I didn't see with dhclient,
>> is that during the negotiation ifconfig says that the interface has
>> "status: no carrier" for 2-3 seconds. Which explains why I don't get a
>> DHCPACK within 1 second.
>
> Is this specific to a particular network driver?
>
> I am suggesting some drivers may have shitty / sloppy coming-up behaviour.
> Or, that dhcpleased is going to need to be more forgiving.  Or maybe
> as a

both dhcpleased and dhclient start working when LINK_STATE_IS_UP is true
(defined in net/if.h). I actually got this wrong at first and then
checked what dhclient is doing. So if it takes 2-3 seconds for the link
to come up it will take 2-3 seconds to get a lease, nothing we can do
about that.

> result of the timeout policy it practices, it works different than dhclient
> did, and maybe that is not surprising?
>

Now, if the driver reports the link is up but it doesn't pass any traffic we
hit a different timeout behaviour. IIRC dhclient sends the first 10
packets with a timeout of 1 second.
I considered that a bit anti-social on wifi where we have seen dhcp
servers taking a few seconds to respond. There is no need to blast the
network. dhcpleased does an exponetial backoff, i.e. timeout of 1, 2, 4,
8... seconds.

-- 
I'm not entirely sure you are real.

Re: dhcpleased and ifstated

[Florian Obser]

On 2022-07-06 21:05 +02, Christer Solskogen  
wrote:
> On Wed, Jul 6, 2022 at 4:47 PM Florian Obser  wrote:
>
>>
>> Are you comparing the same thing? I.e. did dhcpleased get a lease before
>> and does /var/db/dhcpleased/$IF exist?
>>
>
> Both nodes have /var/db/dhcpleased/$IF. If I reboot both firewalls only the
> master have gotten the lease, until I do a switch over.
> During a switchover I get this with debug on:
>
> tugs# dhcpleased -d -v -v
> changed iface: re2[3]
> state_transition[re2] Down -> Down, timo: -1
>
> (when doing the switchover)
>
> state_transition[re2] Down -> Down, timo: -1
> state_transition[re2] Down -> Rebooting, timo: 1

interface coming up, setting timeout to 1 second

> DHCPREQUEST on re2

we are sending DHCPREQUEST

> iface_timeout[3]: Rebooting

we did not get a DHCPACK within 1 second

> state_transition[re2] Rebooting -> Rebooting, timo: 2

setting timeout to 2 seconds

> DHCPREQUEST on re2

send another DHCPREQUEST

Note that we are sending the DHCPREQUEST immediately and then wait at
most 2 seconds.

> parse_dhcp, from: 00:02:00:01:00:01, to: ff:ff:ff:ff:ff:ff
> parse_dhcp: 79.160.116.238:67 -> 255.255.255.255:68
> 

we probably get a DHCPACK.

>
> It looks to me that it's rebooting twice?

yes, because it didn't get a DHCPACK for the first DHCPREQUEST. Maybe
the DHCP server was busy. I'm seeing this with my ISP's CPE once in a
while, too.

>
> What's the correct way of doing this with ifstated? run "ifconfig $IF down"
> or "ifconfig $IF delete"?

I have no idea, I've never used ifstated.

-- 
I'm not entirely sure you are real.

Re: dhcpleased and ifstated

[Florian Obser]

On 2022-07-06 10:09 +02, Christer Solskogen  
wrote:
> On Tue, Jul 5, 2022 at 9:56 PM Christer Solskogen <
> christer.solsko...@gmail.com> wrote:
>
>> Now that dhclient is soon to be gone, I wanted to switch to dhcpleased.
>> But I do have a hard time understanding how I can get that to work together
>> with CARP and ifstated.
>> With dhclient, as soon as the master boots, the backup takes over and get
>> an ip address in an instant from my ISP, but dhcpleased does not. It don't
>> even get an ipaddress unless I run "dhcpleasectl -w 1 "
>> (dhcpleased runs in the background)
>>
>>
> Okay, I've obviously thought of dhcpleased wrong. Now dhcpleased works in
> the background all the time, and a simple "run ifconfig re0 up" instead of
> starting it in ifstated. But still, it takes 2-3 seconds to get a lease,
> while with dhclient it was instant.

Are you comparing the same thing? I.e. did dhcpleased get a lease before
and does /var/db/dhcpleased/$IF exist?
If it then tries to reaquire a lease it goes REBOOTING -> BOUND which
involves 2 packets, DHCPREQUEST and DHCPACK.
If you did not have a lease before you need to exchange 4 packets which
naturaly takes longer.  I have not found dhcpleased being faster or
slower than dhclient.

-- 
I'm not entirely sure you are real.

Re: smtpd: return tempfail if no valid fcrdns: good or bad?

[Florian Obser]

On 2022-06-24 10:16 +02, Alexandre Ratchov  wrote:
> I noticed that most of the spam that spamd(8) doesn't catch comes from
> machines with no valid FCrDNS and that all legitimate mails used valid
> FCrDNS.
>
> Certain [1] recommend to return 550 in case of invalid FCrDNS, but if
> I understand correctly, 550 is a permanent error. So this may block
> legitimate mails in case of temporary DNS lookup failures, which
> happens from time to time.
>
> So I'm tempted to use 421 instead of 550, as follows:
>
> filter check_rdns phase connect match !rdns \
> disconnect "421 DNS lookup failure, please try again later."
> filter check_fcrdns phase connect match !fcrdns \
> disconnect "421 No valid FCrDNS, please try again later."
>

This seems like a reasonable idea, I will probably implement that in a
week or two.

> A quick test shows that this discards a lot of the spam, but I'm not
> 100% sure about whether this could hurt legitimate mail, hence my
> question here.
>

The only thing I can think off is that legitimate mail where the sender
has misconfigured their DNS, they will be informed about this
later. Something, something mail delivery delayed by 4 hours, still
trying.

I looked at the code and assuming I found the right places it looks like
during lookup in smtp_getaddrinfo_cb() it distinguishes 3 DNS cases:
s->fcrdns =  0: reverse doesn't exist or doesn't match
s->fcrdns = -1: lookup failed, maybe because of timeout
s->fcrdns =  1: everything is good

but then in filter_check_fcrdns() this is reduced by
ret = fcrdns == 1
so we can't distinguish between 0 and -1.

I'd say it would be sensible to permfail for 0 and tempfail for -1.
I don't think this can be easily shoehorned into the filter framework?

> Am I missing something? Anyone is successfully using this approach?
>
> [1] 
> https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/
>

-- 
I'm not entirely sure you are real.

xidle(1) and autosuspend

[Florian Obser]

Since my other computer is a datacenter, and my laptop is just a
glorified vt100, I figured how to autosuspend it when it's idle for some
time.

I already at xidle(1) in my .xsession to start xlock(1). I then
discovered -startCmd in xlock(1).

I know have this:

$ cat xlock_zzz
#! /bin/sh

exec /usr/X11R6/bin/xlock -startCmd "/bin/sleep 300 && /usr/sbin/zzz"

and this in my .xsession:

xidle -program /home/florian/bin/xlock_zzz -timeout 300 &

So after 5 minutes xidle starts xlock and 5 minutes after that my laptop
autosuspends. If I unlock the laptop before 5 minutes expire the sleep
gets killed and the laptop doesn't suspend.

-- 
I'm not entirely sure you are real.

Re: Updating nextcloud to new major version

[Florian Obser]

On 2022-05-13 19:35 +02, Clemens Gößnitzer  wrote:
> When I try to update nextcloud to the next major version, it would not
> let me easily:
>
> # pkg_add -vi nextcloud
> Update candidates: quirks-5.5 -> quirks-5.5
> quirks-5.5 signed on 2022-05-12T23:37:02Z
> Ambiguous: choose package for nextcloud
> a   0: 
> 1: nextcloud-21.0.8p0
> 2: nextcloud-22.2.6
> 3: nextcloud-23.0.3
> Your choice: 3
> Can't install nextcloud-23.0.3 because of conflicts (nextcloud-22.2.6)
> --- nextcloud-23.0.3 ---
> Can't install nextcloud-23.0.3: conflicts
> Couldn't install nextcloud-23.0.3
>
>
> Is there a way to do this upgrade without pkg_delete nextcloud &&
> pkg_install nextcloud?

pkg_add -r nextcloud

worked for me.

>
> Thanks.
>

-- 
I'm not entirely sure you are real.

Re: HP T430 "Thin Client": Won't sysupgrade without HDMI monitor attached.

[Florian Obser]

On 2022-05-06 12:00 -04, Nick Holland  wrote:
> here's a weird one.
>
> HP T430 Thin Client, reloaded with OpenBSD.
> In it's intended use, it runs Linux in BIOS boot mode.  OpenBSD's
> installer will boot that way, but the kernel is unable to see the
> 16g storage device.  In UEFI boot mode, OpenBSD works well,
> including running X.  This machine has ONLY HDMI and DisplayPort
> video connections (one each).  There's no com port on the box for
> an alternative view of what is going on.
>
> The problem comes when I put them to work without a monitor.
>
> The machine will boot fine, run fine...but sysupgrade fails to upgrade
> the system.  It downloads the intended files, it reboots, and a few
> moments later, it's back up and running -- the old kernel. Plug an
> HDMI monitor in, run sysupgrade again, and it sees the upgrade marker
> and does the upgrade.  Textbook Heisenbug :-/
>
> For giggles, I did a sysupgrade -k (keep the files), let it reboot,
> in the root directory was bsd.upgrade as expected.  I copied

Not realy, -k keeps stuff in /home/_sysupgrade. bsd.upgrade gets deleted
by the installer.

My guess is bsd.rd panics when there is not monitor plugged in.
You could plug in a monitor to see why it panics, oh wait... :P

> bsd.upgrade to /bsd, forcing it one way or another to run
> bsd.upgrade ... and the result was a hung system.  Never came back
> after the reboot, no idea why.  When I moved it to be near an HDMI
> monitor, it promptly booted, complained about permissions on
> bsd.upgrade, but upgraded perfectly (but I am not sure which of
> the two copies of the kernel it used).
>
> What can I do to help provide info to determine what is going on
> here?

I can't debug this, but I can tell you a bit about the interaction
between sysupgrade(8), the bootloader and the installer in bsd.rd.

>From there you can figure out how for you got.

sysupgrade downloads the sets into /home/_sysupgrade and verifies them.
Then it creates /auto_upgrade.conf and installs /home/_sysupgrade/bsd.rd
as /bsd.upgrade. so bsd.upgrade is a bsd.rd, there is nothing special
about it. /bsd.upgrade is installed with mode 0700.
Then it execs reboot.

The bootloader checks if there is an executable(!) /bsd.upgrade
available, if so it does a chmod u-x /bsd.upgrade and boots it.
If not it consults /etc/boot.conf and boots /bsd or whatever
/etc/boot.conf says.

The installer then checks if this is an unattended upgrade by checking
if bsd.upgrade and auto_upgrade.conf are present. If so it runs an
unattended upgrade. Very early in that process, after checking the disks
and mounting all partitions, the installer delets bsd.upgrade and
auto_upgrade.conf.

So, if you end up with a /bsd.upgrade on the running system that is
still mode 0700, your bootloader is on the fritz.

If you have a /bsd.upgrade that's 0600 your bootloader found the kernel
and tried to boot it, but the installer didn't get very far.

If there is no /bsd.upgrade after a reboot and no email to root the
installer got rebooted by a watchdog process, otherwise you got an email
to root detailing the upgrade process.

-- 
I'm not entirely sure you are real.

Re: Modern RFC3442 (Classless DHCP Static Routes)

[Florian Obser]

On 2022-05-06 10:28 -04, Sonic  wrote:
> On Fri, May 6, 2022 at 7:18 AM Florian Obser  wrote:
>> Also, dhcpd(8) does not even hand out option 3 when option 121 is
>> configured.
>
> That doesn't seem like correct behavior (the ISC version certainly
> offers both). Both options should be sent if configured, it's up to
> the client to properly handle this.
> Clients that are rfc3442 compliant will install the option 121 routes,
> clients that are not rfc3442 compliant will ignore option 121 and
> install the gateway supplied by option 3. If dhcpd doesn't hand out
> option 3 when option 121 is configured then clients that are not
> rfc3442 compliant will not receive a gateway address.

>
I fully agree, I was very surprised when I discovered this
behaviour. But I haven't chased it down why this is.

-- 
I'm not entirely sure you are real.

Re: Modern RFC3442 (Classless DHCP Static Routes)

[Florian Obser]

On 2022-05-06 08:26 UTC, Stuart Henderson  wrote:
> On 2022-05-04, nace...@narwhals.org  wrote:
>> https://marc.info/?l=openbsd-tech=162652200109398=2 I disagree.
>> while its technically correct with the rfc, in practice, not many OSes 
>> rigidly enforces not using the router option when 121 is present that 
>> I've used.
>
> It's not just technically correct, handling this differently would be
> *in*correct, it is a MUST in the RFC.
>
>> This is how dhcpleased works in -current:
>> 1) if a client using dhcpleased gets an option 121 set of routes, it 
>> ignores the dhcp router option.
>
> right.
>
>> 2) dhcpleased enforces that it wont hand out a 0.0.0.0 destination route 
>> in option 121
>
> if this is the case, it's a problem, option 121 routes must be able to set
> 0.0.0.0/0. can you show your working for figuring this out as that might
> give a clue what's wrong? debug logs and packet captures might help.

It is not the case. This just works fine in dhcpleased(8).
Also, dhcpd(8) does not even hand out option 3 when option 121 is
configured.

(Also dhcpleased does not "hand out" anything. I assume the OP means
"configures a default route in the FIB.")

-- 
I'm not entirely sure you are real.

Re: Howto do "a detailed cleanup with the aid of the sysclean package"?

[Florian Obser]

On 2022-05-04 07:42 +02, Harald Dunkel  wrote:
> Hi folks,
>
> I think the main problem is pretty easy to describe: OpenBSD loses track
> about what it had installed and cannot clean up its own files on a system
> upgrade.

The general case is a hard problem and people who deemed this important
have not stepped up to implement the perfect solution that works for everybody.

>
>
> Regards
> Harri
>

-- 
I'm not entirely sure you are real.

Re: vlan autoconf fails to conf at boot

[Florian Obser]

On 2022-04-30 00:49 -04, Josh Grosse  wrote:
> On Fri, Apr 29, 2022 at 09:33:50PM -0700, George Morgan wrote:
>> I created a hostname.vlan10 file which has a single line:
>> 
>> inet autoconf parent vge0 vnetid 10 lladdr ...
>> 
>> At boot the interface fails to configure but after boot I can login to the 
>> console and run "doas sh /etc/netstart" and the interface will configure.
>> 
>> What am I doing wrong?  Do I need to add something to rc.conf.local to force 
>> the parent to configure first?  The parent (vge0) has a static IPv4 address.
>
> The vlan has to be created and assigned parentage before autoconfiguration.
> Craft your hostname.vlan10 file in two lines:
>
> vnetid 10 parent vge0 addrr ...
> inet autoconf
>
> This information brought to my attention via Reddit:
>
> https://www.reddit.com/r/openbsd/comments/ua0wqd/no_longer_able_to_connect_to_the_internet_after/i5z24fj/
>

The explanation on reddit is not quite correct though.
You are trying to configure a vlan interface before setting vlan
parameters, i.e:

# ifconfig vlan10 destroy
# ifconfig vlan10 inet 192.0.2.23/24
ifconfig: SIOCAIFADDR: Device not configured
# ifconfig vlan10 destroy
# ifconfig vlan10 inet autoconf
ifconfig: SIOCSIFXFLAGS: Device not configured

It has nothing to do with requesting a dhcp lease.

I think this kinda maybe worked previously but IIRC dlg shuffled some
code around and tightened the requirements. This has fewer surprises and
works correctly.

-- 
I'm not entirely sure you are real.

Re: Howto do "a detailed cleanup with the aid of the sysclean package"?

[Florian Obser]

On 2022-04-20 21:42 UTC, Stuart Henderson  wrote:
> On 2022-04-20, Florian Obser  wrote:
>> You will need a carefully curated /etc/sysclean.ignore file.
>>
>> You decided to put maildirs somewhere on the system, sysclean is not 
>> omniscient, you need to tell it to leave them alone. Same with .git 
>> directories.
>> I don't recall needing to tell it about package config files though, that's 
>> a bit weird.
>
> e.g. files which are added to /etc that aren't distributed in the package but
> you create yourself

Ah, yes. But it does understand directories, e.g. I have a lot of
changes in /etc/icinga2 but I don't need to ignore it. I guess that's
why I only need to ignore very little in /etc.

>
>> It's a bit daunting on first run if a lot of cruft has accumulated
>> over the years, but it gets better. I'm using it for years, and I
>> can't recall the last time I had to add anything to the ignore file.
>>
>> I run it from daily and also by hand after every upgrade to a snapshot.
>>
>> If it outputs a really long list I cleanup incrementally, for example:
>> sysclean | fgrep /usr
>
> For a first run I would review "| fgrep /usr/local" as that's the most likely
> place where files might exist that should not be cleaned, and it's
> easier to

tzk tzk, someone has been naughty and installed things without packages?
;)

I don't do that and I imagine if one installs compiled, dynamically
linked programs by hand sysclean's returns deminish really fast because
it won't understand that old libs are still needed.

It's an awesome tool that takles a hard problem and for me succeedes
with a bit of hand holding.

Btw. there is another school of thought that says old cruft doesn't need
to be removed, it's not causing any harm. If you need a clean system
just reinstall and restore config and data from backups. It's a good
excercise to check that your backups are working.

-- 
I'm not entirely sure you are real.

Re: Howto do "a detailed cleanup with the aid of the sysclean package"?

[Florian Obser]

You will need a carefully curated /etc/sysclean.ignore file.

You decided to put maildirs somewhere on the system, sysclean is not 
omniscient, you need to tell it to leave them alone. Same with .git directories.
I don't recall needing to tell it about package config files though, that's a 
bit weird.

It's a bit daunting on first run if a lot of cruft has accumulated over the 
years, but it gets better. I'm using it for years, and I can't recall the last 
time I had to add anything to the ignore file.

I run it from daily and also by hand after every upgrade to a snapshot.

If it outputs a really long list I cleanup incrementally, for example:
sysclean | fgrep /usr
There really shouldn't be a false positive there, so after review I run
sysclean | fgrep /usr | xargs rm -r
next up is /etc.
If there is more output afterwards something is either very weird or an 
intentional decision by me to store something in that location so it goes into 
the ignore file.


On 20 April 2022 20:39:09 CEST, Harald Dunkel  wrote:
>Hi folks,
>
>the upgrade guide claims
>
>   A detailed cleanup can be done with the aid of the sysclean package.
>
>sysclean lists 4180 files and directories on my home server, including mail
>directories, config files of various external packages, generated files, .git
>directories, etc. A lot of stuff I wouldn't like to lose. Apparently it also
>lists a lot of old crap, but since it lists *so many* important files I don't
>trust it at all.
>
>Could you please elaborate how sysclean is going to help me to keep my openbsd
>hosts clean? How is the usage model of this tool?
>
>
>Thank you very much in advance
>Harri
>

-- 
Sent from a mobile device. Please excuse poor formatting.

Re: Unwind in rdomain1 returning NXDOMAIN for local queries

[Florian Obser]

On 2022-03-25 20:07 UTC, Stuart Henderson  wrote:
> (I found unwind more trouble than it's worth with rdomains though,
> I killed resolvd and hardcoded a public resolver in resolv.conf
> instead..)

Do we need something simpler for some rdomain setups? A daemon listening
on 127.0.0.1 and only forwarding to a fixed server? I.e. bring back
rebound for this?

-- 
I'm not entirely sure you are real.

Re: Unwind in rdomain1 returning NXDOMAIN for local queries

[Florian Obser]

On 2022-03-25 11:41 +01, Francisco Gaitan  
wrote:
> I have setup a WireGuard VPN so I run two instances of unwind, one for
> rdomain 0 (unwind) and another for rdomain 1 (unwind1) this way:
> lrwxr-xr-x  1 root  wheel16 Mar 23 13:44 unwind1 -> /etc/rc.d/unwind
>
> $ cat /etc/rc.conf.local
> unwind1_flags=-vvv -f /etc/unwind1.conf
> unwind1_rtable=1
>
> After some time and without any output to /var/log/daemon, unwind1 just
> stops replying to queries for the local network until I restart, then it
> works again during some time. 
>
> This happens since days ago where I did this setup.
>
> $ cat /etc/resolv.conf
> nameserver 127.0.0.1 # resolvd: unwind
> search home.arpa
> lookup file bind
>
> $ cat /etc/unwind1.conf
> forwarder 192.168.10.1

Add

preference { forwarder }

to unwind1.conf so that unwind1 only talks to the forwarder.

That will probably fix it.

>
> $ route -T 1 exec dig @127.0.0.1 iron.home.arpa
>
> ; <<>> dig 9.10.8-P1 <<>> @127.0.0.1 iron.home.arpa
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31081
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;iron.home.arpa.IN  A
>
> ;; AUTHORITY SECTION:
> home.arpa.  3600IN  SOA localhost.
> nobody.invalid. 1 3600 1200 604800 10800
>
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Fri Mar 25 11:25:43 CET 2022
> ;; MSG SIZE  rcvd: 91
>
> $ route -T 1 exec dig @127.0.0.1 +short iron.home.arpa
> $ route -T 1 exec dig @192.168.10.1 +short iron.home.arpa
> 192.168.10.10
> $ route -T 1 exec dig +short example.com
> 93.184.216.34
>
> $ doas rcctl restart unwind1
> unwind1(ok)
> unwind1(ok)
>
> $ route -T 1 exec dig @127.0.0.1 +short iron.home.arpa
> 192.168.10.10
> $ route -T 1 exec dig @192.168.10.1 +short iron.home.arpa
> 192.168.10.10
>
> $ ifconfig lo1
> lo1: flags=8049 rdomain 1 mtu 32768
> description: rdomain 1 loopback address
> index 5 priority 0 llprio 3
> groups: lo
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo1 prefixlen 64 scopeid 0x5
> inet 127.0.0.1 netmask 0xff00
>
> $ route -T 1 exec netstat -lnf inet
> Active Internet connections (only servers)
> Proto   Recv-Q Send-Q  Local Address  Foreign Address
> TCP-State
> tcp  0  0  127.0.0.1.53   *.*
> LISTEN
> Active Internet connections (only servers)
> Proto   Recv-Q Send-Q  Local Address  Foreign Address
> udp  0  0  192.168.10.10.68   *.*
> udp  0  0  127.0.0.1.53   *.*
> udp  0  0  *.17233*.*
>
>

-- 
I'm not entirely sure you are real.

Re: Raspberry Pi 4B sysupgraded to GENERIC (not MP)

[Florian Obser]

This thread on bugs@ probably has the information to get you started: 
https://marc.info/?t=16429322751=1=2

On 27 January 2022 20:39:11 CET, Jan Stary  wrote:
>This is current/arm64 on a Raspberry Pi 4B, dmesg below.
>A sysupgrade -sf has installed GENERIC (not GENERIC.MP) as /bsd.
>How can I debug this? Can some one please point to the place
>where the sp/mp decision is made?
>
>   Jan
>
>
>OpenBSD 7.0-current (GENERIC) #1458: Tue Jan 25 11:33:09 MST 2022
>dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC
>real mem  = 8419872768 (8029MB)
>avail mem = 8128622592 (7752MB)
>random: good seed from bootblocks
>mainbus0 at root: Raspberry Pi 4 Model B Rev 1.4
>cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3
>cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
>cpu0: 1024KB 64b/line 16-way L2 cache
>cpu0: CRC32,ASID16
>apm0 at mainbus0
>efi0 at mainbus0: UEFI 2.8
>efi0: Das U-Boot rev 0x20211000
>"system" at mainbus0 not configured
>"axi" at mainbus0 not configured
>simplebus0 at mainbus0: "soc"
>bcmclock0 at simplebus0
>bcmmbox0 at simplebus0
>bcmgpio0 at simplebus0
>bcmaux0 at simplebus0
>ampintc0 at simplebus0 nirq 256, ncpu 4: "interrupt-controller"
>bcmtmon0 at simplebus0
>bcmdmac0 at simplebus0: DMA0 DMA2 DMA4 DMA5 DMA6 DMA7 DMA8 DMA9
>"timer" at simplebus0 not configured
>pluart0 at simplebus0: console
>"local_intc" at simplebus0 not configured
>bcmdog0 at simplebus0
>bcmirng0 at simplebus0
>"firmware" at simplebus0 not configured
>"power" at simplebus0 not configured
>"mailbox" at simplebus0 not configured
>sdhc0 at simplebus0
>sdhc0: SDHC 3.0, 250 MHz base clock
>sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed
>"gpiomem" at simplebus0 not configured
>"fb" at simplebus0 not configured
>"vcsm" at simplebus0 not configured
>"clocks" at mainbus0 not configured
>"phy" at mainbus0 not configured
>"clk-27M" at mainbus0 not configured
>"clk-108M" at mainbus0 not configured
>simplebus1 at mainbus0: "emmc2bus"
>sdhc1 at simplebus1
>sdhc1: SDHC 3.0, 100 MHz base clock
>sdmmc1 at sdhc1: 8-bit, sd high-speed, mmc high-speed, ddr52, dma
>"arm-pmu" at mainbus0 not configured
>agtimer0 at mainbus0: 54000 kHz
>simplebus2 at mainbus0: "scb"
>bcmpcie0 at simplebus2
>pci0 at bcmpcie0
>ppb0 at pci0 dev 0 function 0 "Broadcom BCM2711" rev 0x10
>pci1 at ppb0 bus 1
>xhci0 at pci1 dev 0 function 0 "VIA VL805 xHCI" rev 0x01: intx, xHCI 1.0
>usb0 at xhci0: USB revision 3.0
>uhub0 at usb0 configuration 1 interface 0 "VIA xHCI root hub" rev 3.00/1.00 
>addr 1
>bse0 at simplebus2: address dc:a6:32:e0:50:d3
>brgphy0 at bse0 phy 1: BCM54210E 10/100/1000baseT PHY, rev. 2
>"dma" at simplebus2 not configured
>"hevc-decoder" at simplebus2 not configured
>"rpivid-local-intc" at simplebus2 not configured
>"h264-decoder" at simplebus2 not configured
>"vp9-decoder" at simplebus2 not configured
>gpioleds0 at mainbus0: "led0", "led1"
>"sd_io_1v8_reg" at mainbus0 not configured
>"sd_vcc_reg" at mainbus0 not configured
>"fixedregulator_3v3" at mainbus0 not configured
>"fixedregulator_5v0" at mainbus0 not configured
>simplebus3 at mainbus0: "v3dbus"
>"bootloader" at mainbus0 not configured
>scsibus0 at sdmmc1: 2 targets, initiator 0
>sd0 at scsibus0 targ 1 lun 0:  removable
>sd0: 30436MB, 512 bytes/sector, 62333952 sectors
>uhub1 at uhub0 port 1 configuration 1 interface 0 "VIA Labs USB2.0 Hub" rev 
>2.10/4.21 addr 2
>bwfm0 at sdmmc0 function 1
>manufacturer 0x02d0, product 0xa9a6 at sdmmc0 function 2 not configured
>manufacturer 0x02d0, product 0xa9a6 at sdmmc0 function 3 not configured
>vscsi0 at root
>scsibus1 at vscsi0: 256 targets
>softraid0 at root
>scsibus2 at softraid0: 256 targets
>root on sd0a (d1a7e0233ab9545d.a) swap on sd0b dump on sd0b
>WARNING: CHECK AND RESET THE DATE!
>gpio0 at bcmgpio0: 58 pins
>bwfm0: address dc:a6:32:e0:50:d4
>

-- 
Sent from a mobile device. Please excuse poor formatting.

Re: route advertisement question

[Florian Obser]

On 2021-12-26 19:43 UTC, mgra...@brainfat.net wrote:
> So my question is, is this expected behavior?  When the router advertisement 
> does not have a router and
> thus sets the router lifetime to 0 (as it should), should slaacd ignore 
> advertisement?  Or should
> it still configure an IP address?

It should still form an autoconf address, this is a bug in slaacd.

This should fix it. The diff only removes if (ra->router_lifetime != 0)

diff --git engine.c engine.c
index 81a06cc5528..7a2c11e1bc2 100644
--- engine.c
+++ engine.c
@@ -1749,14 +1749,13 @@ void update_iface_ra(struct slaacd_iface *iface, struct 
radv *ra)
 
update_iface_ra_dfr(iface, ra);
 
-   if (ra->router_lifetime != 0)
-   LIST_FOREACH(prefix, >prefixes, entries) {
-   if (!prefix->autonomous || prefix->vltime == 0 ||
-   prefix->pltime > prefix->vltime ||
-   IN6_IS_ADDR_LINKLOCAL(>prefix))
-   continue;
-   update_iface_ra_prefix(iface, ra, prefix);
-   }
+   LIST_FOREACH(prefix, >prefixes, entries) {
+   if (!prefix->autonomous || prefix->vltime == 0 ||
+   prefix->pltime > prefix->vltime ||
+   IN6_IS_ADDR_LINKLOCAL(>prefix))
+   continue;
+   update_iface_ra_prefix(iface, ra, prefix);
+   }
 
update_iface_ra_rdns(iface, ra);
 }


-- 
I'm not entirely sure you are real.

Re: Unwind does not seem to query forwarders it is pointed to

[Florian Obser]

On 2021-12-06 13:49 +03, Maksim Rodin  wrote:
> Hello
> I have the following unwind.conf:
> ```
> cat /etc/unwind.conf
> fwd1=192.168.1.150
> fwd2=192.168.1.1
> forwarder { $fwd1 $fwd2 }
> preference forwarder
> ```
> and an automatically generated resolv.conf:
> ```
> cat /etc/resolv.conf
> nameserver 127.0.0.1 # resolvd: unwind
> lookup file bind
> ```
> I may not understand the purpose of unwind correctly but I expect the
> unwind to respond to DNS queries using the forwarders it is pointed to
> in its config.

That is one purpose, and you configured it do exactly that.

> But when I do:
> ```
> nslookup dc.mydomain.ru
> ```
> It says:
> ```
> Server: 127.0.0.1
> Address:127.0.0.1#53
>
> ** server can't find dc.mydomain.ru: SERVFAIL
> ```
>
> And I see in the logs the following:
> ```
> unwind[8550]: validation failure : no signatures from 
> 192.168.1.150 for DS ru. while building chain of trust
> ```
> The DNS server on 192.168.1.150 definitely knows about the host
> dc.mydomain.ru
>
> When I ask that DNS server directly:
> ```
> nslookup dc.mydomain.ru 192.168.1.150
> ```
> It returns the correct answer
>
> So the unwind daemon seems to always query root name servers instead of my two
> servers.
> Is that the expected behavior?

It does not do that. I talks to your two servers. But it tries to do
DNSSEC validation: "no signatures from 192.168.1.150 for DS ru."

So something is odd. When unwind starts or learns about new resolvers it
checks if they can do DNSSEC validation. It the equivalent of this:

dig @192.168.1.150 +dnssec . NS
and
dig @192.168.1.1 +dnssec . NS

and got a response it liked.

$ unwindctl status

probably outputs something like

1. forwardervalidating

So it knows the root zone is signed and your forwarders hand out DNSSEC
information, but for some reason your forwarders do not answer to

dig @192.168.1.150 +dnssec ru DS

No idea why.

>
> -- 
> Maksim Rodin
>

-- 
I'm not entirely sure you are real.

Re: Upgrade to 7.0

[Florian Obser]

Here we go again...

On 23 November 2021 21:00:18 CET, "pas...@pascallen.nl"  
wrote:
>I'm trying to upgrade to 7.0 but it fails.
>The upgrade quide shows: 
>   Check available disk space in /usr. Verify that the /usr partition
>   has a size of at least 1.1G. With less space the upgrade may fail
>   and you should consider reinstalling the system instead.
>
>Well theres space. But _sysupgrade folder is DL in /home. And /home is
>encrypted. Gets mounted after I give the password.
>When I don't have sysupgrade dl in the mounted /home/_sysupgrade. It
>goes in the folder /home on /
>Which doesn't have 1.1G spare.
>
>Does sysupgrade have a config file where the dl location is specified?

No. Just copy sysupgrade to ~/bin and edit it. It's a stupidly simple shell 
script. The magic is in the bootblocks and install.sub inside of bsd.rd.

>Has this changed since 6.9? I'm baffled.

No. Has always been like this.

-- 
Sent from a mobile device. Please excuse poor formatting.

Re: dhcpleased(8) not renewing leases

[Florian Obser]

On 2021-11-03 11:41 -06, Zack Newman  wrote:
> dhcpleased(8) is unable to renew DHCP leases from my ISP,
> Xfinity/Comcast. This in turn is causing leases to expire leading to
> IPv4 drops that last between 15 and 20 seconds until a new lease can be
> binded. Note that lease binding does succeed.
>
> For about a month before the release of OpenBSD 7.0, I had been using
> dhcpleased(8) instead of dhclient(8) on OpenBSD 6.9 as I wanted to be
> "ahead of the curve" before the eventual release of OpenBSD 7.0. During
> that time, there were no problems with lease renewals. I have not made
> any hardware or software changes other than the upgrade to 7.0.
>
> I've factory reset my bridge modem about a dozen times, I've changed the
> MAC address of the interface connected to the modem, I've experimented
> using different NICs altogether, and nothing has worked. At the time, I
> "knew" it was Xfinity; so I demanded that a tech come over and inspect
> the cable lines and modem. They said it was fine; although based on
> Internet reviews, that doesn't say much as they are often wrong. It
> wasn't until I had a slice of humble pie and actually considered that
> the problem was indeed my router that I was able to fix the problem by
> switching to dhcpcd which I have been already using for DHCPv6. Sure
> enough, I have had no issues with IPv4 renewals since then.
>  
> I do know that Xfinity, at least where I am, does NOT respond to unicast
> renewals for both DHCP and DHCPv6, but I am unsure if that is relevant.
> Before I successfully switched to dhcpcd, I made sure to log
> dhcpleased(8) over night. Here are the results:
>
> router# cat /root/dhcp.log
> sending output to nohup.out
> changed iface: em0[1]
> state_transition[em0] Down -> Init, timo: 1
> DHCPDISCOVER on em0
> parse_dhcp, from: 00:01:5c:63:ee:46, to: 1c:1b:0d:e7:08:5c
> parse_dhcp: 73.78.230.1:67 -> 73.78.230.64:68
> dhcp_hdr op: Boot Reply (2)
> dhcp_hdr htype: Ethernet (1)
> dhcp_hdr hlen: 6
> dhcp_hdr hops: 1
> dhcp_hdr xid: 0x9d477ad1
> dhcp_hdr secs: 0
> dhcp_hdr flags: 0x0
> dhcp_hdr ciaddr: 0.0.0.0
> dhcp_hdr yiaddr: 73.78.230.64
> dhcp_hdr siaddr: 0.0.0.0
> dhcp_hdr giaddr: 96.120.12.153
> dhcp_hdr chaddr: 1c:1b:0d:e7:08:5c ()
> DHO_DHCP_MESSAGE_TYPE: DHCPOFFER
> DHO_DHCP_SERVER_IDENTIFIER: 96.113.84.152
> DHO_DHCP_LEASE_TIME 4701s
> DHO_SUBNET_MASK: 255.255.254.0
> DHO_ROUTER: 73.78.230.1
> DHO_DOMAIN_NAME_SERVERS: 75.75.75.75 (1/2)
> DHO_DOMAIN_NAME_SERVERS: 75.75.76.76 (2/2)
> DHO_DOMAIN_NAME: hsd1.co.comcast.net.
> DHO_28, len: 4
> DHO_DHCP_RENEWAL_TIME 2350s
> DHO_DHCP_REBINDING_TIME 4113s
> DHO_HOST_NAME: router
> DHO_END
> DHCPOFFER on em0 from 00:01:5c:63:ee:46/73.78.230.1 to 
> 1c:1b:0d:e7:08:5c/73.78.230.64
> state_transition[em0] Init -> Requesting, timo: 1
> DHCPREQUEST on em0
> parse_dhcp, from: 00:01:5c:63:ee:46, to: 1c:1b:0d:e7:08:5c
> parse_dhcp: 73.78.230.1:67 -> 73.78.230.64:68
> dhcp_hdr op: Boot Reply (2)
> dhcp_hdr htype: Ethernet (1)
> dhcp_hdr hlen: 6
> dhcp_hdr hops: 1
> dhcp_hdr xid: 0x55ccb8cb
> dhcp_hdr secs: 0
> dhcp_hdr flags: 0x0
> dhcp_hdr ciaddr: 0.0.0.0
> dhcp_hdr yiaddr: 73.78.230.64
> dhcp_hdr siaddr: 0.0.0.0
> dhcp_hdr giaddr: 96.120.12.153
> dhcp_hdr chaddr: 1c:1b:0d:e7:08:5c ()
> DHO_DHCP_MESSAGE_TYPE: DHCPACK
> DHO_DHCP_SERVER_IDENTIFIER: 96.113.84.152
> DHO_DHCP_LEASE_TIME 4701s
> DHO_SUBNET_MASK: 255.255.254.0
> DHO_ROUTER: 73.78.230.1
> DHO_DOMAIN_NAME_SERVERS: 75.75.75.75 (1/2)
> DHO_DOMAIN_NAME_SERVERS: 75.75.76.76 (2/2)
> DHO_DOMAIN_NAME: hsd1.co.comcast.net.
> DHO_28, len: 4
> DHO_DHCP_RENEWAL_TIME 1101s
> DHO_DHCP_REBINDING_TIME 3801s
> DHO_HOST_NAME: router
> DHO_END
> DHCPACK on em0 from 00:01:5c:63:ee:46/73.78.230.1 to 
> 1c:1b:0d:e7:08:5c/73.78.230.64
> adding 73.78.230.64 to em0 (lease from 96.113.84.152)
> state_transition[em0] Requesting -> Bound, timo: 1101
> configure_interface em0
> iface_timeout[1]: Bound
> state_transition[em0] Bound -> Renewing, timo: 1350
> DHCPREQUEST on em0
> iface_timeout[1]: Renewing
> iface_timeout: res.tv_sec: 2452, rebinding_time: 3801
> state_transition[em0] Renewing -> Renewing, timo: 675
> DHCPREQUEST on em0
> iface_timeout[1]: Renewing
> iface_timeout: res.tv_sec: 3128, rebinding_time: 3801
> state_transition[em0] Renewing -> Renewing, timo: 337
> DHCPREQUEST on em0
> iface_timeout[1]: Renewing
> iface_timeout: res.tv_sec: 3465, rebinding_time: 3801
> state_transition[em0] Renewing -> Renewing, timo: 168
> DHCPREQUEST on em0
> iface_timeout[1]: Renewing
> iface_timeout: res.tv_sec: 3634, rebinding_time: 3801
> state_transition[em0] Renewing -> Renewing, timo: 84
> DHCPREQUEST on em0
> iface_timeout[1]: Renewing
> iface_timeout: res.tv_sec: 3719, rebinding_time: 3801
> state_transition[em0] Renewing -> Renewing, timo: 60
> DHCPREQUEST on em0
> iface_timeout[1]: Renewing
> iface_timeout: res.tv_sec: 3780, rebinding_time: 3801
> state_transition[em0] Renewing -> Renewing, timo: 60

as you point out your ISP is not 

Re: NSD exit status 11 on 7.0

[Florian Obser]

On 2021-10-20 07:55 +02, Otto Moerbeek  wrote:
> On Wed, Oct 20, 2021 at 07:47:30AM +0200, Mischa wrote:
>
>> Unfortunately our joy was short lived. This morning I noticed a lot of
>> Oct 20 07:44:15 name1 nsd[80814]: server 76410 died unexpectedly with status
>> 11, restarting
>> 
>> It looks like there is a potentially fixed in version 4.3.8.
>> 
>> https://github.com/NLnetLabs/nsd/issues/195
>> https://github.com/NLnetLabs/nsd/issues/189
>> 
>> https://github.com/NLnetLabs/nsd/blob/NSD_4_3_8_REL/doc/ChangeLog
>> 23 August 2021: Wouter
>> - Fix #189: nsd 4.3.7 crash answer_delegation: Assertion
>> `query->delegation_rrset' failed.
>> 
>> (Thanx Roger!)

That is not the correct fix, it only hides the problem and worse,
produces wrong results. Please try this, which is the fix for
https://github.com/NLnetLabs/nsd/issues/194

diff --git namedb.c namedb.c
index 06bef71147c..772e038b16d 100644
--- namedb.c
+++ namedb.c
@@ -583,10 +583,13 @@ domain_find_ns_rrsets(domain_type* domain, zone_type* 
zone, rrset_type **ns)
 {
/* return highest NS RRset in the zone that is a delegation above */
domain_type* result = NULL;
+   rrset_type* rrset = NULL;
while (domain && domain != zone->apex) {
-   *ns = domain_find_rrset(domain, zone, TYPE_NS);
-   if (*ns)
+   rrset = domain_find_rrset(domain, zone, TYPE_NS);
+   if (rrset) {
+   *ns = rrset;
result = domain;
+   }
domain = domain->parent;
}
 

>> 
>> As far as I can tell from the things Martijn found it might be the case.
>> 
>> Will give that a try and report back.
>> 
>> Mischa
>
> Are you going to try just the one line fix or the whole of 4.3.8?
> I suppose if we want to backport to -stable the one-line fix is
> preferred.

Yes, except, we should go with the correct fix above ;) Nothing else is
interesting to backport in 4.3.8 as far as I can tell.

>
>   -Otto
>

I provided an explanation what's going on in
https://github.com/NLnetLabs/nsd/issues/195#issuecomment-947505367
Reproduced here (slightly edited):

712296f (the one-line-fix) only hides the problem, it doesn't fix
anything. The real fix is ba0002e (the diff above).

f.9.1.1.0.0.2.ip6.arpa. is an ENT in ip6.arpa. and so is 2.ip6.arpa.
In line 1420 in query.c we haveq->delegation_domain = domain_find_ns_rrsets(
and the unfixed domain_find_ns_rrsets would find the NS RRset for 
9.1.1.0.0.2.ip6.arpa.

But it would then continue searching upwards, overwriting *ns which is
>delegation_rrset. Until it hits 2.ip6.arpa. which has no NS
records. So q->delegation_rrset = NULL but at the same time result !=
NULL because we did find a delegation RRset along the way, we just
ignored it (at least for 9.1.1.0.0.2.ip6.arpa., I didn't check if there
was one further up).

domain_find_ns_rrsets returns non-NULL which means we found a
delegation, but at the same time it doesn't give us the delegation NS
RRset.

It is probably best to revert 712296f since on its own it produces wrong
results. I.e. adding it to 4.3.7 gives this:

$ dig @192.168.178.219 +norec f.9.1.1.0.0.2.ip6.arpa NS

; <<>> dig 9.10.8-P1 <<>> @192.168.178.219 +norec f.9.1.1.0.0.2.ip6.arpa NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10923
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;f.9.1.1.0.0.2.ip6.arpa.INNS

;; AUTHORITY SECTION:
ip6.arpa.3600INSOAb.ip6-servers.arpa. nstld.iana.org. 
2021100154 1800 900 604800 3600

;; Query time: 0 msec
;; SERVER: 192.168.178.219#53(192.168.178.219)
;; WHEN: Wed Oct 20 10:24:56 CEST 2021
;; MSG SIZE  rcvd: 115

But the correct answer is this:

dig @::1 +norec  f.9.1.1.0.0.2.ip6.arpa NS

; <<>> dig 9.10.8-P1 <<>> @::1 +norec f.9.1.1.0.0.2.ip6.arpa NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48090
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;f.9.1.1.0.0.2.ip6.arpa.INNS

;; AUTHORITY SECTION:
9.1.1.0.0.2.ip6.arpa.86400INNSr.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSu.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSx.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSy.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSz.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSarin.authdns.ripe.net.

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Oct 20 10:24:16 CEST 2021
;; MSG SIZE  rcvd: 171


-- 
I'm not entirely sure you are real.

Re: How does bsd.upgrade work?

[Florian Obser]

On 2021-10-18 14:38 UTC, tetrahe...@danwin1210.me wrote:
> On Fri, Oct 15, 2021 at 10:14:56PM +, tetrahe...@danwin1210.me wrote:
>>My setup is a little bit unusual, and I'm trying to understand why
>>`uname -a` is still reporting 6.9 after I successfully booted
>>bsd.upgrade and saw the upgrade process scroll past.

unlikely

>
> I resolved the problem. The solution was to run `sysupgrade -n` to
> download all the upgrade files, and leave the `bsd.upgrade` kernel in
> place, next to the `bsd` kernel I usually boot.
>
> Then, at the next boot, manually boot the `bsd.upgrade` kernel by
> specifying its location.
>

I wouldn't call this "resolved". You are missing the point that
bsd.upgrade should run automatically. *shrug*

-- 
I'm not entirely sure you are real.

Re: xterm not opening on latest snapshot?

[Florian Obser]

mkdir ~/.cache should get you get going again until xterm is fixed.

On 6 September 2021 08:41:38 CEST, henkjan gersen  wrote:
>That indeed gives much more output, but not sure it gives more clarity
>as it ends with this:
>
>--
>69930 xterm CALL mprotect(0xf4aab8c6000,0x1000,0x3)
>69930 xterm RET mprotect 0
>69930 xterm CALL mprotect(0xf4aab8c6000,0x1000,0x169930 xterm RET mprotect 0
>69930 xterm CALL munmap(0xf4aab8c6000,0x1000)
>69930 xterm RET munmap 0
>69930 xterm CALL exit(1)
>77728 ksh PSIG SIGHUP SIG_DFL
>--
>From the output just before this the only thing that stands out to me
>is that it fails to find "/home/hge/.cache/fontconfig" as that returns
>an error for the unveil call and the writing of "xterm: unveil" in the
>.xsession-errors happens immediately after that.
>
>On Sun, 5 Sept 2021 at 20:44, Theo de Raadt  wrote:
>>
>> It is setgid (privdrop) for utmp support, so ktrace stops reporting on
>> what the program is doing.  If you temporarily chmod your utmp file a+w,
>> remove the setgid bit from the xterm binary, then you will likely be
>> able to ktrace further to get closer to identifying the issue.
>>
>> henkjan gersen  wrote:
>>
>> > Assuming I should run "ktrace -di xterm"  it doesn't show any failure
>> > condition at the end, i.e. the last lines from the kdump are
>> > --
>> > 90075 ktrace NAMI "/usr/X11R6/bin/xterm"
>> > 90075 ktrace ARGS
>> >  [0] = "xterm"
>> > --
>> > To me that last line looks like the process launches successfully, yet
>> > no xterm window shows. All errors that are shown before these lines
>> > are because it tries to locate xterm in various system-folders until
>> > it finds it in /usr/X11R6/bin
>> >
>> > @Dave: I'm running using snapshots, so it will take me some time to
>> > get to the stage where I can try your diff. I haven't gone through
>> > building xenocara before (aware that the FAQ describes how to do it).
>> >
>> > On Sun, 5 Sept 2021 at 15:12, Theo de Raadt  wrote:
>> > >
>> > > henkjan gersen  wrote:
>> > >
>> > > > On this mornings snapshot that I just upgraded to I can no longer open
>> > > > an xterm window. Based on the .xsession-error this must be related to
>> > > > the unveil capabilities that got added last week as I see "xterm:
>> > > > unveil" appearing in that file.
>> > > >
>> > > > Can someone give a hint on what I'm missing to be able to open an
>> > > > xterm window again?
>> > >
>> > > ktrace -di, and kdump
>> > >
>> > > The idea is to spot a failure condition near the end.
>> > >
>> >
>

-- 
Sent from a mobile device. Please excuse poor formatting.

Re: dhcpleased with option dhcp-client-identifier

[Florian Obser]

On 2021-08-18 12:48 UTC, Olivier Cherrier  wrote:
>   Hi,
>
> I have a DHCP setup using dhcp-client-identifier option.
>
> On the DHCP server side, i use something similar to this:
> ---8< /etc/dhcpd.conf
> host rex {
>   option dhcp-client-identifier "rex";
>   fixed-address 192.168.1.219;
>   }
> --->8
>
>
> On the clients, I use to configure them like that:
> $ grep -v '^#' /etc/dhclient.conf 
> send dhcp-client-identifier "rex";
> $
>
>
> Using -current and dhcpleased, I tried to configure it this way:
> ---8< /etc/dhcpleased.conf
> interface vio0 {
>   send client id browser
> }
> --->8
>
>
> But the generated packet doesn't seem to be well interpreted by dhcpd.
> Old packet (from dhclient machine called 'rex') is attached
> in packet_dhclient.txt and the new packet (from dhcpleased machine
> called 'browser') is attached in packet_dhcpleased.txt.
>
> The diff show some differences:
>
> 19,22c19,22
> <   0110:    6382 5363 3501 030c 0372  ..c.Sc5r
> <   0120: 6578 370b 011c 0279 030f 7706 0c43 423d  ex7y..w..CB=
> <   0130: 0372 6578 ff00       .rex
> <   0140:          
> ---
>>   0110:    6382 5363 3501 030c 0762  ..c.Sc5b
>>   0120: 726f 7773 6572 3d08 0062 726f 7773 6572  rowser=..browser
>>   0130: 3708 0103 060c 0f1c 7779 3204 c0a8 0162  7...wy2b
>>   0140: ff00         
>
>
> It seems dhcpleased is automatically adding the hostname of the machine
> in the DHCP message. That's the first instance of "browser" seen above.
>
> dhcpd(8) doesn't seem to catch correctly the client identifier. Is it
> supposed to work like that ?

They both send the hostname, that's not the problem. Opinions differ on how
the client ID should be encoded.

> Aug 13 18:10:11.599556 fe:e1:bb:d1:b2:92 ff:ff:ff:ff:ff:ff 0800 342:
> 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] xid:0xba962e2
> vend-rfc1048 DHCP:REQUEST HN:"browser"
 hostname

> CID:0.98.114.111.119.115.101.114 PR:SM+DG+NS+HN+DN+BR+119+121
  ^^^ client id

> RQ:192.168.1.98 [tos 0x10] (ttl 128, id 0, len 328)

> Aug 13 18:12:13.530188 fe:e1:bb:d1:c2:c4 fe:e1:ba:d0:b7:ec 0800 342:
> 192.168.1.219.68 > 192.168.1.12.67: [udp sum ok] xid:0xfbdfb850
> secs:4188 C:192.168.1.219 vend-rfc1048 DHCP:REQUEST HN:"rex"
  ^^^ hostname
> PR:SM+BR+TZ+121+DG+DN+119+NS+HN+BF+TFTP CID:114.101.120 [tos 0x10]
  ^^^ client id
> (ttl 128, id 38490, len 328)

dhclient sends this as client id:
CID:114.101.120

Which is hardware type 114 and hardware address 101.120 (in decimal)
Interpreted as ascii this is of course "rex".

RFC 2132 has this:
   The client identifier MAY consist of type-value pairs similar to the
   'htype'/'chaddr' fields defined in [3]. For instance, it MAY consist
   of a hardware type and hardware address. In this case the type field
   SHOULD be one of the ARP hardware types defined in STD2 [22].  A
   hardware type of 0 (zero) should be used when the value field
   contains an identifier other than a hardware address (e.g. a fully
   qualified domain name).

dhcpleased sends this:
CID:0.98.114.111.119.115.101.114

Which is hardware type 0 + "browser"

dhcpleased.conf has this:
 send client id client-id
 Send the dhcp client identifier option with a value of client-id.
 If client-id consists of a series of octets of two-digit
 hexadecimal numbers separated by colons, the first octet is used
 as the type and the rest as value.  The MAC address
 00:53:FF:AA:BB:CC would be configured as

   send client id "01:00:53:FF:AA:BB:CC"

 Otherwise the string client-id is sent verbatim with type zero.
 The default is to send the interface's MAC address as client
 identifier.

now, what will probably work for you is:

send client id "00:62:72:6f:77:73:65:72"

So in short, everything is terrible.

Should dhcpleased do what dhclient does?
People who actually use this please speak up.


>
> Thanks for any advice.
> Best.
>
> -- 
> Olivier Cherrier
> Phone: +352691570680
> mailto:o...@symacx.com
>
>
>

-- 
I'm not entirely sure you are real.

Re: nc(1) fails the tls handshake when destination ends with a full stop

[Florian Obser]

On 2021-05-30 19:55 +02, Theo Buehler  wrote:
> On Sun, May 30, 2021 at 01:43:54PM -0400, Daniel Jakots wrote:
>> On Sun, 30 May 2021 17:45:22 +0200, Theo Buehler 
>> wrote:
>> 
>> > Unsure. If people really think this is useful and necessary, I can be
>> > convinced. It's easy enough to do. And you're right, curl strips the
>> > trailing dot after resolving a host name for SNI and HTTP host header.
>> 
>> Given the current error message makes it hard to understand what the
>> problem is, I think it's nicer to fix the user error like curl(1) does.
>
> What I do not quite see is why you would want or expect to be able to
> have a trailing dot there. None of nc's examples have it and in ftp/curl
> it seems even weirder.
>

It's the name of the thing (RFC 8499):
   Fully-Qualified Domain Name (FQDN):  This is often just a clear way
  of saying the same thing as "domain name of a node", as outlined
  above.  However, the term is ambiguous.  Strictly speaking, a
  fully-qualified domain name would include every label, including
  the zero-length label of the root: such a name would be written
  "www.example.net." (note the terminating dot).  But, because every
  name eventually shares the common root, names are often written
  relative to the root (such as "www.example.net") and are still
  called "fully qualified".  This term first appeared in [RFC819].

In practical terms, if one adds the trailing dot, the stub resolver in
libc (asr) will not try the search list if the original name does not
resolve.
www.openbsd.org. is really only www.openbsd.org and not maybe
www.openbsd.org.home. or www.openbsd.org.lan. or some such.

-- 
I'm not entirely sure you are real.

Re: acme-client, error 21 at 0 depth lookup:unable to verify the first certificate

[Florian Obser]

https://xkcd.com/979/

On Sat, Apr 03, 2021 at 05:43:36PM +0200, open...@crw.name wrote:
> Self solved.
> 
> Am 02.04.2021 14:02, schrieb open...@crw.name:
> > Hello, I need some help to configure my acme-client the right way.
> > 
> > Obtain certificates itself works using OpenBSD -current #434 from April
> > 1st.
> > 
> > I have a CAA record
> > 
> > $ dig -t CAA our.bio-planet.earth +short
> > 0 issue "letsencrypt.org"
> > 
> > The configuration for httpd.conf and relayd.conf are taken fron honk
> > https://cvsweb.openbsd.org/ports/www/honk/pkg/README?rev=1.4=text/x-cvsweb-markup
> > 
> > The acme-client.conf is taken from /etc/examples/ and the settings for
> > the domain are
> > 
> > $ tail -f /etc/acme-client.conf
> > domain our.bio-planet.earth {
> > domain key "/etc/ssl/private/our.bio-planet.earth.key"
> > domain certificate "/etc/ssl/our.bio-planet.earth.crt"
> > domain full chain certificate
> > "/etc/ssl/our.bio-planet.earth.fullchain.pem"
> > sign with letsencrypt
> > }
> > 
> > The FQHN equals the domain and I don´t want to use other / sub
> > domains. The .crt file is required for the tls keypair part in
> > relayd.conf.
> > 
> > If I try to verify the certificate using
> > 
> > $ openssl verify our.bio.planet.earth.fullchain.pem
> > CN = our.bio-planet.earth
> > error 21 at 0 depth lookup:unable to verify the first certificate
> > CN = our.bio-planet.earth
> > error 21 at 0 depth lookup:unable to verify the first certificate
> > /etc/ssl/our.bio-planet.earth.fullchain.pem: verification failed: 21
> > (unable to verify the first certificate)
> > 
> > On the other hand
> > 
> > $ openssl verify /etc/ssl/cert.pem
> > cert.pem: OK
> > 
> > How can I fix this as it did not work if I try to use the certs for
> > example for prosody.
> > 
> > Thanks and regards,
> > 
> > 
> > Christoph
> 

-- 
I'm not entirely sure you are real.

Re: sysupgrade failure logs

[Florian Obser]

What are the permissions on the bsd.upgrade that's left behind?
If they are still +x then your issue is with the boot loader, maybe that 
boot.conf otto suggested. If they are -x then the boot loader started the 
install kernel but something went wrong.

On 14 February 2021 18:02:07 CET, Judah Kocher  wrote:
>Hello folks,
>
>I am having an issue with sysupgrade and I have had trouble finding the
>
>source of the problem so I hope someone here might be able and willing 
>to point me in the right direction.
>
>I have 6 small systems running OpenBSD -current and I have a basic 
>script which upgrades to the latest snapshot weekly. The systems are
>all 
>relatively similar. Three are the exact same piece of hardware, two are
>
>slightly different, and one is a VM configured to match the first three
>
>as closely as possible with virtual hardware.
>
>The script checks the current kernel version, (e.g. "GENERIC.MP#302") 
>logs it, runs sysupgrade, and after the reboot it checks the kernel 
>version again. If it is different it logs it as a "success" and if it
>is 
>still the same it logs it as a failure.
>
>All 6 systems were configured using the same autoinstall configuration 
>and the upgrade script is identical on each unit. However, two of the 
>three identical units always fail. When I remote into either system and
>
>manually run the upgrade script it also fails. I was able to get onsite
>
>with one of them where I connected a monitor and keyboard and manually 
>ran the script to observe the results but oddly enough it succeeded so
>I 
>learned nothing actionable. However it continues to fail the weekly 
>upgrade. I have confirmed that the script permissions are identical on 
>the working and nonworking units.
>
>The 4 units that successfully upgrade leave a mail message with a log
>of 
>the upgrade process. However I have been unable to find any record or 
>log on the systems that are failing to help me figure out why this
>isn't 
>working. The only difference I can identify between the systems is that
>
>"auto_upgrade.conf" and "bsd.upgrade" are both present in "/" on the
>two 
>systems that fail, but are properly removed on the 4 that succeed.
>
>I would appreciate any suggestions of what else I can try or check to 
>figure out what is causing this issue.
>
>Thanks
>
>Judah

-- 
Sent from a mobile device. Please excuse poor formating.

Re: Website - Missing kstat man page

[Florian Obser]

On 3 January 2021 15:25:13 CET, Ingo Schwarze  wrote:
>Hi,
>
>Daniel Jakots wrote on Sat, Jan 02, 2021 at 11:19:07PM -0500:
>> On Sat, 2 Jan 2021 22:57:06 -0500,  wrote:
>
>>> I came across a broken link during some pre-install research.
>>> 
>>> While browsing URL https://www.openbsd.org/68.html,
>>> I noticed URL link on the webpage for kstat(1) generates
>>> a "No results found." message when pointing to its man page:
>>> 
>>> https://man.openbsd.org/kstat
>>> 
>>> Flagged as new, so I was curious about its general function.
>
>> It looks like kstat isn't linked to the build so it's not built by
>> default, therefore it's not present on the man.o.o server.
>
>Correct.  To explain why the link is not live yet, i added a sentence
>
>  The userland utility is not yet installed by default.
>
>to the 68.html page.
>
>I guess already having the link even though it is still dead is
>intentional such that it springs to life as soon as the kstat(1)
>utility
>will be installed by default.  Otherwise, we would be likely to forget
>as release pages from the past are not very actively maintained.

Indeed, pamela@ and me discussed this problem when she started to maintain 
plus.html. We figured it's best to have the dead link that's likely to appear 
at one point because nobody is going to remember to wander in and add links 
later.

>
>Yours,
>  Ingo
>
>
>> The source is in src/usr.bin/kstat. If you don't have any src tree
>> around, you can either read it on github [1] or you can fetch the raw
>> version [2] and give it to mandoc(1)
>> 
>> [1]:
>https://github.com/openbsd/src/blob/a09091e54b85e8cd86ccf4763998e3800065d5dc/usr.bin/kstat/kstat.1
>> [2]:
>https://raw.githubusercontent.com/openbsd/src/a09091e54b85e8cd86ccf4763998e3800065d5dc/usr.bin/kstat/kstat.1
>> 
>> (I could copy paste the resulting man page in this email, but you'd
>lose
>> all the fancy markup :))
>> 
>> Actually, mandoc(1) supports html output, here's what it gives
>> https://static.chown.me/private/misc/kstat.html

-- 
Sent from a mobile device. Please excuse poor formating.

Re: httpd location statement

[Florian Obser]

I think the only way is to repeat the location statement for each extension :/

You can leave out the socket since that's the default

On 10 December 2020 18:24:20 CET, Alexey Vatchenko  
wrote:
>Hello!
>
>I’m migrating from ancient server with OpenBSD’s apache1 to 6.8
>OpenBSD’s httpd.
>In my configuration I use Handler for .html, .htm, .css, .js and 4 more
>extensions.
>I’ve found a way to configure it for one extension and it works great!
>
>location “*.html” {
>fastcgi {
>socket “/run/slowcgi.sock”
>param SCRIPT_FILENAME “/path/to/handler.pl"
>}
>}
>
>And I havn't found a way to specify multiple extensions.
>
>Any advice how to do it?
>
>Thanks in advance!

-- 
Sent from a mobile device. Please excuse poor formating.

Re: Impact of 002_icmp6.patch

[Florian Obser]

On Fri, Oct 30, 2020 at 11:58:41AM +0100, Martin Schröder wrote:
> Am Fr., 30. Okt. 2020 um 11:54 Uhr schrieb Denis Fondras 
> :
> > Please, fix your tweet. The default install answer for IPv6 is 'none'.
> 
> This borders on "switch off v6 for security reasons", which would be just 
> wrong.

since you like to put words in our mouths...

> 
> I'd much prefer that the project adopted a" v6 first, vintage ip
> second" approach.
> But I'm not a dev.

... you are saying if you were a dev things would be better?

Thanks for ignoring all the hard work we put into making IPv6 better
in OpenBSD.

> 
> Best
> Martin
> 

-- 
I'm not entirely sure you are real.

Re: OpenDNSSEC signer engine: Bus error: How to get debug information?

[Florian Obser]

On Tue, Sep 22, 2020 at 04:08:16PM +0200, Why 42? The lists account. wrote:
> 
> On Tue, Sep 22, 2020 at 07:12:47AM -, Stuart Henderson wrote:
> > Sounds like they are trapping sigbus themselves but the handler isn't
> > giving useful information.
> > 
> > Try just running it under gdb:
> > pkg_add gdb
> > egdb ods-signerd
> > set args -dv
> > run
> > 
> > and see if you can get a backtrace. You may need to build opendnssec
> > with debug symbols to get a usable trace though (checkout the ports
> > tree and build it with "make DEBUG=-g repackage reinstall").
> 
> Hi Stuart,
> 
> Thanks for that, concise and really helpful. The debug build process was
> easier than I expected :).
> 
> For what is worth the results in egdb are:
> Thread 2 received signal SIGBUS, Bus error.
> [Switching to thread 478985]
> 0x0851fb90f5f5 in ldns_rr_clone () from /usr/local/lib/libldns.so.7.1
> (gdb) bt
> #0  0x0851fb90f5f5 in ldns_rr_clone () from /usr/local/lib/libldns.so.7.1
> #1  0x084fca6e4e55 in ixfr_del_rr (ixfr=0x852782d0d80, 
> rr=0xdfdfdfdfdfdfdfdf) at signer/ixfr.c:134
 this is a use after free 


> #2  0x084fca6ea0da in rrset_sign (ctx=0x8522842d800, rrset= out>, signtime=1600781131) at signer/rrset.c:758
> #3  0x084fca6ddd6c in drudge (worker=0x8521a9e4000) at 
> daemon/signertasks.c:196
> #4  0x084fca714e0b in runthread (data=0x851d1fc6300) at janitor.c:318
> #5  0x0852553ad0d1 in _rthread_start (v=) at 
> /usr/src/lib/librthread/rthread.c:96
> #6  0x0851f742dc38 in __tfork_thread () at 
> /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:77
> #7  0x in ?? ()
> (gdb) info args
> No symbol table info available.
> (gdb) info local
> No symbol table info available.
> (gdb) up
> #1  0x084fca6e4e55 in ixfr_del_rr (ixfr=0x852782d0d80, 
> rr=0xdfdfdfdfdfdfdfdf) at signer/ixfr.c:134
> 134   ldns_rr* rr_copy = ldns_rr_clone(rr);
> (gdb) info args
> ixfr = 0x852782d0d80
> rr = 0xdfdfdfdfdfdfdfdf
> (gdb) info local
> rr_copy = 
> 
> I'm not a gdb expert, but I wonder why it says "No symbol table info
> available" ...
> 
> In any case, I've forwarded the info. on to the opendnssec developer
> list.
> 
> Thanks again.
> 
> Cheers,
> Robb.
> 

-- 
I'm not entirely sure you are real.

Re: Is altroot a sysupgrade foe?

[Florian Obser]

On Sun, Sep 20, 2020 at 01:19:17AM -0400, Predrag Punosevac wrote:
> 
> Hi Misc,
> 
> For number of years I had a very simple scheme to backup my OpenBSD
> infrastructure servers running critical network services for our small
> university lab. Namely, I would put a low profile usb flash drive and
> use /altroot facility in the daily(8) scripts to backup root partition
> to it as described in FAQ
> 
> https://www.openbsd.org/faq/faq14.html#altroot
> 
> I started doing that many years ago, before sysupgrade was available. It
> worked like a charm. Once sysupgrade became available I noticed that it
> would get confused by an extra disk in the server. My "solution" was to
> remove usb drive before running sysupgrade and that worked OK until
> Covid 19 when the physical access to my servers became more challenging.
> 
> I had a quick look at the sysupgrade.sh script
> 
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/sysupgrade/sysupgrade.sh?rev=1.40=text/x-cvsweb-markup
> 
> and I have to admit that it is not clear to me how the target disk for
> the installation is picked.  I completely understand that sysupgrade is
> designed not to be configurable in order to be foolproof.

http://cvsweb.openbsd.org/src/distrib/miniroot/install.sub?rev=1.1154=text/x-cvsweb-markup

Specifically check_unattendedupgrade().

The installer tries to guess what a root disk is
( get_dkdevs_root -> is_rootdisk ).
Your altroot disk will naturally look like a root disk, that's the
whole point of the facility after all.
The installer will pick the first disk that looks like a root disk.
If there is no auto_upgrade.conf present it will stop.
I'm surprised that your usb stick shows up as the first disk in the
installer but computers are weird I guess.

I have a diff that might improve on this and that might make 6.8.

-- 
I'm not entirely sure you are real.

Re: bgpd config advice needed

[Florian Obser]

On Tue, Aug 25, 2020 at 09:48:04AM -, Stuart Henderson wrote:
> 
> Guesses can be made, but a quick email might get a more accurate
> answer :) "Hi, I see you are padding your announcements at $IX and we
> are seeing you from other peers with the same path length, would you
> prefer we send to you directly or via 64512?"

Don't forget the circuit id.
SCNR

-- 
I'm not entirely sure you are real.

Re: unwind, is it possible to prevent validation failures?

[Florian Obser]

On Wed, Aug 05, 2020 at 07:19:29AM +0200, Peter J. Philipp wrote:
> Hi,
> 
> Aug  5 07:09:55 beta unwind[1703]: startup
> Aug  5 07:09:59 beta unwind[62921]: validation failure 
>  . A IN>: no DNSSEC records from 192.168.177.1 for DS internal.centroid.eu. 
> while
>  building chain of trust
> 
> Let me describe my setup.  Here is my unwind.conf:
> 
> beta# more /etc/unwind.conf  
> forwarder 192.168.177.1
> preference forwarder
> 
> At 192.168.177.1 runs a forwarding delphinusdnsd (snapshot version).  It has
> some internal zones, such as:  internal.centroid.eu, petphi.centroid.eu, these
> are not zones that are on the big Internet and thus have no DNSSEC.

You could unbreak this in DNS by setting up insecure delegations
(publishing NS records without DS records) for your internal zones.
Doesn't mean that the authoritatives need to be reachable from the outside.
That would unbreak it for all your machines.

It doesn't look like you are running real split horizon DNS, you are
just being "lazy".

> 
> unwind is being overly picky about this it seems.  Is there a way to tell it,
> to not try to validate these internal zones?

The other way is:

 force [accept bogus] type {name ...}
 Force resolving of name and its subdomains by the given resolver
 type.  If accept bogus is specified validation is not enforced.

> 
> I'm running on 6.7.
> 
> Best Regards,
> -peter
> 

-- 
I'm not entirely sure you are real.

Re: Sysupgrade fails with "cannot create SHA256.sig: Permission denied"

[Florian Obser]

Wild guess, /home is an nfs mount or mounted read-only? That's not going to 
work unfortunately.


On 17 June 2020 22:23:13 CEST, "Raymond, David"  wrote:
>I am trying to upgrade a bunch of machines from 6.6 to 6.7 using
>sysupgrade and I get the message
>
>/usr/sbin/sysupgrade[136]: cannot create SHA256.sig: Permission denied
>
>These are AMD64 machines on wired internet at my university.
>Sysupgrade worked fine on a laptop and on an AMD desktop using my home
>internet provider.
>
>Any hints?  Might there be some protocol that is blocked by the
>university network?  When I boot bsd.rd directly (after having been
>locally verified), the upgrade works fine.
>
>Dave Raymond

-- 
Sent from a mobile device. Please excuse poor formating.

Re: sysupgrade confused by additional disk?

[Florian Obser]

On Mon, May 25, 2020 at 12:26:43PM -0400, Nick Holland wrote:
> While OpenBSD itself is great about using duids, those are defined in
> the 'a' partition of the boot disk..which is usually the first disk. But
> in your case, the "first disk" doesn't include the 'a' partitionand the
> /etc/fstab file...which is probably causing the upgrade kernel to choke.

Yeah, that's not how this works.
See distrib/miniroot/install.sub:

# Determine if the supplied disk is a potential root disk, by:
# - Check the disklabel if there is an 'a' partition of type 4.2BSD
# - Mount the partition (read-only) and look for typical root filesystem layout
is_rootdisk() {
local _d=$1 _rc=1

(
make_dev $_d
if disklabel $_d | grep -q '^  a: .*4\.2BSD ' &&
mount -t ffs -r /dev/${_d}a /mnt; then
ls -d /mnt/{bin,dev,etc,home,mnt,root,sbin,tmp,usr,var}
_rc=$?
umount -f /mnt
fi
rm -f /dev/{r,}$_d?
return $_rc
) >/dev/null 2>&1
}

-- 
I'm not entirely sure you are real.

Re: acme client failing [SOLVED]

[Florian Obser]

A common problem. :(
I finally got around to improve acme-client's error reporting, it should be 
better in -current and 6.8

On 23 May 2020 21:28:23 CEST, Teno Deuter  wrote:
>On Sat, May 23, 2020 at 8:22 PM Stuart Henderson 
>wrote:
>>
>> On 2020-05-23, Teno Deuter  wrote:
>> > acme-client: challenge, token:  , status: 2
>> > acme-client: dochngreq:
>> > https://acme-v02.api.letsencrypt.org/acme/authz-v3/4766326725
>> > acme-client: challenge, token: ... , status: 0
>> > acme-client: /var/www/acme/...: created
>> > acme-client:
>https://acme-v02.api.letsencrypt.org/acme/chall-v3/4766326725/TzAk5w:
>> > challenge
>> > acme-client: order.status -1
>> > acme-client: bad exit: netproc(62115): 1
>> >
>> > Thank you for your kind help
>> >
>> >
>>
>> https://acme-v02.api.letsencrypt.org/acme/authz-v3/4766326725 shows
>an
>> error from letsencrypt:
>>
>> "DNS problem: NXDOMAIN looking up A for www.jpcode.org - check that a
>> DNS record exists for this domain"
>>
>
>Thank you for your swift response. I didn't know how to debug the
>acme-client output.
>
>Correct. I forgot to update the DNS records. Now everything works well.

-- 
Sent from a mobile device. Please excuse poor formating.

Re: OpenBSD insecurity rumors from isopenbsdsecu.re

[Florian Obser]

Please leave, optionally seek professional help and never come back.

-- 
I'm not entirely sure you are real.

Re: memmem

[Florian Obser]

On Tue, Apr 14, 2020 at 06:52:21AM +, Roderick wrote:
> Is that not a little too primitive?

I thought so, too. No context, no explanation just a one-liner.

-- 
I'm not entirely sure you are real.

Re: 6.6 pflow IPFIX removed?

[Florian Obser]

The ifconfig option parser is... special.
You must set flowdst as well as pflowproto.

On 4 March 2020 14:02:18 CET, Kapetanakis Giannis  
wrote:
>Hi,
>
>Is IPFIX removed  from pflow in 6.6?
>
># ifconfig pflow0 pflowproto 10
>ifconfig: SIOCSETPFLOW: Can't assign requested address
>
>pflow(4) still mentions it.
>
>regards,
>
>Giannis

-- 
Sent from a mobile device. Please excuse poor formating.

Re: sysupgrade woes on beaglebone black

[Florian Obser]

On Fri, Jan 10, 2020 at 10:06:41AM +0100, Jan Stary wrote:
> It seems it's the SD card that is slow (the machine
> is a BeagleBone Black) - will try with a faster one.
> 
> It seems I am missing out on
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/install.sub.diff?r1=1.1141=1.1142=h
> - I can't figure out how to pass the -x option that sets $UU
> (and thus makes the timer reset before each set is installed).

Those are not the droids you are looking for, you have UU set.

Line 73:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/dot.profile?annotate=1.44

> 
> Thank you for the insight.
> 

-- 
I'm not entirely sure you are real.

Re: OpenBSD's extremely poor network/disk performance?

[Florian Obser]

On Tue, Jan 07, 2020 at 05:35:13PM +0300, Hamd wrote:
> It's 2020 and it's -still- sad to see OpenBSD -still- has the
> lowest/poorest (general/overall) performance ever:

Thank you for your kind and encouraging words.
I will get right on fixing these issues for you.

-- 
I'm not entirely sure you are real.

Re: But there is Fossil...

[Florian Obser]

On Sat, Jan 04, 2020 at 04:59:40PM +, go...@disroot.org wrote:
> I never read

Please stop wasting our time then.

Thanks,
Florian

-- 
I'm not entirely sure you are real.

Re: acme-client issue with domain w/ alternative name

[Florian Obser]

On Tue, Oct 22, 2019 at 09:56:57AM +0100, Daniel Winters wrote:
> Good morning,
> 
> > Today acme-client renewed all but 2 of my domains; the two that have
> > "alternative names" in the certificates. I cannot get it to renew
> > those two.  This is on amd64 on 6.6-current, updated today.
> 
> I can reproduce this on amd64 current, as well as on 6.6.
> 
> Same error and and very similar configuration based on the one in
> /etc/examples.

you mean renewing fails for you with alternative names or you mean you
see tls_close: EOF without close notify? I think everybody sees that.
It started to show up some time ago. I think let's encrypt changed
something on the server.

In any case, I just force-renewed a cert with alt names and it just
worked.

please run acme-client with -vv to see what's going on over the
network if you have renew problems.

> 
> Daniel
> 
> 
> > My acme-config.conf is the latest example version, with the v2 URLs
> > and with example.com replaced by my domains.
> >
> > #
> > # $OpenBSD: acme-client.conf,v 1.2 2019/06/07 08:08:30 florian Exp $
> > #
> > authority letsencrypt {
> > api url "https://acme-v02.api.letsencrypt.org/directory;
> > account key "/etc/acme/letsencrypt-privkey.pem"
> > }
> >
> > authority letsencrypt-staging {
> > api url "https://acme-staging-v02.api.letsencrypt.org/directory;
> > account key "/etc/acme/letsencrypt-staging-privkey.pem"
> > }
> >
> > domain androidcookbook.com {
> > alternative names { androidcookbook.net }
> > domain key "/etc/ssl/private/androidcookbook.com.key"
> > domain certificate "/etc/ssl/androidcookbook.com.crt"
> > domain full chain certificate 
> > "/etc/ssl/androidcookbook.com.fullchain.pem"
> > sign with letsencrypt
> > }
> > domain annabot.org {
> > domain key "/etc/ssl/private/annabot.org.key"
> > domain certificate "/etc/ssl/annabot.org.crt"
> > domain full chain certificate 
> > "/etc/ssl/annabot.org.fullchain.pem"
> > sign with letsencrypt
> > }
> > ...
> >
> > The first domain fails, the second one succeeded.
> >
> > $ doas acme-client androidcookbook.com
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > $ echo $?
> > 1
> > $
> >
> > IDK what those EOF w/o notify are caused by, but the domains that worked
> > also gave a similar bunch of that message.
> >
> > Running with -v does not give any useful info except it ends with -1:
> >
> > $ doas acme-client -v -F androidcookbook.com
> > acme-client: /etc/ssl/androidcookbook.com.crt: certificate renewable: 29 
> > days left
> > acme-client: https://acme-v02.api.letsencrypt.org/directory: directories
> > acme-client: acme-v02.api.letsencrypt.org: DNS: 172.65.32.248
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: dochngreq: 
> > https://acme-v02.api.letsencrypt.org/acme/authz-v3/882690343
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: challenge, token: 22zE2mRAquYtRmY0lMxiCVfYXcTLEUEm78rRa6Nt0So, 
> > uri: https://acme-v02.api.letsencrypt.org/acme/chall-v3/882690343/im5q-Q, 
> > status: 0
> > acme-client: /var/www/acme/22zE2mRAquYtRmY0lMxiCVfYXcTLEUEm78rRa6Nt0So: 
> > created
> > acme-client: 
> > https://acme-v02.api.letsencrypt.org/acme/chall-v3/882690343/im5q-Q: 
> > challenge
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: dochngreq: 
> > https://acme-v02.api.letsencrypt.org/acme/authz-v3/882690357
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: challenge, token: XQm6jdVi6yzlFJHP8ucI8d3AenQFl81KqfC4tNlaDsU, 
> > uri: https://acme-v02.api.letsencrypt.org/acme/chall-v3/882690357/7cuNOw, 
> > status: 0
> > acme-client: /var/www/acme/XQm6jdVi6yzlFJHP8ucI8d3AenQFl81KqfC4tNlaDsU: 
> > created
> > acme-client: 
> > https://acme-v02.api.letsencrypt.org/acme/chall-v3/882690357/7cuNOw: 
> > challenge
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: 172.65.32.248: tls_close: EOF without close notify
> > acme-client: order.status -1
> > acme-client: bad exit: netproc(82984): 1
> > $
> >
> >
> > Any thoughts or more info? Thx.
> 

-- 
I'm not entirely sure you are real.

Re: How can I remove sets installed by sysupgrade?

[Florian Obser]

On Tue, Sep 17, 2019 at 09:43:20AM +0200, Marc Espie wrote:
> I'm a bit surprised nobody looked at instrumenting what sets are actually
> installed on a machine during install/manual upgrade and cloning that 
> into sysupgrade to avoid this kind of surprise...
> 

Yeah, I think sysupgrade was a mistake. Too many people want different
things from it while at the same time the upgrade mechanism in bsd.rd
is perfectly stream lined and has all the options people need.

-- 
I'm not entirely sure you are real.

Re: acme-client no longer usable on -stable?

[Florian Obser]

On Thu, Sep 12, 2019 at 12:42:58PM +0200, Henry Jensen wrote:
> Greetings,
> 
> A tweet[0]from @romanzolotarev confused some people, including me.
> 
> Basically he says, that if you wish co continue to use acme-client you
> have to upgrade to -current, because of the switch to ACME v02 API and
> the deprecation of v01.

[citation needed]
I guess they ran out of space in their twitters.

https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430

> 
> That would mean, that acme-client on -stable can no longer be used.
> 
> Is that true, and if so, it is planned to publish a patch for stable?

mostly not true and it is not planned to publish a patch for stable.

No new accounts starting November 2019 and no new domains starting
June 2020. So existing domains can be renewed while 6.5 still receives
patches.

Changing the api endpoint from 01 to 02 in 6.5 will not work.

> 
> 
> [0] https://twitter.com/romanzolotarev/status/1172009006078074886
> 

-- 
I'm not entirely sure you are real.

Re: handling snapshot installation in production environment

[Florian Obser]

This will only work if you stop upgrading snapshots long before 6.6 is 
announced.
Otherwise you will be on 6.6-current by November 1st and -r will wait for 6.7.

On September 2, 2019 1:15:26 PM GMT+02:00, Ian Darwin  
wrote:
>> The sysupgrade tool is a nice way to install the newest snapshot,
>never
>> had a problem. But what is the correct way to install a stable
>release
>> on snapshot? Using the standard bsd.rd upgrade way?
>
>From man sysupgrade:
>
>-r  Upgrade to the next release.  The default is to find out if the
> system is running a release or a snapshot.  In case of release
> sysupgrade downloads the next release.
>
>So when 6.6 is announced as released
>
>   # sysupgrade -r

-- 
Sent from a mobile device. Please excuse poor formating.

Re: Package -stable updates

[Florian Obser]

On Thu, Aug 29, 2019 at 09:39:40AM +0300, Consus wrote:
> On 19:59 Wed 28 Aug, Steven Shockley wrote:
> > So, many thanks to everyone who put together the new -stable updates for
> > packages.  Is there a command I can put in the crontab that will only
> > output if there are updates?  Similar to what syspatch or openup does.
> > I tried pkg_add -unx, but that still tells me to delete old files and
> > prints the quirks line even if there are no updates.
> 
> I use
> 
>   0 7 * * * pkg_add -un | grep -v 'signed on'
> 
> and it works okay, no warnings about deleting old files.
> 
> Though removing quirks line would be nice.
> 

I thought you had moved on since stable packages are one or two
decades too late?

-- 
I'm not entirely sure you are real.

Re: IPv6 problems

[Florian Obser]

On Sun, Aug 18, 2019 at 07:36:55PM +0200, list wrote:
> Hi,
> 
> The output of slaacctl show interface vio0 ist the following:
> 
> # slaacctl show interface vio0
> 
> slaacctl: connect: /dev/slaacd.sock: Connection refused
> 
> This is not how it is supposed to be i guess.

it would be interesting to know why slaacd is not running though.
Because it's supposed to be always running.

It looks like this when no v6 is configured at all:

[florian@openbsd-dev:~]
> slaacctl show interface em0

[florian@openbsd-dev:~]

and like this once v6 is configured but no router advertisements are
present:
[florian@openbsd-dev:~]
> doas ifconfig em0 inet6 autoconf
[florian@openbsd-dev:~]
> slaacctl show interface em0
em0:
 index:   1 running: yes privacy: yes
lladdr: 00:0c:29:61:52:4b
 inet6: fe80::86fa:49f4:be6c:1ca8%em0



-- 
I'm not entirely sure you are real.

Re: How do I publish default router preferences using rad?

[Florian Obser]

 {"mtu", MTU},
> >{"nameserver",  NAMESERVER},
> >{"no",  NO},
> >{"on-link", ONLINK},
> >{"other",   OTHER},
> > +   {"preference",  PREFERENCE},
> >{"preferred",   PREFERRED},
> >{"prefix",  PREFIX},
> >{"reachable",   REACHABLE},
> > diff --git a/usr.sbin/rad/printconf.c b/usr.sbin/rad/printconf.c
> > index d42890da518..c2173d2142f 100644
> > --- a/usr.sbin/rad/printconf.c
> > +++ b/usr.sbin/rad/printconf.c
> > @@ -26,6 +26,7 @@
> > #include 
> > #include 
> > +#include 
> > #include 
> > #include 
> > @@ -34,6 +35,7 @@
> > #include "rad.h"
> > const char*yesno(int);
> > +const char*preference(int);
> > void   print_ra_options(const char*, const struct ra_options_conf*);
> > void   print_prefix_options(const char*, const struct ra_prefix_conf*);
> > @@ -42,6 +44,20 @@ yesno(int flag)
> > {
> >return flag ? "yes" : "no";
> > }
> > +const char*
> > +preference(int p)
> > +{
> > +   switch (p) {
> > +   case ND_RA_FLAG_RTPREF_LOW:
> > +   return "low";
> > +   case ND_RA_FLAG_RTPREF_MEDIUM:
> > +   return "medium";
> > +   case ND_RA_FLAG_RTPREF_HIGH:
> > +   return "high";
> > +   default:
> > +   return "invalid";
> > +   }
> > +}
> > void
> > print_ra_options(const char *indent, const struct ra_options_conf 
> > *ra_options)
> > @@ -60,6 +76,9 @@ print_ra_options(const char *indent, const struct
> > ra_options_conf *ra_options)
> >printf("%sretrans timer %u\n", indent, ra_options->retrans_timer);
> >if (ra_options->mtu > 0)
> >printf("%smtu %u\n", indent, ra_options->mtu);
> > +   if (ra_options->preference != ND_RA_FLAG_RTPREF_RSV)
> > +   printf("%spreference %s\n", indent,
> > +preference(ra_options->preference));
> >if (!SIMPLEQ_EMPTY(_options->ra_rdnss_list) ||
> > !SIMPLEQ_EMPTY(_options->ra_dnssl_list)) {
> > diff --git a/usr.sbin/rad/rad.c b/usr.sbin/rad/rad.c
> > index 93675167b6b..cb0593f11ab 100644
> > --- a/usr.sbin/rad/rad.c
> > +++ b/usr.sbin/rad/rad.c
> > @@ -433,7 +433,7 @@ main_dispatch_frontend(int fd, short event, void *bula)
> >case IMSG_CTL_LOG_VERBOSE:
> >if (IMSG_DATA_SIZE(imsg) != sizeof(verbose))
> >fatalx("%s: IMSG_CTL_LOG_VERBOSE wrong length: "
> > -"%lu", __func__, IMSG_DATA_SIZE(imsg));
> > +"%lu", __func__, IMSG_DATA_SIZE(imsg));
> >memcpy(, imsg.data, sizeof(verbose));
> >log_setverbose(verbose);
> >break;
> > @@ -754,6 +754,7 @@ config_new_empty(void)
> >xconf->ra_options.cur_hl = 0;
> >xconf->ra_options.m_flag = 0;
> >xconf->ra_options.o_flag = 0;
> > +   xconf->ra_options.preference = ND_RA_FLAG_RTPREF_MEDIUM;
> >xconf->ra_options.router_lifetime = 1800;
> >xconf->ra_options.reachable_time = 0;
> >xconf->ra_options.retrans_timer = 0;
> > diff --git a/usr.sbin/rad/rad.conf.5 b/usr.sbin/rad/rad.conf.5
> > index f651a715d1a..b822f3d195d 100644
> > --- a/usr.sbin/rad/rad.conf.5
> > +++ b/usr.sbin/rad/rad.conf.5
> > @@ -107,6 +107,8 @@ The default is 1800 seconds.
> > .\" XXX
> > .\" .It Ic retrans timer Ar number
> > .\" XXX
> > +.It Ic preference Pq Ic low Ns | Ns Ic medium Ns | Ns Ic high
> > +Communicate router preference to clients. The default is medium.
> > .El
> > .Sh INTERFACES
> > A list of interfaces or interface groups to send advertisments on:
> > diff --git a/usr.sbin/rad/rad.h b/usr.sbin/rad/rad.h
> > index 2bbf7c8ed5c..cfaa5e88638 100644
> > --- a/usr.sbin/rad/rad.h
> > +++ b/usr.sbin/rad/rad.h
> > @@ -92,6 +92,7 @@ struct ra_options_conf {
> >int cur_hl; /* current hop limit */
> >int m_flag; /* managed address conf flag */
> >int o_flag; /* other conf flag */
> > +   int preference; /* router preference (see RFC 4191 2.2) */
> >int router_lifetime;/* default router lifetime */
> >uint32_treachable_time;
> >uint32_tretrans_timer;
> >
> >
> >

Re: How do I publish default router preferences using rad?

[Florian Obser]

On Tue, Aug 06, 2019 at 11:17:04PM +0200, Sebastian Benoit wrote:
> Caleb(enlightened.des...@gmail.com) on 2019.08.06 08:05:48 -0700:
> > How do I publish default router preferences as defined in RFC 4191
> > (https://tools.ietf.org/html/rfc4191) using rad in OpenBSD 6.5?
> > I've read the friendly rad.conf man page
> > (https://man.openbsd.org/rad.conf.5) and scanned the source
> > (https://github.com/openbsd/src/tree/master/usr.sbin/rad) with no
> > success.
> 
> You can't, because it was not implemented.
> 
> That is, until now.
> 
> I wrote a patch, which you can test if you like. It's completly untested
> though.
> 

needs more yak shaving

> 
> diff --git usr.sbin/rad/frontend.c usr.sbin/rad/frontend.c
> index 8178b058629..75723797fcf 100644
> --- usr.sbin/rad/frontend.c
> +++ usr.sbin/rad/frontend.c
> @@ -1016,6 +1016,8 @@ build_packet(struct ra_iface *ra_iface)
>   ra->nd_ra_flags_reserved |= ND_RA_FLAG_MANAGED;
>   if (ra_options_conf->o_flag)
>   ra->nd_ra_flags_reserved |= ND_RA_FLAG_OTHER;
> + ra->nd_ra_flags_reserved |=
> + ra_options_conf->preference;
>   if (ra_iface->removed)
>   /* tell clients that we are no longer a default router */
>   ra->nd_ra_router_lifetime = 0;
> @@ -1048,6 +1050,8 @@ build_packet(struct ra_iface *ra_iface)
>   if (ra_prefix_conf->aflag)
>   ndopt_pi->nd_opt_pi_flags_reserved |=
>   ND_OPT_PI_FLAG_AUTO;
> + ndopt_pi->nd_opt_pi_flags_reserved |=
> + ra_prefix_conf->preference;

This is a prefix information option (type 3) not a route information option 
(type 24).
Option 3 does not have a preference.

>   ndopt_pi->nd_opt_pi_valid_time = htonl(ra_prefix_conf->vltime);
>   ndopt_pi->nd_opt_pi_preferred_time =
>   htonl(ra_prefix_conf->pltime);
> diff --git usr.sbin/rad/parse.y usr.sbin/rad/parse.y
> index 004e5e22f92..b004ab37356 100644
> --- usr.sbin/rad/parse.y
> +++ usr.sbin/rad/parse.y
> @@ -106,6 +106,7 @@ typedef struct {
>   union {
>   int64_t  number;
>   char*string;
> + shortpref;

eek, just treat it as a number?

>   } v;
>   int lineno;
>  } YYSTYPE;
> @@ -117,11 +118,13 @@ typedef struct {
>  %token   CONFIGURATION OTHER LIFETIME REACHABLE TIME RETRANS TIMER
>  %token   AUTO PREFIX VALID PREFERRED LIFETIME ONLINK AUTONOMOUS
>  %token   ADDRESS_CONFIGURATION DNS NAMESERVER SEARCH MTU
> +%token   PREFERENCE LOW MEDIUM HIGH
>  
>  %token STRING
>  %token NUMBER
>  %type  yesno
>  %type  string
> +%typepreftype
>  
>  %%
>  
> @@ -213,6 +216,9 @@ ra_opt_block  : DEFAULT ROUTER yesno {
>   | MTU NUMBER {
>   ra_options->mtu = $2;
>   }
> + | PREFERENCE preftype {
> + ra_options->preference = $2;
> + }
>   | DNS dns_block
>   ;
>  
> @@ -298,6 +304,19 @@ ra_prefixoptsl   : VALID LIFETIME NUMBER {
>   | AUTONOMOUS ADDRESS_CONFIGURATION yesno {
>   ra_prefix_conf->aflag = $3;
>   }
> + | PREFERENCE preftype {
> + ra_prefix_conf->preference = $2;
> + }
> + ;

see above, we are announcing prefix information, not route information

> +preftype : LOW {
> + $$ = RA_PREFIXOPT_PREF_LOW;
> + }
> + | MEDIUM {
> + $$ = RA_PREFIXOPT_PREF_MEDIUM;
> + }
> + | HIGH {
> + $$ = RA_PREFIXOPT_PREF_HIGH;
> + }

please use the defines from icmp6.h:

#define ND_RA_FLAG_RTPREF_HIGH  0x08/* 1000 */
#define ND_RA_FLAG_RTPREF_MEDIUM0x00/*  */
#define ND_RA_FLAG_RTPREF_LOW   0x18/* 00011000 */
#define ND_RA_FLAG_RTPREF_RSV   0x10/* 0001 */


>   ;
>  dns_block: '{' optnl dnsopts_l '}'
>   | '{' optnl '}'
> @@ -425,17 +444,21 @@ lookup(char *s)
>   {"configuration",   CONFIGURATION},
>   {"default", DEFAULT},
>   {"dns", DNS},
> + {"high",HIGH},
>   {"hop", HOP},
>   {"include", INCLUDE},
>   {"interface",   RA_IFACE},
>   {"lifetime",LIFETIME},
>   {"limit",   LIMIT},
> + {"low", LOW},
>   {"managed", MANAGED},
> + {"medium",  MEDIUM},
>   {"mtu", MTU},
>   {"nameserver",  NAMESERVER},
>   {"no",  NO},
>   {"on-link", ONLINK},
>   

Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link

[Florian Obser]

On Thu, Jun 20, 2019 at 10:47:49PM +0200, mathijs wrote:
> this makes misc@ so much more amusing

It really doesn't. We are not here to have manure tossed at us for the
audience's amusement.

Everytime something like this happens it takes time away from hacking
on OpenBSD. It doesn't matter that it wasn't directed at me. I'm part
of the project and I care about my fellow developers.

-- 
I'm not entirely sure you are real.

Re: httpd option max body size is ignored for subdomain

[Florian Obser]

On Sun, Feb 03, 2019 at 03:43:20PM +, Chris Narkiewicz wrote:
> Hi,
> 
> I'm trying to configure Nextcloud on a subdomain. My config has 2
> vhosts and connection max request body is not respected for my subdomain.

this has been fixed in current. Wild guess, you are on 6.4?

This diff should apply cleanly to stable sources:

Index: server_http.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
retrieving revision 1.127
retrieving revision 1.128
diff -u -p -r1.127 -r1.128
--- server_http.c   4 Nov 2018 05:56:45 -   1.127
+++ server_http.c   4 Dec 2018 18:12:08 -   1.128
@@ -198,7 +198,6 @@ void
 server_read_http(struct bufferevent *bev, void *arg)
 {
struct client   *clt = arg;
-   struct server_config*srv_conf = clt->clt_srv_conf;
struct http_descriptor  *desc = clt->clt_descreq;
struct evbuffer *src = EVBUFFER_INPUT(bev);
char*line = NULL, *key, *value;
@@ -357,11 +356,6 @@ server_read_http(struct bufferevent *bev
server_abort_http(clt, 500, errstr);
goto abort;
}
-   if ((size_t)clt->clt_toread >
-   srv_conf->maxrequestbody) {
-   server_abort_http(clt, 413, NULL);
-   goto abort;
-   }
}
 
if (strcasecmp("Transfer-Encoding", key) == 0 &&
@@ -1332,6 +1326,12 @@ server_response(struct httpd *httpd, str
 
/* Now search for the updated location */
srv_conf = server_getlocation(clt, desc->http_path);
+   }
+
+   if (clt->clt_toread > 0 && (size_t)clt->clt_toread >
+   srv_conf->maxrequestbody) {
+   server_abort_http(clt, 413, NULL);
+   return (-1);
}
 
if (srv_conf->flags & SRVFLAG_BLOCK) {


-- 
I'm not entirely sure you are real.

Re: The Dark Side of the ForSSHe - OpenSSH malwares

[Florian Obser]

On Thu, Dec 13, 2018 at 10:02:45AM +0100, Otto Moerbeek wrote:
> On Thu, Dec 13, 2018 at 09:50:31AM +0100, Florian Obser wrote:
> 
> > On Thu, Dec 13, 2018 at 09:25:25AM +0100, Kollar Arpad wrote:
> > > Any creative hints to defend against these kind of threats? 
> > 
> > Your system has been compromised. The attacker is able to replace
> > binaries, you have lost. If your package manager can still tell you
> > that the sshd binary has been replaced that only means that you are
> > dealing with an incompetent attacker.
> > 
> > Throw the computer away. Get a new one. Install from scratch, restore
> > data (and only data!) from backup.
> 
> This assumes you can tell the difference between data and code.
> 
> It's a rather fundamental thing that you cannot tell the difference
> between data and code.
> 
> Data read by a program is interpreted in some way. That's a form of execution.
> 

True. Some people just pick up black smithing. I think they are on to
something...

>   -Otto
> 
> 

-- 
I'm not entirely sure you are real.

Re: The Dark Side of the ForSSHe - OpenSSH malwares

[Florian Obser]

On Thu, Dec 13, 2018 at 09:25:25AM +0100, Kollar Arpad wrote:
> Any creative hints to defend against these kind of threats? 

Your system has been compromised. The attacker is able to replace
binaries, you have lost. If your package manager can still tell you
that the sshd binary has been replaced that only means that you are
dealing with an incompetent attacker.

Throw the computer away. Get a new one. Install from scratch, restore
data (and only data!) from backup.

-- 
I'm not entirely sure you are real.

Re: sh /etc/netstart interface counter intuitive behaviour with multiple inet aliases 6.4 and 6.3

[Florian Obser]

One possible workaround is putting
-inet as the first line in /etc/hostname.vio4
It will nuke all v4 addresses and re-add them.

Depending on your usecase this might work for you or it might melt
down your whole network ;)

On Thu, Dec 06, 2018 at 10:49:01PM +, Tom Smyth wrote:
> Hello,
> 
> Im running a router with multiple ips on an interface using the
> inet alias
> 
> issue:
> when commenting out configured  aliases on hostname.if
> after running sh /etc/netstart vio4
> 
> if you run ifconfig vio4 after the restart of the interface
> the old aliases that were commented still appear in ifconfig output ahead
> of the first ip address configured in the /etc/hostname.vio4 file.
> 
> ifconfig  before commenting  out   10.134.91.253  in hostname.vio4
> is listed below
> vio4: flags=8843 mtu 1500
> lladdr 16:2c:a4:f2:b4:e3
> index 5 priority 0 llprio 3
> media: Ethernet autoselect
> status: active
> inet 10.94.0.1 netmask 0x broadcast 10.94.255.255
> inet 10.134.91.65 netmask 0xfffc broadcast 10.134.91.67
> inet 10.134.91.69 netmask 0xfffc broadcast 10.134.91.71
> inet 10.134.91.73 netmask 0xfffc broadcast 10.134.91.75
> inet 10.134.91.85 netmask 0xfffc broadcast 10.134.91.87
> inet 10.134.91.89 netmask 0xfffc broadcast 10.134.91.91
> inet 10.134.91.93 netmask 0xfffc broadcast 10.134.91.95
> inet 10.134.91.161 netmask 0xfffc broadcast 10.134.91.163
> inet 10.134.91.165 netmask 0xfffc broadcast 10.134.91.167
> inet 10.134.91.169 netmask 0xfffc broadcast 10.134.91.171
> inet 10.134.91.173 netmask 0xfffc broadcast 10.134.91.175
> inet 10.134.91.193 netmask 0xfffc broadcast 10.134.91.195
> inet 10.134.91.197 netmask 0xfffc broadcast 10.134.91.199
> inet 10.134.91.201 netmask 0xfffc broadcast 10.134.91.203
> inet 10.134.91.205 netmask 0xfffc broadcast 10.134.91.207
> inet 10.134.91.209 netmask 0xfffc broadcast 10.134.91.211
> inet 10.134.91.213 netmask 0xfffc broadcast 10.134.91.215
> inet 10.134.91.217 netmask 0xfffc broadcast 10.134.91.219
> inet 10.134.91.221 netmask 0xfffc broadcast 10.134.91.223
> inet 10.134.91.225 netmask 0xfffc broadcast 10.134.91.227
> inet 10.134.91.229 netmask 0xfffc broadcast 10.134.91.231
> inet 10.134.91.233 netmask 0xfffc broadcast 10.134.91.235
> inet 10.134.91.237 netmask 0xfffc broadcast 10.134.91.239
> inet 10.134.91.241 netmask 0xfffc broadcast 10.134.91.243
> inet 10.134.91.245 netmask 0xfffc broadcast 10.134.91.247
> inet 10.134.91.249 netmask 0xfffc broadcast 10.134.91.251
> inet 10.134.91.253 netmask 0xfffc broadcast 10.134.91.255
> 
> 
> after commenting out the last 2 inet aliases , and running sh /etc/netstart 
> vio4
> 
> the ifconfig output is as follows  (i have highlighted with ***  the addresses
> which I think should have been removed
> 
> vio4: flags=8843 mtu 1500
> lladdr 16:2c:a4:f2:b4:e3
> index 5 priority 0 llprio 3
> media: Ethernet autoselect
> status: active
> ** inet 10.134.91.249 netmask 0xfffc broadcast 10.134.91.251
> ** inet 10.134.91.253 netmask 0xfffc broadcast 10.134.91.255
> inet 10.94.0.1 netmask 0x broadcast 10.94.255.255
> inet 10.134.91.65 netmask 0xfffc broadcast 10.134.91.67
> inet 10.134.91.69 netmask 0xfffc broadcast 10.134.91.71
> inet 10.134.91.73 netmask 0xfffc broadcast 10.134.91.75
> inet 10.134.91.85 netmask 0xfffc broadcast 10.134.91.87
> inet 10.134.91.89 netmask 0xfffc broadcast 10.134.91.91
> inet 10.134.91.93 netmask 0xfffc broadcast 10.134.91.95
> inet 10.134.91.161 netmask 0xfffc broadcast 10.134.91.163
> inet 10.134.91.165 netmask 0xfffc broadcast 10.134.91.167
> inet 10.134.91.169 netmask 0xfffc broadcast 10.134.91.171
> inet 10.134.91.173 netmask 0xfffc broadcast 10.134.91.175
> inet 10.134.91.193 netmask 0xfffc broadcast 10.134.91.195
> inet 10.134.91.197 netmask 0xfffc broadcast 10.134.91.199
> inet 10.134.91.201 netmask 0xfffc broadcast 10.134.91.203
> inet 10.134.91.205 netmask 0xfffc broadcast 10.134.91.207
> inet 10.134.91.209 netmask 0xfffc broadcast 10.134.91.211
> inet 10.134.91.213 netmask 0xfffc broadcast 10.134.91.215
> inet 10.134.91.217 netmask 0xfffc broadcast 10.134.91.219
> inet 10.134.91.221 netmask 0xfffc broadcast 10.134.91.223
> inet 10.134.91.225 netmask 0xfffc broadcast 10.134.91.227
> inet 10.134.91.229 netmask 0xfffc broadcast 10.134.91.231
> 

Re: Permission on virtual user password file [dovecot+smtpd]

[Florian Obser]

On Tue, Nov 13, 2018 at 07:38:04PM +0100, Thuban wrote:
> Hi,
> I use dovecot and smtpd on my personal mail server.
> They both share the same password file.
> 
> I works very well, but I'm concerned about permissions on this file : 
> 
>   -rw-r--r--  1 root  wheel passwd
> 
> It's world readable. I would like to let dovecot and smtpd to read only this
> file, and no one else could.
> 
> 
> I tried to set a _maildaemons group and put _smtpd and _dovecot users in it,
> then : 
> 
>   -rw-r-  1 root  _maildaemons passwd
> 
> 
> Sadly, dovecot can't read the passwd file with this configuration,a nd I can't
> figure out why.
> 
> Any advice ?
> 
> 
>   # part of dovecot config 
>   passdb {
>   args = scheme=blf-crypt /etc/mail/passwd
>   driver = passwd-file
>   }
> 
> -- 
> thuban
> 

This works for me and avoids an additional group:

-r--r-  1 _dovecot  _smtpd  1477 Sep 27  2017 /etc/mail/passwd

I'm now wondering if user and group should be flipped around, I trust
smtpd more than dovecot.

-- 
I'm not entirely sure you are real.

Re: iridium-browser + unveil

[Florian Obser]

On Thu, Nov 08, 2018 at 09:45:38AM +0100, Stefan Wollny wrote:
> Am 08.11.18 um 09:03 schrieb Stefan Wollny:
> > Hi there,
> > 
> > just a little nit with the iridium-browser unveiled:
> > 
> > I changed the 'exec' command in /usr/local/bin/iridium like so:
> > - LANG=${_l} exec "/usr/local/iridium/iridium" "${@}"
> > + LANG=${_l} exec "/usr/local/iridium/iridium" "--enable-unveil" "${@}"
> > 
> > With this change I can browse the web as before. BUT: My startpage is a
> > html-file in the users home directory containing a huge collection of
> > links to web sites. I use this file at home and at work where I am
> > forced to use the most popular unsafe OS. With iridium unveiled this
> > page is no longer accessible instead I get 'ERR_FILE_NOT_FOUND'.
> > 
> > Switching back to the exec without "--enable-unveil" and iridium finds
> > the file again. Easily reproducible.
> > 
> > With other browsers (e.g. FF, otter, netsurf, links+) this particular
> > file is accessible. No reason not to enable unveil on iridium in
> > particular as it just has been updated (in ports).
> > 
> Found an easy solution: While access to the user's home directory is not
> permitted, access to the subfolders _is_ allowed. Simply copied that
> particular file to ~/Downloads/, changed the path in iridium's settings
> and we're back to familiar operations. :-)
> 
> Now: How to give permission to access my home directory?
> 

I'm afraid you are missing the point. If you want it to have access to
your home directory run it without --enable-unveil. For all intents
and purposes that's the same thing as "giving permission to ~/"

The point of unveil in chrome is that it can't exfiltrate your ssh
private key.

-- 
I'm not entirely sure you are real.

Re: iridium-browser + unveil

[Florian Obser]

On Thu, Nov 08, 2018 at 10:52:11AM +0200, Dumitru Moldovan wrote:
> On Thu, 8 Nov 2018 09:03:51 +0100, Stefan Wollny  wrote:
> > 
> > I changed the 'exec' command in /usr/local/bin/iridium like so:
> > - LANG=${_l} exec "/usr/local/iridium/iridium" "${@}"
> > + LANG=${_l} exec "/usr/local/iridium/iridium" "--enable-unveil" "${@}"
> > 
> > With this change I can browse the web as before. BUT: My startpage is a
> > html-file in the users home directory containing a huge collection of
> > links to web sites. I use this file at home and at work where I am
> > forced to use the most popular unsafe OS. With iridium unveiled this
> > page is no longer accessible instead I get 'ERR_FILE_NOT_FOUND'.
> 
> With unveil enabled, your browser can only download files to your ~/Downloads 
> sub-dir, and can only upload files from your ~/Uploads sub-dir.  So maybe put 
> your HTML file in ~/Uploads and use the new location as the start page?
> 
> Disclaimer: I am not a user of Iridium or Chromium with unveil, but this is 
> what I remember from Bob Beck's presentation on the subject at EuroBSDCon in 
> September.  Hope I got the sub-dirs right!  Thinking about it, there should 
> be write access to ~/.cache as well, maybe even /tmp, but these are just 
> extra details.
> 

It's only ~/Downloads

-- 
I'm not entirely sure you are real.

Re: Munin node over IPv6

[Florian Obser]

On Thu, Nov 08, 2018 at 12:21:58PM +0100, Solene Rapenne wrote:
> Alarig Le Lay  wrote:
> > Hi,
> > 
> > I would like to pull my munin node over IPv6, but the process is only
> > listening on IPv4.
> > 
> > guinch# grep '^host' /etc/munin/munin-node.conf
> > host *
> > guinch# netstat -af inet | grep 4949
> > tcp  0  0  *.4949 *.*LISTEN
> > guinch# netstat -af inet6 | grep 4949
> > guinch#
> > 
> > This configuration works on other OSes.
> > How could I make it on OpenBSD?
> > 
> > Thanks,
> 
> can you try the following:
> 
> host ::1 (or even host :::1 it seems that a bug requires to add an extra 
> colon)
> 

I believe one needs p5-IO-Socket-INET6 installed.
I have host * in my config and that gives me:

tcp  0  0  *.4949 *.*LISTEN
tcp6 0  0  *.4949 *.*LISTEN

Cheers,
Florian

-- 
I'm not entirely sure you are real.

Re: nsd question

[Florian Obser]

On Tue, Sep 11, 2018 at 04:12:48PM +0200, Peter J. Philipp wrote:
> Hi,
> 
> I wasn't going to ask, but the book I have (alternative dns servers - jpm) is
> somewhat outdated on nsd.
> 
> If I'm correct, in order to pull the zones to disk on a slave nsd setup, one
> has to manually or crontab "nsd-control write example.com".  Is this correct?
> 
> Is there an automated way to do this in the server or must I crontab this?

nsd.conf(5) has this:

   zonefiles-write: 
  Write changed secondary zones to their zonefile every N seconds.
  If the zone (pattern) configuration has "" zonefile, it is not
  written.  Zones that have received zone transfer updates are
  written to their zonefile.  Default is 0 (disabled) when there
  is a database, and 3600 (1 hour) when database is "".  The
  database also commits zone transfer contents.  You can configure
  it away from the default by putting the config statement for
  zonefiles-write: after the database: statement in the config
  file.

Default is to have no database, so on a slave it takes an hour to write to disk.

> 
> What I'm worried on is not writing any zone material to disk and then having
> a mishap on my delphinusdnsd primary server.  A sudden restart could make
> nsd forget zones if they weren't written to disk somehow right?
> 

yes, it will answer servfail

> Thanks and best regards,
> 
> -peter
> 

-- 
I'm not entirely sure you are real.

call for testing: rad(8) - a rtadvd(8) replacement

[Florian Obser]

During g2k18 I commited rad(8).

The latest amd64 and i386 snapshots should contain it with enough
features to replace rtadvd(8). If you are using rtadvd(8) I'd
appreciate if you could switch to rad(8) and report back if any
features are missing.

The plan is to unhook rtadvd(8) from the build sooner rather than
later and to ship 6.4 with rad(8) only.

If you are running rtadvd(8) with out any configuration and only have
rtadvd_flags=em1 the /etc/rad.conf file will be

---8<---
interface em0
---8<---

Once that is inplace disable rtadvd and enable rad:

# rcctl stop rtadvd
# rcctl disable rtadvd
# rcctl enable rad
# rcctl start rad

see man rad.conf for documentation on the config file format. Good
news: it's no longer termcap based!

Thanks!

-- 
I'm not entirely sure you are real.

Re: cgi issues

[Florian Obser]

On Sun, Jul 08, 2018 at 08:30:29AM -0500, Edgar Pettijohn III wrote:
> 
> 
> On 07/08/18 08:09, Florian Obser wrote:
> > On Sun, Jul 08, 2018 at 07:53:41AM -0500, Edgar Pettijohn III wrote:
> > > I am playing around with cgi written in c. I am getting what seems like a
> > > weird error though. I'm starting off with a very basic program:
> > > 
> > > #include 
> > > 
> > > int
> > > main(void)
> > > {
> > >      fprintf(stdout,
> > >     "\n"
> > >     "\n"
> > >     "test\n"
> > >     "\n"
> > >     "\n"
> > >     );
> > you need to output a header, something like
> > printf("Status: 200 OK\r\nContent-Type: text/html\r\n\r\n");
> 
> still the same results

next guess, you are not building a static binary.

this might tell you what goes wrong:
doas chroot -u www /var/www/ /cgi-bin/test

alternatively stop slowcgi and start it in debug mode,
that might tell you things

> > 
> > you might also want to consider using kcgi (in ports)
> > 
> > https://kristaps.bsd.lv/kcgi/
> I'll look into it.
> 
> thanks
> > >      fprintf(stdout, "it works\n");
> > > 
> > >      fprintf(
> > >     stdout,
> > >     "\n"
> > >     "\n"
> > >    );
> > > 
> > >      return (0);
> > > }
> > > 
> > > I set up bgplg to make sure that httpd and slowcgi are working correctly.
> > > Here is the only debug info I could find.
> > > 
> > > doas httpd -dvv
> > > startup
> > > server_privinit: adding server default
> > > socket_rlimit: max open files 1024
> > > socket_rlimit: max open files 1024
> > > socket_rlimit: max open files 1024
> > > server_launch: configuring server default
> > > server_launch: running server default
> > > server_launch: configuring server default
> > > server_launch: configuring server default
> > > server_launch: running server default
> > > server_launch: running server default
> > > default 127.0.0.1 - - [08/Jul/2018:07:45:51 -0500] "GET /cgi-bin/bgplg
> > > HTTP/1.1" 200 0
> > > default 127.0.0.1 - - [08/Jul/2018:07:45:55 -0500] "GET /cgi-bin/test
> > > HTTP/1.1" 500 0
> > > server default, client 1 (1 active), 127.0.0.1:46773 -> 127.0.0.1, empty
> > > stdout (500 Internal Server Error)
> > > 
> > > I'm not sure what `empty stdout' means.
> > > 
> > > Thanks,
> > > 
> > > Edgar
> > > 
> 

-- 
I'm not entirely sure you are real.

Re: cgi issues

[Florian Obser]

On Sun, Jul 08, 2018 at 07:53:41AM -0500, Edgar Pettijohn III wrote:
> I am playing around with cgi written in c. I am getting what seems like a
> weird error though. I'm starting off with a very basic program:
> 
> #include 
> 
> int
> main(void)
> {
>     fprintf(stdout,
>    "\n"
>    "\n"
>    "test\n"
>    "\n"
>    "\n"
>    );

you need to output a header, something like
printf("Status: 200 OK\r\nContent-Type: text/html\r\n\r\n");

you might also want to consider using kcgi (in ports)

https://kristaps.bsd.lv/kcgi/

> 
>     fprintf(stdout, "it works\n");
> 
>     fprintf(
>    stdout,
>    "\n"
>    "\n"
>   );
> 
>     return (0);
> }
> 
> I set up bgplg to make sure that httpd and slowcgi are working correctly.
> Here is the only debug info I could find.
> 
> doas httpd -dvv
> startup
> server_privinit: adding server default
> socket_rlimit: max open files 1024
> socket_rlimit: max open files 1024
> socket_rlimit: max open files 1024
> server_launch: configuring server default
> server_launch: running server default
> server_launch: configuring server default
> server_launch: configuring server default
> server_launch: running server default
> server_launch: running server default
> default 127.0.0.1 - - [08/Jul/2018:07:45:51 -0500] "GET /cgi-bin/bgplg
> HTTP/1.1" 200 0
> default 127.0.0.1 - - [08/Jul/2018:07:45:55 -0500] "GET /cgi-bin/test
> HTTP/1.1" 500 0
> server default, client 1 (1 active), 127.0.0.1:46773 -> 127.0.0.1, empty
> stdout (500 Internal Server Error)
> 
> I'm not sure what `empty stdout' means.
> 
> Thanks,
> 
> Edgar
> 

-- 
I'm not entirely sure you are real.

Re: rtadvd bug ?

[Florian Obser]

Be careful not to break dhcpv6-pd.

I suspect the problem is actually in make_prefix() in config.c which 
unconditionally sets
onlink and autoconf.

I stared at this for some time but can't figure out how to fix this.

RFC 4861 has this which I don't think rtadvd is implementing correctly:

  Prefix Information
 These options specify the prefixes that are on-link
 and/or are used for stateless address
 autoconfiguration.  A router SHOULD include all its
 on-link prefixes (except the link-local prefix) so
 that multihomed hosts have complete prefix
 information about on-link destinations for the
 links to which they attach.  If complete
 information is lacking, a host with multiple
 interfaces may not be able to choose the correct
 outgoing interface when sending traffic to its
 neighbors.

On Sun, Jun 17, 2018 at 10:57:57PM +0200, Sebastian Benoit wrote:
> Hi,
> 
> Denis Fondras(open...@ledeuns.net) on 2018.06.17 21:45:37 +0200:
> > On Mon, Jun 11, 2018 at 10:13:36AM +0200, Bastien Durel wrote:
> > > Because it's lower than RTP_CONNECTED and I don't know what it is. The
> > > /* local address routes (must be the highest) */ comment makes me think
> > > it MAY be 127.0.0.0/8 or ::1/128 (useless for rtadvd then), but it may
> > > be related to interface addresses; I did not check in the kernel code
> > > how this flag is set. (hence the question marks)
> > > 
> > 
> > RTP_LOCAL are local addresses, they won't pass the test at L367 of rtadvd.c
> > anyway.
> > 
> > Here is a diff if you want to try :
> > 
> > Index: if.c
> > ===
> > RCS file: /cvs/src/usr.sbin/rtadvd/if.c,v
> > retrieving revision 1.46
> > diff -u -p -r1.46 if.c
> > --- if.c12 Aug 2017 07:38:26 -  1.46
> > +++ if.c17 Jun 2018 19:37:55 -
> > @@ -285,6 +285,14 @@ get_ifm_flags(char *buf)
> > return (ifm->ifm_flags);
> >  }
> >  
> > +u_char
> > +get_priority(char *buf)
> > +{
> > +   struct rt_msghdr *rtm = (struct rt_msghdr *)buf;
> > +
> > +   return (rtm->rtm_priority);
> > +}
> > +
> >  int
> >  get_prefixlen(char *buf)
> >  {
> > Index: if.h
> > ===
> > RCS file: /cvs/src/usr.sbin/rtadvd/if.h,v
> > retrieving revision 1.14
> > diff -u -p -r1.14 if.h
> > --- if.h10 Aug 2017 19:07:14 -  1.14
> > +++ if.h17 Jun 2018 19:37:55 -
> > @@ -45,6 +45,7 @@ struct in6_addr *get_addr(char *);
> >  int get_rtm_ifindex(char *);
> >  int get_ifm_ifindex(char *);
> >  int get_ifam_ifindex(char *);
> > +u_char get_priority(char *);
> >  int get_ifm_flags(char *);
> >  int get_prefixlen(char *);
> >  int prefixlen(u_char *, u_char *);
> > Index: rtadvd.c
> > ===
> > RCS file: /cvs/src/usr.sbin/rtadvd/rtadvd.c,v
> > retrieving revision 1.91
> > diff -u -p -r1.91 rtadvd.c
> > --- rtadvd.c22 Aug 2017 01:44:09 -  1.91
> > +++ rtadvd.c17 Jun 2018 19:37:55 -
> > @@ -309,7 +309,7 @@ rtsock_cb(int fd, short event, void *arg
> >  {
> > int n, type, ifindex = 0, oldifflags, plen;
> > char *rtm;
> > -   u_char ifname[IF_NAMESIZE];
> > +   u_char ifname[IF_NAMESIZE], prio;
> > struct prefix *prefix;
> > struct rainfo *rai;
> > struct in6_addr *addr;
> > @@ -362,6 +362,11 @@ rtsock_cb(int fd, short event, void *arg
> >  
> > addr = get_addr(rtm);
> > plen = get_prefixlen(rtm);
> > +   prio = get_priority(rtm);
> > +
> > +   if (!(prio & RTP_CONNECTED))
> > +   break;
> > +
> 
> 
> you have to do check
> 
>   if (rtm->rtm_flags & RTF_CONNECTED)
> 
> The priority of a connected route depends on the interface priority,
> see ifconfig(8) on the priority option and wifi and carp interfaces have a
> different default prio than other interfacs. So the prio is not an indicator
> for the type of the route.
> 
> /Benno
> 
> > /* sanity check for plen */
> > /* as RFC2373, prefixlen is at least 4 */
> > if (plen < 4 || plen > 127) {
> > 
> 
> -- 
> 

-- 
I'm not entirely sure you are real.

Re: virtual colocation? Amazon/cloud?

[Florian Obser]

On Fri, Jun 15, 2018 at 08:09:40AM +1000, Stuart Longland wrote:
> On 15/06/18 06:50, Steve Fairhead wrote:
> > I gather Amazon are not quite there yet re OpenBSD virtual machines. Can
> > anyone here provide a cluebat as to prospects or alternatives? I don't
> > want to move away from OpenBSD - it's my security blanket... and I love
> > it *so* much...
> 
> I use Vultr for a virtual host which does some static hosting
> (openhttpd) and DNS (nsd).  They ship an OpenBSD image, but it's based
> on OpenBSD 6.0, so you'll want to bring your own ISO image and do the
> installation yourself.
> 

They have 6.3 these days and their support told me if you select their
iso instead of bringing your own their provisining system will
understand that you run OpenBSD and set kvm_intel.preemption_timer=0
on the hypervisor.

I didn't try that though but I did raise a ticket with them to have
the flag set on my old VMs, they did that within minutes.

They seem to do a staggered upgrade of all their datacenters and new
kvm needs that flag so it's a good thing they do that for you.

> The console can be a bit idiosyncratic with the installer/console I
> find, but it's usable.  Once you have a SSH key deployed the console
> doesn't matter much.
> 
> That said, I'm interested in alternatives, as Vultr aren't completely
> honest with regards to their plans; specifically they don't tell people
> that the $2.50/month plans are actually meant as "sandboxes" rather than
> permanent instances.
> 
> About their only redeeming feature for me is they've got a few data
> centres around the world including Sydney (where my VPS is located) and
> they're not expensive.
> 
> Regards,
> -- 
> Stuart Longland (aka Redhatter, VK4MSL)
> 
> I haven't lost my mind...
>   ...it's backed up on a tape somewhere.
> 

-- 
I'm not entirely sure you are real.

Re: acme-client new cert error

[Florian Obser]

On Sat, May 26, 2018 at 09:14:35AM -0700, Scott Vanderbilt wrote:
> On 5/26/2018 4:54 AM, Stuart Henderson wrote:
> 
> > aeneas.datagenic.com doesn't respond on port 80. (And if I can't
> > fetch it, letsencrypt's checkers are also unlikely to be able to).
> > 
> > Firewall issue?
> 
> Oh, FFS.
> 
> Yes. A silly pf rule blocking incoming traffic from outside my LAN that I
> overlooked when I first considered that idea, but then discarded on account
> of the error message. Which, to me, at least, does not in any reasonable way
> point to a connection problem.
> 
> So, thanks very much for applying the clue stick. And, to whom may I suggest
> that the misleading error message from acme-client be changed to something
> actually resembling the problem it has encountered?

The error message is coming from letsencrypt, from your original mail:

acme-client: transfer buffer: [{ "type": "urn:acme:error:unauthorized", 
"detail": "Error creating new cert :: authorizations for these names not found 
or expired: aeneas.datagenic.com", "status": 403 }] (176 bytes) 

transfer buffer is the json we got back from letsencrypt. I seem to
recall that this used to be different and they did tell us that the
connection was refused. Oh but that might be if they are getting an
icmp port unreachable, I guess you where just dropping the request in
pf?

-- 
I'm not entirely sure you are real.

Re: IPv6 problem after 6.3 upgrade

[Florian Obser]

On Tue, Apr 03, 2018 at 04:05:44PM +0200, Leo Unglaub wrote:
> Hey,
> 
> > see "IPv6 broken on Hetzner.de vServer OpenBSD 6.3 / amd64" on bugs@
> > 
> > I'm pretty sure hetzner sets a static route to your link local address for
> > the /64 they assign to you.
> > 
> > Since the the link local address changes with RFC 7217 you blackhole the 
> > /64...
> 
> you are right. It works fine when I disable RFC 7217 via -soii in my
> hostname.* file. I am going to open a ticket with Hetzner so that they can
> fix there routing. Because i asume using the -soii will not be a solution
> for the next couple of years.

Hang on, what Hetzner is doing is not wrong.

I currently discussing with phessler@ if it's better to revert RFC
7217 for link local addresses and only leave it for global addresses.

> 
> Thanks for helping me!
> Greetings
> Leo
> 

-- 
I'm not entirely sure you are real.

Re: IPv6 problem after 6.3 upgrade

[Florian Obser]

On Tue, Apr 03, 2018 at 03:43:07PM +0200, Paul de Weerd wrote:
> On Tue, Apr 03, 2018 at 03:23:19PM +0200, Miles wrote:
> | 
> | Am 03.04.2018 um 14:56 schrieb Leo Unglaub:
> | > Hello,
> | > i have a IPv6 problem since i upgraded to 6.3. I cannot reach other
> | > 
> | /etc/hostname.vio0
> | >> inet 195.201.22.203 255.255.255.255
> | >> inet6 2a01:4f8:1c0c:4ed8::10 64
> | >> !route add -inet 172.31.1.1 -llinfo -link -static -iface vio0
> | >> !route add -inet default 172.31.1.1
> | > 
> | 
> | I had also an IPv6 issue. The solution was to add -soii into the
> | hostname.vio0 :
> 
> What was your issue?
> 
> | /etc/hostname.vio0
> | 
> | 
> | inet 195.201.22.203 255.255.255.255
> | inet6 2a01:4f8:1c0c:4ed8::10 64
> | -soii
> | !route add -inet 172.31.1.1 -llinfo -link -static -iface vio0
> | !route add -inet default 172.31.1.1
> | 
> | https://www.openbsd.org/faq/upgrade63.html :
> | 
> | "... If you need the old style stateless address calculated from the
> | layer 2 address (i.e. ethernet mac address) put -soii into the
> | /etc/hostname.if file. ..."
> 
> soii is for stateless autoconfigured (SLAAC) setups.  Since you're
> using a static address, then only the link local address is using
> soii.
> 
> I just configured a vmm vm with a static v6 address (I default to
> SLAAC (SOII addresses), they work great), and everything works fine.
> Both with a global unicast gateway address and with a link local
> gateway address (i.e. the one with fe80::) set in /etc/mygate.

see "IPv6 broken on Hetzner.de vServer OpenBSD 6.3 / amd64" on bugs@

I'm pretty sure hetzner sets a static route to your link local address for
the /64 they assign to you.

Since the the link local address changes with RFC 7217 you blackhole the /64...

> 
> Cheers,
> 
> Paul 'WEiRD' de Weerd
> 
> -- 
> >[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
>  http://www.weirdnet.nl/ 
> 

-- 
I'm not entirely sure you are real.

Re: httpd / acme-client confusion

[Florian Obser]

this works for me:

server "tlakh.xyz" {
listen on 0.0.0.0 tls port 443
listen on :: tls port 443
tls certificate "/etc/ssl/tlakh.xyz.crt"
tls key "/etc/ssl/private/tlakh.xyz.key"
hsts
location "/shop.6.html" {
block return 402
}
location "/coffee.6.html" {
block return 418
}
location "/.well-known/acme-challenge/*" {
root "/acme"
root strip 2
}
}
server "tlakh.xyz" {
listen on 0.0.0.0 port 80
listen on :: port 80
hsts
block return 302 "https://$HTTP_HOST$REQUEST_URI;
}


On Thu, Mar 15, 2018 at 11:01:42AM +0100, Markus Rosjat wrote:
> Hi there,
> 
> Im kinda confused right now about it. I have a OpenBSD 6.1 running a simple
> httpd.conf with a definition for a http server and a https server
> so far so good, I figured I need to have a http server so acme-client can
> talk to let's encrypt an issue certificate requests also no big problem but
> now it get confusing. I tried to automate the certificate renew and as far
> as I understand the docs httpd.conf get evaluated to to bottom with first
> matching rule found. So this would mean a definition like:
> 
> $ext_addr ="*" # its just one nic with one external ip on that vm
> 
> server "mydomain.tld" {
> listen on $ext_addr port http
> 
> location "/.well-known/acme-challenge/*" {
> root "/acme"
> root strip 2
> directory no auto index
> }
> 
> block return 302 "https://$HTTP_HOST$REQUEST_URI;
> }
> 
> should enable acme-client to renew certificates but redirect other traffic
> to the https server. Well it doesn't ! So I need to comment out the block
> request to renew the certificate. That's a thing I could live with and just
> invent some script that loads a different conf file just for the renew and
> when the certificate is obtained just load the normal httpd.conf and restart
> httpd. I was playing arround and stumbled over the fact that acme-client
> suddenly can renew certificates even without running httpd in the first
> place o.O Thats just wrong since there isn't support that does dns-01
> challenges right? I stoped httpd to checked the site wasn't reachable and
> did a
> 
> acme-client -vvF mydomain.tld
> 
> it gave me a new certificate from let's encrypt ...
> 
> 
> anyway can someone who has the insight please tell me whats goin on here and
> maybe post a config example that works for a basic https redirect? Or is it
> really the case that I need to load a config that hasn't a blok return
> statement in the http server definition?
> 
> One last note, I did a syspatch today and don't know if this changed
> something in the behaviour of the components involved.
> 
> regards
> 
> -- 
> Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de
> 
> G+H Webservice GbR Gorzolla, Herrmann
> Königsbrücker Str. 70, 01099 Dresden
> 
> http://www.ghweb.de
> fon: +49 351 8107220   fax: +49 351 8107227
> 
> Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you
> print it, think about your responsibility and commitment to the ENVIRONMENT
> 

-- 
I'm not entirely sure you are real.

Re: Wondering if any of my hardware is working on -current

[Florian Obser]

On Wed, Feb 07, 2018 at 09:03:09PM -0800, Chris Bennett wrote:
> OpenBSD 6.2 (GENERIC.MP) #2: Sun Dec 10 21:14:42 CET 2017
> 
> r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 3774021632 (3599MB)
> avail mem = 3652612096 (3483MB)

the ram will probably work

-- 
I'm not entirely sure you are real.

Re: Creating your individual git mirrors of OpenBSD

[Florian Obser]

On Wed, Dec 27, 2017 at 11:33:14PM +, Dinesh Thirumurthy wrote:
> Hi,
> 
> If you wanted your personal git mirrors of OpenBSD, then you can do it with:
> 
> https://github.com/hakrtech/repogen/repogen.sh
> 
> This will generate git repos of OpenBSD's source, xenocara, ports and www.
> 
> You can then push src to your git repo hosting box. My test repo from that
> script is:
> 
> https://github.com/hakrtech/openbsd-src0

Can you move this one level down so that you have the *contents* of
src in git, that is skip the src directory, like
https://github.com/openbsd/src does? Then you should arrive at the
same commit ids.

Cheers,
Florian

> 
> If you like git and openbsd sources and live outside USA/Canada, then
> this script will help you avoid cloning from the github.com mirror.
> 
> Refer: https://github.com/hakrtech/openbsd-src0/wiki
> 
> Thanks.
> 
> Regards,
> Dinesh
> 
> PS: I am looking for github.com equivalent outside USA where I can host
> openbsd src. Kindly let me know of any free ones. Thank you.

-- 
I'm not entirely sure you are real.

Re: OpenBSD 6.2 (up2date with syspatch) - HANGING

[Florian Obser]

On Thu, Dec 21, 2017 at 09:20:16PM +, Maxim Bourmistrov wrote:
> 
> I had to bypass relayd to roll prod stable.
> Down to apache. Taking care of http and https.
> By redirect.
> Now this setup (if I can call it) is stable.
> 
> .
> 
> P.S.
> Looks like we have to move forward from here.

Buy an appliance and get off my lawn.

> 
> > 21 dec. 2017 kl. 21:58 skrev Maxim Bourmistrov :
> > 
> > 
> > Sorry, but I have to say
> > Releases after 5.9 are NOT production stable.
> > (Until all bugs are smashed within stack changes and SMP unlock).
> > After 5.9 - cost money and effort.
> > MONEY.


Yes, quite a lot of effort and money (think travel cost to hackathons)
was spent by developers between 5.9 and 6.2 releases.
You are welcome.

-- 
I'm not entirely sure you are real.