amdgpu startup is slow.
not our fault.
Subhaditya Nath wrote:
> Hi there!
>
> I have installed OpenBSD 6.9 on my ThinkPad E495, and I have run
> syspatch and fw_update to install all the necessary patches and
> firmwares. I have been running it for a few weeks now, and I absolutely
> love it
Hi there!
I have installed OpenBSD 6.9 on my ThinkPad E495, and I have run
syspatch and fw_update to install all the necessary patches and
firmwares. I have been running it for a few weeks now, and I absolutely
love it!
Except, there is one very annoying issue.
Resuming from suspend _always_ tak
I have a vpn from a Windows machine to a network behind an OpenBSD router. It
was working fine until I upgraded the router to 6.9 (amd64).
The VPN is still coming up fine, but the traffic is blocked somehow. Using
tcpdump on the interface protected by the router (vlan0 in my case), I see the
Hi,
In my testings, using « listen on * port https tls » doesn’t work either.
What I did is replace the « * » with the IP address where I want relayd to
listen to. And as my gateway has several interfaces, I created a relay section
for each single interface I wanted relayd to bind to.
Regards,
Hello,
I have a vpn from a Windows machine to a network behind an OpenBSD router. It
was working fine until I upgraded the router to 6.9 (amd64).
The VPN is still coming up fine, but the traffic is blocked somehow. Using
tcpdump on the interface protected by the router (vlan0 in my case), I see
Kent Watsen writes:
> A redacted version of my /etc/relayd.conf follows. But note that I
> also have `httpd` running on this machine, listening for inbound port
> 80 requests, in order to 1) handle ACME requests and 2) redirect all
> port 80 requests to port 443. Both configs follow.
Could it
On Thu, May 27, 2021 at 4:53 PM Theo de Raadt wrote:
> Occasionally a bad snapshot will ship out, because we are actively
> developing. It is rare. Shrug.
>
>
And OpenBSD even has some awesome tools to discover this, so it's really
not a big problem and that tool is vmm.
I have a VM that I upgr
Anthony Campbell wrote:
> After upgrading to -current today I found that xenodm would not run
> because of a missing /usr/lib/libexpat.so.14.0_ Various other things
> didn['t work either, including vim.
>
> As a temporary work-round I made a link for it to libexpat.so.13.0,
> which seems to have
I did this too, because I have:
1) a single external IP
2) multiple internal HTTP-based services
3) a port-based firewall policy
This whole issue would disappear, and remove a single point of failure
(relayd), if my firewall directed inbound traffic based on URLs (for port 80)
and SN
Hi,
* Anthony Campbell wrote:
> After upgrading to -current today I found that xenodm would not run
> because of a missing /usr/lib/libexpat.so.14.0_ Various other things
> didn['t work either, including vim.
Had the same. Just fetch latest sets again and all is working.
ftp.hostserver.de has th
After upgrading to -current today I found that xenodm would not run
because of a missing /usr/lib/libexpat.so.14.0_ Various other things
didn['t work either, including vim.
As a temporary work-round I made a link for it to libexpat.so.13.0,
which seems to have made everything function again.
--
A
Thank you for the reply, I was just curious.
On Thu, 27 May 2021 at 04:21, Philip Guenther wrote:
>
> On Fri, May 21, 2021 at 5:28 AM George Brown <321.geo...@gmail.com> wrote:
>>
>> It seems this ELF note was used for the now dead compat_linux feature.
>> Aside from compat systems in other opera
Hi,
I have been trying to configure relayd for a few days now to multiplex
multiple servers running on the same local machine, while at the same
time taking care of TLS.
A simplified state of my configuration looks something like this:
log connection
log state changes
table { 127
13 matches
Mail list logo
