On Mon, Dec 26, 2016 at 08:44:47PM +0100, Stefan Sperling wrote:
> [...]
> E.g. at 33C3 there are APs with: RxMCS 0xf8f8f800
>
> The diff below makes OpenBSD clients work in 11n mode on such networks
> by relaxing our "supported MCS" 11n feature check.
> [...]
To go along with the 33c
Hi,
While I was testing syslogd with SIGHUP, it sometimes died. This
seems to happen if the signal hits the process durig its initilisation
phase. I think we should block the signals until the handler in
both processes are installed.
ok?
bluhm
Index: usr.sbin/syslogd/privsep.c
===
Alexander Bluhm writes:
> On Mon, Dec 26, 2016 at 09:08:22PM +0100, Jeremie Courreges-Anglas wrote:
>> Alexander Bluhm writes:
>> Your last diff has a drawback: you can't simply start the daemon like
>> this:
>>
>> # syslogd
>>
>> realpath will resolve "syslogd" to "/path/to/current/directory/
On Mon, Dec 26, 2016 at 09:08:22PM +0100, Jeremie Courreges-Anglas wrote:
> Alexander Bluhm writes:
> Your last diff has a drawback: you can't simply start the daemon like
> this:
>
> # syslogd
>
> realpath will resolve "syslogd" to "/path/to/current/directory/syslogd".
>
> Maybe call realpath
Submitted for your consideration:
This diff adds an option '-h' to touch(1) for getting/setting timestamps
from symbolic links directly, rather than the linked-to file. This is
useful if you want to set the timestamp on a link (e.g. to copy the
timestamp from the linked-to file, or from another l
Even though the 11n standard mandates MCS 0-15 for APs, some APs have config
knobs which disable a subset of MCS, and some admins do touch these knobs.
E.g. at 33C3 there are APs with: RxMCS 0xf8f8f800
The diff below makes OpenBSD clients work in 11n mode on such networks
by relaxing
On Sun, Dec 25, 2016 at 09:47:16AM -0700, Todd C. Miller wrote:
> Another alternative is to use realpath(3) to resolve the path
> so it can be used after the chdir(2).
Good idea. I have moved all the path handling to privsep.c.
ok?
bluhm
Index: usr.sbin/syslogd/privsep.c
==
Jeremie Courreges-Anglas writes:
> The net/uucp and news/leafnode ports have been tweaked to use accounts
> managed in the ports tree:
>
> https://www.openbsd.org/faq/current.html#r20161218
>
> The uucp port no longer puts its lock files in /var/spool/lock. This
> means that using uucp and ppp
> Date: Mon, 26 Dec 2016 09:13:50 +0100
> From: Stefan Sperling
>
> I do not see a good reason for using multiple custom task queues
> in this driver, and at the same time it is using systq for tasks.
>
> This moves all tasks to one custom queue to make things consistent.
> Except I'm leaving th
The net/uucp and news/leafnode ports have been tweaked to use accounts
managed in the ports tree:
https://www.openbsd.org/faq/current.html#r20161218
The uucp port no longer puts its lock files in /var/spool/lock. This
means that using uucp and pppd on a serial line could lead to conflicts.
I
Hi,
Forcing autoinstall indeed does work. Thank you for the hint.
I just noticed that one other vm running on this host, never seems to
suffer from this issue. (autoinstall just works)
No obvious difference in the vm specs nor answer files.
Best regards,
Pedro Caetano
On Mon, Dec 26, 2016 at
I do not see a good reason for using multiple custom task queues
in this driver, and at the same time it is using systq for tasks.
This moves all tasks to one custom queue to make things consistent.
Except I'm leaving the init_task on systq because this task is kind
of special (e.g. it might be ad
12 matches
Mail list logo
