Re: Home Assistant
> On 11 May 2021, at 05:01, pas...@pascallen.nl wrote: > > Dear David, > > How do you start homeassistant after a reboot? Manually? i have these scripts. the pexp in the rc script doesnt work, but i havent needed it to yet. apathy$ cat /etc/rc.d/hass #!/bin/ksh daemon="/opt/local/sbin/hass --daemon" daemon_user="_hass" pexp="/opt/hass/bin/hass" . /etc/rc.d/rc.subr rc_reload=NO rc_cmd $1 apathy$ cat /opt/local/sbin/hass #!/bin/ksh . /opt/hass/bin/activate /opt/hass/bin/hass "$@"
Re: Bidirectional audio between OpenBSD sndiod <-> Debian pulseaudio
On Mon, May 10, 2021 at 07:05:49PM +, Martin wrote: > Hi, > > Great experience! But I have no possibility to recompile each sound producer > software to have sndio support. > > So my way is to use additional layer of well implemented sound architecture > and it add additional layer to sound system for sure. > > I've tried to use alsa-sndio module from https://github.com/Duncaen/alsa-sndio > > Module builds successfully, but > > $ sudo alsactl init > returns it can't find any audio hardware (Debian system is headless and run > on VM). > > Tried to add snd-dummy module from > https://www.alsa-project.org/main/index.php/Matrix:Module-dummy > $ sudo modprobe snd-dummy > > $ sudo alsactl init > Found hardware: "Dummy" "Dummy Mixer" "" "" "" > > But how to output from alsa-sndio module using alsa is not clear for me. > > I've created /etc/asound.conf as required by developers of alsa-sndio module. > > $ cat /etc/asound.conf > pcm.!default ( > type sndio > device "snd@192.168.33.1/0" > > alsa don't use this config. > > Do you have some experience how to use alsa modules to iteract with OpenBSD > sndiod server? > Not much, sorry. Did you check that the VM can talk to the host? You could do so by installing the sndio library and utils on the VM and test with aucat that everything works.
'python3.8 setup.py install' gets 'ZIP does not support timestamps before 1980' at OpenBSD 6.9
After upgrading to OpenBSD 6.9 'ValueError: ZIP does not support timestamps before 1980' exceptions started occuring when installing python packages by: 'python3.8 setup.py install --user' where the package was built by: 'python3.8 setup.py sdist --formats gztar' and extracted from the archive on OpenBSD 6.9 by: 'tar xzf *.tar.gz'. The script below uses the packaging_tutorial_elijah-0.0.3 package downloaded from pypi.org and I apologise for not letting the job install the numpy dependency in the two cases which get that far. The third case fails as described above. Simply installing the downloaded package works. Simulating the distribution and installation of a source package built from the downloaded code fails as described above. If Python's tarfile module is used to extract the package from the locally created archive the installation works. I have not seen problems with zip archives. Source distributions built with python3.7 on OpenBSD 6.8 are installed by python3.8 on OpenBSD 6.9 after extracting with tar. Does anyone else see this behaviour? Roger Script started on Mon May 10 16:06:25 2021 opendev$ ls -l pte total 8 -rw-r--r-- 1 roger roger 1253 May 9 23:08 packaging_tutorial_elijah-0.0.3.tar.gz opendev$ cd pte opendev$ tar xzf packaging_tutorial_elijah-0.0.3.tar.gz opendev$ ls -l * -rw-r--r-- 1 roger roger 1253 May 9 23:08 packaging_tutorial_elijah-0.0.3.tar.gz packaging_tutorial_elijah-0.0.3: total 48 -rw-r--r-- 1 roger roger 485 Mar 30 10:27 PKG-INFO -rw-r--r-- 1 roger roger6 Mar 30 09:31 README.md drwxr-xr-x 2 roger roger 512 Mar 30 10:27 example_pkg drwxr-xr-x 2 roger roger 512 Mar 30 10:27 packaging_tutorial_elijah.egg-info -rw-r--r-- 1 roger roger 42 Mar 30 10:27 setup.cfg -rw-r--r-- 1 roger roger 751 Mar 30 10:27 setup.py opendev$ python3.8 setup.py install --user python3.8: can't open file 'setup.py': [Errno 2] No such file or directory opendev$ cd packaging_tutorial_elijah-0.0.3 opendev$ python3.8 setup.py im nstall --user running install running bdist_egg running egg_info writing packaging_tutorial_elijah.egg-info/PKG-INFO writing dependency_links to packaging_tutorial_elijah.egg-info/dependency_links.txt writing requirements to packaging_tutorial_elijah.egg-info/requires.txt writing top-level names to packaging_tutorial_elijah.egg-info/top_level.txt reading manifest file 'packaging_tutorial_elijah.egg-info/SOURCES.txt' writing manifest file 'packaging_tutorial_elijah.egg-info/SOURCES.txt' installing library code to build/bdist.openbsd-6.9-amd64/egg running install_lib running build_py creating build creating build/lib creating build/lib/example_pkg copying example_pkg/hello.py -> build/lib/example_pkg copying example_pkg/__init__.py -> build/lib/example_pkg creating build/bdist.openbsd-6.9-amd64 creating build/bdist.openbsd-6.9-amd64/egg creating build/bdist.openbsd-6.9-amd64/egg/example_pkg copying build/lib/example_pkg/hello.py -> build/bdist.openbsd-6.9-amd64/egg/example_pkg copying build/lib/example_pkg/__init__.py -> build/bdist.openbsd-6.9-amd64/egg/example_pkg byte-compiling build/bdist.openbsd-6.9-amd64/egg/example_pkg/hello.py to hello.cpython-38.pyc byte-compiling build/bdist.openbsd-6.9-amd64/egg/example_pkg/__init__.py to __init__.cpython-38.pyc creating build/bdist.openbsd-6.9-amd64/egg/EGG-INFO copying packaging_tutorial_elijah.egg-info/PKG-INFO -> build/bdist.openbsd-6.9-amd64/egg/EGG-INFO copying packaging_tutorial_elijah.egg-info/SOURCES.txt -> build/bdist.openbsd-6.9-amd64/egg/EGG-INFO copying packaging_tutorial_elijah.egg-info/dependency_links.txt -> build/bdist.openbsd-6.9-amd64/egg/EGG-INFO copying packaging_tutorial_elijah.egg-info/requires.txt -> build/bdist.openbsd-6.9-amd64/egg/EGG-INFO copying packaging_tutorial_elijah.egg-info/top_level.txt -> build/bdist.openbsd-6.9-amd64/egg/EGG-INFO zip_safe flag not set; analyzing archive contents... creating dist creating 'dist/packaging_tutorial_elijah-0.0.3-py3.8.egg' and adding 'build/bdist.openbsd-6.9-amd64/egg' to it removing 'build/bdist.openbsd-6.9-amd64/egg' (and everything under it) Processing packaging_tutorial_elijah-0.0.3-py3.8.egg Removing /home/roger/.local/lib/python3.8/site-packages/packaging_tutorial_elijah-0.0.3-py3.8.egg Copying packaging_tutorial_elijah-0.0.3-py3.8.egg to /home/roger/.local/lib/python3.8/site-packages packaging-tutorial-elijah 0.0.3 is already the active version in easy-install.pth Installed /home/roger/.local/lib/python3.8/site-packages/packaging_tutorial_elijah-0.0.3-py3.8.egg Processing dependencies for packaging-tutorial-elijah==0.0.3 Searching for numpy Reading https://pypi.org/simple/numpy/ Download error on https://pypi.org/simple/numpy/: [Errno -5] no address associated with name -- Some packages may not be found! Couldn't find index page for 'numpy' (maybe misspelled?) Scanning index of all packages (this may take a while) Reading https://pypi.org/simple/ Download error on https://pypi.org/simple/: [Errno
Re: NAT on same interface as vlan on OpenBSD 6.8
Hi Kenneth,
It was staring me in the face and I did not see it. I shot myself in the foot
and didn’t realize it.
Thanks heaps for your support.
From: Kenneth Gober
Sent: Monday, 10 May 2021 11:49 PM
To: Dirk Coetzee
Cc: misc@openbsd.org
Subject: Re: NAT on same interface as vlan on OpenBSD 6.8
On Mon, May 10, 2021 at 5:26 AM Dirk Coetzee
mailto:d...@best-it.tech>> wrote:
I am hoping to create a pf.conf configuration that has VLAN’s and NAT via the
same (physical) interface. The hardware is only capable of having a single
Ethernet interface.
vlan100 is an isolated network to setup servers and is connected to a switch
that is setup for vlan100 and vlan 1. The same interface has the main internal
IP address 192.168.10.241 ("vlan 1" / no vlan). Devices behind vlan100 network
need to be NAT’ed behind the internal / corporate interface 192.168.10.241, so
that they can still have internet access - without affecting the main /
corporate network.
pass out quick log on $int_if
match out on $int_if inet from $vl100_net to any nat-to $int_ip source-hash
I believe your issue is that the "pass out quick" takes effect immediately and
rules that come later aren't checked. Either remove the 'quick' or move the
'match out' NAT rule so that it's above the 'pass out quick'.
Some people don't like to use 'quick' because it makes "last match" semantics
hard to follow (it's an exception to keep track of if most of your ruleset is
structured for 'last match wins'). I prefer to use 'quick' on almost all of my
rules to get "first match" semantics because I find 'first match wins' easier
to work with (it means that the remainder of the ruleset after a matching
'pass' is irrelevant and need not be examined). It is purely personal
preference on whether you prefer to read your rules from the bottom up or the
top down. If you want to continue to use 'quick' the most expedient fix is to
move the 'match out' so that it comes before your first 'pass out' rule.
-ken
Re: Bidirectional audio between OpenBSD sndiod <-> Debian pulseaudio
Hi, Great experience! But I have no possibility to recompile each sound producer software to have sndio support. So my way is to use additional layer of well implemented sound architecture and it add additional layer to sound system for sure. I've tried to use alsa-sndio module from https://github.com/Duncaen/alsa-sndio Module builds successfully, but $ sudo alsactl init returns it can't find any audio hardware (Debian system is headless and run on VM). Tried to add snd-dummy module from https://www.alsa-project.org/main/index.php/Matrix:Module-dummy $ sudo modprobe snd-dummy $ sudo alsactl init Found hardware: "Dummy" "Dummy Mixer" "" "" "" But how to output from alsa-sndio module using alsa is not clear for me. I've created /etc/asound.conf as required by developers of alsa-sndio module. $ cat /etc/asound.conf pcm.!default ( type sndio device "snd@192.168.33.1/0" alsa don't use this config. Do you have some experience how to use alsa modules to iteract with OpenBSD sndiod server? Martin ‐‐‐ Original Message ‐‐‐ On Sunday, May 9, 2021 9:49 AM, Alexandre Ratchov wrote: > On Sat, May 08, 2021 at 10:29:35AM +, Martin wrote: > > > Hi list, > > It is great to have bidirectional audio between OpenBSD host and Debian > > guest (headless). I hope I move in a right way to make this thing working. > > Required configuration: > > mic-in on OpenBSD host >> Debian VMM guest > > audio-out from Debian VMM guest >> OpenBSD host > > Does anybody using pulseaudio or any other driver to have > > bidirectional network audio stream between VMM guest and OpenBSD > > host system? > > Hi, > > These days I use a simiar setup with Alpine running in a > OpenBSD-hosted VM. The main purpose of sndiod -L option is to handle > such setups (don't forget to copy your ~/.sndio/cookie on the VM). In > the past, I used a lot Debian, but on a real machine. > > I didn't try to involve pulseaudio or any alsa tweakery, to limit the > number of audio software layers and in turn get the maximum audio > stability. So I just rebuild the software I needed with sndio support > enabled (that was mostly firefox and few audio players).
Re: Home Assistant
Dear David, How do you start homeassistant after a reboot? Manually? -Oorspronkelijk bericht- Van: David Gwynne Aan: pas...@pascallen.nl Cc: misc@openbsd.org Onderwerp: Re: Home Assistant Datum: Mon, 10 May 2021 19:31:50 +1000 E-mailprogramma: Mutt/1.12.2 (2019-09-21) ive been running hass on openbsd for a while now, and just did a newinstall on 6.9 for my boss on the weekend. i set up a _hass user for it to run as, and gave it /opt/hass: hass$ getent passwd _hass_hass:*:2000:2000:Home Assistant:/opt/hass:/sbin/nologinhass$ getent group 2000_hass:*:2000hass$ ls -ld /opt/hassdrwxr-xr-x 8 _hass _hass 512 May 8 22:35 /opt/hass i installed mosquitto, python3.8, py3-virtualenv, py3-pip,py3- cryptography, py3-Pillow, and py3-zeroconf from ports. thenas the _hass users i set up a venv in /opt/hass with virtualenv--system-site- packages /opt/hass, did the . /opt/hass/bin/activatething, then ran pip install homeassistant. that got me far enough stuff to be able to start home assistant. you'reon your own after this. good luck. dlg On Sat, May 08, 2021 at 06:53:54PM +0200, pas...@pascallen.nl wrote: > Dear all, > What would be the best way to install HASS on Openbsd?Containers are > a nogo? > Run it in virtual env from python? > Any Howto on the subject with Openbsd? > > Currently I got it running as from the website with the "core" > version.But a startup script which runs with a non-root user is where > I getstuck. > > > > -- Met vriendelijke groet, > Pascal Huisman > > Fundamentally, there may be no basis for anything. -- Met vriendelijke groet, Pascal Huisman Elbonics, n.: The actions of two people maneuvering for one armrest in a movie theatre. -- "Sniglets", Rich Hall & Friends signature.asc Description: This is a digitally signed message part
Re: aggr not load balancing
> > On Apr 29, 2021, at 9:13 AM, Steven Surdock > > wrote: > > > > I switched from trunk to aggr on a "OpenBSD 6.8 GENERIC.MP#5 amd64" and it > > isn't load balancing across the two configured links. The remote side is a > > Cisco ASR9k with the same configuration. Is that expected? > > > > > > Hi, try 6.9. There is a bugfix to pf that I found also corrects load > balancing with aggr. > > > Brian Upgrading to 6.9 did resolve the outbound load balancing issue (OBSD --> Switch), but then broke inbound (switch --> OBSD) load balancing. I suspect this is just a load balancing algorithm setting in the ASR9k as the LAG is build on a l2 interface and not a routed interface.
Re: NAT on same interface as vlan on OpenBSD 6.8
On Mon, May 10, 2021 at 5:26 AM Dirk Coetzee wrote:
> I am hoping to create a pf.conf configuration that has VLAN’s and NAT via
> the same (physical) interface. The hardware is only capable of having a
> single Ethernet interface.
>
> vlan100 is an isolated network to setup servers and is connected to a
> switch that is setup for vlan100 and vlan 1. The same interface has the
> main internal IP address 192.168.10.241 ("vlan 1" / no vlan). Devices
> behind vlan100 network need to be NAT’ed behind the internal / corporate
> interface 192.168.10.241, so that they can still have internet access -
> without affecting the main / corporate network.
>
> pass out quick log on $int_if
> match out on $int_if inet from $vl100_net to any nat-to $int_ip source-hash
>
I believe your issue is that the "pass out quick" takes effect immediately
and rules that come later aren't checked. Either remove the 'quick' or
move the 'match out' NAT rule so that it's above the 'pass out quick'.
Some people don't like to use 'quick' because it makes "last match"
semantics hard to follow (it's an exception to keep track of if most of
your ruleset is structured for 'last match wins'). I prefer to use 'quick'
on almost all of my rules to get "first match" semantics because I find
'first match wins' easier to work with (it means that the remainder of the
ruleset after a matching 'pass' is irrelevant and need not be examined).
It is purely personal preference on whether you prefer to read your rules
from the bottom up or the top down. If you want to continue to use 'quick'
the most expedient fix is to move the 'match out' so that it comes before
your first 'pass out' rule.
-ken
Re: DHCPd - option capwap (code 138)
Thank you Denis,Stu,
I added option-138, the syntax is correct now but the AP doesn't connect to the
Controller.
Did I missed any other option(s) in my dhcpd.conf or should I look for the
reason at the Controller side?
subnet 10.109.3.0 netmask 255.255.255.0 {
option routers 10.109.3.254;
range 10.109.3.201 10.109.3.220;
#option option-138 10.109.3.100;
option option-138 A:6D:3:64;
host [...]
On Thu, 6 May 2021 11:45:43 +0200
Denis Fondras wrote:
> Le Thu, May 06, 2021 at 10:48:55AM +0200, Radek a écrit :
> > Hello,
> > I want to use dhcpd server to push Wireless Controller's IP address to the
> > APs.
> >
> > According to this:
> > http://systemnetworksecurity.blogspot.com/2013/02/adding-custom-options-in-isc-dhcpds.html
> > https://www.secuvera.de/blog/capwap-dhcp-option-138-auf-isc-dhcpd-server-einrichten/
> > I need to add *option capwap* to /etc/dhcpd.conf
> >
> > option capwap code 138 = ip-address; #Custom Option capwap
> > option capwap 192.168.1.110; #WLAN-Controller-IP
> >
>
> Have you tried something like :
>
> option option-138 C0:A8:01:6E;
>
> ?
>
--
Radek
Re: pf ipv6 source-routing 6.9
Le lundi 10 mai 2021 à 22:51 +1000, David Gwynne a écrit : > > > > On 10 May 2021, at 8:05 pm, Bastien Durel > > wrote: > > > > Le samedi 08 mai 2021 à 12:07 +0200, Bastien Durel a écrit : > > > Le 08/05/2021 à 11:56, Stuart Henderson a écrit : > > > > > > Does it work if you use the syntax suggested in the upgrade > > > > > > notes > > > > > > for the example with "pass in on pppoe1 reply-to ..."? > > > > > > > > > > > > > > > > > For incoming connections, I tried > > > > > > > > > > pass in on pppoe0 inet6 reply-to > > > > > fe80::520f:80ff:fe65:8800%pppoe0 > > > > > keep state > > > > > pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800 > > > > > keep > > > > > state > > > > Hello, > > > > Thanks to folks of #openbsd, I found out adding an explicit route > > to > > fe80::520f:80ff:fe65:8800 on pppoe0 make this work. > > Referencing fe80::520f:80ff:fe65:8800%pppoe0 in pf.conf results in > > a > > rule referencing fe80::520f:80ff:fe65:8800 > > > > pf.conf: > > pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0 > > pfctl -s rules: > > pass in on pppoe0 inet6 all flags S/SA reply-to > > fe80::520f:80ff:fe65:8800 > > > > hostname.pppoe0: > > !/sbin/route add -inet6 fe80::520f:80ff:fe65:8800 -ifp pppoe0 > > fe80::%pppoe0 > > > > This make pf able to route to the correct interface. > > You're right, pf isn't very good at handling link-local v6 addresses. > This is annoying now that route-to uses addresses as it's argument if > you want to move ipv6 packets toward a host with a link local > address. > > In this situation the least worst way to cope with the problem for > now is to use route-to (pppoe0:0). This should work because route-to > doesn't do any local address checks on the destination address it > resolves. Once it looks up the local address as the direction to send > the packet, it should put it straight out pppoe0. ppp as a tunnel > interface has no address resolution protocol, it just encapsulates > the packet it is given and sends it on its way. > > route-to also takes a destination address as an argument, not a > gateway address. If dhcp6c sets up a route to some global address > that you know about (I'm not sure this is a thing but it might be), > you can use that global address as the argument to route-to and it > will send it in the right direction. > Hello. Thanks for the hint, but (pppoe0:0) does not work : pf.conf:266: route spec requires :peer with dynamic interface addresses (pppoe0:peer) make pf happy, but does not route anything (ifconfig does not show any peer on inet6) dhcp6c does not sets any route by its own, it only returns some DNS resolver addresses, and registers the prefixes the ISP delegates. Regards, -- Bastien
Re: pf ipv6 source-routing 6.9
> On 10 May 2021, at 8:05 pm, Bastien Durel wrote: > > Le samedi 08 mai 2021 à 12:07 +0200, Bastien Durel a écrit : >> Le 08/05/2021 à 11:56, Stuart Henderson a écrit : > Does it work if you use the syntax suggested in the upgrade > notes > for the example with "pass in on pppoe1 reply-to ..."? > > For incoming connections, I tried pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0 keep state pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800 keep state > > Hello, > > Thanks to folks of #openbsd, I found out adding an explicit route to > fe80::520f:80ff:fe65:8800 on pppoe0 make this work. > Referencing fe80::520f:80ff:fe65:8800%pppoe0 in pf.conf results in a > rule referencing fe80::520f:80ff:fe65:8800 > > pf.conf: > pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0 > pfctl -s rules: > pass in on pppoe0 inet6 all flags S/SA reply-to fe80::520f:80ff:fe65:8800 > > hostname.pppoe0: > !/sbin/route add -inet6 fe80::520f:80ff:fe65:8800 -ifp pppoe0 fe80::%pppoe0 > > This make pf able to route to the correct interface. You're right, pf isn't very good at handling link-local v6 addresses. This is annoying now that route-to uses addresses as it's argument if you want to move ipv6 packets toward a host with a link local address. In this situation the least worst way to cope with the problem for now is to use route-to (pppoe0:0). This should work because route-to doesn't do any local address checks on the destination address it resolves. Once it looks up the local address as the direction to send the packet, it should put it straight out pppoe0. ppp as a tunnel interface has no address resolution protocol, it just encapsulates the packet it is given and sends it on its way. route-to also takes a destination address as an argument, not a gateway address. If dhcp6c sets up a route to some global address that you know about (I'm not sure this is a thing but it might be), you can use that global address as the argument to route-to and it will send it in the right direction. dlg > Regards, > > -- > Bastien >
Re: virtual cluster with rdomain(4)
On Mon, May 10, 2021 at 02:07:59PM +0200, Thomas Huber wrote: > Hi David, > > thanks for your input. > > And how would you do it? Just like I described. > Also putting each vport(4) in its own rdomain(4) and veb(4) takes care of > Layer2 connectivity without any pf(4) involvment? Yes. Two things to remember. Firstly, vport(4) interfaces are handled specially by veb(4) and get treated by the IP stack like a physical interface connected to a real switch. This is different to when you add a non-vport interface to a veb, because in that situation veb steals the interface and it is only used to move layer 2 packets between the veb and the wire. Secondly, veb does not run pf on packets traversing the virtual bridge by default. However, vport interfaces are excepted from this policy because of the thing above. This means pf will run on vport interfaces all the time, but veb is the thing that moves the packets between the vports. Both of these together mean that if you do something like this: ifconfig veb0 create jot 5 | while read i; do ifconfig lo$i create ifconfig lo$i rdomain $i ifconfig lo$i inet 127.0.0.1/8 ifconfig vport$i create ifconfig vport$i rdomain $i ifconfig vport$i inet 192.168.0.$i/24 ifconfig veb0 add vport$i ifconfig lo$i up ifconfig vport$i up done ifconfig veb0 up Which looks like this: ix# pfctl -sr block return all block drop quick proto udp from any to any port = 9 pass all flags S/SA block return in on ! lo0 proto tcp from any to any port 6000:6010 block return out log proto tcp all user = 55 block return out log proto udp all user = 55 ix# ifconfig veb0 veb0: flags=8843 index 13 llprio 3 groups: veb vport1 flags=3 port 15 ifpriority 0 ifcost 0 vport2 flags=3 port 17 ifpriority 0 ifcost 0 vport3 flags=3 port 19 ifpriority 0 ifcost 0 vport4 flags=3 port 21 ifpriority 0 ifcost 0 vport5 flags=3 port 23 ifpriority 0 ifcost 0 Addresses (max cache: 100, timeout: 240): ix# ifconfig vport vport1: flags=8943 rdomain 1 mtu 1500 lladdr fe:e1:ba:d2:4a:be index 15 priority 0 llprio 3 groups: vport inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255 vport2: flags=8943 rdomain 2 mtu 1500 lladdr fe:e1:ba:d3:17:a0 index 17 priority 0 llprio 3 groups: vport inet 192.168.0.2 netmask 0xff00 broadcast 192.168.0.255 vport3: flags=8943 rdomain 3 mtu 1500 lladdr fe:e1:ba:d4:f1:a9 index 19 priority 0 llprio 3 groups: vport inet 192.168.0.3 netmask 0xff00 broadcast 192.168.0.255 vport4: flags=8943 rdomain 4 mtu 1500 lladdr fe:e1:ba:d5:a8:78 index 21 priority 0 llprio 3 groups: vport inet 192.168.0.4 netmask 0xff00 broadcast 192.168.0.255 vport5: flags=8943 rdomain 5 mtu 1500 lladdr fe:e1:ba:d6:cd:44 index 23 priority 0 llprio 3 groups: vport inet 192.168.0.5 netmask 0xff00 broadcast 192.168.0.255 ix# route -T1 exec ping 192.168.0.2 PING 192.168.0.2 (192.168.0.2): 56 data bytes 64 bytes from 192.168.0.2: icmp_seq=0 ttl=255 time=0.269 ms 64 bytes from 192.168.0.2: icmp_seq=1 ttl=255 time=0.142 ms 64 bytes from 192.168.0.2: icmp_seq=2 ttl=255 time=0.173 ms ^C --- 192.168.0.2 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.142/0.195/0.269/0.054 ms ix# jot 5 | while read i; do route -T$i exec arp -na; done Host Ethernet AddressNetif ExpireFlags 192.168.0.1 fe:e1:ba:d2:4a:be vport1 permanent l 192.168.0.2 fe:e1:ba:d3:17:a0 vport1 13m30s Host Ethernet AddressNetif ExpireFlags 192.168.0.1 fe:e1:ba:d2:4a:be vport2 13m30s 192.168.0.2 fe:e1:ba:d3:17:a0 vport2 permanent l Host Ethernet AddressNetif ExpireFlags 192.168.0.3 fe:e1:ba:d4:f1:a9 vport3 permanent l Host Ethernet AddressNetif ExpireFlags 192.168.0.4 fe:e1:ba:d5:a8:78 vport4 permanent l Host Ethernet AddressNetif ExpireFlags 192.168.0.5 fe:e1:ba:d6:cd:44 vport5 permanent l ix# ifconfig veb0 veb0: flags=8843 index 13 llprio 3 groups: veb vport1 flags=3 port 15 ifpriority 0 ifcost 0 vport2 flags=3 port 17 ifpriority 0 ifcost 0 vport3 flags=3 port 19 ifpriority 0 ifcost 0 vport4 flags=3 port 21 ifpriority 0 ifcost 0 vport5 flags=3 port 23 ifpriority 0 ifcost 0 Addresses (max cache: 100, timeout: 240)
Re: virtual cluster with rdomain(4)
Hi David, thanks for your input. And how would you do it? Also putting each vport(4) in its own rdomain(4) and veb(4) takes care of Layer2 connectivity without any pf(4) involvment? thanks Thomas On Mon, 10 May 2021 at 08:10, David Gwynne wrote: > > Hi Thomas, > > I'd give this a go with vport(4) interfaces instead of vether(4), and join them all together at layer 2 by adding them to a single veb(4). > > Cheers, > dlg > > > On 10 May 2021, at 03:04, Thomas Huber wrote: > > > > Hi misc, > > > > I wanted to tinker with the cluster manager sysutils/nomad but > > unfortunately I´ve no spare cluster for tinkering... > > > > So I had the idea of utilizing OpenBSDs outstanding > > possibilities for network isolation to create a > > virtual cluster on my VM at openbsd.amsterdam. > > > > I had different ideas to achieve it but nothing worked so far. > > So I'd describe my first approach because I think this is the > > most OpenBSD idiomatic one: > > > > I created 5 vether[0-4] devices, everyone in its own rdomain [0-4] > > and assigned every device its own inet address space 10.10.[0-4].1/24 > > > > I also set the 10.10.[0-4].1 as default route in each rtable. > > > > Now I learned that pf(4) is needed to route between this 5 rdomains > > but after several attempts I've no clue how this could be defined. > > > > Actually I wanted rdomain 0 to work as hub for all rdomains >0. > > Maybe someone can hint me in the right direction > > > > regards > > Thomas (host of the u2k20-hackathon, if someone remembers ;-) > > > > some further listings if my description above is unclear: > > > > > > ud$ ifconfig vether > > vether0: flags=8843 mtu 1500 > > lladdr fe:e1:ba:d7:cc:16 > > index 23 priority 0 llprio 3 > > groups: vether > > media: Ethernet autoselect > > status: active > > inet 10.10.0.1 netmask 0xff00 broadcast 10.255.255.255 > > > > vether1: flags=8843 rdomain 1 mtu > > 1500 > > lladdr fe:e1:ba:d8:73:32 > > index 24 priority 0 llprio 3 > > groups: vether > > media: Ethernet autoselect > > status: active > > inet 10.10.1.1 netmask 0xff00 broadcast 10.255.255.255 > > > > vether2: flags=8843 rdomain 2 mtu > > 1500 > > lladdr fe:e1:ba:d9:bd:e8 > > index 26 priority 0 llprio 3 > > groups: vether > > media: Ethernet autoselect > > status: active > > inet 10.10.2.1 netmask 0xff00 broadcast 10.255.255.255 > > > > vether3: flags=8843 rdomain 3 mtu > > 1500 > > lladdr fe:e1:ba:da:07:4d > > index 28 priority 0 llprio 3 > > groups: vether > > media: Ethernet autoselect > > status: active > > inet 10.10.3.1 netmask 0xff00 broadcast 10.255.255.255 > > > > vether4: flags=8843 rdomain 4 mtu > > 1500 > > lladdr fe:e1:ba:db:31:c8 > > index 30 priority 0 llprio 3 > > groups: vether > > media: Ethernet autoselect > > status: active > > inet 10.10.4.1 netmask 0xff00 broadcast 10.255.255.255 > > > > ud$ netstat -R > > Rdomain 0 > > Interfaces: lo0 vio0 enc0 pflog0 vether0 > > Routing tables: 0 71 > > > > Rdomain 1 > > Interfaces: vether1 lo1 > > Routing table: 1 > > > > Rdomain 2 > > Interfaces: vether2 lo2 > > Routing table: 2 > > > > Rdomain 3 > > Interfaces: vether3 lo3 > > Routing table: 3 > > > > Rdomain 4 > > Interfaces: vether4 lo4 > > Routing table: 4
Re: openssl cms -encrypt does not work with EC key/cert
On Sat, May 08, 2021 at 01:50:24PM -, Stuart Henderson wrote:
> On 2021-05-08, Theodore Wynnychenko wrote:
> >
> > Hello again:
> >
> > I am re-posting this message with additional information..
> > While I have no expectation that there will be any reply, I am hopeful there
> > may be.
>
> Confirmed, and it also fails with OpenSSL 1.0.2u, but succeeds with
> 1.1.1k. I think perhaps this is just something that has been added
> to newer OpenSSL but not added to LibreSSL yet.
Hi,
I had investigated this and found some missing bits.
I believe this diff would solve your issue.
Can you check this if your problem has gone ?
Index: obj_xref.txt
===
RCS file: /cvs/src/lib/libcrypto/objects/obj_xref.txt,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 obj_xref.txt
--- obj_xref.txt9 Nov 2014 19:17:13 - 1.2
+++ obj_xref.txt8 May 2021 13:26:38 -
@@ -46,3 +46,16 @@ id_GostR3411_94_with_GostR3410_94_cc id_
id_GostR3411_94_with_GostR3410_2001_cc id_GostR3411_94 id_GostR3410_2001_cc
id_tc26_signwithdigest_gost3410_2012_256 id_tc26_gost3411_2012_256
id_tc26_gost3410_2012_256
id_tc26_signwithdigest_gost3410_2012_512 id_tc26_gost3411_2012_512
id_tc26_gost3410_2012_512
+
+# ECDH KDFs and their corresponding message digests and schemes
+dhSinglePass_stdDH_sha1kdf_scheme sha1dh_std_kdf
+dhSinglePass_stdDH_sha224kdf_schemesha224 dh_std_kdf
+dhSinglePass_stdDH_sha256kdf_schemesha256 dh_std_kdf
+dhSinglePass_stdDH_sha384kdf_schemesha384 dh_std_kdf
+dhSinglePass_stdDH_sha512kdf_schemesha512 dh_std_kdf
+
+dhSinglePass_cofactorDH_sha1kdf_scheme sha1dh_cofactor_kdf
+dhSinglePass_cofactorDH_sha224kdf_scheme sha224 dh_cofactor_kdf
+dhSinglePass_cofactorDH_sha256kdf_scheme sha256 dh_cofactor_kdf
+dhSinglePass_cofactorDH_sha384kdf_scheme sha384 dh_cofactor_kdf
+dhSinglePass_cofactorDH_sha512kdf_scheme sha512 dh_cofactor_kdf
Index: obj_xref.h
===
RCS file: /cvs/src/lib/libcrypto/objects/obj_xref.h,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 obj_xref.h
--- obj_xref.h 21 Dec 2016 15:49:29 - 1.4
+++ obj_xref.h 8 May 2021 13:26:38 -
@@ -44,6 +44,16 @@ static const nid_triple sigoid_srt[] =
{NID_rsassaPss, NID_undef, NID_rsaEncryption},
{NID_id_tc26_signwithdigest_gost3410_2012_256,
NID_id_tc26_gost3411_2012_256, NID_id_GostR3410_2001},
{NID_id_tc26_signwithdigest_gost3410_2012_512,
NID_id_tc26_gost3411_2012_512, NID_id_GostR3410_2001},
+ {NID_dhSinglePass_stdDH_sha1kdf_scheme, NID_sha1, NID_dh_std_kdf},
+ {NID_dhSinglePass_stdDH_sha224kdf_scheme, NID_sha224, NID_dh_std_kdf},
+ {NID_dhSinglePass_stdDH_sha256kdf_scheme, NID_sha256, NID_dh_std_kdf},
+ {NID_dhSinglePass_stdDH_sha384kdf_scheme, NID_sha384, NID_dh_std_kdf},
+ {NID_dhSinglePass_stdDH_sha512kdf_scheme, NID_sha512, NID_dh_std_kdf},
+ {NID_dhSinglePass_cofactorDH_sha1kdf_scheme, NID_sha1,
NID_dh_cofactor_kdf},
+ {NID_dhSinglePass_cofactorDH_sha224kdf_scheme, NID_sha224,
NID_dh_cofactor_kdf},
+ {NID_dhSinglePass_cofactorDH_sha256kdf_scheme, NID_sha256,
NID_dh_cofactor_kdf},
+ {NID_dhSinglePass_cofactorDH_sha384kdf_scheme, NID_sha384,
NID_dh_cofactor_kdf},
+ {NID_dhSinglePass_cofactorDH_sha512kdf_scheme, NID_sha512,
NID_dh_cofactor_kdf},
};
static const nid_triple * const sigoid_srt_xref[] =
@@ -61,19 +71,29 @@ static const nid_triple * const sigoid_s
&sigoid_srt[5],
&sigoid_srt[8],
&sigoid_srt[12],
+ &sigoid_srt[32],
+ &sigoid_srt[37],
&sigoid_srt[6],
&sigoid_srt[10],
&sigoid_srt[11],
&sigoid_srt[13],
&sigoid_srt[24],
&sigoid_srt[20],
+ &sigoid_srt[34],
+ &sigoid_srt[39],
&sigoid_srt[14],
&sigoid_srt[21],
+ &sigoid_srt[35],
+ &sigoid_srt[40],
&sigoid_srt[15],
&sigoid_srt[22],
+ &sigoid_srt[36],
+ &sigoid_srt[41],
&sigoid_srt[16],
&sigoid_srt[23],
&sigoid_srt[19],
+ &sigoid_srt[33],
+ &sigoid_srt[38],
&sigoid_srt[25],
&sigoid_srt[26],
&sigoid_srt[27],
Re: isakmpd ignoring authentication metod
Thanks Stuart for the answer the new flags don't change the log output. While with tcpdump I can see that the other endpoint is sending correct ipsec parameters: 12:49:08.025601 *.fastwebnet.it.isakmp > *.it.isakmp: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: db2bb04573305edb-> msgid: len: 200 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 32 transform: 1 ID: ISAKMP attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 28800 attribute ENCRYPTION_ALGORITHM = 3DES_CBC attribute AUTHENTICATION_METHOD = PRE_SHARED attribute HASH_ALGORITHM = SHA2_256 attribute GROUP_DESCRIPTION = MODP_1024 payload: VENDOR len: 20 (supports NAT-T, RFC 3947) payload: VENDOR len: 20 (supports v3 NAT-T, draft-ietf-ipsec-nat-t-ike-03) payload: VENDOR len: 20 (supports v2 NAT-T, draft-ietf-ipsec-nat-t-ike-02\n) payload: VENDOR len: 20 (supports v2 NAT-T, draft-ietf-ipsec-nat-t-ike-02) payload: VENDOR len: 20 (supports DPD v1.0) payload: VENDOR len: 20 (DF) (ttl 52, id 41086, len 228) ipsec -vnf /etc/ipsec.conf C add [phase1-peer-*]:Transforms=phase1-transform-peer-*-PRE_SHARED-SHA2_256-3DES-MODP_1024 force C set [phase1-transform-peer-*-PRE_SHARED-SHA2_256-3DES-MODP_1024]:AUTHENTICATION_METHOD=PRE_SHARED force C set [phase1-transform-peer-*-PRE_SHARED-SHA2_256-3DES-MODP_1024]:HASH_ALGORITHM=SHA2_256 force C set [phase1-transform-peer-*-PRE_SHARED-SHA2_256-3DES-MODP_1024]:ENCRYPTION_ALGORITHM=3DES_CBC force C set [phase1-transform-peer-*-PRE_SHARED-SHA2_256-3DES-MODP_1024]:GROUP_DESCRIPTION=MODP_1024 force C set [phase1-transform-peer-*-PRE_SHARED-SHA2_256-3DES-MODP_1024]:Life=phase1-transform-peer-*-PRE_SHARED-SHA2_256-3DES-MODP_1024-life force C set [phase1-transform-peer-*-PRE_SHARED-SHA2_256-3DES-MODP_1024-life]:LIFE_TYPE=SECONDS force C set [phase1-transform-peer-*-PRE_SHARED-SHA2_256-3DES-MODP_1024-life]:LIFE_DURATION=28800 force .. Giacomo > On 5 May 2021, at 14:33, Stuart Henderson wrote: > > On 2021-05-04, Giacomo Marconi wrote: >> Hi all >> >> I have some openbsd boxes as vpn endpoint to a Palo Alto Pa-820. >> >> In my last VPN config (unsing 6.8) I see in the logs that isakmpd is >> expexting RSA_SIG as authentication method, while in ipsec.conf I set the >> psk value. > > This usually means that the packets seen from the other side didn't > match your configuration (possibly a wrong IP or something) and > instead were matched by the implicit default phase 1 configuration > (which is 3DES-SHA-RSA_SIG) > > If that doesn't give any clues, bump up logging in isakmpd. This > set of debug levels (worked out by studying source code) enables > most logs that are possible to do without being so noisy that > they're useless. > > isakmpd_flags="-Kv -D0=29 -D1=49 -D2=10 -D3=30 -D5=20 -D6=30 -D8=30 -D9=30 > -D10=20" > > Sometimes looking at captured packets is useful too. For phase 1 > negotiation then just watching the network interface is usually > good > > tcpdump -vvs1500 -i $interface port 500 or 4500 > > (For problems with phase 2 nego you often need to enable isakmpd's > cleartext IKE packet capture via the isakmpd.fifo control socket > but you aren't that far). > > > > >
Re: pf ipv6 source-routing 6.9
On Mon, May 10, 2021 at 12:05:16PM +0200, Bastien Durel wrote: > Referencing fe80::520f:80ff:fe65:8800%pppoe0 in pf.conf results in a > rule referencing fe80::520f:80ff:fe65:8800 I'm not sure where the scope id gets stripped, but the above may simply be a misleading cosmetic issue. pfctl -sr uses inet_ntop() to convert the address into printable format. It looks like this would never print the scope id (the %pppoe0 part of the address). The 'route get' command uses getnameinfo() instead, and getnameinfo() has special handling for the scope_id which inet_ntop() lacks. Someone would need to debug this to see if the scope id is present in the binary representation of the rule's address, or if the scope id was dropped somewhere on the way from pf.conf to the output of pfctl -sr. > pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0 Rergardless, I would expect the above rule to work without an extra entry in the routing table. Out of the box 'route get' displays the correct route. Try: route get fe80::520f:80ff:fe65:8800%pppoe0 On my system this correctly identifies the outgoing interface as pppoe0. And I have *not* done what you did below: > hostname.pppoe0: > !/sbin/route add -inet6 fe80::520f:80ff:fe65:8800 -ifp pppoe0 fe80::%pppoe0 > > This make pf able to route to the correct interface. In my opinion having to add an extra route for this is a bug. But I have no idea where :)
Re: pf ipv6 source-routing 6.9
Le samedi 08 mai 2021 à 12:07 +0200, Bastien Durel a écrit : > Le 08/05/2021 à 11:56, Stuart Henderson a écrit : > > > > Does it work if you use the syntax suggested in the upgrade > > > > notes > > > > for the example with "pass in on pppoe1 reply-to ..."? > > > > > > > > > > > For incoming connections, I tried > > > > > > pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0 > > > keep state > > > pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800 keep > > > state Hello, Thanks to folks of #openbsd, I found out adding an explicit route to fe80::520f:80ff:fe65:8800 on pppoe0 make this work. Referencing fe80::520f:80ff:fe65:8800%pppoe0 in pf.conf results in a rule referencing fe80::520f:80ff:fe65:8800 pf.conf: pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0 pfctl -s rules: pass in on pppoe0 inet6 all flags S/SA reply-to fe80::520f:80ff:fe65:8800 hostname.pppoe0: !/sbin/route add -inet6 fe80::520f:80ff:fe65:8800 -ifp pppoe0 fe80::%pppoe0 This make pf able to route to the correct interface. Regards, -- Bastien
Re: Home Assistant
ive been running hass on openbsd for a while now, and just did a new install on 6.9 for my boss on the weekend. i set up a _hass user for it to run as, and gave it /opt/hass: hass$ getent passwd _hass _hass:*:2000:2000:Home Assistant:/opt/hass:/sbin/nologin hass$ getent group 2000 _hass:*:2000 hass$ ls -ld /opt/hass drwxr-xr-x 8 _hass _hass 512 May 8 22:35 /opt/hass i installed mosquitto, python3.8, py3-virtualenv, py3-pip, py3-cryptography, py3-Pillow, and py3-zeroconf from ports. then as the _hass users i set up a venv in /opt/hass with virtualenv --system-site-packages /opt/hass, did the . /opt/hass/bin/activate thing, then ran pip install homeassistant. that got me far enough stuff to be able to start home assistant. you're on your own after this. good luck. dlg On Sat, May 08, 2021 at 06:53:54PM +0200, pas...@pascallen.nl wrote: > Dear all, > > What would be the best way to install HASS on Openbsd? > Containers are a nogo? > > Run it in virtual env from python? > > Any Howto on the subject with Openbsd? > > > Currently I got it running as from the website with the "core" version. > But a startup script which runs with a non-root user is where I get > stuck. > > > > > -- > Met vriendelijke groet, > > Pascal Huisman > > > Fundamentally, there may be no basis for anything. >
NAT on same interface as vlan on OpenBSD 6.8
Hi All,
I am hoping to create a pf.conf configuration that has VLAN’s and NAT via the
same (physical) interface. The hardware is only capable of having a single
Ethernet interface.
vlan100 is an isolated network to setup servers and is connected to a switch
that is setup for vlan100 and vlan 1. The same interface has the main internal
IP address 192.168.10.241 ("vlan 1" / no vlan). Devices behind vlan100 network
need to be NAT’ed behind the internal / corporate interface 192.168.10.241, so
that they can still have internet access - without affecting the main /
corporate network.
When attempting to do this with either:
match out on $int_if inet from $vl100_net to any nat-to $int_ip
source-hash
-or-
pass out quick log on $int_if inet from $vl100_net to any nat-to
$int_ip
I see the traffic exiting re0 (default vlan1) interface with the same IP
address as before on vlan100 (i.e. no NAT happened).
When troubleshooting I see the below error in dmesg:
arp: attempt to overwrite entry for 192.168.10.1 on re0 by
7c:5a:1c:74:4f:46 on vlan100
Although I am not super sure that is related. There are thousands of them
though.
Is there a way to have both vlan100 and NAT all on the same interface as my
usual default network interface?
To make sure I am testing the pf configuration correctly on the proxy/firewall,
I execute:
doas ping -I 192.168.100.1 9.9.9.9
and also execute tcpdump at the same time (output below). No NAT is being
observed for 192.168.100.1 (no ICMP replies). Interestingly replies are seen at
192.168.10.241 - but not passed to 192.168.100.1.
Kind Regards
dirk
tetraodontidae# ifconfig
lo0: flags=8049 mtu 32768
index 3 priority 0 llprio 3
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff00
re0: flags=8b43 mtu
1500
lladdr 8c:89:a5:ed:5c:0e
index 1 priority 0 llprio 3
groups: if_host egress
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
inet 192.168.10.241 netmask 0xff00 broadcast 192.168.10.255
enc0: flags=0<>
index 2 priority 0 llprio 3
groups: enc
status: active
vlan100: flags=8843 mtu 1500
lladdr 8c:89:a5:ed:5c:0e
index 5 priority 0 llprio 3
encap: vnetid 100 parent re0 txprio packet rxprio outer
groups: vlan igrp_vlanif
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
inet 192.168.100.1 netmask 0xff00 broadcast 192.168.100.255
tetraodontidae# cat hostname.re0
inet 192.168.10.241 255.255.255.0 192.168.10.255
tetraodontidae# cat hostname.vlan100
vnetid 100 parent re0
inet 192.168.100.1 255.255.255.0 192.168.100.255 vlan 100 vlandev re0
up
### Description
### VLAN100 = setup firewalls
tetraodontidae# cat pf.conf
# $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf
set skip on { lo0 pflog0 }
set reassemble yes
set ruleset-optimization none
set block-policy drop
set state-policy if-bound
#block return # block stateless traffic
#block drop log # block stateless traffic
# ---=== Macros ===---
squidclient_ips = "{ 192.168.10.0/24 }"
syslogclient_ips = "{ 192.168.10.0/24, 192.168.20.0/24, 192.168.12.0/24 }"
table persist file "/etc/pf.files/blockedhostileips.txt"
table persist file "/etc/pf.files/bruteforcers.txt"
int_if= "{ re0 }"
int_ip= "{ re0:0 }"
int_net =re0:network
vl100_if= "{ vlan100 }"
vl100_ip= "{ vlan100:0 }"
vl100_net =vlan100:network
# By default, do not permit remote connections to X11
block return in on ! lo0 proto tcp to port 6000:6010
# Port build user does not need network
block return out log proto {tcp udp} user _pbuild
# ---=== Outbound from proxy ===---
antispoof quick for lo0
antispoof quick for re0
antispoof quick for vlan100
pass out quick log on $int_if
pass out quick log on $vl100_if
# ---=== NAT from VLAN 100 Outbound ===---
# match out on re0 inet proto { tcp udp icmp } from $vl100_net to any nat-to
$re0_ip source-hash
match out on $int_if inet from $vl100_net to any nat-to $int_ip source-hash
match in all scrub (no-df random-id)
# ---=== Inbound from re0 ===---
block in quick log from label "Blocked_Hostile_IPs"
block out quick log to label "Blocked_Hostile_IPs"
pass in quick log on $vl100_if inet from $vl100_net to any
## pass out quick log on $int_if inet from $vl100_net to any nat-to
Re: Disable Unveil
On Mon, May 10, 2021 at 02:02:30AM -0600, Jonathan Drews wrote: > Hello Folks: > > I am using OpenBSD 6.9 GENERIC.MP#473 amd64 Hi Guys: Disregard the first email. I ran firefox as an ordinary user with the url http://localhost:631 and I was able to upload the *.ppd from my ~/Downloads > I need to disable unveil so I can load files into Firefox from > other directories. I also cannot load my *.ppd when using my > webbrowser in root. In the past, I have configured CUPS with the > URL http://localhost:631. I need to be able to upload my *.ppd as > my laser printer is not in the list of Xerox printers . I used > this method in OpenBSD 6.8 and it worked fine. > > I read the man page for unveil but it only gives programming > instructions. How can I disable unveil? > > > Kind regards, > Jonathan >
Re: Disable Unveil
Jonathan Drews writes: > Hello Folks: > > I am using OpenBSD 6.9 GENERIC.MP#473 amd64 > > I need to disable unveil so I can load files into Firefox from > other directories. I also cannot load my *.ppd when using my > webbrowser in root. In the past, I have configured CUPS with the > URL http://localhost:631. I need to be able to upload my *.ppd as > my laser printer is not in the list of Xerox printers . I used > this method in OpenBSD 6.8 and it worked fine. > > I read the man page for unveil but it only gives programming > instructions. How can I disable unveil? > > > Kind regards, > Jonathan The manpage for unveil only describes how to use it from code, not how other programs are using it. For firefox, see /usr/local/share/doc/pkg-readmes/firefox. Anyway, disabling unveil is a bad idea, especially for a program like a web browser that reads and executes random code downloaded from the network. Probably, adjusting /etc/firefox/unveil.main to add things like ~/Document is enough for your use-case. HTH Omar Polo,
Disable Unveil
Hello Folks: I am using OpenBSD 6.9 GENERIC.MP#473 amd64 I need to disable unveil so I can load files into Firefox from other directories. I also cannot load my *.ppd when using my webbrowser in root. In the past, I have configured CUPS with the URL http://localhost:631. I need to be able to upload my *.ppd as my laser printer is not in the list of Xerox printers . I used this method in OpenBSD 6.8 and it worked fine. I read the man page for unveil but it only gives programming instructions. How can I disable unveil? Kind regards, Jonathan
