Re: /var/tmp in current

2014-12-01 Thread Maxim Khitrov
On Tue, Nov 18, 2014 at 7:43 AM, Theo de Raadt dera...@cvs.openbsd.org 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.



Re: sndiod_flags=NO in /etc/rc.conf on recent snapshots

2015-11-18 Thread Maxim Khitrov
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: pfctl interprets "# ... \" as multi-line comment and can skip rules

2016-01-16 Thread Maxim Khitrov
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

2017-07-17 Thread Maxim Khitrov
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

2017-07-17 Thread Maxim Khitrov
On Mon, Jul 17, 2017 at 3:40 PM, Mike Belopuhov <m...@belopuhov.com> wrote:
> On Mon, Jul 17, 2017 at 14:32 -0400, Maxim Khitrov wrote:
>> On Wed, Jan 18, 2017 at 2:16 PM, Dinar Talypov <t.dina...@gmail.com> 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

2017-07-21 Thread Maxim Khitrov
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: Document hostctl commands for XenServer

2017-07-21 Thread Maxim Khitrov
On Fri, Jul 21, 2017 at 9:14 AM, Mike Belopuhov <m...@belopuhov.com> 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