Re: httpd(8) - Cross-Origin Resource Sharing (CORS) header

2022-06-26 Thread Stuart Henderson
On 2022-06-27, David Rinehart  wrote:
> Is there a way to add a CORS header to httpd(8) responses for static
> content?

No.

> I see three options:
>     1. Create a diff that adds a server CORS property to httpd.conf(5).
>     2. Create a diff that adds generic header NVPs to httpd.conf(5).
>     3. Create a local patch to hard code the header, along with existing
> headers.
>
> If there is not an existing solution, is there any interest in adding
> the CORS header as a feature of httpd(8)?

2 was rejected before when I suggested using it instead of the dedicated
keywords that are already there for adding HSTS headers, but maybe
things are different now.


-- 
Please keep replies on the mailing list.



Re: network interface becomes inoperable - No buffer space available

2022-06-25 Thread Stuart Henderson
On 2022-06-24, Boyd Stephens  wrote:
> On 6/23/22 05:34, Stuart Henderson wrote:
>> How do the following look?
>> 
>> pfctl -si
>> systat -b mbuf
>> vmstat -m
>> 
>> Comparing normal + failed might be useful too.
>> 
>> Are you using queues in pf?
>> 
>> The ifconfig output you included looks normal. (rxpause/txpause is
>> "has negotiated flow control" and doesn't indicate what flow control
>> is actually blocking)
>> 
>> 
>
> Mr Stuart:
>
> Currently we are not utilizing any queues in pf.
>
> I'm not sure if the telco provider upstream has made some changes but 
> since our reboot 3 days back the system/services have not failed and we 
> have not experienced a another Ofail on the ix0 interface.  When taking 
> a peek via the netstat command the results below are from this am
>
> NameMtu   Network Address  Ipkts IfailOpkts 
> Ofail Coll
> ix0 1500  198.64.189. 198.64.189.20077302398 0 44506063 
> 0 0
>
> Although I have obtained the data that you requested I have not been 
> able to do so while the device is in a failed state due to this being a 
> production machine and our not having experienced another failure since 
> my initial post.
>
> Would you like to still review the data received while the device is 
> working normally?
>
> Thank you much and I will await your feedback.

I doubt there will be many clues while it's working, but it wouldn't hurt
to post them in case anything looks amiss.



Re: No login prompt on console ttyC0 after boot when using "set tty com0"

2022-06-25 Thread Stuart Henderson
On 2022-06-24, Ted Wynnychenko  wrote:
> Hello
> I am leaving the original message intact below.
>
> I did some experimenting, and have found the following.
>
> When there is a boot.conf file present in /etc with only the following:
>> stty com0 115200
>
> Then, the system will boot.  At the INTIAL boot prompt, EITHER tty0 or ttyC0
> will accept input (for example, a simple "enter" to skip the timeout), and
> will start the boot process.
>
> At that point, the serial terminal goes quiet, and boot messages are
> displayed on the ttyC0 monitor.
> At the end, a login prompt appears on BOTH the serial terminal, and on the
> ttyC0 display, and either can be used to login and access the system.
>
> Also, there are no wsconsctl errors generated, and the ttyC0 screen blanks
> after the appropriate time.

So in this case the serial output during boot is only coming from a
serial-port redirector in the bios, the "stty com0 115200" probably
doesn't change anything, and the serial output in multiuser is via
init / /etc/ttys

> Now, if I change boot.conf to direct output to the serial terminal with:
>> stty com0 115200
>> set tty com0
>
> Now, when the system boots, at the INITIAL boot prompt, ONLY the serial
> console (tty0) keyboard input works.  The ttyC0 screen shows a final message
> "switching to com0," but it does not accept any keyboard input.  The serial
> console still works, and the boot messages appear on it.

So far that is expected, OpenBSD doesn't support dual serial+glass console

> Then, the three wsconsctl error messages appear, and it ends with a login
> prompt on the serial console (tty0) ONLY.
> 
> The screen and keyboard for ttyC0 are dead.  There is no login prompt, and
> the keyboard is not functional.

Assuming ttys is setup to run a login on ttyC0 that is not expected

> I can see nothing in the man pages (boot/boot.conf, ttys, termcap, gettytab)
> that would explain this.
> In addition, when I first installed (at 5.6) both the local terminal (ttyC0)
> and the serial terminal (tty0) would present a login prompt.
>
> If there are any ideas about why this is happening, please let me know.

Can you try kernels between known-good and known-bad (or maybe you have
something in /var/log/messages*gz) and look for when this started appearing?

A diff of dmesg between serial and non-serial boots might give some clues

This maybe implicated:

>> vga1 at pci3 dev 3 function 0 "Matrox MGA G200eW" rev 0x0a
>> wsdisplay at vga1 not configured




>> -Original Message-
>> From: Ted Wynnychenko
>> Sent: Thursday, June 23, 2022 5:19 PM
>> To: misc@openbsd.org
>> Subject: No login prompt on console ttyC0 after boot
>> 
>> Hello
>> 
>> I have been following current since 5.6, and had been pretty good about
>> updates until this last year (issues not related).
>> 
>> Anyway, I asked about updating, found some suggestions that it would
>> work,
>> and decided to blaze ahead.  And, it basically worked.
>> I have a few things to clean up, but overall the update to current from
>> my
>> last update in July 2021 went well.
>> 
>> However, in planning for this, I decided to hook up a monitor and
>> keyboard
>> directly, as I have basically just used a serial console ever since I
>> first installed the systems at 5.6.
>> 
>> Unfortunately, I did not look at the monitor before updating to current
>> (OpenBSD 7.1-current (GENERIC.MP) #587: Fri Jun 17 08:49:40 MDT 2022 -
>> full DMESG below), but after the update I found that there is no login
>> prompt on the monitor (ttyC0), and the keyboard does not do anything (I
>> cannot ALT-CTRL-F2 to change to another virtual console.
>> 
>> I don't know when this happened, since I haven't attached a
>> monitor/keyboard in a very long time.
>> But, now that I know, I am trying to fix it, but can't seem to
>> understand
>> why/how to do so.
>> 
>> When the machine boots, the monitor and keyboard work, and I can access
>> the bios pages and make changes.
>> 
>> Then, if I allow the boot to start, I get the "switching to com0"
>> message,
>> and that's it.
>> 
>> When the boot is complete, I can access the system using a serial
>> console
>> (tty00) or ssh, but the direct monitor shows nothing after "switching
>> to
>> com0," and the keyboard does nothing.
>> 
>> The /etc/boot.conf file correctly routes things to the serial console:
>> stty com0 115200
>> set tty com0
>> 
>> I have not changed /etc/ttys in a long time:
>> #
>> #   $OpenBSD: ttys,v 1.2 2008/01/09 17:39:42 miod Exp $
>> #
>> # name  getty   typestatus
>> comments
>> #
>> console "/usr/libexec/getty std.9600"   vt220   off secure
>> ttyC0   "/usr/libexec/getty std.9600"   vt220   on  secure
>> ttyC1   "/usr/libexec/getty std.9600"   vt220   on  secure
>> ttyC2   "/usr/libexec/getty std.9600"   vt220   on  secure
>> ttyC3   "/usr/libexec/getty std.9600"   vt220   on  secure
>> ttyC4   "/usr/libexec/getty std.9600"   vt220   off secure
>> ttyC5   "/usr/libexec/getty std.9600"   vt220 

Re: how to completely reset all networking configuration without rebooting?

2022-06-24 Thread Stuart Henderson
On 2022-06-24, Jonathan Thornburg  wrote:
> In <https://marc.info/?l=openbsd-misc=165579145005202=1>,
> Stuart Henderson  wrote
>> netstart does nothing to clear existing configuration. It wouldn't make
>> sense to do this for joinlist without also e.g. clearing IP addresses
>> from interfaces as needed, resetting media options/MTU/rdomain/VLAN
>> configuration, etc.
>
> So, is there a way to to completely reset all networking configuration
> without rebooting?

Not afaik. (at least not without undoing it manually).




Re: network interface becomes inoperable - No buffer space available

2022-06-23 Thread Stuart Henderson
How do the following look?

pfctl -si
systat -b mbuf
vmstat -m

Comparing normal + failed might be useful too.

Are you using queues in pf?

The ifconfig output you included looks normal. (rxpause/txpause is
"has negotiated flow control" and doesn't indicate what flow control
is actually blocking)


On 2022-06-22, Boyd Stephens  wrote:
> On 6/22/22 03:36, Boyd Stephens wrote:
>> We're current running a 1U platform (dmesg below) that currentl serves 
>> as our network gateway to a 3Gbps fiber based circuit.  After operating 
>> for a number of hours the ix0 device becomes inaccessible and when a 
>> ping/traceroute/... command is attempted from the device through the 
>> external network interface facing the Internet ie ix0 the following 
>> error occurs
>> 
>> # ping 8.8.8.8
>> PING 8.8.8.8 (8.8.8.8): 56 data bytes
>> ping: sendmsg: No buffer space available
>> ping: wrote 8.8.8.8 64 chars, ret=-1
>> ping: sendmsg: No buffer space available
>> ping: wrote 8.8.8.8 64 chars, ret=-1
>> 
>> a netstat -nI for the both ix0(external) and em0(internal) interface 
>> produces the following
>> 
>> Name    Mtu   Network Address  Ipkts Ifail    Opkts 
>> Ofail Colls
>> ix0 1500  198.64.189. 198.64.189.200    24396906 0 13619148 
>> 906752 0
>> 
>> em0 1500  10.10.210/24 10.10.210.50   15138143 0 25142717 
>> 285044 0
>> 
>> Aslo while the servcies are inoperable nestat -m produces the following
>> 
>> $ netstat -m
>> 2544 mbufs in use:
>>      2461 mbufs allocated to data
>>      1 mbuf allocated to packet headers
>>      82 mbufs allocated to socket names and addresses
>> 16/88 mbuf 2048 byte clusters in use (current/peak)
>> 2315/2415 mbuf 2112 byte clusters in use (current/peak)
>> 0/56 mbuf 4096 byte clusters in use (current/peak)
>> 0/32 mbuf 8192 byte clusters in use (current/peak)
>> 0/0 mbuf 9216 byte clusters in use (current/peak)
>> 0/0 mbuf 12288 byte clusters in use (current/peak)
>> 0/0 mbuf 16384 byte clusters in use (current/peak)
>> 0/0 mbuf 65536 byte clusters in use (current/peak)
>> 6476/6476/524288 Kbytes allocated to network (current/peak/max)
>> 0 requests for memory denied
>> 0 requests for memory delayed
>> 0 calls to protocol drain routines
>> 
>> A reboot clears things up and the services will then work for a period 
>> of time.  Although a pfctl -F all( or some derivative of the modifier) 
>> allows the device to once again pass traffic all of its network 
>> functionality does not return in that certain network requests such as 
>> pkg_add are not successfully processed.
>> 
>> While snagging traffic on the ix0 interface while the device in 
>> malfunctioning noticed a response from the one-hop away/default gateway 
>> for the services making an arp request, namely
>> 
>> tcpdump: listening on ix0, link-type EN10MB
>> 20:28:13.811695 arp who-has 198.64.189.200 tell 198.64.189.199
>> 20:28:14.611323 arp who-has 198.64.189.200 tell 198.64.189.199
>> 
>> the following results are produced from
>> 
>> # sysctl | grep buf
>> 
>> kern.msgbufsize=131032
>> kern.malloc.kmemnames=free,,devbuf,,pcb,rtableifaddr,,sysctl,counters,,ioctlops,iov,mount,,NFS_req,NFS_mount,log,vnodes,,UFS_quota,UFS_mount,shm,VM_map,sem,dirhash,ACPI,VM_pmap,file_desc,sigio,proc,subprocMFS_node,,,Export_Host,NFS_srvsock,,NFS_daemon,ip_moptions,in_multi,ether_multi,mrt,ISOFS_mount,ISOFS_node,MSDOSFS_mount,MSDOSFS_fat,MSDOSFS_node,ttys,exec,miscfs_mount,fusefs_mount,pfkey_data,tdb,xform_data,,pagedep,inodedep,newblk,,,indirdep,VM_swap,,UVM_amap,UVM_aobj,,USB,USB_device,USB_HC,witness,memdesc,,,crypto_data,,IPsec_creds,ip6_options,NDP,,,temp,NTFS_mount,NTFS_node,NTFS_fnode,NTFS_dir,NTFS_hash,NTFS_attr,NTFS_data,NTFS_decomp,NTFS_vrun,kqueue,,SYN_cache,UDF_mount,UDF_file_entry,UDF_file_id,,AGP_Memory,DRM
>>  
>> 
>> kern.malloc.kmemstat.devbuf=(inuse = 6179, calls = 7341, memuse = 8537K, 
>> limblocks = 0, maxused = 8602K, limit = 78644K, spare = 0, sizes = 
>> (16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536,131072,262144))
>> kern.bufcachepercent=20
>> kern.consbufsize=16344
>> net.bpf.bufsize=32768
>> net.bpf.maxbufsize=2097152
>> vfs.fuse.fusefs_fbufs_in=0
>> vfs.fuse.fusefs_fbufs_wait=0
>> 
>> We utilize similar platform with similar deployments (1Gbps Internet 
>> circuits) and have not seen this issue previously.
>> 
>> sAny thoughts on the culprit of the buffer exhaustion?
>> 
>> ---
>> Boyd Stephens
>> 
>> 
>> dmesg:
>> 
>> OpenBSD 7.1 (GENERIC.MP) #3: Sun May 15 10:27:01 MDT 2022
>> 
>> r...@syspatch-71-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>>  
>> 
>> real mem = 17058750464 (16268MB)
>> avail mem = 16524451840 (15758MB)
>> random: good seed from bootblocks
>> mpath0 at root
>> scsibus0 at mpath0: 256 targets
>> mainbus0 at root
>> bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x8ec16000 (47 entries)
>> bios0: vendor American Megatrends Inc. version "1.5" date 10/05/2020
>> bios0: Supermicro 

Re: doas hang suddenly

2022-06-22 Thread Stuart Henderson
On 2022-06-22, Siegfried Levin  wrote:
> My server has been running for weeks without an issue. It is running OpenBSD 
> 7.1. However, today I suddenly cannot use doas anymore. It always hang. Has 
> anyone met this issue before?

How does the doas process look in top(1) when it's hanging?

-- 
Please keep replies on the mailing list.



Re: Wireless network interface remembering join list across /etc/netstart.

2022-06-21 Thread Stuart Henderson
On 2022-06-20, Julian Smith  wrote:
> It turned out that i needed to do `ifconfig iwn0 down -joinlist up` to remove
> all networks from the join list, as described in ifconfig(8). [I'm not
> actually sure that the `down` and `up` are necessary.]
>
> Would it be possible and make sense to have /etc/netstart do this
> automatically for wireless interfaces? Or am i misunderstanding what
> /etc/netstart is for?

netstart does nothing to clear existing configuration. It wouldn't make
sense to do this for joinlist without also e.g. clearing IP addresses
from interfaces as needed, resetting media options/MTU/rdomain/VLAN
configuration, etc.




Re: Blocking ping scan

2022-06-18 Thread Stuart Henderson
On 2022-06-18, Janne Johansson  wrote:
> Den lör 18 juni 2022 kl 11:17 skrev Cristian Danila :
>> 09:51:40.913795 arp reply 192.168.121.131 is-at 00:0c:29:c3:d9:a7
>
> arp is done "outside" of pf, that is why you see the arp exchange.
> nmap lists this as "I know things about the hosts" and while it calls
> it a "ping scan", it really hasn't got much in common with icmp pings,
> but rather does an arp request and says that all hosts that respond
> are "up". I'm sure a box can be all kinds of broken and still send out
> arp replies, so you have to adapt your expectations of what "up" means
> here. (first sentence on 'man nmap' on the part where it says what -sn
> does is informative I guess?)
> So while you can see an ethernet device with a mac and an IP does
> exist on the local network, that is all you get.

Additionally if you disallow ARP, IP won't work at all.

You may be able to restrict ARP by using a bridge interface and MAC
address filters but it won't be pretty.




Re: Upgrade from 6.6

2022-06-15 Thread Stuart Henderson
On 2022-06-15, Łukasz Moskała  wrote:
> Maybe it would be possible to update from 6.6 to 6.8 (which is still on 
> mirrors), but I don't know if skipping a release is supported.

It's not supported and I wouldn't expect any help if it goes wrong,
but it often works to jump multiple releases.

However if updating from 6.6 if it used auto partitioning when installed,
there's a good chance that /usr is really too small so for that reason I'd
probably want to do as a new install if possible ...


-- 
Please keep replies on the mailing list.



Re: How to compact partitions (disklabel)?

2022-06-13 Thread Stuart Henderson
On 2022-06-13, Mike Fischer  wrote:
> After solving a recent problem on a VM where the /usr/local was full I was 
> left with a disklabel that had a hole of unused space in it (see below for 
> details). I was wondering if there is a way to compact the partitions, i.e. 
> move the partitions following the deleted one up to fill the hole, 
> potentially leaving corresponding free space at the end.
>
> I’d prefer to not have to use dd(1) on the raw device to move the data? I’d 
> hope for something that is smart enough to adjust the disklabel after moving 
> the bytes. Wishful thinking?

There's no good way to do this. My preference would be to attach a new
virtual disk, partition either manually or according to current auto
defaults for the larger disk, dump|restore and run installboot, then
remove the old virtual disk.

> 16 partitions:
> #size   offset  fstype [fsize bsize   cpg]
>   f:  5056800  8025952  4.2BSD   2048 16384 12960 # /usr

You might find this a little tight too after some updates.

-- 
Please keep replies on the mailing list.



Re: airport(7) and defunct airports

2022-06-10 Thread Stuart Henderson
On 2022-06-10, Moritz Röhrich  wrote:
> In the end I don't think there is a right answer without defining
> what purpose the list should serve. If it's an insider game for the
> devs, documenting all the places where OpenBSD contributors have
> been, removal is completely undesirable.

Yes that is pretty much the current status of the file.




Re: LDIF case sensitivity, login_ldap

2022-06-09 Thread Stuart Henderson
On 2022-06-09, David Diggles  wrote:
> I've just got ldap login working on OpenBSD/7.1 with accounts stored 
> locally in ldapd and using ypldap.
>
> I just thought I'd share something so anyone reading this may save 
> wasting the time that I wasted :-)
>
> Your LDIF entry that you read into ldap must be as follows for 
> userPassword
>
> userPassword: {CRYPT}${ENCRYPTED_PASSWD}
>
> ie uppercase CRYPT - I was stuffing around for ages with trying to 
> understand why login_ldap was failing to bind because I had {crypt} in 
> lowercase.

