Content-Security-Policy makes page render differently

[Paul Pace]

When I load a page from OpenBSD served with relayd and httpd with 
Content-Security-Policy set to default-src self, I can see that a basic 
HTML page that normally renders with all of the text in the center is 
now rendered on the left.


I have this currently configured with http://mostlybsd.com not loading 
the header and https://mostlybsd.com loading the header.


I have also served the same HTML file in an Ubuntu server with nginx and 
with the header enabled the page still renders in the center.


Is there something I am missing?

I have configured relayd with the following:

log state changes
log connection
prefork 10

list="ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256"
ipv4="45.32.193.189"

table  { 127.0.0.1 }

http protocol "https" {
    tls ciphers $list
    tls keypair mostlybsd.com
    return error

    match request header set "X-Forwarded-For" value "$REOTE_ADDR"
    match request header set "X-Forwarded-Port" value "$REMOTE_PORT"

    match response header set "Content-Security-Policy" value \
    "default-src 'self'"
    match response header set "Referrer-Policy" value "no-referrer"
    match response header set "Strict-Transport-Security" value \
    "max-age=15552000; includeSubDomains; preload"
    match response header set "X-Content-Type-Options" value "nosniff"
    match response header set "X-Frame-Options" value "SAMEORIGIN"
    match response header set "X-XSS-Protection" value "1; mode=block"

    match method GET tag ok
    match method HEAD tag ok

    block
    pass tagged ok forward to 
}

relay "https" {
    listen on $ipv4 port https tls
    protocol "https"
    forward to  port 8080
}

relay "http" {
    listen on $ipv4 port http
    forward to  port 8080
}

Thank you,

Paul

Client-authenicated TLS handshake with relayd

[Paul Pace]

Hello!

I am putting a small server behind Cloudflare that currently is 
configured to serve everything through relayd.


I want to use their option of client-authenticated TLS handshakes, but I 
can't see a way to do it with relayd - is this possible?


It does look like I could use httpd tls client ca option (assuming I'm 
understanding the man page), which I can use if relayd doesn't support this.


Thank you!

Paul

Non-default partitions and upgrades

[Paul Pace]

Hello!

I generally try and run things as a project recommends, but I am 
wondering about running different additional partitions (e.g., add 
/var/www) or changing partition letter (e.g., move /var to the end for 
convenient VPS expansion).


I know it isn't the biggest thing in the world, but would this ever have 
an impact on running version upgrades?


Thank you,

Paul

gzip-static option isn't working on default index

[Paul Pace]

I have gzip-static set in a server block in httpd.conf.

If I make the following request:

curl -I -H 'Accept-Encoding: gzip,deflate' http://example.com

the response has no Content-Encoding header and the Content-Length 
matches /var/www/htdocs/index.html.


If I make the following request:

curl -I -H 'Accept-Encoding: gzip,deflate' http://example.com/index.html

the response includes Content-Encoding: gzip and the Content-Length 
matches /var/www/htdocts/index.html.gz.


Is there some additional configuration required or is this the intended 
output for the option?


Thank you,

Paul

self-hosted man.openbsd.org script?

[Paul Pace]

I have this vague memory of reading someone who posted a script, IIRC, 
to convert the system's man pages to HTML, or similar, into somewhere 
under /var/www and the pages worked just like the highly useful 
man.openbsd.org, and not like the plain text pages that everyone always 
posts to their websites.


Does someone happen to know where that is?

On 12/23/23 11:16 AM, Nick Holland wrote:

On 12/19/23 15:38, Nick Holland wrote:

Hello,

man.openbsd.org, cvsweb.openbsd.org, openbsd.cs.toronto.edu
and obsdacvs.cs.toronto.edu will be unavailable for site
maintenance starting Thursday, December 21 about 6:00am ET
(UTC-5) and hopefully be back up and running by Saturday,
December 23, 6:00am ET.

Sorry for any inconvenience.

Nick.



Unfortunately, it seems there's a problem impacting our servers,
and everyone is celebrating the holiday.

So ... return of man.openbsd.org, cvsweb.openbsd.org and
the install and anoncvs mirrors will be delayed.

Nick.

Re: relayd forward with tls

[Paul Pace]

On 1/4/24 10:22 AM, Adriano Barbosa wrote:

Hi!
I'm trying to use relayd with multiple FQDNs mixing remote servers
with and without tls:

relayd -- fqdn1 --> 127.0.0.1 (no tls)
-- fqdn2 --> x.x.x.x (with tls)

I wrote my relayd.conf like this:

table  { 127.0.0.1 }
table  { x.x.x.x }

http protocol https {
 tls keypair fqdn1
 tls keypair fqdn2

 match request header "Host" value "fqdn1" tag "fqdn1"
 pass request tagged "fqdn1" forward to 

 match request header "Host" value "fqdn2" tag "fqdn2"
 pass request tagged "fqdn2" forward to 
}

relay wwwtls {
 listen on egress port 443 tls
 protocol https
 forward to  port 80
 forward with tls to  port 443
}


With one forward requiring TLS in a relay block, relayd will require TLS 
for all forward statements in the relay block.




I have fqdn2 working and fqdn1 giving a "curl: (52) Empty reply from
server".
Removing "with tls" on the second forward, fqdn1 works and fqdn2 gives
a "Client sent an HTTP request to an HTTPS server."

Is it possible to have relayd working on this scenario? What am I
missing here?

Obrigado!
--
Adriano

Re: relayd forward with tls

[Paul Pace]

On 1/6/24 7:35 PM, Adriano Barbosa wrote:

On Thu, Jan 04, 2024 at 06:57:10PM -0800, Paul Pace wrote:

On 1/4/24 10:22 AM, Adriano Barbosa wrote:

Hi!
I'm trying to use relayd with multiple FQDNs mixing remote servers
with and without tls:

relayd -- fqdn1 --> 127.0.0.1 (no tls)
 -- fqdn2 --> x.x.x.x (with tls)

I wrote my relayd.conf like this:

table  { 127.0.0.1 }
table  { x.x.x.x }

http protocol https {
  tls keypair fqdn1
  tls keypair fqdn2

  match request header "Host" value "fqdn1" tag "fqdn1"
  pass request tagged "fqdn1" forward to 

  match request header "Host" value "fqdn2" tag "fqdn2"
  pass request tagged "fqdn2" forward to 
}

relay wwwtls {
  listen on egress port 443 tls
  protocol https
  forward to  port 80
  forward with tls to  port 443
}


With one forward requiring TLS in a relay block, relayd will require TLS for
all forward statements in the relay block.



I have fqdn2 working and fqdn1 giving a "curl: (52) Empty reply from
server".
Removing "with tls" on the second forward, fqdn1 works and fqdn2 gives
a "Client sent an HTTP request to an HTTPS server."

Is it possible to have relayd working on this scenario? What am I
missing here?

Obrigado!
--
Adriano




Thank you for the response.

Digging a little more, I found that if I change the listen port from
443 to values other than 443 and 80, the "match request host" filter
stops working. The behaviour is the same with or without "with tls" on
the relay.

With port 443:
stable# curl --insecure https://fqdn1
Server 1
stable# curl --insecure https://fqdn2
Server 2

With port 4430 and allegedly any port other than 80 and 443:
stable# curl --insecure https://fqdn1:4430
Server 1
stable# curl --insecure https://fqdn2:4430
Server 1


What does curl -vk show?


Port 8080 also reproduces this last result.
Is that the expected behaviour? BTW, I'm running 7.4.

Please find relayd.conf and httpd.conf below.
fqdn{1,2} are on /etc/hosts as 127.0.0.1 and the respective tls
certificates exists in /etc/ssl and keys in /etc/ssl/private.

Obrigado!
--
Adriano


# relayd.conf
addr="127.0.0.1"

table  { 127.0.0.1 }
table  { 127.0.0.1 }

http protocol https {
 tls keypair fqdn1
 tls keypair fqdn2

 match request header "Host" value "fqdn1" tag "fqdn1"
 pass request tagged "fqdn1" forward to 

 match request header "Host" value "fqdn2" tag "fqdn2"
 pass request tagged "fqdn2" forward to 
}

http protocol https2 {
 tls keypair fqdn1
 tls keypair fqdn2

 match request header "Host" value "fqdn1" tag "fqdn1"
 pass request tagged "fqdn1" forward to 

 match request header "Host" value "fqdn2" tag "fqdn2"
 pass request tagged "fqdn2" forward to 
}

relay wwwtls {
 listen on $addr port 443 tls
 protocol https

 forward to  port 8080
 forward to  port 8081
}

relay wwwtls2 {
 listen on $addr port 4430 tls
 protocol https2

 forward to  port 8080
 forward to  port 8081
}


# httpd.conf
addr="127.0.0.1"

server "fqdn1" {
 listen on $addr port 8080
 location "*" {
 root "/htdocs/server1"
 }
}

server "fqdn2" {
 listen on $addr port 8081
 location "*" {
 root "/htdocs/server2"
 }
}

Re: relayd forward with tls

[Paul Pace]

On 1/7/24 1:31 PM, Adriano Barbosa wrote:

On Sun, Jan 07, 2024 at 05:21:04AM -0800, Paul Pace wrote:

On 1/6/24 7:35 PM, Adriano Barbosa wrote:

On Thu, Jan 04, 2024 at 06:57:10PM -0800, Paul Pace wrote:

On 1/4/24 10:22 AM, Adriano Barbosa wrote:

Hi!
I'm trying to use relayd with multiple FQDNs mixing remote servers
with and without tls:

relayd -- fqdn1 --> 127.0.0.1 (no tls)
  -- fqdn2 --> x.x.x.x (with tls)

I wrote my relayd.conf like this:

table  { 127.0.0.1 }
table  { x.x.x.x }

http protocol https {
   tls keypair fqdn1
   tls keypair fqdn2

   match request header "Host" value "fqdn1" tag "fqdn1"
   pass request tagged "fqdn1" forward to 

   match request header "Host" value "fqdn2" tag "fqdn2"
   pass request tagged "fqdn2" forward to 
}

relay wwwtls {
   listen on egress port 443 tls
   protocol https
   forward to  port 80
   forward with tls to  port 443
}


With one forward requiring TLS in a relay block, relayd will require TLS for
all forward statements in the relay block.



I have fqdn2 working and fqdn1 giving a "curl: (52) Empty reply from
server".
Removing "with tls" on the second forward, fqdn1 works and fqdn2 gives
a "Client sent an HTTP request to an HTTPS server."

Is it possible to have relayd working on this scenario? What am I
missing here?

Obrigado!
--
Adriano




Thank you for the response.

Digging a little more, I found that if I change the listen port from
443 to values other than 443 and 80, the "match request host" filter
stops working. The behaviour is the same with or without "with tls" on
the relay.

With port 443:
stable# curl --insecure https://fqdn1
Server 1
stable# curl --insecure https://fqdn2
Server 2

With port 4430 and allegedly any port other than 80 and 443:
stable# curl --insecure https://fqdn1:4430
Server 1
stable# curl --insecure https://fqdn2:4430
Server 1


What does curl -vk show?



Unfortunately, no difference. Follows:

$ curl --insecure -vk https://fqdn2
* Host fqdn2:443 was resolved.
* IPv6: (none)
* IPv4: 127.0.0.1
*   Trying 127.0.0.1:443...
* Connected to fqdn2 (127.0.0.1) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: C=BR; ST=MS; L=DOU
*  start date: Jan  6 20:12:43 2024 GMT
*  expire date: Jan  5 20:12:43 2025 GMT
*  issuer: C=BR; ST=MS; L=DOU
*  SSL certificate verify result: self signed certificate (18), continuing 
anyway.
*   Certificate level 0: Public key type ? (4096/128 Bits/secBits), signed 
using sha256WithRSAEncryption
* using HTTP/1.x

GET / HTTP/1.1
Host: fqdn2
User-Agent: curl/8.5.0
Accept: */*


< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Length: 18
< Content-Type: text/html
< Date: Sun, 07 Jan 2024 21:23:24 GMT
< Last-Modified: Sun, 07 Jan 2024 21:19:24 GMT
< Server: OpenBSD httpd
<
Server 2
* Connection #0 to host fqdn2 left intact

and

$ curl --insecure -vk https://fqdn2:4430
* Host fqdn2:4430 was resolved.
* IPv6: (none)
* IPv4: 127.0.0.1
*   Trying 127.0.0.1:4430...
* Connected to fqdn2 (127.0.0.1) port 4430
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: C=BR; ST=MS; L=DOU
*  start date: Jan  6 20:12:43 2024 GMT
*  expire date: Jan  5 20:12:43 2025 GMT
*  issuer: C=BR; ST=MS; L=DOU
*  SSL certificate verify result: self signed certificate (18), continuing 
anyway.
*   Certificate level 0: Public key type ? (4096/128 Bits/secBits), signed 
using sha256WithRSAEncryption
* using HTTP/1.x

GET / HTTP/1.1
Host: fqdn2:4430
User-Agent: curl/8.5.0
Accept: */*


< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Length: 18
< Content-Type: text/html
< Date: Sun, 07 Jan 2024 21:25:42 GMT
< Last-Modified: Sun, 07 Jan 2024 21:19:15 GMT
< Server: OpenBSD httpd
<
Server 1
* Connection #0 to host fqdn2 left intact

