nosh version 1.9

classic Classic list List threaded Threaded
69 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

nosh version 1.9

Jonathan de Boyne Pollard
nosh version 1.9 is out.  If you've not heard of it, here's the blurb:

* http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html

If you also read the worked example, make sure that you read all of the
way to the bottom.  (-:  If you want to read more, there's a whole Guide
in the package, and lots of manual pages.

There's now a command for converting FreeBSD /etc/rc.conf{,.local}
preset information (the *_enable variables) to service bundle preset
information.  For kicks, I've also added a small shim for the OpenBSD
"rcctl" command that they're busy inventing.  It's worth noting that
OpenBSD 5.6 now specifies that /etc/rc.conf{,.local} doesn't have shell
expansions and isn't necessarily sourced by a shell, which is change
that I welcome with open arms.  I will be looking at conversion of
OpenBSD *_flags variables; but the big thing that remains in this area
is a utility that pushes all of the other variables, apart from
*_enable, into envdirs in the appropriate service bundles, which is
going to be a tedious one-by-one slog because sometimes the variable
names don't match the service names, as you no doubt know.

I set myself a task of converting to service bundles all but two of the
157 non-target scripts that I found in a stock FreeBSD /etc/rc.d/ .  
I've reached 85.  A lot of the remaining scripts are complex, often
one-shot, shell scripts onto the side of which the rc.d start/stop
system has been bolted, with varying degrees of success.  If you are
interested in helping, one of the things that would help greatly is
factoring out the meat of some of these into helper commands of some
kind, reducing the lopsided hulks to something more like (say)
/etc/rc.d/rpcbind .  (I can supply a list.)  As reciprocal payment in
advance, I'm letting you know that /etc/rc.d/msgs is missing all of the
rc.d mechanism, and so does the same thing on every
start/stop/restart/whatever command verb. Although I suggest that
factoring out things in this way is a gain for the rc.d system, too, and
of mutual benefit.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: nosh version 1.9

Alfred Perlstein-3
Very cool.

Wondering about the idea of /etc/rc.conf *not* being a shell script...
this is sort of bad imo as I can't see any other way to provide the
settings dynamically for the startup scripts at a glance.

I'll give you an example... FreeNAS (and by extension the appliance we
are building at Norse) has /etc/rc.conf.local as a shell script that
pulls data from an sqlite database, this allows us to set various
services on/off based on the contents of that sqlite database file.

This in turn allows us to leverage most of the existing /etc/rc.d and by
extension the /usr/local/etc/rc.d files provided by ports.

I'm wondering how one could still do that if /etc/rc.conf and
/etc/rc.conf.local were no longer scripts?



-Alfred

On 10/18/14, 5:52 PM, Jonathan de Boyne Pollard wrote:

