Re: Switchd-VMD

[Mike Larkin]

On Mon, Jan 29, 2018 at 10:11:08PM -0700, Scott Seekamp wrote:
> On 29.01.2018 17:28, Mike Larkin wrote:
> 
> > On Mon, Jan 29, 2018 at 03:07:49PM -0700, Scott Seekamp wrote:
> > 
> > > I'm attempting to set up an OpenBSD virtualized environment and
> > > running into
> > > issues.
> > > 
> > > OpenBSD 6.2 AMD64 hypervisor
> > > 
> > > vm.conf:
> > > 
> > > vm "vm1" {
> > > disable
> > > memory 1g
> > > disk "/vmm/vm1.img"
> > > interface { switch "uplink" }
> > > }
> > > 
> > > vm "vm2" {
> > > disable
> > > memory 1g
> > > disk "/vmm/vm2.img"
> > > interface { switch "uplink" }
> > > }
> > > 
> > > vm "vm3" {
> > > disable
> > > memory 1g
> > > disk "/vmm/vm3.img"
> > > interface { switch "uplink" }
> > > }
> > > 
> > > switch "uplink" {
> > > interface switch0
> > > add vlan50
> > > }
> > > 
> > > I let vmd bring up the switch and once up it shows:
> > > 
> > > switch0: flags=41
> > > description: switch1-uplink
> > > index 108 llprio 3
> > > groups: switch
> > > datapath 0x6393eae0ca8447fb maxflow 1 maxgroup 1000
> > > vlan50 flags=0<>
> > > port 10 ifpriority 0 ifcost 0
> > > tap3 flags=0<>
> > > port 112 ifpriority 0 ifcost 0
> > > vether0 flags=1000
> > > port 4294967294 ifpriority 0 ifcost 0
> > > tap1 flags=0<>
> > > port 115 ifpriority 0 ifcost 0
> > > tap2 flags=0<>
> > > port 116 ifpriority 0 ifcost 0
> > > 
> > > vether0 defined as:
> > > 
> > > vether0: flags=41 mtu 1500
> > > lladdr fe:e1:ba:df:57:3b
> > > index 113 priority 0 llprio 3
> > > groups: vether egress
> > > media: Ethernet autoselect
> > > status: active
> > > inet 172.50.7.254 netmask 0xf800
> > > 
> > > vlan50 is a vlan on top of a trunk (2 em's LACP to a switch):
> > > 
> > > vlan50: flags=8943
> > > mtu 1500
> > > lladdr 00:25:90:0c:78:42
> > > description: Lab
> > > index 10 priority 0 llprio 3
> > > encap: vnetid 50 parent trunk0
> > > groups: vlan
> > > media: Ethernet autoselect
> > > status: active
> > > 
> > > I have 3 vm's as defined above:
> > > 
> > > ID   PID VCPUS  MAXMEM  CURMEM TTYOWNER NAME
> > > 2 11840 11.0G450M   ttyp6 root vm1
> > > 1 14496 11.0G560M   ttyp2 root vm2
> > > 3 48053 11.0G450M   ttyp7 root vm3
> > > 
> > > The vm's are configured with sequential IP's in the vlan50 network
> > > such as:
> > > 
> > > vio0:
> > > flags=8b43
> > > mtu 1500
> > > lladdr fe:e1:bb:d1:58:82
> > > index 1 priority 0 llprio 3
> > > groups: egress
> > > media: Ethernet autoselect
> > > status: active
> > > inet 172.50.0.6 netmask 0xf800 broadcast 172.50.7.255
> > > 
> > > The problem:
> > > 
> > > I can ping from vm -> vm
> > > I can ping from vm -> vether0 IP
> > > I can ping from vether0 to vm
> > > 
> > > I cannot communicate out of the VM to the rest of the environment
> > > reliably.
> > > 
> > > tcpdump on the tap interface shows:
> > > 
> > > tcpdump -i tap2
> > > tcpdump: listening on tap2, link-type EN10MB
> > > 14:58:54.507948 172.50.0.6 > 172.50.0.1: icmp: echo request
> > > 14:58:56.527958 172.50.0.6 > 172.50.0.1: icmp: echo request
> > > 
> > > tcpdump on the vlan interface shows the traffic gets out and tries
> > > to come
> > > back:
> > > 
> > > tcpdump -i vlan50
> > > tcpdump: listening on vlan50, link-type EN10MB
> > > 15:02:23.657480 172.50.0.6 > 172.50.0.1: icmp: echo request
> > > 15:02:23.657656 172.50.0.1 > 172.50.0.6: icmp: echo reply
> > > 15:02:25.667671 172.50.0.6 > 172.50.0.1: icmp: echo request
> > > 15:02:25.667864 172.50.0.1 > 172.50.0.6: icmp: echo reply
> > > 
> > > I'm using the out of the box pf rules on both the hypervisor box and
> > > vm's.
> > > 
> > > I can see the macs of the vm's in the switch table:
> > > 
> > > switchctl show sum
> > > Switch  PortTypeNameInfo
> > > 1   switch  /dev/switch0
> > > 1   10  mac 00:0d:b9:42:d0:fc   age
> > > 135s
> > > 1   115 mac fe:e1:bb:d1:1c:f5   age
> > > 135s
> > > 1   116 mac fe:e1:bb:d1:58:82   age
> > > 201s
> > > 1   112 mac fe:e1:bb:d1:6d:f4   age
> > > 201s
> > > 
> > > What am I missing? What would block the incoming traffic from
> > > getting back
> > > to the vm from the host level?
> > > 
> > > Thanks
> > > Scott
> > 
> > Can you try adding pass rules for the tapX interfaces to /etc/pf.conf
> > (don't
> > forget to reload the rules). And maybe the vether too. (Mine contains a
> > sequence of "pass on tap0" "pass on tap1" , etc, lines).
> > 
> > I was having similar issues until I did that; I could never figure out
> > what
> > rule was blocking it but that seemed to fix it.
> > 
> > Also, not sure if you need net.inet.ip.forwarding=1 in your sysctl
> > config
> > in this environment?
> > 
> > -ml
> > 
> 
> Mike you are my hero - I 

Re: Switchd-VMD

[Scott Seekamp]

On 29.01.2018 17:28, Mike Larkin wrote:


On Mon, Jan 29, 2018 at 03:07:49PM -0700, Scott Seekamp wrote:

I'm attempting to set up an OpenBSD virtualized environment and 
running into

issues.

OpenBSD 6.2 AMD64 hypervisor

vm.conf:

vm "vm1" {
disable
memory 1g
disk "/vmm/vm1.img"
interface { switch "uplink" }
}

vm "vm2" {
disable
memory 1g
disk "/vmm/vm2.img"
interface { switch "uplink" }
}

vm "vm3" {
disable
memory 1g
disk "/vmm/vm3.img"
interface { switch "uplink" }
}

switch "uplink" {
interface switch0
add vlan50
}

I let vmd bring up the switch and once up it shows:

switch0: flags=41
description: switch1-uplink
index 108 llprio 3
groups: switch
datapath 0x6393eae0ca8447fb maxflow 1 maxgroup 1000
vlan50 flags=0<>
port 10 ifpriority 0 ifcost 0
tap3 flags=0<>
port 112 ifpriority 0 ifcost 0
vether0 flags=1000
port 4294967294 ifpriority 0 ifcost 0
tap1 flags=0<>
port 115 ifpriority 0 ifcost 0
tap2 flags=0<>
port 116 ifpriority 0 ifcost 0

vether0 defined as:

vether0: flags=41 mtu 1500
lladdr fe:e1:ba:df:57:3b
index 113 priority 0 llprio 3
groups: vether egress
media: Ethernet autoselect
status: active
inet 172.50.7.254 netmask 0xf800

vlan50 is a vlan on top of a trunk (2 em's LACP to a switch):

vlan50: flags=8943 mtu 
1500

lladdr 00:25:90:0c:78:42
description: Lab
index 10 priority 0 llprio 3
encap: vnetid 50 parent trunk0
groups: vlan
media: Ethernet autoselect
status: active

I have 3 vm's as defined above:

ID   PID VCPUS  MAXMEM  CURMEM TTYOWNER NAME
2 11840 11.0G450M   ttyp6 root vm1
1 14496 11.0G560M   ttyp2 root vm2
3 48053 11.0G450M   ttyp7 root vm3

The vm's are configured with sequential IP's in the vlan50 network 
such as:


vio0: 
flags=8b43

mtu 1500
lladdr fe:e1:bb:d1:58:82
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect
status: active
inet 172.50.0.6 netmask 0xf800 broadcast 172.50.7.255

The problem:

I can ping from vm -> vm
I can ping from vm -> vether0 IP
I can ping from vether0 to vm

I cannot communicate out of the VM to the rest of the environment 
reliably.


tcpdump on the tap interface shows:

tcpdump -i tap2
tcpdump: listening on tap2, link-type EN10MB
14:58:54.507948 172.50.0.6 > 172.50.0.1: icmp: echo request
14:58:56.527958 172.50.0.6 > 172.50.0.1: icmp: echo request

tcpdump on the vlan interface shows the traffic gets out and tries to 
come

back:

tcpdump -i vlan50
tcpdump: listening on vlan50, link-type EN10MB
15:02:23.657480 172.50.0.6 > 172.50.0.1: icmp: echo request
15:02:23.657656 172.50.0.1 > 172.50.0.6: icmp: echo reply
15:02:25.667671 172.50.0.6 > 172.50.0.1: icmp: echo request
15:02:25.667864 172.50.0.1 > 172.50.0.6: icmp: echo reply

I'm using the out of the box pf rules on both the hypervisor box and 
vm's.


I can see the macs of the vm's in the switch table:

switchctl show sum
Switch  PortTypeNameInfo
1   switch  /dev/switch0
1   10  mac 00:0d:b9:42:d0:fc   age 
135s
1   115 mac fe:e1:bb:d1:1c:f5   age 
135s
1   116 mac fe:e1:bb:d1:58:82   age 
201s
1   112 mac fe:e1:bb:d1:6d:f4   age 
201s


What am I missing? What would block the incoming traffic from getting 
back

to the vm from the host level?

Thanks
Scott


Can you try adding pass rules for the tapX interfaces to /etc/pf.conf 
(don't

forget to reload the rules). And maybe the vether too. (Mine contains a
sequence of "pass on tap0" "pass on tap1" , etc, lines).

I was having similar issues until I did that; I could never figure out 
what

rule was blocking it but that seemed to fix it.

Also, not sure if you need net.inet.ip.forwarding=1 in your sysctl 
config

in this environment?

-ml



Mike you are my hero - I can't believe I didn't try that. Looks like I'm 
in business thank you!


Scott


OpenBSD 6.2 (GENERIC.MP) #2: Sun Dec 10 21:14:42 CET 2017
r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 85873721344 (81895MB)
avail mem = 83264139264 (79406MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x99c00 (81 entries)
bios0: vendor American Megatrends Inc. version "2.1c" date 08/03/2012
bios0: Supermicro X8DTU
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG SLIT OEMB SRAT HPET DMAR SSDT
acpi0: wakeup devices NPE1(S4) NPE2(S4) NPE3(S4) NPE4(S4) NPE5(S4) 
NPE6(S4) NPE7(S4) NPE8(S4) NPE9(S4) NPEA(S4) P0P1(S4) USB0(S4) 
USB1(S4) USB2(S4) USB5(S4) EUSB(S4) [...]

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 E5620 @ 2.40GHz, 2400.40 

Re: Random bans and weird behavior by blakkheim on the IRC channel, lift please? Wondering what's up with this guy, expecting sufficient manners from IRC chat ops.

[Sterling Archer]

On Mon, Jan 29, 2018 at 6:31 PM,   wrote:
> Hi misc@,
>
> The operator "blakkheim" just banned me on the project's IRC channel, out of 
> a private passion or agenda rather than for any benefit of the channel.
>
> I did something apparently-unapprioriate previously on the channel, which was 
> to send a handful mass-highlights in October last year, and then two of them 
> about three weeks ago.
>
> I contacted blakkheim separately to discuss the matter recently and he 
> dismissed to communicate. Two other ops said they would not lift blakkheim's 
> ban, and I have not gotten any response from the channel founder Han.
>
> Now that enough time passed, I made the effort to get into the channel and 
> then clarify the issue by sending a clarification that I understand that 
> blakkheim is easily irritated and that I will pay additional consideration to 
> not highlight people as to not disturb blakkheim in particular, please see 
> the clarification I sent, quoted at the bottom here in this email.
>
> blakkheim was not pleased apparently and instead banned me again, maybe 
> because of the fact that I mentioned his nickname at all. In all cases I find 
> his ban abusive.
>
> blakkheim's mandate to ban people from OpenBSD chat, is to protect the chat 
> from influences that would be malign to the flow of the conversation or to 
> the content of conversation.
>
> Since I am not in that zone, I find his behavior presently to be abusive and 
> disrespectful, and this is emphasized by the fact that I am a (non-code) 
> project contributor.
>
> While I totally see that a certain harshness of character is great for other 
> things, I do not see blakkheim to be justified in his present conduct as a 
> chat op.
>
> I have not tracked what he has done on the IRC channel previously, does he 
> have a history of throwing people around?
>
> I would like to be reassured that the ban has been lifted and that I not will 
> be at risk of being aggressed by blakkheim quieting or banning when 
> participating in a normal way on the chat, so that I would need to go through 
> hoops to enjoy normal project chat participation, which should be a normal 
> given.
>
> Any clarification of lift of the ban by PM or otherwise will be much 
> appreciated.
>
> I am not accustomed to being pushed by an IRC chat operator to be so 
> aggressive that I need to invoke a lot of people and make public 
> clarifications. This altogether leads me to ask what's wrong with blakkheim.
>
> Thanks,
> Tinker
>
>  --
>
> Message I sent on the channel:
>
> To finish a previous ban issue:
>
> Soo, I have at least transitorily changed my nickname, to circumvent the ban 
> for mass-highlighting three people in two messages, that blakkheim attributed 
> to me about three weeks ago, and then did not want to revert.
>
> I did a mass-highlight in October prior to that, and also annoyed blakkheim 
> by being chattier than he likes, during 2016.
>
> I'll likely not irritate blakkheim by being chatty in the future, and I 
> understand that he and others are severely irritated by highlighting more 
> than two people, so I will generally not do that.
>
> I would have appreciated if blakkheim did not ban me and insist with keeping 
> me banned, also with respect to the hardware and time donations I did to the 
> project in 2016-2017, not super big but still making a difference, and also 
> the contributions I am doing this year.
>
> Anyhow, so sorry for the highlights. I intend to not highlight again.
>
> Now please stop banning or quieting me, banning well-intended project 
> contributors (albeit not in code) for non-offenses is not productive.
>
> And so now I hope that problem is out of this world, thanks.
>
> .


So, you got banned from an IRC channel.

Okay. I suggest you move on.

-- 
:wq!

Re: I want to offer a macppc build environment

[Jordan Geoghegan]

I know they're less than ideal, but I have access to almost 30 PowerMac 
Systems available for donation to devs or anyone in general who wants 
them to hack on. They're decent 1Ghz+ (1.4 on some of them I believe) 
powerpc machines. Feel free to let me know if anyone is interested


Jordan


On 01/29/18 03:21, Artur Pedziwilk wrote:



On 15 Jan 2018, at 22:43, Matthias Freitag  
wrote:

Well, the package build takes 17 days, so i thought we could speed that up
with hardware.

I have spoken with Theo some time ago and he told me that "xserve G4" would be good 
donation as "xserve G5" doesn't work well enough.
Currently there is cluster of 2 G4 used to build packages for powerpc.

Re: Switchd-VMD

[Mike Larkin]

On Mon, Jan 29, 2018 at 03:07:49PM -0700, Scott Seekamp wrote:
> I'm attempting to set up an OpenBSD virtualized environment and running into
> issues.
> 
> OpenBSD 6.2 AMD64 hypervisor
> 
> vm.conf:
> 
> vm "vm1" {
> disable
> memory 1g
> disk "/vmm/vm1.img"
> interface { switch "uplink" }
> }
> 
> vm "vm2" {
> disable
> memory 1g
> disk "/vmm/vm2.img"
> interface { switch "uplink" }
> }
> 
> vm "vm3" {
> disable
> memory 1g
> disk "/vmm/vm3.img"
> interface { switch "uplink" }
> }
> 
> switch "uplink" {
> interface switch0
> add vlan50
> }
> 
> 
> I let vmd bring up the switch and once up it shows:
> 
> switch0: flags=41
> description: switch1-uplink
> index 108 llprio 3
> groups: switch
> datapath 0x6393eae0ca8447fb maxflow 1 maxgroup 1000
> vlan50 flags=0<>
> port 10 ifpriority 0 ifcost 0
> tap3 flags=0<>
> port 112 ifpriority 0 ifcost 0
> vether0 flags=1000
> port 4294967294 ifpriority 0 ifcost 0
> tap1 flags=0<>
> port 115 ifpriority 0 ifcost 0
> tap2 flags=0<>
> port 116 ifpriority 0 ifcost 0
> 
> vether0 defined as:
> 
> vether0: flags=41 mtu 1500
> lladdr fe:e1:ba:df:57:3b
> index 113 priority 0 llprio 3
> groups: vether egress
> media: Ethernet autoselect
> status: active
> inet 172.50.7.254 netmask 0xf800
> 
> vlan50 is a vlan on top of a trunk (2 em's LACP to a switch):
> 
> vlan50: flags=8943 mtu 1500
> lladdr 00:25:90:0c:78:42
> description: Lab
> index 10 priority 0 llprio 3
> encap: vnetid 50 parent trunk0
> groups: vlan
> media: Ethernet autoselect
> status: active
> 
> I have 3 vm's as defined above:
> 
>ID   PID VCPUS  MAXMEM  CURMEM TTYOWNER NAME
> 2 11840 11.0G450M   ttyp6 root vm1
> 1 14496 11.0G560M   ttyp2 root vm2
> 3 48053 11.0G450M   ttyp7 root vm3
> 
> The vm's are configured with sequential IP's in the vlan50 network such as:
> 
> vio0: flags=8b43
> mtu 1500
> lladdr fe:e1:bb:d1:58:82
> index 1 priority 0 llprio 3
> groups: egress
> media: Ethernet autoselect
> status: active
> inet 172.50.0.6 netmask 0xf800 broadcast 172.50.7.255
> 
> The problem:
> 
> I can ping from vm -> vm
> I can ping from vm -> vether0 IP
> I can ping from vether0 to vm
> 
> I cannot communicate out of the VM to the rest of the environment reliably.
> 
> tcpdump on the tap interface shows:
> 
> tcpdump -i tap2
> tcpdump: listening on tap2, link-type EN10MB
> 14:58:54.507948 172.50.0.6 > 172.50.0.1: icmp: echo request
> 14:58:56.527958 172.50.0.6 > 172.50.0.1: icmp: echo request
> 
> tcpdump on the vlan interface shows the traffic gets out and tries to come
> back:
> 
> tcpdump -i vlan50
> tcpdump: listening on vlan50, link-type EN10MB
> 15:02:23.657480 172.50.0.6 > 172.50.0.1: icmp: echo request
> 15:02:23.657656 172.50.0.1 > 172.50.0.6: icmp: echo reply
> 15:02:25.667671 172.50.0.6 > 172.50.0.1: icmp: echo request
> 15:02:25.667864 172.50.0.1 > 172.50.0.6: icmp: echo reply
> 
> I'm using the out of the box pf rules on both the hypervisor box and vm's.
> 
> I can see the macs of the vm's in the switch table:
> 
> switchctl show sum
> Switch  PortTypeNameInfo
> 1   switch  /dev/switch0
> 1   10  mac 00:0d:b9:42:d0:fc   age 135s
> 1   115 mac fe:e1:bb:d1:1c:f5   age 135s
> 1   116 mac fe:e1:bb:d1:58:82   age 201s
> 1   112 mac fe:e1:bb:d1:6d:f4   age 201s
> 
> What am I missing? What would block the incoming traffic from getting back
> to the vm from the host level?
> 
> Thanks
> Scott

Can you try adding pass rules for the tapX interfaces to /etc/pf.conf (don't
forget to reload the rules). And maybe the vether too. (Mine contains a
sequence of "pass on tap0" "pass on tap1" , etc, lines).

I was having similar issues until I did that; I could never figure out what
rule was blocking it but that seemed to fix it.

Also, not sure if you need net.inet.ip.forwarding=1 in your sysctl config
in this environment?

-ml

> OpenBSD 6.2 (GENERIC.MP) #2: Sun Dec 10 21:14:42 CET 2017
> 
> r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 85873721344 (81895MB)
> avail mem = 83264139264 (79406MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x99c00 (81 entries)
> bios0: vendor American 

Re: Random bans and weird behavior by blakkheim on the IRC channel, lift please? Wondering what's up with this guy, expecting sufficient manners from IRC chat ops.

[Mike Larkin]

On Mon, Jan 29, 2018 at 05:31:11PM -, ti...@openmailbox.org wrote:
> Hi misc@,
> 
> The operator "blakkheim" just banned me on the project's IRC channel, out of 
> a private passion or agenda rather than for any benefit of the channel.
> 
> I did something apparently-unapprioriate previously on the channel, which was 
> to send a handful mass-highlights in October last year, and then two of them 
> about three weeks ago.
> 
> I contacted blakkheim separately to discuss the matter recently and he 
> dismissed to communicate. Two other ops said they would not lift blakkheim's 
> ban, and I have not gotten any response from the channel founder Han.
> 
> Now that enough time passed, I made the effort to get into the channel and 
> then clarify the issue by sending a clarification that I understand that 
> blakkheim is easily irritated and that I will pay additional consideration to 
> not highlight people as to not disturb blakkheim in particular, please see 
> the clarification I sent, quoted at the bottom here in this email.
> 
> blakkheim was not pleased apparently and instead banned me again, maybe 
> because of the fact that I mentioned his nickname at all. In all cases I find 
> his ban abusive.
> 
> blakkheim's mandate to ban people from OpenBSD chat, is to protect the chat 
> from influences that would be malign to the flow of the conversation or to 
> the content of conversation.
> 
> Since I am not in that zone, I find his behavior presently to be abusive and 
> disrespectful, and this is emphasized by the fact that I am a (non-code) 
> project contributor.
> 

what is a non-code project contributor?

Random bans and weird behavior by blakkheim on the IRC channel, lift please? Wondering what's up with this guy, expecting sufficient manners from IRC chat ops.

[tinkr]

Hi misc@,

The operator "blakkheim" just banned me on the project's IRC channel, out of a 
private passion or agenda rather than for any benefit of the channel.

I did something apparently-unapprioriate previously on the channel, which was 
to send a handful mass-highlights in October last year, and then two of them 
about three weeks ago.

I contacted blakkheim separately to discuss the matter recently and he 
dismissed to communicate. Two other ops said they would not lift blakkheim's 
ban, and I have not gotten any response from the channel founder Han.

Now that enough time passed, I made the effort to get into the channel and then 
clarify the issue by sending a clarification that I understand that blakkheim 
is easily irritated and that I will pay additional consideration to not 
highlight people as to not disturb blakkheim in particular, please see the 
clarification I sent, quoted at the bottom here in this email.

blakkheim was not pleased apparently and instead banned me again, maybe because 
of the fact that I mentioned his nickname at all. In all cases I find his ban 
abusive.

blakkheim's mandate to ban people from OpenBSD chat, is to protect the chat 
from influences that would be malign to the flow of the conversation or to the 
content of conversation.

Since I am not in that zone, I find his behavior presently to be abusive and 
disrespectful, and this is emphasized by the fact that I am a (non-code) 
project contributor.

While I totally see that a certain harshness of character is great for other 
things, I do not see blakkheim to be justified in his present conduct as a chat 
op.

I have not tracked what he has done on the IRC channel previously, does he have 
a history of throwing people around?

I would like to be reassured that the ban has been lifted and that I not will 
be at risk of being aggressed by blakkheim quieting or banning when 
participating in a normal way on the chat, so that I would need to go through 
hoops to enjoy normal project chat participation, which should be a normal 
given.

Any clarification of lift of the ban by PM or otherwise will be much 
appreciated.

I am not accustomed to being pushed by an IRC chat operator to be so aggressive 
that I need to invoke a lot of people and make public clarifications. This 
altogether leads me to ask what's wrong with blakkheim.

Thanks,
Tinker

 --

Message I sent on the channel:

To finish a previous ban issue:

Soo, I have at least transitorily changed my nickname, to circumvent the ban 
for mass-highlighting three people in two messages, that blakkheim attributed 
to me about three weeks ago, and then did not want to revert.

I did a mass-highlight in October prior to that, and also annoyed blakkheim by 
being chattier than he likes, during 2016.

I'll likely not irritate blakkheim by being chatty in the future, and I 
understand that he and others are severely irritated by highlighting more than 
two people, so I will generally not do that.

I would have appreciated if blakkheim did not ban me and insist with keeping me 
banned, also with respect to the hardware and time donations I did to the 
project in 2016-2017, not super big but still making a difference, and also the 
contributions I am doing this year.

Anyhow, so sorry for the highlights. I intend to not highlight again.

Now please stop banning or quieting me, banning well-intended project 
contributors (albeit not in code) for non-offenses is not productive.

And so now I hope that problem is out of this world, thanks.

.

Switchd-VMD

[Scott Seekamp]

I'm attempting to set up an OpenBSD virtualized environment and running 
into issues.


OpenBSD 6.2 AMD64 hypervisor

vm.conf:

vm "vm1" {
disable
memory 1g
disk "/vmm/vm1.img"
interface { switch "uplink" }
}

vm "vm2" {
disable
memory 1g
disk "/vmm/vm2.img"
interface { switch "uplink" }
}

vm "vm3" {
disable
memory 1g
disk "/vmm/vm3.img"
interface { switch "uplink" }
}

switch "uplink" {
interface switch0
add vlan50
}


I let vmd bring up the switch and once up it shows:

switch0: flags=41
description: switch1-uplink
index 108 llprio 3
groups: switch
datapath 0x6393eae0ca8447fb maxflow 1 maxgroup 1000
vlan50 flags=0<>
port 10 ifpriority 0 ifcost 0
tap3 flags=0<>
port 112 ifpriority 0 ifcost 0
vether0 flags=1000
port 4294967294 ifpriority 0 ifcost 0
tap1 flags=0<>
port 115 ifpriority 0 ifcost 0
tap2 flags=0<>
port 116 ifpriority 0 ifcost 0

vether0 defined as:

vether0: flags=41 mtu 1500
lladdr fe:e1:ba:df:57:3b
index 113 priority 0 llprio 3
groups: vether egress
media: Ethernet autoselect
status: active
inet 172.50.7.254 netmask 0xf800

vlan50 is a vlan on top of a trunk (2 em's LACP to a switch):

vlan50: flags=8943 mtu 
1500

lladdr 00:25:90:0c:78:42
description: Lab
index 10 priority 0 llprio 3
encap: vnetid 50 parent trunk0
groups: vlan
media: Ethernet autoselect
status: active

I have 3 vm's as defined above:

   ID   PID VCPUS  MAXMEM  CURMEM TTYOWNER NAME
2 11840 11.0G450M   ttyp6 root vm1
1 14496 11.0G560M   ttyp2 root vm2
3 48053 11.0G450M   ttyp7 root vm3

The vm's are configured with sequential IP's in the vlan50 network such 
as:


vio0: 
flags=8b43 mtu 
1500

lladdr fe:e1:bb:d1:58:82
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect
status: active
inet 172.50.0.6 netmask 0xf800 broadcast 172.50.7.255

The problem:

I can ping from vm -> vm
I can ping from vm -> vether0 IP
I can ping from vether0 to vm

I cannot communicate out of the VM to the rest of the environment 
reliably.


tcpdump on the tap interface shows:

tcpdump -i tap2
tcpdump: listening on tap2, link-type EN10MB
14:58:54.507948 172.50.0.6 > 172.50.0.1: icmp: echo request
14:58:56.527958 172.50.0.6 > 172.50.0.1: icmp: echo request

tcpdump on the vlan interface shows the traffic gets out and tries to 
come back:


tcpdump -i vlan50
tcpdump: listening on vlan50, link-type EN10MB
15:02:23.657480 172.50.0.6 > 172.50.0.1: icmp: echo request
15:02:23.657656 172.50.0.1 > 172.50.0.6: icmp: echo reply
15:02:25.667671 172.50.0.6 > 172.50.0.1: icmp: echo request
15:02:25.667864 172.50.0.1 > 172.50.0.6: icmp: echo reply

I'm using the out of the box pf rules on both the hypervisor box and 
vm's.


I can see the macs of the vm's in the switch table:

switchctl show sum
Switch  PortTypeNameInfo
1   switch  /dev/switch0
1   10  mac 00:0d:b9:42:d0:fc   age 135s
1   115 mac fe:e1:bb:d1:1c:f5   age 135s
1   116 mac fe:e1:bb:d1:58:82   age 201s
1   112 mac fe:e1:bb:d1:6d:f4   age 201s

What am I missing? What would block the incoming traffic from getting 
back to the vm from the host level?


Thanks
ScottOpenBSD 6.2 (GENERIC.MP) #2: Sun Dec 10 21:14:42 CET 2017

r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 85873721344 (81895MB)
avail mem = 83264139264 (79406MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x99c00 (81 entries)
bios0: vendor American Megatrends Inc. version "2.1c" date 08/03/2012
bios0: Supermicro X8DTU
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG SLIT OEMB SRAT HPET DMAR SSDT
acpi0: wakeup devices NPE1(S4) NPE2(S4) NPE3(S4) NPE4(S4) NPE5(S4) NPE6(S4) 
NPE7(S4) NPE8(S4) NPE9(S4) NPEA(S4) P0P1(S4) USB0(S4) USB1(S4) USB2(S4) 
USB5(S4) EUSB(S4) [...]
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 E5620 @ 2.40GHz, 2400.40 MHz
cpu0: 

Re: pcengines apu boards

[Tom Smyth]

Hello
Im not so sure if this is relevant or not but sometimes when installing
6.2.fs onto a usb stick it wont boot in one of the exterior front USB3
Ports, I pretty much dismissed this as an electrical connection issue
but maybe there is more to it ...Unfortunately I only use USB3 for
installing OpenBSD after that I dont really use it at all

On 29 January 2018 at 20:13, Mike Tancsa  wrote:
> On 1/28/2018 8:40 PM, Paul B. Henson wrote:
>> On Wed, Jan 17, 2018 at 12:56:04PM +0100, Christopher Zimmermann wrote:
>>
>>> I have the same problem and have tried to hunt the bug, but failed so
>>> far. Have you already identified the quirks linux and freebsd use to
>>> fix this problem?
>>
>> No :(, I worked on it for a while but kernel hacking isn't my
>
> Not sure if it will help or not, but I recall a timing issue on earlier
> versions of FreeBSD and the APU2/3s where I could work around it by
> loading the xhci module as a kld after the box had fully booted.
>
> ---Mike
> --
> ---
> Mike Tancsa, tel +1 519 651 3400
> Sentex Communications, m...@sentex.net
> Providing Internet services since 1994 www.sentex.net
> Cambridge, Ontario Canada   http://www.tancsa.com/
>

Re: ksh key bindings in vi-mode (arrow keys)

[Kris Katterjohn]

On Mon, Jan 29, 2018 at 07:52:06PM +0100, Andreas Kusalananda Kähäri wrote:
> It looks as if the "bind" builtin lives, along with the bindable
> functions, in emacs.c and that the command line editing in Vi-mode never
> ever calls these.
> 
> I'll conclude (for the time being, until someone says otherwise) that
> the "bind" builtin therefore is a no-op in Vi-mode.

In the ksh man page, one of the entries for bind says to see the section
on the Emacs editing mode for more.  I see bind mentioned there, but not
in the Vi editing mode section.

For whatever that's worth.

Cheers,
Kris Katterjohn

Re: pcengines apu boards

[Mike Tancsa]

On 1/28/2018 8:40 PM, Paul B. Henson wrote:
> On Wed, Jan 17, 2018 at 12:56:04PM +0100, Christopher Zimmermann wrote:
> 
>> I have the same problem and have tried to hunt the bug, but failed so
>> far. Have you already identified the quirks linux and freebsd use to
>> fix this problem?
> 
> No :(, I worked on it for a while but kernel hacking isn't my

Not sure if it will help or not, but I recall a timing issue on earlier
versions of FreeBSD and the APU2/3s where I could work around it by
loading the xhci module as a kld after the box had fully booted.

---Mike
-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

Re: ksh key bindings in vi-mode (arrow keys)

[Andreas Kusalananda Kähäri]

I'll answer my own question...

It looks as if the "bind" builtin lives, along with the bindable
functions, in emacs.c and that the command line editing in Vi-mode never
ever calls these.

I'll conclude (for the time being, until someone says otherwise) that
the "bind" builtin therefore is a no-op in Vi-mode.


Cheers,

On Mon, Jan 29, 2018 at 03:05:38PM +0100, Andreas Kusalananda Kähäri wrote:
> Hi,
> 
> I'm wondering whether "bind" works at all in ksh, in Vi-mode.
> 
> I'm currently using the default (unchanged) key bindings and my
> up-arrow key sends "^[[A".  The bind command tells me this is bound to
> "up-history", but it places me at the end of the command line in insert
> mode (just as would be expected after pressing "Esc" and "A").
> 
> bind seems to work as expected in Emacs mode.
> 
> The reason I'm asking is that I'm trying to get the arrow keys to work
> intuitively in Vi editing mode as a complement to "hjkl" (I'm on a
> Dvorak keyboard).
> 
> 
> I'm running an up-to-date -current installation on amd64.
> 
> 
> Cheers,
> Andreas
> 
> -- 
> Andreas Kusalananda Kähäri,
> National Bioinformatics Infrastructure Sweden (NBIS),
> Uppsala University, Sweden.
> 

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.

Resume fails with connected USB hub

[Maximilian Pichler]

Hi,

Resume after suspend fails on a Zenbook UX390UA if (and only if) the
USB hub/adapter that comes with it is connected.

When resume is attempted by pressing a key, the fan starts to spin,
but the screen remains blank. The laptop can no longer be ssh'ed into.

This is fully reproducible and suspend/resume works perfectly fine
without the hub.

The offender is this:
uhub1 at uhub0 port 1 configuration 1 interface 0 "VIA Labs, Inc.
USB2.0 Hub" rev 2.10/6.80 addr 2
ugen0 at uhub1 port 2 "VIA Technologies Inc. USB 2.0 BILLBOARD" rev
2.01/3.04 addr 3

https://www.asus.com/Laptops-Accessory/Mini-Dock/

Incidentally, after having been forced to shut down the machine by
holding the power button for a few seconds, each time triggering fsck
upon reboot, I can no longer boot the default kernel /bsd, but have to
type "boot bsd.sp" at the boot prompt. Without this, a single line of
text saying "entry point at 0xf000158" appears on the screen for a few
seconds and then the machine reboots by itself. For what it's worth,
all partitions are mounted with softdep.

Best,

Max


OpenBSD 6.2-current (RAMDISK_CD) #379: Wed Jan 24 12:58:41 MST 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 17037766656 (16248MB)
avail mem = 16517648384 (15752MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xeb350 (31 entries)
bios0: vendor American Megatrends Inc. version "UX390UAK.312" date 04/25/2017
bios0: ASUSTeK COMPUTER INC. UX390UAK
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC FPDT ECDT MCFG FIDT SSDT MSDM SSDT HPET
UEFI SSDT LPIT WSMT SSDT SSDT DBGP DBG2 BGRT DMAR TPM2
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 2594.89 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus 3 (RP09)
acpiprt5 at acpi0: bus -1 (RP10)
acpiprt6 at acpi0: bus -1 (RP11)
acpiprt7 at acpi0: bus -1 (RP12)
acpiprt8 at acpi0: bus -1 (RP13)
acpiprt9 at acpi0: bus 1 (RP01)
acpiprt10 at acpi0: bus -1 (RP02)
acpiprt11 at acpi0: bus -1 (RP03)
acpiprt12 at acpi0: bus -1 (RP04)
acpiprt13 at acpi0: bus -1 (RP05)
acpiprt14 at acpi0: bus 2 (RP06)
acpiprt15 at acpi0: bus -1 (RP07)
acpiprt16 at acpi0: bus -1 (RP08)
acpiprt17 at acpi0: bus -1 (RP17)
acpiprt18 at acpi0: bus -1 (RP18)
acpiprt19 at acpi0: bus -1 (RP19)
acpiprt20 at acpi0: bus -1 (RP20)
acpiprt21 at acpi0: bus -1 (RP14)
acpiprt22 at acpi0: bus -1 (RP15)
acpiprt23 at acpi0: bus -1 (RP16)
acpiec at acpi0 not configured
acpicpu at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpitz at acpi0 not configured
"INT3F0D" at acpi0 not configured
"ACPI0003" at acpi0 not configured
"PNP0C0D" at acpi0 not configured
"PNP0C0A" at acpi0 not configured
"INT3403" at acpi0 not configured
"INT3403" at acpi0 not configured
"INT3403" at acpi0 not configured
"INT3403" at acpi0 not configured
"ATK3001" at acpi0 not configured
"ELAN1301" at acpi0 not configured
"PNP0C0E" at acpi0 not configured
"INT33A1" at acpi0 not configured
"PNP0C0C" at acpi0 not configured
"MSFT0101" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"ATK4002" at acpi0 not configured
"INT3400" at acpi0 not configured
"INT340E" at acpi0 not configured
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 7G Host" rev 0x02
"Intel HD Graphics 620" rev 0x02 at pci0 dev 2 function 0 not configured
"Intel Core 6G Thermal" rev 0x02 at pci0 dev 4 function 0 not configured
xhci0 at pci0 dev 20 function 0 "Intel 100 Series xHCI" 

Re: gzip compression and httpd/relayd

[Thuban]

* Stuart Henderson  le [29-01-2018 08:14:03 +]:
> On 2018-01-28, 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"
> > 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.
> >
> >
> 
> Fun hack, but it's going to break for a browser that doesn't support gzip.
> Also it's a nice trap for the next admin that comes along (which may be your
> future self :)

The fun part comes when you trap script kiddies with gzip bomb: 

- Create a bomb : `dd if=/dev/zero bs=1M count=10240 | gzip > surprise.html`
(yeah, this is not html, but bots don't care)
- In html code, put something like 
Do NOT 
follow this link or you will have problems!

- In relayd.conf : 

match request header "Accept-Encoding" value "gzip"
match request path "/surprise.html"
match response header set "Content-Encoding" value "gzip"

A bot fetching "surprise.html" will see CPU usage increasing, too bad...

Regards.


signature.asc
Description: PGP signature

ksh key bindings in vi-mode (arrow keys)

[Andreas Kusalananda Kähäri]

Hi,

I'm wondering whether "bind" works at all in ksh, in Vi-mode.

I'm currently using the default (unchanged) key bindings and my
up-arrow key sends "^[[A".  The bind command tells me this is bound to
"up-history", but it places me at the end of the command line in insert
mode (just as would be expected after pressing "Esc" and "A").

bind seems to work as expected in Emacs mode.

The reason I'm asking is that I'm trying to get the arrow keys to work
intuitively in Vi editing mode as a complement to "hjkl" (I'm on a
Dvorak keyboard).


I'm running an up-to-date -current installation on amd64.


Cheers,
Andreas

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.

Re: http_proxy for rc.firsttime after Upgrade

[Raimo Niskanen]

On Mon, Jan 29, 2018 at 09:48:08AM +, Stuart Henderson wrote:
> On 2018-01-23, Raimo Niskanen  wrote:
> > On Mon, Jan 22, 2018 at 08:22:34PM -0500, trondd wrote:
> >> On Mon, January 22, 2018 2:36 am, Raimo Niskanen wrote:
> >> > On Fri, Jan 19, 2018 at 10:47:15AM -0500, trondd wrote:
> >> >> On Fri, January 19, 2018 4:29 am, Raimo Niskanen wrote:
> >> >> > I have some machines behind a squid proxy and have set the http_proxy 
> >> >> > and
> >> >> > ftp_proxy environment variables both in /etc/profile and in 
> >> >> > /etc/login.conf
> >> >> > for the default login class.  This works well.
> >> >> >
> >> >> > But after an upgrade when rc.firsttime calls fw_update and checks for
> >> >> > binary patches the proxy is not used, so I have to wait for that to 
> >> >> > time
> >> >> > out or break it with Ctrl-C and call fw_update manually.
> >> >> >
> >> >> > So I just wonder if anybody have an idea of how to set the http_proxy 
> >> >> > and
> >> >> > ftp_proxy environment variables so they are picked up by rc.firsttime?
> >> >>
> >> >> I submitted a patch for this:
> >> >> https://marc.info/?l=openbsd-tech=151260860105270=2
> >> >
> >> > That sure looks like an improvement!  But should maybe $http_proxy be
> >> > placed between single quotes?
> >> >
> >> > Unfortunately I fetch the sets into /var/OpenBSD/`machine` and
> >> > verify them before rebooting into /bsd62.rd, so it would not work
> >> > for me...
> >> 
> >> Ah, I see. Yeah, I only acconted for the obvious case when a net
> >> install was done.
> >> 
> >> Having thought about it again, an easier solution will be to write your
> >> http_proxy export to /etc/rc.firsttime before rebooting into bsd.rd.  If
> >> you have your update process scripted already, it's an easy additional
> >> line.  The installer only appends commands so anything you have in
> >> rc.firsttime will be preserved.
> >
> > In my case it would work if rc.firsttime sourced /etc/profile, but I do not
> > know if that is a generally good idea...,
> 
> I think this is probably not a good idea, profile may not be squeaky-clean
> or it might not work correctly before system startup.

I see your point.

But maybe transferring http_proxy from the installer to rc.firsttime is a
good feature...  Does not help me, though.

> 
> >   in particular since I can not
> > find any way to set environment variables for /etc/rc to pass to system and
> > package daemons.
> 
> It doesn't help for rc.firsttime, but the canonical way to do this is via
> a class in login.conf - rc.d(8) automatically handles this:
> 
>"daemon_class is a special read-only variable.  It is set to "daemon" 
> unless
>there is a login class configured in login.conf(5) with the same name as 
> the
>rc.d script itself, in which case it will be set to that login class.  This
>allows setting many initial process properties, for example environment
>variables, scheduling priority, and process limits such as maximum memory
>use and number of files."
> 
> For example:
> 
> daemonname:setenv=FOO=bar:tc=daemon:
> 
> If you need a : in the definition, use \c.
> 
> daemonname:setenv=PATH=/usr/local/bin\c/usr/bin:tc=daemon:

That is a neat feature!  I have already set http_proxy, https_proxy
and ftp_proxy for the 'default' login class.

Great to know for the future that variables can be set per daemon name!

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB

Re: http_proxy for rc.firsttime after Upgrade

[Stuart Henderson]

On 2018-01-23, Raimo Niskanen  wrote:
> On Mon, Jan 22, 2018 at 08:22:34PM -0500, trondd wrote:
>> On Mon, January 22, 2018 2:36 am, Raimo Niskanen wrote:
>> > On Fri, Jan 19, 2018 at 10:47:15AM -0500, trondd wrote:
>> >> On Fri, January 19, 2018 4:29 am, Raimo Niskanen wrote:
>> >> > I have some machines behind a squid proxy and have set the http_proxy 
>> >> > and
>> >> > ftp_proxy environment variables both in /etc/profile and in 
>> >> > /etc/login.conf
>> >> > for the default login class.  This works well.
>> >> >
>> >> > But after an upgrade when rc.firsttime calls fw_update and checks for
>> >> > binary patches the proxy is not used, so I have to wait for that to time
>> >> > out or break it with Ctrl-C and call fw_update manually.
>> >> >
>> >> > So I just wonder if anybody have an idea of how to set the http_proxy 
>> >> > and
>> >> > ftp_proxy environment variables so they are picked up by rc.firsttime?
>> >>
>> >> I submitted a patch for this:
>> >> https://marc.info/?l=openbsd-tech=151260860105270=2
>> >
>> > That sure looks like an improvement!  But should maybe $http_proxy be
>> > placed between single quotes?
>> >
>> > Unfortunately I fetch the sets into /var/OpenBSD/`machine` and
>> > verify them before rebooting into /bsd62.rd, so it would not work
>> > for me...
>> 
>> Ah, I see. Yeah, I only acconted for the obvious case when a net
>> install was done.
>> 
>> Having thought about it again, an easier solution will be to write your
>> http_proxy export to /etc/rc.firsttime before rebooting into bsd.rd.  If
>> you have your update process scripted already, it's an easy additional
>> line.  The installer only appends commands so anything you have in
>> rc.firsttime will be preserved.
>
> In my case it would work if rc.firsttime sourced /etc/profile, but I do not
> know if that is a generally good idea...,

I think this is probably not a good idea, profile may not be squeaky-clean
or it might not work correctly before system startup.

>   in particular since I can not
> find any way to set environment variables for /etc/rc to pass to system and
> package daemons.

It doesn't help for rc.firsttime, but the canonical way to do this is via
a class in login.conf - rc.d(8) automatically handles this:

   "daemon_class is a special read-only variable.  It is set to "daemon" unless
   there is a login class configured in login.conf(5) with the same name as the
   rc.d script itself, in which case it will be set to that login class.  This
   allows setting many initial process properties, for example environment
   variables, scheduling priority, and process limits such as maximum memory
   use and number of files."

For example:

daemonname:setenv=FOO=bar:tc=daemon:

If you need a : in the definition, use \c.

daemonname:setenv=PATH=/usr/local/bin\c/usr/bin:tc=daemon:

Re: IKEv2 - Tunnel all internet traffic from gateway

[Stuart Henderson]

On 2018-01-29, Stuart Henderson  wrote:
> On 2018-01-28, Daniel Ramos  wrote:
>> I'm trying to tunnel all internet traffic from my internal network 
>> (192.168.2.0/24) through another internet-facing machine (10.1.1.0/24) 
>> using IKEv2. After trying what seems to be every possibility of pf.conf 
>> and iked.conf combinations, I just can't seem to get it right. My 
>> closest attempt is to NAT all traffic from 192.168.2.0/24 to appear as 
>> virtual IP 10.1.1.2 on the other side, which is then NAT'd out to the 
>> internet as usual. The problem with this config is that ALL traffic, 
>> including local traffic to 192.168.2.0/24, is tunneled. This is not 
>> desired because I can no longer access my local gateway (192.168.2.1), 
>> or any locally hosted services.
>
> What you need is a "bypass flow", I don't think it can be done from
> iked.conf but you can try this in ipsec.conf (adapt addresses as needed):
>
> flow from 192.168.46.48/28 to 192.168.46.48/28 type bypass
>
> ipsecctl -f /etc/ipsec.conf to load it at runtime, ipsec=YES in
> rc.conf.local to load at boot.
>
> Please follow-up to confirm whether it works for the archive, I've only
> done this combined with IKEv1 but I don't see a reason why it wouldn't work.

PS: might be worth dropping a comment in iked.conf as a reminder that
ipsec.conf is also involved in the config.

Re: gzip compression and httpd/relayd

[Stuart Henderson]

On 2018-01-28, 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"
> 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.
>
>

Fun hack, but it's going to break for a browser that doesn't support gzip.
Also it's a nice trap for the next admin that comes along (which may be your
future self :)