cwm window in all/no groups

2019-12-28 Thread Chris Cappuccio
I'm using windows groups with sticky.

unbind-key  all

bind-keyM-1   group-only-1
bind-keyM-2   group-only-2
...
sticky yes

Usually I can keep all my windows in whatever group they were opened in. On
occasion, I must be typing in some strange key combination and I end up
getting some or all of the windows on my current screen bound to no group.

I don't have any keys bound to 'window-stick' which seems like it would
do exactly this. I don't have any keys bound to group-only-0. When windows
start going into all/nogroup mode, it becomes very frustrating. I can't focus
into a nogroup xterm for typing unless I kill or move any windows which are
members of the current group. I can't move the nogroup windows either. I
can't close them using the meta key delete. These nogroup windows have
some very annoying properties, appropriate for xconsole perhaps.

Does this sound familiar to anyone? 

.cwmrc:

unbind-key  all

bind-keyM-1   group-only-1
bind-keyM-2   group-only-2
bind-keyM-3   group-only-3
bind-keyM-4   group-only-4
bind-keyM-5   group-only-5
bind-keyM-6   group-only-6
bind-keyM-7   group-only-7
bind-keyM-8   group-only-8
bind-keyM-9   group-only-9
bind-keyCM-q   window-delete
bind-keyCM-r   restart
bind-keyM-equal"mixerctl outputs.master=+10"
bind-keyM-jwindow-cycle-ingroup
bind-keyM-kwindow-rcycle-ingroup
bind-keyM-minus"mixerctl outputs.master=-10"
bind-keyM-twindow-maximize
bind-keySM-1   window-movetogroup-1
bind-keySM-2   window-movetogroup-2
bind-keySM-3   window-movetogroup-3
bind-keySM-4   window-movetogroup-4
bind-keySM-5   window-movetogroup-5
bind-keySM-6   window-movetogroup-6
bind-keySM-7   window-movetogroup-7
bind-keySM-8   window-movetogroup-8
bind-keySM-9   window-movetogroup-9

bind-keySM-Return   "xterm -e top"
bind-keyM-Return"xterm"

command firefoxfirefox
command sofficesoffice
command iridiumiridium
command xterm  xterm

borderwidth 1
color   activeborder   gray8
color   inactiveborder black
snapdist4
sticky  yes



Re: What do you use to generate invoices on OpenBSD?

2019-12-28 Thread Roderick


I find the question strange. The program depends on the laws of
the country and personal taste. Nothing to do with OpenBSD.

I would write a script with tcl (and eventually tk) that access a
db (sqlite prefered if there is no big amount data) and generate tex 
code. Is that really difficult?! It is like a dynamic web page.

I wrote my own double-entry accounting program with tcl, tk and sqlite.
A delight using it compared with gnucrash.

Rod.


On Sat, 21 Dec 2019, Mikolaj Kucharski wrote:

> Hi,
> 
> Do you generate invoices on OpenBSD? What do you recommend? If you have
> experience in more than one app, why did you chose one over the other?
> If you use something open-source on other OS, let me know as well. If
> you use some own written app, for generating invoices, I'm also
> interested to hear, just to get an idea, which way people decide to go.
> 
> Please carbon-copy me in the replies, thanks!
> 
> -- 
> Regards,
>  Mikolaj
> 
> 



httpd with multiple php-fpm pools in separate chroots

2019-12-28 Thread Nazar Zhuk

Hello,

I am trying to run multiple PHP sites, each in it's own chroot: 
/var/www/site1, /var/www/site2, etc. Document roots are 
/var/www/siteX/htdocs.


The issue is that fastcgi DOCUMENT_ROOT and SCRIPT_FILENAME generated by 
httpd are relative to httpd chroot and include /siteX. php-fpm can't 
find scripts.


I tried to change DOCUMENT_ROOT and SCRIPT_FILENAME with "fastcgi 
param". This works for DOCUMENT_ROOT, but for SCRIPT_FILENAME, I need to 
pass the actual script name.


