Re: ssh(1) -v gives debug1: pledge: filesystem full

2021-05-19 Thread Hiltjo Posthuma
On Wed, May 19, 2021 at 01:20:34PM +0200, Marcus MERIGHI wrote:
> Hello!
> 
> By accident I noticed that 
> 
> $ ssh -v $host
> 
> gives me, among many other lines, this
> 
> debug1: pledge: filesystem full
> 
> Tried with multiple hosts. None of the filesystems on the hosts (client,
> servers) is full. The messages appears when connecting from -current (as
> of yesterday) to 6.9, when connecting from 6.9 to 6.9 and when
> connecting from -current to -current.
> 
> My .ssh/config has:
> 
> Host *
> ServerAliveInterval 15
> ServerAliveCountMax 4
> AddKeysToAgent yes
> 
> Host a b c d e f
> ForwardAgent yes
> 
> host g h
> ProxyJump i
> CheckHostIP no
> 
> Is this expected? Something to worry about?
> 
> Marcus
> 

Hi,

A grep shows its in the file /usr/src/usr.bin/ssh/clientloop.c client_loop()
function.

Its probably intended to mean "pledge for full filesystem promises". Instead of
having a full filesystem (no more space) :)

-- 
Kind regards,
Hiltjo



Re: sensor value last change time not updated?

