Re: patch: nm(1): add support for symbols created with -ffunction-sections

2021-11-06 Thread Antoine Jacoutot
On Sat, Nov 06, 2021 at 03:20:03PM +0100, Sebastien Marie wrote:
> Hi,
> 
> aja@ shows me some problems with x11/gnome/librsvg update (the port is
> Rust based), and I finally tracked the problem inside nm(1).
> 
> I will not speak of Rust anymore, and will use only C for the example.
> 
> When an object is compiled using -ffunction-sections, the
> compiler/linker will use one section per function (if I correctly
> understood the usual purpose, it is to be able to easily discard
> unused sections/functions at linking time).
> 
> $ cat test.c
> #include 
> 
> void
> test_fn(void)
> {
>   printf("test_fn()\n");
> }
> 
> $ cc -Wall -c test.c -ffunction-sections
> $ readelf --sections test.o | grep -A1 test_fn
>   [ 3] .text.test_fn PROGBITS   0040
>0040    AX   0 0 16
> $ readelf -s test.o
> 
> Symbol table '.symtab' contains 8 entries:
>Num:Value  Size TypeBind   Vis  Ndx Name
>  0:  0 NOTYPE  LOCAL  DEFAULT  UND
>  1:  0 FILELOCAL  DEFAULT  ABS test.c
>  2: 11 OBJECT  LOCAL  DEFAULT7 .L.str
>  3:  0 SECTION LOCAL  DEFAULT3
>  4: 24 FUNCWEAK   HIDDEN 6 
> __llvm_retpoline_r11
>  5:  8 OBJECT  WEAK   HIDDEN 9 __retguard_759
>  6:  0 NOTYPE  GLOBAL DEFAULT  UND printf
>  7: 64 FUNCGLOBAL DEFAULT3 test_fn
>  
> 
> The problem is nm(1) doesn't recognize the test_fn type as a TEXT function:
> 
> $ nm test.o
>  d .L.str
>  W __llvm_retpoline_r11
>  W __retguard_759
>  U printf
>  F test.c
>  ? test_fn
> 
> test_fn symbol should be 'T', but it is reported as '?'.
> 
> 
> llvm-nm(1) is working correctly (but we don't have it in base):
> 
> $ llvm-nm test.o
>  r .L.str
>  W __llvm_retpoline_r11
>  V __retguard_759
>  U printf
>  T test_fn
>
> 
> 
> The following diff makes nm(1) to properly mark the function 'T', by
> recognize ".text.*" sections:
> 
> diff cecccd4b3c548875286ca2b010c95cbce6c0e359 /home/semarie/repos/openbsd/src
> blob - 5aeef7a01a7cbff029299cfc5562cfcec085347f
> file + usr.bin/nm/elf.c
> --- usr.bin/nm/elf.c
> +++ usr.bin/nm/elf.c
> @@ -274,6 +274,8 @@ elf_shn2type(Elf_Ehdr *eh, u_int shn, const char *sn)
>   return (-1);
>   else if (!strcmp(sn, ELF_TEXT))
>   return (N_TEXT);
> + else if (!strncmp(sn, ".text.", 6))
> + return (N_TEXT);
>   else if (!strcmp(sn, ELF_RODATA))
>   return (N_SIZE);
>   else if (!strcmp(sn, ELF_OPENBSDRANDOMDATA))
> @@ -355,6 +357,7 @@ elf2nlist(Elf_Sym *sym, Elf_Ehdr *eh, Elf_Shdr *shdr, 
>   } else if (sn != NULL && *sn != 0 &&
>   strcmp(sn, ELF_INIT) &&
>   strcmp(sn, ELF_TEXT) &&
> + strncmp(sn, ".text.", 6) &&
>   strcmp(sn, ELF_FINI))   /* XXX GNU compat */
>   np->nl.n_other = '?';
>   break;
> 
> The change on elf_shn2type() isn't strictly necessary for my use-case,
> but it (should) makes .text.* support better (recognize N_TEXT for
> STT_NOTYPE, STT_OBJECT, STT_TLS).
> 
> 
> After, nm(1) properly recognize the symbol:
> 
> $ /usr/obj/usr.bin/nm/nm test.o
>  d .L.str
>  W __llvm_retpoline_r11
>  W __retguard_759
>  U printf
>  F test.c
>  T test_fn
> 
> and it makes libtool(1) happy (LT/Archive.pm: get_symbollist
> function), and it makes librsvg build happy (which is playing with
> symbols at build time), and it should makes aja@ happy too.
> 
> Comments or OK ?

You made me happy :-)

-- 
Antoine



Re: new option for rcctl ls

2021-10-23 Thread Antoine Jacoutot
On Fri, Oct 22, 2021 at 07:27:28PM +0100, Stuart Henderson wrote:
> On 2021/10/22 12:56, Stuart Henderson wrote:
> > On 2021/10/22 12:20, Antoine Jacoutot wrote:
> > > On Thu, Oct 21, 2021 at 04:45:47PM +0100, Stuart Henderson wrote:
> > > > Sometimes I find it useful to list daemons which are set to 'disabled'
> > > > but are actually running. Either those where I have started them by hand
> > > > forgotten to enable in rc.conf.local, or to check for services which
> > > > shouldn't be running but which are anyway. Any comments on this diff
> > > > to add it to rcctl? It's pretty much the opposite of "rcctl ls failed".
> > > 
> > > Hi.
> > > 
> > > I have never had a use for this, so I don't really have an opinion...
> > > I am not super fan of the "off-but-started" option name though.
> > 
> > I hate the name but every other idea I had was worse :)
> 
> Ingo had a nice suggestion:

ok with one comment inline.

> 
> Index: rcctl.8
> ===
> RCS file: /cvs/src/usr.sbin/rcctl/rcctl.8,v
> retrieving revision 1.37
> diff -u -p -r1.37 rcctl.8
> --- rcctl.8   26 Jun 2021 18:02:48 -  1.37
> +++ rcctl.8   22 Oct 2021 18:26:40 -
> @@ -36,7 +36,7 @@
>  .Nm rcctl
>  .Cm ls
>  .Sm off
> -.Cm all | failed | on | off | started | stopped
> +.Cm all | failed | on | off | rogue | started | stopped
>  .Sm on
>  .Sh DESCRIPTION
>  The
> @@ -123,6 +123,8 @@ enabled but stopped daemons
>  disabled services and daemons
>  .It Cm on
>  enabled services and daemons
> +.It Cm rogue
> +services and daemons which are disabled but currently running

You can drop services.

>  .It Cm started
>  running daemons
>  .It Cm stopped
> Index: rcctl.sh
> ===
> RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
> retrieving revision 1.110
> diff -u -p -r1.110 rcctl.sh
> --- rcctl.sh  27 Feb 2021 09:28:04 -  1.110
> +++ rcctl.sh  22 Oct 2021 18:26:40 -
> @@ -35,7 +35,7 @@ usage()
>   "usage: rcctl get|getdef|set service | daemon [variable [arguments]]
>   rcctl [-df] ${_a} daemon ...
>   rcctl disable|enable|order [daemon ...]
> - rcctl ls all|failed|off|on|started|stopped"
> + rcctl ls all|failed|off|on|rogue|started|stopped"
>  }
>  
>  needs_root()
> @@ -228,6 +228,13 @@ svc_ls()
>   unset _on
>   done
>   ;;
> + rogue)
> + for _svc in $(svc_ls off); do
> + ! svc_is_special ${_svc} && \
> + /etc/rc.d/${_svc} check >/dev/null && \
> + echo ${_svc} && _ret=1
> + done
> + ;;
>   started|stopped)
>   for _svc in $(ls_rcscripts); do
>   /etc/rc.d/${_svc} check >/dev/null && _started=1
> @@ -502,7 +509,7 @@ ret=0
>  case ${action} in
>   ls)
>   lsarg=$2
> - [[ ${lsarg} == @(all|failed|off|on|started|stopped) ]] || usage
> + [[ ${lsarg} == @(all|failed|off|on|rogue|started|stopped) ]] || 
> usage
>   ;;
>   order)
>   shift 1
> 

-- 
Antoine



Re: new option for rcctl ls

2021-10-22 Thread Antoine Jacoutot
On Thu, Oct 21, 2021 at 04:45:47PM +0100, Stuart Henderson wrote:
> Sometimes I find it useful to list daemons which are set to 'disabled'
> but are actually running. Either those where I have started them by hand
> forgotten to enable in rc.conf.local, or to check for services which
> shouldn't be running but which are anyway. Any comments on this diff
> to add it to rcctl? It's pretty much the opposite of "rcctl ls failed".

Hi.

I have never had a use for this, so I don't really have an opinion...
I am not super fan of the "off-but-started" option name though.


> 
> Index: rcctl.8
> ===
> RCS file: /cvs/src/usr.sbin/rcctl/rcctl.8,v
> retrieving revision 1.37
> diff -u -p -r1.37 rcctl.8
> --- rcctl.8   26 Jun 2021 18:02:48 -  1.37
> +++ rcctl.8   21 Oct 2021 15:42:13 -
> @@ -36,7 +36,7 @@
>  .Nm rcctl
>  .Cm ls
>  .Sm off
> -.Cm all | failed | on | off | started | stopped
> +.Cm all | failed | on | off | started | stopped | off-but-started
>  .Sm on
>  .Sh DESCRIPTION
>  The
> @@ -119,6 +119,8 @@ which can be one of:
>  all services and daemons
>  .It Cm failed
>  enabled but stopped daemons
> +.It Cm off-but-started
> +services and daemons which are disabled but currently running
>  .It Cm off
>  disabled services and daemons
>  .It Cm on
> Index: rcctl.sh
> ===
> RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
> retrieving revision 1.110
> diff -u -p -r1.110 rcctl.sh
> --- rcctl.sh  27 Feb 2021 09:28:04 -  1.110
> +++ rcctl.sh  21 Oct 2021 15:42:13 -
> @@ -35,7 +35,7 @@ usage()
>   "usage: rcctl get|getdef|set service | daemon [variable [arguments]]
>   rcctl [-df] ${_a} daemon ...
>   rcctl disable|enable|order [daemon ...]
> - rcctl ls all|failed|off|on|started|stopped"
> + rcctl ls all|failed|off|on|started|stopped|off-but-started"
>  }
>  
>  needs_root()
> @@ -212,6 +212,13 @@ svc_ls()
>   echo ${_special_svcs} | tr "[:blank:]" "\n"
>   ) | sort
>   ;;
> + off-but-started)
> + for _svc in $(svc_ls off); do
> + ! svc_is_special ${_svc} && \
> + /etc/rc.d/${_svc} check >/dev/null && \
> + echo ${_svc} && _ret=1
> + done
> + ;;
>   failed)
>   for _svc in $(svc_ls on); do
>   ! svc_is_special ${_svc} && \
> @@ -502,7 +509,7 @@ ret=0
>  case ${action} in
>   ls)
>   lsarg=$2
> - [[ ${lsarg} == @(all|failed|off|on|started|stopped) ]] || usage
> + [[ ${lsarg} == 
> @(all|failed|off|on|started|stopped|off-but-started) ]] || usage
>   ;;
>   order)
>   shift 1
> 

-- 
Antoine



Re: rc(8): start unwind earlier

2021-01-29 Thread Antoine Jacoutot
On Fri, Jan 29, 2021 at 04:53:34PM +0100, Florian Obser wrote:
> Start unwind earlier.
> 
> OK?
> 
> diff --git rc rc
> index 94465add54f..7b5f835f0af 100644
> --- rc
> +++ rc
> @@ -442,6 +442,7 @@ fill_baddynamic tcp
>  sysctl_conf
>  
>  start_daemon slaacd >/dev/null 2>&1
> +start_daemon unwind >/dev/null 2>&1

you could do it all in 1 line :-)
start_daemon slaacd unwind >/dev/null 2>&1

>  
>  echo 'starting network'
>  
> @@ -454,8 +455,6 @@ sh /etc/netstart
>  mount -s /usr >/dev/null 2>&1
>  mount -s /var >/dev/null 2>&1
>  
> -start_daemon unwind >/dev/null 2>&1
> -
>  # Load pf rules and bring up pfsync interface.
>  if [[ $pf != NO ]]; then
>   if [[ -f /etc/pf.conf ]]; then
> 
> 
> -- 
> I'm not entirely sure you are real.
> 

-- 
Antoine



Re: Improving the syspatch(8) and sysupgrade(8) test for the invoking user's privileges

2021-01-29 Thread Antoine Jacoutot
On Fri, Jan 29, 2021 at 03:31:10AM -0500, Horia Racoviceanu wrote:
> Hi,
> 
> I noticed the syspatch(8) and sysupgrade(8) ksh scripts test if the
> invoking user has the right privileges i.e. (($(id -u) != 0))
> 
> The test for the effective user ID number can be bypassed in
> syspatch(8) and sysupgrade(8) by sh e.g.
> $ id -u
> 1000
> $ sh /usr/sbin/sysupgrade -s
> /usr/sbin/sysupgrade[90]: 1000: not found
> install: /home/_sysupgrade: Permission denied
> $ sh /usr/sbin/syspatch -r
> [snip]
> /usr/sbin/syspatch[280]: 1000: not found
> Reverting patch 012_carp
> [snip]
> 
> The syspatch(8) and sysupgrade(8) test for the EUID number could be
> improved by adding "set +o sh" (see netstart(8)) or by using the
> "[[expression]]" test (see sysmerge(8)) or "[expression]" test (see
> rcctl(8)) instead of "((expression))" e.g. [ "$(id -u)" -ne 0 ]
> 
> Moreover, other scripts could benefit from the addition of the
> above-mentioned test for the EUID number e.g. daily(8), weekly(8), and
> monthly(8) which are intended to run as root e.g.
> $ id -u
> 1000
> $ sh /etc/weekly
> install: /var/log/INS@FJvExvWnUh: Permission denied
> [snip]

But these are ksh(1) scripts, not strict sh(1); so they are not meant to be run
with "sh syspatch".
Like you wouldn't run them with python or perl.


> [1] http://man.openbsd.org/ksh#__
> [2] http://man.openbsd.org/ksh#test~2
> [3] http://man.openbsd.org/ksh#Strict_Bourne_shell_mode

> Index: syspatch.sh
> ===
> RCS file: /cvs/src/usr.sbin/syspatch/syspatch.sh,v
> retrieving revision 1.167
> diff -u -p -r1.167 syspatch.sh
> --- syspatch.sh   7 Dec 2020 21:19:28 -   1.167
> +++ syspatch.sh   29 Jan 2021 08:04:08 -
> @@ -276,7 +276,7 @@ set -A _KERNV -- $(sysctl -n kern.versio
>  ((${#_KERNV[*]} > 1)) && err "Unsupported release: ${_KERNV[0]}${_KERNV[1]}"
>  
>  [[ $@ == @(|-[[:alpha:]]) ]] || usage; [[ $@ == @(|-(c|R|r)) ]] &&
> - (($(id -u) != 0)) && err "need root privileges"
> + [ "$(id -u)" -ne 0 ] && err "need root privileges"
>  [[ $@ == @(|-(R|r)) ]] && pgrep -qxf '/bin/ksh .*reorder_kernel' &&
>   err "cannot apply patches while reorder_kernel is running"
>  

> Index: sysupgrade.sh
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
> retrieving revision 1.44
> diff -u -p -r1.44 sysupgrade.sh
> --- sysupgrade.sh 22 Oct 2020 07:19:42 -  1.44
> +++ sysupgrade.sh 29 Jan 2021 07:53:31 -
> @@ -89,7 +89,7 @@ while getopts fknrs arg; do
>   esac
>  done
>  
> -(($(id -u) != 0)) && err "need root privileges"
> +[ "$(id -u)" -ne 0 ] && err "need root privileges"
>  
>  if $RELEASE && $SNAP; then
>   usage

> Index: daily
> ===
> RCS file: /cvs/src/etc/daily,v
> retrieving revision 1.95
> diff -u -p -r1.95 daily
> --- daily 20 Oct 2020 22:42:29 -  1.95
> +++ daily 29 Jan 2021 08:08:44 -
> @@ -9,6 +9,7 @@ umask 022
>  
>  PARTOUT=/var/log/daily.part
>  MAINOUT=/var/log/daily.out
> +[ "$(id -u)" -ne 0 ] && echo "${0##*/}: need root privileges" && exit 1
>  install -o 0 -g 0 -m 600/dev/null $PARTOUT
>  install -o 0 -g 0 -m 600 -b /dev/null $MAINOUT
>  


-- 
Antoine



Re: syspatch exit state

2020-12-07 Thread Antoine Jacoutot
On Mon, Dec 07, 2020 at 01:30:55PM +0100, Ingo Schwarze wrote:
> Hello Antoine,
> 
> Antoine Jacoutot wrote on Mon, Dec 07, 2020 at 01:01:27PM +0100:
> 
> > I just tested this change and it seems to work:
> 
> I did not repeat my testing, but here is some quick feedback purely
> from code inspection:
> 
> The proposed code change makes sense to me.
> 
> The proposed manual page text might allow the misconception that
> the tool will always exit 2 if no additional patch was installed,
> including when -c, -l, or -r was specified.
> 
> I think a slightly more explicit wording might make such a
> misunderstanding less likely, for example:
> 
>   .Sh EXIT STATUS
>   .Ex -std syspatch
>   In particular, 2 indicates that applying patches was requested
>   but no additional patch was installed.
> 
> With non-standard meanings of exit codes, i think it is worthwhile
> to be as precise as possible.

Sure that's fine as well.
I did change it to your initial proposal; but careful, since you're a doc master
I will put whatever you send my way ;-)

Index: syspatch.8
===
RCS file: /cvs/src/usr.sbin/syspatch/syspatch.8,v
retrieving revision 1.21
diff -u -p -r1.21 syspatch.8
--- syspatch.8  25 Jul 2020 15:45:44 -  1.21
+++ syspatch.8  7 Dec 2020 12:39:07 -
@@ -64,6 +64,8 @@ of installed patches.
 .El
 .Sh EXIT STATUS
 .Ex -std syspatch
+In particular, 2 indicates that applying patches was requested but no
+additional patch was installed.
 .Sh SEE ALSO
 .Xr signify 1 ,
 .Xr installurl 5 ,
Index: syspatch.sh
===
RCS file: /cvs/src/usr.sbin/syspatch/syspatch.sh,v
retrieving revision 1.166
diff -u -p -r1.166 syspatch.sh
--- syspatch.sh 27 Oct 2020 17:42:05 -  1.166
+++ syspatch.sh 7 Dec 2020 12:39:07 -
@@ -320,6 +320,7 @@ if ((OPTIND == 1)); then
[[ -f ${_D}/rollback.tgz ]] || rm -r ${_D}
done
_PATCHES=$(ls_missing) # can't use errexit in a for loop
+   [[ -n ${_PATCHES} ]] || exit 2
for _PATCH in ${_PATCHES}; do
apply_patch ${_OSrev}-${_PATCH}
_PATCH_APPLIED=true


-- 
Antoine



Re: syspatch exit state

2020-12-07 Thread Antoine Jacoutot
On Mon, Dec 07, 2020 at 11:54:04AM +0100, Ingo Schwarze wrote:
> > Index: syspatch.sh
> > ===
> > RCS file: /cvs/src/usr.sbin/syspatch/syspatch.sh,v
> > retrieving revision 1.166
> > diff -u -p -r1.166 syspatch.sh
> > --- syspatch.sh 27 Oct 2020 17:42:05 -  1.166
> > +++ syspatch.sh 7 Dec 2020 08:47:48 -
> > @@ -248,7 +248,8 @@ must be run manually to install the new 
> > fi
> > fi
> >  
> > -   ${_PATCH_APPLIED} && echo "Errata can be reviewed under ${_PDIR}"
> > +   ${_PATCH_APPLIED} && echo "Errata can be reviewed under ${_PDIR}" ||
> > +   return 2
> 
> This doesn't appear to work unless i screwed up my testing.
> Even if _PATCH_APPLIED==false, syspatch still exits 0 for me.
> The return value of the trap function doesn't appear to affect
> the exit status of the script.

<...>

> Listing patches is an error no matter whether or not patches are
> available, no matter whether these patches are already installed
> or not?
> 
> I doubt the patch is ready for commit in its present state.

It wasn't meant for commit just yet :-)
Thanks for the feedback.

I just tested this change and it seems to work:

Index: syspatch.8
===
RCS file: /cvs/src/usr.sbin/syspatch/syspatch.8,v
retrieving revision 1.21
diff -u -p -r1.21 syspatch.8
--- syspatch.8  25 Jul 2020 15:45:44 -  1.21
+++ syspatch.8  7 Dec 2020 11:58:06 -
@@ -64,6 +64,7 @@ of installed patches.
 .El
 .Sh EXIT STATUS
 .Ex -std syspatch
+2 indicates that no additional patch was installed.
 .Sh SEE ALSO
 .Xr signify 1 ,
 .Xr installurl 5 ,
Index: syspatch.sh
===
RCS file: /cvs/src/usr.sbin/syspatch/syspatch.sh,v
retrieving revision 1.166
diff -u -p -r1.166 syspatch.sh
--- syspatch.sh 27 Oct 2020 17:42:05 -  1.166
+++ syspatch.sh 7 Dec 2020 11:58:06 -
@@ -320,6 +320,7 @@ if ((OPTIND == 1)); then
[[ -f ${_D}/rollback.tgz ]] || rm -r ${_D}
done
_PATCHES=$(ls_missing) # can't use errexit in a for loop
+   [[ -n ${_PATCHES} ]] || exit 2
for _PATCH in ${_PATCHES}; do
apply_patch ${_OSrev}-${_PATCH}
_PATCH_APPLIED=true




-- 
Antoine



Re: syspatch exit state

2020-12-07 Thread Antoine Jacoutot
On Sun, Dec 06, 2020 at 10:52:37PM +0100, Alexander Hall wrote:
> 
> 
> On December 6, 2020 8:13:26 PM GMT+01:00, Antoine Jacoutot 
>  wrote:
> >On Sun, Dec 06, 2020 at 05:20:31PM +, Stuart Henderson wrote:
> >> On 2020/12/06 16:39, Otto Moerbeek wrote:
> >> > On Sun, Dec 06, 2020 at 03:31:19PM +, SW wrote:
> >> > 
> >> > > On 06/12/2020 14:32, Otto Moerbeek wrote:
> >> > > > On Sun, Dec 06, 2020 at 02:19:05PM +, SW wrote:
> >> > > >
> >> > > >> Hi,
> >> > > >> I've been looking to have syspatch give me a quick indication
> >of whether
> >> > > >> a reboot is likely to be required. As a quick and dirty check,
> >I've just
> >> > > >> been treating "Were patches applied?" as the indicator.
> >> > > >>
> >> > > >> The following diff will cause syspatch to exit when applying
> >patches
> >> > > >> with status code 0 only if patches were actually applied.
> >> > > >>
> >> > > >> My biggest concern is that it does cause a change in
> >behaviour, so
> >> > > >> perhaps this either needs making into an option or a different
> >approach
> >> > > >> entirely?
> >> > > >>
> >> > > >> --- syspatch    Sun Dec  6 14:11:12 2020
> >> > > >> +++ syspatch    Sun Dec  6 14:10:23 2020
> >> > > >> @@ -323,3 +323,9 @@ if ((OPTIND == 1)); then
> >> > > >>     _PATCH_APPLIED=true
> >> > > >>     done
> >> > > >>  fi
> >> > > >> +
> >> > > >> +if [ "$_PATCH_APPLIED" = "true" ]; then
> >> > > >> +   exit 0
> >> > > >> +else
> >> > > >> +   exit 1
> >> > > >> +fi
> >> > > >>
> >> > > >> Thanks,
> >> > > >> S
> >> > > >>
> >> > > > I don't this is correct since it maks syspatch exit 1 on "no
> >patches applied".
> >> > > >
> >> > > >  -Otto
> >> > > > .
> >> > > That's precisely the idea- from previous discussion with a couple
> >of
> >> > > people there didn't seem to be an easy (programmatic) way to
> >figure out
> >> > > whether syspatch had done anything or not.
> >> > 
> >> > exit code 1 normally used for error conditions. A system being
> >> > up-to-date is not an error condition. 
> >> > 
> >> >  -Otto
> >> > 
> >> > 
> >> > > 
> >> > > Doing this would be a bit of a blunt way of handling things, and
> >perhaps
> >> > > it would be better gated behind a flag, but is there a better way
> >to
> >> > > make a scripted update work automatically (including rebooting as
> >> > > necessary)?
> >> > > 
> >> > > Thanks,
> >> > > S
> >> > 
> >> 
> >> How about the same exit codes as acme-client? They seem fairly
> >> reasonable - 0=updated, 1=failure, 2=no change.
> >
> >I wouldn't object to that.
> 
> So that'd boil down to
> 
> $_PATCH_APPLIED || exit 4
> 
> or
> 
> $_PATCH_APPLIED && exit
> exit 4
> 
> ...if the explicit exit feels better instead of just running to the end of 
> the script.
> 
> But maybe this script prefers some more verbosity... :-)

Something like this?

Index: syspatch.8
===
RCS file: /cvs/src/usr.sbin/syspatch/syspatch.8,v
retrieving revision 1.21
diff -u -p -r1.21 syspatch.8
--- syspatch.8  25 Jul 2020 15:45:44 -  1.21
+++ syspatch.8  7 Dec 2020 08:47:48 -
@@ -64,6 +64,7 @@ of installed patches.
 .El
 .Sh EXIT STATUS
 .Ex -std syspatch
+2 indicates that no patch is available.
 .Sh SEE ALSO
 .Xr signify 1 ,
 .Xr installurl 5 ,
Index: syspatch.sh
===
RCS file: /cvs/src/usr.sbin/syspatch/syspatch.sh,v
retrieving revision 1.166
diff -u -p -r1.166 syspatch.sh
--- syspatch.sh 27 Oct 2020 17:42:05 -  1.166
+++ syspatch.sh 7 Dec 2020 08:47:48 -
@@ -248,7 +248,8 @@ must be run manually to install the new 
fi
fi
 
-   ${_PATCH_APPLIED} && echo "Errata can be reviewed under ${_PDIR}"
+   ${_PATCH_APPLIED} && echo "Errata can be reviewed under ${_PDIR}" ||
+   return 2
 }
 
 unpriv()


-- 
Antoine



Re: syspatch exit state

2020-12-06 Thread Antoine Jacoutot
On Sun, Dec 06, 2020 at 05:20:31PM +, Stuart Henderson wrote:
> On 2020/12/06 16:39, Otto Moerbeek wrote:
> > On Sun, Dec 06, 2020 at 03:31:19PM +, SW wrote:
> > 
> > > On 06/12/2020 14:32, Otto Moerbeek wrote:
> > > > On Sun, Dec 06, 2020 at 02:19:05PM +, SW wrote:
> > > >
> > > >> Hi,
> > > >> I've been looking to have syspatch give me a quick indication of 
> > > >> whether
> > > >> a reboot is likely to be required. As a quick and dirty check, I've 
> > > >> just
> > > >> been treating "Were patches applied?" as the indicator.
> > > >>
> > > >> The following diff will cause syspatch to exit when applying patches
> > > >> with status code 0 only if patches were actually applied.
> > > >>
> > > >> My biggest concern is that it does cause a change in behaviour, so
> > > >> perhaps this either needs making into an option or a different approach
> > > >> entirely?
> > > >>
> > > >> --- syspatch    Sun Dec  6 14:11:12 2020
> > > >> +++ syspatch    Sun Dec  6 14:10:23 2020
> > > >> @@ -323,3 +323,9 @@ if ((OPTIND == 1)); then
> > > >>     _PATCH_APPLIED=true
> > > >>     done
> > > >>  fi
> > > >> +
> > > >> +if [ "$_PATCH_APPLIED" = "true" ]; then
> > > >> +   exit 0
> > > >> +else
> > > >> +   exit 1
> > > >> +fi
> > > >>
> > > >> Thanks,
> > > >> S
> > > >>
> > > > I don't this is correct since it maks syspatch exit 1 on "no patches 
> > > > applied".
> > > >
> > > > -Otto
> > > > .
> > > That's precisely the idea- from previous discussion with a couple of
> > > people there didn't seem to be an easy (programmatic) way to figure out
> > > whether syspatch had done anything or not.
> > 
> > exit code 1 normally used for error conditions. A system being
> > up-to-date is not an error condition. 
> > 
> > -Otto
> > 
> > 
> > > 
> > > Doing this would be a bit of a blunt way of handling things, and perhaps
> > > it would be better gated behind a flag, but is there a better way to
> > > make a scripted update work automatically (including rebooting as
> > > necessary)?
> > > 
> > > Thanks,
> > > S
> > 
> 
> How about the same exit codes as acme-client? They seem fairly
> reasonable - 0=updated, 1=failure, 2=no change.

I wouldn't object to that.

-- 
Antoine



Re: add a section exit status in syspatch.8

2020-07-21 Thread Antoine Jacoutot
On Tue, Jul 21, 2020 at 03:21:24PM +0200, Solene Rapenne wrote:
> this diff adds an EXIT STATUS section to syspatch man page.
> 
> syspatch exit with 1 on errors and 2 if syspatch updates itself.
> 
> If syspatch does nothing (because no syspatch) or install syspatches
> successfully, the exit status is 0 in both case. Should we emphase
> on this? I guess « Did syspatch install something? » is a common
> question and the exit status can't help.

No objection.

> 
> Index: syspatch.8
> ===
> RCS file: /cvs/src/usr.sbin/syspatch/syspatch.8,v
> retrieving revision 1.20
> diff -u -p -r1.20 syspatch.8
> --- syspatch.815 Jun 2019 16:54:19 -  1.20
> +++ syspatch.819 Jul 2020 22:07:40 -
> @@ -62,6 +62,8 @@ Directories containing the rollback tarb
>  .Xr diff 1
>  of installed patches.
>  .El
> +.Sh EXIT STATUS
> +.Ex -std syspatch
>  .Sh SEE ALSO
>  .Xr signify 1 ,
>  .Xr installurl 5 ,
> 
> 

-- 
Antoine



Re: empty rc.firsttime when installing

2020-07-14 Thread Antoine Jacoutot
Hmm. rc.firsttime could be populated in advance by configuration tools and what 
now and in this case you will loose the changes, no?


—
Antoine

> On 14 Jul 2020, at 15:04, Denis Fondras  wrote:
> 
> I was upgrading an EdgeRouter and it restarted multiple times instead of 
> booting
> /bsd
> 
> When I had a chance to boot it correctly, I noticed that sysmerge and 
> fw_update
> were run multiple times.
> 
> This diff avoids filling rc.firsttime and rc.sysmerge.
> 
> 
> Index: distrib/miniroot/install.sub
> ===
> RCS file: /cvs/src/distrib/miniroot/install.sub,v
> retrieving revision 1.1154
> diff -u -p -r1.1154 install.sub
> --- distrib/miniroot/install.sub26 May 2020 16:21:00 -1.1154
> +++ distrib/miniroot/install.sub14 Jul 2020 12:54:27 -
> @@ -2734,6 +2734,9 @@ finish_up() {
>local _kernel_dir=/mnt/usr/share/relink/kernel
>local _kernel=${MDKERNEL:-GENERIC} _syspatch_archs="amd64 arm64 i386"
> 
> +# Empty rc.firsttime
> +echo "" >/mnt/etc/rc.firsttime
> +
># Mount all known swap partitions.  This gives systems with little
># memory a better chance at running 'MAKEDEV all'.
>if [[ -x /mnt/sbin/swapctl ]]; then
> @@ -2812,7 +2815,7 @@ finish_up() {
> 
># Ensure that sysmerge in batch mode is run on reboot.
>[[ $MODE == upgrade ]] &&
> -echo "/usr/sbin/sysmerge -b" >>/mnt/etc/rc.sysmerge
> +echo "/usr/sbin/sysmerge -b" >/mnt/etc/rc.sysmerge
> 
># If a proxy was needed to fetch the sets, use it for fw_update and 
> syspatch
>[[ -n $http_proxy ]] &&
> 



Re: Add note about example dhclient.conf

2020-02-08 Thread Antoine Jacoutot
On Sat, Feb 08, 2020 at 05:33:34PM +0100, Ingo Schwarze wrote:
> Hi,
> 
> i think i said it before:  i hate /etc/examples/ and think that the
> directory ought to be mostly empty.  With the exception of rare
> cases like bgpd(8), where you have to provide a lot of information
> before you can start it in any meaningful way, i consider a deamon
> ill-designed if the configuration is so complicated that a file in
> /etc/examples/ serves any purpose.  Daemons should have a reasonable
> default configuration, such that a configuration file is not needed
> for typical usage, and if people add a configuration file, they
> ought to get away with very few lines.  By the way, acme-client(1)
> is an example where i was happy to recently see people work into just
> that direction.
> 
> Providing example configuration files is an idiotic concept because
> if you copy them into /etc/, you no longer easily see what the
> defaults are, what generic recommendations are, and what was changed
> locally.  It should be made easy to write short configuration files
> from scratch such that they contain absolutely nothing except local
> changes.
> 
> For daemons designed as described, if they have some complicated
> configuration commands for special purposes, a few typical
> examples of these commands can be shown in the EXAMPLES section of
> the manual page.
> 
> Note that in the past, there was no consensus about the above, so
> i'm not suggesting that we move all the examples into the manual
> pages.  I'm only saying *trivial* files in /etc/examples/ should
> be deleted and the content, if any, moved to the manual pages.  Some
> files will no doubt remain, and there is nothing wrong with that.

Agreed.

-- 
Antoine



Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]

2020-01-24 Thread Antoine Jacoutot
Great :-)
Ok aja 

—
Antoine

> On 24 Jan 2020, at 13:02, Stuart Henderson  wrote:
> 
> On 2020/01/23 21:20, Damien Miller wrote:
>>> On Thu, 23 Jan 2020, Damien Miller wrote:
>>> 
 On Thu, 23 Jan 2020, Damien Miller wrote:
>>> 
 What information would you like there? We could put the first N listen
 addrs in the proctitle if that would help.
>>> 
>>> Maybe like this:
>>> 
>>> 63817 ??  S0:00.05 sshd: [listen] on [0.0.0.0]:22, [::]:22, 0 of 
>>> 10-100
>> 
>> antoine@ said this was not sufficient, so please try the following:
>> 
>> 63817 ??  I0:00.09 sshd: /usr/sbin/sshd [listener] 0 of 10-100 
>> startups
> 
> That works - etc/rc.d/sshd diff to match as follows:
> 
> Index: sshd
> ===
> RCS file: /cvs/src/etc/rc.d/sshd,v
> retrieving revision 1.5
> diff -u -p -r1.5 sshd
> --- sshd22 Jan 2020 13:14:51 -1.5
> +++ sshd24 Jan 2020 11:59:52 -
> @@ -6,7 +6,7 @@ daemon="/usr/sbin/sshd"
> 
> . /etc/rc.d/rc.subr
> 
> -pexp="sshd: \[listener\].*"
> +pexp="sshd: ${daemon}${daemon_flags:+ ${daemon_flags}} \[listener\].*"
> 
> rc_reload() {
>${daemon} ${daemon_flags} -t && pkill -HUP -xf "${pexp}"
> 
> 
> 
>> 
>> diff --git a/sshd.c b/sshd.c
>> index f6139fe..b7ed0f3 100644
>> --- a/sshd.c
>> +++ b/sshd.c
>> @@ -240,6 +240,8 @@ void destroy_sensitive_data(void);
>> void demote_sensitive_data(void);
>> static void do_ssh2_kex(struct ssh *);
>> 
>> +static char *listener_proctitle;
>> +
>> /*
>>  * Close all listening sockets
>>  */
>> @@ -1032,9 +1034,9 @@ server_accept_loop(int *sock_in, int *sock_out, int 
>> *newsock, int *config_s)
>> */
>>for (;;) {
>>if (ostartups != startups) {
>> -setproctitle("[listener] %d of %d-%d startups",
>> -startups, options.max_startups_begin,
>> -options.max_startups);
>> +setproctitle("%s [listener] %d of %d-%d startups",
>> +listener_proctitle, startups,
>> +options.max_startups_begin, options.max_startups);
>>ostartups = startups;
>>}
>>if (received_sighup) {
>> @@ -1347,6 +1349,41 @@ accumulate_host_timing_secret(struct sshbuf 
>> *server_cfg,
>>sshbuf_free(buf);
>> }
>> 
>> +static void
>> +xextendf(char **s, const char *sep, const char *fmt, ...)
>> +__attribute__((__format__ (printf, 3, 4))) __attribute__((__nonnull__ 
>> (3)));
>> +static void
>> +xextendf(char **sp, const char *sep, const char *fmt, ...)
>> +{
>> +va_list ap;
>> +char *tmp1, *tmp2;
>> +
>> +va_start(ap, fmt);
>> +xvasprintf(, fmt, ap);
>> +va_end(ap);
>> +
>> +if (*sp == NULL || **sp == '\0') {
>> +free(*sp);
>> +*sp = tmp1;
>> +return;
>> +}
>> +xasprintf(, "%s%s%s", *sp, sep, tmp1);
>> +free(tmp1);
>> +free(*sp);
>> +*sp = tmp2;
>> +}
>> +
>> +static char *
>> +prepare_proctitle(int ac, char **av)
>> +{
>> +char *ret = NULL;
>> +int i;
>> +
>> +for (i = 0; i < ac; i++)
>> +xextendf(, " ", "%s", av[i]);
>> +return ret;
>> +}
>> +
>> /*
>>  * Main program for the daemon.
>>  */
>> @@ -1774,6 +1811,7 @@ main(int ac, char **av)
>>rexec_argv[rexec_argc] = "-R";
>>rexec_argv[rexec_argc + 1] = NULL;
>>}
>> +listener_proctitle = prepare_proctitle(ac, av);
>> 
>>/* Ensure that umask disallows at least group and world write */
>>new_umask = umask(0077) | 0022;
>> 
> 



Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]

2020-01-22 Thread Antoine Jacoutot
On Thu, Jan 23, 2020 at 02:36:43PM +1100, Damien Miller wrote:
> On Wed, 22 Jan 2020, Stuart Henderson wrote:
> 
> > On 2020/01/21 15:39, Damien Miller wrote:
> > > CVSROOT:  /cvs
> > > Module name:  src
> > > Changes by:   d...@cvs.openbsd.org2020/01/21 15:39:57
> > > 
> > > Modified files:
> > >   usr.bin/ssh: sshd.c 
> > > 
> > > Log message:
> > > expose the number of currently-authenticating connections
> > > along with the MaxStartups limit in the proctitle;
> > > suggestion from Philipp Marek, w/ feedback from Craig Miskell
> > > ok dtucker@
> > > 
> > 
> > It's nice to have this information visible, but it brings some problems.
> > You can't now distinguish between multiple sshd processes (e.g. if you
> > run several on different ports it's hard to figure out which one to
> > signal if needed).
> 
> How could you discern between different sshd processes before? Just the
> command-line args?

Yes.
e.g. for 2 different sshd running:
root 92105  0.0  0.0  1360  1296 ??  I  Wed07AM0:00.05 
/usr/sbin/sshd
root 68236  0.0  0.0  1372  1364 ??  S   7:08AM0:00.00 
/usr/sbin/sshd -f /etc/ssh/sshd_config2

> What information would you like there? We could put the first N listen
> addrs in the proctitle if that would help.

Can't we put the args back and append the new things we expose?
That will also be easier to know which currently-authenticating / MaxStartups
sshd process we are talking about if we run several.
proctitle bit us in the arse several times in the past with rc.d.

My 2 cents, maybe I am talking garbage.

-- 
Antoine



Re: syspatch -c as non-root

2019-12-14 Thread Antoine Jacoutot
On Sat, Dec 14, 2019 at 10:12:36AM +0300, Vadim Zhukov wrote:
> 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.
> This way it works, but in the end I want this check either in stock
> Zabbix code, or in our packages. And requirement to modify doas.conf
> ruins all the fun.
> 
> There is another way: writing some SUID script as simple as:
> 
>   #!/bin/sh
>   case $1 in
>   missing-syspatches) syspatch -c;;
>   failed-services) rcctl ls failed;;
>   *) echo "usage: ..." >&2; exit 1;;
>   esac
> 
> This way we could handle all possible future root-is-required cases
> at once. But adding SUID script... is it a Good Thing(TM)?
> 
> But anyway, root-only requirement for listing available syspatches
> seems a bit silly.
> 
> The patch was tested on 6.6. Well, it doesn't apply cleanly to 6.6,
> since "set +e" magic you see arrived in -CURRENT, but tweaked version
> runs smoothly.
> 
> BTW, why do we ever call eval in unpriv()? Without eval, set +e isn't
> needed, FWIW.

I don't really like this.
It defeats the purpose of unpriv which guarantees you that a specific
unprivileged user will be used to run unsafe commands.