Perhaps it would make sense for ldapd to support {crypt} as well..

> If you search the interwebs you'll find many complicated examples for 
> the ldap class in login.conf but the following worked fine for this 
> local setup:
>
> # /etc/login.conf.d/ldap
>
> ldap:\
>  :auth=ldap:\
>   :x-ldap-uscope=subtree:\
>  :tc=default:

"auth=ldap" (rather than "auth=-ldap") suggests you're using login_ldap
from the base OS, but that uses /etc/login_ldap.conf for settings so
presence of x-ldap-uscope suggests you're using login_ldap from ports.

The ports version has been left around partly because configuration is
different and it would suck if you can't login to fix it, and partly in
case anyone was actually needing the features that were dropped when it
was rewritten for the base OS.

It would be a good idea to use the base OS version as there's less risk
of it getting out of sync following uodates. And if you used the ports
one and *copied* it over /usr/libexec/auth/login_ldap you definitely
want to fix that.





Re: Dynamic gif Tunnel

2022-06-05 Thread Stuart Henderson
On 2022-06-05, open...@007sascha.de  wrote:
> Hi,
> I would like to build a dynamic gif tunnel and search the "best" and secured 
> concept for that.
> Szenario: HomeRouter with dynamic IP; OpenBSD as Gateway with static IP.
> 6in4 gif tunnel.
> On IP change at HomeRouter, i have to adjust the tunnel Endpoint on the 
> Gateway.
> Concepts:
> 1. To change pf, i can use authpf, but how can i change the tunnel parameter? 
> Second ssh session and doas?
>
> 2. Build a web-API to change tunnel and pf? How, httpd is in chroot.
>
> 3. use a external dyndns Service and work with a cronjob to check for changes 
> on DNS
>
> Any suggestions/recommendation?

Any of those would work. If you want to use a web API you can either
run the cgi/php/whatever script unchrooted, or write to a file under
/var/www which is read by a daemon/cronjob.

You will probably be happier with wg(4) though, for this scenario
with a static IP at one side you don't need to do anything special
to maintain the tunnel, it "just works".and automatically follows
changes of client IP. (I use it to route a /27 from colo to home
which can be used across whatever connectivity I have so it works
over mobile/landline/radio link/whatever).

-- 
Please keep replies on the mailing list.



Re: pkg_add in -current

2022-06-04 Thread Stuart Henderson
On 2022/06/04 15:23, Theo de Raadt wrote:
> Stuart Henderson  wrote:
> 
> > If you are running -current and have not updated base recently, you
> > may run inTO "pkg_add: Unknown option: always-update ".
> > To fix it, just update to a newer base snapshot.
> 
> 
> 
> What happened is that a developer made a change to the pkg tools which
> creates completely incompatible package files.
> 
> Noone knew this was happening beforehands.  An email was circulated
> after-the-fact to ports@ list (which is mostly read by developers, and
> not read by users).  It has now been weeks, and it still hasn't been
> clearly communicated.

People can decide for themselves about that,

First commit enabling parsing in pkg_add
https://github.com/openbsd/src/commit/5cb7aebf4211294fd2891b0bc45c383ab7fd66af

"REMINDER: snapshots go with -current"
https://marc.info/?l=openbsd-ports=165355109123377=2

Second commit, after base is updated with this subsequent package builds
use the new annotation
https://github.com/openbsd/src/commit/c2e596a17ac45689d758df0d67597fef94480ebe

(Then it takes time for new packages to be built on the various archs
and it's not until *then* that errors would show up for people who
haven't updated base yet)



pkg_add in -current

2022-06-04 Thread Stuart Henderson
If you are running -current and have not updated base recently, you
may run inTO "pkg_add: Unknown option: always-update ".
To fix it, just update to a newer base snapshot.




Re: Running multiple instances of pflogd

2022-06-03 Thread Stuart Henderson
On 2022-06-02, Pantelis Roditis  wrote:
> I recently started running multiple pflogd instances and noticed that
> /etc/rc.d/pflogd killed/restarted every running instance.
> The same happened from newsyslog rotations as well.
>
> After suggestions by brynet, sthen and ajacoutot (thank you guys)
> I updated pexp to use a combination of `[running]` and `daemon_flags`
>
> pexp="pflogd: \[running\]${daemon_flags:+ ${daemon_flags}}"
>
> However, the default pflogd does not start with any flags set, so in
> order to make this work I had to either set the flags for pflogd
>
> rcctl set pflogd flags -s 160 -i pflog0 -f /var/log/pflog
>
> or add something like this to /etc/rc.d/pflogd
>
>: ${daemon_flags:="-s 160 -i pflog0 -f /var/log/pflog"}
> pexp="pflogd: \[running\]${daemon_flags:+ ${daemon_flags}}"

hmm, so it constructs the process title based on the variables which are
set, rather than the actual supplied command line.

$ rcctl get pflogd flags
-s 256
$ pgrep -lf pflog
40896 pflogd: [running] -s 256 -i pflog0 -f /var/log/pflog
46762 pflogd: [priv]

That's a bit annoying and will get in the way of fixing this properly.
Maybe we need some changes to how pflogd sets the process title as well.




Re: Running multiple instances of pflogd

2022-06-03 Thread Stuart Henderson
On 2022-06-02, Mike Fischer  wrote:
> I think the issue is more general. It applies whenever multiple
> instances of any service are needed.
>
> I have a similar issue with php_fpm which I am using in multiple PHP
> versions and with different settings (chroot(2) for httpd(8) or without
> chroot(2) for Apache httpd).

With php-fpm it's a bit awkward to handle, because it doesn't include
all the flags in the process name, but just the config filename, so the
rc.d script would need to parse the flags itself, it's possible but it
makes things more complex/fragile.

However there is no problem running instances of different versions
of php-fpm, and the usual way to handle different settings within a version
is to use different config blocks with a single main process, so there
doesn't seem to be much advantage to running separate main processes with
the same PHP version - e.g.

$ cat /etc/php-fpm.conf
[global]
error_log = syslog
syslog.facility = daemon
log_level = notice

[www]
user = www
group = www
listen = /var/www/run/php-fpm.sock
listen.owner = www
listen.group = www
listen.mode = 0660
pm = ondemand
pm.max_children = 20
pm.process_idle_timeout = 30s
chroot = /var/www   
 

[librenms]
user = _librenms
group = _librenms
listen = /var/www/run/php-fpm-lnms.sock
listen.owner = www  
 listen.group = www
listen.mode = 0660
pm = ondemand
pm.max_children = 30
pm.process_idle_timeout = 30s
env[TMP] = /var/www/librenms/tmp
env[TMPDIR] = /var/www/librenms/tmp
; no chroot for librenms

(You can also use "include" files if you want to split up the config rather
than having one big file for complex setups).

...so I'd prefer to keep php-fpm like it is, unless I'm missing some big
benefit of running multiple main processes of the same version. (Big benefit
of running a single version is that you don't need to restart each daemon
separately after updates).

> I some cases the fix may be a more specific pexp. However this
> depends, as you have noted, on what parameters the executable is called
> with and whether they are sufficient to differentiate between the
> running service instances.
>
> In general running multiple instances of the same service does not
> seem to be supported out of the box by OpenBSD and specifically by the
> rc(8) infrastructure. It can be made to work in some cases but it feels
> kind of like a hack.

I think the general case is that this *does* work, but there are some cases
where software resets the process name in an annoying way that prevents it.

I admit copying or symlinking the rc.d files is a bit hackish, especially
for daemons from base (because you need to start the copoes from pkg_scripts)
but OTOH it's simple and works well enough.

>> These changes are only needed for when someone needs to run more than
>> one instance of pflogd, in which case they will have to copy the
>> default /etc/rc.d/pflogd and/or modify it anyways (e.g. for the interface
>> name in rc_pre).
>
> Right! So the choices are:
> 1) Leave /etc/rc.d/ as is, and only run modified duplicates.
> 2) Modify /etc/rc.d/ to ensure a unique pexp when dealing
> with multiple instances, but you still need to create modified
> duplicates for the additional instances.
>
> My choice would be (1). It does not change the things installed by
> the base system or from packages. Whenever something is updated, manual
> checks and potentially adjustments may be required anyway. Seems a bit
> cleaner that way. Less dependencies on the defaults.

I haven't looked closely at tbe rc.d/pflogd change yet but will do so later.

There's another case, where somebody runs two copies of pflogd, one from
the default rc.d script, one standalone by running pflogd directly. So,
it probably would be helpful if the dedault rc.d script was more targetted.




Re: Unbound rc script behavior on 7.1

2022-05-31 Thread Stuart Henderson
On 2022-05-29, Georg Pfuetzenreuter  wrote:
> This is a multi-part message in MIME format.
> --ixL2X1ILWFWJlrgqgqUkZvxl
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 7bit
>
> Hi,
>
> I just installed a fresh copy of OpenBSD 7.1 and copied my working 
> Unbound configuration from a 7.0 install (attached).
> Unbound version on the new system is 1.15.0, on the old one it is 1.13.2.
>
> Upon starting it, I encounter this:
>
> opaon$ doas rcctl enable unbound 
>
> opaon$ doas rcctl start unbound 
>
> unboundb/etc/rc.d/unbound: kill: 3957: No such process 
>
> (timeout)
>
> opaon$ doas rcctl start unbound 
>
> unbound(timeout)
>
> ...
>
> opaon# unbound-checkconf 
>
> unbound-checkconf: no errors in /var/unbound/etc/unbound.conf
>
> opaon# rcctl start unbound
> unbound/etc/rc.d/unbound: kill: 33461: No such process
> (ok)
>
> opaon# ps aux |grep unbound
> _unbound 84446  0.0  2.1 13372 10356 ??  Ic  1:53PM0:00.01 
> unbound -c /var/unbound/etc/unbound.conf

No idea what's wrong, but FWIW I'm not seeing any such problems here on
a few machines, this is expected to work..

What are the contents of /var/run/rc.d/unbound ?




Re: Wireguard IP packets fragmentation issue

2022-05-29 Thread Stuart Henderson
On 2022-05-29, n18fu...@tutanota.com  wrote:
> I saw the recent change in pf.conf.5. Thank you. But I would argue that a 
> person who just wants to set up a VPN can easily overlook the max-mss option. 
> That's why I suggest adding it to examples like this:

Would prefer to have a *short* reference in wg(4) pointing at max-mss in
pf.conf - I'm not convinced someone who overlooks max-mss is particularly
likely to find it buried in the already rather unwieldy EXAMPLES section.

It is very much *not* specific to WireGuard, it is expected that MTU is
reduced in nearly all cases of tunnel protocol.

BTW manpages start a new sentence on a new line.




Re: Cannot configure wi-fi card

2022-05-28 Thread Stuart Henderson
On 2022-05-28, Peter Nicolai Mathias Hansteen  wrote:
> --Apple-Mail=_2B4B5EC6-B0C2-4A8D-9201-FCBDE33C5566
> Content-Transfer-Encoding: 8bit
> Content-Type: text/plain;
>   charset=utf-8
>
>
>
>> 28. mai 2022 kl. 04:25 skrev Matsuda Kenji :
>> 
>> Hello.
>> 
>> I just installed OpenBSD 7.1 and am having trouble
>> setting up a wi-fi card.
>> There is no wi-fi interface in ifconfig output.
>> Dmesg says that there is some error configuring NIC:
>>  iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless-AC 9260"\
>>   rev 0x29, msix
>>  iwm0: Failed to wake up the nic.
>
> Some laptops have a physical switch, sometimes implemented as a Fn-function 
> key combo to enable or disable the wifi (think airplane mode). Could that be 
> what you are seeing here?

This isn't a laptop:

bios0: ASRock Z390 Pro4

It may be worth looking in the BIOS for options to do with PCIE ASPM.

Somebody who knows more than me might find something useful in one
of the files included in the template generated by "sendbug" when run
as root..





Re: spamd on VirtualBox vm - rdr-to rules not working as expected

2022-05-27 Thread Stuart Henderson
On 2022-05-27, Arete  wrote:
> I’m setting up spamd in front of a Postfix mail server, and am having
> an issue with rdr-to rules not working the way I expect.
>
> My setup: Re-purposed Mac Mini running MacOS 12.4 Monterey, Postfix &
> Dovecot, smtp port-forwarded to this box from my firewall. OpenBSD 7.1
> running in a VirtualBox machine on the same Mac Mini, with bridged
> networking enabled.
>
> Postfix on the Mac Mini can receive mail just fine from the internet
> through the firewall. The mini has the IP address 192.168.20.15.
> OpenBSD is configured and running with spamd (greylisting enabled) in
> the VM, with IP address 192.168.20.16 - pf.conf rules as follows:

So if I understand correctly you have

internet -> firewall -> 192.168.20.0/24

and in 192.168.20.0/24 you have

- firewall
- vm running spamd 
- machine running postfix

incoming packet flow is internet -> firewall -> spamd -> postfix, but
as the source address is unchanged by rdr-to, return packet flow is
postfix -> firewall -> internet, bypassing the spamd vm, so there is
nothing to "untranslate" the rdr-to.

The classic spamd setup is where it's run on a firewall which is set as
default gateway on the mail server. Alternatively it also works where the
mail daemon is running directly on the machine running spamd.

To run the mail daemon on another machine in the same subnet _alongside_
spamd, you need to provide a way to get the return packets back through
the spamd machine; if the mail server was running OoenBSD you could
probably do this with "pass in quick from !192.168.20.0/24 to port
smtp reply-to 192.168.20.16". There might be a way to do this with the
version of PF in MacOS but I couldn't say how.

To be honest what I would do in your situation is forget about spamd.
You could use postfix with postscreen and enable "after-greeting" tests,
which means that an unknown client must attempt a connection, get a
temporary failure, and reconnect (which it can do straight away)
before being able to send mail. Or you could use explicit greylisting
software (e.g. postgrey, policyd) or spam-filtering software that can
also do greylisting (rspamd can do this and is typically configured
to skip greylisting on mail with a low spam-score, which significantly
reduces the negative impact of greylisting).


-- 
Please keep replies on the mailing list.



Re: mutt fetch-mail ssl error

2022-05-25 Thread Stuart Henderson
On 2022-05-22, Avon Robertson  wrote:
> The libcrypto build and install as outlined above by Theo was completed
> without error a few minutes ago on the Dell M6600. It was then rebooted
> and mutt's G command was invoked to fetch mail from pop3.xtra.co.nz.
>
> Sadly the attempt failed and mutt's error-history command displayed the
> same error as above.

I've just tested with the current snapshot:

$ TZ=UTC ls -l /usr/lib/libssl.so.52.0 /usr/local/bin/mutt
-r--r--r--  1 root  bin  1509824 May 25 06:51 /usr/lib/libssl.so.52.0
-rwxr-xr-x  1 root  bin  1318616 May 24 02:11 /usr/local/bin/mutt

Testing with pop3.xtra.co.nz, I don't have an account but a bogus
username is good enough to check that TLS works, so I added this to
the default muttrc

set pop_host=pops://t...@pop3.xtra.co.nz/

Run mutt and press G - no TLS failure.




Re: gpt+uefi boot+openbsd+linux

2022-05-25 Thread Stuart Henderson
On 2022-05-24, Nick Holland  wrote:
> On 5/24/22 6:28 PM, Gustavo Rios wrote:
>> May some one here suggest a documentation the explains this scenario ? I am
>> in needof this.
>> 
>> Thanks in advance!
>
> I've actually been experimenting with the UEFI OpenBSD and Windows combo,
> though I suspect it is applicable to Linux, as well.
>
> Warning: I'm trying to avoid GRUB as my boot selector.  UEFI is supposed
> to be able to do this for us.  So I would rather just use it.  I don't
> trust grub to do anything other than Windows and Linux (which is just
> Windows re-invented badly).
>
> Short version: wow...there's a lot variety out there on machines.  If you
> want one answer for all hardware, that's not gonna happen. :-/
> That's about the only certainty I have at this point.  Many UEFI systems
> are only designed to boot Windows it seems, the idea of multiple OSs on
> one disk didn't occur to some people..

rEFInd works pretty well - it's just a boot manager and still uses the
standard OS boot loader to boot the kernel. I didn't like the icons so set
it to "textonly", with it set to autoboot OpenBSD after a short timeout,
which I found much more convenient than the built-in boot manager on the
machine I wanted to dual-boot. Good information about the EFI boot process
(and especially about CSM) on the website - https://www.rodsbooks.com/refind/




Re: documentation

2022-05-24 Thread Stuart Henderson
On 2022-05-24, Nathaniel Nigro  wrote:
> any of the ftp mirrors with the "doc" directory should have historical
> versions txt and pdf  of the faq and the pf guide

Those files are nearly 10 years out of date.


-- 
Please keep replies on the mailing list.