Conceptually I need:

fastcgi param SCRIPT_FILENAME "/htdocs/"

Built-in macros like in "block return" and "request rewrite" don't work 
here.


I can make this work with a single php file like this:

server "site1" {
listen on * port 80
root "/site1/htdocs"
location "*.php" {
fastcgi param DOCUMENT_ROOT "/htdocs"
fastcgi param SCRIPT_FILENAME "/htdocs/test.php"
fastcgi socket "/site1/run/php-fpm.sock"
}
}

This will serve http://site1/test.php which is located at 
/var/www/site1/htdocs/test.php


Is there a solution or a workaround? Aside from running all php-fpm 
pools in /var/www chroot?



Thanks.

--
Nazar



Re: midiplay and FAQ ?

2019-12-28 Thread Alexandre Ratchov
On Sat, Dec 28, 2019 at 02:25:22PM -0500, Paul Wisehart wrote:
> I'm on a recently upgraded OpenBSD 6.6 machine.
> 
> I'm reading about midiplay here:
> https://www.openbsd.org/faq/faq13.html#midi
> 
> There is no midiplay command on the machine, but there is on a 6.5
> machine.  In the man view for midiplay the last entry is at 6.4r:
> https://man.openbsd.org/OpenBSD-6.4/midiplay.1
> 
> Was midiplay removed, and midicat is the goto tool to play midi
> files?

To play midi files, a synthesizer is needed, like the audio/fluidsynth
or audio/timidity ports; both can play midi files out of the box.

I forgot to update the FAQ, I'll fix it next week unless someone beats
me at this.



midiplay and FAQ ?

2019-12-28 Thread Paul Wisehart
I'm on a recently upgraded OpenBSD 6.6 machine.

I'm reading about midiplay here:
https://www.openbsd.org/faq/faq13.html#midi

There is no midiplay command on the machine, but there is on a 6.5
machine.  In the man view for midiplay the last entry is at 6.4r:
https://man.openbsd.org/OpenBSD-6.4/midiplay.1

Was midiplay removed, and midicat is the goto tool to play midi
files?

thanks!



Re: KVM Q35 Virtual Machines , SR-IOV PCI-E Bridges and OpenBSD jitter on attached network

2019-12-28 Thread Tom Smyth
Hello just to follow up on this thread,

I tested  the following

I setup OpenBSD 6.6 Release on  Proxmox 6.1 with an intel 82599ES 10G nic
physical function pass through and there was no issues with jitter at all..

so the issue with jitter and SR-IOV seems to be confined to the
iavf(4) / ixl(4) type nics

Thanks
Tom Smyth

On Tue, 17 Dec 2019 at 05:31, Tom Smyth  wrote:
>
> Hello,
>
> I tried SR-IOV and intel I350 1Gb/s nic  hardware being passed through
> to OpenBSD 6.6 amd64
> the intel i350 passed through as a physical function on PCI-E is
> detected as an em(4) nic
>  and these dont suffer from  the same jitter as the IXL(4) or the
> AVF(4) drivers
>
> so i'm thinking there is something different in the way that em(4)
> interacts with the SRIOV Bridge
> vs the ixl(4) avf(4)  interacting wih the same SRIOV Bridge
>
> later this week some hardware with ix(4) type 10G nics will come
> available and I will try with them ..
>
>
>
>
>
>
>
>
> On Mon, 4 Nov 2019 at 01:04, Tom Smyth  wrote:
> >
> > Hello,
> > Has anyone seen jitter   from 0.5ms to 500ms
> >  on PCI-E attached (SR-IOV) Physical function / virtual function
> > Network interfaces on OpenBSD  Machines running on
> > a KVM  Virtual machine type (Q35)  ?
> >
> > any tips for diagnosing what is causing the jitter ?
> > I have ruled out the driver Ixl  by comparing physical / bare metal
> > performance vs
> > performance when the physical function  of the nic is passed through
> > to the KVM Q35 guest
> >
> > I have also ruled out the hypervisor as centos Guest VMs running with
> > the same hardware don't suffer from the jitter issue
> >
> >
> >
> > --
> > Kindest regards,
> > Tom Smyth.
>
>
>
> --
> Kindest regards,
> Tom Smyth.



