Hello all (long time no see!)
TL;DR: Allow syspatch -c run under non-priviledged user.
Reasoning: instead of putting syspatch -c in crontab, I've implemented
a Zabbix trigger. Since the Zabbix agent runs as unpriviledged user,
I had to add _zabbix line to doas.conf, allowing it to run syspatch -c
With "owner root:wheel" (any group) the `vmctl status' output
will omit the "root" part in the OWNER column:
vm "generic" {
owner "root:vms"
...
}
$ vmctl status
ID PID VCPUS MAXMEM CURMEM TTYOWNERSTATE NAME
`allow instance' is invalid, that is the `{...}' is mandatory.
OK?
Index: vm.conf.5
===
RCS file: /cvs/src/usr.sbin/vmd/vm.conf.5,v
retrieving revision 1.46
diff -u -p -r1.46 vm.conf.5
--- vm.conf.5 13 Dec 2019 07:03:46 -
Hi all,
I recently built a new system with an ASRock B450M Pro4 motherboard. This
board has a Nuvoton NCT6779D chip to monitor temperatures, fans and
voltages. OpenBSD's lm(4) currently only supports the Nuvoton NCT6776F
chip, added by Marco Pfatschbacher in 2011:
https://marc.info/?l=openbsd-cvs
On Fri, Dec 13, 2019 at 10:34:59PM +0100, Patrick Wildt wrote:
> Hi,
>
> I have a ThingM blink(1) USB RGB device that shows up as uhid(4).
> The tooling is "interesting", especially with all those libusb and
> HID libraries doing the abstraction. This introduces ublink(4), a
> dedicated kernel dr
From: "Theo de Raadt"
Subject: Re: Is uvm_map_isavail() returning 1 instead of -1?
Date: Fri, 13 Dec 2019 15:54:10 -0700
> Masato Asou wrote:
>
>> Is this correct?
>>
>> Index: sys/uvm/uvm_map.c
>> ===
>> RCS file: /cvs/src/sys/uv
Masato Asou wrote:
> Is this correct?
>
> Index: sys/uvm/uvm_map.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_map.c,v
> retrieving revision 1.259
> diff -u -p -r1.259 uvm_map.c
> --- sys/uvm/uvm_map.c 12 Dec 2019 11:12:36 - 1
Is this correct?
Index: sys/uvm/uvm_map.c
===
RCS file: /cvs/src/sys/uvm/uvm_map.c,v
retrieving revision 1.259
diff -u -p -r1.259 uvm_map.c
--- sys/uvm/uvm_map.c 12 Dec 2019 11:12:36 - 1.259
+++ sys/uvm/uvm_map.c 13 Dec 2
Patrick Wildt wrote:
> On Fri, Dec 13, 2019 at 02:43:25PM -0700, Theo de Raadt wrote:
> > +__devitem(led, led*, Generic LED devices)dnl
> > +_mcdev({-led-}, led*, {-led-}, {-major_led_c-}, 660)dnl
> >
> > Mode 660 leads me to ask -- what is the group?
>
> I don't know, I figured you could help
On Fri, Dec 13, 2019 at 02:43:25PM -0700, Theo de Raadt wrote:
> +__devitem(led, led*, Generic LED devices)dnl
> +_mcdev({-led-}, led*, {-led-}, {-major_led_c-}, 660)dnl
>
> Mode 660 leads me to ask -- what is the group?
I don't know, I figured you could help me there. I guess the
default can be
+__devitem(led, led*, Generic LED devices)dnl
+_mcdev({-led-}, led*, {-led-}, {-major_led_c-}, 660)dnl
Mode 660 leads me to ask -- what is the group?
If you say wheel, that is related to the diff I sent recently.
wheel marks who can su to root. Somehow it has accidentally
gained additional power
Hi,
I have a ThingM blink(1) USB RGB device that shows up as uhid(4).
The tooling is "interesting", especially with all those libusb and
HID libraries doing the abstraction. This introduces ublink(4), a
dedicated kernel driver for that device. There are two LEDs on the
device, which can be modif
This diff changes the way session or peer related imsgs are handled.
Instead of passing the imsg.hdr.peerid down and doing the lookup for the
peer in each function move that code up into the imsg handler.
The plan is to add an imsg queue per peer later on to make the processing
of messages more fai
On Fri, Dec 13, 2019 at 02:19:26PM +0100, Matija Skala wrote:
> Dne petek, 13. december 2019 ob 13:34:57 CET je Marc Espie napisal(a):
> > On Fri, Dec 13, 2019 at 08:45:08AM +0100, Jasper Lievisse Adriaanse wrote:
> > > Hello Matija,
> > >
> > > Could you please provide a testcase for inclusion in
Dne petek, 13. december 2019 ob 13:34:57 CET je Marc Espie napisal(a):
> On Fri, Dec 13, 2019 at 08:45:08AM +0100, Jasper Lievisse Adriaanse wrote:
> > Hello Matija,
> >
> > Could you please provide a testcase for inclusion in
> > src/regress/usr.bin/pkg-config too? Also, is there a particular port
On Fri, Dec 13, 2019 at 08:45:08AM +0100, Jasper Lievisse Adriaanse wrote:
> Hello Matija,
>
> Could you please provide a testcase for inclusion in
> src/regress/usr.bin/pkg-config too?
> Also, is there a particular port or pkg-config file in the wild that you ran
> into which exhibits this part
> Could you please provide a testcase for inclusion in
> src/regress/usr.bin/pkg-config too?
diff --git a/regress/usr.bin/pkg-config/pcdir/minusrc.pc b/regress/usr.bin/pkg-
config/pcdir/minusrc.pc
new file mode 100644
index 000..5bde7da0b44
--- /dev/null
+++ b/regress/usr.bin/pkg-config/pc
This is the next step in refactoring the output functions in bgpctl.
This diff changes the way individual show_XY() functions are called. Up
until now they got passed an imsg and then did stuff based on the imsg
type. Now show() will look at the imsg and based on the type call the
right function f
On Wed, Dec 11, 2019 at 08:03:59PM +0100, Stefan Sperling wrote:
> Back in February we disabled iwm firmware Tx retries at lower rates.
> This improved MiRA's Tx rate selection because bad rates do actually
> look bad, rather than being compensated for by firmware retries.
> The result was increase
Hi tech@,
Here is a diff to add sizes for free() in eso(4).
Similar diff to the ones previously sent for other audio drivers.
Comments? OK?
Index: sys/dev/pci/eso.c
===
RCS file: /cvs/src/sys/dev/pci/eso.c,v
retrieving revision 1.4
Hi tech@,
Here is a diff to add sizes for free() in eap(4).
Similar diff to the ones previously sent for other audio drivers.
Comments? OK?
Index: sys/dev/pci/eap.c
===
RCS file: /cvs/src/sys/dev/pci/eap.c,v
retrieving revision 1.5
Hi tech@,
Here is a diff to add sizes for free() in auixp(4).
Similar diff to the ones previously sent for other audio drivers.
Comments? OK?
Index: sys/dev/pci/auixp.c
===
RCS file: /cvs/src/sys/dev/pci/auixp.c,v
retrieving revisi
Hello,
sorry it dropped on the floor of my INBOX...
thanks for reminding.
> Yes, the main anchor prints as "" but all that is behind compile time
> -DOPT_DEBUG so regular users won't deal with it anyway, so keep the code
> simple instead of adding logging around `rs->anchor->path'.
>
> OK?
cha
On Fri, Dec 06, 2019 at 05:46:52PM +0100, Claudio Jeker wrote:
> The output processing in bgpctl is not very extensible. And output flags
> like ssv have to hacked into the output in a bad way.
>
> This is the first bit of a much bigger shuffling action to make the output
> handling more extensibl
24 matches
Mail list logo
