Re: Experience using httpd in production on busy machines?
I've never run a site with more than a few hundred users before but if you need more 'juice' to handle high volume traffic you could always up the prefork setting. There are also a few tcp knobs, that you probably shouldn't touch, that are mentioned in the httpd.conf(5) manual page. Other than that, just make sure to keep track of how full your pf(4) state table gets. Regards, JP
Re: (bug?) relayd forward to directives interfering
On 21/08/13 11:00pm, Vladimir Nikishkin wrote: > > This has actually been reported before: > > https://www.mail-archive.com/bugs@openbsd.org/msg14189.html Thank you, that information is certainly invaluable! Then might I suggest using the stunnel package in client mode. That way you can have two relayd "forward to" directives without tls. You the use stunnel to wrap the connection in TLS. I've done this sort of quackery before on a FreeBSD host as their relayd port is somewhat ancient and does not support the newer TLS protocols. Regards, JP
Re: literature on tmux
> I'd like to learn this program better. > > I prefer something printed/pressed instead of e-book. I own a copy of a neat little book published by "The Pragmatic Programmers" and written by Brian P. Hogan, specifically the 2nd edition. Though not as authoritative as the manual, it serves as a pretty decent summary. At the end of each chapter they also provide a convenient list of all the keybindings used in that chapter. More info, and an excerpt or two, on their web page: https://pragprog.com/titles/bhtmux2/tmux-2/ Regards, JP
Re: (bug?) relayd forward to directives interfering
On 21/08/11 04:34pm, Vladimir Nikishkin wrote: > I do not think my setup is related to "TLS Inspection". Apologies, my misunderstanding. I always forget I divert traffic to to localhost in my setup. Anyway, > There is no problem connecting to the TLS-enabled backend. The problem > appears when connecting to the HTTP backend, when, _at the same time_, > in the same relay there is another redirect to the TLS backend. Did you make sure to use the https scheme in your curl request? Something like: $ curl https://domain.example/http The listener is still a TLS listener even if the backend uses only plain http. Sorry for the confusion. Regards, JP
Re: (bug?) relayd forward to directives interfering
On 21/08/11 02:40pm, Vladimir Nikishkin wrote: > However, if I keep "with tls", the requests to port 81 are going > encrypted, and are failing with the following message in relayd logs: > `SSL routines:ST_CONNECT:tlsv1 alert protocol version`, > `TLS handshake error: handshake failed:`. What you're currently attemting is referred to as TLS inspection in relayd.conf(5). This is when one combines client and server modes. In order for TLS inspection to function properly the protocol options "ca cert" and "ca key" both need to be set. Further details found in the "TLS Relays" and "Protocols" sections of relayd.conf(5). Regards, JP
Re: rdr-to across wg tunnel
On 21/07/26 08:55am, deich...@placebonol.com wrote: > Did you enable forwarding? > > On July 25, 2021 10:22:58 PM MDT, Vincent Lee wrote: Basically, what this gentleman said. You've thus far not sent us any information of worth on your setup, or even a tcpdump(8). Please send us the output of (1) $ sysctl net.inet.ip.forwarding as well as that of (2) $ netstat -rnf inet The former needs to output 1 for any of this to work. It allow forwarding of packets across interfaces. If it outputs zero then simply set it via sysctl(8) and add the corresponding entry to sysctl.conf(5) In the case of (2), I suspect there might not be a route to the host on the other end. To resolve (2), assuming you've resolved (1), requires my favourite OpenBSD daemon: relayd(8). You can save yourself a lot of time by simply configuring a route context in relayd.conf(5). Regards, JP
Re: Using relayd as a reverse proxy for multiple local servers
I should mention, as I did in a thread months ago, there are extensive example configurations available in '/etc/examples'. Yours would be '/etc/examples/relayd.conf', which illustrates several typical use cases. Also, in future you might want to post the entirety of your configuration files. Otherwise, the responses will be just as vague and it wastes everyone's time (including yours). You may of course "sanitize" any identifying information like hostnames and public ip adressess.
Re: Using relayd as a reverse proxy for multiple local servers
Apologies yes, my error. I forgot I divert traffic using pf to my relayd listener. I've never seen/used a wildcard listen address in relayd before but I'm guessing that, in your case, a listener is created for each ip on every interface. This ofcourse raises the question: does every ip on every one of your interfaces map to one of your hosts? I ask this as I'm relatively certain relayd will expect a TLS certificate for each address it listens on, regardless of whether it forwards traffic from that IP to some host or not. This would explain why it complains that the IPv4 listener 'secure4' was unable to load a certificate. Regards, JP On 21/05/28 09:33pm, Philip Kaludercic wrote: > That confuses me, as one the one hand the manual says > > The relay will attempt to look up a private key in > /etc/ssl/private/name:port.key and a public certificate in > /etc/ssl/name:port.crt, WHERE PORT IS THE SPECIFIED PORT THAT THE > RELAY LISTENS ON. > > which would mean that the certificate should be called localhost:443 (or > 127.0.0.1:443), but then again the same paragraph says > > If not specified, a keypair will be loaded using the specified IP > address of the relay as name. > > Which I read as saying that it will try to use /etc/ssl/secure.key, in > my case. That obviously won't work, as I need different certificates for > different domains. > > -- > Philip K. >
Re: Resuming from suspend takes 12-14 seconds
In other words, you are probably better off asking on the amdgpu(4) mailing list: https://lists.freedesktop.org/mailman/listinfo/amd-gfx The link above, in fact, was copied from amdgpu(4). Other relevant links can also be found there alongside it. Regards, JP On 21/05/27 10:54pm, Theo de Raadt wrote: > 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! > > > > Except, there is one very annoying issue. > > Resuming from suspend _always_ takes 12-14 seconds at least. > > > > Say, I press the sleep button. Within two seconds, the PC goes into > > sleep. Then, I press any button on the keyboard to wake up the PC. As > > soon as I press the button, the POWER LED lights up, indicating that the > > hardware is up and running. But, the screen stays OFF for the next 11-13 > > seconds. Then, the display turns on and shows ttyC0, and after a second, > > automatically switches to Xenocara. > > > > > > Any idea what's causing the 11-13 second delay in the screen turning on? > > How do I go about diagnosing the problem? > > > > > > Also, in case it is relevant, I have noticed that these lines appear in > > dmesg when I suspend and resume - > > > > uhub0 detached > > video0 detached > > uvideo0 detached > > uhub1 detached > > iwm0: acquiring device failed > > uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" rev > > 3.00/1.00 addr 1 > > uhub1 at usb1 configuration 1 interface 0 "AMD xHCI root hub" rev > > 3.00/1.00 addr 1 > > uvideo0 at uhub1 port 2 configuration 1 interface 0 "SunplusIT Inc > > Integrated Camera" rev 2.01/54.22 addr 2 > > video0 at uvideo0 > > > > I presume that the first four lines are from suspending? And that the > > remaining lines are from resuming? > > > > I wondered if it could be that the delay is being caused by the failure to > > acquire iwm0? (iwm0 is my Intel WiFi card) > > So, I disabled my WiFi in BIOS. I also disabled USB, Camera, Microphone, > > Ethernet, and the Memory Card slot. But the problem is still there! > > > > Now, these lines appear on dmesg on suspend-resume (I don't know what > > uhub0 and uhub1 are) - > > > > uhub0 detached > > uhub1 detached > > uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" > > rev > > 3.00/1.00 addr 1 > > uhub1 at usb1 configuration 1 interface 0 "AMD xHCI root hub" > > rev > > 3.00/1.00 addr 1 > > > > > > I have no idea what is causing the delay. Any help to identify the > > problem is appreciated. > > > > Please pardon me if this is a simple mistake in my part... I am new to > > OpenBSD :) > > > > > > > > The full dmesg (with everything except Bluetooth enabled) follows - > > - > > OpenBSD 6.9 (GENERIC.MP) #1: Sat May 22 13:19:59 MDT 2021 > > > > r...@syspatch-69-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 32103845888 (30616MB) > > avail mem = 31115493376 (29674MB) > > random: good seed from bootblocks > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xbc627000 (58 entries) > > bios0: vendor LENOVO version "R11ET40W (1.20 )" date 11/17/2020 > > bios0: LENOVO 20NES02J00 > > acpi0 at bios0: ACPI 5.0 > > acpi0: sleep states S0 S3 S4 S5 > > acpi0: tables DSDT FACP SSDT SSDT SSDT TPM2 SSDT MSDM BATB HPET APIC > > MCFG SBST WSMT IVRS SSDT CRAT CDIT FPDT SSDT SSDT SSDT UEFI > > acpi0: wakeup devices GPP0(S3) GPP1(S4) GPP2(S3) GPP3(S3) GPP4(S3) > > GPP5(S3) GPP6(S3) GP17(S3) XHC0(S3) XHC1(S3) GP18(S3) LID_(S3) > > SLPB(S3) > > acpitimer0 at acpi0: 3579545 Hz, 32 bits > > acpihpet0 at acpi0: 14318180 Hz > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > cpu0 at mainbus0: apid 0 (boot processor) > > cpu0: AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx, 2096.33 MHz, 17-18-01 > > cpu0: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > > cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB > > 64b/line 8-way L2 cache > > cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully > > associative > > cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully > > associative > > cpu0: smt 0, core 0, package 0 > > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > > cpu0: apic clock running a
Re: Using relayd as a reverse proxy for multiple local servers
Personally, I would drop the keypairs you define and rename the
certificates as 'localhost.crt' for example.com and its subdomain and a
certificate 'localhost:8082' for handling beispiel.de. Similarly,
repeat this for the private keys as well.
No further configuration is needed after that. See the description of
'keypair' under the PROTOCOLS section in relayd.conf(8).
Regards,
JP
On 21/05/27 08:43am, Philip Kaludercic wrote:
>
> 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.0.0.1 }
> table { 127.0.0.1 }
> table { 127.0.0.1 }
> table { 127.0.0.1 }
>
> http protocol "http" {
> match request header "Host" value "example.com" forward to
> match request header "Host" value "sub.example.com" forward to
> match request header "Host" value "beispiel.de" forward to
> match request path "/.well-known/acme*" forward to
> }
>
> http protocol "https" {
> tls keypair "example.com" # responsible for example.com and
> sub.example.com
> tls keypair "beispiel.de"
>
> match request header "Host" value "example.com" forward to
> match request header "Host" value "sub.example.com" forward to
> match request header "Host" value "beispiel.de" forward to
> match request path "/.well-known/acme*" forward to
> }
>
> relay plain {
> listen on * port http
>
> protocol "http"
>
> forward to port 8080
> forward to port 8081
> forward to port 8082
> forward to port 8080
> }
>
> relay secure {
> listen on * port https tls
>
> protocol "https"
>
> forward to port 8080
> forward to port 8081
> forward to port 8082
> forward to port 8080
> }
>
> The "plain" relayd works just the way it should, it redirects every
> request to the right destination. "secure" on the other hand triggers an
> error I cannot make sense of:
>
> # relayd -nvvv
> relay_load_certfiles: using certificate /etc/ssl/example.com:443.crt
> relay_load_certfiles: using private key
> /etc/ssl/private/example.com:443.key
> relay_load_certfiles: using certificate /etc/ssl/beispiel.de:443.crt
> relay_load_certfiles: using private key
> /etc/ssl/private/beispiel.de:443.key
> /etc/relayd.conf:46: cannot load certificates for relay secure4:443
>
> I have looked into the source code, but couldn't find where "secure4"
> comes from. The certificates and keys were generated using acme-client,
> and they have the default permissions (crt is 444, key is 400).
>
> Am I doing the right thing here, considering what I want to achieve? I
> would be very grateful for any comments or hints on what I could be
> doing wrong.
>
> --
> Philip K.
>
Re: How to set ThinkPad battery charge thresholds?
Refer to sensorsd(8) and acpibat(4). Given those and related manual pages I'm relatively certain you should be able to achieve this. OpenBSD is well-known for its clear and extensive documentation so use this to your advantage. The apropos(1) utility is your best friend :). Your second and third best friends are the FAQ and the mailing list archives. I am working under the assumption that no proprietary blobs are necessary to accomplish your goal. Otherwise, I am afraid you are out of luck as OpenBSD does not and never will contain any such blobs. They are "black boxes" and thus cannot be trusted. Regards, JP On 21/03/08 07:05pm, Subhaditya Nath wrote: > I have a Thinkpad E495 that has Battery Charge threshold support. i.e. > it can be set such that the battery starts charging at a specified > amount of charge (say, 70%) and automatically stops charging at a > specified charge (say, 80%). This feature is also available on Linux by > using TLP (made by linrunner, his website is linrunner.de) > > The problem is, I searched for this option in OpenBSD, but I couldn't > find it. > > It is a very crucial functionality for me. So, if somebody can please > tell me where I can set it, I would be very very thankful. > > (Pardon my bad english, it's not my first language) >
Re: relayd error: socket_rlimit: max open files 1024
The entry openfiles-cur=1024 is overriding the entry openfiles=1024. Note that openfiles=value sets both openfiles-max=value and openfiles-cur=value. The setting openfiles-max setting is the upper limit which can only be changed by root while any user can change their own openfiles-cur up the maximum value set previously. You will either need to increase openfiles-cur or remove it completely and only have openfiles=4096. All this info and more is contained in login.conf(5) and getrlimit(2). However, I believe the recommended practice would be to create a new login class, called 'relayd' say, that inherits from the daemon class. This is specified using the entry: tc=daemon. Otherwise, every process running as a user in the daemon class will have these heightened privileges - and there's a lot of them. Regards, JP
Re: Bufferbloat, FQ-CoDel, and performance
Have you tried running the same test over UDP? This is done via the tcpbench's "-u" option. Regards, Jean-Pierre On 21/02/23 11:10am, Horia Racoviceanu wrote: > I noticed this effect as well. I'm not sure if it's the right thing to > do, but if a "min" value is added to the hfsc queue, fq_codel will use > the full link bandwith e.g. > > queue outq on em0 bandwidth 9M min 1M max 9M flows 1024 qlimit 1024 \ > default > > On 2/23/21, Todd C. Miller wrote: > > On Tue, 23 Feb 2021 11:29:00 +0100, Stefan Sperling wrote: > > > >> I've noticed a similar effect on a slower link (VDSL with 50 down/ 10 > >> up). > >> In this case the VDSL modem presents an Ethernet switch, so there is no > >> pppoe or vlan involved in the box that runs pf. > >> > >> As soon as I enable this example given in pf.conf(5): > >> > >> queue outq on em0 bandwidth 9M max 9M flows 1024 qlimit 1024 \ > >> default > >> > >> I see only about 2 or 3 Mbit/s max upload during tcpbench. > >> Which is indeed quite a hit compared to 10M. > > > > That's odd. I haven't had any problems with a VDSL connection with > > 100 down / 11 up. My config is very similar to yours: > > > > queue outq on em2 flows 1024 bandwidth 10M max 10M qlimit 1024 default > > > > where em2 the underlying interface used by pppoe0. Without queueing > > I have major problems when utilizing the upstream bandwidth, probably > > due to dropped ACKs. > > > > - todd > > > > >
Re: sndiod on by default (does it need to be ? )
If you are planning to deploy many systems in the near future and your deployment script is very invovled then you might want to consider building your own release and using that to install instead. This way you don't need to append your deployment script to either /install.site or /etc/rc.firsttime each time you install a new system. Sincerely, Jean-Pierre On 21/02/21 05:34pm, Tom Smyth wrote: > Hi folks, > thanks for everyone who replied on and off list, > I had not considered the console only user who uses audio also... > (I had not even considered this so pardon my ignorance folks, > and thanks to Sebastian, Abel, and David for replying on and off list > > I guess Ill just add rcctl disable sndiod to my deploy ment scripts > for my use cases :) > > Thanks again to all who considered it > > :) > > > > On Sun, 21 Feb 2021 at 14:28, Tom Smyth wrote: > > > > Hi Sebastian > > I get users want to listen to audio but if the only hardware is a buzzer > > and the user is not running x what are the chances they are using audio on > > the console only ? > > > > I can keep running > > rcctl disable sndiod > > Post install > > > > I thought linking audio support on by default to x would make sense as it > > is likely such system is for users who may need audio > > > > Just a thought > > Thanks > > > > > > On Sunday, 21 February 2021, Sebastian Benoit wrote: > >> > >> Tom Smyth(tom.sm...@wirelessconnect.eu) on 2021.02.21 04:08:48 +: > >> > Hello, > >> > > >> > I was wondering should sndiod (default) startup be determined based on > >> > whether or not > >> > it the install is a typical headless install (off) or an install for > >> > a user machine with running X > >> > > >> > is there a reason why one would need to run this daemon by default? > >> > >> Because users want to listen to audio. > >> > >> > my thinking is by having the service off by default would reduce the > >> > default attack surface of the OS ? > >> > >> How big is that attack surface? And especially compared to X? > >> > >> > perhaps the installer could use the answer to the question do you > >> > intend to run X to determine whether or not to enable the sndiod > >> > daemon ? > >> > >> The difference is that a running sndiod is not noticable to you. Running X > >> is - you dont have a console anymore on your screen. > >> > >> Whereas a not running sndiod is noticable - no sound. > >> > >> Next to security, we try to make it easy for people to use OpenBSD. Not > >> asking questions when not needed is just that. > >> > >> /Benno > > > > > > > > -- > > Kindest regards, > > Tom Smyth. > > > > -- > Kindest regards, > Tom Smyth. >
Re: Client-authenicated TLS handshake with relayd
In relayd.conf(5) it is explained that using the 'forward' statement with the 'with tls' directive enables client-side TLS mode. Refer to the aforementioned manual page for the exact syntax. Remember that you can check the syntax by running 'relayd -n'. Regards, Jean-Pierre On 21/02/19 12:15pm, Paul Pace wrote: > Hello! > > I am putting a small server behind Cloudflare that currently is configured > to serve everything through relayd. > > I want to use their option of client-authenticated TLS handshakes, but I > can't see a way to do it with relayd - is this possible? > > It does look like I could use httpd tls client ca option (assuming I'm > understanding the man page), which I can use if relayd doesn't support this. > > Thank you! > > Paul >
Re: Doas
You'll find plenty of examples in the directory "/etc/examples". It also helps that many (all?) programs written for the OpenBSD project are able to check the syntax of their own configuration files while printing any errors to standard output, including doas. Regards, Jean-Pierre de Villiers
Re: ACME client doesn't renew certificate (6.9-beta)
I'm going to assume your acme-client configuration is in order and that you are using httpd as your web server. Did you not perhaps forget to reload httpd via rcctl after renewing your certificate? Otherwise, I suspect you're going to have to give us more context. Regards, Jean-Pierre On 21/02/16 06:47pm, Teno Deuter wrote: > OpenBSD 6.9-beta (GENERIC) #328: Mon Feb 15 10:31:18 MST 2021 > > I run: > > # acme-client -vF <>.com > acme-client: /etc/ssl/<>.com.crt: certificate valid: 89 days left > acme-client: /etc/ssl/<>.com.crt: forcing renewal > acme-client: https://acme-v02.api.letsencrypt.org/directory: directories > acme-client: acme-v02.api.letsencrypt.org: DNS: 172.65.32.248 > acme-client: > https://acme-v02.api.letsencrypt.org/acme/finalize/86925799/7946011420: > certificate > acme-client: order.status 3 > acme-client: > https://acme-v02.api.letsencrypt.org/acme/cert/045439171e7c06c448e2584a12e832150e60: > certificate > acme-client: /etc/ssl/<>.com.crt: created > acme-client: /etc/ssl/<>.com.fullchain.pem: created > > but when I access it in Firefox I get a warnung because: > > Let's Encrypt > Validity > Not Before 11/1/2020, 9:25:02 PM (Eastern European Standard Time) > Not After 1/30/2021, 9:25:02 PM (Eastern European Standard Time) > > Thank you
