Re: Supervision on the BSD's

2022-04-11 Thread J. Lewis Muir 
On 04/09, Scott Colby wrote:
> Finally, if you wanted to create a router that you could (metaphorically)
> put in a closet and forget about for 5 years, what approach would
> you take? My initial thought was OpenBSD + s6, but I worry now that
> there could be an impedance mismatch between these systems.
> 
> Any thoughts people have on this will be greatly appreciated.

Hi, Scott!

Re putting it in a closet and forgetting about it for five years, one
thing to note is that according to

  https://www.openbsd.org/errata70.html

OpenBSD's stable branch is supported for one year, so if you were
tracking that, you'd have to upgrade every year.

NetBSD's stable branch is supported for longer than one year based on

  https://www.netbsd.org/releases/formal.html#history

but they don't say exactly how long.  The trend to me looks like
at least three years.  They currently support their 8 and 9 stable
branches which were released on July 17, 2018, and February 14, 2020,
respectively.

FreeBSD's stable branch is supported for five years according to

  https://www.freebsd.org/security/#sup

And of course there are other BSDs that I haven't listed.

Regards,

Lewis

Re: [request for review] Port of s6 documentation to mdoc(7)

2020-08-31 Thread J. Lewis Muir 
On 08/31, Laurent Bercot wrote:
> 
> > Of course, you'd also have to convert the existing HTML documentation
> > into DocBook and then generate the mdoc and HTML from that.  I would
> > understand concern over adding a dependency on a potentially heavy
> > DocBook toolchain in order to generate the HTML.  One possible way
> > around this, though, would be to generate the mdoc from the DocBook
> > using docbook2mdoc, and then generate the HTML from the mdoc using
> > mandoc.
> 
>  Are you volunteering to do that work?

No, unfortunately, I don't have the time.  I was just suggesting the
idea to you and Alexis in case either one of you had not considered it.

Lewis

Re: [request for review] Port of s6 documentation to mdoc(7)

2020-08-31 Thread J. Lewis Muir 
On 08/31, Jason Lenz wrote:
> On 8/31/20 11:08 AM, J. Lewis Muir wrote:
> > On 08/30, Laurent Bercot wrote:
> > > > i've spent the last couple of weeks porting the s6 documentation to 
> > > > mdoc(7) format:
> > > > 
> > > > https://github.com/flexibeast/s6-man-pages
> > >   Excellent, thank you. There is a lot of talk (especially on the #s6
> > > IRC channel, but occasionally on the mailing-list too) about people
> > > wanting to have s6 man pages, but very rarely people wanting to actually
> > > do the *work*. This is clearly the most advanced conversion ever
> > > performed, well done!
> > > 
> > I don't want to rain on anyone's parade, and I certainly would like to
> > see s6 man pages, but it seems like such a waste of effort to maintain
> > two sets of documentation.  Laurent, isn't there a source format that
> > you'd be OK with that could be used to generate mdoc?
> > 
> > Have you considered docbook2mdoc?
> > 
> >https://mandoc.bsd.lv/docbook2mdoc/
> 
> I'm just happy someone is creating manual pages, so I'm not going to "look a
> gift horse in the mouth". ;-)

Yes, and I certainly didn't intend to do that if you're suggesting that
I have, and that's what I was trying to communicate when I said

> > I don't want to rain on anyone's parade, and I certainly would like to
> > see s6 man pages

but at the same time, I thought I'd make one last plea, if you will,
before too much time is invested since, like I said, it felt like such
a waste.  I mean, if there were a source format that everyone could be
happy with, then Alexis could spend time on getting that working instead
of spending time on something that will require indefinite maintenance.
But if there is no such solution, and having two separately maintained
sets of documentation is the only way to get man pages, then yes, I
still would be very thankful for Alexis's work.

> With that said I believe Laurent mentioned in the past that he considered a
> suggestion from someone to use the scdoc utility (links below), as long as
> someone else did the initial work to port to that format?  It's a simplified
> markup format, so although much easier to read probably not as powerful as
> mdoc.
> 
> https://drewdevault.com/2018/05/13/scdoc.html
> 
> https://git.sr.ht/~sircmpwn/scdoc