My best guess is httpd is not receiving a host header so is serving the 
first server block.


Try setting relay 

cloudflare.cdn.openbsd.org has been down for days

[Paul Pace]

Hello!

Apologies if this was announced some place as planned and I missed it, 
but I just wanted to let everyone know that cloudflare.cdn.openbsd.org 
has been down for a few days now.


pkg_add -nu
https://cloudflare.cdn.openbsd.org/pub/OpenBSD/7.4/packages-stable/amd64/: 
TLS handshake failure: handshake failed: error:14004410:SSL 
routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure
https://cloudflare.cdn.openbsd.org/pub/OpenBSD/7.4/packages/amd64/: TLS 
handshake failure: handshake failed: error:14004410:SSL 
routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure

https://cloudflare.cdn.openbsd.org/pub/OpenBSD/7.4/packages/amd64/: empty
Couldn't find updates for...

Thank you,


Paul

Relayd forward to multiple ports on one target host?

[Paul Pace]

Hello!

I have an OpenBSD server that hosts multiple services listening on 
various ports (some projects have their own web server, some projects 
require a reverse proxy, some projects just use httpd, etc.). This 
server receives requests via relayd on a different server. I was hoping 
to not insert relayd between every request to the host, but it's not the 
end of the world if this is the only viable solution while using relayd.


The requests to relayd go to domains (e.g., www.example.com, 
serviceone.example.com, servicetwo.example.com, etc.) for web services 
(ports 80 and 443), but I cannot figure out a way to specify a port on 
the target server to forward requests to when there are multiple ports 
(e.g., www is on port 80, serviceone is on port 8080, servicetwo is on 
port 3, etc.). Running relayd -n does not report syntax errors when 
there are multiple forward to rules for the same target server with 
different ports in the relay block, but I can't find a way to specify 
which request should go to which port.


Thank you,

Paul

Re: Relayd forward to multiple ports on one target host?

[Paul Pace]

On 2024-05-02 07:32, Manuel Giraud wrote:

table  { 127.0.0.1 }
table  { 127.0.0.1 }
table  { 127.0.0.1 }


On 2024-05-02 07:02, Zé Loff wrote:

table  { 10.17.16.10 }
table  { 10.17.16.10 }
table  { 10.17.16.10 }


Multiple tables - I didn't see that!

I'm going with something like this to keep things simple for myself:

table  { 192.0.2.99 }
table  { 192.0.2.99 }
table  { 192.0.2.99 }

Thank you,

Paul

Re: relayd filter

[Paul Pace]

On 6/5/23 3:15 PM, Nick Bouliane wrote:

Hi,

in relayd.conf I'm trying to do :

pass from 192.168.1.1 path "/something.html"

If I individually specify the "from" or the "path", it works
but when I combine both, it doesn't work.


Nowadays, when I come upon this I just use tags and move on.

Something like this might work:

match path "/something.html" tag something
pass from 192.168.1.1 tagged something



Am I missing something or if it's just not possible ?
Or is there another way to express this another way ?

thank you,
Nick

Re: Self-hosting OpenBSD server, any documentation?

[Paul Pace]

On 7/8/23 1:03 AM, Theo de Raadt wrote:

Jonathan Drews  wrote:





On Sat, Jul 8, 2023, at 01:42, Jonas Borchelt wrote:

The book "Absolute OpenBSD" is an excellent choice to expand your knowledge of 
the OpenBSD operating system. It was written by Michael W. Lucas and is regarded as a 
comprehensive resource for beginners and advanced users alike. It covers various aspects 
of OpenBSD, including installation, network security, system administration, and more. 
Enjoy reading it!


There is another book by Michael Lucas that may be of benefit: "Httpd and Relayd 
Mastery".
You can buy it as a *.pdf from Tilted Windmill Press.




One day I really should try this self-hosting which seems to be all the rage.


For those of us not very good at promoting, it turns out to be a very 
self-serving endeavor.

Swap disklabel partition location?

[Paul Pace]

Hello!

I am wondering if there is some requirement to have the swap disklabel 
partition always as partition b? I have a VPS where I might prefer to 
put swap at the end so when the VPS RAM and storage is increased, I can 
increase swap size, as needed, but I can't figure out why this might be 
a bad idea.


I have so far only found in the FAQ on Disk Setup:

> b: The boot disk's b partition is usually a swap partition.

And this isn't clear to me that: when there is a swap partition it must 
be on b, but if there is no swap partition then b is something else, or 
if it means that usually the swap partition is put on the b partition 
but can be on some other partition.


Thank you,

Paul

