Re: pfctl interprets "# ... \" as multi-line comment and can skip rules
I use the following script to reload pf rules. It allows me to check that what I wrote was interpreted as I intended: #!/bin/sh test "$(id -u)" -eq 0 || exec sudo -- "$0" "$@" old=$(mktemp /tmp/pf-reload.) || exit trap "rm $old" EXIT pfctl -sr > $old || exit pfctl -f /etc/pf.conf; rc=$? test $rc -eq 0 && pfctl -sr | diff -U2 -L "old ruleset" -L /etc/pf.conf $old - exit $rc On Sat, Jan 16, 2016 at 12:31 AM, Adam McDougall wrote: > I've been using pf for years and really like it. I accidentally discovered > some undesirable behavior from the rule parser that caused some rules to be > skipped. This has happened to me twice and there was much hair pulling.
Re: [patch] fake pv drivers installation on xen
On Wed, Jan 18, 2017 at 2:16 PM, Dinar Talypov wrote: > I use Xenserver 7.0 with xencenter management console. > without it doesn't allow shutdown or reboot. > Anyway I'll try with hostctl. > > Thanks. Were you able to get this working with hostctl? I'm running OpenBSD 6.1 amd64 on XenServer 7.0. When I run any hostctl command, such as `hostctl device/vif/0/mac`, I get the following error: hostctl: ioctl: Device not configured During boot, I see these messages: pvbus0 at mainbus0: Hyper-V 0.0, Xen 4.6 xen0 at pvbus0: features 0x2705, 32 grant table frames, event channel 3 xbf0 at xen0 backend 0 channel 8: disk Running `hostctl -t` returns "/dev/pvbus0: Hyper-V" Any tips on getting hostctl to work? Also, do the values persist across reboots or do they need to be set via rc.d? -Max
Re: [patch] fake pv drivers installation on xen
On Mon, Jul 17, 2017 at 3:40 PM, Mike Belopuhov wrote: > On Mon, Jul 17, 2017 at 14:32 -0400, Maxim Khitrov wrote: >> On Wed, Jan 18, 2017 at 2:16 PM, Dinar Talypov wrote: >> > I use Xenserver 7.0 with xencenter management console. >> > without it doesn't allow shutdown or reboot. >> > Anyway I'll try with hostctl. >> > >> > Thanks. >> >> Were you able to get this working with hostctl? I'm running OpenBSD >> 6.1 amd64 on XenServer 7.0. When I run any hostctl command, such as >> `hostctl device/vif/0/mac`, I get the following error: >> >> hostctl: ioctl: Device not configured >> >> During boot, I see these messages: >> >> pvbus0 at mainbus0: Hyper-V 0.0, Xen 4.6 >> xen0 at pvbus0: features 0x2705, 32 grant table frames, event channel 3 >> xbf0 at xen0 backend 0 channel 8: disk >> > > You need to disable viridian compatibility in your Xenserver. > >> Running `hostctl -t` returns "/dev/pvbus0: Hyper-V" >> > > That's because Xenserver announces Hyper-V compatibility layer > (called viridian) before Xen for whatever reason. You need to > do "cd /dev; ./MAKEDEV pvbus1" and then use "hostctl -f /dev/pvbus1" > with your commands (I assume -- never tried a Xenserver myself). > >> Any tips on getting hostctl to work? > > See above. The easiest is probably just to disable viridian :) Disabling viridian worked, thanks! For anyone else interested in doing this, run the following command on your XenServer host: xe vm-param-set uuid= platform:viridian=false After that, you can add these commands to /etc/rc.local: ostype=$(sysctl -n kern.ostype) osrelease=$(sysctl -n kern.osrelease) # PV driver version hostctl attr/PVAddons/MajorVersion 6 hostctl attr/PVAddons/MinorVersion 2 hostctl attr/PVAddons/MicroVersion 0 hostctl attr/PVAddons/BuildVersion 76888 hostctl attr/PVAddons/Installed 1 # OS version hostctl data/os_name "$ostype $osrelease" hostctl data/os_uname $osrelease hostctl data/os_distro $ostype # Update XenStore hostctl data/updated 1 -Max
Re: Document hostctl commands for XenServer
On Fri, Jul 21, 2017 at 9:14 AM, Mike Belopuhov wrote:
> Hi,
>
> Together with Maxim Khitrov we have figured out what needs to
> be set for XenServer (that's a Citrix product based on Xen) to
> "recognize" the OpenBSD VM and let it do things like reboot and
> so on.
>
> I'd like to get this documented in the xen(4) man page instead
> of referring users to mailing list archives.
>
> There are two things that we can mention:
>
> 1) viridian capability, that XenServer comes with enabled by
>default, interferes with hostctl: you need to either disable
>it for your VM (if you have access) or MAKEDEV /dev/pvbus1
>and use that with hostctl(8).
>
> 2) to let XenServer management software know that OpenBSD is
>there in full glory we need to set a few XenStore properties
>with hostctl(8). User needs to do this on every boot, so
>putting them somewhere around /etc/rc.local is necessary.
>
> I've come up with the diff below. Please let me know if this
> makes sense and if we can improve it.
>
> Maxim, can you please double check the script itself. Are all
> these values necessary? I've changed a few things including
> the BuildVersion value.
>
> Thanks.
Hi Mike,
attr/PVAddons/* contains version information about XenServer Tools
installed in the VM, not the OS. Dinar copied the original values from
tools v6.2. I don't know whether XenServer actually cares about what
version is reported, but if it does, this would be tied to features
supported by xen, xbf, and xnf drivers. You typically update the tools
with each new XenServer release, which gives you most recent disk and
network drivers, at least on Windows.
Only attr/PVAddons/{MajorVersion,MinorVersion} and data/updated are
required to get graceful reboot and shutdown support in XenCenter, but
I would leave the rest in there to avoid confusing any tools that
might expect to find the other keys as well.
data/{os_name,os_uname,os_distro} provide OS information, which is
shown in VM properties (not required, but useful to have). Setting
data/updated to 1 triggers a refresh of this information in
XenStore/XenCenter.
-Max
Re: Document hostctl commands for XenServer
On Fri, Jul 21, 2017 at 2:22 PM, Mike Belopuhov wrote:
> On Fri, Jul 21, 2017 at 19:58 +0200, Ingo Schwarze wrote:
>> If these numbers are completely fake and irrelevant,
>> then saying so in one short sentence - or even in the
>> comment line above - may be sufficient.
>>
>> But this quote from Maxim fuels doubts:
>>
>> :: I don't know whether XenServer actually cares about what
>> :: version is reported, but if it does, this would be tied
>> :: to features supported by xen, xbf, and xnf drivers.
>> :: You typically update the tools with each new XenServer
>> :: release, which gives you most recent disk and
>> :: network drivers, at least on Windows.
>>
>> If that is true, than you have just built a time bomb:
>> YOU need to remember to regularly update the manual.
>> USERS need to remember to regularly update their rc.local.
>
> Yes and yes, however, these interfaces don't change often so
> there's no need to constantly update them. We can leave this
> as a hint and an exercise for the reader. I've changed a
> comment there saying that this is a version of "XenServer Tools".
> XenServer users must be able to comprehend what this means.
>
>> If the latter is true, this may need to be explained
>> in this manual page. Of course, that can be figured
>> out and improved later, if needed. Including a change
>> to explain where to get the right magic numbers from
>> rather than simply advertising some numbers that may be
>> good today, but not tomorrow.
See the following link for more info:
https://wiki.xenproject.org/wiki/XAPI_fake_presence_of_PV_drivers
It's XAPI that cares about this stuff, but the actual version number
doesn't seem to matter. The script they provide is intended to run on
the host, so it can get the current product version from
/etc/xensource-inventory. I don't think this information is exposed in
any way to the VM itself, at least not through XenStore.
One thing you can do, however, is get (but not set) viridian state via
`hostctl platform/viridian` (true/false). You can use that to decide
whether pvbus1 is needed or not. You can also report VM IP by setting
attr/eth0/{ip,ipv6}.
Here are the values used by other OSs:
CentOS 7:
attr/PVAddons/MajorVersion 7
attr/PVAddons/MinorVersion 0
attr/PVAddons/MicroVersion 0
attr/PVAddons/BuildVersion 130092
attr/PVAddons/Installed 1
data/os_uname = "3.10.0-514.21.2.el7.x86_64"
data/os_name = "CentOS Linux release 7.3.1611 (Core)"
data/os_distro = "centos"
data/os_majorver = "7"
data/os_minorver = "3"
Windows Server 2016:
attr/PVAddons/MajorVersion 7
attr/PVAddons/MinorVersion 1
attr/PVAddons/MicroVersion 0
attr/PVAddons/BuildVersion 825
attr/PVAddons/Installed 1
data/os_distro = "windows"
data/os_majorver = "6"
data/os_minorver = "2"
data/os_name = "Microsoft Windows Server 2016
Standard|C:\\Windows|\\Device\\Harddisk0\\Partition2"
-Max
Re: sndiod_flags=NO in /etc/rc.conf on recent snapshots
On Wed, Nov 18, 2015 at 12:02 AM, Theo de Raadt wrote: >> I only just noticed that, trying to watch a video while having a web >> browser open at the same time, I don't get any sound. >> >> Only going through recent daily insecurity emails, had I found out that: >> >> sndiod_flags= >> >> in /etc/rc.conf, has been changed to: >> >> sndiod_flags=NO >> >> on snapshots from around the 10th November. >> >> The source in CVS doesn't have that change. I couldn't find any >> information about it in the mailing list archives either. >> >> What (if any) is the reason behind it? > > Testing reactions. One down, two to go: check_quotas, pflogd_flags :) At least those are the three things I always disable on new firewalls. check_quotas is harmless, but just unnecessary if I don't use quotas. pflogd can fill-up /var if "log" is added to a frequently-matching rule (had that happen to me once). -Max
Re: /var/tmp in current
On Tue, Nov 18, 2014 at 7:43 AM, Theo de Raadt wrote: >> /var/tmp has been changed to be a symlink to /tmp. Traditionally, >> the difference between /tmp and /var/tmp has been that the former is >> cleaned after a reboot, while the latter isn't. Making /var/tmp a >> symlink to /tmp means it's no longer practical to make /tmp a ramdisk. >> Is this a wise change? > > That distinction is a historical mistake. Read the commit message. I also have /tmp as a tmpfs mount and my concern, in addition to vi.recover, is that the upgrade guide for 5.6 explicitly mentions backups of files replaced by sysmerge surviving a reboot in /var/tmp (at least for a few days). What will happen in 5.7? The commit message says that some daemons assume they will not run out of space in /var. Which ones? That seems like a really bad assumption.