> nosh version 1.9 is out.  If you've not heard of it, here's the blurb:
>
> *
> http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html
>
> If you also read the worked example, make sure that you read all of
> the way to the bottom.  (-:  If you want to read more, there's a whole
> Guide in the package, and lots of manual pages.
>
> There's now a command for converting FreeBSD /etc/rc.conf{,.local}
> preset information (the *_enable variables) to service bundle preset
> information.  For kicks, I've also added a small shim for the OpenBSD
> "rcctl" command that they're busy inventing.  It's worth noting that
> OpenBSD 5.6 now specifies that /etc/rc.conf{,.local} doesn't have
> shell expansions and isn't necessarily sourced by a shell, which is
> change that I welcome with open arms.  I will be looking at conversion
> of OpenBSD *_flags variables; but the big thing that remains in this
> area is a utility that pushes all of the other variables, apart from
> *_enable, into envdirs in the appropriate service bundles, which is
> going to be a tedious one-by-one slog because sometimes the variable
> names don't match the service names, as you no doubt know.
>
> I set myself a task of converting to service bundles all but two of
> the 157 non-target scripts that I found in a stock FreeBSD /etc/rc.d/
> .  I've reached 85.  A lot of the remaining scripts are complex, often
> one-shot, shell scripts onto the side of which the rc.d start/stop
> system has been bolted, with varying degrees of success.  If you are
> interested in helping, one of the things that would help greatly is
> factoring out the meat of some of these into helper commands of some
> kind, reducing the lopsided hulks to something more like (say)
> /etc/rc.d/rpcbind .  (I can supply a list.)  As reciprocal payment in
> advance, I'm letting you know that /etc/rc.d/msgs is missing all of
> the rc.d mechanism, and so does the same thing on every
> start/stop/restart/whatever command verb. Although I suggest that
> factoring out things in this way is a gain for the rc.d system, too,
> and of mutual benefit.
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
> "[hidden email]"
>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: nosh version 1.9

Adrian Chadd-2
On 18 October 2014 18:51, Alfred Perlstein <[hidden email]> wrote:

> Very cool.
>
> Wondering about the idea of /etc/rc.conf *not* being a shell script... this
> is sort of bad imo as I can't see any other way to provide the settings
> dynamically for the startup scripts at a glance.
>
> I'll give you an example... FreeNAS (and by extension the appliance we are
> building at Norse) has /etc/rc.conf.local as a shell script that pulls data
> from an sqlite database, this allows us to set various services on/off based
> on the contents of that sqlite database file.
>
> This in turn allows us to leverage most of the existing /etc/rc.d and by
> extension the /usr/local/etc/rc.d files provided by ports.
>
> I'm wondering how one could still do that if /etc/rc.conf and
> /etc/rc.conf.local were no longer scripts?

The same way /etc/rc.conf and /etc/rc.conf.local is pulled in - via
the little snippet of stuff at the end of /etc/defaults/rc.conf , and
this bit of config in that file:

local_startup="/usr/local/etc/rc.d" # startup script dirs.
script_name_sep=" "     # Change if your startup scripts' names contain spaces
rc_conf_files="/etc/rc.conf /etc/rc.conf.local"

So, we just need some method of pulling in environment variables in
whatever order we need from whatever place we need.

(God, why do I know this stuff? Then I remembered -
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=17595 . God damnit.)

The tricky bit is trying to make it so we don't call sqlite like a
thousand times to pull out all of the environment variables for each
invocation of an rc script.


-adrian
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: nosh version 1.9

Alfred Perlstein-3
Adding lazy variable extension to sh should be relatively easy.

Sent from my iPhone

> On Oct 18, 2014, at 7:16 PM, Adrian Chadd <[hidden email]> wrote:
>
>> On 18 October 2014 18:51, Alfred Perlstein <[hidden email]> wrote:
>> Very cool.
>>
>> Wondering about the idea of /etc/rc.conf *not* being a shell script... this
>> is sort of bad imo as I can't see any other way to provide the settings
>> dynamically for the startup scripts at a glance.
>>
>> I'll give you an example... FreeNAS (and by extension the appliance we are
>> building at Norse) has /etc/rc.conf.local as a shell script that pulls data
>> from an sqlite database, this allows us to set various services on/off based
>> on the contents of that sqlite database file.
>>
>> This in turn allows us to leverage most of the existing /etc/rc.d and by
>> extension the /usr/local/etc/rc.d files provided by ports.
>>
>> I'm wondering how one could still do that if /etc/rc.conf and
>> /etc/rc.conf.local were no longer scripts?
>
> The same way /etc/rc.conf and /etc/rc.conf.local is pulled in - via
> the little snippet of stuff at the end of /etc/defaults/rc.conf , and
> this bit of config in that file:
>
> local_startup="/usr/local/etc/rc.d" # startup script dirs.
> script_name_sep=" "     # Change if your startup scripts' names contain spaces
> rc_conf_files="/etc/rc.conf /etc/rc.conf.local"
>
> So, we just need some method of pulling in environment variables in
> whatever order we need from whatever place we need.
>
> (God, why do I know this stuff? Then I remembered -
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=17595 . God damnit.)
>
> The tricky bit is trying to make it so we don't call sqlite like a
> thousand times to pull out all of the environment variables for each
> invocation of an rc script.
>
>
> -adrian
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: nosh version 1.9

