Re: static IPv6 config on OVH dedicated server
Hi Piotr, -Message initial- > De: Piotr Isajew > Envoyé: vendredi 9 avril 2021 22:59 > À: misc@openbsd.org > Sujet: static IPv6 config on OVH dedicated server > > Hi, > > I'm struggling to configure IPv6 for my fresh OpenBSD 6.8 > installation running on OVH (soyoustart.com) dedicated server. > > What I get from the ISP is the /64 address pool. > OVH requires static configuration with gateway outside of the > assigned subnet. According to their docummentation: > > The default gateway for your IPv6 block (IPv6_GATEWAY) is always > ...xxFF:FF:FF:FF:FF. > > For example: > > The IPv6 address of the server is 2607:5300:60:62ac::/64. The > IPv6_GATEWAY will therefore be 2607:5300:60:62FF:FF:FF:FF:FF. A decade ago, I tried to configure OVH ipv6 and give up after an headhache to use an ugly /56. I never try again to deal with a /64 and an outside gateway since your mail. Then I tried again with a fucking headache. But thanks to you. I solved my misconfigured problem. Before you test, stay with your /56 and try to list the mac address of your default gateway with : # ndp -a You will see the MAC address you will need for your /etc/hostname.if (this is an example for the ip6 part) ... inet6 2607:5300:60:62ac:: 64 !route add -inet6 2607:5300:60:62ff:ff:ff:ff:ff/128 -link -static -iface ix0 !route add -inet6 default 2607:5300:60:62ff:ff:ff:ff:ff #replace XX:XX:XX:XX:XX:XX with the gw mac address : !ndp -s 2607:5300:60:62ff:ff:ff:ff:ff XX:XX:XX:XX:XX:XX proxy #EOF This will work as expected. Cheers,
httpd passes rogue request to internal vhost
I have a machine with OpenBSD 6.8 and with 2 network interfaces:
egress
intranet
httpd has 3 vhosts defined:
server "default" {
listen on * tls port 443
...
location * {
block return 403
}
}
server "externalapp.publicdomain.net" {
listen on egress tls port 443
...
}
server "internalapp.privatedomain.net" {
listen on intranet tls port 443
...
}
So far so good, but when I try to access
"internalapp.privatedomain.net" from the internet, it serves the page
happily. I double checked that I had no access to the intranet at that
moment.
But when I change "default" server to:
server "default" {
listen on egress tls port 443
listen on intranet port 443
...
}
and try again, I get proper 403.
Is that a bug or some sort of non-intuitive behavior of listen on *
stanza?
Cheers,
Chris
signature.asc
Description: PGP signature
Re: static IPv6 config on OVH dedicated server
Forgot this. 1 hour later It sucks again . What a fucking network :( -Message initial- > De: Eric JACQUOT > Envoyé: lundi 12 avril 2021 0:13 > À: Piotr Isajew ; misc@openbsd.org > Sujet: RE: static IPv6 config on OVH dedicated server > > Hi Piotr, > > -Message initial- > > De: Piotr Isajew > > Envoyé: vendredi 9 avril 2021 22:59 > > À: misc@openbsd.org > > Sujet: static IPv6 config on OVH dedicated server > > > > Hi, > > > > I'm struggling to configure IPv6 for my fresh OpenBSD 6.8 > > installation running on OVH (soyoustart.com) dedicated server. > > > > What I get from the ISP is the /64 address pool. > > OVH requires static configuration with gateway outside of the > > assigned subnet. According to their docummentation: > > > > The default gateway for your IPv6 block (IPv6_GATEWAY) is always > > ...xxFF:FF:FF:FF:FF. > > > > For example: > > > > The IPv6 address of the server is 2607:5300:60:62ac::/64. The > > IPv6_GATEWAY will therefore be 2607:5300:60:62FF:FF:FF:FF:FF. > > > A decade ago, I tried to configure OVH ipv6 and give up after an headhache > to use an ugly /56. > I never try again to deal with a /64 and an outside gateway since your mail. > Then I tried again with a fucking headache. But thanks to you. I solved my > misconfigured problem. > > Before you test, stay with your /56 and try to list the mac address of your > default gateway with : > > # ndp -a > > You will see the MAC address you will need for your /etc/hostname.if (this > is an example for the ip6 part) > > ... > inet6 2607:5300:60:62ac:: 64 > !route add -inet6 2607:5300:60:62ff:ff:ff:ff:ff/128 -link -static -iface ix0 > !route add -inet6 default 2607:5300:60:62ff:ff:ff:ff:ff > #replace XX:XX:XX:XX:XX:XX with the gw mac address : > !ndp -s 2607:5300:60:62ff:ff:ff:ff:ff XX:XX:XX:XX:XX:XX proxy > #EOF > > > This will work as expected. > > > Cheers,
help debug NFS
Hello I have an NFS server on OpenBSD 6.8 stable which exports a folder with default settings. I have a linux mint client which mounts a share from this NFS server with these settings: sudo mount -o wsize=8192,rsize=8192 192.168.1.65:/big /home/user/store which gives a decent speed at about 50-60MB/s both sides which seem ok for me. The problem is: when the mount point is not used for a while (5 minutes and more) the share becomes unresponsive and the only way to unmount the share is to do sudo umount -lf /home/user/store After that I can mount the share once again. When I imitate using the share on client using while :; do ls /home/user/store/ && echo "OK" && sleep 3 ; done; the share remains responsive all the time and shows no problems. What tweaks(settings) on the client(server) am I missing in my setup to keep the mount point responsive? -- Best regards Maksim Rodin
Re: Can I shorten fw_update download timeout?
On Thu, Apr 08, 2021 at 01:50:59PM -0500, Luke Small wrote: > I make unbound connect to dnscrypt-proxy and after an update, it’ll just > sit there for what seems like 2 minutes while fw_update inevitably fails > before turning on dnscrypt-proxy. I’ve been running snapshots and that’s > really dumb. Or is there a way to have unbound connect to a failover server > when the default resolver isn’t responsive that I’m not aware of?-- > -Luke well there are many ways to go about this. Both sysupgrade and fw_update are scripts so they can be easily modified to your needs. Copy them to your path that takes precedence and customise them to your needs. fw_update actually is a perl script that calls the pkg_xxx with the fw_update mode. >From the pkg_add manpage you can see that you can specify FETCH_CMD to whatever you want. Now you can either write a small script yourself to either send a SIGALRM after X seconds and listen for that, or use a another command like curl which implements connect timeouts. like so FETCH_CMD="/usr/local/bin/curl --connect-timeout 1" fw_update signature.asc Description: PGP signature
Re: help debug NFS
Hi Maxim, I ran into the problem with the nfs mounts on linux hanging a few months ago, when the Linux distro that I'm running (Void) on the NFS client dropped UDP NFS mounts. At the time I found this post that explains the situation: http://openbsd-archive.7691.n7.nabble.com/nfsd-hangs-Linux-tcp-clients-after-5-minutes-idle-td402844.html As a work around, I've set up a cron script that stat's the mount point every four minutes. That stops the mount from hanging. I hope that helps. James On Sun, Apr 11, 2021 at 2:04 AM Родин Максим wrote: > > Hello > I have an NFS server on OpenBSD 6.8 stable > which exports a folder with default settings. > I have a linux mint client which mounts a share from this NFS server > with these settings: > sudo mount -o wsize=8192,rsize=8192 192.168.1.65:/big > /home/user/store > which gives a decent speed at about 50-60MB/s both sides which seem ok > for me. > The problem is: when the mount point is not used for a while (5 minutes > and more) the share becomes unresponsive and the only way to unmount the > share is to do > sudo umount -lf /home/user/store > After that I can mount the share once again. > When I imitate using the share on client using > while :; do ls /home/user/store/ && echo "OK" && sleep 3 ; done; > the share remains responsive all the time and shows no problems. > > What tweaks(settings) on the client(server) am I missing in my setup > to keep the mount point responsive? > -- > Best regards > Maksim Rodin >
Re: help debug NFS
Hi Maxim, I cannot help you fix this as I don't have a similar set-up but I can tell you this isn't normal behaviour for NFS. You should not need to tweak anything to get a stable mount at least in my experience. It sounds like a bug somewhere to me. You could try using the gnu watch command or similar while loop to run an ls of the share from the client to confirm if it hangs after non use or after five minutes regardless of use or non-use. You could also try testing the network connection between the two machines to make sure there is no connectivity or cable problem. You could use the same while loop to run rpcinfo or showmount commands from the client and server to see if it stops working after the same delay. Someone with more knowledge of NFS might suggest some better debugging steps... Regards Ed Gray On Sun, 11 Apr 2021, 10:07 am Родин Максим, wrote: > Hello > I have an NFS server on OpenBSD 6.8 stable > which exports a folder with default settings. > I have a linux mint client which mounts a share from this NFS server > with these settings: > sudo mount -o wsize=8192,rsize=8192 192.168.1.65:/big > /home/user/store > which gives a decent speed at about 50-60MB/s both sides which seem ok > for me. > The problem is: when the mount point is not used for a while (5 minutes > and more) the share becomes unresponsive and the only way to unmount the > share is to do > sudo umount -lf /home/user/store > After that I can mount the share once again. > When I imitate using the share on client using > while :; do ls /home/user/store/ && echo "OK" && sleep 3 ; done; > the share remains responsive all the time and shows no problems. > > What tweaks(settings) on the client(server) am I missing in my setup > to keep the mount point responsive? > -- > Best regards > Maksim Rodin > >
Upgrade to 6.8 issues
Hi all, Just upgraded to 6.8 from 6.3 (yes, I know...) and now find a few of the websites I'm hosting are no longer connecting to postgres because pear DB is apparently no longer in ports. Fortunately so far they all appear to be *my* websites so no harm, no foul. The sites that I'm hosting through something like drupal7 or wordpress are all fine--it's only the sites that I created a gazillion years ago using pear DB that are really failing. Are there alternatives that I'm missing? Please, I really don't feel the need to move off apache2 just yet. Thanks, Jeff