Re: Swap disklabel partition location?

[Paul Pace]

On 9/15/21 10:30 AM, Theo de Raadt wrote:

The kernel will automatically add swap if it is partition b.
If it is not partition b, it will get added later by fstab
entries.  Almost noone does this.

If you put a filesystem on partition b, I would be surprised
if something causes you problems later, you are fighting against
decades of practice.

You can allocate the 'b' storage near the end of your partition,
rather than in-order with the other filesystems.  I suspect
a series of operations with with 'Resize', 'delete' and allocating new
space will get you storage near the end.  And then yes, you should
be able to re-allocate it in the future, upon a reboot.

But it is also possible that you'll hit bugs in the disklabel editor,
since I've never heard of anyone doing this.

Paul Pace  wrote:


Hello!

I am wondering if there is some requirement to have the swap disklabel
partition always as partition b? I have a VPS where I might prefer to
put swap at the end so when the VPS RAM and storage is increased, I
can increase swap size, as needed, but I can't figure out why this
might be a bad idea.

I have so far only found in the FAQ on Disk Setup:


b: The boot disk's b partition is usually a swap partition.


And this isn't clear to me that: when there is a swap partition it
must be on b, but if there is no swap partition then b is something
else, or if it means that usually the swap partition is put on the b
partition but can be on some other partition.

Thank you,

Paul



Thank you, that is very helpful.

I will choose an appropriate time in the future to experiment with this.

Re: httpd(8) and PHP - more details in error log

[Paul Pace]

On 10/4/21 11:45 PM, openbsd.l...@krottmayer.com wrote:

Hi,

I use PHP on OpenBSD's HTTPD for my private web page. In the default
configuration it's hard
to debug an PHP error, because I don't see a time or the specific
request on which the
error occurred.

Is there a configuration for PHP or HTTPD to print more details in the
error log?

Thanks in advance!



You can send httpd logs to syslog by setting

log syslog

This will log the timestamps, but still not IP addresses in the error 
log. See:


https://www.mail-archive.com/bugs@openbsd.org/msg15344.html

Paul

Re: Rate limit the httpd web server for signup requests

[Paul Pace]

On 2024-06-11 15:41, Martin wrote:

I already do some rate limiting with stateful tracking options for PF,
which works really great for the stuff I use it for.

I also use block lists of known bad IP addresses etc.

But what useful methods exists that prevent spamming a HTML signup form
from stuffing the database with useless signups?

Naturally the accounts that haven't been validated one way or another
gets deleted, but the initial signup is a problem as thousands upon
thousands of requests are stored before deletion.

I have tried blocking by IP, but this is difficult as the IP changes
faster than it can be blocked.

The User Agent is spoofed with random garbage.

Honey pot empty hidden fields gets detected and ignored.

Randomly generated form IDs that gets submitted and validated using a
session cookie also doesn't work as the cookie is just stored and then
send along.

A simple CAPTCHA reduces some of the irrelevant noise, but the more
sophisticated bots solves the CAPTCHA.

Using Cloudflare's or Google's CAPTCHA is frowned upon by the real
users, which I fully understand.

So I was wondering, if some other clever method can reduce the noise?


I haven't tried it and I'm not sure how useful it is in your case, but 
mCaptcha uses proof of work.


https://mcaptcha.org/

Paul

Re: Rate limit the httpd web server for signup requests

[Paul Pace]

On 6/12/24 10:32 PM, Chris Bennett wrote:

It's not perfect, but I have a long list of regexes that I know are spam
that I have my Perl code that processes the form block. Trying to block
from a log is not very helpful. It can let through thousands of the same
spam attempts before the log catches up to the attempts reaching the log,
which is a pretty long time.


I was just wondering if you've tried requiring email or SMS link to 
unique signup URL?


Thank you,


Paul

Multiple httpd.conf rules within location brackets must be on separate lines

[Paul Pace]

I just discovered that location block rules in httpd.conf can only be on 
separate lines. For example, the following does not pass the syntax test 
(httpd -n):


location "foo" { block, no log }

But this passes:

location "foo" {
block
no log
}

However, server block rules can contain more than one rule on a line. 
For example:


tcp { backlog 128, no sack }

I was just wondering if this is the expected output for httpd.conf.

Thank you,


Paul

Re: Multiple httpd.conf rules within location brackets must be on separate lines

[Paul Pace]

On 9/15/24 9:42 AM, Rubén Llorente wrote:

I have a production site with lots of rules which look like:

location "/someplace/*.ext" { pass }

location "/someplace/something.ht*" { block }

I meant for more than one rule in the location block.

Based on your example, the following will not pass the syntax test:

location "someplace/something.ht*" { block, no log }

Thank you,


Paul



Paul Pace wrote:
I just discovered that location block rules in httpd.conf can only be 
on separate lines. For example, the following does not pass the syntax 
test (httpd -n):


location "foo" { block, no log }

But this passes:

location "foo" {
 block
 no log
}

However, server block rules can contain more than one rule on a line. 
For example:


tcp { backlog 128, no sack }

I was just wondering if this is the expected output for httpd.conf.

Thank you,


Paul

7.6 MariaDB packages version is EOL

[Paul Pace]

The current version of MariaDB in packages is 10.9 series, which was EOL 
August, 2023 as a part of the MariaDB short-term maintenance stable 
series, originally released in March, 2022.[1]


I don't know how much it impacts users to upgrade to a newer version, 
but it seems like packages should contain a currently maintained version 
at least as an option.


A current long-term series is 11.4, which is maintained until May, 2029.[2]

If I knew how to create a package, I would submit one, but it is still a 
bit more than know how to do.


Thank you,


Paul

[1] https://mariadb.com/kb/en/release-notes-mariadb-10-9-series/
[2] https://mariadb.com/kb/en/changes-improvements-in-mariadb-11-4/

Mount options for attached block storage partition to be used exclusively for rsnapshot

[Paul Pace]

Hello!

I have a VPS that will use rsnapshot to back up other servers via the 
private network.


The storage used to support this is a block storage device provided by 
my ISP.


Assuming I am understanding mount options and my use case correctly, 
I've generated the following for /etc/fstab:


17a48e68309bde92a.a /.snapshots ffs rw,nodev,noexec,nosuid 1 2

I'm assuming nosuid will not cause issues since rsnapshot/rsync *should* 
just be archiving everything identically the source. Of course, there 
are server partitions that will be backed up which do not set nosuid 
(e.g., /, /usr, /usr/local, /usr/X11R6), but the files, permissions, 
etc., should be identical on the backup regardless of having nosuid set. 
Do I understand this correctly?


Another concern is using attached storage and whether or not to use the 
sync option. I don't have enough experience with with the attached 
storage or rsnapshot/rsync to know if this can become an issue somewhere 
down the line, but I assumed on this matter the default is likely 
sufficient.


Thank you,


Paul

Re: WordPress pretty permalinks with httpd

[Paul Pace]

On 2024-11-25 11:09, Marcus MERIGHI wrote:

location match "/(wp%-json/.*)$" {
request rewrite "/index.php/%1"
fastcgi socket "/run/php-fpm.sock"
pass
}
Thank you for this one, especially. It fixes the REST API issue. 
Unfortunately, I don't understand why, which has at least as much to 
with my not understanding the difference in how the location match rules 
and location rules are applied to the request as not knowing how that 
WordPress feature actually works, but for sure the simple location not 
found rule I made is not identical in function to the nginx try_files 
rule.


Thank you,

Paul

WordPress pretty permalinks with httpd

[Paul Pace]

I have been working on getting pretty permalinks[1] to work properly in 
httpd. The WordPress project publishes configurations for Apache and 
nginx.[2]


I have a slightly better but still very weak grasp of nginx, so here is 
the key part of nginx.conf, as I understand it, for supporting pretty 
permalinks:


location / {
# This is cool because no php is touched for static content.
# include the "?$args" part so non-default permalinks doesn't break 
when using query string

try_files $uri $uri/ /index.php?$args;
}

My attempt to match nginx functionality in httpd.conf:

location "/" {
request rewrite "/index.php?$QUERY_STRING"
}
location not found "/*" {
request rewrite "/index.php?$REQUEST_URI"
}

I have also added lines to 
wp-content/themes/twentytwentyfive/functions.php:


These lines[3]:

function wpse427660_got_rewrite() {
return true;
}

add_filter( 'got_url_rewrite', 'wpse427660_got_rewrite' );

Or this line:

$is_nginx = ( str_contains( $_SERVER['SERVER_SOFTWARE'], 'nginx' ) || 
str_contains( $_SERVER['SERVER_SOFTWARE'], 'OpenBSD httpd' ) );


Using one or the other (not both at the same time) are so far as I can 
tell both the same in how WordPress ends up being served.


If anyone familiar with both httpd and nginx can enlighten to the 
differences between the behavior of the web servers in this regard, I 
would really appreciate it.


Also, if anyone else has worked on getting httpd to support WordPress 
pretty permalinks, did you review through the WordPress code? I am still 
getting the site health error "The REST API did not process the context 
query parameter correctly."


As far I can tell, WordPress detects nginx in wp-includes/vars.php.[4]

And supports the URL rewrite in wp-admin/includes/misc.php.[5]

WordPress does a bunch of other stuff when it detects nginx as a PHP 
variable.[6]


Thank you,

Paul

[1] https://wordpress.org/documentation/article/customize-permalinks/
[2] 
https://developer.wordpress.org/advanced-administration/server/web-server/

[3] https://wordpress.stackexchange.com/a/427664/47317
[4] 
https://github.com/WordPress/wordpress-develop/blob/1aa41dea3345c57cffce9059bbad728c86d1471a/src/wp-includes/vars.php#L127
[5] 
https://github.com/WordPress/wordpress-develop/blob/1aa41dea3345c57cffce9059bbad728c86d1471a/src/wp-admin/includes/misc.php#L46
[6] 
https://github.com/search?q=repo%3AWordPress%2Fwordpress-develop%20is_nginx&type=code

Re: pkg_info -Q: inconsistent search results

[Paul Pace]

On 12/9/24 7:58 AM, Maxim wrote:

The FAQ page [FAQ15] suggests to use "pkg_info -Q" to search the
collection of pre-compiled packages. When I search for "tcl",
I get a few "nextcloud" packages only, but no Tcl:

 $ pkg_info -v -Q tcl


I've been using lynx instead:

lynx --dump https://cdn.openbsd.org/pub/OpenBSD/7.6/packages/amd64/ \
| grep tcl


 PKG_PATH=
 nextcloud-27.1.11p0
 nextcloud-28.0.11
 nextcloud-28.0.12
 nextcloud-29.0.8
 nextcloud-29.0.9

At first I thought it was a bug. Then I read in pkg_info(1) that
the flag -Q makes it "show the names of all packages in the *first*
repository of the package search path" and that passing the flag
-a makes it search *all* repositories instead.

Indeed, now I can find Tcl:

 $ pkg_info -a -Q tcl | grep ^tcl | head -n 3
 tcl-8.5.19p6
 tcl-8.6.13
 tcl-snmptools-1.0p2

It's problem #1. I find the FAQ page instructions misleading.
Assuming pkg_info works as intended, shall the page be updated
to include the -a flag, for example so?--

 --- faq/faq15.html
 +++ faq/faq15.html
 @@ -147 +147 @@ architectures.
 -To search for any given package name, use the -Q flag of
 +To search for any given package name, use the -aQ flags of
 @@ -151 +151 @@ To search for any given package name, use the -Q
 -$ pkg_info -Q unzip
 +$ pkg_info -aQ unzip

* * *

I couldn't find what is a repository (in the context of the pkg_info(1)
man page), nor how they might be set up. I assume it's related to
installurl(5) and PKG_PATH env. var.

I haven't set or changed PKG_PATH. On the mirror that my system uses,
at  there are two directories:
packages and packages-stable. I assume they are the "repositories" and
they both form a default search path, where -stable comes first. The
-stable contains the aforementioned nextcloud packages, hence matching
the "tcl" search substring.

If so, that description of -Q (show names in the first repository)
doesn't match the behaviour of "pkg_info -Q", given the first repository
contains no match for the search substring. Take this example:

 $ pkg_info -Q unzip
 lunzip-1.14p0
 unzip-6.0p17
 unzip-6.0p17-iconv

 $ pkg_info -aQ unzip
 lunzip-1.14p0
 unzip-6.0p17
 unzip-6.0p17-iconv

There are no packages in -stable that match substring "unzip",
so (I assume) the search carries on to the second repository
in the search path, finds and returns something, then stops.

It's problem #2. I don't know whether it's an intended behaviour
to return names from the first *matched* repository. However,
the actual behaviour and the man page subtly disagree here.
I think it should be corrected in one place or another.

* * *

Overall it was a confusing user experience for me. I wanted to
make a simple substring search of all available packages.
"pkg_info -Q" is there to do it. However, inconsistency
between the FAQ page, man page, and the actual pkg_info behaviour
misled and confused me for a while. I also wonder why -aQ is
a special case rather than be included in -Q by default.

(Running on OpenBSD 7.6-stable/amd64.)

[FAQ15]: https://www.openbsd.org/faq/faq15.html#PkgFind

doas timeout feedback

[Paul Pace]

I know there are several posts regarding timeout, so I am aware this has 
been discussed, but I just want to provide some feedback.


