Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
Дана 24/04/15 02:25AM, Jeremy Mates написа: > TL;DR it's TERMINFO related or when ~/.terminfo exists and no TERM file > exists therein. Also trying to read "none" (or maybe also "none.db" when > the TERMINFO thing happens) from the current working directory might not > be a good idea, if an attacker can put naughty things into either of > those files and a sh or ksh or whatever is run in a suitable directory? Just to clarify, this particular instance of this issue seems to be related to terminfo. In general, as I stated earlier, the log message ... [program_name]: vfprintf %s NULL in "[format_string]" is output whenever NULL is passed to the *printf family of functions. That could be vfprintf, but also printf, fprintf, sprintf... and so on and so forth. The inconvenient part of this otherwise very useful mechanism of detecting incorrect code is that there is no precise indication of the location in the source code which is incorrectly written in this manner. It could be the program itself, or it could be one of the libraries it uses, as is likely the case here. The only clue is the format string in the message, which could be not distinctive enough.
Re: OpenBSD Installation Doesn't Detect NVMe SSD, but Detects My USB Drives
On Mon, Apr 15, 2024, at 1:29 AM, aliyu...@tutanota.com wrote: > Hello, > > I'm currently trying to install OpenBSD on my laptop, and I'm coming > across a problem. The installation only detects my installation drive > and my other USB flash drive that I use for data storage, but not my > NVMe SSD I want to do an installation on. > > This same problem also occurs in NetBSD, but not FreeBSD. The UEFI > setup acknowledges my drive as a Non-RAID disk, and Linux also shows > it as nvme0n1, so there isn't any problems with the drive itself. > > Running 'sysctl hw.disknames' only shows 3 disks: > 'sd0' (my installation drive), 'sd1' (my media drive), and 'rd0' > > The disk currently has Alpine Linux installed on it, if that gives > more information. > > Thanks for any help! > > Ali Yuruk Sorry to hear of your trouble. I recommend including some actionable information, such as: - make and model of the NVMe drive - OpenBSD installer dmesg with the drive not recognized - FreeBSD or Linux dmesg with the drive working Brian Conway Owner RCE Software, LLC
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
On Mon, Apr 15, 2024 at 02:25:04AM +, Jeremy Mates wrote: > TL;DR it's TERMINFO related or when ~/.terminfo exists and no TERM file > exists therein. Also trying to read "none" (or maybe also "none.db" when > the TERMINFO thing happens) from the current working directory might not > be a good idea, if an attacker can put naughty things into either of > those files and a sh or ksh or whatever is run in a suitable directory? > hi. i have actually been seeing these for months, but just ignored them. i'm not sure your theory covers everything though: $ echo $TERM wsvt25 $ ls -l ~/.terminfo/w total 12 -r--r--r-- 1 jmc jmc 1597 Apr 15 06:27 wsvt25 -rw-r--r-- 1 jmc jmc 1522 Aug 1 2020 wsvt25-noacs -rw-r--r-- 1 jmc jmc 865 Aug 1 2020 wsvt25-ul $ tail /var/log/messages Apr 15 06:56:21 manila reorder_kernel: kernel relinking done Apr 15 06:57:03 manila -ksh: vfprintf %s NULL in "%.*s" Apr 15 06:57:17 manila last message repeated 4 times Apr 15 06:57:17 manila ksh: vfprintf %s NULL in "%.*s" Apr 15 06:57:17 manila mutt: vfprintf %s NULL in "%.*s" Apr 15 06:57:42 manila -ksh: vfprintf %s NULL in "%.*s" Apr 15 06:59:12 manila sh: vfprintf %s NULL in "%.*s" Apr 15 06:59:12 manila vim: vfprintf %s NULL in "%.*s" Apr 15 07:00:18 manila ksh: vfprintf %s NULL in "%.*s" Apr 15 07:02:35 manila ksh: vfprintf %s NULL in "%.*s" that's basically me logging in, starting tmux (4 shells+mutt). so i'm not sure it's exactly as you describe. curious... jmc
Acme-client error getting validation data when updating LetsEncrypt certs on 7.5
I started seeing an error where acme-client is not able to renew Lets Encrypt certificates. I've tried on several different servers but they all display the same error: "Error getting validation data" Is anyone else seeing the same behavior? Here are my configurations; these have been working for a couple years now. Thanks in advance for any assistance. $ uname -a OpenBSD www-server 7.5 GENERIC#79 amd64 acme-client configuration - authority letsencrypt { api url "https://acme-v02.api.letsencrypt.org/directory"; account key "/etc/acme/letsencrypt-privkey.pem" } authority letsencrypt-staging { api url "https://acme-staging-v02.api.letsencrypt.org/directory"; account key "/etc/acme/letsencrypt-staging-privkey.pem" } domain www-server.example.com { domain key "/etc/ssl/private/www-server.example.com.key.pem" domain full chain certificate "/etc/ssl/certs/www-server.example.com.chain.pem" sign with letsencrypt } httpd configuration --- server "www-server.example.com" { listen on * tls port 443 tls { certificate "/etc/ssl/certs/www-server.example.com.chain.pem" key "/etc/ssl/private/www-server.example.com.key.pem" protocols "TLSv1.3,TLSv1.2" } hsts { max-age 31536000 preload subdomains } log style combined log { access "access.log", error "error.log" } directory auto index root "/htdocs/www" location "/.well-known/acme-challenge/*" { root "/acme" request strip 2 } } server "www-server.example.com" { listen on * port 80 location "/.well-known/acme-challenge/*" { root "/acme" request strip 2 } block return 301 "https://www-server.example.com$REQUEST_URI"; } directory permissions for acme-client verification -- # find /var/www/htdocs/www/.well-known/ -ls 518754 drwxr-xr-x3 w3admin staff 512 Mar 16 2022 /var/www/htdocs/www/.well-known/ 518764 drwxr-xr-x2 w3admin staff 512 Mar 16 2022 /var/www/htdocs/www/.well-known/acme-challenge output of running the client manually - # acme-client -v www-server.example.com acme-client: /etc/ssl/certs/www-server.example.com.chain.pem: certificate renewable: 29 days left acme-client: https://acme-v02.api.letsencrypt.org/directory: directories acme-client: acme-v02.api.letsencrypt.org: DNS: 172.65.32.248 acme-client: acme-v02.api.letsencrypt.org: DNS: 2606:4700:60:0:f53d:5624:85c7:3a2c acme-client: dochngreq: https://acme-v02.api.letsencrypt.org/acme/authz-v3/338785251177 acme-client: challenge, token: iG6ptUbu8wblA1NcB36yC7PRi1-h-lXoMx4MAOn0CoE, uri: https://acme-v02.api.letsencrypt.org/acme/chall-v3/338785251177/Efb4Qg, status: 0 acme-client: /var/www/acme/iG6ptUbu8wblA1NcB36yC7PRi1-h-lXoMx4MAOn0CoE: created acme-client: https://acme-v02.api.letsencrypt.org/acme/chall-v3/338785251177/Efb4Qg: challenge acme-client: order.status 0 acme-client: dochngreq: https://acme-v02.api.letsencrypt.org/acme/authz-v3/338785251177 acme-client: challenge, token: iG6ptUbu8wblA1NcB36yC7PRi1-h-lXoMx4MAOn0CoE, uri: https://acme-v02.api.letsencrypt.org/acme/chall-v3/338785251177/Efb4Qg, status: -1 acme-client: order.status -1 acme-client: dochngreq: https://acme-v02.api.letsencrypt.org/acme/authz-v3/338785251177 acme-client: 203.0.113.51: Fetching https://www-server.example.com/.well-known/acme-challenge/iG6ptUbu8wblA1NcB36yC7PRi1-h-lXoMx4MAOn0CoE: Error getting validation data acme-client: bad exit: netproc(20490): 1
Re: OpenBSD Installation Doesn't Detect NVMe SSD, but Detects My USB Drives
On Mon, Apr 15, 2024 at 08:29:21AM +0200, aliyu...@tutanota.com wrote: > > I'm currently trying to install OpenBSD on my laptop, and I'm coming > across a problem. The installation only detects my installation drive > and my other USB flash drive that I use for data storage, but not my > NVMe SSD I want to do an installation on. > > This same problem also occurs in NetBSD, but not FreeBSD. The UEFI > setup acknowledges my drive as a Non-RAID disk, and Linux also shows > it as nvme0n1, so there isn't any problems with the drive itself. As Brian mentioned, it would generally be useful to have dmesg output from a system where the drive works as well as from the OpenBSD config where the drive is not recognized. That said, I would recommend looking into the BIOS options to see whether there is a setting for the storage controller mode. In an ASUS laptop I bought a little while back, the options were somewhat non-intuitive: "The option turned out to live in the BIOS' Advanced menu, labeled VMD setup menu, where you set the Enable VMD controller option to Disabled." which made the drive visible to OpenBSD. (the fuller story is at https://nxdomain.no/~peter/blog_wild_wild_world_of_windows.html or with nicer formatting and trackers https://bsdly.blogspot.com/2021/07/the-impending-doom-of-your-operating.html) In your case, the relevant option (if it exists) may be labeled something completely different. But it's likely worth checking for. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
On Mon, 15 Apr 2024 14:17:10 +0200, =?utf-8?B?0KHRgtGA0LDRhdC40ZrQsCDQoNCw0LTQu NGb?= wrote: > Just to clarify, this particular instance of this issue seems to be related t > o > terminfo. > > In general, as I stated earlier, the log message > > ... [program_name]: vfprintf %s NULL in "[format_string]" > > is output whenever NULL is passed to the *printf family of functions. That > could be vfprintf, but also printf, fprintf, sprintf... and so on and so fort > h. > The inconvenient part of this otherwise very useful mechanism of detecting > incorrect code is that there is no precise indication of the location in the > source code which is incorrectly written in this manner. It could be the > program itself, or it could be one of the libraries it uses, as is likely the > case here. The only clue is the format string in the message, which could be > not distinctive enough. I believe this is fixed by: CVSROOT:/cvs Module name:src Changes by: mill...@cvs.openbsd.org 2024/04/12 08:10:28 Modified files: lib/libcurses/tinfo: read_entry.c Log message: Avoid snprintf() of NULL when _nc_get_source() returns NULL. The filename buffer is not actually used in this case but it is safer to set it to the empty string than to leave it uninitialized. OK tb@
Re: OpenBSD Installation Doesn't Detect NVMe SSD, but Detects My USB Drives
On Mon, Apr 15, 2024 at 08:29:21AM +0200, aliyu...@tutanota.com wrote: Hello, I'm currently trying to install OpenBSD on my laptop, and I'm coming across a problem. The installation only detects my installation drive and my other USB flash drive that I use for data storage, but not my NVMe SSD I want to do an installation on. SATA settings in your BIOS might be worth a try: if sata mode is set to RAID it might help to switch to ACPI - there was a thread recently about that on this list: https://marc.info/?t=17124438522&r=1&w=2 -- Wolfgang
Re: OpenBSD Installation Doesn't Detect NVMe SSD, but Detects My USB Drives
On Mon, Apr 15, 2024 at 08:38:51PM +0200, Wolfgang Pfeiffer wrote: On Mon, Apr 15, 2024 at 08:29:21AM +0200, aliyu...@tutanota.com wrote: Hello, I'm currently trying to install OpenBSD on my laptop, and I'm coming across a problem. The installation only detects my installation drive and my other USB flash drive that I use for data storage, but not my NVMe SSD I want to do an installation on. SATA settings in your BIOS might be worth a try: if sata mode is set to RAID it might help to switch to ACPI [ .. ] Wrong: Not ACPI, but AHCI. Sorry. -- Wolfgang
Issue with pf route-to and routing tables
Hi all, I'm greatly enjoying OpenBSD and have it on most of my devices as I try to set up my "perfect lab". I would like some feedback / thoughts about one behaviour which I don't quite get. I have a VM for the world facing side of my network. I have a wireguard network to link it up to a home router and other devices. My wireguard traffic is coming onto my VM through wg0. On my home router, I'm redirecting all wifi traffic to wg0 using the routing tables like so: default192.168.0.1 wg0 IP_VM IP_Gatewaybse0 192.168.0.1 wg0 wg0 And natting outbound traffic on wg0 like so: pass out on wg0 from $int_if:network nat-to wg0 I wanted to try out using route-to on my VM instead of using different rdomain or just to try something else. I have another wireguard tunnel, wg1 to relay my internal traffic further. I did not touch the routing tables at all and have something like: pass in on wg0 inet from wg0:network to !wg0:network route-to wg1 pass out on wg1 nat-to wg1 Works like a charm. Now what I don't get is that for troubleshooting purposes, I needed to send some traffic to the world on my VM (instead of onward through wg1) and I initially tried: pass in log on wg0 inet from wg0:network to !wg0:network route-to vio0 pass out log on $vio0 nat-to $vio0 Routing tables: default IP_Gateway vio0 _Gateway MAC_Gateway vio0 But this does not work. Removing "route-to vio0" does work, eg. pass in log on wg0 inet from wg0:network to !wg0:network #route-to vio0 pass out log on vio0 nat-to vio0 I'm guessing that this may have to be since it's routed "twice"? Eg. routed-to and a second time with the default route of the routing tables? So I understand why route-to is not necessary in this case, but I would think route-to should still work and that means I don't get how it's working? I've tried used pflog0 to check the above rules but cannot see any difference: in both cases, it's passing in on wg0 through vio0 and src IP is rewritten to VM public IP. I'm thinking of more complex rules to split traffic from wg0 between wg1 and vio0 based on the ports and using route-to vio0 seemed the easiest way to do so. Thanks in advance, Thomas
Re: Firewall setup
They both give a syntax error by booting. Op 14-04-2024 om 17:45 schreef Zé Loff: pass in on $int_if proto udp to port 53 pass in on $int_if proto udp to $nameservers port 53
Re: Firewall setup
This gives the following error messages when booting: no IP address found for igc1:network /etc/pf.conf:41: could not parse host specification no IP address found for igc2:network /etc/pf.conf:42: could not parse host specification Op 14-04-2024 om 19:59 schreef Peter N. M. Hansteen: On Sun, Apr 14, 2024 at 05:09:01PM +0200, Karel Lucas wrote: Hi all, Everything about PF is all very confusing to me at the moment, so any help is appreciated. So let's start simple and then proceed step by step. I want to continue with ping so that I can test the connection to the internet. This works: ping -c 10 195.121.1.34. But this doesn't work: ping -c 10 www.apple.com. As others have stated, I have a problem with using DNS servers on the internet. The PF ruleset needs to be adjusted for this, but it is still not clear to me how to do that. What else do I need to get ping to work correctly? To get started simply, I created a new pf.conf file, see below. I'd put this somewhere after your block rules: pass inet proto { tcp, udp } from igc1:network to port $client_out pass inet proto { tcp, udp } from igc2:network to port $client_out - that way you will actually use the macro. But the macro sitll references the invalid service nportntp (you probably want ntp instead), and I would think that the services "446, cvspserver, 2628, 5999, 8000, 8080" are unlikely to be useful unless you *know* you need to pass traffic for those.
Re: Firewall setup
On Mon, Apr 15, 2024 at 10:01:59PM +0200, Karel Lucas wrote: > They both give a syntax error by booting. > > Op 14-04-2024 om 17:45 schreef Zé Loff: > > pass in on $int_if proto udp to port 53 > > pass in on $int_if proto udp to $nameservers port 53 You're not giving us a lot to work with here. Off the top of my head, seeing that your int_if macro is a list of two interfaces, that may well be your problem (or one of them). The rule syntax is not really intended to deal with a list of interfaces following 'on'. It is likely more useful to treat the two interfaces separately. The other option - if your network layout is such that it makes sense to treat them to the same rule criteria - would be to make an interface group with both interfaces as members, then use the interface group name in your rules. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Firewall setup
On Mon, Apr 15, 2024 at 10:09:31PM +0200, Karel Lucas wrote: > This gives the following error messages when booting: > no IP address found for igc1:network > /etc/pf.conf:41: could not parse host specification > no IP address found for igc2:network > /etc/pf.conf:42: could not parse host specification This sounds to me like those interfaces either do not exist or have not been correctly configured. Are those interfaces configured, as in do they have IP addresses? the output of ifconfig igc1 and ifconfig igc2 will show you. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Firewall setup
Op 14-04-2024 om 21:57 schreef Jens Kaiser: Hello Karel, if you want to start simply, then I would recommend to remove all marcos from your pf.conf which are not referenced. You can add them later if needed. As already state by others, there is a syntax error in marco martians. If there are syntax errors in pf.conf, the rules are not loaded at all. These have now been resolved, sse below. Also correct the syntax errors in the rules "Letting ping through". The key word "on" without interfacename, -group or keyword any looks incorrect. Give it a parameter or remove it. As far as I can see there are no errors in the ping rules. the key words "on", "group" or "any" do not appear there. Moreover, I have copied these rules, except the key words "log", exactly from Peter Hansteen's book (The book of PF), just like the rules of the martians. Please check your current running configuration with > pfctl -sr It prints out all currently active rules. If something behaves too wired, it can help to proof that the ruleset in /etc/pf.conf is the same as we assume to be active in the kernel. Because of the syntax errors I would guest that this is not true in your case. After correcting some errors, I reloaded pf.conf and found no errors. Here I give the output of pfctl -sr: match in all scrub (no-df max-mss 1440) block return in all block return in quick on igc0 inet from any to <__automatic_628bc734_1> pass log inet proto icmp all icmp-type echoreq pass log inet proto icmp all icmp-type echorep pass log inet proto icmp all icmp-type unreach pass log inet6 proto ipv6-icmp all icmp6-type echoreq pass log inet6 proto ipv6-icmp all icmp6-type echorep pass log inet6 proto ipv6-icmp all icmp6-type unreach pass out all flags S/SA /etc/pf.conf: ext_if = igc0 # The interface to the outside world int_if = "{ igc1, igc2 }" # The interfaces to the private hosts # localnet = "192.168.2.0/24" # Hosts on the screened LAN # tcp_services = "{ smtp, domain, www, auth, http, https, pop3, pop3s }" # udp_services = "{ domain, ntp }" # email = "{ smtp, imap, imaps, imap3, pop3, pop3s }" icmp_types = "{ echoreq, echorep, unreach }" icmp6_types = "{ echoreq, echorep, unreach }" # nameservers = "{ 195.121.1.34, 195.121.1.66 }" # client_out = "{ ssh, domain, pop3, auth, nportntp, http, https, }" martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, \ 10.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, \ 0.0.0.0/8, 240.0.0.0/4 }" # Options: set block-policy return set skip on lo # Normalize packets: match in all scrub ( no-df max-mss 1440 ) block in all # block stateless traffic block in quick on $ext_if from $martians to any block out quick on $ext_if from any to $martians # Letting ping through: pass log inet proto icmp icmp-type $icmp_types pass log inet6 proto icmp6 icmp6-type $icmp6_types pass out all
Re: Firewall setup
That's a possibility I hadn't thought of yet. But how do I do that, and on which page can I find that in your book? Op 15-04-2024 om 22:17 schreef Peter N. M. Hansteen: The other option - if your network layout is such that it makes sense to treat them to the same rule criteria - would be to make an interface group with both interfaces as members, then use the interface group name in your rules.
Re: Firewall setup
Op 15-04-2024 om 22:20 schreef Peter N. M. Hansteen: On Mon, Apr 15, 2024 at 10:09:31PM +0200, Karel Lucas wrote: This gives the following error messages when booting: no IP address found for igc1:network /etc/pf.conf:41: could not parse host specification no IP address found for igc2:network /etc/pf.conf:42: could not parse host specification This sounds to me like those interfaces either do not exist or have not been correctly configured. Are those interfaces configured, as in do they have IP addresses? the output of ifconfig igc1 and ifconfig igc2 will show you. Output from ifconfig igc0: igc0: flags=8b43 mtu 1500 lladdr 7c:2b:e1:13:dd:f4 index 1 priority 0 llprio 3 media: Ethernet autoselect (1000baseT full-duplex) sratus: active Output from ifconfig igc1: igc1: flags=8b43 mtu 1500 lladdr 7c:2b:e1:13:dd:f5 index 2 priority 0 llprio 3 media: Ethernet autoselect (1000baseT full-duplex) sratus: active Output from ifconfig igc2: igc2: flags=8b43 mtu 1500 lladdr 7c:2b:e1:13:dd:f6 index 3 priority 0 llprio 3 media: Ethernet autoselect (none) status: no carrier /etc/hostname.bridge0: add igc0 add igc1 add igc2 blocknonip igc0 blocknonip igc1 blocknonip igc2 up /etc/hostname.igc0: up /etc/hostname.igc1: up /etc/hostname.igc2: up
Re: Firewall setup
On 2024-04-15, Karel Lucas wrote: > /etc/hostname.bridge0: > add igc0 add igc1 add igc2 blocknonip igc0 blocknonip igc1 blocknonip > igc2 up bridging with PF is an advanced topic, please get familiar with PF on a standard routed firewall first -- Please keep replies on the mailing list.
Re: Acme-client error getting validation data when updating LetsEncrypt certs on 7.5
The location { … } block in the port 80 server is non-functional because all requests are redirected to HTTPS. Add a `pass` to make it functional. Note: If you do then you don’t need the corresponding location { … } block in the port 443 server any more. Also, instead of: > block return 301 "https://www-server.example.com$REQUEST_URI“ you could write: block return 301 "https://$HTTP_HOST$REQUEST_URI"; server "www-server.example.com" { listen on * port 80 location "/.well-known/acme-challenge/*" { root "/acme" request strip 2 pass } block return 301 "https://$HTTP_HOST$REQUEST_URI"; } But those are just optimisations that don’t address your issue. To start debugging the issue put a small test file into your /var/www/acme directory and test access using e.g. curl: # echo 'test'>/var/www/acme/test Preferably from a different host: $ curl --url 'http://www-server.example.com/.well-known/acme-challenge/test' HTH Mike PS. see more comments below… > Am 15.04.2024 um 15:02 schrieb rea...@catastrophe.net: > > I started seeing an error where acme-client is not able to renew > Lets Encrypt certificates. I've tried on several different servers > but they all display the same error: "Error getting validation data" > > Is anyone else seeing the same behavior? > > Here are my configurations; these have been working for a couple years > now. Thanks in advance for any assistance. > > > $ uname -a > OpenBSD www-server 7.5 GENERIC#79 amd64 > > acme-client configuration > - > > authority letsencrypt { >api url "https://acme-v02.api.letsencrypt.org/directory"; >account key "/etc/acme/letsencrypt-privkey.pem" > } > > authority letsencrypt-staging { >api url "https://acme-staging-v02.api.letsencrypt.org/directory"; >account key "/etc/acme/letsencrypt-staging-privkey.pem" > } > > domain www-server.example.com { > domain key "/etc/ssl/private/www-server.example.com.key.pem" > domain full chain certificate > "/etc/ssl/certs/www-server.example.com.chain.pem" >sign with letsencrypt > } > > > httpd configuration > --- > > server "www-server.example.com" { > listen on * tls port 443 > tls { >certificate "/etc/ssl/certs/www-server.example.com.chain.pem" >key "/etc/ssl/private/www-server.example.com.key.pem" >protocols "TLSv1.3,TLSv1.2" > } > hsts { >max-age 31536000 >preload >subdomains > } > log style combined > log { access "access.log", error "error.log" } > directory auto index > root "/htdocs/www" > location "/.well-known/acme-challenge/*" { >root "/acme" >request strip 2 > } > } > > server "www-server.example.com" { > listen on * port 80 > location "/.well-known/acme-challenge/*" { >root "/acme" >request strip 2 > } > block return 301 "https://www-server.example.com$REQUEST_URI"; > } > > > directory permissions for acme-client verification > -- > > # find /var/www/htdocs/www/.well-known/ -ls > 518754 drwxr-xr-x3 w3admin staff 512 Mar 16 2022 > /var/www/htdocs/www/.well-known/ > 518764 drwxr-xr-x2 w3admin staff 512 Mar 16 2022 > /var/www/htdocs/www/.well-known/acme-challenge These directories are irrelevant. You want to look at: /var/www/acme as your location { … } block reroutes /.well-known/acme-challenge to /acme (in the /var/www chroot(2) environment). /var/www/acme is there by default and it should have 755 root:daemon permissions. > > > output of running the client manually > - > > # acme-client -v www-server.example.com > acme-client: /etc/ssl/certs/www-server.example.com.chain.pem: certificate > renewable: 29 days left > acme-client: https://acme-v02.api.letsencrypt.org/directory: directories > acme-client: acme-v02.api.letsencrypt.org: DNS: 172.65.32.248 > acme-client: acme-v02.api.letsencrypt.org: DNS: > 2606:4700:60:0:f53d:5624:85c7:3a2c > acme-client: dochngreq: > https://acme-v02.api.letsencrypt.org/acme/authz-v3/338785251177 > acme-client: challenge, token: iG6ptUbu8wblA1NcB36yC7PRi1-h-lXoMx4MAOn0CoE, > uri: https://acme-v02.api.letsencrypt.org/acme/chall-v3/338785251177/Efb4Qg, > status: 0 > acme-client: /var/www/acme/iG6ptUbu8wblA1NcB36yC7PRi1-h-lXoMx4MAOn0CoE: > created > acme-client: > https://acme-v02.api.letsencrypt.org/acme/chall-v3/338785251177/Efb4Qg: > challenge > acme-client: order.status 0 > acme-client: dochngreq: > https://acme-v02.api.letsencrypt.org/acme/authz-v3/338785251177 > acme-client: challenge, token: iG6ptUbu8wblA1NcB36yC7PRi1-h-lXoMx4MAOn0CoE, > uri: https://acme-v02.api.letsencrypt.org/acme/chall-v3/338785251177/Efb4Qg, > status: -1 > acme-client: order.status -1 > acme-client: dochngreq: > https://acme-v02.api.letsencrypt.org/acme/authz-v3/338785251177 > acme-client: 203.0.113.51: Fetching > https://www-server.example.com/.well-known/acme-challenge/iG6ptUbu8wblA
Re: Acme-client error getting validation data when updating LetsEncrypt certs on 7.5
On Tue, Apr 16, 2024 at 01:54:31AM +0200, Mike Fischer wrote: >The location { … } block in the port 80 server is non-functional because all >requests are redirected to HTTPS. Add a `pass` to make it functional. Note: If >you do then you don’t need the corresponding location { … } block in the port >443 server any more. > >Also, instead of: >> block return 301 "https://www-server.example.com$REQUEST_URI“ >you could write: > block return 301 "https://$HTTP_HOST$REQUEST_URI"; > >server "www-server.example.com" { > listen on * port 80 > location "/.well-known/acme-challenge/*" { > root "/acme" > request strip 2 > pass > } > block return 301 "https://$HTTP_HOST$REQUEST_URI"; >} > >But those are just optimisations that don’t address your issue. Thanks. >To start debugging the issue put a small test file into your /var/www/acme >directory and test access using e.g. curl: > ># echo 'test'>/var/www/acme/test > >Preferably from a different host: >$ curl --url 'http://www-server.example.com/.well-known/acme-challenge/test' > [..] > >These directories are irrelevant. You want to look at: /var/www/acme as your >location { … } block reroutes /.well-known/acme-challenge to /acme (in the >/var/www chroot(2) environment). > >/var/www/acme is there by default and it should have 755 root:daemon >permissions. All good now. I don't know what actually fixed it, but it's fixed! Thanks again.
Re: OpenBSD Installation Doesn't Detect NVMe SSD, but Detects My USB Drives
Hello, Sorry, I think I sent the mails directly to the people that replied to me. I'm using an ASUS laptop and disabling the VMD controller in UEFI setup worked, and now my drive is visible as 'sd0' Thanks! Ali Yuruk Apr 15, 2024, 21:47 by r...@gmx.net: > On Mon, Apr 15, 2024 at 08:29:21AM +0200, aliyu...@tutanota.com wrote: > >> Hello, >> >> I'm currently trying to install OpenBSD on my laptop, and I'm coming >> across a problem. The installation only detects my installation drive >> and my other USB flash drive that I use for data storage, but not my >> NVMe SSD I want to do an installation on. >> > > SATA settings in your BIOS might be worth a try: if sata mode is > set to RAID it might help to switch to ACPI - there was a thread > recently about that on this list: > > https://marc.info/?t=17124438522&r=1&w=2 > > -- > Wolfgang >
Re: Firewall setup
I give up. The obviously incomplete, hand edited ifconfig output shows three interfaces that are (or appear to be, judging from the excerpts that we are given) not configured with IP addresses, two of which have a link, while the last does not. For reasons unknown these three are joined in a three-way bridge. >From the tiny crumbs of information you have deigned to reveal to us, it is not at all clear what it is you are trying to achieve. That this configuration does not do anything useful is however no surprise at all. Once you can describe what it is your Rube Goldberg contraption is supposed to do, competent people here might offer some advice on how to make things work properly. Until that happens, I for one will simply ignore anything from that source. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.