Outback Dingo-2
On Sun, Oct 19, 2014 at 1:38 PM, Alfred Perlstein <[hidden email]> wrote:

> Adding lazy variable extension to sh should be relatively easy.
>
> Sent from my iPhone
>
> > On Oct 18, 2014, at 7:16 PM, Adrian Chadd <[hidden email]> wrote:
> >
> >> On 18 October 2014 18:51, Alfred Perlstein <[hidden email]> wrote:
> >> Very cool.
> >>
> >> Wondering about the idea of /etc/rc.conf *not* being a shell script...
> this
> >> is sort of bad imo as I can't see any other way to provide the settings
> >> dynamically for the startup scripts at a glance.
> >>
> >> I'll give you an example... FreeNAS (and by extension the appliance we
> are
> >> building at Norse) has /etc/rc.conf.local as a shell script that pulls
> data
> >> from an sqlite database, this allows us to set various services on/off
> based
> >> on the contents of that sqlite database file.
> >>
> >> This in turn allows us to leverage most of the existing /etc/rc.d and by
> >> extension the /usr/local/etc/rc.d files provided by ports.
> >>
> >> I'm wondering how one could still do that if /etc/rc.conf and
> >> /etc/rc.conf.local were no longer scripts?
> >
> > The same way /etc/rc.conf and /etc/rc.conf.local is pulled in - via
> > the little snippet of stuff at the end of /etc/defaults/rc.conf , and
> > this bit of config in that file:
> >
> > local_startup="/usr/local/etc/rc.d" # startup script dirs.
> > script_name_sep=" "     # Change if your startup scripts' names contain
> spaces
> > rc_conf_files="/etc/rc.conf /etc/rc.conf.local"
> >
> > So, we just need some method of pulling in environment variables in
> > whatever order we need from whatever place we need.
> >
> > (God, why do I know this stuff? Then I remembered -
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=17595 . God damnit.)
> >
> > The tricky bit is trying to make it so we don't call sqlite like a
> > thousand times to pull out all of the environment variables for each
> > invocation of an rc script.
> >
> >
> > -adrian
>

IMHO I think we'd be better off with launchd... but this does show
intelligence....



> > _______________________________________________
> > [hidden email] mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "
> [hidden email]"
> >
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: nosh version 1.9

Jonathan de Boyne Pollard
Outback Dingo:
>
> IMHO I think we'd be better off with launchd... but this does show
> intelligence....
>

A while ago, I lived in a comfortable little world.  Yes, everyone else
was getting the likes of Solaris SMF, AIX SRC, systemd, upstart, and
whatnot.  But BSD was alright.  Someone was bound to come along and
package up launchd.  After all, MacOS is BSD ... right?

Then I did some investigation.

There have been, to my knowledge, three attempts (in 2005, 2008, and
2013) to give launchd to the general BSD world that have involved more
than just talk.  All have foundered.  The discomforting truth is that we
aren't going to get launchd for doing service and system management for
the very same reasons that we aren't going to get systemd for doing
service and system management.  systemd is full of Linuxisms.  launchd
is full of Machisms.  It's simply not a BSD program.  It's a Mach
program.  (The fact that the initial process program isn't portable is
obvious in hindsight.  I kicked myself. I've written several initial
process programs before.  They aren't, and cannot be, limited to
non-operating-system-specific stuff.)  One attempt to port launchd
involved stubbing out the Machisms.  There has been a recent attempt to
port systemd to FreeBSD that is in the same boat: stub out or remove all
of the operating system specific parts, and one can get a program that
will compile (with a lot of compiler warnings); but it doesn't function.