2020-08-14 Thread Hiltjo Posthuma
On Fri, Aug 14, 2020 at 01:46:57PM +0200, Paul de Weerd wrote:
> Hi all,
> 
> I'm trying to read temperature sensor values from my ugold(4) device.
> Seems to work alright (I get the same temperature reading as sysctl(8)
> returns for the sensor), but the 'sensor value last change time'
> doesn't seem to be updated.
> 
> [weerd@pom] $ cat sensor_last_change.c  
> #include 
> #include 
> #include 
> #include 
> 
> int
> main()
> {
>   int mib[5];
>   size_t  sensorlen;
>   struct sensor   sensor;
> 
>   mib[0] = CTL_HW;
>   mib[1] = HW_SENSORS;
>   mib[2] = 3; /* ugold0 on my machine */
>   mib[3] = SENSOR_TEMP;
>   mib[4] = 0;
> 
>   sensorlen = sizeof(sensor);
>   sysctl(mib, 5, , , NULL, 0);
>   printf("%lld.%06ld: %.2f\n",
>   sensor.tv.tv_sec,
>   sensor.tv.tv_usec,
>   ((sensor.value-27315)/100.0));
> 
>   return 0;
> }
> [weerd@pom] $ make sensor_last_change   
> cc -O2 -pipe   -MD -MP   -o sensor_last_change sensor_last_change.c 
> [weerd@pom] $ ./sensor_last_change
> 0.00: 32.32
> [weerd@pom] $ sysctl -n hw.sensors.ugold0.temp0
> 32.32 degC (inner)
> 
> The 'tv' member of struct sensor seems to always be 0.0.  Am I doing
> something wrong?
> 
> Cluesticks very welcome...
> 
> Thanks,
> 
> Paul
> 
> -- 
> >[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
>  http://www.weirdnet.nl/ 
> 

Hi,

I don't think you're doing anything wrong, but I don't think its supported by
the device and it's simply not set and so stays zero.

A quick grep shows some files which do use it:

/usr/src/sys $ grep -R sc_sensor\.tv .
./dev/gpio/gpiodcf.c:   microtime(>sc_sensor.tv);
./dev/pv/hypervic.c:microtime(>sc_sensor.tv);
./dev/pv/vmt.c: struct timeval *guest = >sc_sensor.tv;
./dev/pv/vmmci.c:   struct timeval  *guest = >sc_sensor.tv;
./dev/usb/udcf.c:   microtime(>sc_sensor.tv);

I have a ugold(4) device and will gladly test any improvements/patches.

-- 
Kind regards,
Hiltjo



Re: unveil confusion

2020-04-23 Thread Hiltjo Posthuma
On Thu, Apr 23, 2020 at 09:33:51AM +0200, Peter J. Philipp wrote:
> Hi,
> 
> From the unveil manpage:
> 
>  The first call to unveil() removes visibility of the entire filesystem
>  from all other filesystem-related system calls (such as open(2), chmod(2)
>  and rename(2)), except for the specified path and permissions.
> 
> Can the first call also be the last?  I have a test program called 
> unveiltest.c
> and it does the following:
> 
> paste>
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> int
> main(void)
> {
> int fd;
> 
> #ifdef UNVEIL_MOTD
> if (unveil("/etc/motd", "r") < 0)
> perror("unveil");
> #endif
> if (unveil(NULL, NULL) < 0)
> perror("unveil");
> 
> for (;;) {
> if ((fd = open("/etc/motd", O_RDONLY, 0)) < 0)
> perror("open");
> else
> close(fd);
> 
> sleep(1);
> }
> }
> <--
> 
> When I run it without UNVEIL_MOTD, meaning my first (and last) unveil was
> NULL, NULL.. it doesn't deny /etc/motd reads.
> 
> beta$ cc -g -o unveiltest unveiltest.c   
> beta$ ./unveiltest 
> ^C
> 
> beta$ ps ax | grep unveiltest
> 21482 pg  S+   0:00.10 ./unveiltest
> 98206 ph  R+/3 0:00.00 grep unveiltest
> 
> And when I recompile with UNVEIL_MOTD same behaviour:
> 
> beta$ cc -g -DUNVEIL_MOTD -o unveiltest unveiltest.c 
> beta$ ./unveiltest  
> ^C
> 
> except there is a difference in the ps listing:
> 
> beta$ ps ax | grep unveiltest 
> 40907 pg  S+U  0:00.01 ./unveiltest
> 40013 ph  R+/2 0:00.00 grep unveiltest
> 
> Am I interpreting unveil manpage wrong or is it written wrong?  I did have
> a first call to unveil in the first example only it's NULL, NULL, me telling
> the system I don't want anything opened at all.  Is there any way to do that?
> 
> Or is that pledge()'s job?  
> 
> Another weird one I have is that I call unveil() to a path but chroot() later,
> then call unveil(NULL, NULL) and the ps flag doesn't indicate the U flag.  Is 
> because of the chroot() the unveil lost?
> 
> Best regards,
> -peter
> 

Hi,

Below the quoted part it says in the man page:

"After establishing a collection of path and permissions rules, future
 calls to unveil() can be disabled by passing two NULL arguments.
 Alternatively, pledge(2) may be used to remove the "unveil" promise."

So you could use the code:

if (unveil("/", "") == -1)
err(1, "unveil");
if (unveil(NULL, NULL) == -1)
err(1, "unveil");

For example see netcat, vmstat.

By the way, maybe it's intentional but perror does not exit the program. The
often used pattern is to use:

err(1, "unveil");

-- 
Kind regards,
Hiltjo



Re: Multi-domain DKIM signature with OpenSMTPd

2020-03-18 Thread Hiltjo Posthuma
On Wed, Mar 18, 2020 at 06:23:30PM +0100, Matthieu wrote:
> Hi everybody
> I'm looking to use OpenDKIM with OpenSMTPd. Has anyone ever done it before ?
> My first intention is to sign mails from different domains on a single mail
> server. So the
> 
> OpenDKIM works with a socket and I don't know how and if it works with the
> smptd filter.
> I've seen the «opensmptd-filter-dkimsign» packet, but we can only specify
> one domaine.
> 
> Otherwise I'd be looking at the side of dkimproxy if it can do the job or
> not.
> 
> Thx for any help.
> 

Hi,

Theres an example described in the smtpd.conf(5) man page.

opensmtpd filters are in ports as a package: opensmtpd-filter-dkimsign

The source-code is at: https://imperialat.at/dev/filter-dkimsign/ in main.c
It's relatively small and also privilege-separated.

It has a parameter to set the domain name (-d). In smtpd.conf you can define
multiple filters. See also the man page filter-dkimsign(8) for detailed
information.

I've replaced dkimproxy (Perl-based and complex) with
opensmtpd-filter-dkimsign. It works well for my needs.

-- 
Kind regards,
Hiltjo



Re: man to render pure text? (or a pipe in vi macros ?)

2020-03-02 Thread Hiltjo Posthuma
On Mon, Mar 02, 2020 at 06:25:47PM +0100, Ingo Schwarze wrote:
> Hi,
> 
> Marc Chantreux wrote on Mon, Mar 02, 2020 at 11:49:31AM +0100:
> 
> > coming from linux, i'm used to read manpages
> > in a vi buffer so i can do much more than
> > reading the content.
> 
> I have no idea what the "much more" refers to.  The main effect is to
> lose tagging functionality.  That is, compared to man(1) with the
> default pager, you cannot use the :t functionality to move to the
> place where a word is defined.
> 
> > i basically use
> > 
> > :r !man ls
> > or
> > !!sh (when the line content is "man ls")
> 
> Yikes.  I had no idea what either of these are doing and had to
> try them out.  vi(1) contains so much bloat that is never really
> needed and doesn't belong in a text editor at all.
> 
> > under openbsd, it seems man doesn't if stdout
> > is a tty.
> 
> You mean, man(1) doesn't *imply col -b* if stdout is *not* a tty?
> 
> > i digged the man manual a little bit
> > without finding a solution so i worked the
> > things around:
> > 
> > :r !man ls|fmt
> 
> As others said, the normal way to strip backspace formatting is
> 
>$ man ls | col -b
> 
> It is documented in man(1) below the -c option and below EXAMPLES,
> and in mandoc(1) below "ASCII Output":
> 
>   https://man.openbsd.org/man.1#c
>   https://man.openbsd.org/man.1#EXAMPLES
>   https://man.openbsd.org/mandoc.1#ASCII_Output
> 
> You find such stuff as follows:
> 
>$ man -k 'Xr=col(1)'
>   man(1) - display manual pages
>   mandoc(1) - format manual pages
> 
> The advantage of col(1) over fmt(1) is that it is guaranteed to not
> mess up line breaks.
> 
> > now i would like a poor version of keyword
> > feature in openbsd vi. the linux version
> > 
> > map K yw:E /tmp/vi.keyword.$$p!!xargs man
> 
> You don't say what that is supposed to do.
> 
> Under Debian Jessie, if i start "vim", then type
> 
>   :map K yw:E /tmp/vi.keyword.$$p!!xargs man   
>   als   
>   K   
> 
> i get:
> 
>   Error detected while processing function 
> netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore:
>   line   30:
>   E132: Function call depth is higher than 'maxfuncdepth'
>   Press ENTER or type command to continue
> 
> That doesn't seem useful to me.
> 
> I also tried the same with OpenBSD vi(1) and it resulted in
> 
>   Usage: e[dit][!] [+cmd] [file].
> 
> So, no idea what you are trying to do.
> 
> > becomes
> > 
> > map K yw:E /tmp/vi.keyword.$$p!!xargs -IX sh -c 'man X|fmt'
> > 
> > which doesn't work as | separates 2 vi commands.
> > 
> > i really would like to know one or the two of these:
> > 
> > * is there a way to ask man to deliver pure (non-formatted) text ?
> 
> In 2014, i already wrote a patch to do that because the question
> came up repeatedly.  But demand wasn't that high after all, so i
> never committed it.  Now, i updated the patch to -current, see
> below.
> 
> On the one hand, the UNIX phlosophy is to have each tool do one
> thing well, then use pipes to connect tools as needed.  Then again,
> arguably, you maybe shouldn't need another tool to just revert
> something that the first tool does.  Why would *not* adding backspace
> formatting require a pipe to another program, rather than not adding
> it in the first place?
> 
> Also, the patch that would be required is very small and straightforward.
> 
> So, what do people think?  Should i test the patch below in more
> depth and commit it?  Or do people consider this bloat?
> 
> Yours,
>   Ingo
> 
> 
> Index: main.c
> 

Re: doas(1) adjustable timeout length

2019-12-19 Thread Hiltjo Posthuma
On Thu, Dec 19, 2019 at 02:03:19PM -0700, andrej wrote:
> Hi Ted,
> 
> On the note of accurate documentation; how about adding the actually defined
> timeout for persist rather than the "some time"?
> 
> 
> Cheers,
> Andrej
> 
> 
> 
> --
> Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
> 

Hi Andrej,

Sometimes there is a reason implementation details are not specificly
documented, but I don't know if thats the case here.


Patch:


diff --git usr.bin/doas/doas.conf.5 usr.bin/doas/doas.conf.5
index b5cacde22cd..b541aef966c 100644
--- usr.bin/doas/doas.conf.5
+++ usr.bin/doas/doas.conf.5
@@ -47,7 +47,7 @@ Options are:
 The user is not required to enter a password.
 .It Ic persist
 After the user successfully authenticates, do not ask for a password
-again for some time.
+again for 5 minutes for the session.
 .It Ic keepenv
 Environment variables other than those listed in
 .Xr doas 1

-- 
Kind regards,
Hiltjo



Re: Redraw of terminal change in 6.6?

2019-11-14 Thread Hiltjo Posthuma
On Wed, Nov 13, 2019 at 03:00:05PM +0100, Mischa wrote:
> > On 4 Nov 2019, at 16:51, Mischa  wrote:
> >> On 2 Nov 2019, at 15:19, Hiltjo Posthuma  wrote:
> >> On Sat, Nov 02, 2019 at 08:32:50AM +0100, Mischa wrote:
> >>> Hi All,
> >>> 
> >>> Not sure if this is on my side, setting, or if something has changed with 
> >>> tmux or top redrawing of the terminal.
> >>> I am using tmux, over mosh, on one of my jump hosts to connect to other 
> >>> hosts. In some of the windows I have a remote top -C running.
> >>> When I am attaching the tmux session on a smaller display, for example my 
> >>> phone, the output of top is fine.
> >>> 
> >>> However when I connect back with a larger display the output of top is 
> >>> completely garbled. It does recover line by line when processes jump to a 
> >>> different “rank”.
> >>> 
> >>> Below are two screenshots with roughly 5 minutes between them.
> >>> Anything I can test? Change? Do?
> >>> 
> >>> Thanx!!
> >>> 
> >>> Mischa
> >>> 
> >> 
> >> Hi,
> >> 
> >> Same issue here since upgrading from 6.5 to 6.6.
> >> 
> >> I don't use mosh, but connect via SSH to a remote machine and attaching to 
> >> tmux
> >> running irssi.  It is attached to a shared session. The first attached
> >> resolution/window size is bigger.
> >> 
> >> Maybe it is fixed already:
> >> https://cvsweb.openbsd.org/src/usr.bin/tmux/server-client.c
> >> rev 1.296
> > 
> > Thanx! Will check it out.
> 
> With -current I am still seeing the issue. Anybody else?
> 
> Mischa
> 
> 

Hey Mischa,

Assuming we have the same issue: I have bisected my issue to this commit now:

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/tmux/server-client.c.diff?r1=1.293=1.294
server-client.c Revision 1.294, Wed Aug 28 07:34:32 2019 UTC

It can be reproduced now also in a local single tmux session with these steps:

- Start tmux.
- C-b c (new window).
- Start top -C -s 1 in one window.
- Let top refresh one second.
- Switch to the other tmux window.
- Resize the client in some way.
- Wait a second for top to redraw.
- Switch back to the window that is running top.
- The text is not drawn correctly.

In practise this happens for me when irssi redraws its contents in a similar
way.

I'll try to figure out a patch, but can you confirm if reverting this commit
also fixes your issue?

-- 
Kind regards,
Hiltjo



Re: Redraw of terminal change in 6.6?

2019-11-02 Thread Hiltjo Posthuma
On Sat, Nov 02, 2019 at 08:32:50AM +0100, Mischa wrote:
> Hi All,
> 
> Not sure if this is on my side, setting, or if something has changed with 
> tmux or top redrawing of the terminal.
> I am using tmux, over mosh, on one of my jump hosts to connect to other 
> hosts. In some of the windows I have a remote top -C running.
> When I am attaching the tmux session on a smaller display, for example my 
> phone, the output of top is fine.
> 
> However when I connect back with a larger display the output of top is 
> completely garbled. It does recover line by line when processes jump to a 
> different “rank”.
> 
> Below are two screenshots with roughly 5 minutes between them.
> Anything I can test? Change? Do?
> 
> Thanx!!
> 
> Mischa
> 

Hi,

Same issue here since upgrading from 6.5 to 6.6.

I don't use mosh, but connect via SSH to a remote machine and attaching to tmux
running irssi.  It is attached to a shared session. The first attached
resolution/window size is bigger.

Maybe it is fixed already:
https://cvsweb.openbsd.org/src/usr.bin/tmux/server-client.c
rev 1.296

-- 
Kind regards,
Hiltjo



Re: Setting charset in Content-Type header with relayd and httpd

2019-10-29 Thread Hiltjo Posthuma
On Tue, Oct 29, 2019 at 08:41:54PM +0100, Bertalan Zoltán Péter wrote:
> Hello,
> 
> I have a working httpd server behind a relayd reverse proxy.
> 
> Recently I wanted to host some simple text files in a directory that
> contained UTF-8 characters. Unfortunately, I noticed that when opened
> from a browser, say iridium, these documents render with incorrect
> encoding and are illegible. When using curl from my terminal emulator
> however, things worked as expected.
> 
> I suspect this is due to the lack of the 'charset' setting in the
> Content-Type response from my server.
> 
> I suppose I can't set this from httpd's config, but I have to change the
> header with relayd. I found that I could use something like this:
> 
> match response header append "Content-Type" \
>   value "charset=utf-8"
> 
> But this actually seems to create another Content-Type header and does
> not help. I could also just do
> 
> match response header set "Content-Type" value \
>   "text/plain; charset=utf-8"
> 
> But this would make every response classify as text/plain which of
> course is undesirable.
> 
> Is there a proper way to do this? Can I somehow match when text files
> are requested and only then set the header? I tried something with the
> `url` and `path` keywords but after I reloaded relayd it said (ok) but
> did not serve anything with the new config.
> 
> Thanks for your help
> Bertalan
> 
> -- 
> Bertalan Z. Péter 
> FB9B 34FE 3500 3977 92AE  4809 935C 3BEB 44C1 0F89
> 
> /"\
> \ /ASCII Ribbon Campaign
>  X   against HTML email & proprietary attachments
> / \www.asciiribbon.org
> 


Hi,

You can actually do it in httpd.conf.

This will give a syntax error (httpd -n):

"text/plain; charset=utf-8" txt

Using quoting will work:

"text"/"plain; charset=utf-8"   txt

-- 
Kind regards,
Hiltjo



Re: Openrsync poll Hangup

2019-06-15 Thread Hiltjo Posthuma
On Sat, Jun 15, 2019 at 02:44:47PM +0100, Kevin Chadwick wrote:
> Whilst getting current packages from the leaseweb mirror. I kept getting a 
> stall
> followed by poll:hangup with 6.5 openrsync -v -a --delete
> 
> Eventually all the packages download as it gets further each time.
> 
> I tried building the latest openrsync from the current src tree still on 6.5 
> but
> I get the same issue.
> 
> If you want me to try a different mirror or anything then let me know. I can 
> use
> pkgd rsync without the priv sep otherwise for now.
> 
> Regards, Kc
> 

Hi,

In my testing I also saw a poll hangup error (using only local directories).  I
have not found the cause yet though, but will look at it and try to write some
patch.

It would be interesting to see the calls in the ktrace before this occurs.

-- 
Kind regards,
Hiltjo



Re: doas called multiple times hangs

2019-01-21 Thread Hiltjo Posthuma
On Mon, Jan 21, 2019 at 11:06:58AM +0100, Dariusz Sendkowski wrote:
> I applied this patch, as is, to the stable sources and it works now.
> Thanks.
> 
> 

I've tested this patch too on 6.4 on amd64 and it seems fixed now.

Thanks Ted for the patch :)