I had forgotten about that; thanks for the reminder.  I don't have any
experience with scdoc either, but if Laurent is happy with it and it
could serve as the source documentation format from which HTML and man
pages could be generated, then it seems like a win to me.

Lewis

Re: [request for review] Port of s6 documentation to mdoc(7)

2020-08-31 Thread J. Lewis Muir 
On 08/30, Laurent Bercot wrote:
> > i've spent the last couple of weeks porting the s6 documentation to mdoc(7) 
> > format:
> > 
> > https://github.com/flexibeast/s6-man-pages
> 
>  Excellent, thank you. There is a lot of talk (especially on the #s6
> IRC channel, but occasionally on the mailing-list too) about people
> wanting to have s6 man pages, but very rarely people wanting to actually
> do the *work*. This is clearly the most advanced conversion ever
> performed, well done!
> 
>  Would you be willing to add a small Makefile that by default invokes
> the mandoc commands to produce the formatted man pages, and with an
> install target that installs the source to $(MANDIR), by default
> /usr/share/man ? I would then be able to review them. Thanks :)
> (AS you're aware if you've been here a while, I don't read mdoc source,
> and I will. not. learn. it.)
> 
>  Related question: would you be willing to maintain that repository
> for when I make changes to the s6 documentation? Changes should be few
> and far between, except for fixes and new feature additions (which I
> don't think there will be much of). If so, I would gladly add a link to
> that repository in the official s6 home page, for people who, like you,
> prefer man pages.

I don't want to rain on anyone's parade, and I certainly would like to
see s6 man pages, but it seems like such a waste of effort to maintain
two sets of documentation.  Laurent, isn't there a source format that
you'd be OK with that could be used to generate mdoc?

Have you considered docbook2mdoc?

  https://mandoc.bsd.lv/docbook2mdoc/

(I haven't used it myself; I'm just aware of its existence.)  I think
the existing s6 documentation is HTML, right?  So, DocBook is not too
far from that, and docbook2mdoc is a stand-alone ISO C utility with no
external dependencies that, barring any significant missing features,
would be able to generate the man pages from DocBook source.

Of course, you'd also have to convert the existing HTML documentation
into DocBook and then generate the mdoc and HTML from that.  I would
understand concern over adding a dependency on a potentially heavy
DocBook toolchain in order to generate the HTML.  One possible way
around this, though, would be to generate the mdoc from the DocBook
using docbook2mdoc, and then generate the HTML from the mdoc using
mandoc.  With this scheme, there would be no dependency on a heavy
DocBook toolchain.

I know the documentation has come up on the list before, so I don't want
to rehash that.  If I'm saying nothing new, then no need to discuss
further.

Lewis

Re: runit patches to fix compiler warnings on RHEL 7

2019-12-04 Thread J. Lewis Muir 
On 12/04, Laurent Bercot wrote:
> > What about mandoc?
> 
> The colour of this bikeshed is not up for debate.
> 
> If you want man pages for skaware, provide me with:
> 1. a reasonable source format (e.g. not roff, so mandoc is right out)
> 2. a tool that can be built using *only* a C compiler (so as to keep
> bootstrapping skaware easy), that converts the source format into man
> pages *and* into HTML
> 3. the actual contents of the man pages you want, in that source format.
> 
> (https://git.sr.ht/~sircmpwn/scdoc fits 1. and 2., but its author wasn't
> motivated enough to do 3.)
 
Interesting, I hadn't heard of scdoc before.  I don't see where it says
it can convert the source format into HTML, though.  Did I miss that?

> Until then, any further discussion of documentation formats is pure
> noise, I've heard it all before - several times - and it has the potential
> to piss me off VERY quickly.

Certainly don't want to cause trouble, and not intending to bikeshed,
but I searched for "halibut" in the archive for this list as well as the
skaware list and did not find that it had been mentioned, so I'll just
mention that another system I've used in the past is Halibut which is
lightweight and written in ANSI C:

  https://www.chiark.greenend.org.uk/~sgtatham/halibut/

It can generate ASCII, HTML, PDF, PostScript, man, and info.  So, I
think it would satisfy #1 and #2, but certainly not #3.  Still, if
someone wanted to do the work to provide #3 at some point, then Halibut
may be a reasonable tool to consider.

Lewis

Re: runit patches to fix compiler warnings on RHEL 7

2019-12-04 Thread J. Lewis Muir 
On 12/04, Jonathan de Boyne Pollard wrote:
> Jan Braun:
> 
> > 2) runit has manpages. s6 has HTML. :(
> > 
> Daniel J. Bernstein had something to say on that subject, two decades ago.
> See the "Notes" section of http://cr.yp.to/slashdoc.html .
> 
> I generate both manual pages and HTML from a common DocBook XML master in
> the nosh toolset.  And the DocBook XML is itself readable directly with a
> WWW browser.
> http://jdebp.uk./Softwares/nosh/guide/commands/setuidgid-fromenv.xml is a
> copy of one such DocBook XML master, for example.  It's on the WWW, and the
> packages also install it locally, for off-line reading.

I still like having man pages.  It's often just easier to type "man
" than to find the local (or remote) HTML document and open it in
a web browser.

However, I agree that it's very nice to have HTML as well.  So, I like
to have both!  It seems good to generate them from a single source
format.  I would like DocBook except that the toolchain seems *so*
heavy.  And if you want to generate PDFs, it's even heavier.

What about mandoc?

  http://mandoc.bsd.lv/

It seems pretty lightweight, and from an mdoc source, it can generate
ASCII, HTML, man, PDF, and PostScript.

Lewis

Re: runit patches to fix compiler warnings on RHEL 7

2019-12-02 Thread J. Lewis Muir 
On 12/02, J. Lewis Muir wrote:
> So, if s6 can do something similar, I'd be happy to try it out!  Can it?

Reading more, it seems the answer is yes:

  https://skarnet.org/software/s6/notifywhenup.html

So, s6 has a built-in mechanism where, when the supervised process is
available ("ready" in the s6 nomenclature), it writes a line to a file
descriptor and closes it.

If the supervised process does not support the file descriptor
notification mechanism, a workaround is the s6-notifyoncheck program:

  https://skarnet.org/software/s6/s6-notifyoncheck.html

This all looks promising!  Thank you, Laurent, for writing and
maintaining s6!

Lewis

Re: runit patches to fix compiler warnings on RHEL 7

2019-12-02 Thread J. Lewis Muir 
On 11/28, Laurent Bercot wrote:
>  - This mailing-list accepts all discussions about process supervision
> software. It also accepts patches to such software (but rather than cold
> sending patches, please engage in a tech discussion first - it doesn't
> have to be long.)

OK, great!  I just sent my patch series in a separate reply.  I'm happy
to have a tech discussion about it, and I could possibly change the
patch series based on the discussion, or if it is determined that my
patch series should not be accepted, I would accept that as well.

>  - The original author or runit is still subscribed to this list, and
> comes from time to time. However, I'm not aware of an official repo for
> runit, and runit's latest official version has been 2.1.2 for many a year
> now.
>  It looks like several distributions have their own version of runit;
> they are maintained by the distros themselves.
> 
>  - We on the list will gladly help with any question with runit, but to
> be honest, I'm not exactly sure what to do with patch upstream requests
> for runit. Is anyone processing them and integrating them into a new
> release?
 
This is unfortunate, but I understand and know that things can happen,
priorities can change, time availability can change, etc.  A proper
upstream would be useful.  A bunch of forks does not seem useful to me.
The versions maintained by distros do not seem useful to me because I
suspect that they would not be interested in patches related to distros
or OSes other than their own.

>  - I host this list. I'm also the author of s6, a supervision software
> suite that is very similar to runit in many ways. s6 is actively
> maintained and has a public git repo, and we generally have a quick
> response time with requests.
> 
>  - My opinion is that the most sustainable path forward, for runit
> users who need a centrally maintained supervision software suite, is to
> just switch to s6 - and it comes with several other benefits as well.

OK, I'm open to that.  Thanks for the suggestion!

I don't need an init replacement, and I initially chose daemontools
because it was the original toolset, and I wanted something that could
start and stop a server process that did not daemonize itself.  But
the server that I wanted to manage took a while to actually become
"available," and daemontools didn't support the concept of a service
becoming available sometime after when it was started.  That's when
I found runit which did support the concept of a service becoming
available with its "sv start" command and a "./check" service script.
This way, I could start it and wait for it to become available before
starting something else.

So, if s6 can do something similar, I'd be happy to try it out!  Can it?

My use case is actually to run it as a systemd service, so briefly
looking at

  https://skarnet.org/software/

I see something called sdnotify-wrapper, so maybe I should have a look
at that?  (It was mentioned to me off-list.)

>  - But again, I'm not impartial, and alternatives are a good thing.
> So no matter what individual decisions are made, it would definitely be
> a net positive if the exact state and workflow of runit could be
> clarified, and if a real development/maintenance structure was in place.

+1.  Agreed.

Lewis

Re: runit patches to fix compiler warnings on RHEL 7

2019-12-02 Thread J. Lewis Muir 
On 11/27, Martin Castillo wrote:
> On 27.11.19 21:33, J. Lewis Muir wrote:
> > On 11/25, J. Lewis Muir wrote:
> >> Is runit hosted in a public source code repo?  If so, where?
> >>
> >> Are patches to fix runit compiler warnings on RHEL 7 welcome?
> > 
> > I have patches now.  Is there a public source code repo I can contribute
> > against?  Or would it be helpful to just send the patches to the list?
> 
> AFAIK you have to post them to this list.

OK, attached is the patch series.

To apply it against runit 2.1.2:

$ cd admin/runit-2.1.2
$ patch -p2 < /path/to/runit-2.1.2-rhel-7-compiler-fixes.diff

The patch series eliminates all GCC 4.8.5 warnings on x86_64 RHEL 7.7.
I haven't tested on other platforms, so it could be that some of the
fixes just make it compile cleanly on RHEL 7 but not on other platforms.
If this is the case, then I think more logic would be needed at compile
time to test the available APIs and choose the appropriate APIs to use.

Regards,

Lewis
# HG changeset patch
# User J. Lewis Muir 
# Date 1574790428 21600
#  Tue Nov 26 11:47:08 2019 -0600
# Branch 2.1.2_compiler-warning-fixes
# Node ID bdaf3416fb1b1010546d8a52b75dc764ca8a80a5
# Parent  6001387b32501dd5c76c969467cf4f7a655e9dcf
Change getgroups arg 2 type in chkshsgr.c to gid_t

This change eliminates the following GCC 4.8.5 warning on RHEL 7.7:

  ./compile chkshsgr.c
  chkshsgr.c: In function ‘main’:
  chkshsgr.c:10:3: warning: passing argument 2 of ‘getgroups’ from incompatible 
pointer type [enabled by default]
 if (getgroups(1,x) == 0) if (setgroups(1,x) == -1) _exit(1);
 ^
  In file included from chkshsgr.c:3:0:
  /usr/include/unistd.h:711:12: note: expected ‘__gid_t *’ but argument is of 
type ‘short int *’
   extern int getgroups (int __size, __gid_t __list[]) __THROW __wur;
  ^

diff -r 6001387b3250 -r bdaf3416fb1b external/src/chkshsgr.c
--- a/external/src/chkshsgr.c   Tue Nov 26 10:48:03 2019 -0600
+++ b/external/src/chkshsgr.c   Tue Nov 26 11:47:08 2019 -0600
@@ -4,7 +4,7 @@
 
 int main()
 {
-  short x[4];
+  gid_t x[4];
 
   x[0] = x[1] = 0;
   if (getgroups(1,x) == 0) if (setgroups(1,x) == -1) _exit(1);
# HG changeset patch
# User J. Lewis Muir 
# Date 1574791174 21600
#  Tue Nov 26 11:59:34 2019 -0600
# Branch 2.1.2_compiler-warning-fixes
# Node ID a12ee55203125f8ef926dbe72e66a1bd45235619
# Parent  bdaf3416fb1b1010546d8a52b75dc764ca8a80a5
Include grp.h in chkshsgr.c

This change eliminates the following GCC 4.8.5 warning on RHEL 7.7:

  ./compile chkshsgr.c
  chkshsgr.c: In function ‘main’:
  chkshsgr.c:10:3: warning: implicit declaration of function ‘setgroups’ 
[-Wimplicit-function-declaration]
 if (getgroups(1,x) == 0) if (setgroups(1,x) == -1) _exit(1);
 ^

diff -r bdaf3416fb1b -r a12ee5520312 external/src/chkshsgr.c
--- a/external/src/chkshsgr.c   Tue Nov 26 11:47:08 2019 -0600
+++ b/external/src/chkshsgr.c   Tue Nov 26 11:59:34 2019 -0600
@@ -1,5 +1,6 @@
 /* Public domain. */
 
+#include 
 #include 
 
 int main()
# HG changeset patch
# User J. Lewis Muir 
# Date 1574791401 21600
#  Tue Nov 26 12:03:21 2019 -0600
# Branch 2.1.2_compiler-warning-fixes
# Node ID b0034c0716a2f8496d17d5c4a1d8d77193b3594f
# Parent  a12ee55203125f8ef926dbe72e66a1bd45235619
Include grp.h in chpst.c

This change eliminates the following GCC 4.8.5 warning on RHEL 7.7:

  ./compile chpst.c
  chpst.c: In function ‘suidgid’:
  chpst.c:80:3: warning: implicit declaration of function ‘setgroups’ 
[-Wimplicit-function-declaration]
 if (setgroups(ugid.gids, ugid.gid) == -1) fatal("unable to setgroups");
 ^

diff -r a12ee5520312 -r b0034c0716a2 external/src/chpst.c
--- a/external/src/chpst.c  Tue Nov 26 11:59:34 2019 -0600
+++ b/external/src/chpst.c  Tue Nov 26 12:03:21 2019 -0600
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "sgetopt.h"
 #include "error.h"
# HG changeset patch
# User J. Lewis Muir 
# Date 1574791671 21600
#  Tue Nov 26 12:07:51 2019 -0600
# Branch 2.1.2_compiler-warning-fixes
# Node ID 396b02da6d0e56256ac5c1cf00ed0af690dbd8f1
# Parent  b0034c0716a2f8496d17d5c4a1d8d77193b3594f
Avoid op sequence order ambiguity in chpst.c

This change eliminates the following GCC 4.8.5 warning on RHEL 7.7:

  ./compile chpst.c
  chpst.c: In function ‘main’:
  chpst.c:312:33: warning: operation on ‘subgetoptarg’ may be undefined 
[-Wsequence-point]
 if (optarg[scan_ulong(++optarg, )]) usage(); nicelvl =ul;
   ^

diff -r b0034c0716a2 -r 396b02da6d0e external/src/chpst.c
--- a/external/src/chpst.c  Tue Nov 26 12:03:21 2019 -0600
+++ b/external/src/chpst.c  Tue Nov 26 12:07:51 2019 -0600
@@ -309,7 +309,8 @@
 case 'n':
   switch (*optarg) {
 case '-':
-  if (optarg[scan_ulong(++optarg, )]) usage(); nicelvl =ul;
+  ++optarg;
+  if (optarg[scan_ulong(optarg, )]) usage

Re: runit patches to fix compiler warnings on RHEL 7

2019-11-27 Thread J. Lewis Muir 
On 11/25, J. Lewis Muir wrote:
> Is runit hosted in a public source code repo?  If so, where?
> 
> Are patches to fix runit compiler warnings on RHEL 7 welcome?

I have patches now.  Is there a public source code repo I can contribute
against?  Or would it be helpful to just send the patches to the list?

Lewis

runit patches to fix compiler warnings on RHEL 7

2019-11-25 Thread J. Lewis Muir 
Hello!

Is runit hosted in a public source code repo?  If so, where?

Are patches to fix runit compiler warnings on RHEL 7 welcome?

Thank you!

Lewis