> Index: syspatch.sh
> ===
> RCS file: /cvs/src/usr.sbin/syspatch/syspatch.sh,v
> retrieving revision 1.159
> diff -u -p -r1.159 syspatch.sh
> --- syspatch.sh   10 Dec 2019 17:11:06 -  1.159
> +++ syspatch.sh   14 Dec 2019 06:50:20 -
> @@ -179,7 +179,7 @@ ls_missing()
>   ${_MIRROR}/syspatch${_OSrev}-${_p}.tgz"
>   { unpriv ${_cmd} | tar tzf -; } 2>/dev/null | while read _f; do
>   [[ -f /${_f} ]] || continue && echo ${_p} && pkill -u \
> - _syspatch -xf "${_cmd}" || true && break
> + $_USER -xf "${_cmd}" || true && break
>   done
>   done | sort -V
>  }
> @@ -245,22 +245,26 @@ must be run manually to install the new 
>  
>  unpriv()
>  {
> - local _file=$2 _rc=0 _user=_syspatch
> + local _file=$2 _rc=0
>  
>   if [[ $1 == -f && -n ${_file} ]]; then
>   >${_file}
> - chown "${_user}" "${_file}"
> + chown "${_USER}" "${_file}"
>   chmod 0711 ${_TMP}
>   shift 2
>   fi
>   (($# >= 1))
>  
> - # XXX ksh(1) bug; send error code to the caller instead of failing hard
> - set +e
> - eval su -s /bin/sh ${_user} -c "'$@'" || _rc=$?
> - set -e
> -
> - [[ -n ${_file} ]] && chown root "${_file}"
> + if (($(id -u) == 0)); then
> + # XXX ksh(1) bug; send error code to the caller instead of 
> failing hard
> + set +e
> + eval su -s /bin/sh ${_USER} -c "'$@'" || _rc=$?
> + set -e
> +
> + [[ -n ${_file} ]] && chown root "${_file}"
> + else
> + "$@" || _rc=$?
> + fi
>  
>   return ${_rc}
>  }
> @@ -270,7 +274,7 @@ set -A _KERNV -- $(sysctl -n kern.versio
>   sed 's/^OpenBSD \([1-9][0-9]*\.[0-9]\)\([^ ]*\).*/\1 \2/;q')
>  ((${#_KERNV[*]} > 1)) && sp_err "Unsupported release: 
> ${_KERNV[0]}${_KERNV[1]}"
>  
> -[[ $@ == @(|-[[:alpha:]]) ]] || usage; [[ $@ == @(|-(c|R|r)) ]] &&
> +[[ $@ == @(|-[[:alpha:]]) ]] || usage; [[ $@ == @(|-(R|r)) ]] &&
>   (($(id -u) != 0)) && sp_err "need root privileges"
>  [[ $@ == @(|-(R|r)) ]] && pgrep -qxf '/bin/ksh .*reorder_kernel' &&
>   sp_err "cannot apply patches while reorder_kernel is running"
> @@ -290,7 +294,13 @@ _PDIR="/var/syspatch"
>  _TMP=$(mktemp -d -p ${TMPDIR:-/tmp} syspatch.XX)
>  _KARL=false
>  
> -readonly _BSDMP _KERNV _MIRROR _OSrev _PDIR _TMP
> +if (($(id -u) != 0)); then
> + _USER=$(id -nu)
> +else
> + _USER=_syspatch
> +fi
> +
> +readonly _BSDMP _KERNV _MIRROR _OSrev _PDIR _TMP _USER
>  
>  trap 'trap_handler' EXIT
>  trap exit HUP INT TERM
> 

-- 
Antoine



Re: /etc/rc: remove useless cat

2019-11-10 Thread Antoine Jacoutot
On Sun, Nov 10, 2019 at 02:51:32PM +0100, Christian Weisgerber wrote:
> Since /etc/rc uses ksh constructs anyway, we should use $( of $(cat file).
> 
> ok?

OK aja

> 
> Index: rc
> ===
> RCS file: /cvs/src/etc/rc,v
> retrieving revision 1.540
> diff -u -p -r1.540 rc
> --- rc6 Nov 2019 16:26:24 -   1.540
> +++ rc10 Nov 2019 13:48:36 -
> @@ -220,7 +220,7 @@ reorder_libs() {
>   $_install /usr/libexec/ld.so /usr/libexec/ld.so.save
>   $_install ld.so.test $_lib_dir/ld.so
>   else
> - cc -shared -o $_lib $(ls *.so | sort -R) $(cat .ldadd)
> + cc -shared -o $_lib $(ls *.so | sort -R) $(<.ldadd)
>   [[ -s $_lib ]] && file $_lib | fgrep -q 'shared object'
>   LD_BIND_NOW=1 LD_LIBRARY_PATH=$_tmpdir awk 'BEGIN {exit 
> 0}'
>   LD_BIND_NOW=1 LD_LIBRARY_PATH=$_tmpdir openssl \
> @@ -389,7 +389,7 @@ ttyflags -a
>  
>  # Set keyboard encoding.
>  if [[ -x /sbin/kbd && -s /etc/kbdtype ]]; then
> - kbd "$(cat /etc/kbdtype)"
> + kbd "$(  fi
>  
>  wsconsctl_conf
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 

-- 
Antoine



Re: sysupgrade(8) and http_proxy

2019-11-03 Thread Antoine Jacoutot
On Sun, Nov 03, 2019 at 12:16:56PM +0100, Florian Obser wrote:
> I like it, if someone who is fluent in ksh line noise could please
> verify and commit, that would be awesome, thanks.

Why not let the installer handle this? It already has code for it.
sysupgrade ony needs to create the proper auto_upgrade.conf containing the
answer to the proxy question.


> 
> On Fri, Nov 01, 2019 at 09:37:04PM -0400, trondd wrote:
> > Anthony Coulter  wrote:
> > 
> > > Hello @tech,
> > > 
> > > When I manually upgrade OpenBSD using bsd.rd, I have to set http_proxy
> > > to fetch the file sets. When I reboot after installing, fw_update
> > > succeeds because theinstall script was clever enough to export
> > > http_proxy in /etc/rc.firsttime.
> > > 
> > > Unfortunately sysupgrade(8) does not remember that http_proxy was set
> > > when it fetched the file sets, and so when I run sysupgrade I have to
> > > either wait for fw_update to manually time out on first reboot, or kill
> > > it manually with ^C.
> > > 
> > > Adding the line:
> > > 
> > > [ ${http_proxy} ] && echo "export http_proxy=${http_proxy}" 
> > > >>/etc/rc.firsttime
> > > 
> > > to a spot near the bottom of /usr/sbin/sysupgrade fixes my fw_update
> > > problem, at least until the upgrade restores all of my files to their
> > > stock defaults. Is this something we could integrate into the official
> > > repository?
> > > 
> > > Thanks and regards,
> > > Anthony Coulter
> > 
> > Here it is in patch form in case there is interest.  This also pulls in the
> > quote function from install.sub to make sure a proxy username or password is
> > quoted properly.  I haven't tested this since I could only use it at work.
> > 
> > Tim.
> > 
> > 
> > Index: sysupgrade.sh
> > ===
> > RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
> > retrieving revision 1.29
> > diff -u -p -r1.29 sysupgrade.sh
> > --- sysupgrade.sh   26 Oct 2019 04:04:20 -  1.29
> > +++ sysupgrade.sh   2 Nov 2019 00:39:05 -
> > @@ -73,6 +73,16 @@ rmel() {
> > echo -n "$_c"
> >  }
> >  
> > +# Prints the supplied parameters properly escaped for future sh/ksh 
> > parsing.
> > +# Quotes are added if needed, so you should not do that yourself.
> > +quote() (
> > +   # Since this is a subshell we won't pollute the calling namespace.
> > +   for _a; do
> > +   alias Q=$_a; _a=$(alias Q); print -rn -- " ${_a#Q=}"
> > +   done | sed '1s/ //'
> > +   echo
> > +)
> > +
> >  RELEASE=false
> >  SNAP=false
> >  FORCE=false
> > @@ -199,6 +209,9 @@ if ! ${KEEP}; then
> >  rm -f /home/_sysupgrade/{${CLEAN}}
> >  __EOT
> >  fi
> > +
> > +[[ -n $http_proxy ]] &&
> > +   quote export "http_proxy=$http_proxy" >>/etc/rc.firsttime
> >  
> >  install -F -m 700 bsd.rd /bsd.upgrade
> >  sync
> > 
> 
> -- 
> I'm not entirely sure you are real.
> 

-- 
Antoine



Re: Questions about syspatch(8) mtree(8) behaviour

2019-09-03 Thread Antoine Jacoutot
On Mon, Sep 02, 2019 at 08:58:01PM +0200, Hiltjo Posthuma wrote:
> On Mon, Sep 02, 2019 at 12:07:59PM -0600, Theo de Raadt wrote:
> > Hiltjo Posthuma  wrote:
> > 
> > > Hi,
> > > 
> > > I have three questions regarding a behaviour of syspatch(8) with mtree(8).
> > > 
> > > 1. I noticed when applying patches it resets some permissions of new, but 
> > > also of
> > > existing directories on the system using mtree(8).
> > > 
> > > In the shellscript syspatch(8) there is a function:
> > > 
> > > trap_handler():
> > > # in case a patch added a new directory (install -D)
> > > if [[ -n ${_PATCHES} ]]; then
> > > mtree -qdef /etc/mtree/4.4BSD.dist -p / -U >/dev/null
> > > [[ -f /var/sysmerge/xetc.tgz ]] &&
> > > mtree -qdef /etc/mtree/BSD.x11.dist -p / -U 
> > > >/dev/null
> > > fi
> > > 
> > > Here the comment says: "in case a patch added a new directory (install 
> > > -D)".
> > > This is true, but it also applies to existing directories and resets
> > > permissions, ownership, etc.
> > > 
> > > A real-world example: on my system after applying syspatch this changed
> > > permissions of an existing directory and a daemon (mysqld) failed to 
> > > start,
> > > because it could not access a UNIX domain socket file in the www chroot.
> > 
> > A very long mail without being 100% PRECISE.
> > 
> > > Is this intended? If so should this behaviour perhaps get documented in 
> > > the man
> > > page? I can write a patch if so.
> > 
> > Intentional.  As a general rule if you change a system component, you own
> > all the pieces.
> > 
> > But I guess you did chmod a+wrxt / or something, right?  I have to assume
> > so, because your mail is not PRECISE.
> > 
> 
> In this particular case it was the directory /var/www/run. The default
> permissions are as specified in /etc/mtree/4.4BSD.dist:
> 
>   run type=dir uname=root gname=daemon mode=755
> 
> I changed it from 755 to 775 (still root:daemon) so both mysqld and PHP could
> access the UNIX domain socket in the www chroot (/var/www).

Why don't you do what the mariadb readme advises?

chrooted daemons and MariaDB socket
===

For external program running under a chroot(8) to be able to access the
MariaDB server without using a network connection, the socket must be
placed inside the chroot.

e.g. httpd(8) or nginx(8): connecting to MariaDB from PHP
-
Create a directory for the MariaDB socket:

# install -d -m 0711 -o _mysql -g _mysql /var/www/var/run/mysql

Adjust ${SYSCONFDIR}/my.cnf to use the socket in the chroot - this
applies to both client and server processes:

[client-server]
socket = /var/www/var/run/mysql/mysql.sock


-- 
Antoine



Re: ld.so speedup (part 2)

2019-04-27 Thread Antoine Jacoutot
On Sat, Apr 27, 2019 at 09:55:33PM +0800, Nathanael Rensen wrote:
> The diff below speeds up ld.so library intialisation where the dependency
> tree is broad and deep, such as samba's smbd which links over 100 libraries.
> 
> See for example https://marc.info/?l=openbsd-misc=155007285712913=2
> 
> See https://marc.info/?l=openbsd-tech=155637285221396=2 for part 1
> that speeds up library loading.
> 
> The timings below are for /usr/local/sbin/smbd --version:
> 
> Timing without either diff  : 6m45.67s real  6m45.65s user  0m00.02s system
> Timing with part 1 diff only: 4m42.88s real  4m42.85s user  0m00.02s system
> Timing with part 2 diff only: 2m02.61s real  2m02.60s user  0m00.01s system
> Timing with both diffs  : 0m00.03s real  0m00.03s user  0m00.00s system
> 
> Note that these timings are for a build of a recent samba master tree
> (linked with kerberos) which is probably slower than the OpenBSD port.
> 
> Nathanael

Wow. Tried your part1 and part2 diffs and the difference is indeed insane!
mail/evolution always took 10+ seconds to start for me and now it's almost
instant...
Crazy... But this sounds too good to be true ;-)
What are the potential regressions?


> Index: libexec/ld.so/loader.c
> ===
> RCS file: /cvs/src/libexec/ld.so/loader.c,v
> retrieving revision 1.177
> diff -u -p -p -u -r1.177 loader.c
> --- libexec/ld.so/loader.c3 Dec 2018 05:29:56 -   1.177
> +++ libexec/ld.so/loader.c27 Apr 2019 13:24:02 -
> @@ -749,15 +749,15 @@ _dl_call_init_recurse(elf_object_t *obje
>  {
>   struct dep_node *n;
>  
> - object->status |= STAT_VISITED;
> + int visited_flag = initfirst ? STAT_VISITED_1 : STAT_VISITED_2;
> +
> + object->status |= visited_flag;
>  
>   TAILQ_FOREACH(n, >child_list, next_sib) {
> - if (n->data->status & STAT_VISITED)
> + if (n->data->status & visited_flag)
>   continue;
>   _dl_call_init_recurse(n->data, initfirst);
>   }
> -
> - object->status &= ~STAT_VISITED;
>  
>   if (object->status & STAT_INIT_DONE)
>   return;
> Index: libexec/ld.so/resolve.h
> ===
> RCS file: /cvs/src/libexec/ld.so/resolve.h,v
> retrieving revision 1.90
> diff -u -p -p -u -r1.90 resolve.h
> --- libexec/ld.so/resolve.h   21 Apr 2019 04:11:42 -  1.90
> +++ libexec/ld.so/resolve.h   27 Apr 2019 13:24:02 -
> @@ -125,8 +125,9 @@ struct elf_object {
>  #define  STAT_FINI_READY 0x10
>  #define  STAT_UNLOADED   0x20
>  #define  STAT_NODELETE   0x40
> -#define  STAT_VISITED0x80
> +#define  STAT_VISITED_1  0x80
>  #define  STAT_GNU_HASH   0x100
> +#define  STAT_VISITED_2  0x200
>  
>   Elf_Phdr*phdrp;
>   int phdrc;
> 

-- 
Antoine



Re: vmctl: usage on extra arguments

2019-03-01 Thread Antoine Jacoutot
On Fri, Mar 01, 2019 at 01:28:58PM +0100, Klemens Nanni wrote:
> I blatantly missed the argc/argv adjustments after getopt(3), resulting
> in valid commands like `vmctl create a -s 1G' to fail.
> 
> Noticed by ajacoutot the hard way.
> 
> OK?

Works for me (tm).
ok :-)


> 
> Index: usr.sbin/vmctl/main.c
> ===
> RCS file: /cvs/src/usr.sbin/vmctl/main.c,v
> retrieving revision 1.53
> diff -u -p -r1.53 main.c
> --- usr.sbin/vmctl/main.c 1 Mar 2019 10:34:14 -   1.53
> +++ usr.sbin/vmctl/main.c 1 Mar 2019 12:25:23 -
> @@ -598,6 +598,8 @@ ctl_create(struct parse_result *res, int
>   /* NOTREACHED */
>   }
>   }
> + argc -= optind;
> + argv += optind;
>  
>   if (argc > 0)
>   ctl_usage(res->ctl);
> @@ -915,6 +917,8 @@ ctl_start(struct parse_result *res, int 
>   /* NOTREACHED */
>   }
>   }
> + argc -= optind;
> + argv += optind;
>  
>   if (argc > 0)
>   ctl_usage(res->ctl);
> @@ -959,6 +963,8 @@ ctl_stop(struct parse_result *res, int a
>   /* NOTREACHED */
>   }
>   }
> + argc -= optind;
> + argv += optind;
>  
>   if (argc > 0)
>   ctl_usage(res->ctl);
> 

-- 
Antoine



Re: add getrun for rcctl(8)

2019-02-18 Thread Antoine Jacoutot
On Mon, Feb 18, 2019 at 11:21:38AM +0900, YASUOKA Masahiko wrote:
> Hi,
> 
> On Sun, 17 Feb 2019 10:55:11 +0100
> Antoine Jacoutot  wrote:
> > On Fri, Feb 15, 2019 at 02:50:22PM +0900, YASUOKA Masahiko wrote:
> >> On Fri, 15 Feb 2019 14:45:14 +0900 (JST)
> >> YASUOKA Masahiko  wrote:
> >> > The diff adds "getrun" command for rcctl(8) which shows the daemon
> >> > variables from the running daemon.
> >> > 
> >> > ok? comment?
> >> 
> >> Sorry, previous diff is broken.  It could not get any value other than
> >> daemon_pexp.  Let me update the diff.
> > 
> > That's a lot of chunk of code for an enhanced 'cat /var/run/rc.d/foo'.
> > What is your usage for this?
> 
> My actual usage is to know whether current "rtable" or "user" is
> changed from the values of the running daemon.  If either is changed,
> we need to restart the daemon apply that change.
> 
> For example,
> 
>   curr=$(rcctl get ntpd rtable)
>   running=$(rcctl getrun ntpd rtable)
>   if [[ $curr != $running ]]; then
>  /etc/rc.d/ntpd restart
>   fi

You better of using this I think:
running=$(sed -n 's/^daemon_rtable=*//p' /var/run/rc.d/ntpd)

What's under /var/run/rc.d/ is only a "hint".
If ntpd is manually killed (outside of the rc.d system), the information is not
removed from there.
That's why I'd like to avoid relying on it too much in rcctl.


> >> Index: usr.sbin/rcctl/rcctl.8
> >> ===
> >> RCS file: /cvs/src/usr.sbin/rcctl/rcctl.8,v
> >> retrieving revision 1.35
> >> diff -u -p -r1.35 rcctl.8
> >> --- usr.sbin/rcctl/rcctl.8 20 Sep 2018 12:24:14 -  1.35
> >> +++ usr.sbin/rcctl/rcctl.8 15 Feb 2019 05:48:16 -
> >> @@ -22,7 +22,7 @@
> >>  .Nd configure and control daemons and services
> >>  .Sh SYNOPSIS
> >>  .Nm rcctl
> >> -.Cm get Ns | Ns Cm getdef Ns | Ns Cm set
> >> +.Cm get Ns | Ns Cm getdef Ns | Ns Cm getrun Ns | Ns Cm set
> >>  .Ar service | daemon Op Ar variable Op Ar arguments
> >>  .Nm rcctl
> >>  .Op Fl df
> >> @@ -103,6 +103,10 @@ will display all services and daemons va
> >>  Like
> >>  .Cm get
> >>  but returns the default values.
> >> +.It Cm getrun Ar service | daemon Op Ar variable
> >> +Like
> >> +.Cm get
> >> +but returns the values of the running daemon.
> >>  .It Cm ls Ar lsarg
> >>  Display a list of services and daemons matching
> >>  .Ar lsarg ,
> >> @@ -180,6 +184,9 @@ exits with 0 if the daemon or service is
> >>  .Nm Cm getdef Ar daemon | service Op Cm status
> >>  exits with 0 if the daemon or service is enabled by default
> >>  and 1 if it is not.
> >> +.Nm Cm getrun Ar daemon | service
> >> +exits with 0 if the values of the running daemon exists
> >> +and 1 if it doesn't.
> >>  .Nm Cm ls failed
> >>  exits with 1 if an enabled daemon is not running.
> >>  Otherwise, the
> >> Index: usr.sbin/rcctl/rcctl.sh
> >> ===
> >> RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
> >> retrieving revision 1.107
> >> diff -u -p -r1.107 rcctl.sh
> >> --- usr.sbin/rcctl/rcctl.sh21 Oct 2018 21:20:40 -  1.107
> >> +++ usr.sbin/rcctl/rcctl.sh15 Feb 2019 05:48:16 -
> >> @@ -21,6 +21,7 @@ _special_svcs="accounting check_quotas i
> >> spamd_black"
> >>  readonly _special_svcs
> >>  
> >> +_RC_RUNDIR=/var/run/rc.d
> >>  # get local functions from rc.subr(8)
> >>  FUNCS_ONLY=1
> >>  . /etc/rc.d/rc.subr
> >> @@ -32,7 +33,7 @@ usage()
> >>for _i in ${_rc_actions}; do _a="$(echo -n ${_i}${_a:+|${_a}})"; done
> >>  
> >>_rc_err \
> >> -  "usage: rcctl get|getdef|set service | daemon [variable [arguments]]
> >> +  "usage: rcctl get|getdef|getrun|set service | daemon [variable 
> >> [arguments]]
> >>rcctl [-df] ${_a} daemon ...
> >>rcctl disable|enable|order [daemon ...]
> >>rcctl ls all|failed|off|on|started|stopped"
> >> @@ -374,6 +375,35 @@ svc_getdef()
> >>fi
> >>  }
> >>  
> >> +svc_getrun()
> >> +{
> >> +  local _svc=$1
> >> +
> >> +  ( svc_is_special ${_svc} || svc_is_meta ${_svc} ) && return 1
> >> +
> >> +  local _val _var=$2
> >&g

Re: add getrun for rcctl(8)

2019-02-17 Thread Antoine Jacoutot
On Fri, Feb 15, 2019 at 02:50:22PM +0900, YASUOKA Masahiko wrote:
> On Fri, 15 Feb 2019 14:45:14 +0900 (JST)
> YASUOKA Masahiko  wrote:
> > The diff adds "getrun" command for rcctl(8) which shows the daemon
> > variables from the running daemon.
> > 
> > ok? comment?
> 
> Sorry, previous diff is broken.  It could not get any value other than
> daemon_pexp.  Let me update the diff.

Hi.

That's a lot of chunk of code for an enhanced 'cat /var/run/rc.d/foo'.
What is your usage for this?


> Index: usr.sbin/rcctl/rcctl.8
> ===
> RCS file: /cvs/src/usr.sbin/rcctl/rcctl.8,v
> retrieving revision 1.35
> diff -u -p -r1.35 rcctl.8
> --- usr.sbin/rcctl/rcctl.820 Sep 2018 12:24:14 -  1.35
> +++ usr.sbin/rcctl/rcctl.815 Feb 2019 05:48:16 -
> @@ -22,7 +22,7 @@
>  .Nd configure and control daemons and services
>  .Sh SYNOPSIS
>  .Nm rcctl
> -.Cm get Ns | Ns Cm getdef Ns | Ns Cm set
> +.Cm get Ns | Ns Cm getdef Ns | Ns Cm getrun Ns | Ns Cm set
>  .Ar service | daemon Op Ar variable Op Ar arguments
>  .Nm rcctl
>  .Op Fl df
> @@ -103,6 +103,10 @@ will display all services and daemons va
>  Like
>  .Cm get
>  but returns the default values.
> +.It Cm getrun Ar service | daemon Op Ar variable
> +Like
> +.Cm get
> +but returns the values of the running daemon.
>  .It Cm ls Ar lsarg
>  Display a list of services and daemons matching
>  .Ar lsarg ,
> @@ -180,6 +184,9 @@ exits with 0 if the daemon or service is
>  .Nm Cm getdef Ar daemon | service Op Cm status
>  exits with 0 if the daemon or service is enabled by default
>  and 1 if it is not.
> +.Nm Cm getrun Ar daemon | service
> +exits with 0 if the values of the running daemon exists
> +and 1 if it doesn't.
>  .Nm Cm ls failed
>  exits with 1 if an enabled daemon is not running.
>  Otherwise, the
> Index: usr.sbin/rcctl/rcctl.sh
> ===
> RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
> retrieving revision 1.107
> diff -u -p -r1.107 rcctl.sh
> --- usr.sbin/rcctl/rcctl.sh   21 Oct 2018 21:20:40 -  1.107
> +++ usr.sbin/rcctl/rcctl.sh   15 Feb 2019 05:48:16 -
> @@ -21,6 +21,7 @@ _special_svcs="accounting check_quotas i
> spamd_black"
>  readonly _special_svcs
>  
> +_RC_RUNDIR=/var/run/rc.d
>  # get local functions from rc.subr(8)
>  FUNCS_ONLY=1
>  . /etc/rc.d/rc.subr
> @@ -32,7 +33,7 @@ usage()
>   for _i in ${_rc_actions}; do _a="$(echo -n ${_i}${_a:+|${_a}})"; done
>  
>   _rc_err \
> - "usage: rcctl get|getdef|set service | daemon [variable [arguments]]
> + "usage: rcctl get|getdef|getrun|set service | daemon [variable 
> [arguments]]
>   rcctl [-df] ${_a} daemon ...
>   rcctl disable|enable|order [daemon ...]
>   rcctl ls all|failed|off|on|started|stopped"
> @@ -374,6 +375,35 @@ svc_getdef()
>   fi
>  }
>  
> +svc_getrun()
> +{
> + local _svc=$1
> +
> + ( svc_is_special ${_svc} || svc_is_meta ${_svc} ) && return 1
> +
> + local _val _var=$2
> + local daemon_class daemon_flags daemon_rtable daemon_timeout daemon_user
> + local daemon_pexp
> +
> + [ ! -f $_RC_RUNDIR/$_svc ] && return 1
> + _rc_parse_conf -readonly $_RC_RUNDIR/$_svc
> +
> + [ -z "${daemon_pexp}" ] && eval daemon_pexp=\${pexp}
> +
> + if [ -n "${_var}" ]; then
> + eval _val=\${daemon_${_var}}
> + [ -z "${_val}" ] || print -r -- "${_val}"
> + else
> + echo "${_svc}_class=${daemon_class}"
> + echo "${_svc}_flags=${daemon_flags}"
> + echo "${_svc}_rtable=${daemon_rtable}"
> + echo "${_svc}_timeout=${daemon_timeout}"
> + echo "${_svc}_user=${daemon_user}"
> + echo "${_svc}_pexp=${daemon_pexp}"
> + fi
> + return 0
> +}
> +
>  svc_rm()
>  {
>   local _svc=$1
> @@ -509,7 +539,7 @@ case ${action} in
>   done
>   fi
>   ;;
> - get|getdef)
> + get|getdef|getrun)
>   svc=$2
>   var=$3
>   [ -z "${svc}" ] && usage
> @@ -571,7 +601,7 @@ case ${action} in
>   done
>   exit ${ret}
>   ;;
> - get|getdef)
> + get|getdef|getrun)
>   if [ "${svc}" = "all" ]; then
>   for svc in $(svc_ls all); do
>   ( svc_${action} ${svc} "${var}" )
> Index: etc/rc.d/rc.subr
> ===
> RCS file: /cvs/src/etc/rc.d/rc.subr,v
> retrieving revision 1.130
> diff -u -p -r1.130 rc.subr
> --- etc/rc.d/rc.subr  20 Jan 2019 04:52:07 -  1.130
> +++ etc/rc.d/rc.subr  15 Feb 2019 05:48:16 -
> @@ -138,18 +138,24 @@ _rc_quirks() {
>  
>  _rc_parse_conf() {
>   typeset -l _key
> - local _l _rcfile _val
> + local _l _rcfile _val _readonly=
>   set -A _allowed_keys -- \
>   accounting amd_master check_quotas ipsec 

Re: allow weak passwd

2018-12-12 Thread Antoine Jacoutot
On Tue, Dec 11, 2018 at 10:46:18PM +0100, Mark Kettenis wrote:
> > Date: Tue, 11 Dec 2018 22:39:37 +0100
> > From: Antoine Jacoutot 
> > 
> > On Tue, Dec 11, 2018 at 04:27:19PM -0500, Ted Unangst wrote:
> > > Mark Kettenis wrote:
> > > > > From: "Ted Unangst" 
> > > > > Date: Mon, 10 Dec 2018 14:14:08 -0500
> > > > > Content-Type: text/plain; charset=utf-8
> > > > > 
> > > > > So I was actually looking at the passwd check rules because I wanted
> > > > > to add a flag to disable the 3 bad passwords then ok whatever.
> > > > > 
> > > > > This adds passwd -w to allow user to skip the default 3 warnings and
> > > > > just do what they want. If, by chance, you have configured warnings
> > > > > in login.conf then they can't override that.
> > > > 
> > > > What is the motivation for this diff?
> > > 
> > > i get tired of typing the same password five times.
> >  
> > I also get tired of running 'doas foo' as root and being denied... Not 
> > trying
> > to hijack the thread but could we "fix" that as well?
> 
> Add
> 
> permit nopass keepenv root as root
> 
> in your /etc/doas.conf

Yes of course, but I hate configuring things ;-)

-- 
Antoine



Re: allow weak passwd

2018-12-11 Thread Antoine Jacoutot
On Tue, Dec 11, 2018 at 04:27:19PM -0500, Ted Unangst wrote:
> Mark Kettenis wrote:
> > > From: "Ted Unangst" 
> > > Date: Mon, 10 Dec 2018 14:14:08 -0500
> > > Content-Type: text/plain; charset=utf-8
> > > 
> > > So I was actually looking at the passwd check rules because I wanted
> > > to add a flag to disable the 3 bad passwords then ok whatever.
> > > 
> > > This adds passwd -w to allow user to skip the default 3 warnings and
> > > just do what they want. If, by chance, you have configured warnings
> > > in login.conf then they can't override that.
> > 
> > What is the motivation for this diff?
> 
> i get tired of typing the same password five times.
 
I also get tired of running 'doas foo' as root and being denied... Not trying
to hijack the thread but could we "fix" that as well?

-- 
Antoine



Re: rcctl, tiny typo in comment

2018-10-21 Thread Antoine Jacoutot
On Sun, Oct 21, 2018 at 01:37:51PM +0200, Hiltjo Posthuma wrote:
> Hi,
> 
> Below a patch for a very small typo in a comment in /usr/sbin/rcctl
> 
> 
> diff --git a/usr.sbin/rcctl/rcctl.sh b/usr.sbin/rcctl/rcctl.sh
> index 61ad76a4987..3b2f0cabe49 100644
> --- a/usr.sbin/rcctl/rcctl.sh
> +++ b/usr.sbin/rcctl/rcctl.sh
> @@ -263,7 +263,7 @@ svc_get()
>   fi
>  
>   if ! svc_is_meta ${_svc}; then
> - # these are expensive, make sure they are explicitely 
> requested
> + # these are expensive, make sure they are explicitly 
> requested
>   if [ -z "${_var}" -o "${_var}" = "class" ]; then
>   getcap -f /etc/login.conf ${_svc} 1>/dev/null 
> 2>&1 && \
>   daemon_class=${_svc}

Committed, thanks!

-- 
Antoine



Re: Add $daemon_nice to rc.subr

2018-09-03 Thread Antoine Jacoutot
On Tue, Sep 04, 2018 at 04:58:53AM +0200, Thomas de Grivel wrote:
> Thanks, good to know.
> 
> But if I actually wanted per daemon priorities with settable
> configuration in rc.conf.local how would I get that ? And I still feel

You would do what the man page instructs you to do in login.conf:

mydaemon1:\
:priority=10:\
:tc=daemon:

mydaemon2:\
:priority=5:\
:tc=daemon:

etc.

Where mydaemon1 and mydaemon2 each matches an rc.d script name under /etc/rc.d/

> the default nice priority of 10 is rather a good idea.

I disagree.


> Le lun. 3 sept. 2018 à 23:10, Antoine Jacoutot  a 
> écrit :
> >
> > On Mon, Sep 03, 2018 at 10:34:51PM +0200, Thomas de Grivel wrote:
> > > Hello,
> >
> > Hi.
> >
> > > Following patch allows sysadmins to configure nice values for RC daemons.
> > > Default nice value is set to 10 as I wish to prioritize interactive
> > > applications over system daemons and I think most probably do too.
> > > It is based on OpenBSD 6.3 but might apply easily to later releases.
> > > Please let me know if it is of any interest to you.
> >
> > We already support that.
> >
> > Extract from rc.d(8):
> >
> >  daemon_class is a special read-only variable.  It is set to “daemon”
> >  unless there is a login class configured in login.conf(5) with the same
> >  name as the rc.d script itself, in which case it will be set to that
> >  login class.  This allows setting many initial process properties, for
> >  example environment variables, scheduling priority, and process limits
> >  such as maximum memory use and number of files.
> >
> > Extract from login.conf(5):
> >
> >  priority   number   Initial priority (nice)
> >  level.
> >
> > Cheers!
> >
> >
> > > commit 1f4121df3ae31121d435571ffdbd93a20c1e8a07
> > > Author: Thomas de Grivel 
> > > Date:   Mon Sep 3 21:52:37 2018 +0200
> > >
> > > Add a $daemon_nice parameter.
> > > If not overriden by the launched daemon the default nice value is 10.
> > > See nice(1) for more details.
> > >
> > > diff --git rc.d/rc.subr.orig rc.d/rc.subr
> > > index 6c2f694..5f4fbe5 100644
> > > --- rc.d/rc.subr.orig
> > > +++ rc.d/rc.subr
> > > @@ -49,6 +49,7 @@ _rc_write_runfile() {
> > >   cat >${_RC_RUNFILE} < > >  daemon_class=${daemon_class}
> > >  daemon_flags=${daemon_flags}
> > > +daemon_nice=${daemon_nice}
> > >  daemon_rtable=${daemon_rtable}
> > >  daemon_timeout=${daemon_timeout}
> > >  daemon_user=${daemon_user}
> > > @@ -170,7 +171,7 @@ _rc_parse_conf() {
> > >  [ -n "${FUNCS_ONLY}" ] && return
> > >
> > >  rc_start() {
> > > - ${rcexec} "${daemon} ${daemon_flags}"
> > > + ${rcexec} "nice -n ${daemon_nice} ${daemon} ${daemon_flags}"
> > >  }
> > >
> > >  rc_check() {
> > > @@ -288,6 +289,7 @@ _RC_RUNFILE=${_RC_RUNDIR}/${_name}
> > >  _rc_do _rc_parse_conf
> > >
> > >  eval _rcflags=\${${_name}_flags}
> > > +eval _rcnice=\${${_name}_nice}
> > >  eval _rcrtable=\${${_name}_rtable}
> > >  eval _rcuser=\${${_name}_user}
> > >  eval _rctimeout=\${${_name}_timeout}
> > > @@ -295,6 +297,7 @@ eval _rctimeout=\${${_name}_timeout}
> > >  # set default values; duplicated in rcctl(8)
> > >  getcap -f /etc/login.conf ${_name} 1>/dev/null 2>&1 && 
> > > daemon_class=${_name} ||
> > >   daemon_class=daemon
> > > +[ -z "${daemon_nice}" ] && daemon_nice=10
> > >  [ -z "${daemon_rtable}" ] && daemon_rtable=0
> > >  [ -z "${daemon_user}" ] && daemon_user=root
> > >  [ -z "${daemon_timeout}" ] && daemon_timeout=30
> > > @@ -304,6 +307,7 @@ getcap -f /etc/login.conf ${_name} 1>/dev/null
> > > 2>&1 && daemon_class=${_name} ||
> > >   unset _rcflags
> > >
> > >  [ -n "${_rcflags}" ] && daemon_flags=${_rcflags}
> > > +[ -n "${_rcnice}" ] && daemon_nice=${_rcnice}
> > >  [ -n "${_rcrtable}" ] && daemon_rtable=${_rcrtable}
> > >  [ -n "${_rcuser}" ] && daemon_user=${_rcuser}
> > >  [ -n "${_rctimeout}" ] && daemon_timeout=${_rctimeout}
> > > @@ -315,7 +319,7 @@ if [ -n "${_RC_DEBUG}" ]; then
> > >  fi
> > >
> > >  readonly daemon_class
> > > -unset _rcflags _rcrtable _rcuser _rctimeout
> > > +unset _rcflags _rcnice _rcrtable _rcuser _rctimeout
> > >  pexp="${daemon}${daemon_flags:+ ${daemon_flags}}"
> > >  rcexec="su -l -c ${daemon_class} -s /bin/sh ${daemon_user} -c"
> > >  [ "${daemon_rtable}" -eq 0 ] ||
> > >
> > >
> > > --
> > >  Thomas de Grivel
> > >
> >
> > --
> > Antoine
> 
> 
> 
> -- 
>  Thomas de Grivel
>  http://b.lowh.net/billitch/
> 

-- 
Antoine



Re: Add $daemon_nice to rc.subr

2018-09-03 Thread Antoine Jacoutot
On Mon, Sep 03, 2018 at 10:34:51PM +0200, Thomas de Grivel wrote:
> Hello,
 
Hi.

> Following patch allows sysadmins to configure nice values for RC daemons.
> Default nice value is set to 10 as I wish to prioritize interactive
> applications over system daemons and I think most probably do too.
> It is based on OpenBSD 6.3 but might apply easily to later releases.
> Please let me know if it is of any interest to you.

We already support that.

Extract from rc.d(8):

 daemon_class is a special read-only variable.  It is set to “daemon”
 unless there is a login class configured in login.conf(5) with the same
 name as the rc.d script itself, in which case it will be set to that
 login class.  This allows setting many initial process properties, for
 example environment variables, scheduling priority, and process limits
 such as maximum memory use and number of files.

Extract from login.conf(5):

 priority   number   Initial priority (nice)
 level.

Cheers!


> commit 1f4121df3ae31121d435571ffdbd93a20c1e8a07
> Author: Thomas de Grivel 
> Date:   Mon Sep 3 21:52:37 2018 +0200
> 
> Add a $daemon_nice parameter.
> If not overriden by the launched daemon the default nice value is 10.
> See nice(1) for more details.
> 
> diff --git rc.d/rc.subr.orig rc.d/rc.subr
> index 6c2f694..5f4fbe5 100644
> --- rc.d/rc.subr.orig
> +++ rc.d/rc.subr
> @@ -49,6 +49,7 @@ _rc_write_runfile() {
>   cat >${_RC_RUNFILE} <  daemon_class=${daemon_class}
>  daemon_flags=${daemon_flags}
> +daemon_nice=${daemon_nice}
>  daemon_rtable=${daemon_rtable}
>  daemon_timeout=${daemon_timeout}
>  daemon_user=${daemon_user}
> @@ -170,7 +171,7 @@ _rc_parse_conf() {
>  [ -n "${FUNCS_ONLY}" ] && return
> 
>  rc_start() {
> - ${rcexec} "${daemon} ${daemon_flags}"
> + ${rcexec} "nice -n ${daemon_nice} ${daemon} ${daemon_flags}"
>  }
> 
>  rc_check() {
> @@ -288,6 +289,7 @@ _RC_RUNFILE=${_RC_RUNDIR}/${_name}
>  _rc_do _rc_parse_conf
> 
>  eval _rcflags=\${${_name}_flags}
> +eval _rcnice=\${${_name}_nice}
>  eval _rcrtable=\${${_name}_rtable}
>  eval _rcuser=\${${_name}_user}
>  eval _rctimeout=\${${_name}_timeout}
> @@ -295,6 +297,7 @@ eval _rctimeout=\${${_name}_timeout}
>  # set default values; duplicated in rcctl(8)
>  getcap -f /etc/login.conf ${_name} 1>/dev/null 2>&1 && daemon_class=${_name} 
> ||
>   daemon_class=daemon
> +[ -z "${daemon_nice}" ] && daemon_nice=10
>  [ -z "${daemon_rtable}" ] && daemon_rtable=0
>  [ -z "${daemon_user}" ] && daemon_user=root
>  [ -z "${daemon_timeout}" ] && daemon_timeout=30
> @@ -304,6 +307,7 @@ getcap -f /etc/login.conf ${_name} 1>/dev/null
> 2>&1 && daemon_class=${_name} ||
>   unset _rcflags
> 
>  [ -n "${_rcflags}" ] && daemon_flags=${_rcflags}
> +[ -n "${_rcnice}" ] && daemon_nice=${_rcnice}
>  [ -n "${_rcrtable}" ] && daemon_rtable=${_rcrtable}
>  [ -n "${_rcuser}" ] && daemon_user=${_rcuser}
>  [ -n "${_rctimeout}" ] && daemon_timeout=${_rctimeout}
> @@ -315,7 +319,7 @@ if [ -n "${_RC_DEBUG}" ]; then
>  fi
> 
>  readonly daemon_class
> -unset _rcflags _rcrtable _rcuser _rctimeout
> +unset _rcflags _rcnice _rcrtable _rcuser _rctimeout
>  pexp="${daemon}${daemon_flags:+ ${daemon_flags}}"
>  rcexec="su -l -c ${daemon_class} -s /bin/sh ${daemon_user} -c"
>  [ "${daemon_rtable}" -eq 0 ] ||
> 
> 
> -- 
>  Thomas de Grivel
> 

-- 
Antoine



Re: tracking down sources of spin cpu%

2018-07-25 Thread Antoine Jacoutot
> I see the exact same issue as you do.
> I'll try with s/modesetting/intel and see if it improves things.

OK I can already confirm this "fixes" the issue for me.

-- 
Antoine



Re: tracking down sources of spin cpu%

2018-07-25 Thread Antoine Jacoutot
On Wed, Jul 25, 2018 at 10:22:15AM +0100, Stuart Henderson wrote:
> On 2018/07/24 23:07, Stuart Henderson wrote:
> > My workstation is freezing up a lot again (usually in 30-60ish second
> > bursts with no or very slow response to mouse or keyboard or screen
> > updates).
> > 
> > I have a status bar (xstatbar) that displays a graph of the last minute
> > or so's cpu% split off into user/nice/system/spin/interrupt/idle. It
> > skips a lot of updates when the machine freezes but it's obvious that
> > it's mostly in spin.
> > 
> > It seems particularly likely to occur when opening browser tabs.
> > 
> > Is there anything sane that I can do (ahead of time, as I can't type
> > when it's in that state) that will give clues about what's going on?
> 
> I had a think about what might have changed when it started freezing
> again and remembered that I had switched X back to modesetting at a time
> which would roughly correlate with this (I had been using intel(4) to
> cope with vncviewer problems, and switched back after jcs enabled SHM
> in vncviewer).
> 
> I've moved back to intel(4) now to see if this removes/reduces the
> problem. Haven't run into one since, but it's still a bit early to say
> if it's actually helped.
> 
> (intel does remove one other annoyance, for some inexplicable reason
> context menus like the right-click menu in browsers often show up on the
> wrong monitor with modesetting..).
 
I see the exact same issue as you do.
I'll try with s/modesetting/intel and see if it improves things.

-- 
Antoine



Re: syspatch(8) exit code

2018-04-13 Thread Antoine Jacoutot
On Fri, Apr 13, 2018 at 07:37:24AM -0600, Theo de Raadt wrote:
> No.  There are no patches yet, and it can't handle an empty directory.
> 
> I am waiting for aja and robert to decide what to do about it.  Otherwise
> we'll have thus fuss at the start of every new release.
> 
> Come on guys, make a decision!

For 6.3 it will be "fixed" once there's a syspatch.
For 6.4 I will fix it at p2k18.

-- 
Antoine



Re: Allow syspatch to use ftp

2018-03-10 Thread Antoine Jacoutot
On Sun, Mar 04, 2018 at 05:49:52PM +, Andrew Marks wrote:
> The below allows "ftp://; url in /etc/installurl.
> 
> Now the discussion part, there are at least three utilities I know of
> which use /etc/installurl to find OpenBSD "sources"
> 1. syspatch
> 2. pkg_add
> 3. installation (I don't know the exact name)
> 
> There may be others which are all
> 1. verifiying that /etc/installurl is valid
> 2. fetching things
> 3. verifying checksums
> 
> Which may be cause to consolidate those things into a single utility?
> 
> Any thoughts?

Committed, thanks :-)

> --- syspatch.sh   29 Dec 2017 18:56:36 -  1.134
> +++ syspatch.sh   4 Mar 2018 17:41:41 -
> @@ -264,7 +264,7 @@ _OSrev=${_KERNV[0]%.*}${_KERNV[0]#*.}
>  
>  _MIRROR=$(while read _line; do _line=${_line%%#*}; [[ -n ${_line} ]] &&
>   print -r -- "${_line}"; done /dev/null
> -[[ ${_MIRROR} == @(file|http|https)://* ]] ||
> +[[ ${_MIRROR} == @(ftp|file|http|https)://* ]] ||
>   sp_err "${0##*/}: invalid URL configured in /etc/installurl"
>  _MIRROR="${_MIRROR}/syspatch/${_KERNV[0]}/$(machine)"
>  
> 

-- 
Antoine



Re: syspatch / reorder_kernel

2017-12-12 Thread Antoine Jacoutot
On Tue, Dec 12, 2017 at 11:56:20AM +, Stuart Henderson wrote:
> Quick thought (I don't have time to look further now but I just noticed
> this and wanted to get it down before I forget).
> 
> I just upgraded an Alix to 6.2 release and then wanted to run syspatch
> afterwards. I logged in just after ssh had started, so reorder_kernel was
> still running in the background - it didn't finish until uptime=8 mins.
> 
> It's not going to be a problem for systems with faster storage, but there are
> likely still plenty of machines like this around just plodding along. Thinking
> about users who may not realise about the background reorder_kernel, is this
> enough of a problem to be worth adding some kind of interlock to prevent
> syspatch from running before reorder_kernel finished?

I suppose I could add such a check if we want it.

-- 
Antoine



Re: clang: Avoid EBX/RBX

2017-11-17 Thread Antoine Jacoutot
On Fri, Nov 17, 2017 at 08:46:28AM +, Stuart Henderson wrote:
> On 2017/11/17 09:36, Antoine Jacoutot wrote:
> > > here are.  Personally I'd like to see devel/libexecinfo to be removed
> > > from ports if possible.
> > 
> > +1
> > I even volunteer to do that part.
> > AFAIK it's not a *hard* requirement for anything.
> 
> It would actually be easier not to have it, ports-wise. Things tend
> to pick it up as a hidden dependency. (Often they don't even pick it up
> properly, just notice the header and try to pull that in, but not actually
> link against the library - weird set of functions these, Linux has them
> in libc).

Good, I'll tedu it and send a patch tomorrow :-)

-- 
Antoine



Re: clang: Avoid EBX/RBX

2017-11-17 Thread Antoine Jacoutot
> here are.  Personally I'd like to see devel/libexecinfo to be removed
> from ports if possible.

+1
I even volunteer to do that part.
AFAIK it's not a *hard* requirement for anything.

-- 
Antoine



Re: Mention start, stop, restart, reload, and check in rcctl.8

2017-09-15 Thread Antoine Jacoutot
On Fri, Sep 15, 2017 at 10:16:22AM +0100, George Brown wrote:
> Arguably these options are fairly obvious but I was prompted by the fact
> that "check" is not mentioned in the man page and this differs from the
> nomenclature of "status" often used in other systems.
> 
> This is the first time I've sent a diff so I've gone for minimal change
> only mentioning these in the synopsis and have not expanded up these in
> the description. This is akin to the FreeBSD man page for service(8).
> Arguably the fact "reload" sends SIGHUP could be worth mentioning but as
> a sysadmin it's the behavior I'd be expecting anyway.

These are documented in rc.d(8).


> 
> diff --git usr.sbin/rcctl/rcctl.8 usr.sbin/rcctl/rcctl.8
> index cbce9623720..4188fd26f2c 100644
> --- usr.sbin/rcctl/rcctl.8
> +++ usr.sbin/rcctl/rcctl.8
> @@ -22,6 +22,9 @@
>  .Nd configure and control daemons and services
>  .Sh SYNOPSIS
>  .Nm rcctl
> +.Cm start Ns | Ns Cm stop Ns | Ns Cm restart Ns | Ns Cm reload Ns | Ns Cm 
> check
> +.Op Ar daemon ...
> +.Nm rcctl
>  .Cm get Ns | Ns Cm getdef Ns | Ns Cm set
>  .Ar service | daemon Op Ar variable Op Ar arguments
>  .Nm rcctl
> 

-- 
Antoine



Re: [PATCH] Syspatch not clearing needed free space counter

2017-08-17 Thread Antoine Jacoutot
On Thu, Aug 03, 2017 at 06:26:47PM -0400, trondd wrote:
> Stuart Henderson  wrote:
> 
> > Ah, perhaps the change to disk behaviour wasn't reflected in calculations 
> > then..
> 
> I got it figured out.
> 
> In the checkfs function, the 'eval $(stat...)' command stores a list of disk
> devices and creates a variable named for each device to store the size of the
> files in the patch to be installed there.  It uses :+ to accumulate the sizes 
> of
> multiple files.  But since ksh creates variales as global by default, these 
> are
> not cleared between patches and :+ takes an existing value if the variable 
> already
> exists.  So the value stored in these variables will continue to accumulate.
> 
> A simple solution seems to be to mark these variables local.  Ksh will clean 
> them
> up between calls to checkfs.

Very good find.
Just applied your patch on current, thanks.

> Tim.
> 
> 
> Index: syspatch.sh
> ===
> RCS file: /cvs/src/usr.sbin/syspatch/syspatch.sh,v
> retrieving revision 1.120
> diff -u -p -r1.120 syspatch.sh
> --- syspatch.sh   2 Aug 2017 05:58:29 -   1.120
> +++ syspatch.sh   3 Aug 2017 21:59:13 -
> @@ -91,7 +91,7 @@ checkfs()
>   # - nonexistent files (i.e. syspatch is installing new files)
>   # - broken interpolation due to bogus devices like remote filesystems
>   eval $(cd / &&
> - stat -qf "_dev=\"\${_dev} %Sd\" %Sd=\"\${%Sd:+\${%Sd}\+}%Uz\"" \
> + stat -qf "_dev=\"\${_dev} %Sd\"; local 
> %Sd=\"\${%Sd:+\${%Sd}\+}%Uz\"" \
>   ${_files}) 2>/dev/null || _ret=$?
>   set -e
>   [[ ${_ret} == 127 ]] && sp_err "Remote filesystem, aborting" 
> 

-- 
Antoine



Re: [PATCH] Do not mention newaliases(8) in /etc/mail/aliases

2017-05-31 Thread Antoine Jacoutot
On May 31, 2017 11:35:28 AM GMT+02:00, Consus  wrote:
>OpenBSD defaults to file table now so there is no need in running
>newaliases(8).
>---
> etc/mail/aliases | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
>diff --git a/etc/mail/aliases b/etc/mail/aliases
>index c1ac04b5a81..045b2b2a456 100644
>--- a/etc/mail/aliases
>+++ b/etc/mail/aliases
>@@ -1,12 +1,8 @@
> #
> # $OpenBSD: aliases,v 1.64 2017/03/18 21:18:01 florian Exp $
> #
>-#  Aliases in this file will NOT be expanded in the header from
>-#  Mail, but WILL be visible over networks or from
>/usr/libexec/mail.local.
>-#
>-# >>  The program "newaliases" must be run after
>-# >> NOTE >>  this file is updated for any changes to
>-# >>  show through to smtpd.
>+#  Aliases in this file will NOT be expanded in the header from Mail,
>but WILL
>+#  be visible over networks or from /usr/libexec/mail.local.
> #
> 
> # Basic system aliases -- these MUST be present
>-- 
>2.13.0

I proposed the same a while ago but people preferred to keep it in regard to 
other MTA. Maybe it's time to revisit ?


-- 
Antoine

Re: printcap(5) error

2017-05-14 Thread Antoine Jacoutot
On Sat, May 13, 2017 at 12:52:04PM -0400, mar...@martinbrandenburg.com wrote:
> printcap(5) says:
> 
>  NameTypeDefault  Description
>  sd  str /var/spool/outputspool directory
> 
> However as far as I can tell, the actual default is
> /var/spool/output/lpd.  That's what's listed in
> usr.sbin/lpr/common_source/pathnames.h, and lpd behaves the same without
> the sd option as when it is set to /var/spool/output/lpd.
> 
> Am I missing something?

No I think that's correct.
Any OK?


Index: printcap.5
===
RCS file: /cvs/src/share/man/man5/printcap.5,v
retrieving revision 1.26
diff -u -p -r1.26 printcap.5
--- printcap.5  8 Jan 2016 20:26:54 -   1.26
+++ printcap.5  14 May 2017 08:12:41 -
@@ -66,7 +66,7 @@ for a complete discussion on how to set 
 Refer to
 .Xr termcap 5
 for a description of the file layout.
-.Bl -column "Name" "Type" "/var/spool/output" "Description"
+.Bl -column "Name" "Type" "/var/spool/output/lpd" "Description"
 .It Sy Name Ta Sy Type Ta Sy Default Ta Sy Description
 .It "afstr" Ta Dv NULL Ta "name of accounting file"
 .It "br" Ta "num" Ta "none" Ta "if lp is a tty, set baud rate"
@@ -108,7 +108,7 @@ blocks); 0=unlimited
 .It "rw" Ta "bool" Ta "false" Ta "open printer device for reading and writing"
 .It "sb" Ta "bool" Ta "false" Ta "short banner (one line only)"
 .It "sc" Ta "bool" Ta "false" Ta "suppress multiple copies"
-.It "sd" Ta "str" Ta Pa /var/spool/output Ta "spool directory"
+.It "sd" Ta "str" Ta Pa /var/spool/output/lpd Ta "spool directory"
 .It "sf" Ta "bool" Ta "false" Ta "suppress form feeds"
 .It "sh" Ta "bool" Ta "false" Ta "suppress printing of burst page header"
 .It "st" Ta "str" Ta Pa status Ta "status file name"



-- 
Antoine



Re: OpenBSD Errata: May 2nd, 2017

2017-05-03 Thread Antoine Jacoutot
On Tue, May 02, 2017 at 10:26:02PM -0400, T.J. Townsend wrote:
> Errata patches for dhcpd, vmm, LibreSSL and softraid have been released
> for OpenBSD 6.1 today.
> 
> Details can be found on this page: https://www.openbsd.org/errata61.html
> 
> Binary updates for the amd64 and i386 platforms are also available via
> the syspatch utility. Note that syspatch uses the mirror configured in
> /etc/installurl, so all mirrors may not have the files yet.

Hi folks.

Due to a mistake in creating the syspatch archives, a multi-processor machine
would not default to the MP kernel. New syspatches have been re-rolled and
you're advised to revert and re-apply them (even on non-MP machines). Make sure
your mirror (/etc/installurl) has the new syspatches first (dated May 3rd).

As root:
while true; do syspatch -r || break; done
syspatch

If you're running on a multi-processor machine, you may also remove the extra
/bsd.mp kernel. Sorry about that and thank you all for your report and feedback.

-- 
Antoine



Re: PATCH: change tiling behaviour in cwm(1)

2017-04-24 Thread Antoine Jacoutot
On April 24, 2017 2:19:31 PM GMT+02:00, Okan Demirmen <o...@demirmen.com> wrote:
>On Wed 2017.04.12 at 10:38 +0200, Antoine Jacoutot wrote:
>> On Tue, Apr 11, 2017 at 06:00:21PM +0200, Gerrit Meyerheim wrote:
>> > Hi @tech,
>> > 
>> > The way cwm(1) currently implements tiling (off by default) is
>> > corresponding to this for vtile,
>> > 
>> > -
>> > |  |   |
>> > |  |   1   |
>> > |  |   |
>> > |  M   -
>> > |  |   |
>> > |  |   2   |
>> > |  |   |
>> > -
>> > 
>> >  <->
>> >w
>> > 
>> > where 'w' is the original horizontal size of the master client when
>> > vtile was invoked. The analogous is true for htile and vertical
>height.
>> > 
>> > While this approach gives the greatest flexibility (as one can
>define
>> > the size of the master area for each invocation of vtile) I most
>often
>> > find myself wanting the following behaviour when using tiling,
>> > 
>> > -
>> > |  |   |
>> > |  |   1   |
>> > |  |   |
>> > |  M   -
>> > |  |   |
>> > |  |   2   |
>> > |  |   |
>> > -
>> > 
>> >  <->
>> >w
>> > 
>> > where 'w' is "0.5 x horizontal widht of the screen" for vtile and
>the
>> > analogous for htile and height.
>> > 
>> > The attached patch tries to implement this (replacing the current
>> > approach). Of course, there would also be the possibility of having
>an
>> > additional function (e.g. client_htile_half etc.).
>> > 
>> > Thoughts?
>> 
>> I'd prefer that as well...
>> Not sure what the others think.
>
>Hi - I'm not a tiling user but after playing around, I find expanding
>the
>master client to 50% of the area more appeasing as well. I'd rather not
>create another function, unless enough people need it. Committed as-is.
>
>Thanks!
>Okan
>
>> 
>> > 
>> > Best
>> > 
>> > Gerrit
>> > 
>> > 
>> > Index: client.c
>> > ===
>> > RCS file: /cvs/xenocara/app/cwm/client.c,v
>> > retrieving revision 1.234
>> > diff -u -p -r1.234 client.c
>> > --- client.c   6 Feb 2017 18:10:28 -   1.234
>> > +++ client.c   10 Apr 2017 12:23:48 -
>> > @@ -982,6 +982,7 @@ client_htile(struct client_ctx *cc)
>> >cc->flags &= ~CLIENT_HMAXIMIZED;
>> >cc->geom.x = area.x;
>> >cc->geom.y = area.y;
>> > +  cc->geom.h = (area.h - (cc->bwidth * 2)) / 2;
>> >cc->geom.w = area.w - (cc->bwidth * 2);
>> >client_resize(cc, 1);
>> >client_ptrwarp(cc);
>> > @@ -1042,6 +1043,7 @@ client_vtile(struct client_ctx *cc)
>> >cc->geom.x = area.x;
>> >cc->geom.y = area.y;
>> >cc->geom.h = area.h - (cc->bwidth * 2);
>> > +  cc->geom.w = (area.w - (cc->bwidth * 2)) / 2;
>> >client_resize(cc, 1);
>> >client_ptrwarp(cc);
>> >  
>> > Index: cwmrc.5
>> > ===
>> > RCS file: /cvs/xenocara/app/cwm/cwmrc.5,v
>> > retrieving revision 1.66
>> > diff -u -p -r1.66 cwmrc.5
>> > --- cwmrc.515 Jan 2017 21:07:44 -  1.66
>> > +++ cwmrc.510 Apr 2017 12:23:48 -
>> > @@ -324,11 +324,13 @@ Vertically maximize current window (gap 
>> >  .It window-hmaximize
>> >  Horizontally maximize current window (gap + border honored).
>> >  .It window-htile
>> > -Current window is placed at the top of the screen and maximized
>> > -horizontally, other windows in its group share remaining screen
>space.
>> > +Current window is placed at the top of the screen, maximized
>> > +horizontally and resized to half of the vertical screen space.
>Other
>> > +windows in its group share remaining screen space.
>> >  .It window-vtile
>> > -Current window is placed on the left of the screen and maximized
>> > -vertically, other windows in its group share remaining screen
>space.
>> > +Current window is placed on the left of the screen, maximized
>vertically
>> > +and resized to half of the horizontal screen space. Other windows
>in its
>> > +group share remaining screen space.
>> >  .It window-move
>> >  Move current window.
>> >  .It window-resize
>> > 
>> 
>> -- 
>> Antoine
>> 

Awesome, thanks!
-- 
Antoine

Re: PATCH: change tiling behaviour in cwm(1)

2017-04-12 Thread Antoine Jacoutot
On Tue, Apr 11, 2017 at 06:00:21PM +0200, Gerrit Meyerheim wrote:
> Hi @tech,
> 
> The way cwm(1) currently implements tiling (off by default) is
> corresponding to this for vtile,
> 
> -
> | |   |
> | |   1   |
> | |   |
> | M   -
> | |   |
> | |   2   |
> | |   |
> -
> 
>  <->
>   w
> 
> where 'w' is the original horizontal size of the master client when
> vtile was invoked. The analogous is true for htile and vertical height.
> 
> While this approach gives the greatest flexibility (as one can define
> the size of the master area for each invocation of vtile) I most often
> find myself wanting the following behaviour when using tiling,
> 
> -
> | |   |
> | |   1   |
> | |   |
> | M   -
> | |   |
> | |   2   |
> | |   |
> -
> 
>  <->
>   w
> 
> where 'w' is "0.5 x horizontal widht of the screen" for vtile and the
> analogous for htile and height.
> 
> The attached patch tries to implement this (replacing the current
> approach). Of course, there would also be the possibility of having an
> additional function (e.g. client_htile_half etc.).
> 
> Thoughts?

I'd prefer that as well...
Not sure what the others think.



> 
> Best
> 
> Gerrit
> 
> 
> Index: client.c
> ===
> RCS file: /cvs/xenocara/app/cwm/client.c,v
> retrieving revision 1.234
> diff -u -p -r1.234 client.c
> --- client.c  6 Feb 2017 18:10:28 -   1.234
> +++ client.c  10 Apr 2017 12:23:48 -
> @@ -982,6 +982,7 @@ client_htile(struct client_ctx *cc)
>   cc->flags &= ~CLIENT_HMAXIMIZED;
>   cc->geom.x = area.x;
>   cc->geom.y = area.y;
> + cc->geom.h = (area.h - (cc->bwidth * 2)) / 2;
>   cc->geom.w = area.w - (cc->bwidth * 2);
>   client_resize(cc, 1);
>   client_ptrwarp(cc);
> @@ -1042,6 +1043,7 @@ client_vtile(struct client_ctx *cc)
>   cc->geom.x = area.x;
>   cc->geom.y = area.y;
>   cc->geom.h = area.h - (cc->bwidth * 2);
> + cc->geom.w = (area.w - (cc->bwidth * 2)) / 2;
>   client_resize(cc, 1);
>   client_ptrwarp(cc);
>  
> Index: cwmrc.5
> ===
> RCS file: /cvs/xenocara/app/cwm/cwmrc.5,v
> retrieving revision 1.66
> diff -u -p -r1.66 cwmrc.5
> --- cwmrc.5   15 Jan 2017 21:07:44 -  1.66
> +++ cwmrc.5   10 Apr 2017 12:23:48 -
> @@ -324,11 +324,13 @@ Vertically maximize current window (gap 
>  .It window-hmaximize
>  Horizontally maximize current window (gap + border honored).
>  .It window-htile
> -Current window is placed at the top of the screen and maximized
> -horizontally, other windows in its group share remaining screen space.
> +Current window is placed at the top of the screen, maximized
> +horizontally and resized to half of the vertical screen space. Other
> +windows in its group share remaining screen space.
>  .It window-vtile
> -Current window is placed on the left of the screen and maximized
> -vertically, other windows in its group share remaining screen space.
> +Current window is placed on the left of the screen, maximized vertically
> +and resized to half of the horizontal screen space. Other windows in its
> +group share remaining screen space.
>  .It window-move
>  Move current window.
>  .It window-resize
> 

-- 
Antoine



Re: sync root.mail

2017-03-29 Thread Antoine Jacoutot
On Wed, Mar 29, 2017 at 09:40:32PM +0200, Christian Weisgerber wrote:
> Antoine Jacoutot:
> 
> > Why not just:
> > 
> > # pkg_add -v rsync chromium emacs--no_x11
> > 
> > So we don't have to change it each release?
> 
> Because people won't let Emacs 21 die.

Ah but, you just killed me :-)

> Ambiguous: choose package for emacs--no_x11
> a   0: 
> 1: emacs-21.4p37-no_x11
> 2: emacs-25.1p3-no_x11
> Your choice:

Time to choose another package?

-- 
Antoine



Re: sync root.mail

2017-03-29 Thread Antoine Jacoutot
On Wed, Mar 29, 2017 at 09:10:49PM +0200, Christian Weisgerber wrote:
> Sync the version of the example package.  ok?

Why not just:

# pkg_add -v rsync chromium emacs--no_x11

So we don't have to change it each release?


> Index: root.mail
> ===
> RCS file: /cvs/src/etc/root/root.mail,v
> retrieving revision 1.121
> diff -u -p -r1.121 root.mail
> --- root.mail 5 Mar 2017 15:08:03 -   1.121
> +++ root.mail 29 Mar 2017 19:10:07 -
> @@ -31,7 +31,7 @@ during install/upgrade -- a mirror URLs 
>  is stored into the file /etc/installurl.  Installation of packages is
>  as simple as:
>  
> - # pkg_add -v rsync chromium emacs-24.5p0-no_x11
> + # pkg_add -v rsync chromium emacs-25.1p3-no_x11
>  
>  Significant efforts were made to centralize all system configuration in the
>  /etc directory.  You should be able to find each of the configuration files
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 

-- 
Antoine



Re: wpa key vs wep key

2017-03-21 Thread Antoine Jacoutot
On Tue, Mar 21, 2017 at 02:10:48PM +0900, Stefan Sperling wrote:
> I see no reason to leave WEP enabled if a WPA key is set, and leaving
> WPA enabled when a WEP key is set.
> 
> Several cases of "my wifi suddenly stopped working" turned out to be due
> to stale WEP keys interfering with WPA. I think it is better to let the
> kernel handle this transition instead of requiring 'ifconfig -nwkey'.

I fully agree. I've been annoyed by this countless times :-)

> Index: ieee80211_ioctl.c
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211_ioctl.c,v
> retrieving revision 1.50
> diff -u -p -r1.50 ieee80211_ioctl.c
> --- ieee80211_ioctl.c 12 Mar 2017 03:13:50 -  1.50
> +++ ieee80211_ioctl.c 21 Mar 2017 05:03:46 -
> @@ -55,6 +55,8 @@ void ieee80211_node2req(struct ieee8021
>   const struct ieee80211_node *, struct ieee80211_nodereq *);
>  void  ieee80211_req2node(struct ieee80211com *,
>   const struct ieee80211_nodereq *, struct ieee80211_node *);
> +void  ieee80211_disable_wep(struct ieee80211com *); 
> +void  ieee80211_disable_rsn(struct ieee80211com *); 
>  
>  void
>  ieee80211_node2req(struct ieee80211com *ic, const struct ieee80211_node *ni,
> @@ -166,6 +168,32 @@ ieee80211_req2node(struct ieee80211com *
>   ni->ni_state = nr->nr_state;
>  }
>  
> +void
> +ieee80211_disable_wep(struct ieee80211com *ic)
> +{
> + struct ieee80211_key *k;
> + int i;
> + 
> + for (i = 0; i < IEEE80211_WEP_NKID; i++) {
> + k = >ic_nw_keys[i];
> + if (k->k_cipher != IEEE80211_CIPHER_NONE)
> + (*ic->ic_delete_key)(ic, NULL, k);
> + memset(k, 0, sizeof(*k));
> + }
> + ic->ic_flags &= ~IEEE80211_F_WEPON;
> +}
> +
> +void
> +ieee80211_disable_rsn(struct ieee80211com *ic)
> +{
> + ic->ic_flags &= ~(IEEE80211_F_PSK | IEEE80211_F_RSNON);
> + memset(ic->ic_psk, 0, sizeof(ic->ic_psk));
> + ic->ic_rsnprotos = 0;
> + ic->ic_rsnakms = 0;
> + ic->ic_rsngroupcipher = 0;
> + ic->ic_rsnciphers = 0;
> +}
> +
>  static int
>  ieee80211_ioctl_setnwkeys(struct ieee80211com *ic,
>  const struct ieee80211_nwkey *nwkey)
> @@ -212,6 +240,8 @@ ieee80211_ioctl_setnwkeys(struct ieee802
>  
>   ic->ic_def_txkey = nwkey->i_defkid - 1;
>   ic->ic_flags |= IEEE80211_F_WEPON;
> + if (ic->ic_flags & IEEE80211_F_RSNON)
> + ieee80211_disable_rsn(ic);
>  
>   return ENETRESET;
>  }
> @@ -464,6 +494,8 @@ ieee80211_ioctl(struct ifnet *ifp, u_lon
>   if (psk->i_enabled) {
>   ic->ic_flags |= IEEE80211_F_PSK;
>   memcpy(ic->ic_psk, psk->i_psk, sizeof(ic->ic_psk));
> + if (ic->ic_flags & IEEE80211_F_WEPON)
> + ieee80211_disable_wep(ic);
>   } else {
>   ic->ic_flags &= ~IEEE80211_F_PSK;
>   memset(ic->ic_psk, 0, sizeof(ic->ic_psk));
> @@ -496,6 +528,8 @@ ieee80211_ioctl(struct ifnet *ifp, u_lon
>   break;
>   kr = (struct ieee80211_keyrun *)data;
>   error = ieee80211_keyrun(ic, kr->i_macaddr);
> + if (error == 0 && (ic->ic_flags & IEEE80211_F_WEPON))
> + ieee80211_disable_wep(ic);
>   break;
>   case SIOCS80211POWER:
>   if ((error = suser(curproc, 0)) != 0)
> 

-- 
Antoine



Re: rcctl(8) does not set flags

2017-02-15 Thread Antoine Jacoutot
On Wed, Feb 15, 2017 at 02:22:31PM -0200, Daniel Bolgheroni wrote:
> Hi tech@,
> 
> Setting, for example
> 
> # rcctl enable nfsd 
> # rcctl set nfsd flags -tun 4
> 
> has no effect on /etc/rc.conf.local. This is also true for other cases
> where the default flags for the daemon are equal to the flags you're
> trying to set.

That is correct (and expected).

> It seemed a problem at first, since there is no reference to this
> behaviour on the man page. But looking at the source code
> (usr.sbin/rcctl/rcctl.sh, r1.105, line 452), this is actually expected.  
> 
> # unset flags if they match the default enabled ones
> [ "${_args}" = "$(svc_getdef ${_svc} ${_var})" ] && \
> unset _args
> 
> Should this behaviour be on the man page? I don't think it's too obvious
> to assume the flags wasn't set on /etc/rc.conf.local because it is
> already the default for the daemon.

Well, if you enable sshd it won't add 'sshd=' to rc.conf.local either (since
it's the default).
It's kind of expected I think. That said, I don't mind to add it in the man
page if people think it's worth it.
But if you use rcctl to *set* flags, then use it to *get* them as well and you
will see it's what you expect :-)

> Having it documented or not, the diff below removes an unneeded step,
> since "-tun 4" is already the default for nfsd.

I have no opinion on that one. Sure it's not necessary but maybe it makes it
more obvious as a documentation. Dunno...

> 
> Index: faq6.html
> ===
> RCS file: /cvs/www/faq/faq6.html,v
> retrieving revision 1.427
> diff -u -p -r1.427 faq6.html
> --- faq6.html   9 Feb 2017 17:22:19 -   1.427
> +++ faq6.html   15 Feb 2017 16:05:30 -
> @@ -607,7 +607,6 @@ services must be enabled on the server:
> 
>  
>  # rcctl enable portmap mountd nfsd
> -# rcctl set nfsd flags -tun 4
>  
> 
>  The -t and -u flags for nfsd(8) enable TCP and UDP,
> 
> -- 
> db
> 

-- 
Antoine



Re: add empty /root/.ssh/authorized_keys to mtree/sets ?

2017-02-10 Thread Antoine Jacoutot
On Fri, Feb 10, 2017 at 10:00:51AM +0100, Landry Breuil wrote:
> On Fri, Feb 10, 2017 at 09:36:16AM +0100, Antoine Jacoutot wrote:
> > On Thu, Feb 09, 2017 at 06:19:54PM +0100, Landry Breuil wrote:
> > > On Sun, Feb 05, 2017 at 08:37:31PM +, Stuart Henderson wrote:
> > > > On 2017/02/05 09:53, Robert Peichaer wrote:
> > > > > On Sun, Feb 05, 2017 at 10:46:41AM +0100, Landry Breuil wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > when installing 'throwaway' VMs (manually, not always using 
> > > > > > autoinstall for
> > > > > > $REASONS) i've often found myself having to do right after the 
> > > > > > install:
> > > > > > install -d -m 700 /root/.ssh
> > > > > > install -m 600 /dev/null /root/.ssh/authorized_keys
> > > > > > (or touch /root/.ssh/authorized_keys && chmod 600
> > > > > > /root/.ssh/authorized_keys, ymmv)
> > > > > > 
> > > > > > those are present in /etc/skel for "real" users, so why not creating
> > > > > > them for the root account ? install.sub also creates /mnt/root/.ssh 
> > > > > > when
> > > > > > using autoinstall and giving an ssh pubkey, so that'll be one less 
> > > > > > step
> > > > > > to do there.
> > > > > > 
> > > > > > We advise ppl to set prohibit-password for PermitRootLogin, so why 
> > > > > > not make it
> > > > > > easier to use it ? This ways, the correct modes are set.. i often 
> > > > > > fat-fingered
> > > > > > this, to see sshd complaining (rightly!) about bad modes on 
> > > > > > .ssh/authorized_keys.
> > > > > 
> > > > > Conceptually I'd like this going in.
> > > > 
> > > > +1. (On "managed" systems I use root-owned authorized_keys in a system 
> > > > directory,
> > > > but this doesn't get in the way, and it makes things easier on ad-hoc 
> > > > installed
> > > > systems).
> > > 
> > > Finally built a release with this, the empty file is created in
> > > /var/sysmerge/etc.tgz, and sysmerge didnt overwrite my own
> > > /root/.ssh/authorized_keys - so i think i can now explicitely ask for 
> > > okays.
> > > dtucker@ mentioned that in ${INSTALL} -c idiom the -c was a noop, but i 
> > > kept it
> > > for consistency.
> > > Hopefully more ppl can chime in and think of potential drawbacks this
> > > diff exposes...
> > > 
> > > Sets diff added too, modeled after what's done for
> > > /etc/skel/.ssh/authorized_keys - dunno if it should be commited along the 
> > > etc/
> > > change.
> > 
> > Can you add it to mtree/special please?
> 
> Sure ! Here's a new fuller diff touching files all around..
> 
> Index: etc/Makefile
> ===
> RCS file: /cvs/src/etc/Makefile,v
> retrieving revision 1.449
> diff -u -r1.449 Makefile
> --- etc/Makefile  2 Feb 2017 21:35:05 -   1.449
> +++ etc/Makefile  10 Feb 2017 08:59:27 -
> @@ -110,6 +110,8 @@
>   ${DESTDIR}/root/.Xdefaults; \
>   ${INSTALL} -c -o root -g wheel -m 644 dot.cvsrc \
>   ${DESTDIR}/root/.cvsrc; \
> + ${INSTALL} -c -o root -g wheel -m 600 /dev/null \
> + ${DESTDIR}/root/.ssh/authorized_keys; \
>   rm -f ${DESTDIR}/.cshrc ${DESTDIR}/.profile; \
>   ${INSTALL} -c -o root -g wheel -m 644 dot.cshrc \
>   ${DESTDIR}/.cshrc; \
> Index: etc/mtree/4.4BSD.dist
> ===
> RCS file: /cvs/src/etc/mtree/4.4BSD.dist,v
> retrieving revision 1.293
> diff -u -r1.293 4.4BSD.dist
> --- etc/mtree/4.4BSD.dist 27 Dec 2016 09:17:52 -  1.293
> +++ etc/mtree/4.4BSD.dist 10 Feb 2017 08:59:27 -
> @@ -118,6 +118,8 @@
>  mnt
>  ..
>  root mode=0700
> +.ssh uname=root mode=0700
> +..
>  ..
>  sbin
>  ..
> Index: etc/mtree/special
> ===
> RCS file: /cvs/src/etc/mtree/special,v
> retrieving revision 1.122
> diff -u -r1.122 special
> --- etc/mtree/special 27 Dec 2016 09:17:52 -  1.122
> +++ etc/mtree/special 10 Feb 2017 08:59:27 -
> @@ -121,6 +121,9 @@
>  .login   

Re: add empty /root/.ssh/authorized_keys to mtree/sets ?

2017-02-10 Thread Antoine Jacoutot
On Thu, Feb 09, 2017 at 06:19:54PM +0100, Landry Breuil wrote:
> On Sun, Feb 05, 2017 at 08:37:31PM +, Stuart Henderson wrote:
> > On 2017/02/05 09:53, Robert Peichaer wrote:
> > > On Sun, Feb 05, 2017 at 10:46:41AM +0100, Landry Breuil wrote:
> > > > Hi,
> > > > 
> > > > when installing 'throwaway' VMs (manually, not always using autoinstall 
> > > > for
> > > > $REASONS) i've often found myself having to do right after the install:
> > > > install -d -m 700 /root/.ssh
> > > > install -m 600 /dev/null /root/.ssh/authorized_keys
> > > > (or touch /root/.ssh/authorized_keys && chmod 600
> > > > /root/.ssh/authorized_keys, ymmv)
> > > > 
> > > > those are present in /etc/skel for "real" users, so why not creating
> > > > them for the root account ? install.sub also creates /mnt/root/.ssh when
> > > > using autoinstall and giving an ssh pubkey, so that'll be one less step
> > > > to do there.
> > > > 
> > > > We advise ppl to set prohibit-password for PermitRootLogin, so why not 
> > > > make it
> > > > easier to use it ? This ways, the correct modes are set.. i often 
> > > > fat-fingered
> > > > this, to see sshd complaining (rightly!) about bad modes on 
> > > > .ssh/authorized_keys.
> > > 
> > > Conceptually I'd like this going in.
> > 
> > +1. (On "managed" systems I use root-owned authorized_keys in a system 
> > directory,
> > but this doesn't get in the way, and it makes things easier on ad-hoc 
> > installed
> > systems).
> 
> Finally built a release with this, the empty file is created in
> /var/sysmerge/etc.tgz, and sysmerge didnt overwrite my own
> /root/.ssh/authorized_keys - so i think i can now explicitely ask for okays.
> dtucker@ mentioned that in ${INSTALL} -c idiom the -c was a noop, but i kept 
> it
> for consistency.
> Hopefully more ppl can chime in and think of potential drawbacks this
> diff exposes...
> 
> Sets diff added too, modeled after what's done for
> /etc/skel/.ssh/authorized_keys - dunno if it should be commited along the etc/
> change.

Can you add it to mtree/special please?


> Landry
> 
> Index: etc/Makefile
> ===
> RCS file: /cvs/src/etc/Makefile,v
> retrieving revision 1.449
> diff -u -r1.449 Makefile
> --- etc/Makefile  2 Feb 2017 21:35:05 -   1.449
> +++ etc/Makefile  9 Feb 2017 17:13:00 -
> @@ -110,6 +110,8 @@
>   ${DESTDIR}/root/.Xdefaults; \
>   ${INSTALL} -c -o root -g wheel -m 644 dot.cvsrc \
>   ${DESTDIR}/root/.cvsrc; \
> + ${INSTALL} -c -o root -g wheel -m 600 /dev/null \
> + ${DESTDIR}/root/.ssh/authorized_keys; \
>   rm -f ${DESTDIR}/.cshrc ${DESTDIR}/.profile; \
>   ${INSTALL} -c -o root -g wheel -m 644 dot.cshrc \
>   ${DESTDIR}/.cshrc; \
> Index: etc/mtree/4.4BSD.dist
> ===
> RCS file: /cvs/src/etc/mtree/4.4BSD.dist,v
> retrieving revision 1.293
> diff -u -r1.293 4.4BSD.dist
> --- etc/mtree/4.4BSD.dist 27 Dec 2016 09:17:52 -  1.293
> +++ etc/mtree/4.4BSD.dist 9 Feb 2017 17:13:00 -
> @@ -118,6 +118,8 @@
>  mnt
>  ..
>  root mode=0700
> +.ssh uname=root mode=0700
> +..
>  ..
>  sbin
>  ..
> 
> 
> Index: distrib/sets/lists/base/mi
> ===
> RCS file: /cvs/src/distrib/sets/lists/base/mi,v
> retrieving revision 1.820
> diff -u -r1.820 mi
> --- distrib/sets/lists/base/mi7 Feb 2017 21:32:48 -   1.820
> +++ distrib/sets/lists/base/mi9 Feb 2017 17:12:42 -
> @@ -232,6 +232,7 @@
>  ./home
>  ./mnt
>  ./root
> +./root/.ssh
>  ./sbin
>  ./sbin/atactl
>  ./sbin/badsect
> Index: distrib/sets/lists/etc/mi
> ===
> RCS file: /cvs/src/distrib/sets/lists/etc/mi,v
> retrieving revision 1.211
> diff -u -r1.211 mi
> --- distrib/sets/lists/etc/mi 1 Oct 2016 16:58:29 -   1.211
> +++ distrib/sets/lists/etc/mi 9 Feb 2017 17:12:42 -
> @@ -50,6 +50,7 @@
>  ./root/.cvsrc
>  ./root/.login
>  ./root/.profile
> +./root/.ssh/authorized_keys
>  ./var/crash/minfree
>  ./var/cron/at.deny
>  ./var/cron/cron.deny
> 

-- 
Antoine



syspatch early testing

2016-12-01 Thread Antoine Jacoutot
Hi.

syspatch(8), a "binary" patch system for -release is now ready for early
testing. This does not use binary diffing to update the system, but regular
signed tarballs containing the updated files (ala installer).

I would appreciate feedback on the tool. But please send it directly to *me*,
there's no need to pollute the list.
This is obviously WIP and the tool may or may not change in drastic ways.

These test binary patches are *not* endorsed by the OpenBSD project and should
not be trusted, I am only providing them to get early feedback on the tool.
If all goes as planned, I am hoping that syspatch will make it into the 6.1
release; but for it to happen, I need to know how it breaks your systems :-)

Instructions below, the most recent version will always be at:
http://syspatch.openbsd.org/pub/OpenBSD/6.0/syspatch/amd64/README.txt
during this early testing period.

If behind a firewall, make sure your test machine can www out.

   !!!
   !!! Test this on an *amd64* 6.0 *release* (not -stable, not -current) !!!
   !!!

---8<---
RTFM


http://man.openbsd.org/syspatch
Pay attention to the CAVEATS section.

Install the latest syspatch(8) code from current


$ cvs -d anon...@anoncvs.fr.openbsd.org:/cvs -q co -P 
src/usr.sbin/syspatch/syspatch.sh
$ doas install -m 0555 src/usr.sbin/syspatch/syspatch.sh /usr/sbin/syspatch

*ALWAYS* make sure you have the latest revision of syspatch.sh installed!
(i.e. check CVS often)

Get and install the signify *test|not-to-be-trusted* key


# ftp -o /etc/signify/openbsd-60-syspatch.pub \

http://syspatch.openbsd.org/pub/OpenBSD/6.0/syspatch/amd64/openbsd-60-syspatch.pub

In the future, patches will be signed with the original release key.

Using syspatch
==

Check for available patches:
# syspatch -c

List installed patches:
$ syspatch -l

Install patches (all of them; syspatch(8) is an all-or-nothing solution):
# syspatch

Revert the most recent patch:
# syspatch -r
---8<---

That's it, enjoy or cry! ;-)
Thank you all!

-- 
Antoine



Re: reloading pf through ansible easy hook

2016-11-23 Thread Antoine Jacoutot
On Wed, Nov 23, 2016 at 09:40:48AM -0500, sven falempin wrote:
> On Mon, Nov 21, 2016 at 5:48 PM, Antoine Jacoutot <ajacou...@bsdfrog.org> 
> wrote:
> >
> > On Mon, Nov 21, 2016 at 05:34:35PM -0500, sven falempin wrote:
> > > Ansible is already managing pkg and service of openBSD , cool
> > >
> > > If one want to manage pf with it, and push or modify a few files,
> > > on must run - command: /sbin/pfctl -f {{ dank.config }}
> > >
> > > Yet - service could be use, if this glue was in the rc.d directory :
> >
> > You can easily create an ansible role|module to do that natively.
> > The rc.d framework is only meant to handle real daemons.
> > We don't want it to manage pf, quota, network, mounts...
> >
> > --
> > Antoine
> 
> I see your point and agree, OTH
> and not for the sake of arguing,
> 
> PF is inside rc.conf , so rcctl manages it, so rc.d
> could have a relation.

shlib_dirs is also in rc.conf, I don't see any relation to rc.d...

-- 
Antoine



Re: reloading pf through ansible easy hook

2016-11-21 Thread Antoine Jacoutot
On Mon, Nov 21, 2016 at 05:34:35PM -0500, sven falempin wrote:
> Ansible is already managing pkg and service of openBSD , cool
> 
> If one want to manage pf with it, and push or modify a few files,
> on must run - command: /sbin/pfctl -f {{ dank.config }}
> 
> Yet - service could be use, if this glue was in the rc.d directory :

You can easily create an ansible role|module to do that natively.
The rc.d framework is only meant to handle real daemons.
We don't want it to manage pf, quota, network, mounts...

-- 
Antoine



Re: syspatch(8): How to install patches?

2016-11-09 Thread Antoine Jacoutot
On Wed, Nov 09, 2016 at 07:12:38PM +1100, bytevolc...@safe-mail.net wrote:
> Hello,
> 
> In the manual page for syspatch(8), it provides a list of options, yet
> does not specify how to invoke it for fetching and installing the
> latest patches.
> 
> To avoid this confusion, it is worth adding a line like this:
> 
> "When invoked without options, syspatch(8) will fetch and install the
> latest batch of patches."

Yes. I have a few uncommitted things.
But it's still a moving target and cannot be used right now by most people 
anyway.
Thanks.

-- 
Antoine



Re: rcctl ls - services and daemons

2016-10-10 Thread Antoine Jacoutot
On Mon, Oct 10, 2016 at 06:43:05PM +0200, Jan Stary wrote:
> The rcctl(8) manpage makes the distinction between 'daemons' and 'services',
> and the description of some items in the output of 'rcctl ls'
> mentions only 'daemons'. But they are both 'services and deamons'
> in all cases (tested with e.g. postgresql running, stopped, or failed).

The current wording is correct. Service is like pf, multicast... you do not 
'start' nor 'stop' them using the rc.d framework.

> Index: rcctl.8
> ===
> RCS file: /cvs/src/usr.sbin/rcctl/rcctl.8,v
> retrieving revision 1.33
> diff -u -p -r1.33 rcctl.8
> --- rcctl.8   19 Jun 2016 10:54:20 -  1.33
> +++ rcctl.8   10 Oct 2016 16:37:06 -
> @@ -112,15 +112,15 @@ which can be one of:
>  .It Cm all
>  all services and daemons
>  .It Cm failed
> -enabled but stopped daemons
> +enabled but stopped services and daemons
>  .It Cm off
>  disabled services and daemons
>  .It Cm on
>  enabled services and daemons
>  .It Cm started
> -running daemons
> +running services and daemons
>  .It Cm stopped
> -stopped daemons
> +stopped services and daemons
>  .El
>  .It Cm order Op Ar daemon ...
>  Move the specified package daemons to the beginning of
> 

-- 
Antoine



Re: Improve error message in rcctl(8)

2016-09-06 Thread Antoine Jacoutot
On Tue, Sep 06, 2016 at 04:09:49PM -0400, Anthony Coulter wrote:
> Regarding Jiri's suggestion: Here is a diff that makes
> `rcctl ls all' only list executable files with valid service
> names.
> 
> This diff also fixes two problems with my original submission:
> 1. The use of `[' instead of `[[' causes filename expansion to
>take place on the right-hand side of the comparison; you get
>different results depending on which directory you're sitting
>in when you test. I have switched to `[[' to fix that problem.
> 2. There was a stray closing brace that somehow did not cause
>problems in testing.

That's not enough. It cannot start with a digit either.
I'm working on a better diff.

> Index: usr.sbin/rcctl/rcctl.sh
> ===
> RCS file: /open/anoncvs/cvs/src/usr.sbin/rcctl/rcctl.sh,v
> retrieving revision 1.104
> diff -u -p -r1.104 rcctl.sh
> --- usr.sbin/rcctl/rcctl.sh   30 Jul 2016 06:25:21 -  1.104
> +++ usr.sbin/rcctl/rcctl.sh   6 Sep 2016 20:03:33 -
> @@ -53,8 +53,8 @@ ls_rcscripts()
>  
>   cd /etc/rc.d && set -- *
>   for _s; do
> - [[ ${_s} = *.* ]] && continue
> - [ ! -d "${_s}" ] && echo "${_s}"
> + [[ "${_s}" != +([_0-9A-Za-z]) ]] && continue
> + [ -x "${_s}" ] && echo "${_s}"
>   done
>  }
>  
> @@ -182,7 +182,7 @@ svc_is_meta()
>  svc_is_special()
>  {
>   local _svc=$1
> - [ -n "${_svc}" ] || return
> + [[ "${_svc}" = +([_0-9A-Za-z]) ]] || return
>  
>   local _cached _ret
>  
> 

-- 
Antoine



Re: Improve error message in rcctl(8)

2016-09-06 Thread Antoine Jacoutot
On Tue, Sep 06, 2016 at 09:01:08PM +0200, ludovic coues wrote:
> 2016-09-06 20:53 GMT+02:00 Antoine Jacoutot <ajacou...@bsdfrog.org>:
> > On Tue, Sep 06, 2016 at 12:29:58PM -0400, Anthony Coulter wrote:
> >> Sometimes when I restart a service after changing its configuration file
> >> I accidentally type:
> >>
> >>  # rcctl restart smtpd.conf
> >>  /usr/sbin/rcctl: ${cached_svc_is_special_smtpd.conf}: bad substitution
> >>  /usr/sbin/rcctl[556]: set: cached_svc_is_special_smtpd.conf: is not an
> >>  identifier
> >>  rcctl: service smtpd.conf does not exist
> >>
> >> The message about a bad substitution is not helpful to the user, who
> >> only needs to know that smtpd.conf is not a service.
> >>
> >> The problem is the period in "smtpd.conf". Line 189 of rcctl fails:
> >>   _cached=$(eval print \${cached_svc_is_special_${_svc}})
> >>
> >> Special service names are thus limited to underscores and alphanumerics
> >> because they're concatenated into shell variable names. So instead of
> >> checking for [ -n ${_svc} ] at the top of svc_is_special, we ought to
> >> check that ${_svc} contains only legal characters.
> >>
> >> I check only in svc_is_special and not in any of the other places that
> >> test [ -n ${_svc} ] my only goal is to fix the error message people get
> >> when they try to start or enable configuration files, and this is the
> >> only place that needs the error. Adding a similar check to svc_is_avail
> >> would block an error message when someone creates an executable file
> >> called /etc/rc.d/foo.bar and then calls "rcctl enable foo.bar", but in
> >> that case I think the message "${foo.bar_flags}: bad substitution" is
> >> more helpful---the user is trying to create a service with an illegal
> >> name and the system is telling him why it will never work.
> >
> > Yes I agree this should be fixed.
> > What about this?
> >
> > Index: rcctl.sh
> > ===
> > RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
> > retrieving revision 1.104
> > diff -u -p -r1.104 rcctl.sh
> > --- rcctl.sh30 Jul 2016 06:25:21 -  1.104
> > +++ rcctl.sh6 Sep 2016 18:51:18 -
> > @@ -139,7 +139,7 @@ rcconf_edit_end()
> >  svc_is_avail()
> >  {
> > local _svc=$1
> > -   [ -n "${_svc}" ] || return
> > +   [[ "${_svc}" == +([_/+[:alnum:]]) ]] || return
> >
> > [ -x "/etc/rc.d/${_svc}" ] && return
> > svc_is_special ${_svc}
> >
> >
> > --
> > Antoine
> >
> 
> If people are using daemon named like fastcgi.exemple.com, this will
> break there config.

The daemon name has no importance. Only the rc.d script name does.
And in this case, we can install it as /etc/rc.d/fastcgi_exemple_com
We need to draw a line somewhere to prevent the crazyness...

-- 
Antoine



Re: Improve error message in rcctl(8)

2016-09-06 Thread Antoine Jacoutot
On Tue, Sep 06, 2016 at 12:29:58PM -0400, Anthony Coulter wrote:
> Sometimes when I restart a service after changing its configuration file
> I accidentally type:
> 
>  # rcctl restart smtpd.conf
>  /usr/sbin/rcctl: ${cached_svc_is_special_smtpd.conf}: bad substitution
>  /usr/sbin/rcctl[556]: set: cached_svc_is_special_smtpd.conf: is not an
>  identifier
>  rcctl: service smtpd.conf does not exist
> 
> The message about a bad substitution is not helpful to the user, who
> only needs to know that smtpd.conf is not a service.
> 
> The problem is the period in "smtpd.conf". Line 189 of rcctl fails:
>   _cached=$(eval print \${cached_svc_is_special_${_svc}})
> 
> Special service names are thus limited to underscores and alphanumerics
> because they're concatenated into shell variable names. So instead of
> checking for [ -n ${_svc} ] at the top of svc_is_special, we ought to
> check that ${_svc} contains only legal characters.
> 
> I check only in svc_is_special and not in any of the other places that
> test [ -n ${_svc} ] my only goal is to fix the error message people get
> when they try to start or enable configuration files, and this is the
> only place that needs the error. Adding a similar check to svc_is_avail
> would block an error message when someone creates an executable file
> called /etc/rc.d/foo.bar and then calls "rcctl enable foo.bar", but in
> that case I think the message "${foo.bar_flags}: bad substitution" is
> more helpful---the user is trying to create a service with an illegal
> name and the system is telling him why it will never work.

Yes I agree this should be fixed.
What about this?

Index: rcctl.sh
===
RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
retrieving revision 1.104
diff -u -p -r1.104 rcctl.sh
--- rcctl.sh30 Jul 2016 06:25:21 -  1.104
+++ rcctl.sh6 Sep 2016 18:51:18 -
@@ -139,7 +139,7 @@ rcconf_edit_end()
 svc_is_avail()
 {
local _svc=$1
-   [ -n "${_svc}" ] || return
+   [[ "${_svc}" == +([_/+[:alnum:]]) ]] || return
 
[ -x "/etc/rc.d/${_svc}" ] && return
svc_is_special ${_svc}


-- 
Antoine



Re: sysmerge.8: Mention PAGER behavior when undefined/empty

2016-09-06 Thread Antoine Jacoutot
On Mon, Sep 05, 2016 at 05:56:03PM -0400, Michael Reed wrote:
> As is done in other man pages.

Committed, thank you.

> ===
> RCS file: /cvs/src/usr.sbin/sysmerge/sysmerge.8,v
> retrieving revision 1.78
> diff -u -p -r1.78 sysmerge.8
> --- sysmerge.8  2 Sep 2016 12:17:33 -   1.78
> +++ sysmerge.8  5 Sep 2016 21:54:28 -
> @@ -126,6 +126,11 @@ the default is
>  .Xr vi 1 .
>  .It Ev PAGER
>  Specifies the pagination program to use.
> +If
> +.Ev PAGER
> +is empty or not set,
> +.Xr more 1
> +will be used.
>  .El
>  .Sh FILES
>  .Bl -tag -width "/var/sysmerge/xetc.tgz" -compact
> 

-- 
Antoine



Re: libtool -bindir support

2016-08-01 Thread Antoine Jacoutot
> > > Index: Link.pm
> > > ===
> > > RCS file: /cvs/src/usr.bin/libtool/LT/Mode/Link.pm,v
> > > retrieving revision 1.31
> > > diff -u -p -p -u -r1.31 Link.pm
> > > --- Link.pm   27 Apr 2016 09:50:57 -  1.31
> > > +++ Link.pm   1 Aug 2016 11:36:31 -
> > > @@ -127,6 +127,7 @@ sub run
> > >   'all-static',
> > >   'allow-undefined', # we don't care about THAT one
> > >   'avoid-version',
> > > + 'bindir:',
> > >   'dlopen:',
> > >   'dlpreopen:',
> > >   'export-dynamic',
> > > @@ -152,7 +153,7 @@ sub run
> > >   'version-info:',
> > >   'version-number:');
> > >  
> > > - # XXX options ignored: dlopen, dlpreopen, no-fast-install,
> > > + # XXX options ignored: bindir, dlopen, dlpreopen, no-fast-install,
> > >   #   no-install, no-undefined, precious-files-regex,
> > >   #   shrext, thread-safe, prefer-pic, prefer-non-pic
> > 
> > I'm wondering about the second hunk: is this a mix of options that we
> > don't support on purpose and of options that could be useful?
> > (eg. -no-undefined.)  So is the second hunk of this diff desirable?
> > 
> The main thing about that diff is that it has to go into a successful
> bulk.

I think that goes without saying...
I'll do that in a few.

> As for ignored options, it's informative. It tells us we ignore those
> options.   Which ones should actually be supported is another story.
> 

-- 
Antoine



Re: libtool -bindir support

2016-07-31 Thread Antoine Jacoutot
On July 31, 2016 7:14:21 PM GMT+02:00, j...@wxcvbn.org wrote:
>
>Making read(2) return EISDIR for directories breaks two ports, both
>because they use libtool -bindir.  cc(1) gets executed with an unknown
>option, -bindir, and a path such as /usr/local/bin, which then gets
>passed to ld(1).  ld(1) copes with read(2) returning 0, not with
>EISDIR.
>Thanks to Antoine who ran the bulk builds that exposed this problem.
>
>-bindir support is meaningless on OpenBSD so handling that option
>should
>be easy.  The problem is that I don't know how to implement it in
>libtool(1).  GNU libtool recognizes -bindir among cc flags, while our
>version seems to only handle options passed right after argv[0].
>
>I plan to work around that problem by using GNU libtool for the ports
>mentioned above, but someone else might want to poke at libtool(1)
>internals. :)
>
>-- 
>jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524
>E7EE

I can have a look at it during g2k16 if no one beats me to it.
-- 
Antoine


Re: rcctl ls faulty -> failed

2016-03-29 Thread Antoine Jacoutot
On Tue, Mar 29, 2016 at 10:48:17AM -0400, Ian Darwin wrote:
> On Tue, Mar 29, 2016 at 03:29:27PM +0200, Antoine Jacoutot wrote:
> > Hi.
> > 
> > We'd like to rename the 'faulty' listing to 'failed'.
> > i.e. rcctl ls failed
> > 
> > Index: etc/daily
> > ===
> > RCS file: /cvs/src/etc/daily,v
> > retrieving revision 1.85
> > diff -u -p -u -p -r1.85 daily
> > --- etc/daily   28 Jan 2016 15:45:34 -  1.85
> > +++ etc/daily   29 Mar 2016 13:25:59 -
> > @@ -127,7 +127,7 @@ while [ "X$ROOTBACKUP" = X1 ]; do
> >  done
> >  
> >  next_part "Services that should run but don't:"
> 
> While you're there, can you please change "should run but don't" to
> "should be running but aren't" ? The current wording is awkward,
> and also implies that they don't run (ie. they fail to start)
> when in fact they may have been running but been shut down
> manually, or failed. Language should be precise as well as concise.

Sure.

-- 
Antoine



rcctl ls faulty -> failed

2016-03-29 Thread Antoine Jacoutot
Hi.

We'd like to rename the 'faulty' listing to 'failed'.
i.e. rcctl ls failed

'faulty' does sound a bit weird and is not obvious to remember.
Now the question is should we keep supporting the 'faulty' keyword or not?
I'm not in favor of adding a knob especially when it's just an alias; that'd 
also mean documenting it.

Here's a diff that does s/faulty/failed
Would that of any concern for anyone?



Index: etc/daily
===
RCS file: /cvs/src/etc/daily,v
retrieving revision 1.85
diff -u -p -u -p -r1.85 daily
--- etc/daily   28 Jan 2016 15:45:34 -  1.85
+++ etc/daily   29 Mar 2016 13:25:59 -
@@ -127,7 +127,7 @@ while [ "X$ROOTBACKUP" = X1 ]; do
 done
 
 next_part "Services that should run but don't:"
-rcctl ls faulty
+rcctl ls failed
 
 next_part "Checking subsystem status:"
 if [ "X$VERBOSESTATUS" != X0 ]; then
Index: usr.sbin/rcctl/rcctl.8
===
RCS file: /cvs/src/usr.sbin/rcctl/rcctl.8,v
retrieving revision 1.30
diff -u -p -u -p -r1.30 rcctl.8
--- usr.sbin/rcctl/rcctl.8  30 Jan 2016 18:57:31 -  1.30
+++ usr.sbin/rcctl/rcctl.8  29 Mar 2016 13:25:59 -
@@ -103,7 +103,7 @@ which can be one of:
 .Bl -tag -width started -offset indent -compact
 .It Cm all
 all services and daemons
-.It Cm faulty
+.It Cm failed
 enabled but stopped daemons
 .It Cm off
 disabled services and daemons
@@ -171,7 +171,7 @@ exits with 0 if the daemon or service is
 .Nm Cm getdef Ar daemon | service Op Cm status
 exits with 0 if the daemon or service is enabled by default
 and 1 if it is not.
-.Nm Cm ls faulty
+.Nm Cm ls failed
 exits with 1 if an enabled daemon is not running.
 Otherwise, the
 .Nm
Index: usr.sbin/rcctl/rcctl.sh
===
RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
retrieving revision 1.91
diff -u -p -u -p -r1.91 rcctl.sh
--- usr.sbin/rcctl/rcctl.sh 28 Mar 2016 08:10:19 -  1.91
+++ usr.sbin/rcctl/rcctl.sh 29 Mar 2016 13:25:59 -
@@ -31,7 +31,7 @@ usage()
"usage: rcctl get|getdef|set service | daemon [variable [arguments]]
rcctl [-df] $(echo ${_rc_actions} | tr "[:blank:]" "|") daemon ...
rcctl disable|enable|order [daemon ...]
-   rcctl ls all|faulty|off|on|started|stopped"
+   rcctl ls all|failed|off|on|started|stopped"
 }
 
 needs_root()
@@ -182,7 +182,7 @@ svc_ls()
echo ${_special_svcs} | tr "[:blank:]" "\n"
) | sort
;;
-   faulty)
+   failed)
for _svc in $(svc_ls on); do
! svc_is_special ${_svc} && \
! /etc/rc.d/${_svc} check >/dev/null && 
\
@@ -444,7 +444,7 @@ ret=0
 case ${action} in
ls)
lsarg=$2
-   [[ ${lsarg} == @(all|faulty|off|on|started|stopped) ]] || usage
+   [[ ${lsarg} == @(all|failed|off|on|started|stopped) ]] || usage
;;
order)
shift 1
@@ -529,7 +529,7 @@ case ${action} in
;;
ls)
# some rc.d(8) scripts need root for rc_check()
-   [[ ${lsarg} == @(started|stopped|faulty) ]] && needs_root 
${action} ${lsarg}
+   [[ ${lsarg} == @(started|stopped|failed) ]] && needs_root 
${action} ${lsarg}
svc_ls ${lsarg}
;;
order)




-- 
Antoine



Re: Xorg stipple

2016-03-09 Thread Antoine Jacoutot
On Wed, Mar 09, 2016 at 05:09:13PM -0600, joshua stein wrote:
> Is anyone seriously finding video/Xorg bugs through the default X
> stipple pattern anymore?  Xorg changed the default to draw a black
> background a while ago (with stipple enabled using the -retro flag),
> but we have this local change that reverted it while adding a silly
> -retard flag in order to show the black background.
> 
> I think we can finally stop partying like it's 1989 (vax is dead,
> after all) and have X show a solid black background by default.

I am fully supporting of this move. I am currently patching GDM to prevent 
having the ugly stipple pattern.


> Index: dix/globals.c
> ===
> RCS file: /var/cvs/xenocara/xserver/dix/globals.c,v
> retrieving revision 1.11
> diff -u -p -u -p -r1.11 globals.c
> --- dix/globals.c 16 Sep 2015 19:10:20 -  1.11
> +++ dix/globals.c 9 Mar 2016 22:57:54 -
> @@ -118,11 +118,7 @@ const char *defaultCursorFont = COMPILED
>  FontPtr defaultFont;/* not declared in dix.h to avoid including 
> font.h in
> every compilation of dix code */
>  CursorPtr rootCursor;
> -#ifndef __OpenBSD__
>  Bool party_like_its_1989 = FALSE;
> -#else
> -Bool party_like_its_1989 = TRUE;
> -#endif
>  Bool whiteRoot = FALSE;
>  
>  TimeStamp currentTime;
> Index: os/utils.c
> ===
> RCS file: /var/cvs/xenocara/xserver/os/utils.c,v
> retrieving revision 1.21
> diff -u -p -u -p -r1.21 utils.c
> --- os/utils.c7 Nov 2015 16:48:53 -   1.21
> +++ os/utils.c9 Mar 2016 22:57:37 -
> @@ -579,11 +579,7 @@ UseMsg(void)
>  ErrorF("-r turns off auto-repeat\n");
>  ErrorF("r  turns on auto-repeat \n");
>  ErrorF("-render [default|mono|gray|color] set render color alloc 
> policy\n");
> -#ifndef __OpenBSD__
>  ErrorF("-retro start with classic stipple and cursor\n");
> -#else
> -ErrorF("-retard start with black background and no 
> cursor\n");
> -#endif
>  ErrorF("-s #   screen-saver timeout (minutes)\n");
>  ErrorF("-seat string   seat to run on\n");
>  ErrorF("-t #   default pointer threshold (pixels/t)\n");
> @@ -918,13 +914,8 @@ ProcessCommandLine(int argc, char *argv[
>  defaultKeyboardControl.autoRepeat = TRUE;
>  else if (strcmp(argv[i], "-r") == 0)
>  defaultKeyboardControl.autoRepeat = FALSE;
> -#ifndef __OpenBSD__
>   else if ( strcmp( argv[i], "-retro") == 0)
>  party_like_its_1989 = TRUE;
> -#else
> - else if ( strcmp( argv[i], "-retard") == 0)
> - party_like_its_1989 = FALSE;
> -#endif
>  else if (strcmp(argv[i], "-s") == 0) {
>  if (++i < argc)
>  defaultScreenSaverTime = ((CARD32) atoi(argv[i])) *
> 

-- 
Antoine



Re: diff to /etc/examples/printcap and sysmerge

2016-02-26 Thread Antoine Jacoutot
On Fri, Feb 26, 2016 at 09:17:16AM -0600, Chris Bennett wrote:
> On Thu, Feb 25, 2016 at 07:56:54PM -0700, Theo de Raadt wrote:
> > Chris, you continue to amaze me.
> > 
> > Upon running sysmerge, that will break everyone's setup.
> > 
> > Like, can you try stuff before you send it out?
> > 
> > I'm done.
> > 
> > > /etc/examples/printcap doesn't match
> > > #define   _PATH_DEFSPOOL  "/var/spool/output/lpd"
> > > 
> > > Which seems sensible to keep lpd jobs out of output directory
> > > 
> > > Index: printcap
> > > ===
> > > RCS file: /cvs/src/etc/examples/printcap,v
> > > retrieving revision 1.1
> > > diff -u -p -r1.1 printcap
> > > --- printcap  12 Jul 2014 03:52:39 -  1.1
> > > +++ printcap  25 Feb 2016 20:53:56 -
> > > @@ -1,7 +1,7 @@
> > >  #$OpenBSD: printcap,v 1.1 2014/07/12 03:52:39 deraadt Exp $
> > >  
> > >  #lp|local line printer:\
> > > -#:lp=/dev/lp:sd=/var/spool/output:lf=/var/log/lpd-errs:
> > > +#:lp=/dev/lp:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:
> > >  
> > >  #rp|remote line printer:\
> > > -#
> > > :lp=:rm=printhost:rp=lp:sd=/var/spool/output:lf=/var/log/lpd-errs:
> > > +#
> > > :lp=:rm=printhost:rp=lp:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:
> > > 
> > > OK?
> > > 
> > > Chris
> > > 
> > 
> 
> I did not realize that sysmerge did a checksum on the files in
> /etc/examples.
> What else needs to be changed to make my change acceptable?
> 
> I base my change both on the different directories in the lpd/lpr code
> and the fact that some packages, such as apsfilter create an lpd
> subdirectory also with another subdirectory for each printer to keep the
> print queue files destinations clear rather than all bunched together.

I don't think your change would break anything. This is just a sample file.
sysmerge will just warn about the configuration change so that one can look in 
case there's been a syntax change but that's all.

Theo, am I missing anything?

-- 
Antoine



Re: libgtop2: Use getifaddrs(3) instead of KVM

2015-12-05 Thread Antoine Jacoutot
On Sat, Dec 05, 2015 at 05:05:07PM +0100, Martin Pieuchot wrote:
> Here's a rewrite of glibtop_get_netload_p().  I tested it with custom
> code because I could not trigger this code path with our ports.
> 
> This unbreaks devel/libgtop2 after the recent  commit.
> 
> I believe this should go upstream, how should I submit this?

You can open a bug report here: https://bugzilla.gnome.org/
Jasper and I have commit access to gnome and since it's OpenBSD-only code, it 
can be pushed pretty fast.

 
> ok?
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/libgtop2/Makefile,v
> retrieving revision 1.130
> diff -u -p -r1.130 Makefile
> --- Makefile  22 May 2015 11:31:13 -  1.130
> +++ Makefile  5 Dec 2015 15:58:01 -
> @@ -6,7 +6,7 @@ GNOME_VERSION=2.30.0
>  GNOME_PROJECT=   libgtop
>  PKGNAME= libgtop2-${VERSION}
>  
> -REVISION=3
> +REVISION=4
>  
>  SHARED_LIBS= gtop-2.09.0 # .10.0
>  
> Index: patches/patch-sysdeps_openbsd_netload_c
> ===
> RCS file: patches/patch-sysdeps_openbsd_netload_c
> diff -N patches/patch-sysdeps_openbsd_netload_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-sysdeps_openbsd_netload_c   5 Dec 2015 15:59:31 -
> @@ -0,0 +1,345 @@
> +$OpenBSD$
> +
> +Rewrite of glibtop_get_netload_p() to use getifaddrs(3) instead of KVM.
> +
> +--- sysdeps/openbsd/netload.c.orig   Mon Apr 28 23:09:24 2014
>  sysdeps/openbsd/netload.cSat Dec  5 16:27:56 2015
> +@@ -1,48 +1,39 @@
> +-/* Copyright (C) 1998-99 Martin Baulig
> +-   This file is part of LibGTop 1.0.
> ++/*
> ++ * Copyright (c) 2015 Martin Pieuchot 
> ++ *
> ++ * Permission to use, copy, modify, and distribute this software for any
> ++ * purpose with or without fee is hereby granted, provided that the above
> ++ * copyright notice and this permission notice appear in all copies.
> ++ *
> ++ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> ++ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> ++ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> ++ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> ++ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> ++ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> ++ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> ++ */
> + 
> +-   Contributed by Martin Baulig , October 1998.
> ++#include "config.h"
> + 
> +-   LibGTop is free software; you can redistribute it and/or modify it
> +-   under the terms of the GNU General Public License as published by
> +-   the Free Software Foundation; either version 2 of the License,
> +-   or (at your option) any later version.
> ++#include 
> ++#include 
> ++#include 
> + 
> +-   LibGTop is distributed in the hope that it will be useful, but WITHOUT
> +-   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> +-   FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> +-   for more details.
> +-
> +-   You should have received a copy of the GNU General Public License
> +-   along with LibGTop; see the file COPYING. If not, write to the
> +-   Free Software Foundation, Inc., 59 Temple Place - Suite 330,
> +-   Boston, MA 02111-1307, USA.
> +-*/
> +-
> +-#include 
> +-#include 
> +-#include 
> +-#include 
> +-
> +-#include 
> +-
> +-#include 
> +-
> + #include 
> + #include 
> +-#include 
> + 
> +-#include 
> +-
> +-#include 
> +-
> + #include 
> +-#define _KERNEL
> + #include 
> +-#undef _KERNEL
> + #include 
> + 
> ++#include 
> ++
> ++#include "glibtop.h"
> ++#include "glibtop/netload.h"
> ++
> + static const unsigned long _glibtop_sysdeps_netload =
> ++(1L << GLIBTOP_NETLOAD_MTU) +
> + (1L << GLIBTOP_NETLOAD_IF_FLAGS) +
> + (1L << GLIBTOP_NETLOAD_PACKETS_IN) +
> + (1L << GLIBTOP_NETLOAD_PACKETS_OUT) +
> +@@ -55,183 +46,115 @@ static const unsigned long _glibtop_sysdeps_netload =
> + (1L << GLIBTOP_NETLOAD_ERRORS_TOTAL) +
> + (1L << GLIBTOP_NETLOAD_COLLISIONS);
> + 
> +-static const unsigned _glibtop_sysdeps_netload_data =
> +-(1L << GLIBTOP_NETLOAD_ADDRESS) +
> +-(1L << GLIBTOP_NETLOAD_SUBNET) +
> +-(1L << GLIBTOP_NETLOAD_MTU);
> +-
> +-/* nlist structure for kernel access */
> +-static struct nlist nlst [] = {
> +-{ "_ifnet" },
> +-{ 0 }
> +-};
> +-
> +-/* Init function. */
> +-
> + void
> + _glibtop_init_netload_p (glibtop *server)
> + {
> + server->sysdeps.netload = _glibtop_sysdeps_netload;
> +-
> +-if (kvm_nlist (server->machine.kd, nlst) < 0)
> +-glibtop_error_io_r (server, "kvm_nlist");
> + }
> + 
> +-/* Provides Network statistics. */
> +-
> + void
> + glibtop_get_netload_p (glibtop *server, glibtop_netload *buf,
> +const char 

Re: rcctl action multiple daemons

2015-10-03 Thread Antoine Jacoutot
On Wed, Sep 30, 2015 at 01:40:44PM +0200, Antoine Jacoutot wrote:
> On Wed, Sep 30, 2015 at 12:30:52PM +0200, Martijn van Duren wrote:
> > ping
> 
> I am still pondering the pros and cons...

I'll probably commit your diff tomorrow, thanks.

-- 
Antoine



Re: rc script for ftp-proxy with v6

2015-09-12 Thread Antoine Jacoutot
On Sat, Sep 12, 2015 at 01:20:39PM +0100, Stuart Henderson wrote:
> ftp-proxy can only open one listening socket, so to use it with
> both IPv4 and IPv6, two instances are required. Now that rc.subr
> does exact matches of the process name, we could add a separate
> rc script for this. Do we want to do this?
> 
> (snmpd and ntpd have the same restriction, but don't have a simple
> command line flag that would allow them to be handled in this way).

I am fine with it except for the default ntpd_flags change ;-)

> 
> Index: rc.d/ftpproxy6
> ===
> RCS file: rc.d/ftpproxy6
> diff -N rc.d/ftpproxy6
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ rc.d/ftpproxy612 Sep 2015 12:16:37 -
> @@ -0,0 +1,11 @@
> +#!/bin/sh
> +#
> +# $OpenBSD$
> +
> +daemon="/usr/sbin/ftp-proxy -6"
> +
> +. /etc/rc.d/rc.subr
> +
> +rc_reload=NO
> +
> +rc_cmd $1
> Index: rc.conf
> ===
> RCS file: /cvs/src/etc/rc.conf,v
> retrieving revision 1.204
> diff -u -p -r1.204 rc.conf
> --- rc.conf   3 Aug 2015 04:19:25 -   1.204
> +++ rc.conf   12 Sep 2015 12:16:37 -
> @@ -22,6 +22,7 @@ dhcrelay_flags=NO   # for normal use: "-i 
>  dvmrpd_flags=NO
>  ftpd_flags=NO# set to NO if ftpd is running out of inetd
>  ftpproxy_flags=NO
> +ftpproxy6_flags=NO
>  hostapd_flags=NO
>  hotplugd_flags=NO
>  httpd_flags=NO
> @@ -40,7 +41,7 @@ mopd_flags=NO
>  mrouted_flags=NO # be sure to enable multicast_router below
>  npppd_flags=NO
>  nsd_flags=NO
> -ntpd_flags=
> +ntpd_flags=NO
>  ospfd_flags=NO
>  ospf6d_flags=NO
>  pflogd_flags=# add more flags, e.g. "-s 256"
> Index: rc
> ===
> RCS file: /cvs/src/etc/rc,v
> retrieving revision 1.460
> diff -u -p -r1.460 rc
> --- rc28 Aug 2015 18:10:46 -  1.460
> +++ rc12 Sep 2015 12:16:37 -
> @@ -488,7 +488,7 @@ if ifconfig lo0 inet6 >/dev/null 2>&1; t
>  fi
>  
>  start_daemon hostapd lpd smtpd slowcgi httpd ftpd
> -start_daemon ftpproxy tftpd tftpproxy identd inetd rarpd bootparamd
> +start_daemon ftpproxy ftpproxy6 tftpd tftpproxy identd inetd rarpd bootparamd
>  start_daemon rbootd mopd spamd spamlogd sndiod
>  echo '.'
>  
> 

-- 
Antoine



Re: rcctl ls: give an argument to needs_root()

2015-08-01 Thread Antoine Jacoutot
On Sat, Aug 01, 2015 at 11:23:56AM +0200, Theo Buehler wrote:
 If the `rcctl ls' command is given an argument that requires root,
 the error message has a awkward space in front of the colon since
 no argument is passed to the needs_root() function:
 
 $ rcctl ls started
 rcctl : need root privileges
 
 Since this is the only place where `needs_root()' is called without an
 argument, the following seems to be more consistent with the rest of
 the script:

Right, thanks.
I will fix this and tweak the output a bit.

 Index: usr.sbin/rcctl/rcctl.sh
 ===
 RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
 retrieving revision 1.76
 diff -u -p -r1.76 rcctl.sh
 --- usr.sbin/rcctl/rcctl.sh   25 Jul 2015 04:12:43 -  1.76
 +++ usr.sbin/rcctl/rcctl.sh   1 Aug 2015 09:16:49 -
 @@ -485,7 +485,7 @@ case ${action} in
   ;;
   ls)
   # some rc.d(8) scripts need root for rc_check()
 - [[ ${lsarg} == @(started|stopped|faulty) ]]  needs_root
 + [[ ${lsarg} == @(started|stopped|faulty) ]]  needs_root 
 ${action} ${lsarg}
   svc_ls ${lsarg}
   ;;
   order)
 

-- 
Antoine



Re: sed -i

2015-07-17 Thread Antoine Jacoutot
On Fri, Jul 17, 2015 at 12:57:12PM -0400, Brian Callahan wrote:
 
 
 On 07/17/15 12:10, Jasper Lievisse Adriaanse wrote:
  Hi,
  
  Here's a diff to add the '-i' flag to sed to do inplace edits. It's mostly
  from FreeBSD with some adjustments to prevent a race with unlink() and 
  fopen()
  during the tempfile creation.
  
  It's been tested in a full ports bulk (thanks aja), and went through a build
  of base and xenocara.
  Regress tests will also be added for this.
  
  This diff is already OK millert@. Any more OKs?
  
 
 Cool. This saves me having to install coreutils just to work on some
 school projects.

You mean gsed right?


 ok bcallah@, fwiw.
 
  Index: defs.h
  ===
  RCS file: /cvs/src/usr.bin/sed/defs.h,v
  retrieving revision 1.5
  diff -u -p -r1.5 defs.h
  --- defs.h  19 Jan 2015 15:30:52 -  1.5
  +++ defs.h  16 Jul 2015 18:45:58 -
  @@ -128,6 +128,7 @@ typedef struct {
  char *space;/* Current space pointer. */
  size_t len; /* Current length. */
  int deleted;/* If deleted. */
  +   int append_newline; /* If originally terminated by \n. */
  char *back; /* Backing memory. */
  size_t blen;/* Backing memory length. */
   } SPACE;
  Index: extern.h
  ===
  RCS file: /cvs/src/usr.bin/sed/extern.h,v
  retrieving revision 1.9
  diff -u -p -r1.9 extern.h
  --- extern.h13 Apr 2015 05:11:23 -  1.9
  +++ extern.h16 Jul 2015 00:23:57 -
  @@ -40,17 +40,19 @@ extern regmatch_t *match;
   extern size_t maxnsub;
   extern u_long linenum;
   extern size_t appendnum;
  -extern int lastline;
   extern int Eflag, aflag, eflag, nflag;
  -extern char *fname;
  +extern const char *fname, *outfname;
  +extern FILE *infile, *outfile;
   
   voidcfclose(struct s_command *, struct s_command *);
   voidcompile(void);
  -voidcspace(SPACE *, char *, size_t, enum e_spflag);
  +voidcspace(SPACE *, const char *, size_t, enum e_spflag);
   char   *cu_fgets(char **, size_t *);
   voiderr(int, const char *, ...);
   int mf_fgets(SPACE *, enum e_spflag);
  +int lastline(void);
   voidprocess(void);
  +voidresetranges(void);
   char   *strregerror(int, regex_t *);
   void   *xmalloc(size_t);
   void   *xreallocarray(void *, size_t, size_t);
  Index: main.c
  ===
  RCS file: /cvs/src/usr.bin/sed/main.c,v
  retrieving revision 1.18
  diff -u -p -r1.18 main.c
  --- main.c  26 Nov 2014 18:34:51 -  1.18
  +++ main.c  16 Jul 2015 19:21:16 -
  @@ -34,6 +34,7 @@
*/
   
   #include sys/types.h
  +#include sys/stat.h
   
   #include ctype.h
   #include errno.h
  @@ -45,6 +46,7 @@
   #include stdlib.h
   #include string.h
   #include unistd.h
  +#include libgen.h
   
   #include defs.h
   #include extern.h
  @@ -78,15 +80,23 @@ struct s_flist {
*/
   static struct s_flist *files, **fl_nextp = files;
   
  +FILE *infile;  /* Current input file */
  +FILE *outfile; /* Current output file */
  +
   int Eflag, aflag, eflag, nflag;
  +static int rval;   /* Exit status */
   
   /*
* Current file and line number; line numbers restart across compilation
  - * units, but span across input files.
  + * units, but span across input files.  The latter is optional if editing
  + * in place.
*/
  -char *fname;   /* File name. */
  +const char *fname; /* File name. */
  +const char *outfname;  /* Output file name */
  +static char oldfname[PATH_MAX];/* Old file name (for in-place editing) 
  */
  +static char tmpfname[PATH_MAX];/* Temporary file name (for in-place 
  editing) */
  +char *inplace; /* Inplace edit file extension */
   u_long linenum;
  -int lastline;  /* TRUE on the last line of the last 
  file */
   
   static void add_compunit(enum e_cut, char *);
   static void add_file(char *);
  @@ -97,7 +107,8 @@ main(int argc, char *argv[])
  int c, fflag;
   
  fflag = 0;
  -   while ((c = getopt(argc, argv, Eae:f:nru)) != -1)
  +   inplace = NULL;
  +   while ((c = getopt(argc, argv, Eae:f:i::nru)) != -1)
  switch (c) {
  case 'E':
  case 'r':
  @@ -114,6 +125,9 @@ main(int argc, char *argv[])
  fflag = 1;
  add_compunit(CU_FILE, optarg);
  break;
  +   case 'i':
  +   inplace = optarg ? optarg : ;
  +   break;
  case 'n':
  nflag = 1;
  break;
  @@ -123,8 +137,8 @@ main(int argc, char *argv[])
  default:
  case '?':
  (void)fprintf(stderr,
  -   

Re: [patch] Path typo in FAQ

2015-07-13 Thread Antoine Jacoutot
Fixed, thank you.

On Mon, Jul 13, 2015 at 01:01:32AM -0400, Michael McConville wrote:
 Index: faq/faq15.html
 ===
 RCS file: /cvs/www/faq/faq15.html,v
 retrieving revision 1.109
 diff -u -p -r1.109 faq15.html
 --- faq/faq15.html2 Jul 2015 05:49:04 -   1.109
 +++ faq/faq15.html13 Jul 2015 04:56:40 -
 @@ -369,7 +369,7 @@ scaled. Below is the relevant section fr
  
  p
  Additionally, some packages provide configuration and other information
 -in a file located in tt/usr/local/share/docs/pkg-readmes/tt.
 +in a file located in tt/usr/local/share/doc/pkg-readmes/tt.
  
  p
  Let us now continue with an example of a package which has dependencies:
 Index: faq/obsd-faq.txt
 ===
 RCS file: /cvs/www/faq/obsd-faq.txt,v
 retrieving revision 1.39
 diff -u -p -r1.39 obsd-faq.txt
 --- faq/obsd-faq.txt  5 Jun 2015 12:04:13 -   1.39
 +++ faq/obsd-faq.txt  13 Jul 2015 04:56:41 -
 @@ -13279,7 +13279,7 @@ the following example:
 FontPath   /usr/X11R6/lib/X11/fonts/Type1/
  
  Additionally, some packages provide configuration and other information in a
 -file located in /usr/local/share/docs/pkg-readmes.
 +file located in /usr/local/share/doc/pkg-readmes.
  
  Let us now continue with an example of a package which has dependencies:
  
 

-- 
Antoine



Re: nsd.conf in /etc/changelist

2015-07-07 Thread Antoine Jacoutot
On Sun, May 17, 2015 at 11:42:24AM +0200, Tim van der Molen wrote:
 nsd.conf may contain keys, so store its checksum only. Also update the
 path to unbound's root.key.

Thanks Tim, committed.
I did change /var/unbound/db/root.key to be stored as a checksum as well.


 Index: changelist
 ===
 RCS file: /cvs/src/etc/changelist,v
 retrieving revision 1.103
 diff -u -r1.103 changelist
 --- changelist2 Oct 2014 09:02:48 -   1.103
 +++ changelist17 May 2015 09:26:59 -
 @@ -145,8 +145,8 @@
  /var/cron/cron.allow
  /var/cron/cron.deny
  /var/cron/tabs/root
 -/var/nsd/etc/nsd.conf
 -/var/unbound/etc/root.key
 ++/var/nsd/etc/nsd.conf
 +/var/unbound/db/root.key
  /var/unbound/etc/unbound.conf
  /var/yp/Makefile.main
  /var/yp/Makefile.yp
 

-- 
Antoine



Re: ftp://ftp.fr

2015-06-27 Thread Antoine Jacoutot
On Fri, Jun 26, 2015 at 05:40:19PM +0200, Antoine Jacoutot wrote:
 Everything else will remain the same (cvs, rsync, ...); it's *only* the FTP 
 service that is going away.
 Thank you.

The hosting place of ftp.fr was going under major electrical maintenance this 
morning.
Everything should be back to normal now and all services should be available.
Sorry for the inconvenience.

-- 
Antoine



ftp://ftp.fr

2015-06-26 Thread Antoine Jacoutot
Hi.

As of tomorrow morning (CET), ftp.fr will stop serving files over FTP.
It is time people move to HTTP.

Everything else will remain the same (cvs, rsync, ...); it's *only* the FTP 
service that is going away.
Thank you.

-- 
Antoine



Re: don't error for duplicate identical type definitions

2015-06-10 Thread Antoine Jacoutot
 Any objections?

Considering I am the one who requested it, obviously no objection :-)
I've successfully tested this with ports that used to need ports/lang/gcc/4.9 .

So as far as I am concerned, OK for me.


 Index: c-decl.c
 ===
 RCS file: /OpenBSD/src/gnu/gcc/gcc/c-decl.c,v
 retrieving revision 1.2
 diff -u -p -r1.2 c-decl.c
 --- c-decl.c  29 Apr 2010 18:37:37 -  1.2
 +++ c-decl.c  2 May 2015 14:35:28 -
 @@ -1285,9 +1285,17 @@ diagnose_mismatched_decls (tree newdecl,
if (DECL_IN_SYSTEM_HEADER (newdecl) || DECL_IN_SYSTEM_HEADER (olddecl))
   return true;  /* Allow OLDDECL to continue in use.  */
  
 -  error (redefinition of typedef %q+D, newdecl);
 -  locate_old_decl (olddecl, error);
 -  return false;
 +  if (pedantic)
 + {
 +   pedwarn (redefinition of typedef %q+D, newdecl);
 +   if (flag_pedantic_errors)
 + {
 +   locate_old_decl (olddecl, error);
 +   return false;
 + }
 + }
 +
 +  return true;
  }
  
/* Function declarations can either be 'static' or 'extern' (no
 

-- 
Antoine



Re: luarexlib patch

2015-05-22 Thread Antoine Jacoutot
On Sun, May 10, 2015 at 10:20:10PM +0200, Mark Kettenis wrote:
 [ Sending this to tech@ since I don't just want the ports people to
   know about this ]
 
 Invoking the linker directly to build executables or shared libraries
 is strongly discouraged.  It really doesn't work properly unless you
 also link in the appropriate /usr/lib/crt*.o files.  We rely on code
 in these files for:
 
  * The private stack protector cookie.
 
  * For atexit(3) to work in shared libraries that can be dlclose()ed.
 
  * For pthread_atfork(3) to work in shared libraries that can be dlclose()ed.
 
 With binutils 2.15 linking will succeed, but you might see random
 crashes if executable and shared libraries happen to be loaded more
 than 2G apart from eachother.  With binutils 2.17 you'll see the
 R_X86_64_PC32 relocation failure, and linking will fail.
 
 In general, you should just invoke cc(1) instead of ld(1), since it
 will take care of all the magic.
 
 Diff below fixes things for devel/luarexlib.
 
 ok?

OK aja (with a rev bump)


 
 
 Index: patches/patch-src_common_mak
 ===
 RCS file: /cvs/ports/devel/luarexlib/patches/patch-src_common_mak,v
 retrieving revision 1.1
 diff -u -p -r1.1 patch-src_common_mak
 --- patches/patch-src_common_mak  9 Sep 2009 18:02:01 -   1.1
 +++ patches/patch-src_common_mak  10 May 2015 20:05:23 -
 @@ -1,6 +1,6 @@
  $OpenBSD: patch-src_common_mak,v 1.1 2009/09/09 18:02:01 jolan Exp $
  --- src/common.mak.orig  Sat Jun 14 20:11:08 2008
 -+++ src/common.mak   Wed Sep  9 12:13:00 2009
  src/common.mak   Sun May 10 22:02:08 2015
  @@ -3,11 +3,11 @@
   V = 2.4
   
 @@ -9,8 +9,9 @@ $OpenBSD: patch-src_common_mak,v 1.1 200
  +CFLAGS+= $(MYCFLAGS) $(DEFS) $(INC)
   TRG_AR = lib$(TRG).a
   TRG_SO = $(TRG).so
 - LD = ld
 +-LD = ld
  -LDFLAGS= -shared
 ++LD = cc
  +LDFLAGS= -fPIC -shared
   
   all: $(TRG_AR) $(TRG_SO)
 

-- 
Antoine



Re: chroot: add -c to use login class with -u

2015-05-18 Thread Antoine Jacoutot
On Mon, May 18, 2015 at 04:30:33PM -0600, Todd C. Miller wrote:
 Currently, chroot -u doesn't use the settings in /etc/login.conf.
 This adds a -c option to apply the via setusercontext().  We can't
 use LOGIN_SETALL since the uid change has to happen after chroot(2)
 and the groups may be specified via the -g option.
 
 Open questions:
 
 1) Should this just be default behavior with -u?  Are there cases
when you would *not* want to set the priority and resouce limits
based on the target user when one is specified?
 
 2) Does it make sense to apply LOGIN_SETPATH, LOGIN_SETPATH
and LOGIN_SETUMASK or are we better off with just LOGIN_SETPRIORITY
and LOGIN_SETRESOURCES?  Ultimately it depends on whether you
expect the chroot'd environment to be setup like a login session
or not.  We don't invoke the shell as a login shell though.

FWIW, I'd expect it to be setup like a login session.

 
 Opinions?
 
  - todd
 
 Index: usr.sbin/chroot/chroot.8
 ===
 RCS file: /cvs/src/usr.sbin/chroot/chroot.8,v
 retrieving revision 1.14
 diff -u -p -u -r1.14 chroot.8
 --- usr.sbin/chroot/chroot.8  8 Jul 2010 06:52:30 -   1.14
 +++ usr.sbin/chroot/chroot.8  18 May 2015 20:02:55 -
 @@ -37,6 +37,7 @@
  .Nd change root directory
  .Sh SYNOPSIS
  .Nm chroot
 +.Op Fl c
  .Op Fl g Ar group,group,...
  .Op Fl u Ar user
  .Ar newroot
 @@ -56,6 +57,13 @@ command is restricted to the superuser.
  .Pp
  The options are as follows:
  .Bl -tag -width Ds
 +.It Fl c
 +Apply the user's login class as defined in
 +.Xr login.conf 5
 +before executing
 +.Ar command .
 +This option may only be used in conjunction with
 +.Fl u .
  .It Fl g Ar group,group,...
  Override the primary and supplemental group IDs.
  The primary group ID is set to the first group in the list.
 @@ -94,6 +102,7 @@ is used.
  .El
  .Sh SEE ALSO
  .Xr ldd 1 ,
 +.Xr login.conf 5 ,
  .Xr group 5 ,
  .Xr passwd 5 ,
  .Xr environ 7
 Index: usr.sbin/chroot/chroot.c
 ===
 RCS file: /cvs/src/usr.sbin/chroot/chroot.c,v
 retrieving revision 1.13
 diff -u -p -u -r1.13 chroot.c
 --- usr.sbin/chroot/chroot.c  27 Oct 2009 23:59:51 -  1.13
 +++ usr.sbin/chroot/chroot.c  18 May 2015 19:56:15 -
 @@ -35,8 +35,10 @@
  #include errno.h
  #include grp.h
  #include limits.h
 +#include login_cap.h
  #include paths.h
  #include pwd.h
 +#include stdbool.h
  #include stdio.h
  #include stdlib.h
  #include string.h
 @@ -50,16 +52,21 @@ main(int argc, char **argv)
  {
   struct group*grp;
   struct passwd   *pwd;
 + login_cap_t *lc = NULL;
   const char  *shell;
   char*user, *group, *grouplist;
   gid_t   gidlist[NGROUPS_MAX];
   int ch, ngids;
 + boolcflag = false;
  
   ngids = 0;
   pwd = NULL;
   user = grouplist = NULL;
 - while ((ch = getopt(argc, argv, g:u:)) != -1) {
 + while ((ch = getopt(argc, argv, cg:u:)) != -1) {
   switch(ch) {
 + case 'c':
 + cflag = true;
 + break;
   case 'u':
   user = optarg;
   if (*user == '\0')
 @@ -83,6 +90,12 @@ main(int argc, char **argv)
   if (user != NULL  (pwd = getpwnam(user)) == NULL)
   errx(1, no such user `%s', user);
  
 + if (cflag) {
 + if (pwd == NULL)
 + errx(1, login class requires a user);
 + lc = login_getclass(pwd-pw_class);
 + }
 +
   while ((group = strsep(grouplist, ,)) != NULL) {
   if (*group == '\0')
   continue;
 @@ -104,6 +117,11 @@ main(int argc, char **argv)
   err(1, setgid);
   if (initgroups(user, pwd-pw_gid) == -1)
   err(1, initgroups);
 + if (lc != NULL) {
 + const int flags = LOGIN_SETALL  
 ~(LOGIN_SETGROUP|LOGIN_SETLOGIN|LOGIN_SETUSER);
 + if (setusercontext(lc, pwd, pwd-pw_uid, flags) == -1)
 + err(1, setusercontext);
 + }
   }
  
   if (chroot(argv[0]) != 0 || chdir(/) != 0)
 

-- 
Antoine



Re: [DIFF] /etc/rc: gracefully shut down base daemons too

2015-02-17 Thread Antoine Jacoutot
 I see how a clean shutdown might matter for, say, postgres.
 But what is the point in shutting down cron, sshd, ntpd, or unbound
 right before the system is going down anyway?
 
 Shutting down stuff like pflogd and syslogd before the system
 is actually going down might even be harmful.
 
 If it turns out there are one or two base daemons where shutting
 them down by running the rc.d(8) script is better than what
 currently happens, those one or two could get special handling
 in /etc/rc itself.  But so far, i don't remember that anybody ever
 saw a specific need for any of them.

I fully agree.

-- 
Antoine



Re: [DIFF] /etc/rc: gracefully shut down base daemons too

2015-02-17 Thread Antoine Jacoutot
On Tue, Feb 17, 2015 at 01:20:03PM +, Craig Skinner wrote:
 Produces (on 5.6 release) - with start up order reversed:
 
 root@box:~ 0# halt -p
 stopping package daemons: greyscanner postfix sshguard.
 stopping base daemons: cron spamlogd spamd sshd ntpd unbound nsd pflogd 
 syslogd.
 syncing disks... done

I cooked a patch for that a few months ago (actually 1 year ago iirc) but we 
decided not to go down that road for a reason I cannot recall right now.
And I was using the information from /var/run/rc.d instead to know what to 
shutdown exactly instead of greping /etc/rc.

 Index: rc
 ===
 RCS file: /cvs/src/etc/rc,v
 retrieving revision 1.447
 diff -u -p -r1.447 rc
 --- rc22 Jan 2015 19:00:24 -  1.447
 +++ rc17 Feb 2015 13:16:05 -
 @@ -131,17 +131,42 @@ fill_baddynamic()
   }
  }
  
 -start_daemon()
 +start_stop_daemon()
  {
 - local _n
 - for _n; do
 - eval _do=\${${_n}_flags}
 - if [ X${_do} != XNO ]; then
 - /etc/rc.d/${_n} start
 - fi
 + local _start_stop=$1
 + local _daemon _daemon_script
 + shift
 +
 + for _daemon
 + do
 + eval _do=\${${_daemon}_flags}
 + [[ ${_do} == 'NO' ]]  continue
 +
 + _daemon_script=/etc/rc.d/${_daemon}
 + [[ -e ${_daemon_script} ]] ||
 + {
 + print -n --  ${_daemon}(absent)
 + continue
 + }
 + [[ -x ${_daemon_script} ]] ||
 + {
 + print -n --  ${_daemon}(inexecutable)
 + continue
 + }
 + ${_daemon_script} ${_start_stop}
   done
  }
  
 +start_daemon()
 +{
 + start_stop_daemon 'start' $*
 +}
 +
 +stop_daemon()
 +{
 + start_stop_daemon 'stop' $*
 +}
 +
  make_keys()
  {
   if [ ! -f /etc/isakmpd/private/local.key ]; then
 @@ -269,12 +294,24 @@ if [ X$1 = Xshutdown ]; then
   while [ -n ${pkg_scripts} ]; do
   _r=${pkg_scripts##* }
   pkg_scripts=${pkg_scripts%%*( )${_r}}
 - [ -x /etc/rc.d/${_r} ]  /etc/rc.d/${_r} stop
 + stop_daemon ${_r}
   done
   echo '.'
   fi
  
   [ -f /etc/rc.shutdown ]  sh /etc/rc.shutdown
 +
 + print -n 'stopping base daemons:'
 + _daemons=$(egrep start_daemon[[:blank:]][[:alnum:]] /etc/rc |
 + sed s/start_daemon//)
 + while [[ -n ${_daemons} ]]
 + do
 + _daemon=${_daemons##* }
 + _daemons=${_daemons%%*( )${_daemon}}
 + stop_daemon ${_daemon}
 + done
 + print '.'
 +
   else
   echo single user: not running shutdown scripts
   fi
 @@ -513,11 +550,7 @@ rm -f /etc/rc.firsttime.run
  if [ -n ${pkg_scripts} ]; then
   echo -n 'starting package daemons:'
   for _r in $pkg_scripts; do
 - if [ -x /etc/rc.d/${_r} ]; then
 - start_daemon ${_r}
 - else
 - echo -n  ${_r}(absent)
 - fi
 + start_daemon ${_r}
   done
   echo '.'
  fi
 

-- 
Antoine



Re: unnbound vs file descriptors

2014-12-16 Thread Antoine Jacoutot
  may just a naive question..
  but did you sudo vipw 
  and put unbound class for unbound user?
 
 That's not neccesary anymore these days, I believe. The rc.d subsystem
 takes case of setting the proper class, if available.  At least it

That's correct.

 does not document setting the login class in the pwd db is needed. 

Because it's not :-)

-- 
Antoine



Re: Binary code patching and paravirtualization

2014-12-09 Thread Antoine Jacoutot
 in summer, I posted some paravirt patches for amd64. In response to the 
 comments I received then, I have created some infrastructure to binary 
 patch kernel code during boot. In order to get some feedback, I am posting 
 the whole paravirt  code patching diff here. Also, KVM users may be 
 interested in trying it (hi Antoine ;).

\o/ \o/ \o/ :-)

I assume we still need this:
printf 'change paravirt0\ny\n\n0x8\nq\n'  | config -ef /bsd
under Illumos?

 The rest of the diff is paravirtualization for KVM that partially also 
 uses the code patching infrastructure. The paravirtualization stuff seems 
 to work fine and gives some nice speed-up, but it still needs plenty of 
 cleanup before it can be committed.

s/nice/huge !

 There are some paravirtualization bits that are not specific to KVM. For 
 example, I introduce a running_on_hypervisor() function and skip some 
 delays during shutdown if it returns true. I think this should work for 
 most (all?) hypervisors, though it still needs some detection logic. 
 Making it depend on the CPUIDECX_HYPERV bit should catch the most common 
 hypervisors. Is this something we could commit already in order to see if 
 it causes any problems?
 
 Another question: Most of the infrastructure and the pointers to the code 
 that needs patching are only used at boot. Is there already a way to put 
 that into a dedicated section that is freed and reused after boot?

FWIW I've been running several iterations of this patch for the last 4/5 months 
on *all* my VMs.
It brings a ridiculous speed-up boost :-)

-- 
Antoine



fuck you pkg.conf

2014-11-29 Thread Antoine Jacoutot
Hi.

So. Each time pkg_add runs, it tries to connect to either PKG_PATH or to 
installpath from pkg.conf to fetch quirks (I assume).
When you have no network anymore (moving around with your laptop or whatever), 
and you want to install a local package, you're basically fucked:

$ time sudo pkg_add ./gmake-4.1.tgz
- hangs forever
- getting tired, so ^C
Fatal error: Caught SIGINT
 at /usr/libdata/perl5/OpenBSD/AddDelete.pm line 40.
1m57.24s real 0m0.15s user 0m0.08s system
- sometimes, that keeps the pkg db locked...


On my production machines, I have a regular job that removes the useless 
pkg.conf, but it happens often enough on my dev boxen now that I felt I should 
send something.
The problem is that each time I update using bsd.rd, /etc/pkg.conf is 
re-created... and I am not even talking about the fact that the created file is 
wrong since I usually do not install base from the same place I get packages -- 
but well.
Can we have a switch or whatever that would prevent pkg_add from trying to go 
online each time it's run please?

-- 
Antoine



Re: fuck you pkg.conf

2014-11-29 Thread Antoine Jacoutot
 But that said, why does your pkg.conf keep returning? I don't have one on
 my laptop at all, I probably removed it once after installing, but it

It returns each time I upgrade using bsd.rd.

-- 
Antoine



OpenBSD 5.6 Released

2014-11-01 Thread Antoine Jacoutot
 architecture,
   for example, amd64.  This is a list of what you will see:

INSTALL.amd64   cd56.isoindex.txt   xetc56.tgz
SHA256  cdboot* install56.fsxfont56.tgz
SHA256.sig  cdbr*   install56.iso   xserv56.tgz
base56.tgz  comp56.tgz  man56.tgz   xshare56.tgz
bsd*etc56.tgz   miniroot56.fs
bsd.mp* floppy56.fs pxeboot*
bsd.rd* game56.tgz  xbase56.tgz

   If you are new to OpenBSD, fetch _at least_ the file INSTALL.amd64
   and install56.iso.  The install56.iso file (roughly 250MB in size)
   is a one-step ISO-format install CD image which contains the various
   *.tgz files so you do not need to fetch them separately.

   If you prefer to use a USB flash drive, fetch install56.fs and
   follow the instructions in INSTALL.amd64.

5) If you are an expert, follow the instructions in the file called
   README; otherwise, use the more complete instructions in the
   file called INSTALL.amd64.  INSTALL.amd64 may tell you that you
   need to fetch other files.

6) Just in case, take a peek at:

http://www.OpenBSD.org/errata.html

   This is the page where we talk about the mistakes we made while
   creating the 5.6 release, or the significant bugs we fixed
   post-release which we think our users should have fixes for.
   Patches and workarounds are clearly described there.

Note: If you end up needing to write a raw floppy using Windows,
  you can use fdimage.exe located in the pub/OpenBSD/5.6/tools
  directory to do so.


- X.ORG FOR MOST ARCHITECTURES -

X.Org has been integrated more closely into the system.  This release
contains X.Org 7.7.  Most of our architectures ship with X.Org, including
amd64, sparc, sparc64 and macppc.  During installation, you can install
X.Org quite easily.  Be sure to try out xdm(1) and see how we have
customized it for OpenBSD.


- PORTS TREE ---

The OpenBSD ports tree contains automated instructions for building
third party software.  The software has been verified to build and
run on the various OpenBSD architectures.  The 5.6 ports collection,
including many of the distribution files, is included on the 3-CD
set.  Please see the PORTS file for more information.

Note: some of the most popular ports, e.g., the nginx web server
and several X applications, come standard with OpenBSD.  Also, many
popular ports have been pre-compiled for those who do not desire
to build their own binaries (see BINARY PACKAGES, below).


- BINARY PACKAGES WE PROVIDE ---

A large number of binary packages are provided.  Please see the PACKAGES
file (http://ftp.OpenBSD.org/pub/OpenBSD/5.6/PACKAGES) for more details.


- SYSTEM SOURCE CODE ---

The CD-ROMs contain source code for all the subsystems explained
above, and the README (http://ftp.OpenBSD.org/pub/OpenBSD/5.6/README)
file explains how to deal with these source files.  For those who
are doing an HTTP install, the source code for all four subsystems
can be found in the pub/OpenBSD/5.6/ directory:

xenocara.tar.gz ports.tar.gz   src.tar.gz sys.tar.gz


- THANKS ---

Ports tree and package building by Jasper Lievisse Adriaanse,
Pierre-Emmanuel Andre, Landry Breuil, Stuart Henderson, Peter Hessler,
Nick Holland, Paul Irofti, Sebastian Reitenbach, Miod Vallat, and
Christian Weisgerber.  System builds by Jasper Lievisse Adriaanse,
Kenji Aoyama, Theo de Raadt, Nick Holland, and Miod Vallat.
X11 builds by Jasper Lievisse Adriaanse, Kenji Aoyama, Todd Fries,
Nick Holland, and Miod Vallat.  ISO-9660 filesystem layout by
Theo de Raadt.

We would like to thank all of the people who sent in bug reports, bug
fixes, donation cheques, and hardware that we use.  We would also like
to thank those who pre-ordered the 5.6 CD-ROM or bought our previous
CD-ROMs.  Those who did not support us financially have still helped
us with our goal of improving the quality of the software.

Our developers are:

Aaron Bieber, Alexander Bluhm, Alexander Hall, Alexandr Shadchin,
Alexandre Ratchov, Andrew Fresh, Anil Madhavapeddy,
Anthony J. Bentley, Antoine Jacoutot, Austin Hook, Benoit Lecocq,
Bob Beck, Brad Smith, Brandon Mercer, Brent Cook, Bret Lambert,
Brett Mahar, Brian Callahan, Camiel Dobbelaar, Charles Longeau,
Chris Cappuccio, Christian Weisgerber, Christopher Zimmermann

Re: uhub(4) USB device (dis)connect

2014-10-31 Thread Antoine Jacoutot
On Fri, Oct 31, 2014 at 11:19:22PM +0100, Martin Pieuchot wrote:
 Device below changes uhub(4) to no longer check *all* the ports status
 of *all* the hubs on bus when one of those hubs requests an explore.
 
 This has the nice effect of reducing the delay/bus traffic when a port
 status change is detected which reduces (avoid) some timing related
 problems when connection devices.
 
 To do so, we only query the status of the ports having reported a status
 changed in the interrupt.
 
 I'd appreciate tests on various HC/archs.
 
 Comments, ok?

wunderbar!

 Index: uhub.c
 ===
 RCS file: /cvs/src/sys/dev/usb/uhub.c,v
 retrieving revision 1.74
 diff -u -p -r1.74 uhub.c
 --- uhub.c1 Oct 2014 08:29:01 -   1.74
 +++ uhub.c31 Oct 2014 22:00:38 -
 @@ -57,8 +57,11 @@ struct uhub_softc {
   struct device   sc_dev; /* base device */
   struct usbd_device  *sc_hub;/* USB device */
   struct usbd_pipe*sc_ipipe;  /* interrupt pipe */
 - u_int8_t*sc_statusbuf;  /* per port status buffer */
 - size_t  sc_statuslen;   /* status bufferlen */
 +
 + uint32_t sc_status; /* status from last interrupt */
 + uint8_t *sc_statusbuf;  /* per port status buffer */
 + size_t   sc_statuslen;  /* status bufferlen */
 +
   u_char  sc_running;
  };
  #define UHUB_PROTO(sc) ((sc)-sc_hub-ddesc.bDeviceProtocol)
 @@ -349,18 +352,24 @@ uhub_explore(struct usbd_device *dev)
  
   for (port = 1; port = dev-hub-nports; port++) {
   up = dev-hub-ports[port-1];
 - err = usbd_get_port_status(dev, port, up-status);
 - if (err) {
 - DPRINTF(%s: get port %d status failed, error=%s\n,
 - sc-sc_dev.dv_xname, port, usbd_errstr(err));
 - continue;
 - }
 - status = UGETW(up-status.wPortStatus);
 - change = UGETW(up-status.wPortChange);
 +
   reconnect = up-reattach;
   up-reattach = 0;
 - DPRINTF(%s: port %d status=0x%04x change=0x%04x\n,
 - sc-sc_dev.dv_xname, port, status, change);
 + change = 0;
 + status = 0;
 +
 + if (sc-sc_status  (1  port)) {
 + sc-sc_status = (1  port);
 +
 + if (usbd_get_port_status(dev, port, up-status))
 + continue;
 +
 + status = UGETW(up-status.wPortStatus);
 + change = UGETW(up-status.wPortChange);
 + DPRINTF(%s: port %d status=0x%04x change=0x%04x\n,
 + sc-sc_dev.dv_xname, port, status, change);
 + }
 +
   if (change  UPS_C_PORT_ENABLED) {
   usbd_clear_port_feature(dev, port, UHF_C_PORT_ENABLE);
   if (change  UPS_C_CONNECT_STATUS) {
 @@ -556,6 +565,8 @@ void
  uhub_intr(struct usbd_xfer *xfer, void *addr, usbd_status status)
  {
   struct uhub_softc *sc = addr;
 + uint32_t stats;
 + int i;
  
   if (usbd_is_dying(sc-sc_hub))
   return;
 @@ -563,6 +574,11 @@ uhub_intr(struct usbd_xfer *xfer, void *
   DPRINTF(%s: intr status=%d\n, sc-sc_dev.dv_xname, status);
   if (status == USBD_STALLED)
   usbd_clear_endpoint_stall_async(sc-sc_ipipe);
 - else if (status == USBD_NORMAL_COMPLETION)
 + else if (status == USBD_NORMAL_COMPLETION) {
 + for (i = 0; i  xfer-actlen; i++)
 + stats |= (uint32_t)(xfer-buffer[i])  (i * 8);
 + sc-sc_status = stats;
 +
   usb_needs_explore(sc-sc_hub, 0);
 + }
  }
 Index: usbdivar.h
 ===
 RCS file: /cvs/src/sys/dev/usb/usbdivar.h,v
 retrieving revision 1.64
 diff -u -p -r1.64 usbdivar.h
 --- usbdivar.h31 Oct 2014 12:43:33 -  1.64
 +++ usbdivar.h31 Oct 2014 21:12:55 -
 @@ -182,7 +182,7 @@ struct usbd_pipe {
  struct usbd_xfer {
   struct usbd_pipe   *pipe;
   void   *priv;
 - void   *buffer;
 + char   *buffer;
   u_int32_t   length;
   u_int32_t   actlen;
   u_int16_t   flags;
 

-- 
Antoine



Re: rcctl: find(1) service files in /etc/rc.d

2014-10-15 Thread Antoine Jacoutot
On Wed, Oct 15, 2014 at 10:11:18AM +0100, Craig R. Skinner wrote:
 On 2014-10-14 Tue 00:24 AM |, Antoine Jacoutot wrote:
  
  Makes sense yes. Not sure I'd want a function just for that one liner 
  though.
  I'll commit something tomorrow.
  
 
 Nice one, using shell internals.
 
 This restricts the listing to files which are also executable:

I don't think that's necessary.

 Index: rcctl.sh
 ===
 RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
 retrieving revision 1.45
 diff -u -p -r1.45 rcctl.sh
 --- rcctl.sh  15 Oct 2014 07:38:24 -  1.45
 +++ rcctl.sh  15 Oct 2014 09:01:35 -
 @@ -39,10 +39,12 @@ needs_root()
  ls_rcscripts() {
   local _s
  
 - cd /etc/rc.d  set -- *
 + cd /etc/rc.d || exit
 + set -- *
   for _s; do
   [ ${_s} = rc.subr ]  continue
 - [ ! -d ${_s} ]  echo ${_s}
 + [[ -d ${_s} ]]  continue
 + [[ -f ${_s}  -x ${_s} ]]  echo ${_s}
   done
  }
  
 

-- 
Antoine



Re: rcctl: find(1) service files in /etc/rc.d

2014-10-13 Thread Antoine Jacoutot
On Mon, Oct 13, 2014 at 09:31:05PM +0100, Craig R. Skinner wrote:
 Move 2 duplicate searches into a function.
 
 The diff also ignores (RCS) subdirectories.
 
 $ find /etc/rc.d ! -type f
 /etc/rc.d
 /etc/rc.d/RCS

Makes sense yes. Not sure I'd want a function just for that one liner though.
I'll commit something tomorrow.

 Index: rcctl.sh
 ===
 RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
 retrieving revision 1.43
 diff -u -p -r1.43 rcctl.sh
 --- rcctl.sh  11 Oct 2014 19:12:19 -  1.43
 +++ rcctl.sh  13 Oct 2014 20:10:34 -
 @@ -93,7 +93,7 @@ svc_get_defaults()
   print -r -- $(svc_default_enabled_flags ${_svc})
   svc_default_enabled ${_svc}
   else
 - for _i in $(ls -A /etc/rc.d | grep -v rc.subr); do
 + get_svc_list | while read _i; do
   echo ${_i}_flags=$(svc_default_enabled_flags ${_i})
   done
   for _i in ${_special_services}; do
 @@ -134,7 +134,7 @@ svc_get_status()
   svc_get_flags ${_svc}
   svc_is_enabled ${_svc}
   else
 - for _i in $(ls -A /etc/rc.d | grep -v rc.subr); do
 + get_svc_list | while read _i; do
   echo ${_i}_flags=$(svc_get_flags ${_i})
   done
   for _i in ${_special_services}; do
 @@ -175,6 +175,12 @@ svc_is_special()
   [ -n ${_svc} ] || return
  
   echo ${_special_services} | grep -qw ${_svc}
 +}
 +
 +get_svc_list()
 +{
 + # Ignore rc.subr  (RCS) subdirectories:
 + find /etc/rc.d -type f -maxdepth 1 ! -name rc.subr
  }
  
  append_to_pkg_scripts()
 

-- 
Antoine



Re: rcctl(8): Fetch default service flags

2014-10-10 Thread Antoine Jacoutot
 The problem occurs when I try to manage a service like nfsd which has a
 default set of flags. Consider the following commands, which basically
 performs what ansible does when the user is not supplying any extra
 arguments:
 ---
 # rcctl status nfsd
 NO
 # rcctl enable nfsd   
 
 # rcctl status nfsd 
 -tun 4
 #
 ---
 
 If I now run the tool again, still without any supplied arguments, it
 will compare the empty set of user supplied flags to -tun 4 which
 always differs. So ansible will now think it needs to change something
 forever :).
 
 To solve this I need the default flags to compare to the output of
 'status'.

Well in this case, I think you should pass the flags you want to ansible -- 
even if they are the same as the defaults.
I'm not very keen on adding a new knob...

-- 
Antoine



Re: rcctl(8): Fetch default service flags

2014-10-10 Thread Antoine Jacoutot
On Fri, Oct 10, 2014 at 02:50:40PM +0200, Patrik Lundin wrote:
 On Fri, Oct 10, 2014 at 01:50:52PM +0200, Antoine Jacoutot wrote:
   
   If I now run the tool again, still without any supplied arguments, it
   will compare the empty set of user supplied flags to -tun 4 which
   always differs. So ansible will now think it needs to change something
   forever :).
   
   To solve this I need the default flags to compare to the output of
   'status'.
  
  Well in this case, I think you should pass the flags you want to ansible -- 
  even if they are the same as the defaults.
  I'm not very keen on adding a new knob...
  
 
 This breaks the principle of least surprise. If you do not need to
 supply flags when calling rcctl in the shell you should not have to
 supply flags when using ansible.

But you should not have to.
If you don't pass any flags to ansible, why is ansible looking at the output of 
rcctl status to compare flags?
In saltstack, iirc what I implemented is that flags are only compared when one 
actually sets some.

-- 
Antoine



Re: rcctl(8): Fetch default service flags

2014-10-10 Thread Antoine Jacoutot
  4. Enable the service *without* any arguments (even if it has
 default arguments).

It's been discussed at lenght in Slovenia -- that's a known issue; the move of 
rc.conf to a parsed config file has had similar side effects on other stuffs.

 I see no way to do that with rcctl(8).
 You have to edit /etc/rc.conf.local manually and put:
   service_flags= 

Not true.
rcctl enable foobar flags ' '


-- 
Antoine



Re: rcctl(8): Fetch default service flags

2014-10-10 Thread Antoine Jacoutot
 Maby the expected results of our tools are different. My goal for the
 ansible module is that you either keep a specific set of flags in the
 
 playbook which will then get set if necessary, or you remove the flags
 and will instead get the system default.
 
 Not passing any arguments does not mean do not modify any flags, it
 means make sure we have the default flags. Because of this I will need

That's backward. From what I know of Puppet and SaltStack, they work totally 
different. They will never change anything on the system unless you intruct 
them to.
In your case you want that the absence of a configuration knob (flags in this 
case) resets what in rc.conf.local... I think that is *not* the element of 
least surprise :-)

-- 
Antoine



Re: rcctl(8): Fetch default service flags

2014-10-10 Thread Antoine Jacoutot
On Fri, Oct 10, 2014 at 08:02:17PM +0100, Stuart Henderson wrote:
 On 2014/10/10 15:19, Patrik Lundin wrote:
  Not passing any arguments does not mean do not modify any flags, it
  means make sure we have the default flags. Because of this I will need
  to check if the current set of flags are the default or not.
 
 Would it make sense for rcctl status to display something like
 default (-tun 4) or similar when it's using default flags (actually,
 to be more exact about what I mean, when the relevant foo_flags is
 not set in rc.conf.local - to distinguish it from being explicitly set
 in rc.conf.local to the same value that is the default).

Actually on second though, adding a 'default' command kind of make sense; I'm 
looking into it.

-- 
Antoine



Re: rcctl(8): special services and flags

2014-10-09 Thread Antoine Jacoutot
On Thu, Oct 09, 2014 at 09:02:14PM +0200, Patrik Lundin wrote:
 Hello,
 
 While working on rcctl(8) support for ansible I have run into a
 situation I am not sure how to deal with.
 
 Basically, if the user has supplied arguments we append
 flags whatever the user requested and this works good.
 
 If the user supplied no arguments, but there currently are flags set
 in rc.conf.local we append an empty flags argument to reset the
 default value.
 
 The later behaviour causes a problem when modifying special services
 like pf. When disabling pf a pf=NO is added to rc.conf.local as
 expected, but when trying to enable it again it will fail because the
 ansible module notices that flags are currently set (NO), and tries to
 call rcctl enable pf flags which fails: 

Why is ansible appending flags in the first place when no flags are configured?


 ---
 # rcctl enable pf flags 
 rcctl: pf is a special variable, cannot set flags
 ---
 
 I am not sure how to deal with this properly since I do not want to
 duplicate the _special_services variable in the module.
 
 A possible solution to this would be to relax the flags check in rcctl,
 so it only cares if there are actual flags supplied. See diff below for
 a suggestion on how to deal with this which seems to work.
 
 If I am going about this the wrong way any pointers are greatly
 appreciated of course!
 
 Regards,
 Patrik Lundin
 
 Index: rcctl.sh
 ===
 RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
 retrieving revision 1.38
 diff -u -p -u -r1.38 rcctl.sh
 --- rcctl.sh  1 Sep 2014 18:01:55 -   1.38
 +++ rcctl.sh  9 Oct 2014 18:17:56 -
 @@ -274,10 +274,14 @@ fi
  if [ -n $flag ]; then
   if [ $flag = flags ]; then
   if [ $action != enable ]; then
 - _rc_err ${0##*/}: \flags\ can only be set with 
 \enable\
 + if [ -n $4 ]; then
 + _rc_err ${0##*/}: \flags\ can only be set 
 with \enable\
 + fi
   fi
   if svc_is_special $svc; then
 - _rc_err ${0##*/}: \$svc\ is a special variable, 
 cannot set \flags\
 + if [ -n $4 ]; then
 + _rc_err ${0##*/}: \$svc\ is a special 
 variable, cannot set \flags\
 + fi
   fi
   if [ $4 = NO ]; then
   _rc_err ${0##*/}: \flags NO\ contradicts \enable\
 

-- 
Antoine



Re: rcctl(8): special services and flags

2014-10-09 Thread Antoine Jacoutot
 An example would be if the user started out with supplying -s to ntpd
 and then changes his mind and removes the flag. The idea is to then call
 rcctl with an empty flags argument to get the default set of flags
 instead.
 
 It was my understanding from the man page that this was the approriate
 way to do it, am I mistaken?

Hmm actually that makes sense yes.
Let me sleep on it... ;-)

-- 
Antoine



Re: rcctl(8): Fetch default service flags

2014-10-09 Thread Antoine Jacoutot
 The module wants to figure out if it should reset the flags in
 rc.conf.local to the default set if no arguments are supplied by the 
 user.

Can you provide an example. Because if not arguments are supplied, according to 
your previous mail, it should run like:
rcctl enable foobar flags
which will reset the flags anyway.

 The problem with this is that there is no way to find out what the 
 default flags are. This makes it hard to deal with a service like nfsd

But why do you need that exactly?
Note that I am not against modifying rcctl, I am just trying to understand the 
need...

-- 
Antoine



Re: rcctl(8): Fetch default service flags

2014-10-09 Thread Antoine Jacoutot
 Sorry, I should probably have been more clear on the reason I need it :).
 
 The main issue from the ansible perspective is to know if we are _going_
 to change something or not. The user may for example run ansible in
 --check mode where it should only report if it is about to change
 something or not.

Ok but then I don't understand why you need to know the default flags :-)
If you run rcctl status, it will tell you the current flags of the daemon; if 
these differ from the new flags you want to pass ansible then 'ansible --check' 
will report you that it will change the flags. Which is correct, no ?
Or did I misundertand something (I probably did...).

-- 
Antoine



Re: groupdel(8): preserve `+' line

2014-10-04 Thread Antoine Jacoutot
 Do people run this crap as root?  I wonder.  I certainly don't.

Yes. Just like useradd and such. These historical tools are harcoded in so many 
places and are expected to be present.
That said, having someone rewrites them in a sane way would be awesome.

-- 
Antoine



Re: sysmerge auto update

2014-07-20 Thread Antoine Jacoutot
On Sun, Jul 20, 2014 at 03:52:14PM +0800, Nathanael Rensen wrote:
 Since the switch to SHA256, sysmerge(8) has stopped auto-upgrading files 
 without
 local changes.

Oh right, I forgot that part. Thanks, I'll have a look.


 
 $ diff -u a b | grep -E '^\+' | sed '1d'
 +SHA256 (./etc/rc) = 
 0e1cb2e6c6d11941dab14853a8ab1888f1b14fad6588fa3e6230b8ef16b62ffd
 
 $ diff -u a b | grep -E '^\+' | sed '1d' | awk '{print $3}'
 =
 
 $ diff -u a b | sed -n 's/^+SHA256 (\(.*\)).*/\1/p'
 ./etc/rc
 
 Index: sysmerge.sh
 ===
 RCS file: /cvs/src/usr.sbin/sysmerge/sysmerge.sh,v
 retrieving revision 1.142
 diff -u -p -r1.142 sysmerge.sh
 --- sysmerge.sh   18 Jul 2014 10:43:29 -  1.142
 +++ sysmerge.sh   20 Jul 2014 07:20:45 -
 @@ -194,7 +194,7 @@ sm_populate() {
   fi
  
   # set auto-upgradable files
 - _D=$(diff -u ${WRKDIR}/${i} ${DESTDIR}/${DBDIR}/${i} | 
 grep -E '^\+' | sed '1d' | awk '{print $3}')
 + _D=$(diff -u ${WRKDIR}/${i} ${DESTDIR}/${DBDIR}/${i} | 
 sed -n 's/^+SHA256 (\(.*\)).*/\1/p')
   for _d in ${_D}; do
   # 2/dev/null: if file got removed manually but 
 is still in the sum file
   CURSUM=$(cd ${DESTDIR:=/}  sha256 ${_d} 
 2/dev/null)
 
 Nathanael
 

-- 
Antoine



Re: DNS control port additions to /etc/services

2014-07-15 Thread Antoine Jacoutot
On Tue, Jul 15, 2014 at 12:22:37PM +0100, Craig R. Skinner wrote:
 
 Suggestion of add NSD, Unbound  BIND control ports to /etc/services:

Makes sense to me. Anyone want to OK this?

 Index: etc/services
 ===
 RCS file: /cvs/src/etc/services,v
 retrieving revision 1.87
 diff -u -p -r1.87 services
 --- etc/services  12 Jul 2014 14:51:07 -  1.87
 +++ etc/services  15 Jul 2014 11:17:31 -
 @@ -181,6 +181,8 @@ kerberos-adm  749/tcp # 
 Kerberos 5 kad
  kerberos-adm 749/udp # Kerberos 5 kadmin
  rsync873/tcp # rsync server
  cddb 888/tcp cddbp   # Audio CD Database
 +named-rndc   953/tcp # Domain Name System (DNS) BIND 
 RNDC Service
 +named-rndc   953/udp # Domain Name System (DNS) BIND 
 RNDC Service
  imaps993/tcp # imap4 protocol over 
 TLS/SSL
  imaps993/udp # imap4 protocol over 
 TLS/SSL
  pop3s995/tcp spop3   # pop3 protocol over 
 TLS/SSL
 @@ -301,6 +303,8 @@ spamd 8025/tcp# 
 spamd(8)
  spamd-sync   8025/udp# spamd(8) synchronisation
  spamd-cfg8026/tcp# spamd(8) configuration
  dhcpd-sync   8067/udp# dhcpd(8) synchronisation
 +nsd-cntl 8952/tcp# NSD authoritative DNS server 
 control
 +unbound-cntl 8953/tcp# Unbound validating, 
 recursive, and caching DNS server control
  hunt 26740/udp   # hunt(6)
  #
  # Appletalk
 

-- 
Antoine



Re: DNS control port additions to /etc/services

2014-07-15 Thread Antoine Jacoutot
On Tue, Jul 15, 2014 at 10:06:10AM -0400, Simon Perreault wrote:
 Le 2014-07-15 09:51, Antoine Jacoutot a écrit :
 +unbound-cntl   8953/tcp# Unbound validating, 
 recursive, and caching DNS server control
 
 The IANA name for this port is ub-dns-control.
 
 http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8953
 
 Does that matter at all?

We shoud use the iana assigned name. If unbound-cntl is really needed, we can 
add it as an alias.

-- 
Antoine



Re: DNS control port additions to /etc/services

2014-07-15 Thread Antoine Jacoutot
 I'll discuss tweaks to the diff below but I'm in two minds about whether
 we want it. We don't enable the control socket in unbound by default at
 present (there is a diff somewhere to move this to unix domain sockets
 which we'd much prefer over network sockets..) Be aware, there is a
 downside to adding entries to /etc/services on OpenBSD. It isn't just a
 handy list of ports, it is used to populate net.inet.tcp.baddynamic and
 net.inet.udp.baddynamic which are used to block off ports from dynamic
 port allocation.

Absolutely!

   +named-rndc   953/tcp # Domain Name System 
   (DNS) BIND RNDC Service
   +named-rndc   953/udp # Domain Name System 
   (DNS) BIND RNDC Service
 
 BIND uses TCP for the control socket, so if this does go in, please
 do not list the UDP one.

Well it depends what policy we want. Looking at the file most entries have both 
even if only one protocol is effectively in use.

  
 12345678901234567890123456789012345678901234567890123456789012345678901234567890
imaps993/tcp # imap4 protocol over 
   TLS/SSL
imaps993/udp # imap4 protocol over 
   TLS/SSL
pop3s995/tcp spop3   # pop3 protocol over 
   TLS/SSL
   @@ -301,6 +303,8 @@ spamd 8025/tcp# 
   spamd(8)
spamd-sync   8025/udp# spamd(8) 
   synchronisation
spamd-cfg8026/tcp# spamd(8) configuration
dhcpd-sync   8067/udp# dhcpd(8) 
   synchronisation
   +nsd-cntl 8952/tcp# NSD authoritative DNS server 
   control
   +unbound-cntl 8953/tcp# Unbound validating, 
   recursive, and caching DNS server control
hunt 26740/udp   # hunt(6)
 
 +1 on sperreault's comment to use iana names. And let's try not
 to go over 80 columns unnecessarily please.
 

-- 
Antoine



Re: DNS control port additions to /etc/services

2014-07-15 Thread Antoine Jacoutot
  Well it depends what policy we want. Looking at the file most entries have 
  both even if only one protocol is effectively in use.
 
 Looking at the file though, most of those are older entries - I think

Yes. The reason is this:

# Note that it is presently the policy of IANA to assign a single well-known
# port number for both TCP and UDP; hence, most entries here have two entries
# even if the protocol doesn't support UDP operations.


 new entries should be specific, and where we have knowledge of the
 protocols we should remove silly old ones. BGP, Gopher, HTTP, POP,
 and IMAP over UDP look like good candidates for example..

I am all in favor of cleaning this file and removing useless entries.
But be careful, this is not a user-editable file anymore, so we need to take 
into account that some stuffs that may not appear obvious to us may still be 
needed by people.

-- 
Antoine



Re: DNS control port additions to /etc/services

2014-07-15 Thread Antoine Jacoutot
On Tue, Jul 15, 2014 at 04:35:58PM +0100, Stuart Henderson wrote:
 On 2014/07/15 17:17, Antoine Jacoutot wrote:
Well it depends what policy we want. Looking at the file most entries 
have both even if only one protocol is effectively in use.
   
   Looking at the file though, most of those are older entries - I think
  
  Yes. The reason is this:
  
  # Note that it is presently the policy of IANA to assign a single well-known
  # port number for both TCP and UDP; hence, most entries here have two 
  entries
  # even if the protocol doesn't support UDP operations.
  
  
   new entries should be specific, and where we have knowledge of the
   protocols we should remove silly old ones. BGP, Gopher, HTTP, POP,
   and IMAP over UDP look like good candidates for example..
  
  I am all in favor of cleaning this file and removing useless entries.
  But be careful, this is not a user-editable file anymore,
 
 It isn't? Oh dear...

No. That is why we can relax the rules a *little*.

-- 
Antoine



  1   2   >