A quick little program to reproduce the issue:

#include 
#include 

int
main(void)
{
int i;

for (i = 0; i < 2; ++i) {
printf("%d\n", i);
unveil("/nonexistant/ls", "x");
}

return 0;
}

> 
> pon., 21 sty 2019 o 06:03 Ted Unangst  napisał(a):
> 
> > Ted Unangst wrote:
> > > Dariusz Sendkowski wrote:
> > > > Yes, it does.
> > > >
> > > > I extracted 'unveilcommands' function from doas.c and put it into a
> > > > standalone program to run it.
> > > > It turned out the result was the same as in doas command. When I
> > disable
> > > > unveil, then it works fine.
> > >
> > > This diff should fix the problem.
> >
> > Actually, miscalculation. This is a better diff. Sorry for the trouble.
> > Against current, but should be adaptable to stable.
> >
> > Index: vfs_syscalls.c
> > ===
> > RCS file: /cvs/src/sys/kern/vfs_syscalls.c,v
> > retrieving revision 1.310
> > diff -u -p -r1.310 vfs_syscalls.c
> > --- vfs_syscalls.c  3 Jan 2019 21:52:31 -   1.310
> > +++ vfs_syscalls.c  21 Jan 2019 04:57:17 -
> > @@ -92,6 +92,7 @@ int dofutimens(struct proc *, int, struc
> >  int dounmount_leaf(struct mount *, int, struct proc *);
> >  int unveil_add(struct proc *, struct nameidata *, const char *);
> >  void unveil_removevnode(struct vnode *vp);
> > +void unveil_free_traversed_vnodes(struct nameidata *);
> >  ssize_t unveil_find_cover(struct vnode *, struct proc *);
> >  struct unveil *unveil_lookup(struct vnode *, struct proc *, ssize_t *);
> >
> > @@ -911,7 +912,7 @@ sys_unveil(struct proc *p, void *v, regi
> >
> > nd.ni_pledge = PLEDGE_UNVEIL;
> > if ((error = namei()) != 0)
> > -   return (error);
> > +   goto end;
> >
> > /*
> >  * XXX Any access to the file or directory will allow us to
> > @@ -948,6 +949,10 @@ sys_unveil(struct proc *p, void *v, regi
> > vrele(nd.ni_vp);
> > if (nd.ni_dvp && nd.ni_dvp != nd.ni_vp)
> > vrele(nd.ni_dvp);
> > +
> > +   pool_put(_pool, nd.ni_cnd.cn_pnbuf);
> > +end:
> > +   unveil_free_traversed_vnodes();
> >
> > return (error);
> >  }
> > Index: kern_unveil.c
> > ===
> > RCS file: /cvs/src/sys/kern/kern_unveil.c,v
> > retrieving revision 1.22
> > diff -u -p -r1.22 kern_unveil.c
> > --- kern_unveil.c   17 Jan 2019 03:26:19 -  1.22
> > +++ kern_unveil.c   21 Jan 2019 05:01:26 -
> > @@ -630,8 +630,6 @@ unveil_add(struct proc *p, struct nameid
> >   done:
> > if (ret == 0)
> > unveil_add_traversed_vnodes(p, ndp);
> > -   unveil_free_traversed_vnodes(ndp);
> > -   pool_put(_pool, ndp->ni_cnd.cn_pnbuf);
> > return ret;
> >  }
> >
> >

-- 
Kind regards,
Hiltjo



Re: doas called multiple times hangs

2019-01-20 Thread Hiltjo Posthuma
On Sun, Jan 20, 2019 at 11:15:38AM +0100, Dariusz Sendkowski wrote:
> Hi,
> 
> Calling 'doas' in a loop makes the machine hang.
> I guess this is not an expected behavior.
> It can be checked by executing the following simple bash script:
> 
> for i in {0..2}
> do
> doas ls some_dir
> done
> 
> I have run it on three different machines and the result is the same on
> each of them. After about 9000 iterations the entire machine hangs.
> Executing the script without 'doas' works fine.

Hi,

Just tested, but no issue here on -current.

What is your doas.conf contents and OpenBSD version / dmesg?

-- 
Kind regards,
Hiltjo



Re: USB stick recovery after dd with miniroot64.fs

2019-01-03 Thread Hiltjo Posthuma
On Thu, Jan 03, 2019 at 06:19:41PM +0200, Mihai Popescu wrote:
> Hello,
> 
> I used a storage USB stick to dd the miniroot64.fs on it. It was the
> wrong one with some useful files saved on it and I did the dd
> if=miniroot64.fs of=/dev/rsd1c bs=1m and let it write. The USB size is
> almost 32Gb, it was configured as one msdos partition, sd1i.
> 
> Is there any chance to recover even some files from this USB stick?
> I read some disaster recipes, but I want to ask for the best one, to
> avoid even more damage.
> 
> Thank you.
> 

sysutils/testdisk is very good.

Good luck,

-- 
Kind regards,
Hiltjo



Re: Httpd unix socket

2018-12-23 Thread Hiltjo Posthuma
On Sun, Dec 23, 2018 at 02:03:25AM +0100, Flipchan wrote:
> Hey,
> 
> I have a http server listening on a socket in /var/www/run/listen.sock , with 
> permissions 0666 and www:www i can curl the socket and it works , but it does 
> not work when i try to use it with httpd, maybe because httpd only support 
> fastcgi sockets and not "raw" unix sockets.
> 
> Does anyone know how to get httpd to use unix sockets?
> 

> The only solution i could image was to monkey hack a fastcgi socket to 
> reverse proxy to the regular socket, this was without success.
> 

Hi,

As a reverse-proxy you could use relayd(8) before incoming HTTP data.

-- 
Kind regards,
Hiltjo



Re: pkg_add source code modification

2018-12-15 Thread Hiltjo Posthuma
On Sat, Dec 15, 2018 at 07:49:19PM +0200, Mihai Popescu wrote:
> Hello,
> 
> I want to modify the char used for pkg_add (and other pkg_ suite)
> progress bar from "*" to "|" but i am unable to figure out where is
> the actual code for this. I managed to found /usr/sbin/pkg_add but
> there are another links in there, and perl for me is a no idea
> language.
> 
> It could be that what I want is not so simple or it is not
> recommended. I will accept that gladly if that's the case. Could you
> give me some hints for this modification?
> 
> Thank you.
> 

Hi,

It is in:

/usr/src/usr.sbin/pkg_add/OpenBSD/ProgressMeter/Term.pm

sub show

Maybe in the christmas style you could use a snowman instead :P

☃

-- 
Kind regards,
Hiltjo



Re: Portslist

2018-11-24 Thread Hiltjo Posthuma
On Sat, Nov 24, 2018 at 02:32:02PM +0100, Jan Betlach wrote:
> Hi all,
> 
> strange problem. I am running -current. I have downloaded latest ports
> tree .tar.gz to /temp, then tar xzf in /usr.
> All ports are where they belong (/usr/ports).
> However when searching anything (make search key=package) I get
> following error:
> Please install portslist
> pkg_add portslist
> *** Error 1 in /usr/ports (Makefile:80 '/usr/local/share/ports-INDEX':
> @exit 1)
> 
> Any help is appreciated. Thank you
> 
> Jan

Hi,

See the mail from:
Subject: bye bye INDEX
Date:2018-11-16 10:33:33

Archive:
https://marc.info/?l=openbsd-ports=154236447922665=2

-- 
Kind regards,
Hiltjo



Re: httpd write file out from within cgi script

2018-08-11 Thread Hiltjo Posthuma
 socket_rlimit: max open files 1024
> startup
> server_privinit: adding server 127.0.0.1
> socket_rlimit: max open files 1024
> socket_rlimit: max open files 1024
> server_launch: configuring server 127.0.0.1
> server_launch: running server 127.0.0.1
> server_launch: configuring server 127.0.0.1
> server_launch: running server 127.0.0.1
> server_launch: configuring server 127.0.0.1
> server_launch: running server 127.0.0.1
> 127.0.0.1 192.168.178.29 - - [09/Aug/2018:19:39:13 +0200] "GET 
> /cgi-bin/test.pl HTTP/1.1" 200 0
> 
> # cat /etc/httpd.conf
> server "127.0.0.1" {
> listen on * port 80
> location "/cgi-bin/*" {
> fastcgi
> root "/"
> }
> }
> 
> # ls -l /var/www/usr/bin/
> total 20
> -rwxr-xr-x  1 root  daemon  9296 Apr 15 11:19 perl
> 
> # ls -l /var/www/usr/lib/
> total 15576
> -r--r--r--  1 root  daemon  2862990 Apr 15 11:19 libc.so.89.3
> -r--r--r--  1 root  daemon   463356 Apr 15 11:19 libm.so.10.0
> -r--r--r--  1 root  daemon  4293077 Apr 15 11:20 libperl.so.18.0
> -r--r--r--  1 root  daemon   146552 Apr 15 11:20 libpthread.so.23.0
> -r--r--r--  1 root  daemon   125877 Apr 15 11:20 libutil.so.12.1
> 
> # ls -l /var/www/usr/libexec/
> total 372
> -r--r--r--  1 root  daemon  189764 Apr 15 11:21 ld.so
> 
> Still no error but no written file as well.
> 
> Am 11.08.2018 um 21:13 schrieb Hiltjo Posthuma:
> > On Sat, Aug 11, 2018 at 07:58:02PM +0200, Toru Okada wrote:
> >> Hi:
> >>
> >> I want to write a file out from within a perl cgi script. This is 
> >> obviously not possible in the standard configuration of httpd. The normal 
> >> output works perfectly. What is to do?
> >>
> >> #!/usr/bin/perl
> >>
> >> print("Content-Type: text/html; charset=ascii\n\n");
> > 
> > Unrelated but the line-endings should be "\r\n" for these headers.
> > https://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2
> > 
> >> print("hello world"); # works
> >> # no error but not found in file system after the script finished
> >> open(my $fh, ">", "out") or die $!;   
> > 
> > Maybe some permission/work directory issue? Try writing to an absolute path.
> > slowcgi is chrooted by default, so maybe it tries to write to /var/www/out 
> > and
> > it has no permissions for that?
> > 
> > Running httpd -d -vv and slowcgi -d can help to debug too.
> > 
> >> print($fh "foo");
> >> close($fh);
> >>
> >> OpenBSD 6.1
> >>
> >> Many thanks in advance.
> >>
> > 
> 

-- 
Kind regards,
Hiltjo



Re: httpd write file out from within cgi script

2018-08-11 Thread Hiltjo Posthuma
On Sat, Aug 11, 2018 at 07:58:02PM +0200, Toru Okada wrote:
> Hi:
> 
> I want to write a file out from within a perl cgi script. This is obviously 
> not possible in the standard configuration of httpd. The normal output works 
> perfectly. What is to do?
> 
> #!/usr/bin/perl
> 
> print("Content-Type: text/html; charset=ascii\n\n");

Unrelated but the line-endings should be "\r\n" for these headers.
https://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2

> print("hello world"); # works
> # no error but not found in file system after the script finished
> open(my $fh, ">", "out") or die $!;   

Maybe some permission/work directory issue? Try writing to an absolute path.
slowcgi is chrooted by default, so maybe it tries to write to /var/www/out and
it has no permissions for that?

Running httpd -d -vv and slowcgi -d can help to debug too.

> print($fh "foo");
> close($fh);
> 
> OpenBSD 6.1
> 
> Many thanks in advance.
> 

-- 
Kind regards,
Hiltjo



Re: sshfs permission problem

2018-08-10 Thread Hiltjo Posthuma
On Fri, Aug 10, 2018 at 10:38:52AM +0200, Hiltjo Posthuma wrote:
> On Fri, Aug 03, 2018 at 01:44:39PM +0200, Rudolf Sykora wrote:
> > Hello!
> > 
> > I run
> > 
> > doas sshfs syk...@pc109.fzu.cz: /home/ruda/mnt/fzu -o uid=1000 -o gid=1000
> > 
> > But then the mount point is owned (after the mounting) by root:
> > 
> > drwx--  1 root  wheel512 Aug  3 13:22 fzu
> > 
> > Hence I cannot enter the directory as the usual (and wanted) user 'ruda'.
> > 
> > 1) doas chmod 777 fzu does not help (does nothing)
> > 2) doas chown ruda:ruda fzu   gives permission denied
> > 
> > What can I do?
> > 
> > Thanks
> > Ruda
> > 
> 
> Hi,
> 
> I have the same issue here.
> 
> chmod 777 changes the permisions, but seems to reset them automatically after 
> a
> second or so.
> 
> The umask  suggestion doesn't work either unfortunately.
> 
> On 6.3 this problem doesn't occur, but on -current it does. I'll try to bisect
> it later.
> 
> -- 
> Kind regards,
> Hiltjo
> 

I figured it out and it doesn't seem like a bug, just a changed behaviour. The
following commit changed it:

CVS revision 1.47:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libfuse/fuse.c?rev=1.47=text/x-cvsweb-markup

or git commit:

commit 0f4d2db5a50672bad418a08041219503c0deeced
Author: helg 
Date:   Tue Jun 19 13:01:34 2018 +

Changes the default mount behaviour so only the user that mounts the
file system can access it unless the allow_other mount options is
specified. The allow_other mount option makes the file system
available to other users just like any other mounted file system.

ok mpi@


So the solution is to use the option: -o allow_other, for example:
sshfs -o allow_other user@host:dir /mnt/mount

I hope this helps someone.

-- 
Kind regards,
Hiltjo



Re: sshfs permission problem

2018-08-10 Thread Hiltjo Posthuma
On Fri, Aug 03, 2018 at 01:44:39PM +0200, Rudolf Sykora wrote:
> Hello!
> 
> I run
> 
> doas sshfs syk...@pc109.fzu.cz: /home/ruda/mnt/fzu -o uid=1000 -o gid=1000
> 
> But then the mount point is owned (after the mounting) by root:
> 
> drwx--  1 root  wheel512 Aug  3 13:22 fzu
> 
> Hence I cannot enter the directory as the usual (and wanted) user 'ruda'.
> 
> 1) doas chmod 777 fzu does not help (does nothing)
> 2) doas chown ruda:ruda fzu   gives permission denied
> 
> What can I do?
> 
> Thanks
> Ruda
> 

Hi,

I have the same issue here.

chmod 777 changes the permisions, but seems to reset them automatically after a
second or so.

The umask  suggestion doesn't work either unfortunately.

On 6.3 this problem doesn't occur, but on -current it does. I'll try to bisect
it later.

-- 
Kind regards,
Hiltjo



Re: OT: Temperature sensors suggestions?

2018-05-19 Thread Hiltjo Posthuma
On Fri, May 18, 2018 at 04:42:01PM -0400, Daniel Ouellet wrote:
> Does anyone have a decent temperature sensors that can connect to an
> OpenBSD server and be reliable and give any decent reading via either
> USB or Serial port or even stand alone via Ethernet?
> 
> I asked because yes I can use the sensors on some servers, but I got a
> pretty expensive router blowing up because an AC unit stop working and
> in a few hours the router was history and I need something reliable so I
> can graph the changes in temperature to keep track of things.
> 
> I got lucky this time as that using was providing 192 VoIP channels and
> I had just moved them from PRI to full SIP like a month earlier. If I
> haven't done that it would have been a disaster for me!
> 
> So, I need more then just servers sensors so I can place these at
> various location to get a better idea of what's going on.
> 
> I don't understand why it is so difficult to have decent AC technician
> keep AC units working properly. It's not like brain surgery, but that's
> always a problem.
> 
> Anything you know or use that is reliable that you can recommend would
> be very much appreciated.
> 
> I am trying to keep it simple, so using base tools in OpenBSD is a must,
> no proprietary shit or Windows crap like I found tonnes of them. I have
> NO Windows systems for 20+ years already and I am sure hell not going to
> install any either. I try to keep it simple. Even snmp reading is find.
> Simpler the better. I can grab the reading and save to a database to
> graph later and what not. I got two self standing units in the pass,
> nice but they get hacked and not useful obviously, so add-on to OpenBSD
> is better to me. I trust that way more then all the self standing units,
> records proving it...
> 
> If that's no interest for the list fell free to reply off line as well,
> but I guess some might like to know too.
> 
> Thanks in advance for any suggestions...
> 
> Daniel
> 

I use PCsensors TEMPer-based USB device and the ugold(4) driver.
It works well.

-- 
Kind regards,
Hiltjo



Re: Missing relayd.conf(5) example

2018-04-21 Thread Hiltjo Posthuma
On Fri, Apr 20, 2018 at 02:55:04PM -0700, Aaron Miller wrote:
> Hi all,
> 
> I was able to setup relayd(8) with URL-based redirection to either a
> local application server or to httpd(8), both listening on lo0; relayd
> also terminates TLS. However, the man pages were not very helpful and I
> ended up resorting to stackoverflow and trial and error.
> 
> I recommend an example like this be added to relayd.conf(5) man page:
> 
>   table { 127.0.0.1 }
>   table  { 127.0.0.1 }
> 
>   http protocol "https" {
> match header set "X-Forwarded-For" \
>   value "$REMOTE_ADDR" 
> match header set "X-Forwarded-By" \
>   value "$SERVER_ADDR:$SERVER_PORT" 
> match header set "Keep-Alive" value "$TIMEOUT" 
> 
> pass request quick path "/api/*" forward to 
> pass request quick forward to 
> block
>   }
> 
>   relay "main" {
> protocol "https"
> listen on 0.0.0.0 port 443 tls
> forward to  port 3000
> forward to  port 4443
>   }
> 
> I think that would be helpful for others who want to do what I did...
> any thoughts?
> 
> --Aaron
> 

Hi,

I think this example is a common use-case and probably helpful.

I don't mean to hijack the thread, but have you been able to forward the
HTTP request and modifying the path? I've researched the code, but I don't
think it's possible at the moment.

Locally I have a patch which changes the matching logic to the httpd Lua
pattern matching. This has some side-effects and complicates the code though,
so is probably not suitable for upstream.

One of the reasons I don't use relayd (yet) is because I'd like to reverse
proxy HTTP traffic but strip the path, for example:

somedomain.org/someservice to 127.0.0.1:8080/ (stripping "someservice").

Do you perhaps have a solution or idea to do this?

-- 
Kind regards,
Hiltjo



Re: go get abort trap?

2018-03-07 Thread Hiltjo Posthuma
On Wed, Mar 07, 2018 at 01:46:43PM -0800, jungle Boogie wrote:
> Hi All,
> 
> With the latest openbsd snapshot:
> OpenBSD 6.3-beta (GENERIC.MP) #40: Wed Mar  7 12:51:00 MST 201
> 
> It seems I cannot build or update go projects:
> 
> $ go get -u github.com/justwatchcom/gopass
> Abort trap (core dumped)
> 
> dmesg shows:
> trap pid 74737 tid 99500 type 6: sp c420024750 not inside
> 7f7fffbef000-7f7ee000
> 
> A week or two ago, I was able to update this project without any issues.
> I can't run 'go' without the abort trap.
> 
> Anyone else running openbsd snapshots experiencing this?
> 
> Thanks!
> 
> -- 
> ---
> inum: 883510009027723
> sip: jungleboo...@sip2sip.info
> 

Hey,

This is probably related to the new stack-register changes.

See the mail with the subject "stack-register checking" on tech@ on 6 March.

I hope this helps,

-- 
Kind regards,
Hiltjo



Re: van Sprundel

2018-01-28 Thread Hiltjo Posthuma
On Sun, Jan 28, 2018 at 12:56:26PM +, Andy Lemin wrote:
> Really, did he actually post any real vulnerabilities to OpenBSD!
> 
> This article has to be govt propaganda..
> 
> https://www.csoonline.com/article/3250653/open-source-tools/is-the-bsd-os-dying-some-security-researchers-think-so.amp.html
> 
> I was laughing with tears when I read this..
> 
> OpenBSD is the only OS I place any real trust in <3
> 
> Is probably the only OS they can’t hack.
> 
> And SystemD makes me want to both cry and scream at the same time.
> 
> A
> 
> 
> Sent from a teeny tiny keyboard, so please excuse typos

Hey,

Maybe I shouldn't reply, but I feel this is insulting to the amazing work of
Van Sprundel. I've also seen better nuanced articles about the same
presentation talk.

Sources:
- https://www.openbsd.org/errata60.html (the batch of patches on August 3 2017).
- http://undeadly.org/cgi?action=article=20170804053102
- Slides: 
https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Ilja-van-Sprundel-BSD-Kern-Vulns.pdf
- https://www.openbsd.org/errata56.html (earlier work).

Please do more research before you post.

-- 
Kind regards,
Hiltjo



Re: gzip compression and httpd/relayd

2018-01-28 Thread Hiltjo Posthuma
On Sun, Jan 28, 2018 at 10:18:30AM +0100, Thuban wrote:
>  
> > Yes it's possible. Make sure to set the appriopriate HTTP headers aswell
> > with relayd: read "Accept-Encoding" and if it's acceptable set
> > "Content-Encoding".
> 
> Indeed, it works.
> 
> relayd.conf : 
> 
>   match response header "Accept-Encoding" value "gzip"

This should be: match request header "Accept-Encoding" value "*gzip*" I think.
It should only output gzip if it's an accepted encoding, else some clients
break.

> match response header set "Content-Encoding" value "gzip"
> 
> Then : 
> 
>   cd /var/www/htdocs/site
>   gzip style.css && mv style.css.gz style.css
> 
> Now, open URL pointing to style.css, and here you go.
> 
> However, all your files must be gzipped, or the browser is unhappy.
> 
> Thanks a lot.
> 

You're welcome :)

-- 
Kind regards,
Hiltjo



Re: gzip compression and httpd/relayd

2018-01-26 Thread Hiltjo Posthuma
On Thu, Jan 25, 2018 at 09:37:06PM +0100, Michael Hekeler wrote:
> Am Thu, 25 Jan 2018 19:47:09 +0100
> schrieb Thuban :
> 
> > I'm very happy with relayd + httpd.
> > Relayd deals with headers and httpd serve files.
> > 
> > I know httpd doesn't have gzip compression.
> > 
> > 1. Do you know if it's planned in the future?
> > 2. Does anyone has a workaround to advise?
> > 
> > regards
> > 
> 
> to 1.
> https://marc.info/?l=openbsd-misc=142407262812306=2
> 
> 

Hi,

In some servers there were some security issues with compression like:
https://en.wikipedia.org/wiki/BREACH

I don't know if thats the reason httpd doesn't have it though.

> to 2.
> I never tested it myself, but ,maybe you can compress the files before
> you place them in htdocs!?
> 

Yes it's possible. Make sure to set the appriopriate HTTP headers aswell
with relayd: read "Accept-Encoding" and if it's acceptable set
"Content-Encoding".

> ...or use ngingx reverse-proxy?
> 

-- 
Kind regards,
Hiltjo



Re: softraid crypto seem really slower than plain ffs

2017-09-15 Thread Hiltjo Posthuma
On Fri, Sep 15, 2017 at 12:24:32PM +0200, Joel Carnat wrote:
> Hi,
> 
> Initially comparing I/O speed between FreeBSD/ZFS/GELI and
> OpenBSD/FFS/CRYPTO, I noticed that there were a huge difference between
> plain and encrypted filesystem using OpenBSD. I ran the test on a 1
> vCore/1GB RAM Vultr VPS, running OpenBSD 6.2-beta. I had / configured in
> plain FFS and /home encrypted using bioctl(8). Then I ran a few `dd` and
> `bonnie++`
> 
> According to those tests, writing FFS/CRYPTO is about 10 times slower than
> FFS/PLAIN.
> For the record, using the same `dd` on FreeBSD, ZFS with GELI is only 2
> times slower than plain ZFS.
> Furthemore, comparing FreeBSD/ZFS/PLAIN and OpenBSD/FFS/PLAIN, the speed is
> about the same.
> Finally, it seems reading OpenBSD/FFS/PLAIN and OpenBSD/FFS/CRYPTO is done
> at the same speed.
> 
> Is this expected to have so much difference between FFS/PLAIN and FFS/CRYPTO
> when writing data?
> 
> TIA,
>   Jo
> 
> PS: here's my test data.
> 
> # sysctl kern.version hw.machine hw.model hw.ncpu hw.physmem
> kern.version=OpenBSD 6.2-beta (GENERIC) #91: Wed Sep 13 22:05:17 MDT 2017
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> 
> hw.machine=amd64
> hw.model=Virtual CPU a7769a6388d5
> hw.ncpu=1
> hw.physmem=1056817152
> 
> # disklabel sd0
> # /dev/rsd0c:
> type: SCSI
> disk: SCSI disk
> label: Block Device
> duid: 69939b6a66c3879a
> flags:
> bytes/sector: 512
> sectors/track: 63
> tracks/cylinder: 255
> sectors/cylinder: 16065
> cylinders: 3263
> total sectors: 52428800
> boundstart: 64
> boundend: 52420095
> drivedata: 0
> 
> 16 partitions:
> #size   offset  fstype [fsize bsize   cpg]
>   a: 16739680 35680384  4.2BSD   2048 16384 12958 # /
>   b:  4208966   64swap# none
>   c: 524288000  unused
>   d: 31471335  4209030RAID
> 
> # disklabel sd1
> # /dev/rsd1c:
> type: SCSI
> disk: SCSI disk
> label: SR CRYPTO
> duid: 4179a9e67beb3d4e
> flags:
> bytes/sector: 512
> sectors/track: 63
> tracks/cylinder: 255
> sectors/cylinder: 16065
> cylinders: 1958
> total sectors: 31470807
> boundstart: 64
> boundend: 31455270
> drivedata: 0
> 
> 16 partitions:
> #size   offset  fstype [fsize bsize   cpg]
>   c: 314708070  unused
>   e:   273024   64  4.2BSD   2048 16384  2133 # /etc
>   h: 31182176   273088  4.2BSD   2048 16384 12958 # /home
> 
> # mount
> /dev/sd0a on / type ffs (local, wxallowed)
> /dev/sd1e on /etc type ffs (local, softdep)
> /dev/sd1h on /home type ffs (local, nodev, nosuid)
> 
> # df -h
> Filesystem SizeUsed   Avail Capacity  Mounted on
> /dev/sd0a  7.9G915M6.6G12%/
> /dev/sd1e  131M4.9M120M 4%/etc
> /dev/sd1h 14.6G2.0K   13.9G 0%/home
> 
> # sync && time dd if=/dev/zero of=/TEST bs=512 count=300 && sync
> 300+0 records in
> 300+0 records out
> 153600 bytes transferred in 8.567 secs (179278802 bytes/sec)
> 0m08.61s real 0m00.29s user 0m07.70s system
> 
> # sync && time dd if=/dev/zero of=/home/TEST bs=512 count=300 && sync
> 300+0 records in
> 300+0 records out
> 153600 bytes transferred in 20.875 secs (73580525 bytes/sec)
> 0m20.88s real 0m00.42s user 0m05.54s system
> 
> # sync && time dd if=/dev/zero of=/TEST bs=4k count=30 && sync
> 30+0 records in
> 30+0 records out
> 122880 bytes transferred in 4.151 secs (296024071 bytes/sec)
> 0m04.19s real 0m00.04s user 0m04.01s system
> 
> # sync && time dd if=/dev/zero of=/home/TEST bs=4k count=30 && sync
> 30+0 records in
> 30+0 records out
> 122880 bytes transferred in 22.872 secs (53723676 bytes/sec)
> 0m22.95s real 0m00.06s user 0m01.89s system
> 

NOTE: a block size is 1024 bytes, so the counts are incorrect in the conversion.

the count should be 375000: 4096/512=8, 30/8=375000.

my write numbers are:
run 1

+ dd if=/dev/zero of=/home/TEST bs=512 count=240
240+0 records in
240+0 records out
122880 bytes transferred in 8.616 secs (142611817 bytes/sec)
0m09.33s real 0m00.20s user 0m09.05s system

+ dd if=/dev/zero of=/home/TEST bs=4k count=30
30+0 records in
30+0 records out
122880 bytes transferred in 5.591 secs (219749191 bytes/sec)
0m05.59s real 0m00.02s user 0m05.46s system

4k, 8k, 16k, 32k and 64k are comparable on my machine.


run 2

+ dd if=/dev/zero of=/home/TEST bs=512 count=240
240+0 records in
240+0 records out
122880 bytes transferred in 8.748 secs (140451506 bytes/sec)
0m09.24s real 0m00.26s user 0m08.87s system

+ dd if=/dev/zero of=/home/TEST bs=4k count=30
30+0 records in
30+0 records out
122880 bytes transferred in 5.140 secs (239049708 bytes/sec)
0m05.87s real 0m00.03s user 0m05.74s 

Re: OpenBSD 6.1 current relayd TLS error "cannot load certificates"

2017-06-03 Thread Hiltjo Posthuma
On Fri, Jun 02, 2017 at 08:38:50PM -0700, Dillon Jay Pena wrote:
> I'm not understanding why I'm getting a relayd error. Thanks in advance.
> 
> According to 
> http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/relayd.conf.5#listen_on,
> I just need address.crt and private/address.key to use tls with
> relayd, which you can see I do below.
> So why am I getting the relayd error "cannot load certificates for relay www"?
> 
> I have included how I got the key and crt files from acme-client/lets
> encrypt in case it's relevant.
> 
> 
> $ uname -prsv
> OpenBSD 6.1 GENERIC#88 amd64
> 
> $ cat /etc/acme-client.conf
> #
> # $OpenBSD: acme-client.conf,v 1.4 2017/03/22 11:14:14 benno Exp $
> #
> authority letsencrypt {
> agreement url
> "https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf;
> api url "https://acme-v01.api.letsencrypt.org/directory;
> account key "/etc/acme/letsencrypt-privkey.pem"
> }
> 
> authority letsencrypt-staging {
> agreement url
> "https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf;
> api url "https://acme-staging.api.letsencrypt.org/directory;
> account key "/etc/acme/letsencrypt-staging-privkey.pem"
> }
> 
> domain thelang.space {
> alternative names { mail.thelang.space www.thelang.space }
> domain key "/etc/ssl/private/thelang.space.key"
> domain certificate "/etc/ssl/thelang.space.crt"
> domain full chain certificate "/etc/ssl/thelang.space.fullchain.pem"
> sign with letsencrypt
> challengedir "/var/www/htdocs/.well-known/acme-challenge"
> }
> 
> $ doas acme-client -vAD thelang.space
> acme-client: /etc/ssl/private/thelang.space.key: domain key exists
> (not creating)
> acme-client: /etc/acme/letsencrypt-privkey.pem: account key exists
> (not creating)
> acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
> acme-client: acme-v01.api.letsencrypt.org: DNS: 104.68.109.156
> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz:
> req-auth: thelang.space
> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz:
> req-auth: mail.thelang.space
> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz:
> req-auth: www.thelang.space
> acme-client: 
> /var/www/htdocs/.well-known/acme-challenge/hALHIbtLAX4k274bN4AFBV0W-T08pKTqD6lBw0-CplM:
> created
> acme-client: 
> https://acme-v01.api.letsencrypt.org/acme/challenge/mempVpv498Gw4d7Wr24qcinn5ZUfX_6IO2kQOeskf40/1271082083:
> challenge
> acme-client: 
> /var/www/htdocs/.well-known/acme-challenge/SMwY0p1ma9ZDQrlyM6h9BbZkEnMCKx2lW69__zcmCgI:
> created
> acme-client: 
> https://acme-v01.api.letsencrypt.org/acme/challenge/bwNrTgnJmUIH-XqInRMDmRNgRMnXQKBUZngPi3wuHt4/1271082087:
> challenge
> acme-client: 
> /var/www/htdocs/.well-known/acme-challenge/wu3Zhef8NA8b9wmxHeMjXBZCg3EKGHgnM30Tx_qn1Ws:
> created
> acme-client: 
> https://acme-v01.api.letsencrypt.org/acme/challenge/fHeHrAzF9RAXO-eJMZxfWElhkf4duUw934pUWy2gWyM/1271082092:
> challenge
> acme-client: 
> https://acme-v01.api.letsencrypt.org/acme/challenge/mempVpv498Gw4d7Wr24qcinn5ZUfX_6IO2kQOeskf40/1271082083:
> status
> acme-client: 
> https://acme-v01.api.letsencrypt.org/acme/challenge/bwNrTgnJmUIH-XqInRMDmRNgRMnXQKBUZngPi3wuHt4/1271082087:
> status
> acme-client: 
> https://acme-v01.api.letsencrypt.org/acme/challenge/fHeHrAzF9RAXO-eJMZxfWElhkf4duUw934pUWy2gWyM/1271082092:
> status
> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-cert: certificate
> acme-client: http://cert.int-x3.letsencrypt.org/: full chain
> acme-client: cert.int-x3.letsencrypt.org: DNS: 165.254.42.42
> acme-client: /etc/ssl/thelang.space.crt: created
> acme-client: /etc/ssl/thelang.space.fullchain.pem: created
> 
> $ cat /etc/relayd.conf
> table  { 127.0.0.1 }
> 
> relay www {
>   listen on thelang.space port 443 tls
> 
>   forward to  check tcp port 8080
> }
> 
> $ doas relayd -d
> startup
> /etc/relayd.conf:7: cannot load certificates for relay www
> no actions, nothing to do
> hce exiting, pid 2324
> pfe exiting, pid 21204
> ca exiting, pid 18722
> ca exiting, pid 45718
> ca exiting, pid 79639
> relay exiting, pid 31292
> relay exiting, pid 32940
> relay exiting, pid 75225
> 
> $ ls /etc/ssl/thelang.space.crt
> /etc/ssl/thelang.space.crt
> $ doas ls /etc/ssl/private/thelang.space.key
> /etc/ssl/private/thelang.space.key
> 
> - Dillon
> 

Hey,

ktrace is also useful help here.

# ktrace relayd -d -v
# kdump ...

I've had a similar thing to debug listening on IPV6 interface(s).

Hope this helps you,

-- 
Kind regards,
Hiltjo



Re: How to syspatch from a different server?

2017-05-15 Thread Hiltjo Posthuma
On Mon, May 15, 2017 at 09:05:38AM +0200, Federico Giannici wrote:
> We use an internal server to speedup the upgrade of OS and packages of all
> our internal machines (all amd64). We simply set /etc/installurl in every
> machine to point to our server were there are the OS tarballs and packages.
> 
> Anyway we'd like to use the standard OpenBSD servers for syspatch as it uses
> much less files than complete installation and it's often updated.
> 
> How can we do it?
> Is there a way to tell syspatch to use another source instead of the one in
> /etc/installurl? If no, what about a new option in syspatch?
> 
> Thanks.
> 

Can't you just sync the patches to your internal server? Then syspatch
should work.

-- 
Kind regards,
Hiltjo



Re: OpenBSD 6.1: relayd does not start more than 3 processes

2017-05-05 Thread Hiltjo Posthuma
On Fri, May 05, 2017 at 04:33:02PM +0200, Florian Ermisch wrote:
> 
> 
> Am 5. Mai 2017 16:05:09 MESZ schrieb Maxim Bourmistrov 
> <m...@alumni.chalmers.se>:
> >
> >> 5 maj 2017 kl. 15:55 skrev Maxim Bourmistrov
> ><m...@alumni.chalmers.se>:
> >> 
> >> 
> >>> 5 maj 2017 kl. 14:41 skrev Hiltjo Posthuma <hil...@codemadness.org>:
> >>> 
> >>> On Fri, May 05, 2017 at 12:30:56PM +0200, Maxim Bourmistrov wrote:
> >>>> […] 
> >>>> Changing ’prefork’ from 15 to 3 makes it work.
> >>>> 
> >>>> Is this a bug?
> >>>> 
> >>>> Br
> >>> 
> >>> Hey,
> >>> 
> >>> This is a random guess since you haven't posted the whole config,
> >>> but I think
> >>> it has bitten me too sometime:
> >>> 
> >>> Do you have the global options such as prefork defined before your
> >>> relays and routes or not?
> >>> 
> >>> The order of the global options matter. If the global options are
> >>> set after
> >>> the table they are not initialized on the tables and can actually
> >>> crash relayd.
> >>> This is because the health checking uses a different prefork value
> >and checks
> >>> the "wrong" amount.
> >>> 
> >>> I'm not sure, but I think it is not a bug: it is documented in
> >>> relayd.conf(5).
> >>> 
> >>> Thinking about it: would it be acceptable if `relayd -n` shows a
> >>> warning if
> >>> global options are defined in the wrong order? I can write the patch
> >>> for it
> >>> if it makes sense.
> >>> 
> >>> I hope this helps you in some way,
> >>> 
> >>> -- 
> >>> Kind regards,
> >>> Hiltjo
> >> 
> >> The whole config is like this:
> >> 
> >> […]
> >> 
> >> Note, config layout exactly the same which runs already on
> >6.0-stable.
> >> 
> >> My original question is why I can’t fork more than 3 procs any more
> >> and why relayd starts then prefork > 3
> >> and does not do a health check.
> >> 
> >> Br
> >
> >Hm, I tried this out - re-ordering the layout of the config.
> >You are, indeed, correct here.
> >
> >Strange that this runs on 6.0.
> >
> >Case closed.
> >Sorry for the noise.
> >
> >Br
> 
> I would still say it's worth the patch
> Hiltjo offered to write. Or At least have
> the warning printed when testing the
> config with `-v -n`.
> 
> Regards, Florian
> 

An idea:

Maybe in parse.y in the main rule it can be checked something like this:

if (last_table_id || last_host_id || last_relay_id ||
last_proto_id || last_rt_id || last_nr_id ||
last_key_id) {
yyerror("global option used after non-global option");
YYERROR;
}

Sorry, I'm not a yacc guru :)

-- 
Kind regards,
Hiltjo



Re: OpenBSD 6.1: relayd does not start more than 3 processes

2017-05-05 Thread Hiltjo Posthuma
On Fri, May 05, 2017 at 12:30:56PM +0200, Maxim Bourmistrov wrote:
> 
> Hey,
> on OpenBSD 6.0-stable I have following configuration for relayd:
> 
> snip———
> interval 10
> timeout 1200
> prefork 15
> log all
> ——
>  
> Respective login.conf to spawn more relayd procs:
> 
> relayd:\
> :maxproc-max=31:\
> :maxproc-cur=15:\
> :openfiles=65536:\
> :tc=daemon:
> 
> 
> With config options above moved to a 6.1 creates following:
> 
> relayd starts but brings up no more that 3 relay-processes.
> Also after start up it refuses to do any checks configured (in my simple test 
> I used check tcp) 
> 
> [mxb-test]-[12:21:41]# relayctl sh su
> Id  TypeNameAvlblty Status
> 1   relay   rabbitmqactive
> 1   table   rabbitmqpool:5672   empty
> 1   host10.5.96.8   unknown
> 2   table   rabbitmqfallback:5672   empty
> 2   host10.5.96.9   unknown
> 
> 
> Changing ’prefork’ from 15 to 3 makes it work.
> 
> Is this a bug?
> 
> Br
> 
> 
> 

Hey,

This is a random guess since you haven't posted the whole config, but I think
it has bitten me too sometime:

Do you have the global options such as prefork defined before your
relays and routes or not?

The order of the global options matter. If the global options are set after
the table they are not initialized on the tables and can actually crash relayd.
This is because the health checking uses a different prefork value and checks
the "wrong" amount.

I'm not sure, but I think it is not a bug: it is documented in relayd.conf(5).

Thinking about it: would it be acceptable if `relayd -n` shows a warning if
global options are defined in the wrong order? I can write the patch for it
if it makes sense.

I hope this helps you in some way,

-- 
Kind regards,
Hiltjo



Re: relayd splice timeout

2017-04-28 Thread Hiltjo Posthuma
On Thu, Apr 27, 2017 at 07:11:56PM +0200, Markus Rosjat wrote:
> Hi there,
> 
> I was playing arround wit relayd just to get a feeling for it. So I started
> with relaying a ssh connection to a machine behind my gateway.
> 
> But it seems there is some kind of config value I miss because after like  8
> minutes the open ssh connection gets suddenly closed. Running relayd in
> foreground shows a splice timeout.
> 
> So question is, can I and if so where can I adjust the timeout value.
> 
> SSH might be a bad example for relayd use but its the easiest starting point
> thought. Better to discover stuff befor a setup gets more complicated.
> 
> Regards
> 
> -- 
> Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de
> 
> G+H Webservice GbR Gorzolla, Herrmann
> Königsbrücker Str. 70, 01099 Dresden
> 
> http://www.ghweb.de
> fon: +49 351 8107220   fax: +49 351 8107227
> 
> Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you
> print it, think about your responsibility and commitment to the ENVIRONMENT
> 

Hey,

Have you tried "session timeout"?

They can be used for relays and redirections.

See the RELAYS and REDIRECTIONS section in relayd.conf(5).

-- 
Kind regards,
Hiltjo



Re: [relayd] keep origin IP in logs

2017-04-09 Thread Hiltjo Posthuma
On Sun, Apr 09, 2017 at 11:30:37AM +, Stuart Henderson wrote:
> On 2017-04-09, Thuban <thu...@yeuxdelibad.net> wrote:
> > * Hiltjo Posthuma <hil...@codemadness.org> le [09-04-2017 11:42:23 +0200]:
> >> On Sat, Apr 08, 2017 at 08:48:43PM +0200, Thuban wrote:
> >> > Hello,
> >> > I use relayd to deal with HTTP headers as suggested here [1].
> >> > My problem is that in httpd logs, the origin IP is 127.0.0.1 and thats
> >> > not very handy to track bruteforce attacks (in example).
> >> > 
> >> > Do you have any advice to keep the visitor IP in logs ?
> >> > 
> >> > [1] : 
> >> > https://github.com/reyk/httpd/wiki/Using-relayd-to-add-Cache-Control-headers-to-httpd-traffic
> >> > -- 
> >> > :thuban:
> >> > 
> >> 
> >> It's commonly done by adding a X-Forwarded-For header with the origin IP.
> >> 
> >> From the relayd.conf(5) man page:
> >> 
> >>http protocol "https" {
> >>match header append "X-Forwarded-For" \
> >>value "$REMOTE_ADDR"
> >>match header append "X-Forwarded-By" \
> >>value "$SERVER_ADDR:$SERVER_PORT"
> 
> "append" isn't good here, you don't want to trust whatever the client
> sends in headers.
> 

Good point! I've send a relayd.conf(5) patch for this to tech@.

-- 
Kind regards,
Hiltjo



Re: [relayd] keep origin IP in logs

2017-04-09 Thread Hiltjo Posthuma
On Sun, Apr 09, 2017 at 11:51:25AM +0200, Thuban wrote:
> * Hiltjo Posthuma <hil...@codemadness.org> le [09-04-2017 11:42:23 +0200]:
> > On Sat, Apr 08, 2017 at 08:48:43PM +0200, Thuban wrote:
> > > Hello,
> > > I use relayd to deal with HTTP headers as suggested here [1].
> > > My problem is that in httpd logs, the origin IP is 127.0.0.1 and thats
> > > not very handy to track bruteforce attacks (in example).
> > > 
> > > Do you have any advice to keep the visitor IP in logs ?
> > > 
> > > [1] : 
> > > https://github.com/reyk/httpd/wiki/Using-relayd-to-add-Cache-Control-headers-to-httpd-traffic
> > > -- 
> > > :thuban:
> > > 
> > 
> > Hey,
> > 
> > It's commonly done by adding a X-Forwarded-For header with the origin IP.
> > 
> > From the relayd.conf(5) man page:
> > 
> >http protocol "https" {
> >match header append "X-Forwarded-For" \
> >value "$REMOTE_ADDR"
> >match header append "X-Forwarded-By" \
> >value "$SERVER_ADDR:$SERVER_PORT"
> > 
> >... snip snip ...
> >}
> > 
> 
> That's exactly what I use, but it doesn't seems to work : 
> 
>   # snip from httpd logs
>   test.yeuxdelibad.net 127.0.0.1 - - [09/Apr/2017:11:47:54 +0200] "GET / 
> HTTP/1.0" 200 0
> 

Hey,

In my example you should also log the "X-Forwarded-For" header in relayd or
your httpd. The source IP and headers were modified (non-transparant).

relayd can log headers (and other data) using for example:

match header log "User-Agent"

Additionally it can be useful to edit /etc/syslog.conf to log this to a
separate file like /var/log/relayd.

-- 
Kind regards,
Hiltjo



Re: [relayd] keep origin IP in logs

2017-04-09 Thread Hiltjo Posthuma
On Sat, Apr 08, 2017 at 08:48:43PM +0200, Thuban wrote:
> Hello,
> I use relayd to deal with HTTP headers as suggested here [1].
> My problem is that in httpd logs, the origin IP is 127.0.0.1 and thats
> not very handy to track bruteforce attacks (in example).
> 
> Do you have any advice to keep the visitor IP in logs ?
> 
> [1] : 
> https://github.com/reyk/httpd/wiki/Using-relayd-to-add-Cache-Control-headers-to-httpd-traffic
> -- 
> :thuban:
> 

Hey,

It's commonly done by adding a X-Forwarded-For header with the origin IP.

>From the relayd.conf(5) man page:

   http protocol "https" {
   match header append "X-Forwarded-For" \
   value "$REMOTE_ADDR"
   match header append "X-Forwarded-By" \
   value "$SERVER_ADDR:$SERVER_PORT"

   ... snip snip ...
   }


I hope this helps you,

-- 
Kind regards,
Hiltjo



Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

2017-03-28 Thread Hiltjo Posthuma
On Tue, Mar 28, 2017 at 02:39:44PM +0200, Mathieu BLANC wrote:
> On Tue, Mar 28, 2017 at 02:22:28PM +0200, Mathieu BLANC wrote:
> > I can reproduce the bug (on the slave firewall) as many times as I want.
> > 
> 
> I've just read https://www.openbsd.org/ddb.html and saw that you need a trace
> for all cpu.
> 
> http://www.hostingpics.net/viewer.php?id=238876panic9.jpg
> http://www.hostingpics.net/viewer.php?id=275943panic10.jpg
> http://www.hostingpics.net/viewer.php?id=375143panic11.jpg
> http://www.hostingpics.net/viewer.php?id=220012panic12.jpg
> 
> (it's a different crash from the last screenshots i've made, if it's not good 
> i
> can provide a full new set of pics)
> 
> -- 
> Mathieu
> 

Hey,

Can you also provide your pf.conf ?

Can you test if it also happens on -current?

-- 
Kind regards,
Hiltjo



Re: Openup and stable

2017-03-25 Thread Hiltjo Posthuma
On Sat, Mar 25, 2017 at 08:49:22AM +, Andreas Thulin wrote:
> Hi all!
> 

Hey!,

> I'm running 6.0 -stable using openup for patching. I think it works very
> well since it's so convenient. At the same time I realise there are trust
> and security concerns with people like myself, who "blindly" install
> patches without understanding the details. I suppose my problem is that I'm
> not a developer and cannot make a fair assessment just by reading code, so
> neither patch method would be secure for me. I'm the risk, so to speak.
> 

I'm not familiar with openup, but the official patches are always described
at: https://www.openbsd.org/errata60.html (for 6.0). The official patches are
cryptographically signed.

> Anyway, to my question(s): Is openup considered good or bad practise, and
> for what reasons, as you see them? Has there ever been plans among OpenBSD
> developers to make following -stable easier for "users" such as myself?
> 
> I failed to find enough info about this topic in the archives, but please
> point me in the right direction if you happen to know about applicable
> threads.
> 

OpenBSD 6.1 will have the (new) syspatch(8) tool for base system binary
patches: http://man.openbsd.org/syspatch.8 .

> Humbly,
> Andreas
> 

-- 
Kind regards,
Hiltjo



Re: OpenBSD 5.9/amd64 (2-Jun-2016), httpd(40862): [syscall 5 "wpath"] error when attempting to start httpd with ssl

2016-06-13 Thread Hiltjo Posthuma
On Thu, Jun 09, 2016 at 01:19:50PM -0500, Troy Frericks wrote:
> ...
> 
> I've spent hours googeling, and found only one mention that this may be a
> kernel bug.
> I've checked theOpenBSD 5.9 patch list, the OpenBSD 5.9 -current changes
> log.
> 

By the way, instead of googeling a nice way to see what is going on is to run:

ktrace httpd -d -v

then run

kdump -f ktrace.out

after it aborts to see what exactly triggered the abort.

Hope this helps,

-- 
Kind regards,
Hiltjo



Re: Deadlink in current.html

2016-05-08 Thread Hiltjo Posthuma
On Sun, May 08, 2016 at 11:28:33AM +0200, Heiko wrote:
> Hello Team,
> 
> there is a deadlink in current.html @ 2016/05/07 - MAJOR ABI BREAK
> 
> "Not Found
> The requested URL /faq/r20160319 was not found on this server."
> 

Nice find, I think it was intended to link to the item on the same page on
http://www.openbsd.org/faq/current.html :

To fix change the HTML code from:

2016/03/19 csu and ld.so update

to (added #):

2016/03/19 csu and ld.so update

--
Kind regards,
Hiltjo



Re: relayd as a reverse-proxy in front of OpenBSD httpd + custom Golang httpd

2015-10-27 Thread Hiltjo Posthuma
On Sun, Oct 25, 2015 at 7:30 PM, Hiltjo Posthuma <hil...@codemadness.org>
wrote:
> My /etc/relayd.conf looked something like this:
>
> table  { 127.0.0.1 }
>
> http protocol "protmyapp" {
> return error
>
> # TODO: forward non-matching traffic to standard httpd.
> match request header "Host" value "someapp.mydomain.*"
> }
>
> relay "myapp" {
> listen on 0.0.0.0 port 80
> protocol "protmyapp"
> forward to  port 8081
> }
>

I figured it out, I overlooked in relayd.conf(5) FILTER RULES:

"forward to ⟨table⟩ Forward the request to a server in the specified
table. With this option, requests can be passed to specific backend
servers. -> A corresponding forward to declaration in the RELAYS
section is required. <-".

In case someone wants to do a similar thing the working relayd.conf is
(simplified):

table  { 127.0.0.1 }
table  { 127.0.0.1 }

http protocol "protsomeapp" {
match request quick header "Host" value "someapp.mydomain.*" \
forward to 
}

relay "someapp" {
listen on 0.0.0.0 port 80
protocol "protsomeapp"

forward to  port 8080
forward to  port 8081
}

Kind regards / hope this helps someone,
Hiltjo



relayd as a reverse-proxy in front of OpenBSD httpd + custom Golang httpd

2015-10-25 Thread Hiltjo Posthuma
Hi folks!,

I have a question about how to convert my current setup with nginx +
fastcgi to OpenBSD httpd + slowcgi and relayd.

The setup is pretty simple, I have the follow subdomains:

www.mydomain.org - OpenBSD httpd, static pages.
git.mydomain.org - OpenBSD httpd, slowcgi and cgit.
someapp.mydomain.org - custom httpd application (written in Golang),
listens on a UNIX domain socket or localhost port.

I have www and git successfully working with OpenBSD httpd, cgit and
git-daemon, it works very well and was simple to setup.

Now I want to also relay someapp.mydomain.org to the local Golang
httpd, the other HTTP traffic can go to the OpenBSD httpd, this is all
running on the same server. With nginx this was possible by using
nginx "proxy_pass"[0], like:

server {
listen 80;
server_name someapp.mydomain.org;

location / {
proxy_pass
"http://unix:/domains/someapp.mydomain.org/someapp.sock:/;;
}
}

server {
listen 80;
server_name www.mydomain.org;
root /var/www/domains/www.mydomain.org/htdocs;
}

I've tried to put relayd (port 80) as a reverse-proxy in front of
httpd and relay based on the HTTP "Host" header. It seems to me from
reading the documentation
that relayd can relay to one host or table per protocol, but not relay
to different ports on the same machine, but hopefully I'm totally
wrong.

My /etc/relayd.conf looked something like this:

table  { 127.0.0.1 }

http protocol "protmyapp" {
return error

# TODO: forward non-matching traffic to standard httpd.
match request header "Host" value "someapp.mydomain.*"
}

relay "myapp" {
listen on 0.0.0.0 port 80
protocol "protmyapp"
forward to  port 8081
}

Does anyone have a similar setup and can help me with this?

Kind regards,
Hiltjo

[0] - http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass