Re: IPsec "road warrior" VPN not getting set up properly.
Stuart Henderson wrote: > Currently iked (and isakmpd) use flows, not routes. These use messages > on the PF_KEY socket not the route socket. (If I watch route -nv monitor > while iked starts and brings up tunnels, I don't see any messages). > > IIUC the parts you found which currently exist are for the "iface" > option which tells an iked initiator (a machine, typically but not > necessarily mobile) to use mode-config to fetch an address, and > configure it on an interface. > > There is a diff for route-based IPsec which does use the route table > (https://marc.info/?l=openbsd-tech=168844868110327=2), but I think > if you were using that, you could just look for messages relating to > sec(4) interfaces anyway and not have to worry about labels? Oops, you are correct. I was doing my initial testing on the client (since it's my primary desktop) and didn't look closely at at the routes that were getting set up. The good news, though, is that now I can get away without route labels even before the sec(4) code gets merged. Since the flows that are visible in the PF_KEY socket are tunneled routes only, I can apply the following reasoning: for this use case, any flow (not route) for which one side is a single address and the other side is "::" (for "any") is one that needs to be proxied. So now my monitoring program needs to monitor two sockets instead of one, but I don't have to make any changes to iked to support it. > If you're on a low end VPS that is not already doing filtering like > this, you may find that later on they change to implement that, when > they figure out why the L3 switch they're using as a router is > running out of steam when handling junk traffic... As Zack may have figured out earlier, I am in fact using Vultr. Their IPv6 guide for OpenBSD specifically says they use routeradv, neighbrsol, and neighbradv ICMPv6 messages to identify the active IP addresses, and they also specifically permit the addition of additional IPv6 addresses to the same interface. Source: https://www.vultr.com/docs/configuring-ipv6-on-your-vps/#IPv6_on_OpenBSD The consensus in this thread seems to be that Vultr is doing it wrong and their bad decisions will cause problems both for them (because their gateway router is susceptible to NDP cache exhaustion from external scans even if I don't do anything creative with my host configuration) and for me (because I've spent the last week in a fifteen-email exchange about figuring out how to make down with a /64 instead of using that time to figure out how to configure dhcpcd and rad to make use of the /56 that is my IETF birthright). I won't try to defend Vultr's IPv6 choices here; I can only say that since they're explicitly telling me to use NDP to request IPv6 addresses then they won't change that behavior behind my back without telling me. >> Since my proposal to have iked enable NDP proxying itself failed to >> gain traction I looked into other options (that don't involve >> requesting a larger subnet from my ISP and VPS providers). > > I think you're thinking of having a subnet routed across as something > that is going to cause more pain for the upstream provider. > > The reality is the opposite. > > If the provider doesn't understand this, there are probably a few > other things they don't understand too, it would be a bit of a red > flag for me. > > Yes there are a huge number of addresses in a /64, but really a /64 > is what providers are expected to assign where they would assign an > individual address for IPv4. > > For a situation where you'd have a couple of addresses with v4, > with v6 it's really normal to have a /56 or /48. In Vultr's defense, they did only assign me a single IPv4 address. You would probably counter, "Yes, but if you want your VPN connection to support IPv4 when the server has a single address then you have to use NAT, which you can also do with IPv6. If you want to avoid using NAT, then for IPv4 you should request another address and for IPv6 you should request a larger subnet." And to *that* I will admit that Vultr has an option to buy additional IPv4 addresses but doesn't have an option to increase the size of your IPv6 subnet. Presumably this is where you and Zack would both say, "Exactly, that's the problem." So OK, the final conclusions here seem to be: - Vultr is bad for not offering a way to allocate and statically route a larger subnet. (Note that it would also work for me if they statically routed the entire /64 to my VPS instead of filtering it in their gateway router, but they don't offer a way to do that either.) - The NDP proxy trick is too hacky to justify making changes to iked to make it easier to implement. - I can still automate NDP proxying by creating a second process that monitors the PF_KEY socket for changes to the "flow table" to get the tunnel addresses so it can enable and disable NDP proxying when clients connect and disconnect. Even better, I should be able to do this without any
Re: iked server/client OBSD/OBSD
Questions about cert for roadwarrior and more? Why 192.168.1.79? i was expecting 10.0.5.x please. Why did you expect that? spi=0xc166e8f236679cc9: recv IKE_SA_INIT res 0 peer 45.77.223.7:500 local 192.168.1.79:500, 255 bytes, policy 'roadwarrior' 192.168.1.79 is your local IP, which is on the interface with a link to the default gateway. $ route -n show -inet If you have multiple IPs and you want to force iked to use a specific one, you have to use "local": local 10.0.5.x peer 45.77.223.7 \ spi=0xaf891eb37dd8f4cc: ca_getreq: no valid local certificate found for FQDN/roadwarrior spi=0xaf891eb37dd8f4cc: ca_getreq: using local public key of type RSA_KEY spi=0xaf891eb37dd8f4cc: send IKE_AUTH req 1 peer 45.77.223.7:4500 local 192.168.1.79:4500, 947 bytes, NAT-T spi=0xaf891eb37dd8f4cc: recv IKE_AUTH res 1 peer 45.77.223.7:4500 local 192.168.1.79:4500, 65 bytes, policy 'roadwarrior' spi=0xaf891eb37dd8f4cc: sa_free: authentication failed notification from peer Just a guess, since I have never worked with trusted public keys, but maybe you have to copy the clients local.pub it into /etc/iked/pubkeys/fqdn/roadwarrior (not /etc/iked/pubkeys/fqdn/roadwarrior/local.pub) or /etc/iked/pubkeys/ipv4/A.B.C.D on the server.
Re: [SPAM] Re: iked server/client OBSD/OBSD
> >> what is wrong? client side iked.conf: >> >> ikev2 'roadwarrior' active esp \ >> from dynamic to any \ >> peer 45.77.223.7 \ >> srcid roadwarrior \ >> dstid server1.domain \ >> request address any \ >> iface lo1 >> >> # iked -dv >> /etc/iked.conf: 43: invalid iface > > lo1 must exist: > # ifconfig lo1 create > > > To create it at a reboot: > # touch /etc/hostname.lo1 > OK Thomas thank you. Questions about cert for roadwarrior and more? Why 192.168.1.79? i was expecting 10.0.5.x please. >From Road Warrior after deletetion of certs, exept local.pub and local.key: # iked -dv ikev2 "roadwarrior" active tunnel esp inet from 0.0.0.0 to 0.0.0.0/0 from :: to ::/0 local any peer 45.77.223.7 ikesa enc aes-128-gcm enc aes-256-gcm prf hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 group curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group modp3072 group modp2048 group modp1536 group modp1024 ikesa enc aes-256 enc aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth hmac-sha2-384 auth hmac-sha2-512 auth hmac-sha1 group curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group modp3072 group modp2048 group modp1536 group modp1024 childsa enc aes-128-gcm enc aes-256-gcm group none esn noesn childsa enc aes-256 enc aes-192 enc aes-128 auth hmac-sha2-256 auth hmac-sha2-384 auth hmac-sha2-512 auth hmac-sha1 group none esn noesn srcid roadwarrior dstid agroena.org lifetime 10800 bytes 4294967296 signature config address any iface lo0 ikev2_init_ike_sa: initiating "roadwarrior" spi=0xc166e8f236679cc9: send IKE_SA_INIT req 0 peer 45.77.223.7:500 local 0.0.0.0:500, 518 bytes spi=0xc166e8f236679cc9: recv IKE_SA_INIT res 0 peer 45.77.223.7:500 local 192.168.1.79:500, 255 bytes, policy 'roadwarrior' spi=0xc166e8f236679cc9: ca_getreq: no valid local certificate found for FQDN/roadwarrior spi=0xc166e8f236679cc9: ca_getreq: using local public key of type RSA_KEY spi=0xc166e8f236679cc9: send IKE_AUTH req 1 peer 45.77.223.7:4500 local 192.168.1.79:4500, 947 bytes, NAT-T spi=0xc166e8f236679cc9: recv IKE_AUTH res 1 peer 45.77.223.7:4500 local 192.168.1.79:4500, 65 bytes, policy 'roadwarrior' spi=0xc166e8f236679cc9: sa_free: authentication failed notification from peer spi=0x128062d2440a20ca: recv IKE_SA_INIT res 0 peer 45.77.223.7:500 local 192.168.1.79:500, 255 bytes, policy 'roadwarrior' spi=0x128062d2440a20ca: recv IKE_SA_INIT res 0 peer 45.77.223.7:500 local 192.168.1.79:500, 255 bytes, policy 'roadwarrior' spi=0x128062d2440a20ca: recv IKE_SA_INIT res 0 peer 45.77.223.7:500 local 192.168.1.79:500, 255 bytes, policy 'roadwarrior' spi=0x128062d2440a20ca: recv IKE_SA_INIT res 0 peer 45.77.223.7:500 local 192.168.1.79:500, 255 bytes, policy 'roadwarrior' spi=0x128062d2440a20ca: recv IKE_SA_INIT res 0 peer 45.77.223.7:500 local 192.168.1.79:500, 255 bytes, policy 'roadwarrior' ikev2_init_ike_sa: initiating "roadwarrior" spi=0xaf891eb37dd8f4cc: send IKE_SA_INIT req 0 peer 45.77.223.7:500 local 0.0.0.0:500, 518 bytes spi=0xaf891eb37dd8f4cc: recv IKE_SA_INIT res 0 peer 45.77.223.7:500 local 192.168.1.79:500, 255 bytes, policy 'roadwarrior' spi=0xaf891eb37dd8f4cc: ca_getreq: no valid local certificate found for FQDN/roadwarrior spi=0xaf891eb37dd8f4cc: ca_getreq: using local public key of type RSA_KEY spi=0xaf891eb37dd8f4cc: send IKE_AUTH req 1 peer 45.77.223.7:4500 local 192.168.1.79:4500, 947 bytes, NAT-T spi=0xaf891eb37dd8f4cc: recv IKE_AUTH res 1 peer 45.77.223.7:4500 local 192.168.1.79:4500, 65 bytes, policy 'roadwarrior' spi=0xaf891eb37dd8f4cc: sa_free: authentication failed notification from peer spi=0x128062d2440a20ca: recv IKE_SA_INIT res 0 peer 45.77.223.7:500 local 192.168.1.79:500, 255 bytes, policy 'roadwarrior' ikev2_init_ike_sa: initiating "roadwarrior" spi=0x72a1368e235340b8: send IKE_SA_INIT req 0 peer 45.77.223.7:500 local 0.0.0.0:500, 518 bytes spi=0x72a1368e235340b8: recv IKE_SA_INIT res 0 peer 45.77.223.7:500 local 192.168.1.79:500, 255 bytes, policy 'roadwarrior' spi=0x72a1368e235340b8: ca_getreq: no valid local certificate found for FQDN/roadwarrior spi=0x72a1368e235340b8: ca_getreq: using local public key of type RSA_KEY spi=0x72a1368e235340b8: send IKE_AUTH req 1 peer 45.77.223.7:4500 local 192.168.1.79:4500, 947 bytes, NAT-T spi=0x72a1368e235340b8: recv IKE_AUTH res 1 peer 45.77.223.7:4500 local 192.168.1.79:4500, 65 bytes, policy 'roadwarrior' spi=0x72a1368e235340b8: sa_free: authentication failed notification from peer
Re: iked server/client OBSD/OBSD
what is wrong? client side iked.conf: ikev2 'roadwarrior' active esp \ from dynamic to any \ peer 45.77.223.7 \ srcid roadwarrior \ dstid server1.domain \ request address any \ iface lo1 # iked -dv /etc/iked.conf: 43: invalid iface lo1 must exist: # ifconfig lo1 create To create it at a reboot: # touch /etc/hostname.lo1
Re: Audio issue: noise/interference
On 2023-07-08 05:22, Alexandre Ratchov wrote: On Fri, Jul 07, 2023 at 06:23:26PM -0400, Ricky Cintron wrote: I recently resolved an audio issue where I could hear a constant, light static noise in my earphones. It wasn't loud or distracting, but it was always there. The solution was to remove 'mix' as a source for mix2 and mix3. However, once I got rid of that static, I noticed some additional noise that was apparently hidden behind the original static. Compared to the first issue, this noise is quieter and not constant. Anyway, it manifests itself in the following ways: 1) Very light static noise that never increases, but I've noticed that when I load a web page (YouTube, for example), the noise is silenced until the page finishes loading. This also sometimes happens when I move the mouse cursor around the web browser window, but very briefly. It's easier to notice when loading a page since it lasts longer. 2) Moving the mouse generates a barely audible buzzing sound, but this either doesn't occur or is barely noticeable when moving the cursor on a web browser window. To troubleshoot, I inspected all the cables in the back of the computer (power, DP, ethernet, USB keyboard, USB mouse, speakers/line), and unplugged them (except the power cable) one at a time. I didn't hear a difference, good or bad. I also turned some mixerctl knobs with no noticeable effects. Does anyone have any ideas? This isn't a big deal since I can't notice it while listening to audio, and it's pretty easy to tune out even without audio, but I'd still like to remove it if possible. I'm considering buying a USB audio interface, so if that even works, that could be a solution. Check that your AC power plug is connected to the ground. Possibly plug the computer in another plug, in another room, and see if this makes any difference. FWIW, I managed to reduce similar noises by putting ferrite rings on most cables, the HDMI cable was a significant source of noise in my case. I didn't try to put ferrite rings on the internal cables (ex. those between the power supply and the motherboard), but it might make sense as well. Certain motherboards are just not well designed and noise might remain, no matter what you do. A good audio interface would solve this problem, assuming you're using speakers that don't generate noise or passive headphones. HTH I'm definitely going to try different outlets later on, along with a few other tests dealing with the power delivery. Fortunately the noise is light so I can wait until a better time to disconnect and move things around. In your case, were the noises loud and audible through speakers? Also, how did you determine which cables needed ferrite rings?
Re: Audio issue: noise/interference
On 2023-07-07 23:26, Chris Bennett wrote: On Fri, Jul 07, 2023 at 06:23:26PM -0400, Ricky Cintron wrote: I recently resolved an audio issue where I could hear a constant, light static noise in my earphones. It wasn't loud or distracting, but it was always there. The solution was to remove 'mix' as a source for mix2 and mix3. I wouldn't call this resolved. This is just a useful step in troubleshooting. You now have more information towards a resolution. That's a good thing, but not enough. "My toaster shocks me every time I touch the metal case. I resolved it by not touching the metal part of the toaster." However, once I got rid of that static, I noticed some additional noise that was apparently hidden behind the original static. Compared to the first issue, this noise is quieter and not constant. Don't assume that there are actually two issues here. It may all have one cause or be two (or more) different problems. Anyway, it manifests itself in the following ways: 1) Very light static noise that never increases, but I've noticed that when I load a web page (YouTube, for example), the noise is silenced until the page finishes loading. This also sometimes happens when I move the mouse cursor around the web browser window, but very briefly. It's easier to notice when loading a page since it lasts longer. 2) Moving the mouse generates a barely audible buzzing sound, but this either doesn't occur or is barely noticeable when moving the cursor on a web browser window. To troubleshoot, I inspected all the cables in the back of the computer (power, DP, ethernet, USB keyboard, USB mouse, speakers/line), and unplugged them (except the power cable) one at a time. I didn't hear a difference, good or bad. I also turned some mixerctl knobs with no noticeable effects. Did you troubleshoot your earphones? It is very reasonable that they could now have bad wires or other problems. Do you still hear these noises with other earphones or speakers? Yes, when I first noticed the noise, I tested the earphones with a MacBook Pro, and there weren't any audible sounds at all (silent as far as my ears could measure). Before installing OpenBSD on this computer, it was running Windows 11 for about 8 months, and I never noticed any noises, but I can't guarantee they weren't there either. I'm going to do some additional testing soon, and one thing I want to try is to load up a Linux live environment with working audio. As far as speakers go, I can't hear the noise through them (it's too faint and not affected by volume level). Does anyone have any ideas? This isn't a big deal since I can't notice it while listening to audio, and it's pretty easy to tune out even without audio, but I'd still like to remove it if possible. I'm considering buying a USB audio interface, so if that even works, that could be a solution. I advise finding out what the problem is before buying anything new. You might find the same problem getting passed through another audio device. I suspect that you will need to fix a hardware problem. Don't assume that audio noise is in software. You are surrounded by 50/60Hz noise caused by the power in your house/office/workshop. I agree. I've been looking at audio interfaces for a while, and wouldn't buy one simply to avoid noise. Electrolytic capacitors can go bad (Even brand new capacitors can be defective). Look up bad motherboard capacitors and you can find some pretty good pictures and information. You can find some good YouTube videos on it too. I would also suspect grounding problems as a possibility. Which can mean bad connections with cables even if they look good. You can be having a power supply problem too. Check for loose motherboard screws. Are you using the computer with the cover off? Do you get these noises with the computer on, but then turning off the monitor and moving the mouse around? Nope, the cover's on. I didn't turn the monitor off, but I did disconnect the display port cable, and the noises were still present. Is your electrical wiring done properly? Do you have any other equipment hooked up that might be causing ground loops? Excellent videos on YouTube about ground loops and audio problems. Do you have any OLD radio or TV equipment that could be latching onto the computer noise and amplifying it? Also, if you can, go unplug (not turn off) things around that could be defective. For example, I have to throw away 3-4 USB chargers every year. Nowadays, hardly anything is actually turned off anymore. I used to hear noises like these too, but that was a long time ago... I could hear them in my memory while reading your email. Thanks for the ideas. I've compiled a list of additional tests I want to perform (some will have to wait though). Good luck, Chris Bennett
Re: Maintaining multiple PHP-FPM versions on the same host
> I’ll answer both of your replies here. But please note that Stuart provided > the feedback I needed so from my point of view this issue is closed. I'm happy you find the solution to your problem. > >> However, I passed a small amount of time with 5.6 and 7.3 from source >> loading together. >> In both cases I was using init.d scritps, that I can pass you. > > init.d is not an OpenBSD thing I'm working since 2011 with OpenBSD so my "init.d" did the solution to me. I pass you them privately.. >>> Problem(s) arising in reading you is at (your problem) origins > But if you are implying that maybe I should not be using OpenBSD because of a > specific issue with php-fpm and the rc(8) mechanism, I don’t agree. We do not know each other so I finally was guessing you are BSD dev testing stuff.. If it is not like that I can't reccomend to anyone working in PHP to invest its machine resources in this way, just that. So it was difficult to follow your intent from the beginning. As a php developer I kindly reccomend to keep things simple and you will see that impact among PHP versions, expecially what you are talking about is very little; apart ver 8.2 that break some small bit of stuff. I limit myself to answer these thoughts. I keep you posted privately with my "init.d" scripts PS: thanks to follow up also in @misc -- Daniele Bonini
Re: Maintaining multiple PHP-FPM versions on the same host
I’ll answer both of your replies here. But please note that Stuart provided the feedback I needed so from my point of view this issue is closed. > Am 10.07.2023 um 14:30 schrieb Daniele B. : > > However, I passed a small amount of time with 5.6 and 7.3 from source loading > together. > In both cases I was using init.d scritps, that I can pass you. init.d is not an OpenBSD thing. And my issue is not running multiple versions of PHP but configuring things so they don’t break when updates are installed. > Take it AS-IS, I do not want to recommend BSD subsystems or show off something > that is not part of my baggage. Indeed, for any system suggestion there is a > big truppen here, > not certenly myself. Not sure I understand your English here. But my question was posted on an OpenBSD mailing list, so solutions for other OSes are not really helpful. > Jul 10, 2023 13:57:15 Daniele B. : > >> Problem arising in reading you is at its origins, in plain italian "a >> monte".. ;) I don’t speak Italian. So I don’t get your comment. But if you are implying that maybe I should not be using OpenBSD because of a specific issue with php-fpm and the rc(8) mechanism, I don’t agree. >> >> - PHP 8 is enough retrocompatible with any version you mention, and should >> take in a >> certain amount of benefits in performance gain and bug fixing; So will you fix all of the (3rd party) code that may have issues for me? Theory and dogmatic concepts are fine. But there is also real life™. And there are other reasons for wanting to use older versions of PHP as well. For example compatibility testing. That said, sure PHP 8.2 is great for new projects. And I am using it where it makes sense. >> - PHP-FPM should be enough configurable and versatile to support huge amount >> of requests; Not relevant to the issue. A PHP-FPM process can only handle one version of PHP. My issue is with maintaining multiple PHP-FPM versions as stated in the subject. >> - multi webservers could be nice to have probably for some sorts of load >> balancing only, >> (having a reversed proxy is something often questionable); Just because you can’t think of a reason to use multiple web servers, that does not mean others can’t have valid reasons. And I fail to see what would be gained by using a reverse proxy to somehow mitigate the imagined reasons for your premise. It only adds complexity and has its own issues. And this is completely irrelevant to my issue. >> - multi webservers are surely a huge angle hole in your "resource room". What is an »angle hole«? And what do you mean by »resource room«. I’m sorry, but your version of English is often littered with what seem to be phrases and literal translations from your native language that make no sense in English. So whatever you think multiple web servers surly are, it is not relevant to my issue (see subject of this email). >> >> I do not know, are you maybe building your machine for testing purpose? Yes I do have legitmate reasons for wanting to run multiple versions of PHP in parallel. Testing is one reason. Compatibility is another. Not that it matters for the issue at hand. None of your comments address the issue I am having. On-topic comments to the list are generally welcome. But in this case I think Stuart has already provided the feedback I needed. Mike >> >> -- Daniele Bonini
Re: IPsec "road warrior" VPN not getting set up properly.
I'm sure this is obvious to people, but just in case it is not: I pay $25/month for my VPS, and I think I could bring that down to $10 or $15 if I wanted. My VPS routes me a /48 IPv6 network... I clearly meant "My VPS _provider_ routes me...".
Re: IPsec "road warrior" VPN not getting set up properly.
Before I essentially echo back what Stuart said, let me clarify something. I don't really recommend NAT over NDP proxying more than the other way around. I was merely stating that a hack is a hack is a hack. If you are forced to use a hack, then insisting on one over the other is bizarre unless one legitimately solves something the other doesn't. Personally, I would use NAT since it is more familiar to me. What I am still befuddled by is your insistence on sticking with your incompetent VPS provider. I sympathize with your plight vis-a-vis a residential ISP. It is not uncommon to have monopolies/duopolies dominate a particular residential ISP market; so if they are incompetent, then you're SOL. VPS providers, however, are a dime a dozen. Why would you want to stick with a VPS provider that (un)knowingly does not adhere to RFCs? If they don't follow one RFC, then I wouldn't be surprised if they don't follow others. To me I don't view it much differently than insisting on renting a laptop with malfunctioning hardware or BIOS/UEFI and waving $200 at kernel developers to hack around the bugs. They might; but even if they do, is it not better to solve the problem at the root (i.e., rent a functioning laptop)? I pay $25/month for my VPS, and I think I could bring that down to $10 or $15 if I wanted. My VPS routes me a /48 IPv6 network via a link-local address and a /29 IPv4 network via a private address. I have two WireGuard interfaces: one for "normal" peers where they connect to this VPN server via WireGuard software (e.g., the Android app) and another for my server/router at home which subsequently gets routed a /56 IPv6 block and the whole /29 IPv4 block. Bam. Finito. No BGP, no problem. I get to stay within the cozy confines of good ole routing. No hacks or other shenanigans. It just works. Just in case people misinterpret above: I am _not_ recommending this over BGP if you have the money/resources for BGP. Obviously you want the shortest routes possible and avoid any overhead associated with a VPN.
Re: Maintaining multiple PHP-FPM versions on the same host
(moving to ports@, reply-to set) On 2023-07-10, Mike Fischer wrote: > Hi! > > I’m trying to figure out the best way to maintain multiple php-fpm setups at > the same time and ran into a somewhat annoying issue. > > I’m not sure how many other users might have a similar situation? If this > something too non-standard, let me know and I’ll shut up ;-) > > > Background >== > > The server supports multiple versions of PHP for websites using php-fpm. > There are also multiple web servers running at the same time (on different > IP/port combinations obviously). Specifically OpenBSD httpd and Apache httpd > from ports. > > OpenBSD httpd runs in its normal chroot(2) environment. Apache httpd does not > use chroot(2). This requires corresponding setups for php-fpm as well. Using > e.g. a non-chroot(2) php-fpm with OpenBSD httpd does not work. > > Each php-fpm variant uses its own socket. So changing the PHP version for a > web server (or even for just certain paths on that server) is as easy as > pointing to the correct socket for the FastCGI mechanism of the web server. > > > Setup >= > > All available PHP Versions are supported and configured. I.e. 7.4, 8.0, 8.1 > and 8.2 for OpenBSD 7.3. > > I have adjusted /etc/php-7.4.ini, /etc/php-8.0.ini, etc. as required > > I have created and modified /etc/php-fpm-7.4cr.conf, > /etc/php-fpm-7.4ncr.conf, /etc/php-fpm-8.0cr.conf, /etc/php-fpm-8.0ncr.conf, > etc. The default /etc/php-fpm.conf is not actively used. > > I have copied the /etc/rc.d/phpXX_fpm files and modified them to: > - use the appropriate /etc/php-fpm.conf (/etc/php-fpm-7.4cr.conf, > /etc/php-fpm-7.4ncr.conf, /etc/php-fpm-8.0cr.conf, /etc/php-fpm-8.0ncr.conf, > etc.) > - use the appropriate /etc/php.ini (/etc/php-7.4.ini, /etc/php-8.0.ini, > /etc/php-8.1.ini and /etc/php-8.2.ini) > - adjust the pexp to match the php-fpm.conf in addition to "php-fpm-7.4: > master process", e.g. "php-fpm-7.4: master process > .*/etc/php-fpm-7.4cr.conf.*", etc. > > Thus I have: > /etc/rc.d/php74cr_fpm > /etc/rc.d/php74ncr_fpm > /etc/rc.d/php80cr_fpm > /etc/rc.d/php80ncr_fpm > /etc/rc.d/php81cr_fpm > /etc/rc.d/php81ncr_fpm > /etc/rc.d/php82cr_fpm > /etc/rc.d/php82ncr_fpm > > And all of these have been enabled using `rcctl enable php74cr_fpm > php74ncr_fpm php80cr_fpm php80ncr_fpm php81cr_fpm php81ncr_fpm php82cr_fpm > php82ncr_fpm` and of course started using `rcctl start …`. > > For example: > # cat /etc/rc.d/php82cr_fpm > #!/bin/ksh > > daemon="/usr/local/sbin/php-fpm-8.2" > daemon_flags="-c /etc/php-8.2-cr.ini -y /etc/php-fpm-82cr.conf" > > . /etc/rc.d/rc.subr > > pexp="php-fpm-8.2: master process .*/etc/php-fpm-82cr.conf.*" > rc_reload=NO > > rc_cmd $1 > # > > > (Note: I know this could be further reduced to just one master process for > each version with a chroot(2) and a non-chroot(2) pool defined in the single > php-fpm.conf for each PHP version. But that is irrelevant to the issue at > hand.) Actually I think that is relevant. At least, if you just had one running php-fpm daemon per version, you totally avoid the problem. > > Issue >= > > `rcctl ls started` lists php74_fpm, php80_fpm, php81_fpm and php82_fpm as > started even though they are neither enabled nor started! > > The reason this happens is the pexp which is too general. E.g. for php74_fpm > it is pexp="php-fpm-7.4: master process .*" > > Modifying this to e.g. pexp="php-fpm-7.4: master process > .*/etc/php-fpm.conf.*" solves the problem. > > BUT: /etc/rc.d/php74_fpm will be overwritten when the php-7.4 port ist > updated. (Same for the other versions of course.) So my change is lost and > has to be reapplied. If I forget about this then at a later time I’ll become > confused by the output of `rcctl ls started`. > > > Questions >= > > 1) Is there a better, update-proof way to solve this problem? With a single daemon per version, remove the extra added phpXX_fpm copies, instead follow the suggestion after "If you need to run multiple versions of PHP on one machine" in php's pkg-readme. > 2) Would it make sense to include the more specific pexp in the PHP ports? (I > don’t think doing so would hurt the default use case, but maybe I’m > overlooking something?) This is a bit awkward to do; the rc script would then need to parse the phpXX_fpm_flags variable and figure out what string php-fpm will use when it sets the process name (i.e. look for -y or --fpm-config and parse them the same way that php-fpm itself does). Yes it is possible to do that, but it's definitely more fragile, and considering that the main purpose of php-fpm is to run multiple copies of php for different environments anyway, it seems a bit redundant to run multiple copies of the same version of php-fpm. Though the existing pexp is slightly less flexible, IMHO it's enough for most use cases, and it doesn't really seem worth the extra fragility to do this differently.
Re: Maintaining multiple PHP-FPM versions on the same host
However, I passed a small amount of time with 5.6 and 7.3 from source loading together. In both cases I was using init.d scritps, that I can pass you. Take it AS-IS, I do not want to recommend BSD subsystems or show off something that is not part of my baggage. Indeed, for any system suggestion there is a big truppen here, not certenly myself. Jul 10, 2023 13:57:15 Daniele B. : > Problem arising in reading you is at its origins, in plain italian "a > monte".. ;) > > - PHP 8 is enough retrocompatible with any version you mention, and should > take in a > certain amount of benefits in performance gain and bug fixing; > - PHP-FPM should be enough configurable and versatile to support huge amount > of requests; > - multi webservers could be nice to have probably for some sorts of load > balancing only, > (having a reversed proxy is something often questionable); > - multi webservers are surely a huge angle hole in your "resource room". > > I do not know, are you maybe building your machine for testing purpose? > > -- Daniele Bonini > > Jul 10, 2023 13:01:10 Mike Fischer : > >> Hi! >> >> I’m trying to figure out the best way to maintain multiple php-fpm setups at >> the same time and ran into a somewhat annoying issue. >> >> I’m not sure how many other users might have a similar situation? If this >> something too non-standard, let me know and I’ll shut up ;-) >> >> >> Background >> == >> >> The server supports multiple versions of PHP for websites using php-fpm. >> There are also multiple web servers running at the same time (on different >> IP/port combinations obviously). Specifically OpenBSD httpd and Apache httpd >> from ports. >> >> OpenBSD httpd runs in its normal chroot(2) environment. Apache httpd does >> not use chroot(2). This requires corresponding setups for php-fpm as well. >> Using e.g. a non-chroot(2) php-fpm with OpenBSD httpd does not work. >> >> Each php-fpm variant uses its own socket. So changing the PHP version for a >> web server (or even for just certain paths on that server) is as easy as >> pointing to the correct socket for the FastCGI mechanism of the web server. >> >> >> Setup >> = >> >> All available PHP Versions are supported and configured. I.e. 7.4, 8.0, 8.1 >> and 8.2 for OpenBSD 7.3. >> >> I have adjusted /etc/php-7.4.ini, /etc/php-8.0.ini, etc. as required >> >> I have created and modified /etc/php-fpm-7.4cr.conf, >> /etc/php-fpm-7.4ncr.conf, /etc/php-fpm-8.0cr.conf, /etc/php-fpm-8.0ncr.conf, >> etc. The default /etc/php-fpm.conf is not actively used. >> >> I have copied the /etc/rc.d/phpXX_fpm files and modified them to: >> - use the appropriate /etc/php-fpm.conf (/etc/php-fpm-7.4cr.conf, >> /etc/php-fpm-7.4ncr.conf, /etc/php-fpm-8.0cr.conf, /etc/php-fpm-8.0ncr.conf, >> etc.) >> - use the appropriate /etc/php.ini (/etc/php-7.4.ini, /etc/php-8.0.ini, >> /etc/php-8.1.ini and /etc/php-8.2.ini) >> - adjust the pexp to match the php-fpm.conf in addition to "php-fpm-7.4: >> master process", e.g. "php-fpm-7.4: master process >> .*/etc/php-fpm-7.4cr.conf.*", etc. >> >> Thus I have: >> /etc/rc.d/php74cr_fpm >> /etc/rc.d/php74ncr_fpm >> /etc/rc.d/php80cr_fpm >> /etc/rc.d/php80ncr_fpm >> /etc/rc.d/php81cr_fpm >> /etc/rc.d/php81ncr_fpm >> /etc/rc.d/php82cr_fpm >> /etc/rc.d/php82ncr_fpm >> >> And all of these have been enabled using `rcctl enable php74cr_fpm >> php74ncr_fpm php80cr_fpm php80ncr_fpm php81cr_fpm php81ncr_fpm php82cr_fpm >> php82ncr_fpm` and of course started using `rcctl start …`. >> >> For example: >> # cat /etc/rc.d/php82cr_fpm >> #!/bin/ksh >> >> daemon="/usr/local/sbin/php-fpm-8.2" >> daemon_flags="-c /etc/php-8.2-cr.ini -y /etc/php-fpm-82cr.conf" >> >> . /etc/rc.d/rc.subr >> >> pexp="php-fpm-8.2: master process .*/etc/php-fpm-82cr.conf.*" >> rc_reload=NO >> >> rc_cmd $1 >> # >> >> >> (Note: I know this could be further reduced to just one master process for >> each version with a chroot(2) and a non-chroot(2) pool defined in the single >> php-fpm.conf for each PHP version. But that is irrelevant to the issue at >> hand.) >> >> >> Issue >> = >> >> `rcctl ls started` lists php74_fpm, php80_fpm, php81_fpm and php82_fpm as >> started even though they are neither enabled nor started! >> >> The reason this happens is the pexp which is too general. E.g. for php74_fpm >> it is pexp="php-fpm-7.4: master process .*" >> >> Modifying this to e.g. pexp="php-fpm-7.4: master process >> .*/etc/php-fpm.conf.*" solves the problem. >> >> BUT: /etc/rc.d/php74_fpm will be overwritten when the php-7.4 port ist >> updated. (Same for the other versions of course.) So my change is lost and >> has to be reapplied. If I forget about this then at a later time I’ll become >> confused by the output of `rcctl ls started`. >> >> >> Questions >> = >> >> 1) Is there a better, update-proof way to solve this problem? >> >> 2) Would it make sense to include the more specific pexp in the PHP ports? >>
Re: Maintaining multiple PHP-FPM versions on the same host
Problem arising in reading you is at its origins, in plain italian "a monte".. ;) - PHP 8 is enough retrocompatible with any version you mention, and should take in a certain amount of benefits in performance gain and bug fixing; - PHP-FPM should be enough configurable and versatile to support huge amount of requests; - multi webservers could be nice to have probably for some sorts of load balancing only, (having a reversed proxy is something often questionable); - multi webservers are surely a huge angle hole in your "resource room". I do not know, are you maybe building your machine for testing purpose? -- Daniele Bonini Jul 10, 2023 13:01:10 Mike Fischer : > Hi! > > I’m trying to figure out the best way to maintain multiple php-fpm setups at > the same time and ran into a somewhat annoying issue. > > I’m not sure how many other users might have a similar situation? If this > something too non-standard, let me know and I’ll shut up ;-) > > > Background > == > > The server supports multiple versions of PHP for websites using php-fpm. > There are also multiple web servers running at the same time (on different > IP/port combinations obviously). Specifically OpenBSD httpd and Apache httpd > from ports. > > OpenBSD httpd runs in its normal chroot(2) environment. Apache httpd does not > use chroot(2). This requires corresponding setups for php-fpm as well. Using > e.g. a non-chroot(2) php-fpm with OpenBSD httpd does not work. > > Each php-fpm variant uses its own socket. So changing the PHP version for a > web server (or even for just certain paths on that server) is as easy as > pointing to the correct socket for the FastCGI mechanism of the web server. > > > Setup > = > > All available PHP Versions are supported and configured. I.e. 7.4, 8.0, 8.1 > and 8.2 for OpenBSD 7.3. > > I have adjusted /etc/php-7.4.ini, /etc/php-8.0.ini, etc. as required > > I have created and modified /etc/php-fpm-7.4cr.conf, > /etc/php-fpm-7.4ncr.conf, /etc/php-fpm-8.0cr.conf, /etc/php-fpm-8.0ncr.conf, > etc. The default /etc/php-fpm.conf is not actively used. > > I have copied the /etc/rc.d/phpXX_fpm files and modified them to: > - use the appropriate /etc/php-fpm.conf (/etc/php-fpm-7.4cr.conf, > /etc/php-fpm-7.4ncr.conf, /etc/php-fpm-8.0cr.conf, /etc/php-fpm-8.0ncr.conf, > etc.) > - use the appropriate /etc/php.ini (/etc/php-7.4.ini, /etc/php-8.0.ini, > /etc/php-8.1.ini and /etc/php-8.2.ini) > - adjust the pexp to match the php-fpm.conf in addition to "php-fpm-7.4: > master process", e.g. "php-fpm-7.4: master process > .*/etc/php-fpm-7.4cr.conf.*", etc. > > Thus I have: > /etc/rc.d/php74cr_fpm > /etc/rc.d/php74ncr_fpm > /etc/rc.d/php80cr_fpm > /etc/rc.d/php80ncr_fpm > /etc/rc.d/php81cr_fpm > /etc/rc.d/php81ncr_fpm > /etc/rc.d/php82cr_fpm > /etc/rc.d/php82ncr_fpm > > And all of these have been enabled using `rcctl enable php74cr_fpm > php74ncr_fpm php80cr_fpm php80ncr_fpm php81cr_fpm php81ncr_fpm php82cr_fpm > php82ncr_fpm` and of course started using `rcctl start …`. > > For example: > # cat /etc/rc.d/php82cr_fpm > #!/bin/ksh > > daemon="/usr/local/sbin/php-fpm-8.2" > daemon_flags="-c /etc/php-8.2-cr.ini -y /etc/php-fpm-82cr.conf" > > . /etc/rc.d/rc.subr > > pexp="php-fpm-8.2: master process .*/etc/php-fpm-82cr.conf.*" > rc_reload=NO > > rc_cmd $1 > # > > > (Note: I know this could be further reduced to just one master process for > each version with a chroot(2) and a non-chroot(2) pool defined in the single > php-fpm.conf for each PHP version. But that is irrelevant to the issue at > hand.) > > > Issue > = > > `rcctl ls started` lists php74_fpm, php80_fpm, php81_fpm and php82_fpm as > started even though they are neither enabled nor started! > > The reason this happens is the pexp which is too general. E.g. for php74_fpm > it is pexp="php-fpm-7.4: master process .*" > > Modifying this to e.g. pexp="php-fpm-7.4: master process > .*/etc/php-fpm.conf.*" solves the problem. > > BUT: /etc/rc.d/php74_fpm will be overwritten when the php-7.4 port ist > updated. (Same for the other versions of course.) So my change is lost and > has to be reapplied. If I forget about this then at a later time I’ll become > confused by the output of `rcctl ls started`. > > > Questions > = > > 1) Is there a better, update-proof way to solve this problem? > > 2) Would it make sense to include the more specific pexp in the PHP ports? (I > don’t think doing so would hurt the default use case, but maybe I’m > overlooking something?) > > > OpenBSD 7.3, amd64 > > > Thanks! > Mike
Re: recommendations for web hosting in Canada?
I’m using Cirrus Hosting based out of Toronto. Sent from my iPhone > On Jul 10, 2023, at 06:30, Steve Litt wrote: > > Jonathan Thornburg said on Mon, 10 Jul 2023 03:13:46 -0700 > >> I'm looking for a web hosting provider based in Canada. That is, >> I'm looking for a provider who will host my html, jpeg, css, etc., >> files on their web server and manage certificates and DNS entries >> for my domain. I don't need super-high performance (the websites >> will be relatively small, low-traffic, and static), but I'd like a >> provider based in Canada whose interface and "management console" >> don't require a proprietory Windows/Mac/Android client. Any >> recommendations? > > There are many web hosts worldwide who have all your preceding > requirements except for being Canada based. My new web host is hosting > me out of West Chicago, Illinois, which is pretty close to Canada if > latency is your motive. Is there any reason you prefer a Canada based > host? > > > SteveT > > Steve Litt > Autumn 2022 featured book: Thriving in Tough Times > http://www.troubleshooters.com/bookstore/thrive.htm >
Re: IPsec "road warrior" VPN not getting set up properly.
On 2023-07-10, Anthony Coulter wrote: > 2. I abandon my quest to get NDP proxying added to iked and instead ask >if we can add a "rtlabel" keyword to iked.conf to make it easier for >me to write a separate process that monitors the routing table to >detect when the tunnel gets set up. Currently iked (and isakmpd) use flows, not routes. These use messages on the PF_KEY socket not the route socket. (If I watch route -nv monitor while iked starts and brings up tunnels, I don't see any messages). IIUC the parts you found which currently exist are for the "iface" option which tells an iked initiator (a machine, typically but not necessarily mobile) to use mode-config to fetch an address, and configure it on an interface. There is a diff for route-based IPsec which does use the route table (https://marc.info/?l=openbsd-tech=168844868110327=2), but I think if you were using that, you could just look for messages relating to sec(4) interfaces anyway and not have to worry about labels? >> NDP proxying is also vulnerable to NDP cache DoS. It's more than just NDP proxying that results in this. Put a big chunk of address space on an interface that requires IP-to-physical address resolution and you end up having to do that resolution for a bunch of junk traffic coming from the internet. Say someone does some kind of sweep looking for hosts and sending unsolicited traffic to a bunch of addresses within a prefix, each address attempt will result in having to try to resolve that address. Whether it's successful or not, some work must be done for that (e.g. slow-path lookups on the gateway router, caching, etc). FWIW if I was a VPS/colo provider wanting to keep router resources low, I would probably assign a single address from a /64 to the customer machine/VM, and filter traffic from the internet so that packets to other addresses in the /64 are blocked - so junk traffic would not trigger junk NDP attempts.. (alternatively it's possible to use link-locals for that one "route via" address, though I would prefer to have that on a routable address for ease of debugging - traceroutes etc). Then for any additional addresses I'd route either multiple /64's, or a /56 or /48, via that one address - that way NDP is only ever done for the one address and it's likely to stay in cache. If you're on a low end VPS that is not already doing filtering like this, you may find that later on they change to implement that, when they figure out why the L3 switch they're using as a router is running out of steam when handling junk traffic... > Since my proposal to have iked enable NDP proxying itself failed to > gain traction I looked into other options (that don't involve > requesting a larger subnet from my ISP and VPS providers). I think you're thinking of having a subnet routed across as something that is going to cause more pain for the upstream provider. The reality is the opposite. If the provider doesn't understand this, there are probably a few other things they don't understand too, it would be a bit of a red flag for me. Yes there are a huge number of addresses in a /64, but really a /64 is what providers are expected to assign where they would assign an individual address for IPv4. For a situation where you'd have a couple of addresses with v4, with v6 it's really normal to have a /56 or /48.
Maintaining multiple PHP-FPM versions on the same host
Hi! I’m trying to figure out the best way to maintain multiple php-fpm setups at the same time and ran into a somewhat annoying issue. I’m not sure how many other users might have a similar situation? If this something too non-standard, let me know and I’ll shut up ;-) Background == The server supports multiple versions of PHP for websites using php-fpm. There are also multiple web servers running at the same time (on different IP/port combinations obviously). Specifically OpenBSD httpd and Apache httpd from ports. OpenBSD httpd runs in its normal chroot(2) environment. Apache httpd does not use chroot(2). This requires corresponding setups for php-fpm as well. Using e.g. a non-chroot(2) php-fpm with OpenBSD httpd does not work. Each php-fpm variant uses its own socket. So changing the PHP version for a web server (or even for just certain paths on that server) is as easy as pointing to the correct socket for the FastCGI mechanism of the web server. Setup = All available PHP Versions are supported and configured. I.e. 7.4, 8.0, 8.1 and 8.2 for OpenBSD 7.3. I have adjusted /etc/php-7.4.ini, /etc/php-8.0.ini, etc. as required I have created and modified /etc/php-fpm-7.4cr.conf, /etc/php-fpm-7.4ncr.conf, /etc/php-fpm-8.0cr.conf, /etc/php-fpm-8.0ncr.conf, etc. The default /etc/php-fpm.conf is not actively used. I have copied the /etc/rc.d/phpXX_fpm files and modified them to: - use the appropriate /etc/php-fpm.conf (/etc/php-fpm-7.4cr.conf, /etc/php-fpm-7.4ncr.conf, /etc/php-fpm-8.0cr.conf, /etc/php-fpm-8.0ncr.conf, etc.) - use the appropriate /etc/php.ini (/etc/php-7.4.ini, /etc/php-8.0.ini, /etc/php-8.1.ini and /etc/php-8.2.ini) - adjust the pexp to match the php-fpm.conf in addition to "php-fpm-7.4: master process", e.g. "php-fpm-7.4: master process .*/etc/php-fpm-7.4cr.conf.*", etc. Thus I have: /etc/rc.d/php74cr_fpm /etc/rc.d/php74ncr_fpm /etc/rc.d/php80cr_fpm /etc/rc.d/php80ncr_fpm /etc/rc.d/php81cr_fpm /etc/rc.d/php81ncr_fpm /etc/rc.d/php82cr_fpm /etc/rc.d/php82ncr_fpm And all of these have been enabled using `rcctl enable php74cr_fpm php74ncr_fpm php80cr_fpm php80ncr_fpm php81cr_fpm php81ncr_fpm php82cr_fpm php82ncr_fpm` and of course started using `rcctl start …`. For example: # cat /etc/rc.d/php82cr_fpm #!/bin/ksh daemon="/usr/local/sbin/php-fpm-8.2" daemon_flags="-c /etc/php-8.2-cr.ini -y /etc/php-fpm-82cr.conf" . /etc/rc.d/rc.subr pexp="php-fpm-8.2: master process .*/etc/php-fpm-82cr.conf.*" rc_reload=NO rc_cmd $1 # (Note: I know this could be further reduced to just one master process for each version with a chroot(2) and a non-chroot(2) pool defined in the single php-fpm.conf for each PHP version. But that is irrelevant to the issue at hand.) Issue = `rcctl ls started` lists php74_fpm, php80_fpm, php81_fpm and php82_fpm as started even though they are neither enabled nor started! The reason this happens is the pexp which is too general. E.g. for php74_fpm it is pexp="php-fpm-7.4: master process .*" Modifying this to e.g. pexp="php-fpm-7.4: master process .*/etc/php-fpm.conf.*" solves the problem. BUT: /etc/rc.d/php74_fpm will be overwritten when the php-7.4 port ist updated. (Same for the other versions of course.) So my change is lost and has to be reapplied. If I forget about this then at a later time I’ll become confused by the output of `rcctl ls started`. Questions = 1) Is there a better, update-proof way to solve this problem? 2) Would it make sense to include the more specific pexp in the PHP ports? (I don’t think doing so would hurt the default use case, but maybe I’m overlooking something?) OpenBSD 7.3, amd64 Thanks! Mike
Re: recommendations for web hosting in Canada?
I wrote: > I'm looking for a web hosting provider based in Canada. Performance > isn't critical (the websites will be relatively small, static, and > low-traffic), but I'd like a firm whose customer support doesn't > core-dump if I mention Perl or OpenBSD. Any recommendations? Thank you to the many people who replied, both privately and here in misc@. But, in hindsight I didn't express my actual question very well. What I should have written was more like this: I'm looking for a web hosting provider based in Canada. That is, I'm looking for a provider who will host my html, jpeg, css, etc., files on their web server and manage certificates and DNS entries for my domain. I don't need super-high performance (the websites will be relatively small, low-traffic, and static), but I'd like a provider based in Canada whose interface and "management console" don't require a proprietory Windows/Mac/Android client. Any recommendations? I'm sorry for confusing people with my original sloppily-worded query. thanks, ciao, -- -- "Jonathan Thornburg [remove -color to reply]" currently on the west coast of Canada "!07/11 PDP a ni deppart m'I !pleH" -- slashdot.org page footer, 2022-10-16 "eHpl !'I mrtpaep dnia P PD1 /107" -- slightly more plausible message given the PDP-11's little-endian byte order
