Re: Improve error message in rcctl(8) again

2023-07-13 Thread Antoine Jacoutot
On Mon, Jul 10, 2023 at 04:46:28PM -0400, Anthony Coulter wrote:
> Seven years ago I tried to restart a configuration file and it didn't
> work out: https://marc.info/?l=openbsd-tech&m=147318006722787&w=2
> 
> This morning I tried to disable a different configuration file and got
> similar results. Maybe my hands get too used to typing ".conf" when I
> am fiddling with config files and restarting services. Or maybe I have
> the mind of a LISP programmer, to whom code and data are the same
> thing. But if I have not stopped passing config files to rcctl after
> seven years I will probably never stop, so we should fix the error
> message again.
> 
> Test cases:
> 
> # rcctl disable foo.bar
> # rcctl set foo.bar status off
> 
> Compare the error messages before and after the patch.
> 
> 
> diff --git usr.sbin/rcctl/rcctl.sh usr.sbin/rcctl/rcctl.sh
> index fb87943ba00..489c0217c45 100644
> --- usr.sbin/rcctl/rcctl.sh
> +++ usr.sbin/rcctl/rcctl.sh
> @@ -541,6 +541,12 @@ case ${action} in
>   svc_is_avail ${svc} || \
>   rcctl_err "service ${svc} does not 
> exist" 2
>   done
> + else
> + # But you still have to catch invalid characters
> + for svc in ${svcs}; do
> + _rc_check_name "${svc}" || \
> + rcctl_err "service ${svc} does not 
> exist" 2
> + done
>   fi
>   ;;
>   get|getdef)
> @@ -572,6 +578,9 @@ case ${action} in
>   if [ "${action} ${var} ${args}" != "set status off" ]; then
>   svc_is_avail ${svc} || \
>   rcctl_err "service ${svc} does not exist" 2
> + else
> + _rc_check_name "${svc}" || \
> + rcctl_err "service ${svc} does not exist" 2
>   fi
>   [[ ${var} != 
> @(class|execdir|flags|logger|rtable|status|timeout|user) ]] && usage
>   svc_is_meta ${svc} && [ "${var}" != "status" ] && \
> 

Hi Anthony.

Thanks for the patch.
Slightly modified version but it should do the same.
Does this work for you?

Index: rcctl.sh
===
RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
retrieving revision 1.116
diff -u -p -r1.116 rcctl.sh
--- rcctl.sh24 Apr 2023 14:31:15 -  1.116
+++ rcctl.sh13 Jul 2023 09:58:39 -
@@ -535,13 +535,17 @@ case ${action} in
shift 1
svcs="$*"
[ -z "${svcs}" ] && usage
-   # it's ok to disable a non-existing daemon
-   if [ "${action}" != "disable" ]; then
-   for svc in ${svcs}; do
+   for svc in ${svcs}; do
+   # it's ok to disable a non-existing daemon
+   if [ "${action}" != "disable" ]; then
svc_is_avail ${svc} || \
rcctl_err "service ${svc} does not 
exist" 2
-   done
-   fi
+   # but still check for bad input
+   else
+   _rc_check_name "${svc}" || \
+   rcctl_err "service ${svc} does not 
exist" 2
+   fi  
+   done
;;
get|getdef)
svc=$2
@@ -571,6 +575,10 @@ case ${action} in
# it's ok to disable a non-existing daemon
if [ "${action} ${var} ${args}" != "set status off" ]; then
svc_is_avail ${svc} || \
+   rcctl_err "service ${svc} does not exist" 2
+   # but still check for bad input
+   else
+   _rc_check_name "${svc}" || \
rcctl_err "service ${svc} does not exist" 2
fi
[[ ${var} != 
@(class|execdir|flags|logger|rtable|status|timeout|user) ]] && usage



Re: [PATCH] [src] share/man/man8/rc.subr.8 - normalise markup

2022-10-22 Thread Antoine Jacoutot
On Wed, Oct 19, 2022 at 10:42:18PM +0100, Raf Czlonka wrote:
> On Fri, May 27, 2022 at 01:28:07PM BST, Antoine Jacoutot wrote:
> > 
> > rc.subr.8 committed, thanks.
> 
> Hi Antoine,
> 
> I only just noticed that the diff hasn't been applied/committed in
> its entirety - only the "daemon Ns _logger" -> "daemon_logger" part
> has been but the "Ar" -> "Va" hasn't, but was also part of markup
> normalisation.

Indeed.
Committed, thanks.


> Regards,
> 
> Raf
> 
> Index: share/man/man8/rc.subr.8
> ===
> RCS file: /cvs/src/share/man/man8/rc.subr.8,v
> retrieving revision 1.48
> diff -u -p -r1.48 rc.subr.8
> --- share/man/man8/rc.subr.8  2 Sep 2022 22:11:57 -   1.48
> +++ share/man/man8/rc.subr.8  19 Oct 2022 21:33:32 -
> @@ -283,7 +283,7 @@ Change to this directory before running
>  .Ic rc_exec .
>  .It Va daemon_flags
>  Arguments to call the daemon with.
> -.It Ar daemon_logger
> +.It Va daemon_logger
>  Redirect standard output and error to
>  .Xr logger 1
>  using the configured priority (e.g. "daemon.info").

-- 
Antoine



Re: /etc/rc.d/iked regression after r1.9

2022-09-03 Thread Antoine Jacoutot
On Sat, Sep 03, 2022 at 11:51:41PM +, Lucas wrote:
> Hello tech@,
> 
> commit r1.9 removed the rc_exec call in iked's rc_pre. Because of that,
> the exit code of rc_pre is that of the && list. In the case of
> sasyncd_flags=NO, this means that rc_pre fails and triggers the break
> in the while true loop in rc_cmd start case. I solved this using the
> same approach as in isakmpd rc file: hardcoding a return 0 afterwards.
> The other alternative is using an if instead of && list, idiom which I
> prefer, but haven't seen much in these files.

Good finding.
Committed, thanks.

> -Lucas
> 
> 
> diff /usr/src
> commit - a300f670c8e17f72646e4eaedfbfeb3ce01a295f
> path + /usr/src
> blob - 8cfb786e6a883c83d4d27de65fb55ce894632cab
> file + etc/rc.d/iked
> --- etc/rc.d/iked
> +++ etc/rc.d/iked
> @@ -15,6 +15,7 @@ rc_configtest() {
>  rc_pre() {
>   [[ ${sasyncd_flags} != NO ]] &&
>   daemon_flags="-S ${daemon_flags}"
> + return 0
>  }
>  
>  rc_cmd $1
> 

-- 
Antoine



Re: [PATCH] [src] share/man/man8/rc.{d,subr}.8 - normalise markup

2022-05-27 Thread Antoine Jacoutot
On Fri, May 27, 2022 at 12:34:16PM +0100, Raf Czlonka wrote:
> On Fri, May 27, 2022 at 12:06:53PM BST, Stuart Henderson wrote:
> > On 2022/05/27 11:43, Raf Czlonka wrote:
> > > Hello,
> > > 
> > > daemon_logger was the odd one out in rc.subr(8).
> > 
> > I think that is correct.
> > 
> > > While there, I did the same in rc.d(8).
> > 
> > But that isn't, it is talking about _execdir,
> > _flags, etc where you need to replace the 
> 
> D'oh! Of course it is! Got carried away there :^P
> 
> Retracting rc.d(8) part.

rc.subr.8 committed, thanks.

-- 
Antoine



Re: rc.subr: implement rc_execdir

2022-05-22 Thread Antoine Jacoutot
Here's new diff that implements daemon_execdir.

Index: etc/rc.d/rc.subr
===
RCS file: /cvs/src/etc/rc.d/rc.subr,v
retrieving revision 1.153
diff -u -p -r1.153 rc.subr
--- etc/rc.d/rc.subr21 May 2022 10:50:09 -  1.153
+++ etc/rc.d/rc.subr22 May 2022 08:10:04 -
@@ -49,7 +49,7 @@ _rc_parse_conf() {
while IFS=' ' read -r _l; do
[[ $_l == [!#=]*=* ]] || continue
_key=${_l%%*([[:blank:]])=*}
-   [[ $_key == *_@(flags|logger|rtable|timeout|user) ]] ||
+   [[ $_key == 
*_@(execdir|flags|logger|rtable|timeout|user) ]] ||
[[ " ${_allowed_keys[*]} " == *" $_key "* ]] ||
continue
[[ $_key == "" ]] && continue
@@ -114,14 +114,17 @@ _rc_write_runfile() {
[ -d ${_RC_RUNDIR} ] || mkdir -p ${_RC_RUNDIR} &&
cat >${_RC_RUNFILE} <&1 
|
-   logger -ip ${daemon_logger} -t ${_name}}"
+   ${_rcexec} "${daemon_logger:+set -o pipefail; } \
+   ${daemon_execdir:+cd ${daemon_execdir} && } \
+   $@ \
+   ${daemon_logger:+ 2>&1 |
+   logger -ip ${daemon_logger} -t ${_name}}"
 }
 
 rc_start() {
@@ -317,6 +323,7 @@ _rc_do _rc_parse_conf
 rc_reload_signal=${rc_reload_signal:=HUP}
 rc_stop_signal=${rc_stop_signal:=TERM}
 
+eval _rcexecdir=\${${_name}_execdir}
 eval _rcflags=\${${_name}_flags}
 eval _rclogger=\${${_name}_logger}
 eval _rcrtable=\${${_name}_rtable}
@@ -334,6 +341,7 @@ getcap -f /etc/login.conf.d/${_name}:/et
 [ -n "${_RC_FORCE}" -o "$1" != "start" ] && [ X"${_rcflags}" = X"NO" ] &&
unset _rcflags
 
+[ -n "${_rcexecdir}" ] && daemon_execdir=${_rcexecdir}
 [ -n "${_rcflags}" ] && daemon_flags=${_rcflags}
 [ -n "${_rclogger}" ] && daemon_logger=${_rclogger}
 [ -n "${_rcrtable}" ] && daemon_rtable=${_rcrtable}
@@ -347,7 +355,7 @@ if [ -n "${_RC_DEBUG}" ]; then
 fi
 
 readonly daemon_class
-unset _rcflags _rclogger _rcrtable _rctimeout _rcuser
+unset _rcexecdir _rcflags _rclogger _rcrtable _rctimeout _rcuser
 # the shell will strip the quotes from daemon_flags when starting a daemon;
 # make sure pexp matches the process (i.e. doesn't include the quotes)
 pexp="$(eval echo ${daemon}${daemon_flags:+ ${daemon_flags}})"
Index: usr.sbin/rcctl/rcctl.8
===
RCS file: /cvs/src/usr.sbin/rcctl/rcctl.8,v
retrieving revision 1.39
diff -u -p -r1.39 rcctl.8
--- usr.sbin/rcctl/rcctl.8  1 Apr 2022 10:13:35 -   1.39
+++ usr.sbin/rcctl/rcctl.8  22 May 2022 08:10:04 -
@@ -62,6 +62,7 @@ The following commands are available
 .Ar variable
 can be one of
 .Cm class ,
+.Cm execdir ,
 .Cm flags ,
 .Cm logger ,
 .Cm rtable ,
@@ -206,7 +207,8 @@ flags:
 # rcctl set apmd flags -A
 # rcctl get apmd
 apmd_class=daemon
-apmd_flags=-A
+apmd_execdir=
+apmd_flags=NO
 apmd_logger=
 apmd_rtable=0
 apmd_timeout=30
Index: usr.sbin/rcctl/rcctl.sh
===
RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
retrieving revision 1.112
diff -u -p -r1.112 rcctl.sh
--- usr.sbin/rcctl/rcctl.sh 10 Feb 2022 16:57:33 -  1.112
+++ usr.sbin/rcctl/rcctl.sh 22 May 2022 08:10:04 -
@@ -258,8 +258,8 @@ svc_get()
[ -n "${_svc}" ] || return
 
local _status=0 _val _var=$2
-   local daemon_class daemon_flags daemon_logger daemon_rtable
-   local daemon_timeout daemon_user
+   local daemon_class daemon_execdir daemon_flags daemon_logger
+   local daemon_rtable daemon_timeout daemon_user
 
if svc_is_special ${_svc}; then
daemon_flags="$(eval echo \${${_svc}})"
@@ -279,6 +279,12 @@ svc_get()
[ -z "${daemon_class}" ] && \
daemon_class="$(svc_getdef ${_svc} 
class)"
fi
+   if [ -z "${_var}" -o "${_var}" = "execdir" ]; then
+   [ -z "${daemon_execdir}" ] && \
+   daemon_execdir="$(eval echo 
\"\${${_svc}_execdir}\")"
+   [ -z "${daemon_execdir}" ] && \
+   daemon_execdir="$(svc_getdef ${_svc} 
execdir)"
+   fi
if [[ -z ${_var} || ${_var} == @(flags|status) ]]; then
[ -z "${daemon_flags}" ] && \
daemon_flags="$(eval echo 
\"\${${_svc}_flags}\")"
@@ -324,6 +330,7 @@ svc_get()
echo "${_svc}=${daemon_flags}"
else
echo "${_svc}_class=${daemon_class}"
+   echo "${_svc}_execdir=${daemon_execdir}"
echo "${_svc}_flags=${daemon_flags}"

Re: rc.subr: implement rc_execdir

2022-05-21 Thread Antoine Jacoutot
Can you give me real life examples please where it would be useful. 
I don’t want to add configuration knob for a couple of obscur use cases. 

Thanks. 

—
Antoine

> On 21 May 2022, at 22:26, Aaron Bieber  wrote:
> 
> 
> 
>> On Sat, May 21, 2022, at 10:56 AM, aisha wrote:
>>> On 5/21/2022 12:24 PM, Antoine Jacoutot wrote:
>>> On Sat, May 21, 2022 at 12:04:03PM -0400, A Tammy wrote:
>>>> On 5/21/2022 10:53 AM, Antoine Jacoutot wrote:
>>>>> Hi.
>>>>> 
>>>>> This diff allows to configure an directory from which we run rc.d 
>>>>> commands.
>>>>> This can be useful for daemons that must cd into a specific directory prio
>>>>> launching.
>>>>> 
>>>>> Here's an example for the automounter.
>>>>> Some rc.d scripts in ports can benefit from this as well (so we can remove
>>>>> handcrafted rc_start function and use the default).
>>>>> 
>>>>> Comments / OK?
>>>>> 
>>>>> Index: amd
>>>>> ===
>>>>> RCS file: /cvs/src/etc/rc.d/amd,v
>>>>> retrieving revision 1.9
>>>>> diff -u -p -r1.9 amd
>>>>> --- amd11 Jan 2018 21:09:26 -1.9
>>>>> +++ amd21 May 2022 14:52:07 -
>>>>> @@ -7,16 +7,13 @@ daemon="/usr/sbin/amd"
>>>>>   . /etc/rc.d/rc.subr
>>>>>   pexp="${daemon}.*"
>>>>> +rc_execdir=/etc/amd
>>>>>   rc_reload=NO
>>>>>   rc_stop=NO
>>>>>   rc_pre() {
>>>>>   [[ -e ${amd_master} ]] || return 1
>>>>>   daemon_flags="${daemon_flags} $(print -rn -- $(< ${amd_master}))"
>>>>> -}
>>>>> -
>>>>> -rc_start() {
>>>>> -${rcexec} "cd /etc/amd; ${daemon} ${daemon_flags}"
>>>>>   }
>>>>>   rc_cmd $1
>>>>> 
>>>>> 
>>>>> 
>>>>> Index: etc/rc.d/rc.subr
>>>>> ===
>>>>> RCS file: /cvs/src/etc/rc.d/rc.subr,v
>>>>> retrieving revision 1.153
>>>>> diff -u -p -r1.153 rc.subr
>>>>> --- etc/rc.d/rc.subr21 May 2022 10:50:09 -1.153
>>>>> +++ etc/rc.d/rc.subr21 May 2022 14:49:17 -
>>>>> @@ -164,8 +164,11 @@ rc_exec() {
>>>>>   [ "${daemon_rtable}" -eq "$(id -R)" ] ||
>>>>>   _rcexec="route -T ${daemon_rtable} exec ${_rcexec}"
>>>>> -${_rcexec} "${daemon_logger:+set -o pipefail; }$@${daemon_logger:+ 
>>>>> 2>&1 |
>>>>> -logger -ip ${daemon_logger} -t ${_name}}"
>>>>> +${_rcexec} "${daemon_logger:+set -o pipefail; } \
>>>>> +${rc_execdir:+cd ${rc_execdir} && } \
>>>>> +$@ \
>>>>> +${daemon_logger:+ 2>&1 |
>>>>> +logger -ip ${daemon_logger} -t ${_name}}"
>>>>>   }
>>>>>   rc_start() {
>>>>> Index: share/man/man8/rc.subr.8
>>>>> ===
>>>>> RCS file: /cvs/src/share/man/man8/rc.subr.8,v
>>>>> retrieving revision 1.43
>>>>> diff -u -p -r1.43 rc.subr.8
>>>>> --- share/man/man8/rc.subr.821 May 2022 14:11:39 -1.43
>>>>> +++ share/man/man8/rc.subr.821 May 2022 14:49:17 -
>>>>> @@ -194,9 +194,10 @@ Execute process using
>>>>>   according to
>>>>>   .Va daemon_class ,
>>>>>   .Va daemon_user ,
>>>>> -.Va daemon_rtable
>>>>> -and
>>>>> +.Va daemon_rtable ,
>>>>>   .Va daemon_logger
>>>>> +and
>>>>> +.Va rc_execdir
>>>> Is there a reason why you've chosen it to be rc_execdir instead of
>>>> daemon_execdir?
>>>> Calling it `daemon_execdir` (and possibly allowing it to be modified from
>>>> /etc/rc.conf.local)
>>>> would be inline with other daemon_* variables.
>>>> The first thing that comes to my mind would be people who want to start
>>>> multiple copies of
>>>> a daemon, e.g. navidrome or calibre-web, create libraries in the start
>>>> directory.
>>>> I personally don't have anything except calibre-web, so no strong opinions
>>>> on this.
>>> I wondered the same but came to the conclusion there where not that many use
>>> cases and implementing rc_ is easier.
>>> Going for daemon_ will mean changing rcctl as well.
>>> 
>>> I have no strong preference honestly.
>>> If people think it will be handy to change this in rc.conf.local, I will
>>> change the implementation.
>> In that case, my vote is for it to be called daemon_execdir :)
> 
> Mine too! :D
> 
>>>> Also, if it is decided to keep it rc_execdir, does it need to be added to
>>>> the man page?
>>>> It is not something thats going to be exposed user side.
>>> Yes it is needed.
>>> It is exposed to people creating rc.d scripts; which is exactly what
>>> rc.subr(8) is for.
>>> Users will read rc.d(8).
>>> Also that kind of contradicts your point for using daemon_
>>> 
>>> 
>>>>>   values.
>>>>>   .It Ic rc_reload
>>>>>   Send the
>>>>> @@ -305,6 +306,9 @@ in an
>>>>>   .Nm rc.d
>>>>>   script to force starting the daemon in background when using the default
>>>>>   .Ic rc_start .
>>>>> +.It Va rc_execdir
>>>>> +Change to this directory before running
>>>>> +.Ic rc_exec .
>>>>>   .It Va rc_reload
>>>>>   Can be set to
>>>>>   .Dq NO
>>>>> 
>>>>> 
> 