Re: booting OpenBSD on Raspberry pi4 without using sdcard for UEFI

2022-05-22 Thread Stuart Henderson

It also mentions how to put console on the framebuffer.

--
 Sent from a phone, apologies for poor formatting.

On 22 May 2022 16:33:53 Sandeep Gupta  wrote:

Yes, the document does mention:
- standard miniroot supports boot without additional firmware
- by default, the kernel output is on console



On Sat, May 21, 2022 at 2:53 PM Stuart Henderson 
 wrote:

On 2022-05-20, Sandeep Gupta  wrote:

Hello,

 This post here (
http://matecha.net/posts/openbsd-on-pi-4-with-full-disk-encryption/) claims
its possible to
boot OpenBSD directly from USB without the need for UEFI on sdcard.
I tried today but couldn't get it to work. I got a blank screen during the
installation process. What I did was
1) updated the eeprom (bootloader)
2) set boot to usb
3) wrote install71.img onto ssd.

The boot process did start but I got a blank screen. I was wondering if
anyone has tried and has had success with booting
OpenBSD directly from USB.


See "ibstall on Raspberry Pi" in the INSTALL.arm64 file.

--
Please keep replies on the mailing list.




Re: booting OpenBSD on Raspberry pi4 without using sdcard for UEFI

2022-05-21 Thread Stuart Henderson
On 2022-05-20, Sandeep Gupta  wrote:
> Hello,
>
>  This post here (
> http://matecha.net/posts/openbsd-on-pi-4-with-full-disk-encryption/) claims
> its possible to
> boot OpenBSD directly from USB without the need for UEFI on sdcard.
> I tried today but couldn't get it to work. I got a blank screen during the
> installation process. What I did was
> 1) updated the eeprom (bootloader)
> 2) set boot to usb
> 3) wrote install71.img onto ssd.
>
> The boot process did start but I got a blank screen. I was wondering if
> anyone has tried and has had success with booting
> OpenBSD directly from USB.

See "ibstall on Raspberry Pi" in the INSTALL.arm64 file.

-- 
Please keep replies on the mailing list.



Re: mutt fetch-mail ssl error

2022-05-20 Thread Stuart Henderson
On 2022/05/20 22:18, Avon Robertson wrote:
> Thank you for your response Stuart. Alas your suggestion to try the
> binary from the working host does not work. I have pasted a log of my
> actions below. I will try Theo's fix tomorrow.

Hopefully there will be a snapshot by then so you can just update to it -
given the tests you've done thus far, it's clearly due to a change in
libressl, and testing with nc shows that it's not a general problem rather
something with how mutt interface with it, so there's a good chance that
will fix the issue.

> $ fgrep -e 995 ~/.muttrc
> set pop_host="pops://avo...@pop3.xtra.co.nz:995"
> 
> $ nc -vvc pop3.xtra.co.nz 995
> Connection to pop3.xtra.co.nz (210.55.143.37) 995 port [tcp/pop3s]
> succeeded!
> TLS handshake negotiated TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384 with host
> pop3.xtra.co.nz
> Peer name: pop3.xtra.co.nz
> Subject: /C=NZ/L=Auckland/O=Spark New Zealand Limited/OU=Spark
> Connect/CN=pop3.xtra.co.nz
> Issuer: /C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c)
> 2012 Entrust, Inc. - for authorized use only/CN=Entrust Certification
> Authority - L1K
> Valid From: Thu Jul 22 12:41:29 2021
> Valid Until: Wed Aug 17 12:41:29 2022
> Cert Hash:
> SHA256:ec5b8868a45006e3b185fe01a918b88598d5ac113822985a988c64fb395537ca
> OCSP URL: http://ocsp.entrust.net
> +OK pop3.xtra.co.nz POP3 server ready
> ^C
> 
> On working mail host:
> $ rsync -v /usr/local/bin/mutt errhost.xyz.abcd:/home/aer
> 
> On errhost:
> # chown root:bin /home/aer/mutt
> $ cd
> $ ./mutt
> 
> Does not work and mutt's error-history command reports the same error.
> 
> Regards
> -- 
> aer
> 



Re: mutt fetch-mail ssl error

2022-05-20 Thread Stuart Henderson
On 2022-05-20, Avon Robertson  wrote:
> I have been unable to fetch mail with mutt on this host using either the
> currently installed snapshot and mutt package, or the snapshot and mutt
> package that had been installed 2-3 days previously.
>
> I have been able to send mail using mutt in conjuction with msmtp from
> this host.
>
> mutt's error-history command displays
>
> Reading /home/aer/var/mail/inbox...
> Reading /home/aer/var/mail/inbox... 0
> Looking up pop3.xtra.co.nz...
> Connecting to pop3.xtra.co.nz...
> SSL failed: error:14007086:SSL routines:CONNECT_CR_CERT:certificate
> +verify failed
> Error connecting to server: pop3.xtra.co.nz

I assume this is pop3s on port 995?
What do you get from "nc -vvc pop3.xtra.co.nz 995"?

> The below snapshot was installed yesterday and all packages were updated
> immediately afterwards such that mutt's version is now 2.2.5.
>
> kern.version=OpenBSD 7.1-current (GENERIC.MP) #533: Thu May 19 07:38:57 MDT 
> 2022
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> Another amd64 host that I have with OpenBSD 7.1 (GENERIC.MP) #454 and
> mutt 2.2.2 installed, fetches and sends mail without error using the
> same set of mutt configuration files.

Try copying the mutt binary from the working system (don't overwrite the file
from the installed package, just put it in ~ and run it from there) - does that
work or not?




Re: best place to put export variables

2022-05-19 Thread Stuart Henderson
On 2022-05-18, Michael  wrote:
> On 05/19/22 01:44AM, Mihai Popescu wrote:
>> Hello,
>> 
>> I want to export XDG_CACHE_HOME variable used by Xorg.
>> What is the best place (file or ?) to export this variable?
>> 
>> I remember i used some file to export a long time ago PS1 variable.
>> Should I use ~/.login file or is it a better way to export this xorg 
>> variable?
>> 
>> OpenBSD amd64 here, snapshots install.
>> 
>> Thank you.
>> 
>
> Non-expert answer here, but I recently was trying various places to get
> the following working:
>
> export QT_QPA_PLATFORMTHEME=qt5ct
>
> Everywhere online (Linux users mainly) were saying to put it in
> .profile, which did not work on OpenBSD.  What ended up working for me
> is putting it in .xsession.  So I assume that is a good place for any
> export command like this.

.xsession is not a bad place for things relating to a single user in X.
For a more global thing, environment variables can be set in login.conf,
independent of shells etc.




Re: calling all PFsync users for experience, gotchas, feedback, tips and tricks

2022-05-19 Thread Stuart Henderson
On 2022-05-19, Jordan Geoghegan  wrote:
> I've run pfsync + CARP for a number of years now. One interesting 
> "gotcha" I discovered when building an IPv6-only test network was that 
> pfsync does not work in an IPv6-only environment. I tried both unicast 
> and multicast configurations to no avail. When pfsync has a parent 
> interface that only has an IPv6 address assigned (ie no IPv4 at all), no 
> pfsync traffic transits the interface. Just thought I'd share this 
> little tidbit since you were looking for edge cases and gotchas and 
> since IPv6 support (or lack thereof) is not mentioned in the manpage.

That sounds like a bug not an "edge case". To my knowledge nobody ever
reported that, consider writing it up for bugs@.




Re: kernel fault after 7.1

2022-05-17 Thread Stuart Henderson
On 2022/05/18 01:40, Vitaliy Makkoveev wrote:
> > On 18 May 2022, at 01:18, Stuart Henderson  
> > wrote:
> > 
> > On 2022-05-17, kasak  wrote:
> >> Can I somehow revert kernel to 7.1-release, to make syspatch working?
> > 
> > Boot bsd.rd and do an 'upgrade' install to 7.1 again. (You can also do
> > this with sysupgrade if you modify the script).
> > 
> > 
> 
> 
> Or just download bsd.mp kernel from [1], check it with signify(1) and
> reboot. 
> 
> 1. https://ftp.openbsd.org/pub/OpenBSD/7.1/amd64/

Doing an 'upgrade' also cleans out any syspatches that were applied
before updating the kernel to -stable and gets things into more of
a known state (that's why I suggested doing it, even though it's a
bit more awkward)



Re: kernel fault after 7.1

2022-05-17 Thread Stuart Henderson
On 2022-05-17, kasak  wrote:
> Can I somehow revert kernel to 7.1-release, to make syspatch working?

Boot bsd.rd and do an 'upgrade' install to 7.1 again. (You can also do
this with sysupgrade if you modify the script).




Re: Historical Reasons For Default NAT Source Port Modification

2022-05-16 Thread Stuart Henderson
On 2022-05-16, Alexander Bochmann  wrote:
> Hi,
>
> ...on 2022-05-16 13:23:31, Philipp Buehler wrote:
>
> > I cannot recall many applications from 20y ago that have been very keen
> > on sending from certain ports (besides IKE already mentioned by JJ).
>
> I seem to remember firewall rules that allowed only udp/53 as _source_ port 
> for DNS traffic.
>
> Might have been more than 20 years ago.

Such rules often existed to cover replies, before the days
of stateful firewalls.




Re: Wireguard IP packets fragmentation issue

2022-05-15 Thread Stuart Henderson
On 2022-05-15, Tom Smyth  wrote:
> Hi Stuart,
> I have huge regard for you and all you contribute to OpenBSD and the community
> Im going to clarify what I meant and what my experience with PMTU and
> constrained MTUs behind
> NAT,
> My humble  experience is that if we have a constrained MTU behind a NAT
> Path MTU discovery from the server to the client  fails because
>
> [website]--- public IP MTU 1500 bytes --[firewall/Nat]
> private network MTU 1492 bytes-client
>
> so while MTU discovery may work outbound...(from client to the website)
>  the public website to the public IP has  no way to discover the
> constrained PMTU behind the nat...

There's no reason for this to fail? 1500 byte packet with DF set hits
the firewall/nat box, route lookup, exit MTU is 1492, too big -> surely
it just sends back frag needed?

Even if you have a nat device with 1500 exit mtu and it then hits 1492
mtu on another device, similar case but the original frag-needed is
sourced from a private address so it gets natted on the way out.

There could be some specific cases where things aren't setup to allow
this to work but there's nothing in general to cause it to fail.

The problem case is when you have router hops on private addresses
where there is *no* nat in the path in which case icmp is generated
from the private address but there's nithing ti translate it, so that
case you do often lose the message due to "no martian" packet filtering.

> This corner case was discovered when I setup My ISP initially and I
> had not many IP addresses many moons ago
> It would be rare for a client behind a NAT to have a smaller MTU than
> their  public IP internet connection.
>
> Is my reasoning and analysis here correct ?
>
>
> Regarding my comment
>> PMTU cannot properly account for underlay restrictions Inside a VPN
>
> what I meant was, that if you set an  MTU of 1500 on a VPN Tunnel interface
> but in sending 1500 Bytes in an IP packet across the tunnel it
> requires a the VPN encapsulated Packet + a Fragment Packet to be sent
> also, (on the underlay interface)
> the Router on the VPN wont sent a Fragment needed IP message  to the
> client because the MTU of the Tunnel was not exceeded
> (but the MTU on the underlay was exceeded)

This depends on the MTU stored in the route table entry used to send
the packet over the vpn.

With a separate tunnel interface the mtu on that interface and thus the
route table can be set low enough that frag needed is sent.

