Re: Pledge shutdown halt
On Tue, Nov 17, 2015 at 11:31:57PM -0700, Theo de Raadt wrote: > What ttys are you guys rebooting from. Is it seen on console? Or... is it > only seen from xterm...? > I just now rebuilt my amd64 machine with a fresh checkout from "anon...@anoncvs.eu.openbsd.org:/cvs". The message displays in the terminal from which the command was executed. Rebooting as root in the console, I see the message in the console. Rebooting with "doas reboot" from logging in as a user with SSH I get the same: $ doas reboot reboot: revoke: Inappropriate ioctl for device Shared connection to xxx.xxx.xx.xxx closed. Connection to xxx.xxx.xx.xxx closed by remote host. I do not run X. -- :: Andreas Kusalananda Kähäri :: Bioinformatics Developer :: Uppsala, Sweden ::--
Re: Pledge shutdown halt
On Wed, Nov 18, 2015 at 06:31:57AM GMT, Theo de Raadt wrote: > What ttys are you guys rebooting from. Is it seen on console? Or... is it > only seen from xterm...? Both local console and over SSH. Raf
Re: Pledge shutdown halt
On Wed, Nov 18, 2015 at 05:43:15AM GMT, Theo de Raadt wrote: > > > > Anybody see this on shutdown?=C2=A0 > > > > shutdown -hp now > > > > *** FINAL System shutdown message from i...@ianm-openbsd.xxx.edu.au > > > > System going down IMMEDIATELY=C2=A0 > > > > System shutdown time has arrived=20 > > > > halt: revoke: Inappropriate ioctl for device > > I think your kernel is very slightly out of sync, but will double > check the changes I made. Same here with '-r' on recent snapshots: reboot: revoke: Inappropriate ioctl for device Raf
Re: Pledge shutdown halt
What ttys are you guys rebooting from. Is it seen on console? Or... is it only seen from xterm...?
Re: Pledge shutdown halt
I also get this with sources updated on Monday. Andreas On Wed, Nov 18, 2015 at 03:56:46PM +1100, Ian McWilliam wrote: > > Anybody see this on shutdown? > > shutdown -hp now > > *** FINAL System shutdown message from i...@ianm-openbsd.xxx.edu.au > > *** > > > System going down IMMEDIATELY > > System shutdown time has arrived > > halt: revoke: Inappropriate ioctl for device > > Kernel and userland built today > > OpenBSD 5.8-current (GENERIC.MP) #0: Wed Nov 18 14:15:33 AEDT 2015 > > > r...@ianm-openbsd.xxx.edu.au:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Machine still shuts down and powers off. > > Ian McWilliam > -- :: Andreas Kusalananda Kähäri :: Bioinformatics Developer :: Uppsala, Sweden ::--
Re: sndiod_flags=NO in /etc/rc.conf on recent snapshots
On Wed, Nov 18, 2015 at 05:02:33AM GMT, 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. ;^) Fewer daemons in default configuration? Since it is 'rcctl enable sndiod' away, I don't mind that much - whatever works for majority. Just tad unexpected, that's all :^) Regards, Raf
Re: Pledge shutdown halt
> > Anybody see this on shutdown?=C2=A0 > > shutdown -hp now > > *** FINAL System shutdown message from i...@ianm-openbsd.xxx.edu.au > > System going down IMMEDIATELY=C2=A0 > > System shutdown time has arrived=20 > > halt: revoke: Inappropriate ioctl for device I think your kernel is very slightly out of sync, but will double check the changes I made.
Re: printf(3) wording
On Tue, Nov 17, 2015 at 11:48 AM, Christian Weisgerber wrote: > On 2015-11-17, Jan Stary wrote: > >> I am not a native speaker, but the conversion specifiers >> are "interpreted" by printf, not "interpolated", right? > > I think "interpolated" as a technical term is correct here. > (The Perl documentation is very fond of it.) Well, in perl that's in the context of expansion of variable references inside quote operators, where the evaluated result has the references inserted in theirs positions in the quote context. In the context of printf(3), what will be interp*ed here is not the conversion specifiers themselves but the strings that will result from their processing. I would therefore say that the conversion specifiers are interpreted. Note that the perlfunc(1) section on perl's sprintf() built-in talks of the interpretation of the format letters, what printf(3) calls conversions. Put me firmly in the "interpreted" camp for this. Philip Guenther
Pledge shutdown halt
Anybody see this on shutdown? shutdown -hp now *** FINAL System shutdown message from i...@ianm-openbsd.xxx.edu.au *** System going down IMMEDIATELY System shutdown time has arrived halt: revoke: Inappropriate ioctl for device Kernel and userland built today OpenBSD 5.8-current (GENERIC.MP) #0: Wed Nov 18 14:15:33 AEDT 2015 r...@ianm-openbsd.xxx.edu.au:/usr/src/sys/arch/amd64/compile/GENERIC.MP Machine still shuts down and powers off. Ian McWilliam
Re: sndiod_flags=NO in /etc/rc.conf on recent snapshots
> 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.
sndiod_flags=NO in /etc/rc.conf on recent snapshots
Hi all, 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? Regards, Raf
Feedback on AddKeysToAgent ssh_config(5) option
Hello, Regarding the recently added AddKeysToAgent ssh_config(5) option, it would also be nice to specify a key timeout when adding keys via this option. Given that the agent is normally started automatically for the user (on OpenBSD and other operating systems) the user normally doesn't have the opportunity to specify any command-line options to ssh-agent. So, if you want to specify a key timeout the typical approach is to do so when adding the keys. Perhasp an AgentTimeout option could be added? Alternatively, the syntax of AddKeysToAgent could be extended, e.g. "AddKeysToAgent yes:10m" Of the two, adding AgentTimeout seems cleaner. One other thought, I suspect that having both "ask" and "confirm" as vaild arguments to AddKeysToAgent will cause some confusion. However, I don't have a suggestion to address this. -- Iain Morgan
Re: Better ASR support in ospfd
On 2015/11/15 21:47, Claudio Jeker wrote: > On Mon, Oct 26, 2015 at 04:40:12PM +0100, Claudio Jeker wrote: > > ospfd has some issues with self-originated networks and building summary > > entries for those in case the router is an ABR (area border router). > > This diff should hopefully fix all of the troubles. It changes a bit the > > way we do nexthop calculation in the SPF/rib calculation to make sure we > > handle self-originated networks correctly. As a side-effect it should also > > remove the behaviour where ospfd added a OSPF route for all those > > self-originated routes. Also the way we track active areas is changed to > > be actually the way it should be. > > > > Please test this on all ospfd setups and check for issues. > > I guess nobody is using ospfd anymore. Anyway here is an updated diff that > fixes an issue with stub networks announced by routers connected via a P2P > link. I'm running this on our ABR router at work now and plan to commit > this in the next days. No regressions with this, but I flattened my areas 2 years ago (I was using 'stub redistribute default' but switched over to carrying defaults in BGP instead) so I don't have ABRs any more. I didn't spot any problems from reading, OK with me.
missing period in pledge.2
Index: pledge.2 === RCS file: /cvs/src/lib/libc/sys/pledge.2,v retrieving revision 1.15 diff -u -p -r1.15 pledge.2 --- pledge.216 Nov 2015 19:26:21 - 1.15 +++ pledge.217 Nov 2015 21:14:08 - @@ -472,7 +472,7 @@ process: .Xr setlogin 2 , .Xr setrlimit 2 , .Xr getpriority 2 , -.Xr setpriority 2 +.Xr setpriority 2 . .El .Pp A whitelist of permitted paths may be provided in
Re: pledge audioctl
On 2015/11/17 18:11, Jan Stary wrote: > I am trying to add pledge(2) to audioctl(1), > but it gets SIGABRT'ed under any pledge promises. > (Indeed, I have pledged everything in a desperate attempt.) Note that pledging "everything" still gives quite a restriction on what's allowed - it's "block-by-default, whitelist (parts of) some".
Re: printf(3) wording
On 2015-11-17, Jan Stary wrote: > I am not a native speaker, but the conversion specifiers > are "interpreted" by printf, not "interpolated", right? I think "interpolated" as a technical term is correct here. (The Perl documentation is very fond of it.) > using a function like > .Fn snprintf , > as the resulting string may still contain user-supplied conversion specifiers > -for later interpolation by > +for later interpretation by > .Fn printf . > .Pp > Be sure to use the proper secure idiom: -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: printf(3) wording
On 11/18/15 07:16, Amit Kulkarni wrote: jan is right, interpretation is the correct word. Interpolate is using something to do mathematically. the program is going to work on, so interpret... Interpolate is a word I picked up when learning Perl and to do with strings, not just mathematically: https://en.wikipedia.org/wiki/String_interpolation I'm not arguing for either word being better, I'll leave that to others.
Re: printf(3) wording
> > > > i don;t know how these implementations work, so it's hard to say. > > > > perhaps they are interpolated. maybe use cvs to track down the author > > > > and ask them? > > > > > > > > whatever the outcome, if you want to change this text you probably want > > > > to adjust a few more: > > > > > > > > /usr/src/lib/libc/gen/err.3:for later interpolation by the > > > > /usr/src/lib/libc/gen/setproctitle.3:for later interpolation by > > > > /usr/src/lib/libc/gen/syslog.3:for later interpolation by > > > > /usr/src/lib/libc/stdio/printf.3:for later interpolation by > > > > > > Hm, probably just my English; > > > sorry for the noise. > > > > > > Jan > > > > > > > not neccessarily. the author may have been confused too. who knows. i > > had to look up "interpolation" myself. it's a word i'd prefer to avoid > > in man pages if we can ;) > > interpretation is the correct word to use. another option is "expansion"
Re: printf(3) wording
On Tue, Nov 17, 2015 at 11:22 AM, Jason McIntyre wrote: > On Tue, Nov 17, 2015 at 06:14:33PM +0100, Jan Stary wrote: > > On Nov 17 17:06:11, j...@kerhand.co.uk wrote: > > > On Tue, Nov 17, 2015 at 10:38:41AM +0100, Jan Stary wrote: > > > > I am not a native speaker, but the conversion specifiers > > > > are "interpreted" by printf, not "interpolated", right? > > > > > > > > Jan > > > > > > > > > > i don;t know how these implementations work, so it's hard to say. > > > perhaps they are interpolated. maybe use cvs to track down the author > > > and ask them? > > > > > > whatever the outcome, if you want to change this text you probably want > > > to adjust a few more: > > > > > > /usr/src/lib/libc/gen/err.3:for later interpolation by the > > > /usr/src/lib/libc/gen/setproctitle.3:for later interpolation by > > > /usr/src/lib/libc/gen/syslog.3:for later interpolation by > > > /usr/src/lib/libc/stdio/printf.3:for later interpolation by > > > > Hm, probably just my English; > > sorry for the noise. > > > > Jan > > > > not neccessarily. the author may have been confused too. who knows. i > had to look up "interpolation" myself. it's a word i'd prefer to avoid > in man pages if we can ;) > > jan is right, interpretation is the correct word. Interpolate is using something to do mathematically. the program is going to work on, so interpret...
Re: ypserv h
Ted Unangst wrote: > memory.h is spelled string.h now. ok? Index: etherent.c === RCS file: /cvs/src/lib/libpcap/etherent.c,v retrieving revision 1.7 diff -u -p -r1.7 etherent.c --- etherent.c 27 Jan 2004 06:58:03 - 1.7 +++ etherent.c 17 Nov 2015 18:10:36 - @@ -24,7 +24,6 @@ #include #include -#include #include #include Index: gencode.c === RCS file: /cvs/src/lib/libpcap/gencode.c,v retrieving revision 1.41 diff -u -p -r1.41 gencode.c --- gencode.c 27 Sep 2015 05:25:00 - 1.41 +++ gencode.c 17 Nov 2015 18:10:37 - @@ -42,9 +42,9 @@ struct rtentry; #include #include -#include #include #include +#include #include "pcap-int.h" Index: inet.c === RCS file: /cvs/src/lib/libpcap/inet.c,v retrieving revision 1.21 diff -u -p -r1.21 inet.c --- inet.c 24 Oct 2015 05:26:00 - 1.21 +++ inet.c 17 Nov 2015 18:10:37 - @@ -50,7 +50,6 @@ struct rtentry; #include #include -#include #include #include #include Index: nametoaddr.c === RCS file: /cvs/src/lib/libpcap/nametoaddr.c,v retrieving revision 1.17 diff -u -p -r1.17 nametoaddr.c --- nametoaddr.c24 Oct 2015 06:07:43 - 1.17 +++ nametoaddr.c17 Nov 2015 18:10:37 - @@ -40,9 +40,9 @@ struct rtentry; #include #include #include -#include #include #include +#include #include "pcap-int.h" Index: optimize.c === RCS file: /cvs/src/lib/libpcap/optimize.c,v retrieving revision 1.15 diff -u -p -r1.15 optimize.c --- optimize.c 26 Jun 2014 04:03:33 - 1.15 +++ optimize.c 17 Nov 2015 18:10:38 - @@ -29,7 +29,7 @@ #include #include #include -#include +#include #include "pcap-int.h" Index: savefile.c === RCS file: /cvs/src/lib/libpcap/savefile.c,v retrieving revision 1.13 diff -u -p -r1.13 savefile.c --- savefile.c 16 Jan 2015 03:19:57 - 1.13 +++ savefile.c 17 Nov 2015 18:10:38 - @@ -34,9 +34,9 @@ #include #include -#include #include #include +#include #include #ifdef HAVE_OS_PROTO_H
Re: printf(3) wording
Jason McIntyre wrote: > On Tue, Nov 17, 2015 at 06:14:33PM +0100, Jan Stary wrote: > > On Nov 17 17:06:11, j...@kerhand.co.uk wrote: > > > On Tue, Nov 17, 2015 at 10:38:41AM +0100, Jan Stary wrote: > > > > I am not a native speaker, but the conversion specifiers > > > > are "interpreted" by printf, not "interpolated", right? > > > > > > > > Jan > > > > > > > > > > i don;t know how these implementations work, so it's hard to say. > > > perhaps they are interpolated. maybe use cvs to track down the author > > > and ask them? > > > > > > whatever the outcome, if you want to change this text you probably want > > > to adjust a few more: > > > > > > /usr/src/lib/libc/gen/err.3:for later interpolation by the > > > /usr/src/lib/libc/gen/setproctitle.3:for later interpolation by > > > /usr/src/lib/libc/gen/syslog.3:for later interpolation by > > > /usr/src/lib/libc/stdio/printf.3:for later interpolation by > > > > Hm, probably just my English; > > sorry for the noise. > > > > Jan > > > > not neccessarily. the author may have been confused too. who knows. i > had to look up "interpolation" myself. it's a word i'd prefer to avoid > in man pages if we can ;) interpretation is the correct word to use.
ypserv h
Really wants ndbm.h, not dbm.h. Also, memory.h is spelled string.h now. Index: yppush/yppush_svc.c === RCS file: /cvs/src/usr.sbin/ypserv/yppush/yppush_svc.c,v retrieving revision 1.14 diff -u -p -r1.14 yppush_svc.c --- yppush/yppush_svc.c 15 Jan 2015 00:40:23 - 1.14 +++ yppush/yppush_svc.c 17 Nov 2015 18:02:08 - @@ -32,7 +32,7 @@ #include #include #include -#include +#include #include #include Index: ypserv/ypserv.c === RCS file: /cvs/src/usr.sbin/ypserv/ypserv/ypserv.c,v retrieving revision 1.42 diff -u -p -r1.42 ypserv.c --- ypserv/ypserv.c 26 Oct 2015 10:12:46 - 1.42 +++ ypserv/ypserv.c 17 Nov 2015 18:01:58 - @@ -42,9 +42,8 @@ #include #include #include -#include +#include #include -#include #include "acl.h" #include "yplog.h" #include "ypdef.h"
Re: fdisk(8) -l -c -h -s manpage bits
On Tue, Nov 17, 2015 at 06:38:06PM +0100, Jan Stary wrote: > On Nov 17 17:21:42, j...@kerhand.co.uk wrote: > > On Tue, Nov 17, 2015 at 09:36:26AM +0100, Jan Stary wrote: > > > On Nov 14 14:17:08, k...@openbsd.org wrote: > > > > Modified files: > > > > sbin/fdisk : disk.c fdisk.c > > > > > > > > Log message: > > > > Since -l is ignored if -c/-h/-s are specified, make that combination > > > > invalid and mention the constraint in usage(). > > > > > > Mention it in the manpage too. > > > > > > Jan > > > > > > > > > > i agree it makes sense to document it. but there is already similar text > > there for -u and -i, and this makes it a little consistent. > > note i actually meant to say "inconsistent", not "consistent" > > i propose using the same text. are you happy with this? > > I agree that this is better. > fine, i'll fix in a sec. thanks for the mail. jmc > > > > > Index: fdisk.8 > > === > > RCS file: /cvs/src/sbin/fdisk/fdisk.8,v > > retrieving revision 1.87 > > diff -u -r1.87 fdisk.8 > > --- fdisk.8 26 Oct 2015 18:05:25 - 1.87 > > +++ fdisk.8 17 Nov 2015 17:19:53 - > > @@ -79,6 +79,12 @@ > > or values that > > .Em /boot > > has passed to the kernel. > > +.Pp > > +Only one of > > +.Fl chs > > +or > > +.Fl l > > +can be specified. > > .It Fl e > > Use the > > .Nm > > @@ -127,6 +133,12 @@ > > .It Fl l Ar blocks > > Specify the number of blocks in the disk, and force the MBR to be in LBA > > mode only. > > +.Pp > > +Only one of > > +.Fl chs > > +or > > +.Fl l > > +can be specified. > > .It Fl u > > Update MBR bootcode, preserving existing MBR partition table. > > The MBR bootcode extends from offset 0x000 to the start of the MBR > > partition >
Re: fdisk(8) -l -c -h -s manpage bits
On Nov 17 17:21:42, j...@kerhand.co.uk wrote: > On Tue, Nov 17, 2015 at 09:36:26AM +0100, Jan Stary wrote: > > On Nov 14 14:17:08, k...@openbsd.org wrote: > > > Modified files: > > > sbin/fdisk : disk.c fdisk.c > > > > > > Log message: > > > Since -l is ignored if -c/-h/-s are specified, make that combination > > > invalid and mention the constraint in usage(). > > > > Mention it in the manpage too. > > > > Jan > > > > > > i agree it makes sense to document it. but there is already similar text > there for -u and -i, and this makes it a little consistent. > > i propose using the same text. are you happy with this? I agree that this is better. > > Index: fdisk.8 > === > RCS file: /cvs/src/sbin/fdisk/fdisk.8,v > retrieving revision 1.87 > diff -u -r1.87 fdisk.8 > --- fdisk.8 26 Oct 2015 18:05:25 - 1.87 > +++ fdisk.8 17 Nov 2015 17:19:53 - > @@ -79,6 +79,12 @@ > or values that > .Em /boot > has passed to the kernel. > +.Pp > +Only one of > +.Fl chs > +or > +.Fl l > +can be specified. > .It Fl e > Use the > .Nm > @@ -127,6 +133,12 @@ > .It Fl l Ar blocks > Specify the number of blocks in the disk, and force the MBR to be in LBA > mode only. > +.Pp > +Only one of > +.Fl chs > +or > +.Fl l > +can be specified. > .It Fl u > Update MBR bootcode, preserving existing MBR partition table. > The MBR bootcode extends from offset 0x000 to the start of the MBR partition
Re: fdisk(8) -l -c -h -s manpage bits
On Tue, Nov 17, 2015 at 09:36:26AM +0100, Jan Stary wrote: > On Nov 14 14:17:08, k...@openbsd.org wrote: > > Modified files: > > sbin/fdisk : disk.c fdisk.c > > > > Log message: > > Since -l is ignored if -c/-h/-s are specified, make that combination > > invalid and mention the constraint in usage(). > > Mention it in the manpage too. > > Jan > > i agree it makes sense to document it. but there is already similar text there for -u and -i, and this makes it a little consistent. i propose using the same text. are you happy with this? jmc Index: fdisk.8 === RCS file: /cvs/src/sbin/fdisk/fdisk.8,v retrieving revision 1.87 diff -u -r1.87 fdisk.8 --- fdisk.8 26 Oct 2015 18:05:25 - 1.87 +++ fdisk.8 17 Nov 2015 17:19:53 - @@ -79,6 +79,12 @@ or values that .Em /boot has passed to the kernel. +.Pp +Only one of +.Fl chs +or +.Fl l +can be specified. .It Fl e Use the .Nm @@ -127,6 +133,12 @@ .It Fl l Ar blocks Specify the number of blocks in the disk, and force the MBR to be in LBA mode only. +.Pp +Only one of +.Fl chs +or +.Fl l +can be specified. .It Fl u Update MBR bootcode, preserving existing MBR partition table. The MBR bootcode extends from offset 0x000 to the start of the MBR partition
Re: pledge audioctl
> I am trying to add pledge(2) to audioctl(1), > but it gets SIGABRT'ed under any pledge promises. > (Indeed, I have pledged everything in a desperate attempt.) > > Looking at gdb and a ktrace, /dev/audioctl gets opened fine, > but then it fails on an ioctl in getinfo() > > 23472 audioctl CALL ioctl(3,AUDIO_GETDEV,0x10d3bed03a20) > 23472 audioctl PLDG ioctl, "ioctl", errno 1 Operation not permitted > 23472 audioctl PSIG SIGABRT SIG_DFL code <1054761850> > 23472 audioctl NAMI "audioctl.core" > > Obviously, "ioctl" is in the pledge call. > Is it simply that AUDIO_GETDEV is not included in the ioctl pledge? ... > Is there a way to pledge audio stuff like this with current pledge? No. Much of ioctl is considered attack surface, and we will look into handling those things after the less intense parts of the tree are correctly annotated/managed by pledge. Priority is on the more procedural code. More than 80% done...
Re: printf(3) wording
On Tue, Nov 17, 2015 at 06:14:33PM +0100, Jan Stary wrote: > On Nov 17 17:06:11, j...@kerhand.co.uk wrote: > > On Tue, Nov 17, 2015 at 10:38:41AM +0100, Jan Stary wrote: > > > I am not a native speaker, but the conversion specifiers > > > are "interpreted" by printf, not "interpolated", right? > > > > > > Jan > > > > > > > i don;t know how these implementations work, so it's hard to say. > > perhaps they are interpolated. maybe use cvs to track down the author > > and ask them? > > > > whatever the outcome, if you want to change this text you probably want > > to adjust a few more: > > > > /usr/src/lib/libc/gen/err.3:for later interpolation by the > > /usr/src/lib/libc/gen/setproctitle.3:for later interpolation by > > /usr/src/lib/libc/gen/syslog.3:for later interpolation by > > /usr/src/lib/libc/stdio/printf.3:for later interpolation by > > Hm, probably just my English; > sorry for the noise. > > Jan > not neccessarily. the author may have been confused too. who knows. i had to look up "interpolation" myself. it's a word i'd prefer to avoid in man pages if we can ;) jmc
pledge audioctl
I am trying to add pledge(2) to audioctl(1), but it gets SIGABRT'ed under any pledge promises. (Indeed, I have pledged everything in a desperate attempt.) Looking at gdb and a ktrace, /dev/audioctl gets opened fine, but then it fails on an ioctl in getinfo() 23472 audioctl CALL ioctl(3,AUDIO_GETDEV,0x10d3bed03a20) 23472 audioctl PLDG ioctl, "ioctl", errno 1 Operation not permitted 23472 audioctl PSIG SIGABRT SIG_DFL code <1054761850> 23472 audioctl NAMI "audioctl.core" Obviously, "ioctl" is in the pledge call. Is it simply that AUDIO_GETDEV is not included in the ioctl pledge? Is there a way to pledge audio stuff like this with current pledge? Jan
Re: printf(3) wording
On Nov 17 17:06:11, j...@kerhand.co.uk wrote: > On Tue, Nov 17, 2015 at 10:38:41AM +0100, Jan Stary wrote: > > I am not a native speaker, but the conversion specifiers > > are "interpreted" by printf, not "interpolated", right? > > > > Jan > > > > i don;t know how these implementations work, so it's hard to say. > perhaps they are interpolated. maybe use cvs to track down the author > and ask them? > > whatever the outcome, if you want to change this text you probably want > to adjust a few more: > > /usr/src/lib/libc/gen/err.3:for later interpolation by the > /usr/src/lib/libc/gen/setproctitle.3:for later interpolation by > /usr/src/lib/libc/gen/syslog.3:for later interpolation by > /usr/src/lib/libc/stdio/printf.3:for later interpolation by Hm, probably just my English; sorry for the noise. Jan > jmc > > > Index: printf.3 > > === > > RCS file: /cvs/src/lib/libc/stdio/printf.3,v > > retrieving revision 1.74 > > diff -u -p -r1.74 printf.3 > > --- printf.313 Oct 2015 12:25:04 - 1.74 > > +++ printf.317 Nov 2015 09:36:19 - > > @@ -852,7 +852,7 @@ This holds true even if the string has b > > using a function like > > .Fn snprintf , > > as the resulting string may still contain user-supplied conversion > > specifiers > > -for later interpolation by > > +for later interpretation by > > .Fn printf . > > .Pp > > Be sure to use the proper secure idiom: > >
Re: printf(3) wording
On Tue, Nov 17, 2015 at 10:38:41AM +0100, Jan Stary wrote: > I am not a native speaker, but the conversion specifiers > are "interpreted" by printf, not "interpolated", right? > > Jan > i don;t know how these implementations work, so it's hard to say. perhaps they are interpolated. maybe use cvs to track down the author and ask them? whatever the outcome, if you want to change this text you probably want to adjust a few more: /usr/src/lib/libc/gen/err.3:for later interpolation by the /usr/src/lib/libc/gen/setproctitle.3:for later interpolation by /usr/src/lib/libc/gen/syslog.3:for later interpolation by /usr/src/lib/libc/stdio/printf.3:for later interpolation by jmc > Index: printf.3 > === > RCS file: /cvs/src/lib/libc/stdio/printf.3,v > retrieving revision 1.74 > diff -u -p -r1.74 printf.3 > --- printf.3 13 Oct 2015 12:25:04 - 1.74 > +++ printf.3 17 Nov 2015 09:36:19 - > @@ -852,7 +852,7 @@ This holds true even if the string has b > using a function like > .Fn snprintf , > as the resulting string may still contain user-supplied conversion specifiers > -for later interpolation by > +for later interpretation by > .Fn printf . > .Pp > Be sure to use the proper secure idiom: >
Re: apmd ignoring ENXIO on /dev/apmctl
Jan Stary wrote:
> Upon startup, apmd(8) opens /dev/apmctl like this:
>
> if ((ctl_fd = open(fname, O_RDWR | O_CLOEXEC)) == -1) {
> if (errno != ENXIO && errno != ENOENT)
> error("cannot open device file `%s'", fname);
> }
>
> Why is it that we ignore ENXIO and ENOENT here?
> apmd(8) seems to go on using the fd as if opening successfully.
There are quite a few checks for ctl_fd == -1 elsewhere, in which case apmd
uses fake data, but a few are missing. And I'm not impressed with the idea in
general.
Re: Exclude invalid sensors from the sensors MIB
ok Stuart Henderson(st...@openbsd.org) on 2015.11.17 11:33:50 +: > On 2015/11/17 11:47, Gerhard Roth wrote: > > Sensors marked as invalid should be excluded by snmpd(8) from the sensors > > MIB just as sysctl(8) excludes them from the 'hw.sensors' tree. > > Agreed - any OKs to commit? > > After: > > $ snmptable -v2c -c public 127.0.0.1 sensorTable > SNMP table: OPENBSD-SENSORS-MIB::sensorTable > > sensorIndexsensorDescr sensorType sensorDevice sensorValue > sensorUnits sensorStatus >1"temp0" temperature "cpu0" "36.00" > "degC" unspecified >2 "zone temperature" temperature"acpitz0" "27.80" > "degC" unspecified >3 "zone temperature" temperature"acpitz1" "29.80" > "degC" unspecified >4"temp0" temperature"sdtemp0" "34.25" > "degC" unspecified >5"temp0" temperature"sdtemp1" "33.50" > "degC" unspecified >6"inner" temperature "ugold0" "21.37" > "degC" unspecified >7 "sd3" drive "softraid0""online" > "" ok > > Before: > > $ snmptable -v2c -c public 127.0.0.1 sensorTable > SNMP table: OPENBSD-SENSORS-MIB::sensorTable > > sensorIndex sensorDescr sensorType sensorDevice sensorValue > sensorUnits sensorStatus >1 "temp0" temperature "cpu0" "38.00" > "degC" unspecified >2 "zone temperature" temperature"acpitz0" "27.80" > "degC" unspecified >3 "zone temperature" temperature"acpitz1" "29.80" > "degC" unspecified >4"voltage" voltsdc "acpibat0" "0.00" > "V DC" unspecified >5"current voltage" voltsdc "acpibat0" "0.00" > "V DC" unspecified >6 "rate" power "acpibat0" "0.00" > "W" unspecified >7 "last full capacity"watthour "acpibat0" "0.00" > "Wh" unspecified >8 "warning capacity"watthour "acpibat0" "0.00" > "Wh" unspecified >9 "low capacity"watthour "acpibat0" "0.00" > "Wh" unspecified > 10 "remaining capacity"watthour "acpibat0" "0.00" > "Wh" unspecified > 11"design capacity"watthour "acpibat0" "0.00" > "Wh" unspecified > 12"battery removed" raw "acpibat0" "0" > "" unspecified > 13"voltage" voltsdc "acpibat1" "0.00" > "V DC" unspecified > 14"current voltage" voltsdc "acpibat1" "0.00" > "V DC" unspecified > 15 "rate" power "acpibat1" "0.00" > "W" unspecified > 16 "last full capacity"watthour "acpibat1" "0.00" > "Wh" unspecified > 17 "warning capacity"watthour "acpibat1" "0.00" > "Wh" unspecified > 18 "low capacity"watthour "acpibat1" "0.00" > "Wh" unspecified > 19 "remaining capacity"watthour "acpibat1" "0.00" > "Wh" unspecified > 20"design capacity"watthour "acpibat1" "0.00" > "Wh" unspecified > 21"battery removed" raw "acpibat1" "0" > "" unspecified > 22"voltage" voltsdc "acpibat2" "0.00" > "V DC" unspecified > 23"current voltage" voltsdc "acpibat2" "0.00" > "V DC" unspecified > 24 "rate" power "acpibat2" "0.00" > "W" unspecified > 25 "last full capacity"watthour "acpibat2" "0.00" > "Wh" unspecified > 26 "warning capacity"watthour "acpibat2" "0.00" > "Wh" unspecified > 27 "low capacity"watthour "acpibat2" "0.00" > "Wh" unspecified > 28 "remaining capacity"watthour "acpibat2" "0.00" > "Wh" unspecified > 29"design capacity"watthour "acpibat2" "0.00" > "Wh" unspecified > 30"battery removed" raw "acpibat2" "0" > "" unspecified > 31 "temp0" temperature"sdtemp0" "34.50" > "degC" unspecified > 32 "temp0" temperature"sdtemp1" "33.75" > "degC" unspecified > 33 "inner" temperature "ugold0" "21.25" > "degC" unspecified > 34"sd3" drive "softraid0""online" > "" ok > --
Re: em(4) watchdog timeouts
Hi Gregor, Thank you for your feedback. Did you have some timeout on 5.6 ? On amd64 version, I experienced some on heavy network load. Is it related ? Regards, Alexis VACHETTE. On 11/11/2015 21:19, Gregor Best wrote: Hi Alexis, On Wed, Nov 11, 2015 at 08:11:15PM +, Alexis VACHETTE wrote: [...] Even with heavy network load ? [...] So far, yes. I've saturated the device for about 45 Minutes with something like this (the other end is my laptop): ## on the router $ dd if=/dev/zero bs=8k | nc 172.31.64.174 55000 ## on my laptop $ nc -l 55000 | dd of=/dev/null bs=8k (with two or three streams in parallel). There were about 6k interrupts per second and bandwidth was about 250Mbps, which seems to be the maximum the tiny CPU in this router can do. No watchdog timeouts appeared, where previously something relatively low bandwidth (the SSDs in router and laptop suck) like this caused one every 20 or 30 seconds: ## on the router $ pax -w /home | nc 172.31.64.174 55000 I'll keep an eye on things, but so far it looks good. Regular usage works out so far as well. If you need me to run some special workload for you, I'd be more than happy to do that.
Re: em(4) watchdog timeouts
Hi Gregor, I use the same revision than yours : - "Intel 82583V" rev 0x00: msi Regards, Alexis VACHETTE.* * On 16/11/2015 10:12, Alexis VACHETTE wrote: Hi Gregor, Thank you for your feedback. Did you have some timeout on 5.6 ? On amd64 version, I experienced some on heavy network load. Is it related ? Regards, Alexis VACHETTE. On 11/11/2015 21:19, Gregor Best wrote: Hi Alexis, On Wed, Nov 11, 2015 at 08:11:15PM +, Alexis VACHETTE wrote: [...] Even with heavy network load ? [...] So far, yes. I've saturated the device for about 45 Minutes with something like this (the other end is my laptop): ## on the router $ dd if=/dev/zero bs=8k | nc 172.31.64.174 55000 ## on my laptop $ nc -l 55000 | dd of=/dev/null bs=8k (with two or three streams in parallel). There were about 6k interrupts per second and bandwidth was about 250Mbps, which seems to be the maximum the tiny CPU in this router can do. No watchdog timeouts appeared, where previously something relatively low bandwidth (the SSDs in router and laptop suck) like this caused one every 20 or 30 seconds: ## on the router $ pax -w /home | nc 172.31.64.174 55000 I'll keep an eye on things, but so far it looks good. Regular usage works out so far as well. If you need me to run some special workload for you, I'd be more than happy to do that.
Re: Exclude invalid sensors from the sensors MIB
On 2015/11/17 11:47, Gerhard Roth wrote: > Sensors marked as invalid should be excluded by snmpd(8) from the sensors > MIB just as sysctl(8) excludes them from the 'hw.sensors' tree. Agreed - any OKs to commit? After: $ snmptable -v2c -c public 127.0.0.1 sensorTable SNMP table: OPENBSD-SENSORS-MIB::sensorTable sensorIndexsensorDescr sensorType sensorDevice sensorValue sensorUnits sensorStatus 1"temp0" temperature "cpu0" "36.00" "degC" unspecified 2 "zone temperature" temperature"acpitz0" "27.80" "degC" unspecified 3 "zone temperature" temperature"acpitz1" "29.80" "degC" unspecified 4"temp0" temperature"sdtemp0" "34.25" "degC" unspecified 5"temp0" temperature"sdtemp1" "33.50" "degC" unspecified 6"inner" temperature "ugold0" "21.37" "degC" unspecified 7 "sd3" drive "softraid0""online" "" ok Before: $ snmptable -v2c -c public 127.0.0.1 sensorTable SNMP table: OPENBSD-SENSORS-MIB::sensorTable sensorIndex sensorDescr sensorType sensorDevice sensorValue sensorUnits sensorStatus 1 "temp0" temperature "cpu0" "38.00" "degC" unspecified 2 "zone temperature" temperature"acpitz0" "27.80" "degC" unspecified 3 "zone temperature" temperature"acpitz1" "29.80" "degC" unspecified 4"voltage" voltsdc "acpibat0" "0.00" "V DC" unspecified 5"current voltage" voltsdc "acpibat0" "0.00" "V DC" unspecified 6 "rate" power "acpibat0" "0.00" "W" unspecified 7 "last full capacity"watthour "acpibat0" "0.00" "Wh" unspecified 8 "warning capacity"watthour "acpibat0" "0.00" "Wh" unspecified 9 "low capacity"watthour "acpibat0" "0.00" "Wh" unspecified 10 "remaining capacity"watthour "acpibat0" "0.00" "Wh" unspecified 11"design capacity"watthour "acpibat0" "0.00" "Wh" unspecified 12"battery removed" raw "acpibat0" "0" "" unspecified 13"voltage" voltsdc "acpibat1" "0.00" "V DC" unspecified 14"current voltage" voltsdc "acpibat1" "0.00" "V DC" unspecified 15 "rate" power "acpibat1" "0.00" "W" unspecified 16 "last full capacity"watthour "acpibat1" "0.00" "Wh" unspecified 17 "warning capacity"watthour "acpibat1" "0.00" "Wh" unspecified 18 "low capacity"watthour "acpibat1" "0.00" "Wh" unspecified 19 "remaining capacity"watthour "acpibat1" "0.00" "Wh" unspecified 20"design capacity"watthour "acpibat1" "0.00" "Wh" unspecified 21"battery removed" raw "acpibat1" "0" "" unspecified 22"voltage" voltsdc "acpibat2" "0.00" "V DC" unspecified 23"current voltage" voltsdc "acpibat2" "0.00" "V DC" unspecified 24 "rate" power "acpibat2" "0.00" "W" unspecified 25 "last full capacity"watthour "acpibat2" "0.00" "Wh" unspecified 26 "warning capacity"watthour "acpibat2" "0.00" "Wh" unspecified 27 "low capacity"watthour "acpibat2" "0.00" "Wh" unspecified 28 "remaining capacity"watthour "acpibat2" "0.00" "Wh" unspecified 29"design capacity"watthour "acpibat2" "0.00" "Wh" unspecified 30"battery removed" raw "acpibat2" "0" "" unspecified 31 "temp0" temperature"sdtemp0" "34.50" "degC" unspecified 32 "temp0" temperature"sdtemp1" "33.75" "degC" unspecified 33 "inner" temperature "ugold0" "21.25" "degC" unspecified 34"sd3" drive "softraid0""online" "" ok
Exclude invalid sensors from the sensors MIB
Sensors marked as invalid should be excluded by snmpd(8) from the sensors
MIB just as sysctl(8) excludes them from the 'hw.sensors' tree.
Gerhard
Index: usr.sbin/snmpd/mib.c
===
RCS file: /cvs/src/usr.sbin/snmpd/mib.c,v
retrieving revision 1.79
diff -u -p -u -p -r1.79 mib.c
--- usr.sbin/snmpd/mib.c8 Oct 2015 08:29:21 - 1.79
+++ usr.sbin/snmpd/mib.c17 Nov 2015 10:39:31 -
@@ -2556,7 +2556,7 @@ mib_sensors(struct oid *oid, struct ber_
}
for (j = 0; j < SENSOR_MAX_TYPES; j++) {
mib[3] = j;
- for (k = 0; k < sensordev.maxnumt[j]; k++, n++) {
+ for (k = 0; k < sensordev.maxnumt[j]; k++) {
mib[4] = k;
if (sysctl(mib, 5,
&sensor, &slen, NULL, 0) == -1) {
@@ -2566,8 +2566,11 @@ mib_sensors(struct oid *oid, struct ber_
break;
return (-1);
}
+ if (sensor.flags & SENSOR_FINVALID)
+ continue;
if (n == idx)
goto found;
+ n++;
}
}
}
printf(3) wording
I am not a native speaker, but the conversion specifiers are "interpreted" by printf, not "interpolated", right? Jan Index: printf.3 === RCS file: /cvs/src/lib/libc/stdio/printf.3,v retrieving revision 1.74 diff -u -p -r1.74 printf.3 --- printf.313 Oct 2015 12:25:04 - 1.74 +++ printf.317 Nov 2015 09:36:19 - @@ -852,7 +852,7 @@ This holds true even if the string has b using a function like .Fn snprintf , as the resulting string may still contain user-supplied conversion specifiers -for later interpolation by +for later interpretation by .Fn printf . .Pp Be sure to use the proper secure idiom:
Re: pledge for tetris
On Tue, Nov 17, 2015 at 12:21:32AM -0500, Michael McConville wrote: Ted Unangst wrote: Theo Buehler wrote: > drop the score file support No way! this is critical functionality. :) Seconded. :P I disagree - the obvious solution is to move tetris to ports for anyone who needs score file support, and for Ted to write a new cut down alternative version to go in base. -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
Re: fdisk(8) -l -c -h -s manpage bits
On Nov 14 14:17:08, k...@openbsd.org wrote: > Modified files: > sbin/fdisk : disk.c fdisk.c > > Log message: > Since -l is ignored if -c/-h/-s are specified, make that combination > invalid and mention the constraint in usage(). Mention it in the manpage too. Jan Index: fdisk.8 === RCS file: /cvs/src/sbin/fdisk/fdisk.8,v retrieving revision 1.87 diff -u -p -r1.87 fdisk.8 --- fdisk.8 26 Oct 2015 18:05:25 - 1.87 +++ fdisk.8 17 Nov 2015 08:34:38 - @@ -79,6 +79,8 @@ These figures are taken from the in-core or values that .Em /boot has passed to the kernel. +These options are mutually exclusive with +.Fl l . .It Fl e Use the .Nm @@ -127,6 +129,8 @@ can be specified. .It Fl l Ar blocks Specify the number of blocks in the disk, and force the MBR to be in LBA mode only. +This option is mutually exclusive with +.Fl c h s . .It Fl u Update MBR bootcode, preserving existing MBR partition table. The MBR bootcode extends from offset 0x000 to the start of the MBR partition
apmd ignoring ENXIO on /dev/apmctl
Upon startup, apmd(8) opens /dev/apmctl like this:
if ((ctl_fd = open(fname, O_RDWR | O_CLOEXEC)) == -1) {
if (errno != ENXIO && errno != ENOENT)
error("cannot open device file `%s'", fname);
}
Why is it that we ignore ENXIO and ENOENT here?
apmd(8) seems to go on using the fd as if opening successfully.
Jan