Re: rc.subr: implement rc_execdir

2022-05-21 Thread Antoine Jacoutot
On Sat, May 21, 2022 at 12:04:03PM -0400, A Tammy wrote:
> 
> On 5/21/2022 10:53 AM, Antoine Jacoutot wrote:
> > Hi.
> > 
> > This diff allows to configure an directory from which we run rc.d commands.
> > This can be useful for daemons that must cd into a specific directory prio
> > launching.
> > 
> > Here's an example for the automounter.
> > Some rc.d scripts in ports can benefit from this as well (so we can remove
> > handcrafted rc_start function and use the default).
> > 
> > Comments / OK?
> > 
> > Index: amd
> > ===
> > RCS file: /cvs/src/etc/rc.d/amd,v
> > retrieving revision 1.9
> > diff -u -p -r1.9 amd
> > --- amd 11 Jan 2018 21:09:26 -  1.9
> > +++ amd 21 May 2022 14:52:07 -
> > @@ -7,16 +7,13 @@ daemon="/usr/sbin/amd"
> >   . /etc/rc.d/rc.subr
> >   pexp="${daemon}.*"
> > +rc_execdir=/etc/amd
> >   rc_reload=NO
> >   rc_stop=NO
> >   rc_pre() {
> > [[ -e ${amd_master} ]] || return 1
> > daemon_flags="${daemon_flags} $(print -rn -- $(< ${amd_master}))"
> > -}
> > -
> > -rc_start() {
> > -   ${rcexec} "cd /etc/amd; ${daemon} ${daemon_flags}"
> >   }
> >   rc_cmd $1
> > 
> > 
> > 
> > Index: etc/rc.d/rc.subr
> > ===
> > RCS file: /cvs/src/etc/rc.d/rc.subr,v
> > retrieving revision 1.153
> > diff -u -p -r1.153 rc.subr
> > --- etc/rc.d/rc.subr21 May 2022 10:50:09 -  1.153
> > +++ etc/rc.d/rc.subr21 May 2022 14:49:17 -
> > @@ -164,8 +164,11 @@ rc_exec() {
> > [ "${daemon_rtable}" -eq "$(id -R)" ] ||
> > _rcexec="route -T ${daemon_rtable} exec ${_rcexec}"
> > -   ${_rcexec} "${daemon_logger:+set -o pipefail; }$@${daemon_logger:+ 2>&1 
> > |
> > -   logger -ip ${daemon_logger} -t ${_name}}"
> > +   ${_rcexec} "${daemon_logger:+set -o pipefail; } \
> > +   ${rc_execdir:+cd ${rc_execdir} && } \
> > +   $@ \
> > +   ${daemon_logger:+ 2>&1 |
> > +   logger -ip ${daemon_logger} -t ${_name}}"
> >   }
> >   rc_start() {
> > Index: share/man/man8/rc.subr.8
> > ===
> > RCS file: /cvs/src/share/man/man8/rc.subr.8,v
> > retrieving revision 1.43
> > diff -u -p -r1.43 rc.subr.8
> > --- share/man/man8/rc.subr.821 May 2022 14:11:39 -  1.43
> > +++ share/man/man8/rc.subr.821 May 2022 14:49:17 -
> > @@ -194,9 +194,10 @@ Execute process using
> >   according to
> >   .Va daemon_class ,
> >   .Va daemon_user ,
> > -.Va daemon_rtable
> > -and
> > +.Va daemon_rtable ,
> >   .Va daemon_logger
> > +and
> > +.Va rc_execdir
> 
> Is there a reason why you've chosen it to be rc_execdir instead of
> daemon_execdir?
> Calling it `daemon_execdir` (and possibly allowing it to be modified from
> /etc/rc.conf.local)
> would be inline with other daemon_* variables.
> The first thing that comes to my mind would be people who want to start
> multiple copies of
> a daemon, e.g. navidrome or calibre-web, create libraries in the start
> directory.
> I personally don't have anything except calibre-web, so no strong opinions
> on this.

I wondered the same but came to the conclusion there where not that many use
cases and implementing rc_ is easier.
Going for daemon_ will mean changing rcctl as well.

I have no strong preference honestly.
If people think it will be handy to change this in rc.conf.local, I will
change the implementation.

> Also, if it is decided to keep it rc_execdir, does it need to be added to
> the man page?
> It is not something thats going to be exposed user side.

Yes it is needed.
It is exposed to people creating rc.d scripts; which is exactly what
rc.subr(8) is for.
Users will read rc.d(8).
Also that kind of contradicts your point for using daemon_


> >   values.
> >   .It Ic rc_reload
> >   Send the
> > @@ -305,6 +306,9 @@ in an
> >   .Nm rc.d
> >   script to force starting the daemon in background when using the default
> >   .Ic rc_start .
> > +.It Va rc_execdir
> > +Change to this directory before running
> > +.Ic rc_exec .
> >   .It Va rc_reload
> >   Can be set to
> >   .Dq NO
> > 
> > 

-- 
Antoine



rc.subr: implement rc_execdir

2022-05-21 Thread Antoine Jacoutot
Hi.

This diff allows to configure an directory from which we run rc.d commands.
This can be useful for daemons that must cd into a specific directory prio
launching.

Here's an example for the automounter.
Some rc.d scripts in ports can benefit from this as well (so we can remove
handcrafted rc_start function and use the default).

Comments / OK?

Index: amd
===
RCS file: /cvs/src/etc/rc.d/amd,v
retrieving revision 1.9
diff -u -p -r1.9 amd
--- amd 11 Jan 2018 21:09:26 -  1.9
+++ amd 21 May 2022 14:52:07 -
@@ -7,16 +7,13 @@ daemon="/usr/sbin/amd"
 . /etc/rc.d/rc.subr
 
 pexp="${daemon}.*"
+rc_execdir=/etc/amd
 rc_reload=NO
 rc_stop=NO
 
 rc_pre() {
[[ -e ${amd_master} ]] || return 1
daemon_flags="${daemon_flags} $(print -rn -- $(< ${amd_master}))"
-}
-
-rc_start() {
-   ${rcexec} "cd /etc/amd; ${daemon} ${daemon_flags}"
 }
 
 rc_cmd $1



Index: etc/rc.d/rc.subr
===
RCS file: /cvs/src/etc/rc.d/rc.subr,v
retrieving revision 1.153
diff -u -p -r1.153 rc.subr
--- etc/rc.d/rc.subr21 May 2022 10:50:09 -  1.153
+++ etc/rc.d/rc.subr21 May 2022 14:49:17 -
@@ -164,8 +164,11 @@ rc_exec() {
[ "${daemon_rtable}" -eq "$(id -R)" ] ||
_rcexec="route -T ${daemon_rtable} exec ${_rcexec}"
 
-   ${_rcexec} "${daemon_logger:+set -o pipefail; }$@${daemon_logger:+ 2>&1 
|
-   logger -ip ${daemon_logger} -t ${_name}}"
+   ${_rcexec} "${daemon_logger:+set -o pipefail; } \
+   ${rc_execdir:+cd ${rc_execdir} && } \
+   $@ \
+   ${daemon_logger:+ 2>&1 |
+   logger -ip ${daemon_logger} -t ${_name}}"
 }
 
 rc_start() {
Index: share/man/man8/rc.subr.8
===
RCS file: /cvs/src/share/man/man8/rc.subr.8,v
retrieving revision 1.43
diff -u -p -r1.43 rc.subr.8
--- share/man/man8/rc.subr.821 May 2022 14:11:39 -  1.43
+++ share/man/man8/rc.subr.821 May 2022 14:49:17 -
@@ -194,9 +194,10 @@ Execute process using
 according to
 .Va daemon_class ,
 .Va daemon_user ,
-.Va daemon_rtable
-and
+.Va daemon_rtable ,
 .Va daemon_logger
+and
+.Va rc_execdir
 values.
 .It Ic rc_reload
 Send the
@@ -305,6 +306,9 @@ in an
 .Nm rc.d
 script to force starting the daemon in background when using the default
 .Ic rc_start .
+.It Va rc_execdir
+Change to this directory before running
+.Ic rc_exec .
 .It Va rc_reload
 Can be set to
 .Dq NO


-- 
Antoine



Re: turn rc_exec variable into an rcexec function

2022-05-20 Thread Antoine Jacoutot
On Tue, May 17, 2022 at 09:12:08AM +0200, Antoine Jacoutot wrote:
> Hi folks.
> 
> I would like to move away from the rc_exec variable to an rcexec() function 
> for
> rc.d scripts.
> That will allow daemon_logger to work out of the box even for manually
> crafted rc_start() functions.
> I will also simplify the addition of new features like daemon_startdir.
> 
> I have tested this with a few daemons only.
> So I am calling for testing this diff on your own setup to detect any possible
> regression (especially for daemons with a complex starting sequence).
> To test, just apply the diff to rc.subr and replace ${rcexec} with rc_exec in
> your rc.d scripts.
> 
> As I don't want to spam the list, please report OK tests directly to me and
> KO ones to the list.
> 
> Thanks a lot!

FYI I intend to commit this over the week-end.
Best way to get test reports I guess.


> Index: rc.subr
> ===
> RCS file: /cvs/src/etc/rc.d/rc.subr,v
> retrieving revision 1.152
> diff -u -p -r1.152 rc.subr
> --- rc.subr   10 Feb 2022 16:57:33 -  1.152
> +++ rc.subr   17 May 2022 07:05:57 -
> @@ -159,11 +159,19 @@ _rc_wait_for_start() {
>   return
>  }
>  
> -rc_start() {
> - ${rcexec} "${daemon_logger:+set -o pipefail; }${daemon} 
> ${daemon_flags}${daemon_logger:+ 2>&1 |
> +rc_exec() {
> + local _rcexec="su -fl -c ${daemon_class} -s /bin/sh ${daemon_user} -c"
> + [ "${daemon_rtable}" -eq "$(id -R)" ] ||
> + _rcexec="route -T ${daemon_rtable} exec ${_rcexec}"
> +
> + ${_rcexec} "${daemon_logger:+set -o pipefail; }$@${daemon_logger:+ 2>&1 
> |
>   logger -ip ${daemon_logger} -t ${_name}}"
>  }
>  
> +rc_start() {
> + rc_exec "${daemon} ${daemon_flags}"
> +}
> +
>  rc_check() {
>   pgrep -T "${daemon_rtable}" -q -xf "${pexp}"
>  }
> @@ -343,6 +351,3 @@ unset _rcflags _rclogger _rcrtable _rcti
>  # the shell will strip the quotes from daemon_flags when starting a daemon;
>  # make sure pexp matches the process (i.e. doesn't include the quotes)
>  pexp="$(eval echo ${daemon}${daemon_flags:+ ${daemon_flags}})"
> -rcexec="su -fl -c ${daemon_class} -s /bin/sh ${daemon_user} -c"
> -[ "${daemon_rtable}" -eq "$(id -R)" ] ||
> - rcexec="route -T ${daemon_rtable} exec ${rcexec}"
> 
> 
> -- 
> Antoine
> 

-- 
Antoine



turn rc_exec variable into an rcexec function

2022-05-17 Thread Antoine Jacoutot
Hi folks.

I would like to move away from the rc_exec variable to an rcexec() function for
rc.d scripts.
That will allow daemon_logger to work out of the box even for manually
crafted rc_start() functions.
I will also simplify the addition of new features like daemon_startdir.

I have tested this with a few daemons only.
So I am calling for testing this diff on your own setup to detect any possible
regression (especially for daemons with a complex starting sequence).
To test, just apply the diff to rc.subr and replace ${rcexec} with rc_exec in
your rc.d scripts.

As I don't want to spam the list, please report OK tests directly to me and
KO ones to the list.

Thanks a lot!


Index: rc.subr
===
RCS file: /cvs/src/etc/rc.d/rc.subr,v
retrieving revision 1.152
diff -u -p -r1.152 rc.subr
--- rc.subr 10 Feb 2022 16:57:33 -  1.152
+++ rc.subr 17 May 2022 07:05:57 -
@@ -159,11 +159,19 @@ _rc_wait_for_start() {
return
 }
 
-rc_start() {
-   ${rcexec} "${daemon_logger:+set -o pipefail; }${daemon} 
${daemon_flags}${daemon_logger:+ 2>&1 |
+rc_exec() {
+   local _rcexec="su -fl -c ${daemon_class} -s /bin/sh ${daemon_user} -c"
+   [ "${daemon_rtable}" -eq "$(id -R)" ] ||
+   _rcexec="route -T ${daemon_rtable} exec ${_rcexec}"
+
+   ${_rcexec} "${daemon_logger:+set -o pipefail; }$@${daemon_logger:+ 2>&1 
|
logger -ip ${daemon_logger} -t ${_name}}"
 }
 
+rc_start() {
+   rc_exec "${daemon} ${daemon_flags}"
+}
+
 rc_check() {
pgrep -T "${daemon_rtable}" -q -xf "${pexp}"
 }
@@ -343,6 +351,3 @@ unset _rcflags _rclogger _rcrtable _rcti
 # the shell will strip the quotes from daemon_flags when starting a daemon;
 # make sure pexp matches the process (i.e. doesn't include the quotes)
 pexp="$(eval echo ${daemon}${daemon_flags:+ ${daemon_flags}})"
-rcexec="su -fl -c ${daemon_class} -s /bin/sh ${daemon_user} -c"
-[ "${daemon_rtable}" -eq "$(id -R)" ] ||
-   rcexec="route -T ${daemon_rtable} exec ${rcexec}"


-- 
Antoine



Re: rc.subr - allow setting daemon start directory

2022-05-13 Thread Antoine Jacoutot
On Fri, May 13, 2022 at 07:06:23PM -0400, aisha wrote:
> 
> On 5/13/2022 7:03 PM, Antoine Jacoutot wrote:
> > On Fri, May 13, 2022 at 07:01:30PM -0400, aisha wrote:
> > > On 22/05/06 08:28AM, Antoine Jacoutot wrote:
> > > > On Thu, May 05, 2022 at 04:49:10PM -0600, Aaron Bieber wrote:
> > > > > 
> > > > > On Thu, May 5, 2022, at 4:46 PM, Antoine Jacoutot wrote:
> > > > > > Can you elaborate?
> > > > > > Do they need to start from a specific directory or from a directory
> > > > > > they have write access to?
> > > > > > Because we could cd /tmp unconditionally
> > > > > > 
> > > > >  From a specific directory. I can???t think of which ones off the top 
> > > > > of my head, but for sure I have some personal rc scripts that need it 
> > > > > for nodejs things.
> > > > Ok. Let me think about it.
> > > > 
> > > > -- 
> > > > Antoine
> > > > 
> > > 
> > > ping, reattached patch.
> > That's not enough.
> > Please give me some time; there are other things I need to look at first.
> > No rush.
> 
> Got it, my apologies.

No worries, I am just super busy right now.



Re: rc.subr - allow setting daemon start directory

2022-05-05 Thread Antoine Jacoutot
On Thu, May 05, 2022 at 04:49:10PM -0600, Aaron Bieber wrote:
> 
> 
> On Thu, May 5, 2022, at 4:46 PM, Antoine Jacoutot wrote:
> > Can you elaborate?
> > Do they need to start from a specific directory or from a directory 
> > they have write access to?
> > Because we could cd /tmp unconditionally 
> >
> 
> From a specific directory. I can’t think of which ones off the top of my 
> head, but for sure I have some personal rc scripts that need it for nodejs 
> things.

Ok. Let me think about it.

-- 
Antoine



Re: rc.subr - allow setting daemon start directory

2022-05-05 Thread Antoine Jacoutot
Can you elaborate?
Do they need to start from a specific directory or from a directory they have 
write access to?
Because we could cd /tmp unconditionally 

—
Antoine

> On 6 May 2022, at 00:43, Aaron Bieber  wrote:
> 
> 
> 
>> On Thu, May 5, 2022, at 3:24 PM, Antoine Jacoutot wrote:
>> Not a fan adding a knob for this. 
>> I don’t remember why amd needs to start from /etc/amd. 
>> 
>> —
>> Antoine
> 
> There are a number of ports that would benefit from this as well.
> 
>> 
>>>> On 5 May 2022, at 23:12, aisha  wrote:
>>> 
>>> Hi,
>>> I've attached a patch which allows setting the daemon start directory using 
>>> the variable `daemon_startdir`.
>>> I think this is useful in the cases where it is desirable to change the 
>>> start directory before running the daemon, e.g. with /etc/rc.d/amd .
>>> A major benefit of this is that this allows setting the start directory 
>>> manually while also allowing the use of daemon_logger, which gets lost in 
>>> case someone writes their own rc_start (again, amd is an example).
>>> 
>>> This is not always possible using the rcexec which uses `su -l` as the 
>>> daemon might be running as root (or if user has home directory to 
>>> /nonexistent).
>>> 
>>> Thanks,
>>> Aisha
>>> 
>>> diff --git a/etc/rc.d/amd b/etc/rc.d/amd
>>> index 3bfe9dc555e..5c1b8a897ed 100644
>>> --- a/etc/rc.d/amd
>>> +++ b/etc/rc.d/amd
>>> @@ -3,6 +3,7 @@
>>> # $OpenBSD: amd,v 1.9 2018/01/11 21:09:26 rpe Exp $
>>> 
>>> daemon="/usr/sbin/amd"
>>> +daemon_startdir="/etc/amd"
>>> 
>>> . /etc/rc.d/rc.subr
>>> 
>>> @@ -15,8 +16,4 @@ rc_pre() {
>>>   daemon_flags="${daemon_flags} $(print -rn -- $(< ${amd_master}))"
>>> }
>>> 
>>> -rc_start() {
>>> -${rcexec} "cd /etc/amd; ${daemon} ${daemon_flags}"
>>> -}
>>> -
>>> rc_cmd $1
>>> diff --git a/etc/rc.d/rc.subr b/etc/rc.d/rc.subr
>>> index ed2adb6515e..035f8d9b172 100644
>>> --- a/etc/rc.d/rc.subr
>>> +++ b/etc/rc.d/rc.subr
>>> @@ -117,6 +117,7 @@ daemon_class=${daemon_class}
>>> daemon_flags=${daemon_flags}
>>> daemon_logger=${daemon_logger}
>>> daemon_rtable=${daemon_rtable}
>>> +daemon_startdir=${daemon_startdir}
>>> daemon_timeout=${daemon_timeout}
>>> daemon_user=${daemon_user}
>>> pexp=${pexp}
>>> @@ -160,7 +161,7 @@ _rc_wait_for_start() {
>>> }
>>> 
>>> rc_start() {
>>> -${rcexec} "${daemon_logger:+set -o pipefail; }${daemon} 
>>> ${daemon_flags}${daemon_logger:+ 2>&1 |
>>> +${rcexec} "${daemon_logger:+set -o pipefail; }${daemon_startdir:+cd 
>>> ${daemon_startdir}; }${daemon} ${daemon_flags}${daemon_logger:+ 2>&1 |
>>>   logger -ip ${daemon_logger} -t ${_name}}"
>>> }
>>> 
>>> @@ -312,6 +313,7 @@ rc_stop_signal=${rc_stop_signal:=TERM}
>>> eval _rcflags=\${${_name}_flags}
>>> eval _rclogger=\${${_name}_logger}
>>> eval _rcrtable=\${${_name}_rtable}
>>> +eval _rcstartdir=\${${_name}_startdir}
>>> eval _rctimeout=\${${_name}_timeout}
>>> eval _rcuser=\${${_name}_user}
>>> 
>>> @@ -329,6 +331,7 @@ getcap -f /etc/login.conf.d/${_name}:/etc/login.conf 
>>> ${_name} 1>/dev/null 2>&1 &
>>> [ -n "${_rcflags}" ] && daemon_flags=${_rcflags}
>>> [ -n "${_rclogger}" ] && daemon_logger=${_rclogger}
>>> [ -n "${_rcrtable}" ] && daemon_rtable=${_rcrtable}
>>> +[ -n "${_rcstartdir}" ] && daemon_startdir=${_rcstartdir}
>>> [ -n "${_rctimeout}" ] && daemon_timeout=${_rctimeout}
>>> [ -n "${_rcuser}" ] && daemon_user=${_rcuser}
>>> 
>>> 
> 



Re: rc.subr - allow setting daemon start directory

2022-05-05 Thread Antoine Jacoutot
Not a fan adding a knob for this. 
I don’t remember why amd needs to start from /etc/amd. 

—
Antoine

> On 5 May 2022, at 23:12, aisha  wrote:
> 
> Hi,
>  I've attached a patch which allows setting the daemon start directory using 
> the variable `daemon_startdir`.
> I think this is useful in the cases where it is desirable to change the start 
> directory before running the daemon, e.g. with /etc/rc.d/amd .
> A major benefit of this is that this allows setting the start directory 
> manually while also allowing the use of daemon_logger, which gets lost in 
> case someone writes their own rc_start (again, amd is an example).
> 
> This is not always possible using the rcexec which uses `su -l` as the daemon 
> might be running as root (or if user has home directory to /nonexistent).
> 
> Thanks,
> Aisha
> 
> diff --git a/etc/rc.d/amd b/etc/rc.d/amd
> index 3bfe9dc555e..5c1b8a897ed 100644
> --- a/etc/rc.d/amd
> +++ b/etc/rc.d/amd
> @@ -3,6 +3,7 @@
> # $OpenBSD: amd,v 1.9 2018/01/11 21:09:26 rpe Exp $
> 
> daemon="/usr/sbin/amd"
> +daemon_startdir="/etc/amd"
> 
> . /etc/rc.d/rc.subr
> 
> @@ -15,8 +16,4 @@ rc_pre() {
>daemon_flags="${daemon_flags} $(print -rn -- $(< ${amd_master}))"
> }
> 
> -rc_start() {
> -${rcexec} "cd /etc/amd; ${daemon} ${daemon_flags}"
> -}
> -
> rc_cmd $1
> diff --git a/etc/rc.d/rc.subr b/etc/rc.d/rc.subr
> index ed2adb6515e..035f8d9b172 100644
> --- a/etc/rc.d/rc.subr
> +++ b/etc/rc.d/rc.subr
> @@ -117,6 +117,7 @@ daemon_class=${daemon_class}
> daemon_flags=${daemon_flags}
> daemon_logger=${daemon_logger}
> daemon_rtable=${daemon_rtable}
> +daemon_startdir=${daemon_startdir}
> daemon_timeout=${daemon_timeout}
> daemon_user=${daemon_user}
> pexp=${pexp}
> @@ -160,7 +161,7 @@ _rc_wait_for_start() {
> }
> 
> rc_start() {
> -${rcexec} "${daemon_logger:+set -o pipefail; }${daemon} 
> ${daemon_flags}${daemon_logger:+ 2>&1 |
> +${rcexec} "${daemon_logger:+set -o pipefail; }${daemon_startdir:+cd 
> ${daemon_startdir}; }${daemon} ${daemon_flags}${daemon_logger:+ 2>&1 |
>logger -ip ${daemon_logger} -t ${_name}}"
> }
> 
> @@ -312,6 +313,7 @@ rc_stop_signal=${rc_stop_signal:=TERM}
> eval _rcflags=\${${_name}_flags}
> eval _rclogger=\${${_name}_logger}
> eval _rcrtable=\${${_name}_rtable}
> +eval _rcstartdir=\${${_name}_startdir}
> eval _rctimeout=\${${_name}_timeout}
> eval _rcuser=\${${_name}_user}
> 
> @@ -329,6 +331,7 @@ getcap -f /etc/login.conf.d/${_name}:/etc/login.conf 
> ${_name} 1>/dev/null 2>&1 &
> [ -n "${_rcflags}" ] && daemon_flags=${_rcflags}
> [ -n "${_rclogger}" ] && daemon_logger=${_rclogger}
> [ -n "${_rcrtable}" ] && daemon_rtable=${_rcrtable}
> +[ -n "${_rcstartdir}" ] && daemon_startdir=${_rcstartdir}
> [ -n "${_rctimeout}" ] && daemon_timeout=${_rctimeout}
> [ -n "${_rcuser}" ] && daemon_user=${_rcuser}
> 
> 



Re: rcctl.8: Add missing variable

2022-04-01 Thread Antoine Jacoutot
On Thu, Mar 31, 2022 at 09:46:07PM -0500, Matthew Martin wrote:
> diff --git rcctl.8 rcctl.8
> index 6c3048b834c..93a76a937c1 100644
> --- rcctl.8
> +++ rcctl.8
> @@ -64,6 +64,7 @@ can be one of
>  .Cm class ,
>  .Cm flags ,
>  .Cm logger ,
> +.Cm rtable ,
>  .Cm status ,
>  .Cm timeout
>  or

Indeed, committed.
Thank you.

-- 
Antoine



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(&tmp1, fmt, ap);
>> +va_end(ap);
>> +
>> +if (*sp == NULL || **sp == '\0') {
>> +free(*sp);
>> +*sp = tmp1;
>> +return;
>> +}
>> +xasprintf(&tmp2, "%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(&ret, " ", "%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-02 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&m=155007285712913&w=2
> 
> See https://marc.info/?l=openbsd-tech&m=155637285221396&w=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, &object->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
> >> +
&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 library_aslr

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  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->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

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  
> 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 :
> > 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-08-01 Thread Antoine Jacoutot
On Sun, Jul 31, 2016 at 07:21:39PM +0200, Antoine Jacoutot wrote:
> 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

Hi Jeremie.

This seems to do the trick for me:

Index: LT/Getopt.pm
===
RCS file: /cvs/src/usr.bin/libtool/LT/Getopt.pm,v
retrieving revision 1.12
diff -u -p -r1.12 Getopt.pm
--- LT/Getopt.pm19 Mar 2014 02:16:22 -  1.12
+++ LT/Getopt.pm1 Aug 2016 10:18:03 -
@@ -292,6 +292,11 @@ MAINLOOP2:
if ($arg =~ m/^\-\-$/) {
next;   # XXX ?
}
+   # ignore "-bindir /path/to/dir" on OpenBSD (matches GNU libtool)
+   if ($arg =~ m/^\-bindir$/) {
+   shift @main::ARGV;
+   next;
+   }
if ($arg =~ m/^\-/) {
for my $opt (@options) {
if ($opt->match($arg, $self)) {



-- 
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 *interface)
> + {
> +-struct ifnet ifnet;

Re: rc.d/rebound: check for rebound.conf

2015-12-04 Thread Antoine Jacoutot
On Fri, Dec 04, 2015 at 01:41:55PM +0100, Christian Weisgerber wrote:
> Require /etc/rebound.conf to exist before starting rebound.
> 
> Otherwise, if the configuration file doesn't exist, rebound will
> error out, but only after daemonizing, so the rc system won't notice
> the failure.
> 
> ok?

I did the same for httpd but was told this is not the way we should do things 
and that the daemon should return a proper error code.

> Index: rebound
> ===
> RCS file: /cvs/src/etc/rc.d/rebound,v
> retrieving revision 1.1
> diff -u -p -r1.1 rebound
> --- rebound   30 Nov 2015 23:35:30 -  1.1
> +++ rebound   4 Dec 2015 12:37:04 -
> @@ -6,4 +6,8 @@ daemon="/usr/sbin/rebound"
>  
>  . /etc/rc.d/rc.subr
>  
> +rc_pre() {
> + [ -s /etc/rebound.conf ]
> +}
> +
>  rc_cmd $1
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 

-- 
Antoine



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: rcctl action multiple daemons

2015-09-30 Thread Antoine Jacoutot
On Wed, Sep 30, 2015 at 12:30:52PM +0200, Martijn van Duren wrote:
> ping

I am still pondering the pros and cons...

> On 09/25/15 14:44, Martijn van Duren wrote:
> >On 09/25/15 14:03, Stuart Henderson wrote:
> >>On 2015/09/25 13:17, Martijn van Duren wrote:
> >>>I don't always want all daemons running all the time on my desktop,
> >>>but when
> >>>I want to start multiple daemons (for instance when doing some webdev) I
> >>>have to call rcctl multiple times, which results in multiple password
> >>>questions and long commands (I know I could set up doas.conf with the
> >>>nopass
> >>>option, but I'd rather enter my password when starting a daemon):
> >>
> >>I like this a lot, but there's one small issue: if a service fails to
> >>stop/start (either due to a problem with the service, or due to not being
> >>enabled if you don't use -f) then it doesn't go on to start the remaining
> >>daemons.
> >>
> >
> >Here's an updated version with two extra minor regressions found and fixed:
> >- `rcctl  ` results in a usage again (regression)
> >- `rcctl get(def) ` doesn't results in a usage again (regression)
> >- `rcctl...` continues to run if a daemon
> >fails and exits with the error code of the last failed daemon.

> Index: rcctl.sh
> ===
> RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
> retrieving revision 1.79
> diff -u -p -r1.79 rcctl.sh
> --- rcctl.sh  12 Aug 2015 06:28:18 -  1.79
> +++ rcctl.sh  25 Sep 2015 12:34:44 -
> @@ -424,52 +424,76 @@ shift $((OPTIND-1))
>  [ $# -gt 0 ] || usage
>  
>  action=$1
> -if [ "${action}" = "ls" ]; then
> - lsarg=$2
> - [[ ${lsarg} == @(all|faulty|off|on|started|stopped) ]] || usage
> -elif [ "${action}" = "order" ]; then
> - shift 1
> - svcs="$*"
> -else
> - svc=$2
> - var=$3
> - [ $# -ge 3 ] && shift 3 || shift $#
> - args="$*"
> -fi
> -
> -if [ -n "${svc}" ]; then
> - [[ ${action} == 
> @(disable|enable|get|getdef|set|start|stop|restart|reload|check) ]] || \
> - usage
> - svc_is_avail ${svc} || \
> - rcctl_err "service ${svc} does not exist" 2
> -elif [[ ${action} != @(ls|order) ]] ; then
> - usage
> -fi
> -
> -if [ -n "${var}" ]; then
> - [[ ${var} != @(class|flags|status|timeout|user) ]] && usage
> - [[ ${action} == set && ${var} = flags && ${args} = NO ]] && \
> - rcctl_err "\"flags NO\" contradicts \"${action}\""
> - [[ ${action} == set && ${var} == class ]] && \
> - rcctl_err "\"${svc}_class\" is a read-only variable set in 
> login.conf(5)"
> - if svc_is_special ${svc}; then
> - if [[ ${action} == set && ${var} != status ]] || \
> - [[ ${action} == @(get|getdef) && ${var} == 
> @(class|timeout|user) ]]; then
> - rcctl_err "\"${svc}\" is a special variable, cannot 
> \"${action} ${svc} ${var}\""
> +case ${action} in
> + ls)
> + lsarg=$2
> + [[ ${lsarg} == @(all|faulty|off|on|started|stopped) ]] || usage
> + ;;
> + order)
> + shift 1
> + svcs="$*"
> + ;;
> + disable|enable|start|stop|restart|reload|check)
> + shift 1
> + svcs="$*"
> + [ -z "${svcs}" ] && usage
> + for svc in ${svcs}; do
> + svc_is_avail ${svc} || \
> + rcctl_err "service ${svc} does not exist" 2
> + done
> + ;;
> + get|getdef)
> + svc=$2
> + var=$3
> + [ -z "${svc}" ] && usage
> + svc_is_avail ${svc} || \
> + rcctl_err "service ${svc} does not exist" 2
> + if [ -n "${var}" ]; then
> + [[ ${var} != @(class|flags|status|timeout|user) ]] && 
> usage
> + if svc_is_special ${svc}; then
> + [[ ${var} == @(class|timeout|user) ]] && \
> + rcctl_err "\"${svc}\" is a special 
> variable, cannot \"${action} ${svc} ${var}\""
> + fi
>   fi
> - fi
> -elif [ ${action} = "set" ]; then
> - usage
> -fi
> + ;;
> + set)
> + svc=$2
> + var=$3
> + [ $# -ge 3 ] && shift 3 || shift $#
> + args="$*"
> + [ -z "${svc}" ] && usage
> + svc_is_avail ${svc} || \
> + rcctl_err "service ${svc} does not exist" 2
> + [[ ${var} != @(class|flags|status|timeout|user) ]] && usage
> + [[ ${var} = flags && ${args} = NO ]] && \
> + rcctl_err "\"flags NO\" contradicts \"${action}\""
> + [[ ${var} == class ]] && \
> + rcctl_err "\"${svc}_class\" is a read-only variable set 
> in login.conf(5)"
> + if svc_is_special ${svc}; then
> + [[ ${var} != status ]] && \
> +

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 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -45,6 +46,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #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':
> > 

Re: [patch] Path typo in FAQ

2015-07-12 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
>  
>  
>  Additionally, some packages provide configuration and other information
> -in a file located in /usr/local/share/docs/pkg-readmes.
> +in a file located in /usr/local/share/doc/pkg-readmes.
>  
>  
>  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 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -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:
> 
> # 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}" != X"NO" ]; 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" = X"shutdown" ]; 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



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



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



OpenBSD 5.6 Released

2014-11-01 Thread Antoine Jacoutot
hile reading).

3) Read the README file.  It is short, and a quick read will make
   sure you understand what else you need to fetch.

4) Next, go into the directory that applies to your 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,
  

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



  1   2   3   >