With standard flow-based IPsec the route used is normally the default
route with either a standard ethernet MTU or a pppoe MTU. But if there's
another route (route-based IPsec on OS which have this, or a dummyinterface 
such as is sometines used in combo with flow-based IPsec,
for example a vether interface with a netmask that covers the "other
side" of the IPsec tunnel as defined in the flow) with a lower MTU set
on that interface, when the packet is attempted to be transmitted it
will again see the lower MTU via the route table and be able to send
frag-needed.

It's easy to hit the blackhole case with IPsec tunnels *but* also often
not so hard to avoid it.

My preference is to try and set things up as much as possible so that
you don't get PMTU blackholes or have to fragment the tunnel packet,
but also clamp mss so that even if you do hit a blackhole there's no problem.
There are some downsides to clamping MSS but they're relatively small
and it's something done by almost every off-the-shelf home CPE so it's
very very xommon on the internet.


> I hope the clarifications helps  and that im right or at least that I
> learn something new :)
> Thanks
> Tom Smyth
>
>
>
>
>
>
>
>
> On Sun, 15 May 2022 at 19:37, Stuart Henderson
> wrote:
>>
>> On 2022-05-15, Tom Smyth  wrote:
>> > IP fragments on internet are avoided generally through PMTU discovery (mtu 
>> > path
>> > discovery) but
>> > PMTU does not work beyond a Nat (if a smaller MTU interface exists
>> > behind a NAT then the smaller
>> > MTU will not be discovered.
>>
>> That's not right, NAT doesn't break PMTU detection.
>>
>> > PMTU cannot properly account for underlay restrictions Inside a VPN
>>
>> Depends on the VPN type. For VPNs using a tunnel device (openvpn,
>> WireGuard, gif/gre/l2tp etc, maybe route-based IPsec) then PMTU works
>> like it would on another network type. Not nornally for flow-based IPsec
>> though as the MTU is taken from the route (but it can be made to work
>> with a dummy interface covering the VPN range with a lower MTU set in
>> it).
>>
>>
>
>


-- 
Please keep replies on the mailing list.



Re: Wireguard IP packets fragmentation issue

2022-05-15 Thread Stuart Henderson
On 2022-05-15, Tom Smyth  wrote:
> IP fragments on internet are avoided generally through PMTU discovery (mtu 
> path
> discovery) but
> PMTU does not work beyond a Nat (if a smaller MTU interface exists
> behind a NAT then the smaller
> MTU will not be discovered.

That's not right, NAT doesn't break PMTU detection.

> PMTU cannot properly account for underlay restrictions Inside a VPN

Depends on the VPN type. For VPNs using a tunnel device (openvpn,
WireGuard, gif/gre/l2tp etc, maybe route-based IPsec) then PMTU works
like it would on another network type. Not nornally for flow-based IPsec
though as the MTU is taken from the route (but it can be made to work
with a dummy interface covering the VPN range with a lower MTU set in
it).




Re: Wireguard IP packets fragmentation issue

2022-05-15 Thread Stuart Henderson
On 2022-05-15, Theo de Raadt  wrote:
>  .Bd -literal -offset indent
> -inet 0.0.0.0 255.255.255.255 NONE \e
> +inet 0.0.0.0 255.255.255.255 0.0.0.1 \e
> pppoedev em0 authproto pap \e
> authname 'testcaller' authkey 'donttell' up
> -dest 0.0.0.1
>  inet6 eui64
>
> I don't think this is the right way to go.  Yes, on p2p links the
> broadcast address is reused as destination by internal kernel logic,
> but I don't think anyone is helped by hiding the configuration of this
> in such a way.

The other way, setting dest *after* the interface is brought up, is wrong.




Re: Wireguard IP packets fragmentation issue

2022-05-15 Thread Stuart Henderson
On 2022-05-15, Jason McIntyre  wrote:
> On Sat, May 14, 2022 at 09:14:36PM -0000, Stuart Henderson wrote:
>> On 2022-05-14, Georg Pfuetzenreuter  wrote:
>> > pppoe(4) already has a section on this, possibly this could be used as a 
>> > start.
>> 
>> It's not a great start really. Mixes up information about a method to
>> set the pppoe MTU to 1500 (RFC4638) and using scrub, doesn't describe
>> the problem (says "causing conflict" but this isn't very meaningful
>> or really correct), and points at nonexistent "more information on MTU,
>> MSS and NAT" as this isn't in pf.conf(5).
>> 
>> 
>
> hi.
>
> if there are issues in that text, feel free to suggest how to improve
> it.
>
> - mixing mtu to 1500 and scrub: well, both concern issues with mtu. why
>   wouldn;t they be together in there?

They're related but one is for avoiding the problem in the first place
(which may or may not work, depending on the ISP and backhaul network)
and the other is working around problems encountered (due to
misconfiguration of other people's networks) as a result.

Putting them together in one large section isn't so bad for pppoe, though
it already feels like it makes it harder to distinguish the two, but in
the context of using this as a base for text relating to other interface
types then the RFC 4638 bits aren't relevant at all there.

> - "causing conflict": feel free to be more specific. it's not something
>   i have knowledge of

outline:

- client <> router is on ethernet and can pass packets of 1500 bytes
(or even larger)

- router <> "the internet" can sometimes carry 1500 byte packets but
via certain types of connection can only pass packets of a smaller size,
e.g. 1492 bytes with standard pppoe, some ISPs have tougher restrictions
(either outright, or "work but don't work _well_" if you go above some
other size)

- router <> "sites accessed by tunnel/vpn over the internet" has an
extra header inserted in packets, further reducing the available size
for packets (usually 1420 bytes for wg(4) though can be less if
it's carried over a more restrictive internet connection than usual,
other sizes for other types of tunnel/vpn)

- website (or other host "on the internet") <> "the internet" can
typically send packets of 1500 bytes

so the two endpoints of a TCP connection (say, client and website)
can send 1500 byte packets to their immediate upstream. but the path
between them (router/ISP/internet/vpn/whatever) can only carry smaller
packets.

clear so far?

the size of packets which can be carried on a particular network
interface is "the MTU" of that interface. this defaults to the hardware
capable size or 1500 whichever is less.

for TCP packets there is a negotiation at connection setup between the
two sides. they look at the MTU of the route to reach the other address
which defaults to that of the network interface used to reach it.
subtract the TCP header size, and call that MSS "maximum segment
size". they tell the other side their idea of MSS (in the TCP SYN
packet) and the lowest of the two is used for the connection
(so packets are capped at that size).

this is fine where the whole path can cope with the same sized packets,
but if not then a router on the path must either split it into fragments
(much slower than simply forwarding it, involving use of the router cpu
which is usually fairly weedy) or send a "fragmentation needed" ICMP
message and rely on the other side to do it. (the common case is for
TCP connections to be generated with packets flagged as "don't fragment"
because the endpoints want to know about the issue so they can adapt
to it).

in the best case, the relevant endpoint (e.g. client or website)
receives that message and acts on it by reducing the size of packets
it then transmits. there's still some overhead from detecting the
oversized packet and reacting to it but things "work".

in the worst case, those packets don't reach the relevant endpoint.
(various possible reasons. maybe a misconfigured firewall blocks all
ICMP. maybe there's some link numbered on private addresses in the
network path and the frag-needed message was sent from a private
address and blocked by a firewall. maybe some loadbalancing or
queueing or icmp-packets-per-second limit got in the way. lots of
options).

so in that case the endpoint sending the oversize packet doesn't
know it must reduce packet size, and the packet doesn't make it
through.

(it's actually worse with a standard IPsec tunnel because the MTU is
that of the interface carrying the network route, usually the default
route, so in that case it also affects connections where the VPN is
run directly on an endpoint, not just where the VPN is handled on a
separate router).

anyway. when a rule with &

Re: Cron running at 99% CPU for seemingly no reason

2022-05-15 Thread Stuart Henderson
On 2022-05-15, Stephan Mending  wrote:
> Especially the line stating "the kernel did not panic" surprises me, as I am 
> greeted by the kernel debugger. Not sure how to interpret that.

ddb is entered for panics (which are explicit calls from kernel
code) and for other exceptions (which are not) - only the former
have anything to show in "show panic".

To catch the reason for entering ddb in the latter case, either
leave serial console connected and logged, or type "dmesg" _in ddb_
which should also show it at the bottom.

You will likely get a better trace from ddb if you boot a kernel
with debug symbols. Build a kernel from source yourself and you'll have
"bsd.gdb" in the obj directory - either copy that to /bsd, or copy it to
/bsd.gdb and type "boot bsd.gdb" in the boot loader .




Re: Wireguard IP packets fragmentation issue

2022-05-14 Thread Stuart Henderson
On 2022-05-14, Georg Pfuetzenreuter  wrote:
> pppoe(4) already has a section on this, possibly this could be used as a 
> start.

It's not a great start really. Mixes up information about a method to
set the pppoe MTU to 1500 (RFC4638) and using scrub, doesn't describe
the problem (says "causing conflict" but this isn't very meaningful
or really correct), and points at nonexistent "more information on MTU,
MSS and NAT" as this isn't in pf.conf(5).




Re: Wireguard IP packets fragmentation issue

2022-05-14 Thread Stuart Henderson
On 2022-05-14, n18fu...@tutanota.com  wrote:
>> I recommend "max-mss" instead of no-df, you don't really want fragments
>> if you can help it. The number to cap at is 40 below the lowest actual
>> MTU across the tunnel, so 1380 should do for WireGuard, IPsec varies
>> depending on the options used.
>
> Thank you Stuart and William for your replies. I really like the idea of 
> setting "max-mss" and I can confirm that after changing my pf.conf like this:
>
> match out on egress from (wg0:network) nat-to (egress:0) scrub (max-mss 1380)
>
> I did not notice any network-related problems.
>
> I'm pretty sure this needs to be in the documentation. I think we need to add 
> a subsection about Wireguard setup into Networking section in the FAQ.

It isn't just WireGuard, it is common to...well, everything.

gif
gre
vxlan
eoip
etherip
ipsec
wg
pppoe
tun/tap (which would be configured by some other software)

and _any_ standard network interface if a packet is forwarded
between interfaces with a lower and a higher mtu

Perhaps adding a bit more to the description in pf.conf(5) would
be a good start, explaining why one might want to use it..




Re: Wireguard IP packets fragmentation issue

2022-05-14 Thread Stuart Henderson
On 2022-05-14, William Ahern  wrote:
> On Fri, May 13, 2022 at 11:10:41PM +0200, n18fu...@tutanota.com wrote:
>> Hi,
>> 
>> I've set up an OpenBSD server on the Cloud, set up a Wireguard tunnel, and
>> configured default route through that server. I've noticed that I can't
>> access some websites: my browser was not able to complete TLS handshakes
>> with some servers. I've traced the issue to the fact that the MTU on my
>> server's network interface is 1500 while the default MTU on a wg0
>> interface is 1420. So when a large enough packet has a DF flag set it
>> would not make it through the smaller wg0 interface. I've fixed the
>> problem by adding a "scrub" option to server's pf.conf like this:
>> 
>>   match out on egress from (wg0:network) nat-to (egress:0) scrub (no-df 
>> random-id)
>> 
>> But I'm surprised that I did not see anyone mentioning this problem. I
>> also did not see that "scrub" option included in any examples of Wireguard
>> setup that I was able to find.

>> I'm not a networking expert, so I wonder if using a "scrub" option like
>> that is a good idea.
>
> Seems like ICMP responses are being dropped. In such cases the proper
> solution is fix whatever is filtering out ICMP responses.

It is most likely some firewall close to the website, you need to
deal with the fact that this happens because it's quite common on the
internet.

> However, according to
> https://github.com/QubesOS/qubes-issues/issues/5264#issuecomment-683177300
> Wireguard deliberately drops ICMP responses to its UDP transport packets. If
> this is the case in your situation, the better solution might be to drop the
> MTU on the Wireguard interfaces so oversized packets are rejected before
> they're encapsulated. A common fail-safe MTU for VPN interfaces is 1300 or
> 1280.

Problem will be with the decapsulated packets on the path between the
wg endpoint and the webserver. (Very unlikely to be elsewhere as PF
automatically permits relevant ICMP messages as part of the state for a
TCP connection).


> Another alternative might be to switch to IPSec+IKEv2. If there's no NAT
> between your tunnel endpoints, it won't need to use UDP encapsulation, so
> packet overhead would be smaller. But even with NAT traversal, OpenBSD's
> iked might handle things better (e.g. permitting fragmentation of its UDP
> packet, or mirroring ICMP responses), though I don't know specifically if
> this would the case.

It's a common thing with every protocol which lowers MTU of packets
generated by systems which don't know about the limit (it's well known
for pppoe but affects plenty of other protocols).

Happens with IPsec too.

I recommend "max-mss" instead of no-df, you don't really want fragments
if you can help it. The number to cap at is 40 below the lowest actual
MTU across the tunnel, so 1380 should do for WireGuard, IPsec varies
depending on the options used.

(You _could_ also hit the problem with UDP, but the main place where
people actually hit this was with large EDNS0 buffers, and modern
server software tends to stick to oacket sizes that work across all
non-ridiculous tunnels).


-- 
Please keep replies on the mailing list.



Re: calling all PFsync users for experience, gotchas, feedback, tips and tricks

2022-05-13 Thread Stuart Henderson
On 2022-05-13, Marko Cupać  wrote:
> The only problem I currently have with pfsync is the fact that it does
> not synchronise queue membership of states.

IIRC this is meant to work but only if you have identical rulesets,
after expanding interface addresses etc. This will require some care in
constructing pf.conf - interface groups instead of interface names if
nic hw is different - "(self)" or list the addresses of both firewalls
instead of using "self" - avoid "antispoof".




Re: A speed test with Iperf , Relayd and PF

2022-05-13 Thread Stuart Henderson
On 2022-05-13, Fabrizio Francione  wrote:
> Code:
> tcp connection fixup {
>    tcp nodelay
> }
> 
> relay IPERF_TEST{
>    listen on 10.10.10.2 port 6740
>    forward to 192.168.20.9 port 6670
>    protocol fixup
> }
> With IPERF I obtain a speed of 144Mbps .

Why use nodelay? That disables Nagle and is normally only wanted for 
interactive protocols like SSH. High chance that will be slowing
things down.

https://en.m.wikipedia.org/wiki/Nagle%27s_algorithm 

> If instead, I deactivate the relayd function and using a simple PF
> redirecting with
>
> Code:
>
> pass in on em0 proto {tcp} from any to em0 port 6740 rdr-to 192.168.20.9
> port 6670
>
> I obtain a speed of 892 Mbps.

rdr-to and relayd TCP proxies are totally different things.


-- 
Please keep replies on the mailing list.



Re: Setting up vmd with veb0/vport0

2022-05-12 Thread Stuart Henderson
On 2022-05-12, David Demelier  wrote:
> (vm) #
> ping 8.8.8.8 
> PING 8.8.8.8 (8.8.8.8): 56 data bytes
> ping: sendmsg: Can't assign requested address
> ping: wrote 8.8.8.8 64 chars, ret=-1
> (vm) #
> # ftp http://5.135.187.121/index.html 
> Trying 5.135.187.121...
> ftp: connect: Can't assign requested address

How do ifconfig -A and netstat -rnfinet look in the vm?

> vlan0: flags=8002 mtu 1500
>   lladdr e0:d4:64:3c:31:9c
>   index 6 priority 0 llprio 3
>   encap: vnetid none parent iwx0 txprio packet rxprio outer
>   groups: vlan
>   media: IEEE802.11 autoselect (VHT-MCS9 mode 11ac)
>   status: active

I think this isn't doing anything, right?

> vport0: flags=8902 mtu 1500
>   lladdr fe:e1:ba:d0:32:b5
>   index 7 priority 0 llprio 3
>   groups: vport
>   inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255

This interface is not "up", iirc you need to do that explicitly
for vport.

Also check you have set sysctl net.inet.ip.forwarding in the host.


-- 
Please keep replies on the mailing list.



Re: OpenBSD ports require xbase set - still true?

2022-05-09 Thread Stuart Henderson
On 2022-05-09, Steffen Nurpmeso  wrote:
> Until now whenever i wanted to do this i had to install xbase,
> otherwise the port makefile complained some.  (I am afraid i have
> forgotten the details.)  Is this still true?

Yes. We don't particularly want to deal with reports of build failures
or worse builds which succeeded but are missing features, from people who
have decided that they don't need to install all sets but e.g. didn't
realise that some non-X software uses freetype or fontconfig (or in the
past before it moved from xbase to base, expat). Having this as an
error certainly seemed to help.




Re: hw.perfpolicy behavior on desktop/server

2022-05-09 Thread Stuart Henderson
On 2022-05-09, Atanas Vladimirov  wrote:
> Hi Guys,
>
> I'm running -current.
> Recently I noticed (not sure when it changed) that my CPU is not 
> throttling anymore. The `hw.perfpolicy` is set to auto and `hw.setperf` 
> is always at 100%. I red that there was a change in 7.1:
>
> - Changed the power management sysctl(8) hw.perfpolicy to "auto" at 
> startup, defaulting to 100% performance with AC power connected and 
> using the auto algorithm when on battery.
>
> So, my question is how I can change that behavior so the throttling is 
> working again?

Currently, you can either set it manually to low speed (hw.perfpolicy=manual,
hw.setperf=0), modify the kernel (e.g. with the diff below), or use obsdfreqd 
from
packages. The latter is only in -current packages not 7.1, but it could be built
from ports.


Index: sched_bsd.c
===
RCS file: /cvs/src/sys/kern/sched_bsd.c,v
retrieving revision 1.70
diff -u -p -r1.70 sched_bsd.c
--- sched_bsd.c 30 Oct 2021 23:24:48 -  1.70
+++ sched_bsd.c 9 May 2022 17:13:10 -
@@ -525,7 +525,6 @@ int perfpolicy = PERFPOL_AUTO;
 
 void setperf_auto(void *);
 struct timeout setperf_to = TIMEOUT_INITIALIZER(setperf_auto, NULL);
-extern int hw_power;
 
 void
 setperf_auto(void *v)
@@ -544,11 +543,6 @@ setperf_auto(void *v)
if (cpu_setperf == NULL)
return;
 
-   if (hw_power) {
-   speedup = 1;
-   goto faster;
-   }
-   
if (!idleticks)
if (!(idleticks = mallocarray(ncpusfound, sizeof(*idleticks),
M_DEVBUF, M_NOWAIT | M_ZERO)))
@@ -583,7 +577,6 @@ setperf_auto(void *v)
downbeats = 5;
 
if (speedup && perflevel != 100) {
-faster:
perflevel = 100;
cpu_setperf(perflevel);
} else if (!speedup && perflevel != 0 && --downbeats <= 0) {




Re: Modern RFC3442 (Classless DHCP Static Routes)

2022-05-09 Thread Stuart Henderson
On 2022-05-09, Stuart Henderson  wrote:
>>>
>>> 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.
>
> It was done to work-around broken clients:
>
> https://github.com/openbsd/src/commit/3f461432d6a77eea41f084ef892403cacc2ee370

...so the correct configuration is clear: list both a 0.0.0.0/0
classless route and "option routers", and it should work for all
cases.




Re: Modern RFC3442 (Classless DHCP Static Routes)

2022-05-09 Thread Stuart Henderson
On 2022-05-06, Florian Obser  wrote:
> 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.

It was done to work-around broken clients:

https://github.com/openbsd/src/commit/3f461432d6a77eea41f084ef892403cacc2ee370




Re: deep packet inspection over no TLS/SSL traffic

2022-05-09 Thread Stuart Henderson
On 2022/05/09 10:46, Riccardo Giuntoli wrote:
> Yes I know. With rdomains and pair it would be nice to write a daemon
> that inspect L7 search for bittorrent identification and take action
> above those packets. 
> Yes. DMCA is a complete overkill. Vultr applies it. When business will

It doesn't make sense though, DMCA relates to hosted content, you aren't
hosting on the VPS though, right? If I understand correctly you just
route through it?

> grow I will host in some data center a pair of servers and do vmd
> machines. But I've got to register for RIPE, get an IPv4 and IPv6
> class, and so on. It's a temporary solution. For now I'm using ndpi on
> linux and changing DSCP.

If you're in Europe, running this service via US-territory VPS seems a
legal minefield and a bad idea both for network performance and privacy
related reasons.



Re: deep packet inspection over no TLS/SSL traffic

2022-05-09 Thread Stuart Henderson
On 2022-05-09, Riccardo Giuntoli  wrote:
> I've found a distfiles on the fr openbsd mirror:
>
> https://ftp.fr.openbsd.org/pub/OpenBSD/distfiles/ndpi-4.2.tar.gz
>
> Someone try it?

This is used by ntopng, we don't have anything to use this to make
packet forwarding decisions (anyway, by the time you have used DPI
to detect the protocol, it is too late to make a decision on packet
routing).

Also, I have found it to be a bit crashy. It's not so bad for ntopng
if you're just using it to identify a network problem etc, but doesn't
seem good as a continuously-running thing.

>> On Sunday, May 8, 2022, Riccardo Giuntoli  wrote:
>>
>> > Hello there, I've got a little wireless service provider where the edge
>> > connect to different VPS providers in many geographic locations. One of
>> > them, based in US, is applying DMCA doing DPI above no encrypted traffic.

This seems complete overkill from the provider, I would replace them.




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

2022-05-06 Thread Stuart Henderson
On 2022-05-04, Theo de Raadt  wrote:
> I have also pointed out a couple of times now that sysclean ignores the
> lessons of "find -print0" and "xargs -0", and I worry it could find a
> file called
>
> "/somewhere/matchingpattern/\n/etc/spwd.db"

Thus is easily fixed by adding a "delete" mode which removes the files
internally in sysclean.




Re: Modern RFC3442 (Classless DHCP Static Routes)

2022-05-06 Thread Stuart Henderson
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.

> What I've seen (and rely on with other OSes) is to honor dhcp routers and 
> option 121.

which OS are explicitly breaking this RFC and how are they doing it? i.e.
what happens if there are conflicting default routes between the two options?

> if the client doesnt like the dhcp routers setting, there is
> option 121.  if the client doesnt like the dhcp routers setting, there is
> usually a flag to ignore that (or the dhcp server can be configured to 
> hand out a lease without a routers option for that client)

the client shouldn't do this, the whole point of DHCP is that it's a protocol
where the network admin sets things up.

> If there is no method to have the client ignore the routers option of the 
> lease, folks who for whatever reason rely on rfc3442 explicit behavior 
> might not like this change - but again, I suspect this is not the right 
> default here and that the rfc3442 has a bit of a glitch

This isn't something that was just forgotten in the RFC, it was explicitly
considered and the authors chose to do it this way and the reviewers agreed.

> (either support 
> handing out the 0.0.0.0 route in option 121 or honor routers and option 
> 121 (and 249, fine, microsoft)... but dont do what it currently spells out 
> and get no default routes when option 121 is in use - thats painful.)

It seems quite clear-cut that the network is misconfigured in this case...

*maybe* there's a case for a "the network admin doesn't know what
they're doing" option to allow getting a default route in this case but
I definitely think it is wrong to change this default behaviour.




Re: OpenBSD ftp and libtls: how to use session resumption with -S

2022-05-06 Thread Stuart Henderson
On 2022-05-06, Theo Buehler  wrote:
> While we could readily make libssl fall back to the legacy stack if
> SSL_OP_NO_TICKET is disabled, I don't think this optimization outweighs
> the overall benefit of TLSv1.3 - better protocol, cleaner code.

Especially when the major beneficiary of this is pkg_add when it
searches for updates; the number of connections has been *hugely*
reduced with the caching added recently.




Re: relayd blocking by IP

2022-05-05 Thread Stuart Henderson
On 2022-05-05, Fabio Martins  wrote:
> On Thursday, May 5, 2022, Marcus MERIGHI  wrote:
>
>> Hello Stuart, Hello Fabio,
>>
>> thanks for reading and suggesting!
>>
>>
>> Exactly, though it is going to be relayd that is listening and
>> forwarding to the application (or not, in case of geoblocking).
>>
>> Marcus
>>
>
> This way you are only blocking per IP, not Host.

not quite, PF is looking up the IP in the table to decide which port
number to use

then the different port number is handled in relayd to pick between
two contexts:

one does not inspect Host (for those requests coming from
addresses on "geoallow")

the other (for all other requests) does inspect Host




Re: Two minor issues with GNOME (autologin/night light)

2022-05-05 Thread Stuart Henderson
On 2022-05-05, David Demelier  wrote:
> 2. The autologin feature does not seem to work. Even though enabled in
> the GNOME users settings and it has edited the /etc/gdm/custom.conf the
> file to add:
>
> AutomaticLoginEnable=True
> AutomaticLogin=markand
>
> It still goes to the GDM login screen on boot.

There's a workaround

TimedLoginEnable=True
TimedLogin=username
TimedLoginDelay=1




Re: relayd blocking by IP

2022-05-04 Thread Stuart Henderson
On 2022-05-04, Marcus MERIGHI  wrote:
> Hello!
>
> I need to block http/s traffic, but only for some Host: header values.
> I.e. domain "xyz.abc" should be reachable, domain "klm.opq" not, both
> behind the same IP.
>
> This rules out blocking with PF. 
>
> I looked at relayd(8)/relayd.conf(5) next. 
> I found "from address[/prefix]" in the "FILTER RULES" section. 
> But relayd.conf(5) does not seem to have a table option for this
> purpose, as pf.conf(5) does.
>
> So it would take one config line per IP or Network; with 
>
> $ wc -l /etc/pf/geoallow
> 20649 /etc/pf/geoallow
>
> this would bloat my relayd.conf quite a bit :-)
>
> Have I missed something in relayd.conf(5)?
> Any other ideas to solve the task?
>
> Thanks in advance for any pointers!

Maybe redirect connections from the PF table to a different port, then
handle the two ports differently in relayd?

-- 
Please keep replies on the mailing list.



Re: rspamd and pyzor

2022-05-03 Thread Stuart Henderson
On 2022-05-03, kasak  wrote:
> rspamd manual assume, that we should use this construction:
>
> ExecStart=/bin/sh -c '/usr/bin/razor-check && /usr/bin/echo -n "spam" || 
> /usr/bin/echo -n "ham"'
>
> The razor-check manual confirm this: "razor-check" terminates with exit 
> value 0 if the signature for the mail is catalogued on the server (spam) 
> or 1 if the mail is not catalogued by the server (not a spam).
>
> I don't like this construction, and can't even imagine that we can do 
> the same with inetd.

> Maybe i should put all this to some script and call it from inetd, but 
> i'm not sure it this a good idea or not.

it may work direct in inetd.conf, but yes that would be neater.
I don't think there's any disadvantage to running it in a shell script
rather than as a "sh -c" construct.

btw keep an eye on how it performs, I haven't used pyzor/razor in a
fairly long time but have used dcc more recently, I found it fairly easy
for some bulk/automated non-spam to get caught up by the checks.
I stopped using it because of this, the biggest problem was mail where
there were a couple of other spam signs (but not enough to trigger
detection by themselves). at least, you really don't want to learn
symbols for Bayesian detection or feed neural network detection from
those mails.




Re: mutt-wizard

2022-05-03 Thread Stuart Henderson
On 2022-05-02, ehakanduran  wrote:
> didn't) but I couldn't figure out a way to fix the second problem. Why
> Ctrl-o doesn't work remains a mystery too. Any pointers will be very
> much appreciated.

See "stty -a", ^O is probably set to 'discard'.

Try 'stty discard undef' to disable this and pass ^O through.


-- 
Please keep replies on the mailing list.



Re: rspamd and pyzor

2022-05-03 Thread Stuart Henderson
On 2022-05-03, Michael Hekeler  wrote:
> But are you sure that you need it for pyzor?!?!?!?

rspamd needs it. It's event-driven so they probably try to avoid blocking
as much as possible, and by running it over TCP the load can be distributed
between machines more easily.


-- 
Please keep replies on the mailing list.



Re: rspamd and pyzor

2022-05-03 Thread Stuart Henderson
On 2022-05-02, kasak  wrote:
> Hello misc!
>
> I have some information for rspamd users, and one question.
>
> As you may know, rspamd not using pyzor by directly calling pyzor binary.
>
> Instead, they say, you need to create special systemd socket, and call 
> pyzor through it.
>
> It is described on rspamd manuals: 
> https://rspamd.com/doc/modules/external_services.html#pyzor-specific-details
>
> OpenBSD does not has systemd, but it has inetd.
>
> This is simple way to create socket similar to systemd:
>
> 127.0.0.1:5953    stream    tcp    nowait    root 
> /usr/local/bin/pyzor    pyzor check
>
> It actually works, but you may notice, that i'm using "root" here.
>
> I've tried to use _rspamd user, but for some reason it drops an error
>
> rspamd[90054]: <9ef568>; lua; pyzor.lua:134: error parsing response: 
> ERROR [Errno 13] Permission denied: '/root/.pyzor'.\\0a
>
> Can somebody explain to me, what is happening here? Why socket, runned 
> as _rspamd try to access root home instead of _rspamd home ?

I bet inetd is not resetting HOME in the environment and just passes through
the environment it was running under itself.

Simplest / most efficient fix is probably to just use pyzor's --homedir flag.

> And of course, maybe someone have an idea how to implement the same for 
> the razor-agents?

Same but with -home?

-- 
Please keep replies on the mailing list.



Re: pkg-readmes missing for gnome and kde?

2022-05-01 Thread Stuart Henderson
On 2022-05-01, Antoine Jacoutot  wrote:
> On Sun, 2022-05-01 at 20:51 +0300, Mihai Popescu wrote:
>> Hello,
>> 
>> I tried to enable gnome or kde after install in an openbsd snapshot for 
>> amd64.
>> Last time (some time ago) I know for sure there were some pkg-readmes
>> for both gnome and kde start. I can't find them now, I have some
>> readmes in the directory, but not for gnome nor kde.
>> 
>> Is there some other way used to document gnome or kde start, please?
>> 
>> Thank you.
>
> # pkg_add gnome
>
> There will be a readme under:
> /usr/local/share/doc/pkg-readmes/gnome

The pkg-readme from KDE was removed with KDE 4, we don't have the
Plasma desktop environment for 5 due to the strong dependence on
Wayland (see https://undeadly.org/cgi?action=article;sid=20210124113220).




Re: OpenBSD 7.1 - hangs after userland upgrade on server hardware

2022-05-01 Thread Stuart Henderson
On 2022-05-01, Andrew Lemin  wrote:
> Hi all,
>
> I am totally stumped with issues while upgrading/installing 7.1 and I need
> some help!
>
> Server; Supermicro X10SLV-Q (Intel Q87 Express), Xeon E3-1280 v3, 8G RAM,
> Mellanox 10G NIC
>
> This server has been running OpenBSD flawlessly for years. I followed the
> upgrade instructions and was able to reboot fine onto the 7.1 kernel (I
> rebooted a couple of times on the 7.1 kernel in fact). However after I run
> 'pkg_add -u' to upgrade all of userland to 7.1, the machine started hanging
> during boot.
>
> The hang looked like an IO problem as it would always hang around the disk
> setup stages.
> I went into the BIOS and tried optimised defaults and failsafe defaults but
> no luck..
>
> I also downloaded a fresh copy and tried installing 7.1 from flash, however
> the 7.1 installer also hangs. It hangs in the same place every time after
> selecting 'done' to the networking config.
> As I have a Mellanox card in here, I removed the NIC. but the hang
> continues so its not that..
>
> I get nothing to debug, it just freezes. I have reinstalled 7.0 which is
> still working perfectly so this is not a hardware fault.
>
> Is there anything I can do to increase the verbosity to see what driver it
> is trying to load before the hang?
>
> Other information, this is a totally headless machine, with a Xeon CPU
> without any onboard GPU. It has a console connection with
> console-redirection in the bios, and I have to set the tty params during
> boot to interact over console. Otherwise everything else is standard.

If you can copy the console output (from boot loader to hang) from serial
console into an email, that might give some clues.

dmesg from 7.0 might be useful too.

It's a bit unclear how you upgraded (pkg_add -u is for packages rather than
userland parts of the OS) - normally you would upgrade kernel and userland
such that you'd boot onto new kernel+userland at the same time, then update
packages.




Re: creating new partition has corrupted the disklabel ("bad super block")

2022-04-30 Thread Stuart Henderson
On 2022-04-30, Nick Holland  wrote:
> On 4/30/22 5:16 AM, Sylvain Saboua wrote:
>> Hello
>> 
>> I have recently got an upgrade for my laptop with a 1TB SSD drive.
>> I successfully managed to install a dual boot between archlinux and
>> openbsd, both on encrypted partitions.
>> 
>> Everything was fine with both systems, until the final act of the
>> dual boot which consists in setting a partition for file sharing> between 
>> the two operating systems, using encfs on ext2.
>
> So...you want to share an encrypted partition between two unrelated
> operating systems.
>
> Pretty sure that's not going to work.  And since you haven't provided
> any details of what you did, I'm guessing you don't have a plan to
> get around the problems.  Linux and OpenBSD use very different
> encryption mechanisms.

encfs runs on top of other filesystems and works on various OS.
it is in packages. As far as the problems experienced here are
concerned I think it can be ignored what exactly is stored on the
ext2fs partition, the same probably would probably occur with
plain stored files.

(btw if I wanted to share between OpenBSD and another OS I would
go with FAT32, it's more likely that others will have already found the
worst bugs with FAT32 than with the less-used ext2fs support).

>> Creating this partition in archlinux works fine, but has seemingly
>> corrupted the disklabel for openbsd : openbsd boots fine until the
>> disk-checking step comes, whereupon I am informed that the j and k
>> partitions on the sd1 disklabel are somewhat corrupted:> 
>> /dev/sd1k (/home): BAD SUPER BLOCK: MAGIC NUMBER WRONG
>> /dev/sd1j (/usr/obj): BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE
>> WITH THOSE IN LAST ALTERNATE
>> 
>> UNEXPECTED INCONSISTENCY; RUN fsck_ffs MANUALLY
>> 
>> Automatic file system check failed: help!
>> Enter pathname of shell or RETURN for sh:
>
> This absolutely does not imply a corrupted disklabel.  This is a
> corrupted partition.  Or an encrypted partition that OpenBSD doesn't
> know how to decrypt.

If the partition table now points to the wrong place then it seems
likely that could result in a "magic number wrong" too. I did wonder if
adding it in Arch would cause OpenBSD to update the "constructed"
disklabel entries for non-OpenBSD filesystems, which start from 'i',
but disklabel(8) says that these are "not dynamic, they are fixed
at the time disklabel is run. That means that subsequent changes
that affect non-OpenBSD partitions will not be present in the
default label" - which suggests it's something else.

So corrupted partition due to creating another filtesystem on top of
an OpenBSD one does seem more likely here.

>> I don't know how I can upgrade an encrypted install using the usb
>> medium, but perhaps if I would this would be a way to solve my problem?

simplest way is to boot an upgrade kernel (bsd.rd) on a softraid-crypted
filesystem from the OpenBSD boot loader. You should be able to do it
from USB storage too but probably need to run bioctl by hand to "create"
the softraid device in that case.

> But as I and others have said in the past, multiboot systems are
> complicated.

Yes multiboot is the fiddly bit here.

I would suggest maybe creating the "fdisk style" (MBR) paritition table
first, with a chunk for OpenBSD, a chunk for $other_OS, and the shared
space, then install OpenBSD so that those "disklabel style" partition
entries are automatically constructed for those, and install onto the
other partitions, avoiding those two.

My preference for dualbooting would be, if possible, to use an entirely
separate disk (in the same machine). There's far less risk of error
that way.




Re: bwfm0 no networking when combined with trunk (Raspberry Pi 4)

2022-04-30 Thread Stuart Henderson
On 2022-04-30, David Demelier  wrote:
> I have setup a trunk combination on my Pi 4 to aggregate the ethernet
> port (bse0) with the wireless port (bwfm0) using the examples in the
> documentation:

trunk changes the MAC address to that of the first port, and there's a
fair chance that changing MAC might not work with bwfm.

You could try "lladdr (mac address of bwfm interface)" in hostname.trunk0
and see if that helps.




Re: Unusable resolution on a widescreen monitor during install

2022-04-27 Thread Stuart Henderson
On 2022-04-27, Nick Holland  wrote:
> On 4/27/22 9:15 AM, David Demelier wrote:
>> 
>> http://markand.fr/static/openbsd-resolution.jpeg
>
> * Do a serial install (aren't I funny?  As if there is a serial port on a
> machine with an HDMI port!  But maybe there is...Maybe I should go buy
> a lottery ticket, too).

it isn't 100% clear from the photo which thinkcentre machine it is, but
actually there is quite a good chance it _does_ have a serial port.

> * Try the install with a 1920x1080 or lesser resolution monitor.

or maybe a VGA cable to the existing monitor, if machine and monitor can do it




Re: clang 13 space issues with KARL

2022-04-27 Thread Stuart Henderson
On 2022-04-27, Nick Holland  wrote:
>> What can I do to make KARL reorder_kernel use less memory without buying more
>> RAM?  I've turned KARL off for now but that's not a real solution and I hate
>> it.
>> 
>> Is there no option in the clang 13.0.0 linker to store what it would normally
>> store in memory to disk?  I know it would be slow but KARL doesn't need to
>> be fast if it's backgrounded.
>
> yep. It is called "swap".  You just reinvented swap. :)
> And KARL is backgrounded already.

And that's the problem in some cases: /bin/time -l says that
reorder_kernel uses ~650MB rss on my laptop. Depending on what else you
have running (noting that daemons, which are often starting at around
the same time as reorder_kernel runs, often use more RAM during startup
than in a steady state) that can be enough to tip it over the edge.




Re: OpenBSD 7.1 and unbound 1.15.0

2022-04-27 Thread Stuart Henderson
On 2022-04-27, Renaud Allard  wrote:
> This is a cryptographically signed message in MIME format.
>
> --ms080604030904040206090102
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 8bit
>
>
>
> On 4/26/22 16:25, Renaud Allard wrote:
>> 
>> Hello,
>> 
>> Since I upgraded my DNS servers to 7.1 with unbound 1.15.0, I have a lot 
>> of issues with DNS resolution (without changing anything in the config). 
>> I randomly get SERVFAIL (or somethings NXDOMAIN) for a lot of names, or 
>> something even stranger like some addresses and SERVFAIL for others (see 
>> dashlane example).
>> 
>> Examples:
>> host dashlane.com
>> dashlane.com has address 65.9.82.43
>> dashlane.com has address 65.9.82.13
>> dashlane.com has address 65.9.82.36
>> dashlane.com has address 65.9.82.97
>> Host dashlane.com not found: 2(SERVFAIL)
>> Host dashlane.com not found: 2(SERVFAIL)
>> 
>> 
>> host forum.opnsense.org
>> Host forum.opnsense.org not found: 2(SERVFAIL)
>> 
>
>>      use-caps-for-id: yes
>
> After removing the use-caps-for-id, it seems the resolver works fine. I 
> opened the following bug report 
> https://github.com/NLnetLabs/unbound/issues/670

I'm not aware of intentional changes in use-caps-for-id between the
versions of Unbound in 7.0 and 7.1, it might be worth trying the old
version again to rule out a coincidental change on the authoritative
servers for those domains, it can happen.

(there is some fallback in unbound for hosts which don't handle this,
but I think it might not cope if there's differing behaviour between
multiple hosts load-balanced behind a single backend IP).

Maybe consider packet captures to the auth servers for some domains
you've seen problems? You aren't on an ISP which might be intercepting
some DNS requests are you?




Re: OpenBSD and multitasking

2022-04-26 Thread Stuart Henderson
On 2022-04-26, Mike Larkin  wrote:
> On Tue, Apr 26, 2022 at 02:13:16AM +0300, Mihai Popescu wrote:
>> I can bear this since I'm not into large file transfer business. But
>> here is another interesting fact: each time my disk is used by some
>> file transfer, all the running applications, mostly GUI based are
>> stalling - that includes mostly chromium ( even if it is not chromium
>> that it does the disk data transfer).

I have found MP performance to be poor when doing lots of disk io, in
my case noticed when doing multithreaded searches (the_silver_searcher)
over unpacked source from the whole ports tree, making the machine
often respond poorly when it was running (including lack of response to
keyboard/mouse).

> See comments below. The hardware is ancient. I'd say try running
> chrome on windows on this hardware and you'll probably see it's also
> horrible.

Chrome runs reasonably well on other OS including Windows on much worse
machines than this.

>> avail mem = 7460139008 (7114MB)
>> cpu0: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.45 MHz, [...]

not bad really

>> cpu1: disabling user TSC (skew=129)
>> cpu2: disabling user TSC (skew=186)

this is not ideal if you have software calling gettimeofday a lot.
browsers often do.

>> sd0 at scsibus1 targ 0 lun 0:  
>> naa.5000c5006520feaf
>
> HDD, not SSD, and release date of this model is April 2011... Eleven years 
> ago.

at least it's not SMR like many newer HDDs :)

>From Mihai's description it really feels like it's disk io in particular
that's causing the problem. Performance could well be better on OS with
better developed SMP (I don't get the impression that disk io has really
been a target area for our MP work).

I am sure the #1 improvement will be replacing this with SSD, or adding
SSD and moving those filesystems which see frequent access. (Even if
the machine won't boot from NVMe directly, a cheap M.2 NVMe in a PCIe
carrier card for /usr/local, /home, /tmp would have a good cost/benefit
ratio).

Alternatively this hardware will likely work better with another OS.
Choice of OS is a trade-off.




Re: Sysctl settings for transmission bittorrent (udp receive buffer size)

2022-04-25 Thread Stuart Henderson
On 2022-04-25, Daniel Schuermann  wrote:
> I can't get transmission (bittorrent client) to work properly.  
>
> From the logs: 
> transmission-daemon: UDP Failed to set receive buffer: 
> requested 4194304, got 41600
>
> On Linux I would do: 
> sysctl net.core.rmem_max=4194304
> I couldn't figure out the correct settings for OpenBSD. 
>
> net.inet.udp.recvspace sets the default, not the max buffer size, 
> e.g. sysctl net.inet.udp.recvspace=4194304 causes errors:
> nslookup openbsd.org
> nslookup: isc_socket_create: not enough free resources

That is the right sysctl, the alternative is to set per-socket with
setsockopt() (SO_SNDBUF, SO_RCVBUF).

The max is 256K (262144).



-- 
Please keep replies on the mailing list.



Re: Should FUSE mounts be considered local?

2022-04-23 Thread Stuart Henderson
On 2022-04-22, Allan Streib  wrote:
> I had an SMB network share mounted on a directory under my $HOME (via
> FUSE using usmb package), and overnight security(8) tried to check it for
> setuid/setgid files. That did not go well. I see that I could have set
> the SUIDSKIP environment variable but I didn't think about that in advance
> and even if I had, I probably would have assumed that such a mount was not
> considered local.
>
> $ mount
> [...]
> fusefs on /home/astreib/sav type fuse (local)
>
> Is this a problem with the usmb package, that it did not indicate that
> this was a network mount, or is that distinction just not possible with
> FUSE mounts? I.e. wondering if this is potentially fixable or if I need
> to remember to exclude any FUSE mounts via SUIDSKIP?

I don't know if there's a way to indicate network/not with fuse (and even if
there is on other OS, the implementation on OpenBSD is not full featured).
Certainly some fuse filesystem types would want to be considered local
(ntfs-3g for example).

I think you might be better served by finding a way to do what you want
that doesn't involve fuse/usmb if possible..




Re: kernel fault after 7.1

2022-04-23 Thread Stuart Henderson
On 2022-04-23, kasak  wrote:
> hello everybody. after upgrading to 7.1 my router started to panic very 
> often :(( about twice a day.

Please report to b...@openbsd.org, with the information from your mail,
plus dmesg, and an outline of how the machine is configured (what types
of network interface/pseudointerface are involved, a bit about ipsec
config and what software is running, is it iked or isakmpd or static,
is sasyncd running, etc)


> This is the information from the screen:
>
> kernel: protection fault trap, code=0
>
> Stopped at    ipsp_ids_gc+0xb4    cmpl $0,0x64(%r14)
>
> ddb{0}> show panic
>
> the kernel did not panic
> ddb{0}> trace
>
> ipsp_ids_gc(0) at ipsp_ids_gc+0xb4
>
> softclock_thread(800022baf260) at softclock_thread+0x13b
>
> and trace frame: 0x0, count: -2
>
> ddb{0}> machine ddbcpu 1
>
> Stopped at    x86_ipi_db+0x12:    leave
>
> ddb{1}> trace
>
> x86_ipi_db(800022909ff0) at x86_ipi_db+0x12
>
> x86_ipi_handler() at x86_ipi_handler+0x80
>
> Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23
>
> acpicpu_idle() at acpicpu_idle+0x203
>
> sched_idle(800022909ff0) at sched_idle+0x280
>
> end trace frame: 0x0, count -5
>
>
>


-- 
Please keep replies on the mailing list.



Re: 7.1 & nsd - failed writing to tcp: Permission denied

2022-04-23 Thread Stuart Henderson
On 2022-04-22, Laura Smith  wrote:
> --- Original Message ---
> On Friday, April 22nd, 2022 at 18:16, Peter J. Philipp 
>  wrote:
>
>> So that's weird becuase the 3-way handshake must have completed for nsd to
>> reply a query. Meaning there was SYN's and ACK's being exchanged but perhaps
>> a PUSH+ACK may not succeed through the pf rules?
>>
>> Don't post your firewall rules to the list, but study them :-) and correct
>> them.
>
>
> Thanks Peter.
>
> If I understand you correctly, I would need to be messing around with flags 
> a/b in my PF rules ?
>
> IIRC I'm not doing that, but I'll go and double check to be sure !
>
> Laura

I think (though am not 100% sure) that there is a possibility this could
happen if the client is extremely slow to respond and the PF state times
out.



Re: No valid root disk found when upgrading

2022-04-22 Thread Stuart Henderson
On 2022-04-21, Stuart Henderson  wrote:
>> upgrade# cd /dev; sh MAKEDEV sd0
>> upgrade# mount -t ffs -r /dev/sd0a /mnt
>> upgrade# ls /mnt
>> .cshrc  bsd dev sbin
>> .profilebsd.booted  etc sys
>> altroot bsd.rd  hometmp
>> auto_upgrade.conf   bsd.sp  mailwrapper.coreusr
>> bin bsd.upgrade rootvar
>> upgrade# df -h
>> Filesystem SizeUsed   Avail Capacity  Mounted on
>> /dev/rd0a  3.5M3.0M451K87%/
>> /dev/sd0a  3.9G677M3.0G18%/mnt
>>
>>> it's worth seeing what "sysctl hw.disknames" says too
>> upgrade# sysctl hw.disknames
>> hw.disknames=sd0:dc999ef6267325df,rd0:a8c7c8e3bbaa0da7
>
> That looks sane too..

Oh I didn't look close enough. You are missing /mnt. mkdir it and
that shoukd fix the problem.



Re: No valid root disk found when upgrading

2022-04-21 Thread Stuart Henderson
On 2022-04-21, michal.lyszc...@bofc.pl  wrote:
> --47wmzg5ty6ypgy6x
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: 7bit
>
> Hello Stuart,
> Thanks for your reply, here is more data
> On 2022-04-21 21:43:08, Stuart Henderson wrote:
>> if you boot the upgrade kernel and drop to a shell, what do you
>> get from this?
>> 
>> cd /dev; sh MAKEDEV sd0
>> mount -t ffs -r /dev/sd0a /mnt
>> ls /mnt
> Sadly, nothing that would raise any flags or ideas in my brain,
> everything seems to work fine
>
> upgrade# cd /dev; sh MAKEDEV sd0
> upgrade# mount -t ffs -r /dev/sd0a /mnt
> upgrade# ls /mnt
> .cshrc  bsd dev sbin
> .profilebsd.booted  etc sys
> altroot bsd.rd  hometmp
> auto_upgrade.conf   bsd.sp  mailwrapper.coreusr
> bin bsd.upgrade rootvar
> upgrade# df -h
> Filesystem SizeUsed   Avail Capacity  Mounted on
> /dev/rd0a  3.5M3.0M451K87%/
> /dev/sd0a  3.9G677M3.0G18%/mnt
>
>> it's worth seeing what "sysctl hw.disknames" says too
> upgrade# sysctl hw.disknames
> hw.disknames=sd0:dc999ef6267325df,rd0:a8c7c8e3bbaa0da7

That looks sane too..

>> (similar to what's used for the "is_rootdisk()" check in
>> src/distrib/miniroot/install.sub)
> Is there a way to run upgrade script with "set -x" globally?
> I tried to run /bin/ksh -x /upgrade.sh, but it seems -x is
> discarded in functions and I can only see debug up untile
> +do_ugrade function call.
>
> Maybe replacing all "() {" with "() {\nset -x" will do the trick?
>

Not 100% sure but there are some functions that return output rather
than just a return code and I think it may break those. Something more
targetted in is_rootdisk might do though (set -x. maybe get rid of the
redirect).




Re: No valid root disk found when upgrading

2022-04-21 Thread Stuart Henderson
On 2022-04-21, michal.lyszc...@bofc.pl  wrote:
>> 16 partitions:
>> #size   offset  fstype [fsize bsize   cpg]
>>   a:  8400960 1024  4.2BSD   2048 16384 12960
>>   b: 67119581  8401984swap
>>   c:4883971680  unused
>>   d:134223072 75521568  4.2BSD   2048 16384 12960
>>   e:278652416209744640  4.2BSD   4096 32768 26062
>>   i:  960   64   MSDOS

disklabel looks alright. if you boot the upgrade kernel and drop to a
shell, what do you get from this?

cd /dev; sh MAKEDEV sd0
mount -t ffs -r /dev/sd0a /mnt
ls /mnt

(similar to what's used for the "is_rootdisk()" check in
src/distrib/miniroot/install.sub)

it's worth seeing what "sysctl hw.disknames" says too



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

2022-04-21 Thread Stuart Henderson
On 2022-04-21, Florian Obser  wrote:
> 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, but if someone has a machine with layer of accumulated cruft
and they do local build/installs then that's a good way to find them.

> 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.

Me too.

> 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 disagree, it can cause harm sometimes. Not least when you run out of
space in /usr halfway through untarring sets during an update...





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

2022-04-20 Thread Stuart Henderson
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

> 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
check for those if you don't have to wade through maybe thousands of lines of
old headers, fonts, manpages, obsolete perl components and timezone files.
If that is clear then I'm usually pretty happy to just remove anything else
under /usr.

If you want to be on the safe side then tar up the files before rm'ing.
I don't do that though.

> 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.




Re: Is there a way to build mod_auth_kerb?

2022-04-19 Thread Stuart Henderson
On 2022-04-18, Maksim Rodin  wrote:
> Hello,
> I am trying to build mod_auth_kerb for apache2 on OpenBSD 6.9
> I installed heimdal-libs-7.7.0p0 and downloaded the latest src for
> mod_auth_kerb from github
> After unpacking and configuring the following way:
> ./configure --with-krb5=/usr/local/heimdal --with-krb4=no
> I try to run 'make'
> I get a bunch of warnings like these:
>
> ```
> /usr/local/heimdal/include/krb5-protos.h:18:52: note: expanded from macro 
> 'KRB5_DEPRECATED_FUNCTION'
> #define KRB5_DEPRECATED_FUNCTION(x) __attribute__((__deprecated__(x)))
>^
> src/mod_auth_kerb.c:1547:47: warning: incompatible pointer types passing 
> 'request_rec *' (aka 'struct request_rec *') to parameter of type 'const char 
> *'
>   [-Wincompatible-pointer-types]
> log_rerror(APLOG_MARK, APLOG_ERR, 0, r,

This suggests that it is not compatible with the API of the version of
Apache HTTPD that you're trying to use it with.

You might have better luck with https://github.com/S2-/mod_auth_kerb
but that is still years old and might not work either


-- 
Please keep replies on the mailing list.



Re: reordering libraries: fdcresult: overrun

2022-04-19 Thread Stuart Henderson
On 2022-04-19, rtw0 dtw0  wrote:
> I would provide more info if I knew how to configure the mail service on
> OBSD, which I had never considered useful before when I thought that I
> might rely solely on the Handbook and man pages. 

You just need to get the information onto a computer which _can_ send mail.
Methods include ssh and copy/paste, sftp, copying via USB stick. Or use
a mail client on OpenBSD that can use an external SMTP server if you don't
want to configure the local mail service, there are plenty of options.




Re: no output from zathura

2022-04-18 Thread Stuart Henderson
I've committed a fix.

If you report problems with ports, it would help to include at least:

- OpenBSD version and machine arch (it never hurts to include the full dmesg)
- Package version
- (plus the description of what happens, any console messages etc, like
you included here)

And preferably on ports@ rather than misc.


On 2022-04-18, Shadrock Uhuru  wrote:
> Hi everyone
> i have zathura zathura-ps zathura-pdf-mupdf installed,
> i run zathura from the command line with zathura file.pdf which opens zathura 
> with nothing
> displayed,
> the shell that i run zathura from displays the following
>
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'jbig2_ctx_new_imp'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'jbig2_data_in'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'jbig2_make_global_ctx'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'jbig2_global_ctx_free'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'jbig2_complete_page'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'jbig2_page_out'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'jbig2_release_page'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'jbig2_ctx_free'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'opj_set_default_decoder_parameters'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'opj_create_decompress'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'opj_set_info_handler'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'opj_set_warning_handler'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'opj_set_error_handler'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'opj_setup_decoder'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'opj_stream_default_create'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'opj_stream_set_read_function'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'opj_stream_set_skip_function'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'opj_stream_set_seek_function'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'opj_stream_set_user_data'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'opj_stream_set_user_data_length'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'opj_read_header'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'opj_decode'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'opj_stream_destroy'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'opj_destroy_codec'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'opj_image_destroy'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'gumbo_parse_with_options'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'gumbo_destroy_output'
> zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 
> 'gumbo_normalized_tagname'
> error: Could not load plugin '/usr/local/lib/zathura/libpdf-mupdf.so' (Cannot 
> load specified object).
> error: Could not determine file type.
>
> ---
>
> this error appears if i try to open a pdf or ps file,
> i managed to open one out of about ten ps files i tried,
> is this a known problem or something i'm not doing right ?
>
> shadrock
>
>


-- 
Please keep replies on the mailing list.



Re: Auto layout for disk partitions - a new user's perspective

2022-04-18 Thread Stuart Henderson
On 2022-04-18, James Mintram  wrote:
> Hi. I am new to OpenBSD, so these questions come from my first 
> experience with the system.
>
> I selected the auto layout option when partitioning my 256GB drive. I have 
> then found issues while doing the following:
>
> 1) Cloning src from the github mirror and checking it out, completely fills 
> the /usr/src parition.
> 
> 2) Building some ports fail because /usr/local/pobj is not on an wxallowed fs.
> 
> My questions are:
>
> 1) Should the default /usr/src partition be bigger on large disks?

/usr/src is sized for just a checkout rather than a full repository mirror
with history.

This is normal for cvs (and if you do have a full repo mirror with cvs,
that would be in a different place than /usr/src).

If you're using the git conversion you could do a shallow checkout, or
use a larger fs, or place it elsewhere.

On a typical system I don't think it's helpful to have this much larger
(though it is now starting to get a little tight for a checkout so maybe it
could go up a few hundred MB). /usr/src isn't needed on a typical machine
and raising the size will impact on sizes of other partitions, which
might make it more likely people run into harder problems later..

> 2) Should there be a /usr/local/pobj partition created with correct mount 
> options? (I appreciate building ports is an "advanced" thing to do - but it 
> feels weird having to mess with partition layout after a fresh install just 
> to 
> build them)

Ports doesn't use /usr/local/pobj by default (you can set it via WRKOBJDIR
in mk.conf, but /usr/local isn't a great place for a filesystem with rapid
changes during a port build). Also, /usr/local/pobj *is* normally wxallowed.

If you are using ports I would strongly recommend a separate filesystem
for /usr/ports, either with default ports-related directories (i.e. don't
change dirs in mk.conf) and set that wxallowed, or with a separate WRKOBJDIR
on a wxallowed filesystem.


-- 
Please keep replies on the mailing list.



Re: Nginx + Syslog Question

2022-04-17 Thread Stuart Henderson
On 2022-04-17, David Anthony  wrote:
> I'm trying to send Nginx access logs to syslog. I've tried examples in 
> the default nginx configuration file and man page to no avail. Can 
> anyone help identify why I'm not seeing access logs?

It runs in /var/www chroot, and uses its own code to write to the
/dev/log unix socket (rather than using the OS syslog functions
which don't require the socket as there is a different interface
with the kernel).)

So you need to set syslogd to create a socket in the chroot:

rcctl set syslogd flags -a /var/www/dev/log


-- 
Please keep replies on the mailing list.



Re: Spamd as a proxy

2022-04-15 Thread Stuart Henderson
On 2022-04-15, alejan...@rogue-research.com  
wrote:
> Hi Mr Hansteen,
>
> Thanks for the reply, I started my journey with OpenBSD this week and I 
> decided to buy your book to help me understand its PF system, it's been 
> very helpful. I've been reading man pages from pf,spamd,opensmtpd and 
> sysctl, perhaps I just need more reading and time to fully understand 
> what is wrong with my setup.
>
> Since I am using 2 hosts (1 antispamer, 1 smtp server) on the same LAN, 
> I thought `rdr-to` would not work as stated on: 
>, under the section 
> "Redirection and Reflection" which is why I used `divert-to`. But 
> neither work, thus, I am left with no ideas as of how to forward the 
> emails from the antispam machine to the email server.
>
> What's different from all the docs and examples I've found is that I'm 
> trying to use two hosts, and everything I've seen seems to assume spamd 
> and the smtp server are on the same host. If `rdr-to` is not the way to 
> go, how must I overcome this challenge?

spamd expects to either be on the same host as the real SMTP service,
or on a router/firewall in front of that host. the only way to do proxy
like this on a host in a subnet alongside the smtp server (with another
firewall "in front") is to rdr *and* nat. but for obvious reasons you
really want the SMTP service to see the original source IP so nat isn't
much help...




Re: time drift in OpenBSD in proxmox (qemu-kvm) guest

2022-04-15 Thread Stuart Henderson
On 2022/04/15 22:02, Tom Smyth wrote:
> Hello Stuart,
> What is the EFI / BIOS  Power management / CPU power management
> Performance setting set to  ?
> if the CPU is throttled back (due to low usage) is that affecting the
> time keeping ?
> It might be worth trying OS Controlled or Performance (as a test)
> it may be set to power saving or balanced
> 
> I hope this helps,
> ( and thanks for your patience with my previous impulsive (albeit
> trying to help) replies earlier

Thanks for the suggestions - since the change I made in the last mail
("I've changed mine to acpihpet0 and it seems much happier", i.e. setting
the kern.timecounter.hardware sysctl to acpihpet0, based on Stefan's
pointer) the time has stayed in sync.

The machine is on what looks like the closest thing to "power saving"
(option in machine config is "best experience") - since I leave this
machine turned on, at around 0.30GBP/kWh power cost, and often with
only ~50% of power generation where I live being low carbon unless
it's particularly windy (https://www.carbonintensity.org.uk/#regional,
https://www.gridwatch.templar.co.uk/) I'd like to keep it like that
if possible :)


> On Fri, 15 Apr 2022 at 11:12, Stuart Henderson
>  wrote:
> >
> > On 2022-04-14, Stefan Sperling  wrote:
> > > On Thu, Apr 14, 2022 at 09:26:41PM -, Stuart Henderson wrote:
> > >> I have some OpenBSD guests in Proxmox VE 7.1-7 (pve-qemu-kvm_6.1.0) and
> > >> seeing pretty bad clock drift (50 seconds in ~7h uptime). ntpd can't cope
> > >> with it. From boot:
> > >>
> > >> 2022-04-14T13:58:19.844Z  ntpd[26996]: adjusting local clock by 1.745061s
> > >> 2022-04-14T13:59:24.070Z  ntpd[26996]: adjusting local clock by 1.504470s
> > >> 2022-04-14T14:03:51.176Z  ntpd[26996]: adjusting local clock by 2.430486s
> > >> 2022-04-14T14:07:40.299Z  ntpd[26996]: adjusting local clock by 2.48s
> > >> 2022-04-14T14:11:51.540Z  ntpd[26996]: adjusting local clock by 3.173884s
> > >> 2022-04-14T14:15:03.534Z  ntpd[26996]: adjusting local clock by 3.109722s
> > >> 2022-04-14T14:16:04.848Z  ntpd[26996]: adjusting local clock by 3.185755s
> > >> 2022-04-14T14:17:40.286Z  ntpd[26996]: adjusting local clock by 3.575126s
> > >> 2022-04-14T14:18:45.582Z  ntpd[26996]: adjusting local clock by 4.231518s
> > >> 2022-04-14T14:22:27.618Z  ntpd[26996]: adjusting local clock by 4.231999s
> > >> 2022-04-14T14:25:41.618Z  ntpd[26996]: adjusting local clock by 4.844904s
> > >> 2022-04-14T14:29:58.888Z  ntpd[26996]: adjusting local clock by 4.451876s
> > >> 2022-04-14T14:32:41.628Z  ntpd[26996]: adjusting local clock by 5.250357s
> > >>
> > >> etc. No difference whether qemu-ga is used or not. No difference between
> > >> passing through the real cpu type (i.e. cpu=host, Ryzen 5650G in this 
> > >> case)
> > >> and passing through as "common KVM processor". The guest does detect and
> > >> use pvclock(4).
> > >>
> > >> $ sysctl kern.timecounter
> > >> kern.timecounter.tick=1
> > >> kern.timecounter.timestepwarnings=0
> > >> kern.timecounter.hardware=pvclock0
> > >> kern.timecounter.choice=i8254(0) pvclock0(1500) acpihpet0(1000) 
> > >> acpitimer0(1000)
> > >>
> > >> Anyone have ideas of things I could try that are less wrong than
> > >> running rdate from cron? Thanks.
> > >
> > > I have a -current built-a-week-ago guest on stock Debian KVM, no problems
> > > with time-keeping. It picks acpihpet as timecounter instead of pvclock:
> > >
> > > $ sysctl kern.timecounter
> > > kern.timecounter.tick=1
> > > kern.timecounter.timestepwarnings=0
> > > kern.timecounter.hardware=acpihpet0
> > > kern.timecounter.choice=i8254(0) pvclock0(500) acpihpet0(1000) 
> > > acpitimer0(1000)
> >
> > Interesting - I would have expected the opposite. I've changed mine to
> > acpihpet0 and it seems much happier. Your value of 500 indicates that the
> > PVCLOCK_TSC_STABLE flag wasn't set by the host, I guess that's dependent
> > on host cpu features.
> >
> > Summarising other responses:
> >
> > - Q35 vs i440FX emulated hw setting: no difference
> > - AMD EPYC performance tuning guide: cpu load is pretty low, I think this
> > is unlikely to be relevant
> > - kvm_intel/parameters/preemption_timer: seems Intel-only and reports are
> > that it's not needed for newer KVM
> >
> >
> 
> 
> -- 
> Kindest regards,
> Tom Smyth.



Re: time drift in OpenBSD in proxmox (qemu-kvm) guest

2022-04-15 Thread Stuart Henderson
On 2022-04-14, Stefan Sperling  wrote:
> On Thu, Apr 14, 2022 at 09:26:41PM -0000, Stuart Henderson wrote:
>> I have some OpenBSD guests in Proxmox VE 7.1-7 (pve-qemu-kvm_6.1.0) and
>> seeing pretty bad clock drift (50 seconds in ~7h uptime). ntpd can't cope
>> with it. From boot:
>> 
>> 2022-04-14T13:58:19.844Z  ntpd[26996]: adjusting local clock by 1.745061s
>> 2022-04-14T13:59:24.070Z  ntpd[26996]: adjusting local clock by 1.504470s
>> 2022-04-14T14:03:51.176Z  ntpd[26996]: adjusting local clock by 2.430486s
>> 2022-04-14T14:07:40.299Z  ntpd[26996]: adjusting local clock by 2.48s
>> 2022-04-14T14:11:51.540Z  ntpd[26996]: adjusting local clock by 3.173884s
>> 2022-04-14T14:15:03.534Z  ntpd[26996]: adjusting local clock by 3.109722s
>> 2022-04-14T14:16:04.848Z  ntpd[26996]: adjusting local clock by 3.185755s
>> 2022-04-14T14:17:40.286Z  ntpd[26996]: adjusting local clock by 3.575126s
>> 2022-04-14T14:18:45.582Z  ntpd[26996]: adjusting local clock by 4.231518s
>> 2022-04-14T14:22:27.618Z  ntpd[26996]: adjusting local clock by 4.231999s
>> 2022-04-14T14:25:41.618Z  ntpd[26996]: adjusting local clock by 4.844904s
>> 2022-04-14T14:29:58.888Z  ntpd[26996]: adjusting local clock by 4.451876s
>> 2022-04-14T14:32:41.628Z  ntpd[26996]: adjusting local clock by 5.250357s
>> 
>> etc. No difference whether qemu-ga is used or not. No difference between
>> passing through the real cpu type (i.e. cpu=host, Ryzen 5650G in this case)
>> and passing through as "common KVM processor". The guest does detect and
>> use pvclock(4).
>> 
>> $ sysctl kern.timecounter
>> kern.timecounter.tick=1
>> kern.timecounter.timestepwarnings=0
>> kern.timecounter.hardware=pvclock0
>> kern.timecounter.choice=i8254(0) pvclock0(1500) acpihpet0(1000) 
>> acpitimer0(1000)
>> 
>> Anyone have ideas of things I could try that are less wrong than
>> running rdate from cron? Thanks.
>
> I have a -current built-a-week-ago guest on stock Debian KVM, no problems
> with time-keeping. It picks acpihpet as timecounter instead of pvclock:
>
> $ sysctl kern.timecounter 
> kern.timecounter.tick=1
> kern.timecounter.timestepwarnings=0
> kern.timecounter.hardware=acpihpet0
> kern.timecounter.choice=i8254(0) pvclock0(500) acpihpet0(1000) 
> acpitimer0(1000)

Interesting - I would have expected the opposite. I've changed mine to
acpihpet0 and it seems much happier. Your value of 500 indicates that the
PVCLOCK_TSC_STABLE flag wasn't set by the host, I guess that's dependent
on host cpu features.

Summarising other responses:

- Q35 vs i440FX emulated hw setting: no difference
- AMD EPYC performance tuning guide: cpu load is pretty low, I think this
is unlikely to be relevant
- kvm_intel/parameters/preemption_timer: seems Intel-only and reports are
that it's not needed for newer KVM
 



Re: IKEV2 two devices can connect but only one can make traffic

2022-04-15 Thread Stuart Henderson
On 2022-04-12, Łukasz Moskała  wrote:
> I remember talking with network engineer at one company I used to work at.
> We used fortigate firewalls, and I asked why are we using SSLVPN instead of 
> ipsec-based vpn, as both were supported.
>
> He said something along the lines of "ipsec does not work when there are two 
> devices connecting from the same IP so this would be issue for us when two 
> admins were on the same public wifi, or lived together"
>
> I don't know if this is specific to fortinet's implementation, or if it's 
> issue with ipsec itself, as I never used ipsec in anything else than 
> site-to-site connection.

This is not the case with IPsec with NAT-T.


-- 
Please keep replies on the mailing list.



time drift in OpenBSD in proxmox (qemu-kvm) guest

2022-04-14 Thread Stuart Henderson
I have some OpenBSD guests in Proxmox VE 7.1-7 (pve-qemu-kvm_6.1.0) and
seeing pretty bad clock drift (50 seconds in ~7h uptime). ntpd can't cope
with it. From boot:

2022-04-14T13:58:19.844Z  ntpd[26996]: adjusting local clock by 1.745061s
2022-04-14T13:59:24.070Z  ntpd[26996]: adjusting local clock by 1.504470s
2022-04-14T14:03:51.176Z  ntpd[26996]: adjusting local clock by 2.430486s
2022-04-14T14:07:40.299Z  ntpd[26996]: adjusting local clock by 2.48s
2022-04-14T14:11:51.540Z  ntpd[26996]: adjusting local clock by 3.173884s
2022-04-14T14:15:03.534Z  ntpd[26996]: adjusting local clock by 3.109722s
2022-04-14T14:16:04.848Z  ntpd[26996]: adjusting local clock by 3.185755s
2022-04-14T14:17:40.286Z  ntpd[26996]: adjusting local clock by 3.575126s
2022-04-14T14:18:45.582Z  ntpd[26996]: adjusting local clock by 4.231518s
2022-04-14T14:22:27.618Z  ntpd[26996]: adjusting local clock by 4.231999s
2022-04-14T14:25:41.618Z  ntpd[26996]: adjusting local clock by 4.844904s
2022-04-14T14:29:58.888Z  ntpd[26996]: adjusting local clock by 4.451876s
2022-04-14T14:32:41.628Z  ntpd[26996]: adjusting local clock by 5.250357s

etc. No difference whether qemu-ga is used or not. No difference between
passing through the real cpu type (i.e. cpu=host, Ryzen 5650G in this case)
and passing through as "common KVM processor". The guest does detect and
use pvclock(4).

$ sysctl kern.timecounter
kern.timecounter.tick=1
kern.timecounter.timestepwarnings=0
kern.timecounter.hardware=pvclock0
kern.timecounter.choice=i8254(0) pvclock0(1500) acpihpet0(1000) acpitimer0(1000)

Anyone have ideas of things I could try that are less wrong than
running rdate from cron? Thanks.


OpenBSD 7.1 (GENERIC.MP) #463: Thu Apr  7 12:48:15 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1056808960 (1007MB)
avail mem = 1007554560 (960MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf58e0 (9 entries)
bios0: vendor SeaBIOS version "rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org" 
date 04/01/2014
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: ACPI 1.0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP APIC SSDT HPET WAET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Common KVM processor, 3892.54 MHz, 0f-06-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF,CMPLEG
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 1000MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Common KVM processor, 3892.11 MHz, 0f-06-01
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF,CMPLEG
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu1: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu1: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpihpet0 at acpi0: 1 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
"ACPI0006" at acpi0 not configured
acpipci0 at acpi0 PCI0
acpicmos0 at acpi0
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"QEMU0002" at acpi0 not configured
"ACPI0010" at acpi0 not configured
"QEMUVGID" at acpi0 not configured
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
pvbus0 at mainbus0: KVM
pvclock0 at pvbus0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11
piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0 int 9
iic0 at piixpm0
vga1 at pci0 dev 2 function 0 "Bochs VGA" rev 0x02
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Memory Balloon" rev 0x00
viomb0 at virtio0
virtio0: apic 0 int 11
virtio1 at pci0 dev 10 function 0 "Qumranet Virtio 

Re: Request additions to qbittorrent-nox port README

2022-04-14 Thread Stuart Henderson
+cc ports@ & maintainer

On 2022/04/14 21:11, u...@mailo.com wrote:
> > 127.0.0.1 is probably the best thing to suggest
> > for listening to localhost.
> The thing is - I need it accessible from another machine over network.
> With `localhost` it DOES work over network,
> this is how I have used it for months.
> (With `127.0.0.1` it doesn't.)
> 
> > For listening to connections from any v4 address use 0.0.0.0
> Thank you for this tip, it does work and I leave it set to `0.0.0.0`.
> 
> > the ideal fix for qbittorrent-nox would be if it created
> > separate socket bindings, one for IPv4, one for IPv6.
> I can't help with that, hope someone will address it.
> 
> > Java is a different situation
> My point is that `qbittorrent-nox` suffers either,
> even though the details may grossly differ.
> And `jdk` README has it described
> whereas `qbittorrent-nox` README has not.

This issue does affect various software in packages, it is a common
thing you need to deal with if you're using various software on OpenBSD.
It doesn't really feel right to me to mention it in a pkg-readme for
one specific package when it affects a wide range of them. Perhaps an
FAQ section might be a better idea.

In qbittorrent-nox case, Qt5's network socket listener, when told to
listen for connections to "Any" address, binds only a v6 socket. To
have it do something different, software using this API would need
to listen for "AnyIPv6" and/or "AnyIPv4" instead.

> I feel such intricacies would be welcome in the README.
> Again, my main question to openbsd-misc is:
> whom and how to contact if the maintainer seems not to reply?

Generally the ports@ mailing list is the best place for ports-specific
questions. Also if a maintainer is not responding to your mail, it is
possible that they did not receive it - if that's the case there is a
higher chance they'll see a re-post on ports@ than misc@ (ports devs
are more likely to read ports@ than misc@)

In this case perhaps the diff below might be the least surprising
approach i.e. have it listen to v4 by default. Maybe the pkg-readme
isn't needed any more then too.

Index: Makefile
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent-nox/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile11 Mar 2022 19:47:15 -  1.9
+++ Makefile14 Apr 2022 20:42:55 -
@@ -1,5 +1,6 @@
 COMMENT =  BitTorrent client with web interface
 PKGNAME =  qbittorrent-nox-${VER}
+REVISION = 0
 
 WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5Network Qt5Xml boost_system
 WANTLIB += boost_system-mt c crypto execinfo m ssl torrent-rasterbar z
Index: patches/patch-src_base_bittorrent_tracker_cpp
===
RCS file: patches/patch-src_base_bittorrent_tracker_cpp
diff -N patches/patch-src_base_bittorrent_tracker_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_base_bittorrent_tracker_cpp   14 Apr 2022 20:42:55 
-
@@ -0,0 +1,15 @@
+qt's "Any" listener binds the socket to AF_INET6 which doesn't accept v4
+connections on OpenBSD. Change this to "AnyIPv4".
+
+Index: src/base/bittorrent/tracker.cpp
+--- src/base/bittorrent/tracker.cpp.orig
 src/base/bittorrent/tracker.cpp
+@@ -199,7 +199,7 @@ Tracker::Tracker(QObject *parent)
+ 
+ bool Tracker::start()
+ {
+-const QHostAddress ip = QHostAddress::Any;
++const QHostAddress ip = QHostAddress::AnyIPv4;
+ const int port = Preferences::instance()->getTrackerPort();
+ 
+ if (m_server->isListening())
Index: patches/patch-src_webui_webui_cpp
===
RCS file: patches/patch-src_webui_webui_cpp
diff -N patches/patch-src_webui_webui_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_webui_webui_cpp   14 Apr 2022 20:42:55 -
@@ -0,0 +1,16 @@
+qt's "Any" listener binds the socket to AF_INET6 which doesn't accept v4
+connections on OpenBSD. Change this to "AnyIPv4". If you specifically
+want v6 then set config to listen to :: instead
+
+Index: src/webui/webui.cpp
+--- src/webui/webui.cpp.orig
 src/webui/webui.cpp
+@@ -112,7 +112,7 @@ void WebUI::configure()
+ if (!m_httpServer->isListening())
+ {
+ const auto address = (serverAddressString == "*" || 
serverAddressString.isEmpty())
+-? QHostAddress::Any : QHostAddress(serverAddressString);
++? QHostAddress::AnyIPv4 : QHostAddress(serverAddressString);
+ bool success = m_httpServer->listen(address, m_port);
+ if (success)
+ {



Re: How do I report a kernel panic occuring on install media?

2022-04-14 Thread Stuart Henderson
On 2022/04/14 12:21, rtw0 dtw0 wrote:
> Hi,
> 
> To disable acpi permanently:
> # config -ef /bsd
> ukc > disable acpi
> ukc > quit

This is a REALLY BAD IDEA.

>From my earlier mail:  https://marc.info/?l=openbsd-misc=164983204029245=2

|  (Note: acpi drivers are used for various machine functions including
|  in some cases temperature control, so it's not advisable to run with
|  them disabled long term, but should be fine for a short test - the
|  N2600 is low power too which helps).



Re: Request additions to qbittorrent-nox port README

2022-04-13 Thread Stuart Henderson
On 2022-04-13,   wrote:
> I have had 2 issues with `qbittorrent-nox`, both are OpenBSD-specific
> and IMHO it would be appropriate if README described them.
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/qbittorrent/qbittorrent-nox/pkg/README?rev=1.3=text/x-cvsweb-markup
>
> I emailed Elias M. Mariani (package maintainer) and
> Rafael Sadowski (who edited the README),
> 2 times each one, with no reply and the readme has not changed.
> I emailed Christian Weisgerber (who edited the README),
> who replied he is not in charge and agreed I'd better ask at misc list.
>
> So, how can my plea on `qbittorrent-nox` README
> be delivered to the right person?
>
>
> The issues were:
>
> 1. `qbittorrent-nox` connection refused
>Discussed here:
>https://www.unitedbsd.com/d/634-qbittorrent-nox-connection-refused
>
>apparent cause: `IPV6_V6ONLY`
>http://man.openbsd.org/amd64/ip6#IPV6_V6ONLY
>
>READMEs for `jdk` do mention the issue:
>
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/devel/jdk/1.8/pkg/README?rev=1.3=text/x-cvsweb-markup
>
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/devel/jdk/11/pkg/README?rev=1.3=text/x-cvsweb-markup
>
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/devel/jdk/17/pkg/README?rev=1.2=text/x-cvsweb-markup
>
>```
>ipv4 and v6 networking
>==
>  ipv4 to ipv6 address mapping is disabled on OpenBSD. This means the
>  jdk can only use ipv4 addresses or ipv6 addresses but not both at
>  the same time. By default ipv4 addresses are enabled. To use ipv6
>  addresses set the following properties when you start java:
>
>  -Djava.net.preferIPv4Stack=false
>  -Djava.net.preferIPv6Stack=true
>  -Djava.net.preferIPv6Addresses=true
>```
>
>I personally have set `WebUI\Address=localhost`
>in `~/.config/qBittorrent/qBittorrent.conf`
>which works for my setup,
>yet I don't know what good defaults the README should suggest.

127.0.0.1 is probably the best thing to suggest for listening to localhost.
For listening to connections from any v4 address use 0.0.0.0. Though, the
ideal fix for qbittorrent-nox would be if it created separate socket
bindings, one for IPv4, one for IPv6.

Java is a different situation as the *entire process* is restricted to
either IPv4 or IPv6 connections depending on the setting of these variables.
It *may* be possible to work around this by setting it as v6-only, pointing
at a DNS resolver doing DNS64, and nat-pt NAT translations ("af-to" in PF).
But it is a mess.


-- 
Please keep replies on the mailing list.



Re: How do I report a kernel panic occuring on install media?

2022-04-13 Thread Stuart Henderson
On 2022-04-13, misc.99...@aleeas.com  wrote:
> > It sounds like you're trying to use the 32bit OpenBSD installer for a
>> 64bit cpu. In that case, you would want the AMD64 installer.

Even if that is the case, it's not very likely to change the ACPI parsing.

> As far as I remember the CPU is only 32-bit capable. But outputs I gathered 
> from Linux is telling me otherwise (given below).

CPU spec sheet says it could support it, but maybe it's disabled by BIOS.
IIRc 64-bit mode on some of the Atoms does not work brilliantly anyway.

> To give it a shot, I just tried to boot amd64 install70.img (sha256: 
> 6bc7f945c2709247d449892c33c0f1b9a31590528572c1e988fef4a7637210e6) on the 
> machine and this time it didn't even get to kernel panic stage.
>
> Using drive 0, partition 3.
> Loading.
> probing: pc0 mem[634K 2035M a20=on]
> disk hd0+ hd1+*
>>> OpenBSD/amd64 BOOT 3.53
> boot>
> cannot open hd0a:/etc/random.seed: No such file or directory
> booting hd0a /7.0/amd64/bsd.rd: 3830471+1598464+3907256+0+704512 
> [109+288+28]=0x995530
> entry point at 0x81001000
>
> Then it stops. Pressing Ctrl+Alt+Del or any key doesn't do anything. Only way 
> is to press the power button to force shutdown.

The two main causes of this:

- booting on serial console without "set tty com0" in the boot loader
- trying to run amd64 on a machine that only supports 32-bit




Re: Question about /etc/resolvd.conf and local resolver

2022-04-13 Thread Stuart Henderson
On 2022-04-13, J Doe  wrote:
> For people reading this thread ...
>
> /etc/resolv.conf is the traditional file for configuring the system 
> resolver(s) while /etc/resolvd.conf is the configuration file for the 
> resolvd *daemon*, which is also involved in the configuration of the 
> system resolver(s).

There is no resolvd.conf, resolvd configures itself automatically

-- 
Please keep replies on the mailing list.



Re: How do I report a kernel panic occuring on install media?

2022-04-13 Thread Stuart Henderson
On 2022-04-13, misc.99...@aleeas.com  wrote:
> I'm trying to boot OpenBSD 7.0 i386 image (sha256: 
> 2423307414df1800537063b3cafd9ae788b46711074b7f94d855c8a3de622f51) from a USB 
> flash drive on HP Mini, Intel Atom N2600 1.60 GHz machine. Before I could 
> install, unfortunately I'm facing a kernel panic. It shows on screen:
>
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Atom(TM) CPU N2600 @ 1.60 GHz ("GenuineIntel" 686-class) 1.60 
> GHz, 06-36-01
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,NXE,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64 max=64. C-substates=0.2.2.0.2.0.3, IBE
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins, remapped
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt0 at acpi0: bus 3 (PCI1)
> acpiprt0 at acpi0: bus 1 (RP01)
> acpiprt0 at acpi0: bus 2 (RP02)
> acpiec0 at acpi0
> Could not convert 1 to 0
>
> panic: aml_die aml_convert:2095
>
> The operating system has halted.
> Please press any key to reboot.
>
> Almost any key or key combination I press gets the machine to reboot.

This is expected from the install kernel, it doesn't have DDB.

> It runs Windows 7 and Debian just fine. In fact I rebooted on to the media 
> from a Debian install which is running without any hardware complaints. But 
> OpenBSD seems to have this issue.

OpenBSD has its own written-from-scratch ACPI implementation and can
sometimes run into problems interpreting machine ACPI tables that are
already handled by other implementations.

What's needed is a dump of the ACPI tables, which you could get from
another OS, but it would be helpful to try and get it booted into
OpenBSD as this could give more information.

Try boot -c at the boot loader prompt and disabling individual acpi
device drivers and see if you can get it booted like that. The i386
install kernel has these:

$ grep ^acpi RAMDISK_CD
acpi0   at bios?
acpihpet*   at acpi?
acpicmos*   at acpi?
acpiec* at acpi?
acpimadt0   at acpi?
acpiprt*at acpi?

So after "boot -c", I would first try "disable acpiec" and "quit" and
see if that boots. If not then try disabling others (acpiprt is probably
ok as you would likely have seen the error earlier).

If none work you can try "disable acpi" but information about *which*
driver hit the problem is likely to be helpful.

If you can get it installed then try to get it booted - you'll need
to disable the driver again to boot the standard kernel, and as this
has additional acpi drivers, potentially you may need to disable some
others - here's the list in case you do run into it:

$ grep ^acpi GENERIC
acpi0   at bios?
acpitimer*  at acpi?
acpihpet*   at acpi?
acpiac* at acpi?
acpibat*at acpi?
acpibtn*at acpi?
acpicpu*at acpi?
acpicmos*   at acpi?
acpidock*   at acpi?
acpiec* at acpi?
acpimadt0   at acpi?
acpimcfg*   at acpi?
acpiprt*at acpi?
acpisbs*at acpi?
acpitz* at acpi?
acpiasus*   at acpi?
acpisony*   at acpi?
acpithinkpad*   at acpi?
acpitoshiba*at acpi?
acpivideo*  at acpi?
acpivout*   at acpivideo?
acpipwrres* at acpi?

If you can get it booted then run sendbug to generate a report (usually
easiest as "sendbug -P > somefile" and move it to a machine which
already has email configured; scp or copy via USB storage etc).
Send that in to b...@openbsd.org along with details of which driver/s
you disabled, and the kernel output you included in your mail above.

(Note: acpi drivers are used for various machine functions including
in some cases temperature control, so it's not advisable to run with
them disabled long term, but should be fine for a short test - the
N2600 is low power too which helps).

-- 
Please keep replies on the mailing list.



Re: IKEV2 two devices can connect but only one can make traffic

2022-04-12 Thread Stuart Henderson
On 2022-04-11, Ettore Tagarelli  wrote:
> If I use the "dynamic keyword I get this error: "no IP address found for
> dynamic" though "config address 192.168.98.1/24" is there.
> Using 0.0.0.0/32 instead of 0.0.0.0/0 causes that traffic is not routed
> ('cause /32 restrict the only address possible to 0.0.0.0) though
> connection happens correctly.

You need to upgrade before you can use "dynamic".


-- 
Please keep replies on the mailing list.



Re: IKEV2 two devices can connect but only one can make traffic

2022-04-11 Thread Stuart Henderson
On 2022-04-11, Ettore Tagarelli  wrote:
> Hello,
> I've an Openbsd 6.6 machine with IKEV2. I always used it with only one
> client connected and it always worked. Trying to connect with two clients
> (behind the same NAT) I found out that the connection seems established but
> only one client works.
> Can anybody help me? Thanks 

This usually means the config is not quite right.

On the currently supported versions of OpenBSD you would probably want
to use "ike (somename) passive esp from any to dynamic" in the iked.conf
section. It worked with older versions (like 6.6) too but I can't remember
what was needed in config. Also there have been *many* improvements to
iked since then, so you should upgrade..

It would also help to show the configuration.


-- 
Please keep replies on the mailing list.



Re: TLS library problme: tlsv1 alert protocol

2022-04-09 Thread Stuart Henderson
On 2022-04-09, Stephan Mending  wrote:
> Hi Tom, 
>
> Hm.. I am on the receiving end of this TLS Handshake.
> I am running -release on one and -current on another. Problem and error 
> messages are the same. 
>
> Excerpt of the running postfix main.cf:
>
>  smtpd_tls_mandatory_ciphers = high
>  smtpd_tls_ciphers = high
>  smtp_tls_mandatory_ciphers = high
>  smtp_tls_ciphers = high
>
>  tls_ssl_options = NO_COMPRESSION, NO_RENEGOTIATION, PRIORITIZE_CHACHA
>
>  tls_high_cipherlist = 
> HIGH:+aRSA:+SHA384:+SHA256:+DH:+SHA:+kRSA:!eNULL:!aNULL:!PSK:!SRP:!AESCCM:!DSS:!ARIA
>
>  smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
>  smtpd_tls_protocols = !SSLv2, !SSLv3
>  smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
>  smtp_tls_protocols = !SSLv2, !SSLv3
>
>  smtpd_tls_security_level = maytfix/smtpd[97536]: 
> mout.web.de[212.227.17.12]:52515: TLS cipher list 
> "HIGH:+aRSA:+SHA384:+SHA256:+DH:+SHA:+kRSA:!eNULL:!aNULL:!PSK:!SRP:!AESCCM:!DSS:!ARIA:!aNULL"

I suggest starting by commenting-out all of the above lines in favour of
the defaults, which are sane, and take things from there.

If you can get *some* connection then you'll have a better idea of what
the other side is trying to use and how it matches/doesn't match with
your settings.

IMHO unless you're disabling plaintext SMTP completely (in which case
you can't expect to receive email from the whole internet anyway), for
incoming delivery from other MXs it's usually better to have some
encryption rather than none.

Some of the settings you have used e.g. those in tls_ssl_options
are not supported at all by libressl anyway. I don't know what
will happen if you set them.

If you want higher requirements for your own users with authenticated
SMTP, just put those settings on the listeners for that i.e. on the
submission/smtps ports in master.cf

submission inet n   -   y   -   -   smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_tls_mandatory_ciphers=high
  -o smtpd_tls_mandatory_protocols=!TLSv1,!TLSv1.1
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

-- 
Please keep replies on the mailing list.



Re: map/mount a directory/partition into memory

2022-04-08 Thread Stuart Henderson
On 2022-04-08, Stuart Henderson  wrote:
> On 2022-04-08, Stefan Hagen  wrote:
>> Mihai Popescu wrote (2022-04-08 05:17 CEST):
>>> Since my computer is struggling with chromium and I suspect it's the
>>> disk access being too slow, I want to map the directory accessed by
>>> chromium ( i think it is ~/.cache) into the memory.
>>> 
>>> Looking in the man, i spotted rd, but i think i need to setup this in
>>> the kernel.
>>> The next choice is tmpfs.
>>> The next one is mfs.
>>> 
>>> I have no experience with this stuff, so does it worth to take this 
>>> approach?
>>> If so, what is the recommended fs, please?
>>> Is it possible to map/mount a directory from a partition only, or is
>>> it the entire partition only accepted as a mount argument?
>
> Just as with a disk/network filesystem, you can mount it at whatever
> directory you like. So directly over /home/username/.cache is possible.
>
>> I haven't played with rd or tmpfs, but this works:
>
> rd is for creating the "ramdisk" kernel for the installer or similar
> use-cases.
>
> tmpfs is disabled in GENERIC kernels, so you'll need to build your own,
> and hope you don't run into the reason for it being disabled.
>
> mfs is probably right for this case (but do check speeds though;
> for Mihai's use-case it seems likely to be better, but a decent SSD is
> likely to be same/faster than mfs.

Since someone complained offlist that I didn't include figures:

# cd /mnt/mfs; for i in `jot 5`; do dd if=/dev/zero of=foo bs=1m count=990 2>&1 
| grep bytes; done
1038090240 bytes transferred in 2.641 secs (392976029 bytes/sec)
1038090240 bytes transferred in 2.627 secs (395040864 bytes/sec)
1038090240 bytes transferred in 2.660 secs (390203934 bytes/sec)
1038090240 bytes transferred in 2.693 secs (385398220 bytes/sec)
1038090240 bytes transferred in 2.688 secs (386081589 bytes/sec)
# cd ~; for i in `jot 5`; do dd if=/dev/zero of=foo bs=1m count=990 2>&1 | grep 
bytes; done  
1038090240 bytes transferred in 2.311 secs (449182544 bytes/sec)
1038090240 bytes transferred in 2.314 secs (448454320 bytes/sec)
1038090240 bytes transferred in 2.303 secs (450684315 bytes/sec)
1038090240 bytes transferred in 2.303 secs (450627092 bytes/sec)
1038090240 bytes transferred in 2.311 secs (449121684 bytes/sec)

Obviously it is going to vary by hardware, I have seen a bigger
difference before. In this case the drive is a SATA-connected Samsung
860 EVO 500GB (plain not softraid crypto) on an AMD EPYC running i386.

-- 
Please keep replies on the mailing list.



Re: map/mount a directory/partition into memory

2022-04-08 Thread Stuart Henderson
On 2022-04-08, Mihai Popescu  wrote:
>> swap /tmp mfs rw,nodev,nosuid,-s=1g 0 0
>
> for some reason, xenodm is not displayed and i am not able to login ...

Permissions are probably wrong. Try this:

- boot single-user
- mount -uw / (don't mount other filesystems)
- chmod 1777 /tmp
- reboot


-- 
Please keep replies on the mailing list.




Re: map/mount a directory/partition into memory

2022-04-08 Thread Stuart Henderson
On 2022-04-08, Stefan Hagen  wrote:
> Mihai Popescu wrote (2022-04-08 05:17 CEST):
>> Since my computer is struggling with chromium and I suspect it's the
>> disk access being too slow, I want to map the directory accessed by
>> chromium ( i think it is ~/.cache) into the memory.
>> 
>> Looking in the man, i spotted rd, but i think i need to setup this in
>> the kernel.
>> The next choice is tmpfs.
>> The next one is mfs.
>> 
>> I have no experience with this stuff, so does it worth to take this approach?
>> If so, what is the recommended fs, please?
>> Is it possible to map/mount a directory from a partition only, or is
>> it the entire partition only accepted as a mount argument?

Just as with a disk/network filesystem, you can mount it at whatever
directory you like. So directly over /home/username/.cache is possible.

> I haven't played with rd or tmpfs, but this works:

rd is for creating the "ramdisk" kernel for the installer or similar
use-cases.

tmpfs is disabled in GENERIC kernels, so you'll need to build your own,
and hope you don't run into the reason for it being disabled.

mfs is probably right for this case (but do check speeds though;
for Mihai's use-case it seems likely to be better, but a decent SSD is
likely to be same/faster than mfs.




Re: pf documentation

2022-04-07 Thread Stuart Henderson
On 2022-04-07, Steve Litt  wrote:
> I need some easy beginner's pf documentation as well as some
> intermediate pf documentation. I plan to make an OpenBSD/pf firewall. I
> haven't done this in ten years, and imagine pf and the process of
> turning OpenBSD into a firewall have changed in that time.

The pf.conf(5) manual is the primary reference, if you prefer to have a
nicely formatted printable version you can get one with

$ man -T pdf pf.conf > pf.conf.pdf

There are many many online guides about configuring PF; some are
helpful, many less so. If you do use these, cross-referring to
pf.conf(5) is a good idea.

IMHO the "building a router" example on the FAQ complicates things a
bit too much (it is actually "how to setup dhcp, wifi hostap [which few
people actually use and doesn't work on many adapters], and a DNS
resolver", and uses some PF features which I think it's really better
if you understand what they do before using them.

My main tips would be:

- start the ruleset with a "block" or "block log" rule so that no
packets match the implicit default "rule 0", which is effectively
"pass all no state". This avoids one of the main hard-to-diagnose
cases where some packets accepted without creating firewall state.

- tags and received-on can be pretty helpful and most guides don't
use them.

- if you can't figure out which rules are matching a packet, put
a "match log(matches)" rule at the top of the ruleset (maybe
with a from/to or port restriction if it's on a busy machine),
and watch "tcpdump -nevvipflog0" - when a packet traverses the
PF ruleset, you'll get some output for every rule matching that
packet, with a final line showing the overall pass/drop outcome.
the rule numbers shown can be looked up with "pfctl -sr -R XX -v".




  1   2   3   4   5   6   7   8   9   10   >