-- 
Kindest regards,
Tom Smyth.



Re: OpenBSD 6.6 amd64 iavf(4) iavf / SR-iov 40G NIC lots of Jitter

2019-12-28 Thread Tom Smyth
Hello
just to update this thread

I setup OpenBSD 6.6 Release on  Proxmox 6.1 with an intel 82599ES 10G nic
physical function pass through and there was no issues with jitter at all..
so that throws my SR-IOV / PCI Bridge issue theory out the window...

so the jitter issue seems to be an issue with the ixl(4) / iavf(4)
drivers when used in an SR-IOV setup...

I hope this helps,

On Mon, 4 Nov 2019 at 00:56, Tom Smyth  wrote:
>
> Hello,
> from bare metal testing the ixl driver didn't have any jitter, but when IXL 
> card
>  it was passed through with SR-IOV on a KVM virtual machine
> there was jitter,
> so i'm thinking the issue is in the virtual machines handling of the
> PCI-PCI bridge
> I'm assuming based on the above test
> the iavf driver  is not at fault but probably some thing in PCI between
> OpenBSD Guest running on the KVM Q35 Machine.
>
> Ill open a separate email thread about KVM Guests and  support for
> Virtio / virtual
> hardware in OpenBSD
> Thanks
>
> On Tue, 22 Oct 2019 at 09:32, Tom Smyth  wrote:
> >
> > Hi,
> > I ran another test with virtio net drivers on the same Q35 type vm guest in 
> > KVM
> >  and the pings  were a lot more stable.
> >
> >
> > --- 10.4.24.1 ping statistics ---
> > 1000 packets transmitted, 1000 packets received, 0.0% packet loss
> > round-trip min/avg/max/std-dev = 0.223/0.394/3.766/0.172 ms
> >
> > pcidump
> > openbsd66# pcidump
> > Domain /dev/pci0:
> >  0:0:0: Intel 82G33 Host
> >  0:1:0: Bochs VGA
> >  0:26:0: Intel 82801I USB
> >  0:26:1: Intel 82801I USB
> >  0:26:2: Intel 82801I USB
> >  0:26:7: Intel 82801I USB
> >  0:27:0: Intel 82801I HD Audio
> >  0:28:0: Red Hat unknown
> >  0:28:1: Red Hat unknown
> >  0:28:2: Red Hat unknown
> >  0:28:3: Red Hat unknown
> >  0:29:0: Intel 82801I USB
> >  0:29:1: Intel 82801I USB
> >  0:29:2: Intel 82801I USB
> >  0:29:7: Intel 82801I USB
> >  0:30:0: Intel 82801BA Hub-to-PCI
> >  0:31:0: Intel 82801IB LPC
> >  0:31:2: Intel 82801I AHCI
> >  0:31:3: Intel 82801I SMBus
> >  5:1:0: Red Hat Qemu PCI-PCI
> >  5:2:0: Red Hat Qemu PCI-PCI
> >  5:3:0: Red Hat Qemu PCI-PCI
> >  5:4:0: Red Hat Qemu PCI-PCI
> >  6:7:0: Intel 82801I AHCI
> >  6:18:0: Qumranet Virtio Network
> >
> > dmesg
> > openbsd66# dmesg
> > OpenBSD 6.6 (GENERIC) #353: Sat Oct 12 10:45:56 MDT 2019
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> > real mem = 4278050816 (4079MB)
> > avail mem = 4135776256 (3944MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5900 (10 entries)
> > bios0: vendor SeaBIOS version 
> > "rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org" date 04/01/2014
> > bios0: QEMU Standard PC (Q35 + ICH9, 2009)
> > acpi0 at bios0: ACPI 3.0
> > acpi0: sleep states S3 S4 S5
> > acpi0: tables DSDT FACP APIC SSDT HPET MCFG
> > acpi0: wakeup devices
> > acpitimer0 at acpi0: 3579545 Hz, 24 bits
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz, 91.04 MHz, 06-3e-04
> > cpu0: 
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,FSGSBASE,TSC_ADJUST,SMEP,ERMS,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,ARAT,XSAVEOPT,MELTDOWN
> > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
> > 64b/line 16-way L2 cache
> > cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> > cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> > cpu0: smt 0, core 0, package 0
> > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> > cpu0: apic clock running at 1000MHz
> > ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
> > acpihpet0 at acpi0: 1 Hz
> > acpimcfg0 at acpi0
> > acpimcfg0: addr 0xb000, bus 0-255
> > acpiprt0 at acpi0: bus 0 (PCI0)
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > no _STA method
> > 

Iked roadwarrior to router

2019-12-28 Thread niav
Hello,
I am struggeling with understanding OpenBSD's implementation of ipsec (v2) 
fully.
So as far as I have wrapped my head around I have understood the following. 
When a packets destination and origin matches an IPsec flow it is being stolen 
from iked and passed through the tunnel. It does not hit the routing table. So 
far correct ? That implies that all the routing that needs to be done for IPsec 
tunnels to work is happening in iked.conf. Ok. Imagine the following setup.
I have got a router and a roadwarrior, both are running openbsd (-release). The 
router has got 3 subnets next to it's uplink. In my scenario I need the 
roadwarrior to pass traffic to one client in one of the subnets.
Pf is configured to pass traffic on ports 500 and 4500 protocol udp. Further 
NAT is NOT being applied. Pubkeys are according to the manual exchanged. The 
tunnel is being established. Only problem is that the traffic doesn't reach the 
desired destination.

So here a rough markout:
(IPs are examples)
Router: 192.0.0.1
Target subnet: 10.0.1.0/24
Target machine in subnet: 10.0.1.101/32

Roadwarrior: 172.0.0.1

Corresponding iked.confs:
Router iked.conf:
ikev2 'road2router' esp \
 from 0.0.0.0/0 to 10.0.2.1/32 \
 peer 172.0.0.1 local 192.0.0.1 \
 srcid roadwarrior.domain.com \
 dstid router.domain.com

roadwarrior iked.conf:
ikev2 'road2router' esp \
 from 0.0.0.0/0 to 10.0.2.1/32 \
 peer 192.0.0.1 local 172.0.0.1 \
 srcid roadwarrior.domain.com \
 dstid router.domain.com


So .. that is it. I do admit I am slightly confused by the config options in 
iked.conf.
When do I need to configure an IP address for the client in iked with 'config'.
Help would be SO much appreciated.

Thanks alot for your time.

Best regards,
Niav



Re: How to use proot?

2019-12-28 Thread Marc Espie
On Fri, Dec 27, 2019 at 06:35:34PM -0800, Xiyue Deng wrote:
> Hi,
> 
> I'm trying to set up a chroot for dpb using proot, but it looks like I'm
> doing something wrong and nothing has been created in the chroot
> directory.  According to proot man page the following command should be
> sufficient, but I got the following outputs and nothing happens in /build:
> 
> 8<
> $ sudo ./proot -B /build
Why are you still using sudo and not doas ?
You're not saying if you're running current.

> Password: 
> loguser: _pbuild
> fetchuser: _pfetch
> builduser: _pbuild
> PORTSDIR=/usr/ports
> DISTDIR=/usr/ports/distfiles
> WRKOBJDIR=/usr/ports/pobj
> LOCKDIR=/usr/ports/pobj/locks
> LOGDIR=/usr/ports/logs
> PACKAGE_REPOSITORY=/usr/ports/packages
> PLIST_REPOSITORY=/usr/ports/plist
> Couldn't find mountpoint for /build ???
> Running locate: ok
> 8<
> 
> It looks like it treats /build as a mountpoint, but what if I just need
> a local chroot?  I wonder what is the correct way to use proot.  Thanks!

No it doesn't. It's definitely not what it says.
The actual code will try to figure out on which mountpoint /build is located,
by calling dirname() until it doesn't change any more.

How about giving us the output of mount as well ?



Re: What do you use to generate invoices on OpenBSD?

2019-12-28 Thread Romain FABBRI
I like to use https://www.dolibarr.org/

-Message d'origine-
De : owner-m...@openbsd.org  De la part de Allan Streib
Envoyé : vendredi 27 décembre 2019 19:49
À : jeanfrancois ; misc@openbsd.org
Objet : Re: What do you use to generate invoices on OpenBSD?

jeanfrancois  writes:

> Thanks for that insight on using LaTeX (from ports).

If you look on CTAN there are several invoicing pacakges.

https://ctan.org/topic/invoice

Allan



Re: relayd(8) Tables and pfctl -T

2019-12-28 Thread Thomas Huber
On Fri, 27 Dec 2019 at 12:17, Stuart Henderson  wrote:

> On 2019-12-26, Thomas Huber  wrote:
> > I just tried to get a little deeper into load-balancing and try
> > to use relayd(8) in a dynamic (translate to microservices) environment
> > where I´l like to add and remove hosts on the fly.
> > After some reading I thought I should use tables for this purpose.
> >
> > relayctl(8) only allows to enable or disable complete tables but not
> > to alter a table.
> >
> > So I checked out
> >
> > 'pfctl -t  -T add '
> >
> > which should do exactly what I want.
>
> That manipulates tables in PF not in relayd.
>
> > But unfortunatelly the tables (to relay or redirect) are not
> > present in 'pfctl -s Table'
>
> relayd *uses* PF tables for redirect (but not relay). They are added
> under PF "anchors". See the list of relayd's anchors with pfctl -sA -a
> relayd. See the list of tables attached to an anchor with pfctl -sT -a
> relayd/RDR_someanchor. See table contents with pfctl -a RDR_someanchor
> -t RDR_sometable -Ts. But changing PF tables doesn't feed back to
> relayd. It won't start doing health checks for added hosts, etc.
>
>
thanks for the details, Stuart. This makes absolute sense.


> > I just hava a small setup to play, no real hosts or serverices attached
> > but before growing bigger I wanted to ask here if this should be
> > possible how I try it or another idea how to alter realyd(8) tables
> > without updating relay.conf(5) and reload.
>
> You need to update the config and reload. This is probably easier if
> you use a short file containing just the table definition and use
> "include".
>

sure. or work with some kind of template for the config-file.
The first idea I had to react on more dynamic host changes was to
utilze the '-D macro=value' for relayd. But I guess this also has
some downsides.


>
> If you want something with more dynamic runtime configuration, haproxy
> is in ports, runs ok on OpenBSD and maybe a better fit. relayd has lower
> overhead in cases where packets are sent unmodified (it uses SO_SPLICE
> for simple TCP relays to hand-off packet shuffling to the kernel;
> haproxy can do this on Linux using splice(2) on Linux but doesn't
> use SO_SPLICE) but that's irrelevant in other cases (e.g. if the
> load-balancer terminates TLS connections) and might otherwise be a
> better fit for microservices.
>

haproxy would be my weappon of choice but of course it is always nicer
to use the OpenBSD onboard-tools. And thanks again for details about
syscalls here. Quite interesting too me. I´ll try to extend my setup and do
some kind of benchmarking with relayd, haproy (on Linux and OpenBSD)
and maybe nginx.