The launchd train is never coming.  It's this realization, in addition
to several other motivating factors, that spurred me to aim high with
nosh, and actually set that task of converting those rc.d scripts.  Feel
free to thank the valiant and noble failures of the launchd porters for
the fact that there's one alternative to BSD init that doesn't put an
XML parser into the program for process #1.  (-:
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: nosh version 1.9

Outback Dingo-2
On Thu, Oct 23, 2014 at 9:06 AM, Jonathan de Boyne Pollard <
[hidden email]> wrote:

> Outback Dingo:
>
>>
>> IMHO I think we'd be better off with launchd... but this does show
>> intelligence....
>>
>>
> A while ago, I lived in a comfortable little world.  Yes, everyone else
> was getting the likes of Solaris SMF, AIX SRC, systemd, upstart, and
> whatnot.  But BSD was alright.  Someone was bound to come along and package
> up launchd.  After all, MacOS is BSD ... right?
>
> Then I did some investigation.
>
> There have been, to my knowledge, three attempts (in 2005, 2008, and 2013)
> to give launchd to the general BSD world that have involved more than just
> talk.  All have foundered.  The discomforting truth is that we aren't going
> to get launchd for doing service and system management for the very same
> reasons that we aren't going to get systemd for doing service and system
> management.  systemd is full of Linuxisms.  launchd is full of Machisms.
> It's simply not a BSD program.  It's a Mach program.  (The fact that the
> initial process program isn't portable is obvious in hindsight.  I kicked
> myself. I've written several initial process programs before.  They aren't,
> and cannot be, limited to non-operating-system-specific stuff.)  One
> attempt to port launchd involved stubbing out the Machisms.  There has been
> a recent attempt to port systemd to FreeBSD that is in the same boat: stub
> out or remove all of the operating system specific parts, and one can get a
> program that will compile (with a lot of compiler warnings); but it doesn't
> function.
>
> The launchd train is never coming.  It's this realization, in addition to
> several other motivating factors, that spurred me to aim high with nosh,
> and actually set that task of converting those rc.d scripts.  Feel free to
> thank the valiant and noble failures of the launchd porters for the fact
> that there's one alternative to BSD init that doesn't put an XML parser
> into the program for process #1.  (-:
>
>
Actually thats not true..... We did successfully port it, and it is not
released on github..... and it does work.

https://github.com/outbackdingo/launchd_xml


> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: nosh version 1.9

Outback Dingo-2
On Thu, Oct 23, 2014 at 9:59 AM, Outback Dingo <[hidden email]>
wrote:

>
>
> On Thu, Oct 23, 2014 at 9:06 AM, Jonathan de Boyne Pollard <
> [hidden email]> wrote:
>
>> Outback Dingo:
>>
>>>
>>> IMHO I think we'd be better off with launchd... but this does show
>>> intelligence....
>>>
>>>
>> A while ago, I lived in a comfortable little world.  Yes, everyone else
>> was getting the likes of Solaris SMF, AIX SRC, systemd, upstart, and
>> whatnot.  But BSD was alright.  Someone was bound to come along and package
>> up launchd.  After all, MacOS is BSD ... right?
>>
>> Then I did some investigation.
>>
>> There have been, to my knowledge, three attempts (in 2005, 2008, and
>> 2013) to give launchd to the general BSD world that have involved more than
>> just talk.  All have foundered.  The discomforting truth is that we aren't
>> going to get launchd for doing service and system management for the very
>> same reasons that we aren't going to get systemd for doing service and
>> system management.  systemd is full of Linuxisms.  launchd is full of
>> Machisms.  It's simply not a BSD program.  It's a Mach program.  (The fact
>> that the initial process program isn't portable is obvious in hindsight.  I
>> kicked myself. I've written several initial process programs before.  They
>> aren't, and cannot be, limited to non-operating-system-specific stuff.)
>> One attempt to port launchd involved stubbing out the Machisms.  There has
>> been a recent attempt to port systemd to FreeBSD that is in the same boat:
>> stub out or remove all of the operating system specific parts, and one can
>> get a program that will compile (with a lot of compiler warnings); but it
>> doesn't function.
>>
>> The launchd train is never coming.  It's this realization, in addition to
>> several other motivating factors, that spurred me to aim high with nosh,
>> and actually set that task of converting those rc.d scripts.  Feel free to
>> thank the valiant and noble failures of the launchd porters for the fact
>> that there's one alternative to BSD init that doesn't put an XML parser
>> into the program for process #1.  (-:
>>
>>
> Actually thats not true..... We did successfully port it, and it is not
> released on github..... and it does work.
>
> https://github.com/outbackdingo/launchd_xml
>

And to further note, we have even used openrc successfully on FreeBSD, As
it all boils down I think to users preferences
I believe having a choice is good..... now there appear to be three
alternatives in the mix......


>
>
>
>> _______________________________________________
>> [hidden email] mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "[hidden email]
>> "
>>
>
>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: nosh version 1.9

Jordan Hubbard-3
In reply to this post by Jonathan de Boyne Pollard

> On Oct 22, 2014, at 3:06 PM, Jonathan de Boyne Pollard <[hidden email] <mailto:[hidden email]>> wrote:
>
> There have been, to my knowledge, three attempts (in 2005, 2008, and 2013) to give launchd to the general BSD world that have involved more than just talk.  All have foundered.  The discomforting truth is that we aren't going to get launchd for doing service and system management for the very same reasons that we aren't going to get systemd for doing service and system management.  systemd is full of Linuxisms.  launchd is full of Machisms.  It's simply not a BSD program.  It's a Mach program.  (The fact that the initial process program isn't portable is obvious in hindsight.  I kicked myself. I've written several initial process programs before.  They aren't, and cannot be, limited to non-operating-system-specific stuff.)  One attempt to port launchd involved stubbing out the Machisms.  There has been a recent attempt to port systemd to FreeBSD that is in the same boat: stub out or remove all of the operating system specific parts, and one can get a program that will compile (with a lot of compiler warnings); but it doesn't function.
>
> The launchd train is never coming.  

I aim to disprove that assertion sometime in the next 12 months.

I’ll also point out that it would have taken less time to port NetBSD’s COMPAT_MACH code than it’s probably taken to beat one’s head against mach ports in launchd.  They would certainly not be the first Mach code FreeBSD has ever seen (take a look at the VM system sometime!).

- Jordan

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: nosh version 1.9

Jordan Hubbard-3
In reply to this post by Jonathan de Boyne Pollard

> On Oct 22, 2014, at 3:06 PM, Jonathan de Boyne Pollard <[hidden email]> wrote:
>
> Feel free to thank the valiant and noble failures of the launchd porters for the fact that there's one alternative to BSD init that doesn't put an XML parser into the program for process #1.  (-:

Also, just to correct what has always been a rather blatant misconception about launchd.  Launchd knows *nothing* (NUH-THING) about XML.  There is no XML parser in process 1.  Anyone who thinks this has simply never even looked at how launchd works.   It’s completely agnostic to configuration file formats and wouldn’t know a configuration file format if one bit it on the ass.  That’s actually one of the more elegant aspects of its design!

- Jordan

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: nosh version 1.9

Jim Thompson-6
In reply to this post by Outback Dingo-2


> On Oct 22, 2014, at 5:59 PM, Outback Dingo <[hidden email]> wrote:
>
> Actually thats not true..... We did successfully port it, and it is not
> released on github..... and it does work.
>
> https://github.com/outbackdingo/launchd_xml

And they used it in a forked version of pfSense. :-)


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: nosh version 1.9

Outback Dingo-2
In reply to this post by Jordan Hubbard-3
On Thu, Oct 23, 2014 at 10:10 AM, Jordan Hubbard <[hidden email]> wrote:

>
> > On Oct 22, 2014, at 3:06 PM, Jonathan de Boyne Pollard
> <[hidden email]> wrote:
> >
> > Feel free to thank the valiant and noble failures of the launchd porters
> for the fact that there's one alternative to BSD init that doesn't put an
> XML parser into the program for process #1.  (-:
>
> Also, just to correct what has always been a rather blatant misconception
> about launchd.  Launchd knows *nothing* (NUH-THING) about XML.  There is no
> XML parser in process 1.  Anyone who thinks this has simply never even
> looked at how launchd works.   It’s completely agnostic to configuration
> file formats and wouldn’t know a configuration file format if one bit it on
> the ass.  That’s actually one of the more elegant aspects of its design!
>
> - Jordan
>
>
Actually our port is "very" xml aware :) see
https://github.com/outbackdingo/launchd_xml/tree/master/launch_xml



> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: nosh version 1.9

Jordan Hubbard-3

> On Oct 22, 2014, at 7:16 PM, Outback Dingo <[hidden email] <mailto:[hidden email]>> wrote:
>
> Actually our port is "very" xml aware :) see https://github.com/outbackdingo/launchd_xml/tree/master/launch_xml <https://github.com/outbackdingo/launchd_xml/tree/master/launch_xml>
OK, well, launchd as originally designed certainly was not (and is not) xml-aware.  This was on purpose.  You don’t want a lot of surface area in pid 1, which can never crash, nor do you want to bake your serialization format into stone tablets.

launchctl(1) does all the XML parsing and then passes the results to launchd using its own custom IPC format.  Was there some particular reason you violently inserted the XML parsing directly into launchd after the original architect(s) went to such pains to avoid such blatant penitentiary experiences? :-)

- Jordan

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: nosh version 1.9

Alfred Perlstein-3

On 10/22/14 7:49 PM, Jordan Hubbard wrote:
>> On Oct 22, 2014, at 7:16 PM, Outback Dingo <[hidden email] <mailto:[hidden email]>> wrote:
>>
>> Actually our port is "very" xml aware :) see https://github.com/outbackdingo/launchd_xml/tree/master/launch_xml <https://github.com/outbackdingo/launchd_xml/tree/master/launch_xml>
> OK, well, launchd as originally designed certainly was not (and is not) xml-aware.  This was on purpose.  You don’t want a lot of surface area in pid 1, which can never crash, nor do you want to bake your serialization format into stone tablets.
>
> launchctl(1) does all the XML parsing and then passes the results to launchd using its own custom IPC format.  Was there some particular reason you violently inserted the XML parsing directly into launchd after the original architect(s) went to such pains to avoid such blatant penitentiary experiences? :-)
>
I could see the utility of that.  One of our senior full stack devs says
that XML is "triggering" and that they wouldn't want to work on such a
system.  Perhaps it's to keep web people out?

-Alfred
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: nosh version 1.9

Allan Jude-9
In reply to this post by Jordan Hubbard-3
On 2014-10-22 22:49, Jordan Hubbard wrote:

>
>> On Oct 22, 2014, at 7:16 PM, Outback Dingo <[hidden email] <mailto:[hidden email]>> wrote:
>>
>> Actually our port is "very" xml aware :) see https://github.com/outbackdingo/launchd_xml/tree/master/launch_xml <https://github.com/outbackdingo/launchd_xml/tree/master/launch_xml>
> OK, well, launchd as originally designed certainly was not (and is not) xml-aware.  This was on purpose.  You don’t want a lot of surface area in pid 1, which can never crash, nor do you want to bake your serialization format into stone tablets.
>
> launchctl(1) does all the XML parsing and then passes the results to launchd using its own custom IPC format.  Was there some particular reason you violently inserted the XML parsing directly into launchd after the original architect(s) went to such pains to avoid such blatant penitentiary experiences? :-)
>
> - Jordan
>
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
>
The nice thing about this design is that it would allow replacing the
XML with something more human readable/writing like UCL

--
Allan Jude