I am only an enthusiast, but I have switched from Ubuntu Server to 
OpenBSD for all of my web servers and have now been a very happy user of 
OpenBSD for around 5 years or so.


I have found that the timeout on doas is a very regular and 
unnecessary-feeling interruption that pushes me in the following directions:


1. Create simpler user password. This way I can more easily and quickly 
complete a command.


2. Use doas su -l so I never have to enter a password.

Of course I don't like either of these as the user password can also be 
used to access the user account and I prefer to enter doas when 
performing commands that can really mess things up because it is a cue 
for my brain to pay a little extra attention to what I am typing.


Having used Ubuntu Server nearly since it was launched, I never really 
paid much attention to sudo timeout length because at 15 minutes, I am 
rarely hitting the timeout.


The 5-minute timeout in OpenBSD is rarely long enough for me to get what 
I need out of a man page, and often I am also referencing external 
package documentation while making configuration edits that require root 
privileges.


The timeout occurs most commonly while I am editing a file. After 
completing the edit, I often will edit another document requiring root 
privileges or I will test a configuration prior to reloading appropriate 
services. While the simple option of a 15-minute timeout as Ubuntu 
Server uses seemed to provide me enough time for this, another probably 
more complex not-worthwhile solution would be a 5-minute timeout where 
the timer begins after completing the most recent command as I'm rarely 
more than 5 minutes between running commands requiring root privilege, 
not including the time to edit a file.


I do find OpenBSD to be a fantastic project that I otherwise enjoy 
using, I just wish this timeout length to be 15 minutes or managed a 
little differently, somehow.


Thank you,


Paul

Re: It would be nice if the Elixir package supported multiple versions of Elixir

[Paul Pace]

On 3/6/25 12:59 PM, Volker Schlecht wrote:

Well, there is also the option of porting either for OpenBSD. Still not a
guarantee for anything, but at least problems won't come as a surprise. 
If that's

something you want to consider, I'd be happy to review and test.


I think based on the previous information you've provided, I am 
comfortable just soldiering through with everything as is, at least 
until I discover a problem I am unable to resolve.


Thank you for the very helpful responses!


Paul

It would be nice if the Elixir package supported multiple versions of Elixir

[Paul Pace]

Hello!

Since I don't know anything about creating or maintaining packages, I am 
not pretending to be requesting something trivial.


I am currently figuring out how to install and configure Akkoma (a fork 
of Pleroma), and while Akkoma currently supports up to Elixir 1.17, 
Pleroma only supports up to Elixir 1.16.


OpenBSD 7.6 packages has Elixir 1.17, and I can see the version in 
snapshots/packages/amd64/ is Elixir 1.18. AFAICT, there happens to be 
one contributor to Akkoma that has been running OpenBSD, so I speculate 
that before OpenBSD 7.8 is released there will be an update to Akkoma to 
support Elixir 1.18 at which point I would be able to upgrade to OpenBSD 
7.8, but Pleroma users may be out of luck for any supported OpenBSD 
version after 7.8 is released.


The OpenBSD Erlang package supports multiple versions of OTP, so I just 
want to request if the same thing can be done for Elixir? Or if 
different packages can be available for versions of Elixir?


Thank you,


Paul

Re: It would be nice if the Elixir package supported multiple versions of Elixir

[Paul Pace]

On 2025-03-06 11:54, Volker Schlecht wrote:

On 2025-03-06 07:48, Paul Pace wrote:
I am currently figuring out how to install and configure Akkoma (a 
fork of Pleroma), and while Akkoma currently supports up to Elixir 
1.17, Pleroma only supports up to Elixir 1.16.


Did you actually try to run Pleroma on 1.18.x? While the docs say that 
it needs
Elixir < 1.17, they run CI on 1.17.1 and there is a really solid chance 
that

both Akkoma and Pleroma will just work on 1.18.3.

While I'm not *totally* opposed to keeping older Elixir versions 
around, in my
experience they are very committed to keeping their minor releases 
backwards

compatible, and quite good about it, too.


Indeed, I have not tried installing on a newer version than the docs 
state.


My searching on the projects discovered previous versions of Pleroma 
that failed to install due to the OpenBSD version being newer than 
Pleroma supported, so the concern I end up with is wondering what 
happens if there is some update to either Elixir or Pleroma/Akkoma that 
breaks something.


That said, I know little about Plermoa or Elixir on the development 
side, so it could be that was an unusual circumstance. I can certainly 
move forward with things as they are and in the event I have an issue, 
future me is usually able to figure out what to do about it. (o;


Thank you,


Paul