signature.asc (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: nosh version 1.9

Jim Thompson-6

> On Oct 22, 2014, at 11:34 PM, Allan Jude <[hidden email]> wrote:
>
> The nice thing about this design is that it would allow replacing the
> XML with something more human readable/writing like UCL.

Dude, that's not web-scale.  You're gonna want yaml.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: nosh version 1.9

Jim Thompson-6
In reply to this post by Jordan Hubbard-3


> On Oct 22, 2014, at 9:49 PM, Jordan Hubbard <[hidden email]> wrote:
>
> launchctl(1) does all the XML parsing and then passes the results to launchd using its own custom IPC format.  Was there some particular reason you violently inserted the XML parsing directly into launchd after the original architect(s) went to such pains to avoid such blatant penitentiary experiences?

They forked pfSense.

See figure 1.

(Even I, lead on one of the larger consumers of XML in freebsd,
think it's abhorrent.)
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: nosh version 1.9

Jim Thompson-6
In reply to this post by Jordan Hubbard-3


> On Oct 22, 2014, at 6:10 PM, Jordan Hubbard <[hidden email]> wrote:
>
> That’s actually one of the more elegant aspects of its design!

Now I'm waiting for esr to appear and explain BCPL to Robert Firth.

https://groups.google.com/forum/m/#!topic/comp.arch/GUA7AtDPy84
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: nosh version 1.9

Allan Jude-9
In reply to this post by Jim Thompson-6
On 2014-10-23 01:10, Jim Thompson wrote:

>
>> On Oct 22, 2014, at 11:34 PM, Allan Jude <[hidden email]> wrote:
>>
>> The nice thing about this design is that it would allow replacing the
>> XML with something more human readable/writing like UCL.
>
> Dude, that's not web-scale.  You're gonna want yaml.
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
>
UCL can read YAML and JSON, it is just less sensitive than either, so
missing whitespace, or a trailing comma won't break the parsing of your
config file.

(A trailing comma on the last array element is nice to have, as it
reduces the diff when you add a new item)

So it means the config files can be valid JSON or YAML, or something
that looks similar but is less fussy, so that it is more human writable.

--
Allan Jude


signature.asc (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: nosh version 1.9

Jordan Hubbard-2
In reply to this post by Alfred Perlstein-3

> On Oct 22, 2014, at 8:40 PM, Alfred Perlstein <[hidden email]> wrote:
>
>> launchctl(1) does all the XML parsing and then passes the results to launchd using its own custom IPC format.  Was there some particular reason you violently inserted the XML parsing directly into launchd after the original architect(s) went to such pains to avoid such blatant penitentiary experiences? :-)
>>
> I could see the utility of that.  One of our senior full stack devs says that XML is "triggering" and that they wouldn't want to work on such a system.  Perhaps it's to keep web people out?

Well, whatever the rationale the pfsense-forkers (that sounds dirty) might have had, I think it’s fair to say that this is an abstraction layer that would be easy to add back since it exists that way in the original source code base, and I would certainly be happy to see it done (it could be done via a socket and a -h <hostname> argument added to launchctl if “something other than Mach ports” was the desired IPC mechanism and you even wanted to be able to drive a remote launchd through its paces).  Either way, it’s the launchctl(1) command that ought to speak XML or YAML or any other reasonably structured format people like.  Not embedding it in launchd is good for a lot more than architectural cleanliness.

As far as Mach IPC is concerned, it’s so prevalent in OS X and iOS largely because:

A) It’s already there.
B) The Mach port space confers certain security advantages (port rights, bootstrap sets, security trailers on all IPC).
C) It’s easy to create interfaces for it (MiG isn’t pretty, but it’s more than you get with sockets).

However, given that launchd starts up as pid 1 and can bind to a suitably secure low-numbered port for IPC (making it correspondingly harder to spoof launchctl) I don’t really see any reason, other than code compatibility, not to use another IPC mechanism in FreeBSD.   I’d kind of like Mach ports in FreeBSD just to remove this final barrier to compatibility for a wide range of software that would otherwise cross the divide, but I also get that they’re a bit retro.

- Jordan

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
1234