OpenRC on FreeBSD

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

OpenRC on FreeBSD

Martin Wilke-9
Hi

I'd like to reopen the discussion for OpenRC on FreeBSD. Basically this is the second attempt to get it into FreeBSD.

I've opened a review here with a working patch for CURRENT,
https://reviews.freebsd.org/D18578


To recap the discussion
    * First attempt of RFC in March of 2018: https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.html
    * Working group at BSDCan: https://wiki.freebsd.org/DevSummit/201806/OpenRC

Here some key points:

OpenRC provides additional features for service management without requiring kernel changes or replacing pid 1, unlike launchd and other solutions.  All rc.d scripts have been converted with a few changes, typically changing the shebang and making sure the start function is named start(). Most service scripts are simplified, usually needing only name, command, and, if required, depends statements.

History:
OpenRC started out as an init system by Roy Marples, developed for the Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into Gentoo as baselayout v2, and was then split off as a separate BSD-licensed project. It is under active development, portable, and remains BSD licensed today.

OpenRC and RC:
Both can coexist and be chosen with a setting in /boot/loader.conf.

OpenRC Features:

Service supervision and service monitoring: any service can be supervised. Supervised services that crash are automatically restarted. The rc-status command shows how many times a service has restarted.

Device hotplug support and event-driven service management: the hotplug feature allows devd to take actions when devices are connected. For example, a USB wifi adapter can create additional network services when attached. The net-online service can, for example, detect when a network connection is restored, and restart ntp.

Network profiles: using stacked runlevels, different profiles can be established for different networking settings. For instance, different profiles can be used for wired or wireless networking, or for differing wireless networks, as well as dependency caching and parallel startup speed up booting.

Interactive mode:
The boot process can be run interactively for more effective debugging.

OpenRC uses the term “runlevels” to refer to the context in which a script is running. There are only three at present:
sysinit (the OpenRC system is starting), boot (start base services when the computer is booting), and default (normal execution).

OpenRC, by default, provides a “colorized” text boot, using ANSI color sequences. This can be disabled.

Ports:
As of July 2017, iXsystems has created OpenRC versions of port service scripts for the entire ports tree. These scripts coexist with the rc.d versions.

License:
OpenRC is a BSD licensed RC init system written in C. From a user perspective, it is very similar to the FreeBSD rc.d init system, making it easy to use and learn.

Tested: OpenRC has been used as the init system for TrueOS since October 2016.

Ken Moore has an OpenRC vs RC.d comparison which can be found here:
http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf <http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf>
I look forward to discuss the features and capabilities of OpenRC.

Regards,
Martin

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

Re: OpenRC on FreeBSD

Warner Losh
On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke <[hidden email]> wrote:

> Hi
>
> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically this is
> the second attempt to get it into FreeBSD.
>
> I've opened a review here with a working patch for CURRENT,
> https://reviews.freebsd.org/D18578
>
>
> To recap the discussion
>     * First attempt of RFC in March of 2018:
> https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.html
>     * Working group at BSDCan:
> https://wiki.freebsd.org/DevSummit/201806/OpenRC
>
> Here some key points:
>
> OpenRC provides additional features for service management without
> requiring kernel changes or replacing pid 1, unlike launchd and other
> solutions.  All rc.d scripts have been converted with a few changes,
> typically changing the shebang and making sure the start function is named
> start(). Most service scripts are simplified, usually needing only name,
> command, and, if required, depends statements.
>
> History:
> OpenRC started out as an init system by Roy Marples, developed for the
> Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into Gentoo
> as baselayout v2, and was then split off as a separate BSD-licensed
> project. It is under active development, portable, and remains BSD licensed
> today.
>
> OpenRC and RC:
> Both can coexist and be chosen with a setting in /boot/loader.conf.
>
> OpenRC Features:
>
> Service supervision and service monitoring: any service can be supervised.
> Supervised services that crash are automatically restarted. The rc-status
> command shows how many times a service has restarted.
>
> Device hotplug support and event-driven service management: the hotplug
> feature allows devd to take actions when devices are connected. For
> example, a USB wifi adapter can create additional network services when
> attached. The net-online service can, for example, detect when a network
> connection is restored, and restart ntp.
>
> Network profiles: using stacked runlevels, different profiles can be
> established for different networking settings. For instance, different
> profiles can be used for wired or wireless networking, or for differing
> wireless networks, as well as dependency caching and parallel startup speed
> up booting.
>
> Interactive mode:
> The boot process can be run interactively for more effective debugging.
>
> OpenRC uses the term “runlevels” to refer to the context in which a script
> is running. There are only three at present:
> sysinit (the OpenRC system is starting), boot (start base services when
> the computer is booting), and default (normal execution).
>
> OpenRC, by default, provides a “colorized” text boot, using ANSI color
> sequences. This can be disabled.
>
> Ports:
> As of July 2017, iXsystems has created OpenRC versions of port service
> scripts for the entire ports tree. These scripts coexist with the rc.d
> versions.
>
> License:
> OpenRC is a BSD licensed RC init system written in C. From a user
> perspective, it is very similar to the FreeBSD rc.d init system, making it
> easy to use and learn.
>
> Tested: OpenRC has been used as the init system for TrueOS since October
> 2016.
>
> Ken Moore has an OpenRC vs RC.d comparison which can be found here:
> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf <
> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf>
> I look forward to discuss the features and capabilities of OpenRC.
>

This is cool technology.

However, what was missing last time was a written plan that could be
critiqued for fit with the project's needs. The result of the working group
was that this was to be produced, and we'd iterate through it to ease the
landing of openrc in the tree. I think there's wide agreement this is cool,
and that we'd like tot have both it and rc.d in the tree for a transition
period. Absent a plan, though, it's not really possible to say 'go do it'
or 'that's insane'.

So maybe start there?

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

Re: OpenRC on FreeBSD

Martin Wilke-9
Hi,

The missing bit was actually the flag for switching the rc’s which have been resolved.

- Martin

> On 19 Dec 2018, at 10:51 PM, Warner Losh <[hidden email]> wrote:
>
>
>
> On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke <[hidden email] <mailto:[hidden email]>> wrote:
> Hi
>
> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically this is the second attempt to get it into FreeBSD.
>
> I've opened a review here with a working patch for CURRENT,
> https://reviews.freebsd.org/D18578 <https://reviews.freebsd.org/D18578>
>
>
> To recap the discussion
>     * First attempt of RFC in March of 2018: https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.html <https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.html>
>     * Working group at BSDCan: https://wiki.freebsd.org/DevSummit/201806/OpenRC <https://wiki.freebsd.org/DevSummit/201806/OpenRC>
>
> Here some key points:
>
> OpenRC provides additional features for service management without requiring kernel changes or replacing pid 1, unlike launchd and other solutions.  All rc.d scripts have been converted with a few changes, typically changing the shebang and making sure the start function is named start(). Most service scripts are simplified, usually needing only name, command, and, if required, depends statements.
>
> History:
> OpenRC started out as an init system by Roy Marples, developed for the Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into Gentoo as baselayout v2, and was then split off as a separate BSD-licensed project. It is under active development, portable, and remains BSD licensed today.
>
> OpenRC and RC:
> Both can coexist and be chosen with a setting in /boot/loader.conf.
>
> OpenRC Features:
>
> Service supervision and service monitoring: any service can be supervised. Supervised services that crash are automatically restarted. The rc-status command shows how many times a service has restarted.
>
> Device hotplug support and event-driven service management: the hotplug feature allows devd to take actions when devices are connected. For example, a USB wifi adapter can create additional network services when attached. The net-online service can, for example, detect when a network connection is restored, and restart ntp.
>
> Network profiles: using stacked runlevels, different profiles can be established for different networking settings. For instance, different profiles can be used for wired or wireless networking, or for differing wireless networks, as well as dependency caching and parallel startup speed up booting.
>
> Interactive mode:
> The boot process can be run interactively for more effective debugging.
>
> OpenRC uses the term “runlevels” to refer to the context in which a script is running. There are only three at present:
> sysinit (the OpenRC system is starting), boot (start base services when the computer is booting), and default (normal execution).
>
> OpenRC, by default, provides a “colorized” text boot, using ANSI color sequences. This can be disabled.
>
> Ports:
> As of July 2017, iXsystems has created OpenRC versions of port service scripts for the entire ports tree. These scripts coexist with the rc.d versions.
>
> License:
> OpenRC is a BSD licensed RC init system written in C. From a user perspective, it is very similar to the FreeBSD rc.d init system, making it easy to use and learn.
>
> Tested: OpenRC has been used as the init system for TrueOS since October 2016.
>
> Ken Moore has an OpenRC vs RC.d comparison which can be found here:
> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf <http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf> <http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf <http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf>>
> I look forward to discuss the features and capabilities of OpenRC.
>
> This is cool technology.
>
> However, what was missing last time was a written plan that could be critiqued for fit with the project's needs. The result of the working group was that this was to be produced, and we'd iterate through it to ease the landing of openrc in the tree. I think there's wide agreement this is cool, and that we'd like tot have both it and rc.d in the tree for a transition period. Absent a plan, though, it's not really possible to say 'go do it' or 'that's insane'.
>
> So maybe start there?
>
> Warner

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

Re: OpenRC on FreeBSD

Warner Losh
In reply to this post by Martin Wilke-9
On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke <[hidden email]> wrote:

> I've opened a review here with a working patch for CURRENT,
> https://reviews.freebsd.org/D18578


Please break this review up into manageable sized chunks. There are too
many things going on all at once.

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

Re: OpenRC on FreeBSD

Warner Losh
In reply to this post by Martin Wilke-9
On Wed, Dec 19, 2018 at 7:57 AM Martin Wilke <[hidden email]> wrote:

> Hi,
>
> The missing bit was actually the flag for switching the rc’s which have
> been resolved.
>

No. The missing bit is an articulated plan. While that minor sub-issue may
be resolved, I see no plan for integration into the tree. Unless the plan
is 'commit the review in one big push' which really isn't a viable plan.
There are problems with the review (it's too large to be successful, and
has issues that need to be discussed in a less massively huge environment).
This isn't what the working group's conclusion would be the next steps. The
FCP I provided feedback on died. It was a good start on a plan, but was
just dropped with my feedback completely ignored.

Warner


> - Martin
>
> On 19 Dec 2018, at 10:51 PM, Warner Losh <[hidden email]> wrote:
>
>
>
> On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke <[hidden email]> wrote:
>
>> Hi
>>
>> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically this
>> is the second attempt to get it into FreeBSD.
>>
>> I've opened a review here with a working patch for CURRENT,
>> https://reviews.freebsd.org/D18578
>>
>>
>> To recap the discussion
>>     * First attempt of RFC in March of 2018:
>> https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.html
>>     * Working group at BSDCan:
>> https://wiki.freebsd.org/DevSummit/201806/OpenRC
>>
>> Here some key points:
>>
>> OpenRC provides additional features for service management without
>> requiring kernel changes or replacing pid 1, unlike launchd and other
>> solutions.  All rc.d scripts have been converted with a few changes,
>> typically changing the shebang and making sure the start function is named
>> start(). Most service scripts are simplified, usually needing only name,
>> command, and, if required, depends statements.
>>
>> History:
>> OpenRC started out as an init system by Roy Marples, developed for the
>> Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into Gentoo
>> as baselayout v2, and was then split off as a separate BSD-licensed
>> project. It is under active development, portable, and remains BSD licensed
>> today.
>>
>> OpenRC and RC:
>> Both can coexist and be chosen with a setting in /boot/loader.conf.
>>
>> OpenRC Features:
>>
>> Service supervision and service monitoring: any service can be
>> supervised. Supervised services that crash are automatically restarted. The
>> rc-status command shows how many times a service has restarted.
>>
>> Device hotplug support and event-driven service management: the hotplug
>> feature allows devd to take actions when devices are connected. For
>> example, a USB wifi adapter can create additional network services when
>> attached. The net-online service can, for example, detect when a network
>> connection is restored, and restart ntp.
>>
>> Network profiles: using stacked runlevels, different profiles can be
>> established for different networking settings. For instance, different
>> profiles can be used for wired or wireless networking, or for differing
>> wireless networks, as well as dependency caching and parallel startup speed
>> up booting.
>>
>> Interactive mode:
>> The boot process can be run interactively for more effective debugging.
>>
>> OpenRC uses the term “runlevels” to refer to the context in which a
>> script is running. There are only three at present:
>> sysinit (the OpenRC system is starting), boot (start base services when
>> the computer is booting), and default (normal execution).
>>
>> OpenRC, by default, provides a “colorized” text boot, using ANSI color
>> sequences. This can be disabled.
>>
>> Ports:
>> As of July 2017, iXsystems has created OpenRC versions of port service
>> scripts for the entire ports tree. These scripts coexist with the rc.d
>> versions.
>>
>> License:
>> OpenRC is a BSD licensed RC init system written in C. From a user
>> perspective, it is very similar to the FreeBSD rc.d init system, making it
>> easy to use and learn.
>>
>> Tested: OpenRC has been used as the init system for TrueOS since October
>> 2016.
>>
>> Ken Moore has an OpenRC vs RC.d comparison which can be found here:
>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf <
>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf>
>> I look forward to discuss the features and capabilities of OpenRC.
>>
>
> This is cool technology.
>
> However, what was missing last time was a written plan that could be
> critiqued for fit with the project's needs. The result of the working group
> was that this was to be produced, and we'd iterate through it to ease the
> landing of openrc in the tree. I think there's wide agreement this is cool,
> and that we'd like tot have both it and rc.d in the tree for a transition
> period. Absent a plan, though, it's not really possible to say 'go do it'
> or 'that's insane'.
>
> So maybe start there?
>
> Warner
>
>
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: OpenRC on FreeBSD

Matthew Seaman-5
In reply to this post by Martin Wilke-9
On 19/12/2018 14:57, Martin Wilke wrote:

> Hi,
>
> The missing bit was actually the flag for switching the rc’s which have been resolved.
>
> - Martin
>
>> On 19 Dec 2018, at 10:51 PM, Warner Losh <[hidden email]> wrote:
>>
>>
>>
>> On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke <[hidden email] <mailto:[hidden email]>> wrote:
>> Hi
>>
>> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically this is the second attempt to get it into FreeBSD.
>>
>> I've opened a review here with a working patch for CURRENT,
>> https://reviews.freebsd.org/D18578 <https://reviews.freebsd.org/D18578>
>>
>>
>> To recap the discussion
>>      * First attempt of RFC in March of 2018: https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.html <https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.html>
>>      * Working group at BSDCan: https://wiki.freebsd.org/DevSummit/201806/OpenRC <https://wiki.freebsd.org/DevSummit/201806/OpenRC>
>>
>> Here some key points:
>>
>> OpenRC provides additional features for service management without requiring kernel changes or replacing pid 1, unlike launchd and other solutions.  All rc.d scripts have been converted with a few changes, typically changing the shebang and making sure the start function is named start(). Most service scripts are simplified, usually needing only name, command, and, if required, depends statements.
>>
>> History:
>> OpenRC started out as an init system by Roy Marples, developed for the Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into Gentoo as baselayout v2, and was then split off as a separate BSD-licensed project. It is under active development, portable, and remains BSD licensed today.
>>
>> OpenRC and RC:
>> Both can coexist and be chosen with a setting in /boot/loader.conf.
>>
>> OpenRC Features:
>>
>> Service supervision and service monitoring: any service can be supervised. Supervised services that crash are automatically restarted. The rc-status command shows how many times a service has restarted.
>>
>> Device hotplug support and event-driven service management: the hotplug feature allows devd to take actions when devices are connected. For example, a USB wifi adapter can create additional network services when attached. The net-online service can, for example, detect when a network connection is restored, and restart ntp.
>>
>> Network profiles: using stacked runlevels, different profiles can be established for different networking settings. For instance, different profiles can be used for wired or wireless networking, or for differing wireless networks, as well as dependency caching and parallel startup speed up booting.
>>
>> Interactive mode:
>> The boot process can be run interactively for more effective debugging.
>>
>> OpenRC uses the term “runlevels” to refer to the context in which a script is running. There are only three at present:
>> sysinit (the OpenRC system is starting), boot (start base services when the computer is booting), and default (normal execution).
>>
>> OpenRC, by default, provides a “colorized” text boot, using ANSI color sequences. This can be disabled.
>>
>> Ports:
>> As of July 2017, iXsystems has created OpenRC versions of port service scripts for the entire ports tree. These scripts coexist with the rc.d versions.
>>
>> License:
>> OpenRC is a BSD licensed RC init system written in C. From a user perspective, it is very similar to the FreeBSD rc.d init system, making it easy to use and learn.
>>
>> Tested: OpenRC has been used as the init system for TrueOS since October 2016.
>>
>> Ken Moore has an OpenRC vs RC.d comparison which can be found here:
>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf <http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf> <http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf <http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf>>
>> I look forward to discuss the features and capabilities of OpenRC.
>>
>> This is cool technology.
>>
>> However, what was missing last time was a written plan that could be critiqued for fit with the project's needs. The result of the working group was that this was to be produced, and we'd iterate through it to ease the landing of openrc in the tree. I think there's wide agreement this is cool, and that we'd like tot have both it and rc.d in the tree for a transition period. Absent a plan, though, it's not really possible to say 'go do it' or 'that's insane'.
>>
>> So maybe start there?
>>
>> Warner

This would mean that we're going to need both OpenRC and rc.d versions
of init scripts in the ports for however long the transition period is.

How do you plan on managing that?  Will port maintainers be expected to
develop and test both flavours of init script?  Not all maintainers will
have ready access to build/test systems running CURRENT if that's where
OpenRC gets deployed initially.

Will both types of init script be added to every pkg, or will there be a
default per major version?  Will this change be MFC'd to 11.x / 12.x ?

Also, isn't this a prime candidate for the FCP treatment?

        Cheers,

        Matthew

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

Re: OpenRC on FreeBSD

Warner Losh
On Wed, Dec 19, 2018 at 8:17 AM Matthew Seaman <[hidden email]> wrote:

> On 19/12/2018 14:57, Martin Wilke wrote:
> > Hi,
> >
> > The missing bit was actually the flag for switching the rc’s which have
> been resolved.
> >
> > - Martin
> >
> >> On 19 Dec 2018, at 10:51 PM, Warner Losh <[hidden email]> wrote:
> >>
> >>
> >>
> >> On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke <[hidden email] <mailto:
> [hidden email]>> wrote:
> >> Hi
> >>
> >> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically this
> is the second attempt to get it into FreeBSD.
> >>
> >> I've opened a review here with a working patch for CURRENT,
> >> https://reviews.freebsd.org/D18578 <https://reviews.freebsd.org/D18578>
> >>
> >>
> >> To recap the discussion
> >>      * First attempt of RFC in March of 2018:
> https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.html
> <
> https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.html
> >
> >>      * Working group at BSDCan:
> https://wiki.freebsd.org/DevSummit/201806/OpenRC <
> https://wiki.freebsd.org/DevSummit/201806/OpenRC>
> >>
> >> Here some key points:
> >>
> >> OpenRC provides additional features for service management without
> requiring kernel changes or replacing pid 1, unlike launchd and other
> solutions.  All rc.d scripts have been converted with a few changes,
> typically changing the shebang and making sure the start function is named
> start(). Most service scripts are simplified, usually needing only name,
> command, and, if required, depends statements.
> >>
> >> History:
> >> OpenRC started out as an init system by Roy Marples, developed for the
> Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into Gentoo
> as baselayout v2, and was then split off as a separate BSD-licensed
> project. It is under active development, portable, and remains BSD licensed
> today.
> >>
> >> OpenRC and RC:
> >> Both can coexist and be chosen with a setting in /boot/loader.conf.
> >>
> >> OpenRC Features:
> >>
> >> Service supervision and service monitoring: any service can be
> supervised. Supervised services that crash are automatically restarted. The
> rc-status command shows how many times a service has restarted.
> >>
> >> Device hotplug support and event-driven service management: the hotplug
> feature allows devd to take actions when devices are connected. For
> example, a USB wifi adapter can create additional network services when
> attached. The net-online service can, for example, detect when a network
> connection is restored, and restart ntp.
> >>
> >> Network profiles: using stacked runlevels, different profiles can be
> established for different networking settings. For instance, different
> profiles can be used for wired or wireless networking, or for differing
> wireless networks, as well as dependency caching and parallel startup speed
> up booting.
> >>
> >> Interactive mode:
> >> The boot process can be run interactively for more effective debugging.
> >>
> >> OpenRC uses the term “runlevels” to refer to the context in which a
> script is running. There are only three at present:
> >> sysinit (the OpenRC system is starting), boot (start base services when
> the computer is booting), and default (normal execution).
> >>
> >> OpenRC, by default, provides a “colorized” text boot, using ANSI color
> sequences. This can be disabled.
> >>
> >> Ports:
> >> As of July 2017, iXsystems has created OpenRC versions of port service
> scripts for the entire ports tree. These scripts coexist with the rc.d
> versions.
> >>
> >> License:
> >> OpenRC is a BSD licensed RC init system written in C. From a user
> perspective, it is very similar to the FreeBSD rc.d init system, making it
> easy to use and learn.
> >>
> >> Tested: OpenRC has been used as the init system for TrueOS since
> October 2016.
> >>
> >> Ken Moore has an OpenRC vs RC.d comparison which can be found here:
> >> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf <
> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf> <
> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf <
> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf>>
> >> I look forward to discuss the features and capabilities of OpenRC.
> >>
> >> This is cool technology.
> >>
> >> However, what was missing last time was a written plan that could be
> critiqued for fit with the project's needs. The result of the working group
> was that this was to be produced, and we'd iterate through it to ease the
> landing of openrc in the tree. I think there's wide agreement this is cool,
> and that we'd like tot have both it and rc.d in the tree for a transition
> period. Absent a plan, though, it's not really possible to say 'go do it'
> or 'that's insane'.
> >>
> >> So maybe start there?
> >>
> >> Warner
>
> This would mean that we're going to need both OpenRC and rc.d versions
> of init scripts in the ports for however long the transition period is.
>
> How do you plan on managing that?  Will port maintainers be expected to
> develop and test both flavours of init script?  Not all maintainers will
> have ready access to build/test systems running CURRENT if that's where
> OpenRC gets deployed initially.
>
> Will both types of init script be added to every pkg, or will there be a
> default per major version?  Will this change be MFC'd to 11.x / 12.x ?
>
> Also, isn't this a prime candidate for the FCP treatment?
>

There was a FCP that started to cover these things. I provided feedback,
and then nothing happened. These are exactly the sorts of details that need
too be covered somewhere, and the FCP is the logical place. It's why I am
asking for there to be a plan. These sorts of policy and logistical details
would be in there, and having an agreement in place up front will ease the
transition as the project's expectations are clearly articulated. It
needn't be perfect, but it has to be something substantially more than the
nothing we have today.

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

Re: OpenRC on FreeBSD

Marcelo Araujo-7
In reply to this post by Warner Losh
Em qua, 19 de dez de 2018 às 23:02, Warner Losh <[hidden email]> escreveu:

>
>
> On Wed, Dec 19, 2018 at 7:57 AM Martin Wilke <[hidden email]> wrote:
>
>> Hi,
>>
>> The missing bit was actually the flag for switching the rc’s which have
>> been resolved.
>>
>
> No. The missing bit is an articulated plan. While that minor sub-issue may
> be resolved, I see no plan for integration into the tree. Unless the plan
> is 'commit the review in one big push' which really isn't a viable plan.
> There are problems with the review (it's too large to be successful, and
> has issues that need to be discussed in a less massively huge environment).
> This isn't what the working group's conclusion would be the next steps. The
> FCP I provided feedback on died. It was a good start on a plan, but was
> just dropped with my feedback completely ignored.
>

Hi Warner,

I have asked miwi@ to keep that huge patch on the review because of the
lack of coordination and discussion between different groups and also
because there is not a clear plan how to bring OpenRC into FreeBSD. So in
that way people could try the patch easily without chasing different open
reviews, and to be honest, without further discussion regarding to how the
transition would happens between rcd and OpenRC, there is nothing much to
review there.

IMHO, if we want to move forward with OpenRC on FreeBSD we would need a
broad discussion, because it will impacts not only the base system but also
ports, and also docs needs to get involved because we eventually would need
to update our documentation. We have people that wants OpenRC also in other
hands we have people that wants to keep things as it is.

NOTE: I have updated the review with the same content of this email just to
make it registered there.

I agree for review purpose small chunks are better, however I don't see yet
a plan for all this migration between rcd and OpenRC.
Best,


>
> Warner
>
>
>> - Martin
>>
>> On 19 Dec 2018, at 10:51 PM, Warner Losh <[hidden email]> wrote:
>>
>>
>>
>> On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke <[hidden email]> wrote:
>>
>>> Hi
>>>
>>> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically this
>>> is the second attempt to get it into FreeBSD.
>>>
>>> I've opened a review here with a working patch for CURRENT,
>>> https://reviews.freebsd.org/D18578
>>>
>>>
>>> To recap the discussion
>>>     * First attempt of RFC in March of 2018:
>>> https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.html
>>>     * Working group at BSDCan:
>>> https://wiki.freebsd.org/DevSummit/201806/OpenRC
>>>
>>> Here some key points:
>>>
>>> OpenRC provides additional features for service management without
>>> requiring kernel changes or replacing pid 1, unlike launchd and other
>>> solutions.  All rc.d scripts have been converted with a few changes,
>>> typically changing the shebang and making sure the start function is named
>>> start(). Most service scripts are simplified, usually needing only name,
>>> command, and, if required, depends statements.
>>>
>>> History:
>>> OpenRC started out as an init system by Roy Marples, developed for the
>>> Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into Gentoo
>>> as baselayout v2, and was then split off as a separate BSD-licensed
>>> project. It is under active development, portable, and remains BSD licensed
>>> today.
>>>
>>> OpenRC and RC:
>>> Both can coexist and be chosen with a setting in /boot/loader.conf.
>>>
>>> OpenRC Features:
>>>
>>> Service supervision and service monitoring: any service can be
>>> supervised. Supervised services that crash are automatically restarted. The
>>> rc-status command shows how many times a service has restarted.
>>>
>>> Device hotplug support and event-driven service management: the hotplug
>>> feature allows devd to take actions when devices are connected. For
>>> example, a USB wifi adapter can create additional network services when
>>> attached. The net-online service can, for example, detect when a network
>>> connection is restored, and restart ntp.
>>>
>>> Network profiles: using stacked runlevels, different profiles can be
>>> established for different networking settings. For instance, different
>>> profiles can be used for wired or wireless networking, or for differing
>>> wireless networks, as well as dependency caching and parallel startup speed
>>> up booting.
>>>
>>> Interactive mode:
>>> The boot process can be run interactively for more effective debugging.
>>>
>>> OpenRC uses the term “runlevels” to refer to the context in which a
>>> script is running. There are only three at present:
>>> sysinit (the OpenRC system is starting), boot (start base services when
>>> the computer is booting), and default (normal execution).
>>>
>>> OpenRC, by default, provides a “colorized” text boot, using ANSI color
>>> sequences. This can be disabled.
>>>
>>> Ports:
>>> As of July 2017, iXsystems has created OpenRC versions of port service
>>> scripts for the entire ports tree. These scripts coexist with the rc.d
>>> versions.
>>>
>>> License:
>>> OpenRC is a BSD licensed RC init system written in C. From a user
>>> perspective, it is very similar to the FreeBSD rc.d init system, making it
>>> easy to use and learn.
>>>
>>> Tested: OpenRC has been used as the init system for TrueOS since October
>>> 2016.
>>>
>>> Ken Moore has an OpenRC vs RC.d comparison which can be found here:
>>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf <
>>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf>
>>> I look forward to discuss the features and capabilities of OpenRC.
>>>
>>
>> This is cool technology.
>>
>> However, what was missing last time was a written plan that could be
>> critiqued for fit with the project's needs. The result of the working group
>> was that this was to be produced, and we'd iterate through it to ease the
>> landing of openrc in the tree. I think there's wide agreement this is cool,
>> and that we'd like tot have both it and rc.d in the tree for a transition
>> period. Absent a plan, though, it's not really possible to say 'go do it'
>> or 'that's insane'.
>>
>> So maybe start there?
>>
>> Warner
>>
>>
>>

--

--
Marcelo Araujo            (__)[hidden email]
\\\'',)http://www.FreeBSD.org <http://www.freebsd.org/>   \/  \ ^
Power To Server.         .\. /_)
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: OpenRC on FreeBSD

Matt Joras-2
On Wed, Dec 19, 2018, 9:49 AM Marcelo Araujo <[hidden email] wrote:

> Em qua, 19 de dez de 2018 às 23:02, Warner Losh <[hidden email]> escreveu:
>
> >
> >
> > On Wed, Dec 19, 2018 at 7:57 AM Martin Wilke <[hidden email]> wrote:
> >
> >> Hi,
> >>
> >> The missing bit was actually the flag for switching the rc’s which have
> >> been resolved.
> >>
> >
> > No. The missing bit is an articulated plan. While that minor sub-issue
> may
> > be resolved, I see no plan for integration into the tree. Unless the plan
> > is 'commit the review in one big push' which really isn't a viable plan.
> > There are problems with the review (it's too large to be successful, and
> > has issues that need to be discussed in a less massively huge
> environment).
> > This isn't what the working group's conclusion would be the next steps.
> The
> > FCP I provided feedback on died. It was a good start on a plan, but was
> > just dropped with my feedback completely ignored.
> >
>
> Hi Warner,
>
> I have asked miwi@ to keep that huge patch on the review because of the
> lack of coordination and discussion between different groups and also
> because there is not a clear plan how to bring OpenRC into FreeBSD. So in
> that way people could try the patch easily without chasing different open
> reviews, and to be honest, without further discussion regarding to how the
> transition would happens between rcd and OpenRC, there is nothing much to
> review there.
>

Just making a small suggestion here, does our Phabricator support "stacked"
diffs? That is the defacto way for a group of diffs on Phabricator to be
logically grouped so they are easy to navigate and review separately.


> IMHO, if we want to move forward with OpenRC on FreeBSD we would need a
> broad discussion, because it will impacts not only the base system but also
> ports, and also docs needs to get involved because we eventually would need
> to update our documentation. We have people that wants OpenRC also in other
> hands we have people that wants to keep things as it is.
>
> NOTE: I have updated the review with the same content of this email just to
> make it registered there.
>
> I agree for review purpose small chunks are better, however I don't see yet
> a plan for all this migration between rcd and OpenRC.
> Best,
>
>
> >
> > Warner
> >
> >
> >> - Martin
> >>
> >> On 19 Dec 2018, at 10:51 PM, Warner Losh <[hidden email]> wrote:
> >>
> >>
> >>
> >> On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke <[hidden email]> wrote:
> >>
> >>> Hi
> >>>
> >>> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically this
> >>> is the second attempt to get it into FreeBSD.
> >>>
> >>> I've opened a review here with a working patch for CURRENT,
> >>> https://reviews.freebsd.org/D18578
> >>>
> >>>
> >>> To recap the discussion
> >>>     * First attempt of RFC in March of 2018:
> >>>
> https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.html
> >>>     * Working group at BSDCan:
> >>> https://wiki.freebsd.org/DevSummit/201806/OpenRC
> >>>
> >>> Here some key points:
> >>>
> >>> OpenRC provides additional features for service management without
> >>> requiring kernel changes or replacing pid 1, unlike launchd and other
> >>> solutions.  All rc.d scripts have been converted with a few changes,
> >>> typically changing the shebang and making sure the start function is
> named
> >>> start(). Most service scripts are simplified, usually needing only
> name,
> >>> command, and, if required, depends statements.
> >>>
> >>> History:
> >>> OpenRC started out as an init system by Roy Marples, developed for the
> >>> Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into
> Gentoo
> >>> as baselayout v2, and was then split off as a separate BSD-licensed
> >>> project. It is under active development, portable, and remains BSD
> licensed
> >>> today.
> >>>
> >>> OpenRC and RC:
> >>> Both can coexist and be chosen with a setting in /boot/loader.conf.
> >>>
> >>> OpenRC Features:
> >>>
> >>> Service supervision and service monitoring: any service can be
> >>> supervised. Supervised services that crash are automatically
> restarted. The
> >>> rc-status command shows how many times a service has restarted.
> >>>
> >>> Device hotplug support and event-driven service management: the hotplug
> >>> feature allows devd to take actions when devices are connected. For
> >>> example, a USB wifi adapter can create additional network services when
> >>> attached. The net-online service can, for example, detect when a
> network
> >>> connection is restored, and restart ntp.
> >>>
> >>> Network profiles: using stacked runlevels, different profiles can be
> >>> established for different networking settings. For instance, different
> >>> profiles can be used for wired or wireless networking, or for differing
> >>> wireless networks, as well as dependency caching and parallel startup
> speed
> >>> up booting.
> >>>
> >>> Interactive mode:
> >>> The boot process can be run interactively for more effective debugging.
> >>>
> >>> OpenRC uses the term “runlevels” to refer to the context in which a
> >>> script is running. There are only three at present:
> >>> sysinit (the OpenRC system is starting), boot (start base services when
> >>> the computer is booting), and default (normal execution).
> >>>
> >>> OpenRC, by default, provides a “colorized” text boot, using ANSI color
> >>> sequences. This can be disabled.
> >>>
> >>> Ports:
> >>> As of July 2017, iXsystems has created OpenRC versions of port service
> >>> scripts for the entire ports tree. These scripts coexist with the rc.d
> >>> versions.
> >>>
> >>> License:
> >>> OpenRC is a BSD licensed RC init system written in C. From a user
> >>> perspective, it is very similar to the FreeBSD rc.d init system,
> making it
> >>> easy to use and learn.
> >>>
> >>> Tested: OpenRC has been used as the init system for TrueOS since
> October
> >>> 2016.
> >>>
> >>> Ken Moore has an OpenRC vs RC.d comparison which can be found here:
> >>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf <
> >>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf>
> >>> I look forward to discuss the features and capabilities of OpenRC.
> >>>
> >>
> >> This is cool technology.
> >>
> >> However, what was missing last time was a written plan that could be
> >> critiqued for fit with the project's needs. The result of the working
> group
> >> was that this was to be produced, and we'd iterate through it to ease
> the
> >> landing of openrc in the tree. I think there's wide agreement this is
> cool,
> >> and that we'd like tot have both it and rc.d in the tree for a
> transition
> >> period. Absent a plan, though, it's not really possible to say 'go do
> it'
> >> or 'that's insane'.
> >>
> >> So maybe start there?
> >>
> >> Warner
> >>
> >>
> >>
>
> --
>
> --
> Marcelo Araujo            (__)[hidden email]
> \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/>   \/  \ ^
> Power To Server.         .\. /_)
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: OpenRC on FreeBSD

Warner Losh
In reply to this post by Marcelo Araujo-7
On Wed, Dec 19, 2018 at 8:48 AM Marcelo Araujo <[hidden email]>
wrote:

>
>
> Em qua, 19 de dez de 2018 às 23:02, Warner Losh <[hidden email]> escreveu:
>
>>
>>
>> On Wed, Dec 19, 2018 at 7:57 AM Martin Wilke <[hidden email]> wrote:
>>
>>> Hi,
>>>
>>> The missing bit was actually the flag for switching the rc’s which have
>>> been resolved.
>>>
>>
>> No. The missing bit is an articulated plan. While that minor sub-issue
>> may be resolved, I see no plan for integration into the tree. Unless the
>> plan is 'commit the review in one big push' which really isn't a viable
>> plan. There are problems with the review (it's too large to be successful,
>> and has issues that need to be discussed in a less massively huge
>> environment). This isn't what the working group's conclusion would be the
>> next steps. The FCP I provided feedback on died. It was a good start on a
>> plan, but was just dropped with my feedback completely ignored.
>>
>
> Hi Warner,
>
> I have asked miwi@ to keep that huge patch on the review because of the
> lack of coordination and discussion between different groups and also
> because there is not a clear plan how to bring OpenRC into FreeBSD. So in
> that way people could try the patch easily without chasing different open
> reviews, and to be honest, without further discussion regarding to how the
> transition would happens between rcd and OpenRC, there is nothing much to
> review there.
>
> IMHO, if we want to move forward with OpenRC on FreeBSD we would need a
> broad discussion, because it will impacts not only the base system but also
> ports, and also docs needs to get involved because we eventually would need
> to update our documentation. We have people that wants OpenRC also in other
> hands we have people that wants to keep things as it is.
>
> NOTE: I have updated the review with the same content of this email just
> to make it registered there.
>
> I agree for review purpose small chunks are better, however I don't see
> yet a plan for all this migration between rcd and OpenRC.
>

Reviews aren't patch delivery devices. They are to review the code present.
You can't do that with the super-monster review that's there. If you want
to have one patch file, that's great! You can always link each review to
that patch file or have a dummy master review to do that. Reviews this
large in the past have failed to reach consensus and frustrated the
authors. I'd kinda like to avoid that outcome here because I really want to
see forward progress here. Maybe once we've hashed out the plan on
integration, we can move to breaking up the patch into manageable pieces.

So what's my next step for saying that the verbatim copy of devd.conf into
devd-openrc.conf is not going to work, that problem needs to be solved
properly without such copying. Eg, moving the openrc dependency out of
devd.conf and into pccard-ether or its replacement to hide this detail.  I
don't know if this is emblematic of a poor design, or just a sloppy
short-cut.

Warner


> Best,
>
>
>>
>> Warner
>>
>>
>>> - Martin
>>>
>>> On 19 Dec 2018, at 10:51 PM, Warner Losh <[hidden email]> wrote:
>>>
>>>
>>>
>>> On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke <[hidden email]> wrote:
>>>
>>>> Hi
>>>>
>>>> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically this
>>>> is the second attempt to get it into FreeBSD.
>>>>
>>>> I've opened a review here with a working patch for CURRENT,
>>>> https://reviews.freebsd.org/D18578
>>>>
>>>>
>>>> To recap the discussion
>>>>     * First attempt of RFC in March of 2018:
>>>> https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.html
>>>>     * Working group at BSDCan:
>>>> https://wiki.freebsd.org/DevSummit/201806/OpenRC
>>>>
>>>> Here some key points:
>>>>
>>>> OpenRC provides additional features for service management without
>>>> requiring kernel changes or replacing pid 1, unlike launchd and other
>>>> solutions.  All rc.d scripts have been converted with a few changes,
>>>> typically changing the shebang and making sure the start function is named
>>>> start(). Most service scripts are simplified, usually needing only name,
>>>> command, and, if required, depends statements.
>>>>
>>>> History:
>>>> OpenRC started out as an init system by Roy Marples, developed for the
>>>> Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into Gentoo
>>>> as baselayout v2, and was then split off as a separate BSD-licensed
>>>> project. It is under active development, portable, and remains BSD licensed
>>>> today.
>>>>
>>>> OpenRC and RC:
>>>> Both can coexist and be chosen with a setting in /boot/loader.conf.
>>>>
>>>> OpenRC Features:
>>>>
>>>> Service supervision and service monitoring: any service can be
>>>> supervised. Supervised services that crash are automatically restarted. The
>>>> rc-status command shows how many times a service has restarted.
>>>>
>>>> Device hotplug support and event-driven service management: the hotplug
>>>> feature allows devd to take actions when devices are connected. For
>>>> example, a USB wifi adapter can create additional network services when
>>>> attached. The net-online service can, for example, detect when a network
>>>> connection is restored, and restart ntp.
>>>>
>>>> Network profiles: using stacked runlevels, different profiles can be
>>>> established for different networking settings. For instance, different
>>>> profiles can be used for wired or wireless networking, or for differing
>>>> wireless networks, as well as dependency caching and parallel startup speed
>>>> up booting.
>>>>
>>>> Interactive mode:
>>>> The boot process can be run interactively for more effective debugging.
>>>>
>>>> OpenRC uses the term “runlevels” to refer to the context in which a
>>>> script is running. There are only three at present:
>>>> sysinit (the OpenRC system is starting), boot (start base services when
>>>> the computer is booting), and default (normal execution).
>>>>
>>>> OpenRC, by default, provides a “colorized” text boot, using ANSI color
>>>> sequences. This can be disabled.
>>>>
>>>> Ports:
>>>> As of July 2017, iXsystems has created OpenRC versions of port service
>>>> scripts for the entire ports tree. These scripts coexist with the rc.d
>>>> versions.
>>>>
>>>> License:
>>>> OpenRC is a BSD licensed RC init system written in C. From a user
>>>> perspective, it is very similar to the FreeBSD rc.d init system, making it
>>>> easy to use and learn.
>>>>
>>>> Tested: OpenRC has been used as the init system for TrueOS since
>>>> October 2016.
>>>>
>>>> Ken Moore has an OpenRC vs RC.d comparison which can be found here:
>>>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf <
>>>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf>
>>>> I look forward to discuss the features and capabilities of OpenRC.
>>>>
>>>
>>> This is cool technology.
>>>
>>> However, what was missing last time was a written plan that could be
>>> critiqued for fit with the project's needs. The result of the working group
>>> was that this was to be produced, and we'd iterate through it to ease the
>>> landing of openrc in the tree. I think there's wide agreement this is cool,
>>> and that we'd like tot have both it and rc.d in the tree for a transition
>>> period. Absent a plan, though, it's not really possible to say 'go do it'
>>> or 'that's insane'.
>>>
>>> So maybe start there?
>>>
>>> Warner
>>>
>>>
>>>
>
> --
>
> --
> Marcelo Araujo            (__)[hidden email]     \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/>   \/  \ ^
> Power To Server.         .\. /_)
>
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: OpenRC on FreeBSD

Marcelo Araujo-7
In reply to this post by Matt Joras-2
Em qua, 19 de dez de 2018 às 23:55, Matt Joras <[hidden email]>
escreveu:

>
>
> On Wed, Dec 19, 2018, 9:49 AM Marcelo Araujo <[hidden email]
> wrote:
>
>> Em qua, 19 de dez de 2018 às 23:02, Warner Losh <[hidden email]>
>> escreveu:
>>
>> >
>> >
>> > On Wed, Dec 19, 2018 at 7:57 AM Martin Wilke <[hidden email]> wrote:
>> >
>> >> Hi,
>> >>
>> >> The missing bit was actually the flag for switching the rc’s which have
>> >> been resolved.
>> >>
>> >
>> > No. The missing bit is an articulated plan. While that minor sub-issue
>> may
>> > be resolved, I see no plan for integration into the tree. Unless the
>> plan
>> > is 'commit the review in one big push' which really isn't a viable plan.
>> > There are problems with the review (it's too large to be successful, and
>> > has issues that need to be discussed in a less massively huge
>> environment).
>> > This isn't what the working group's conclusion would be the next steps.
>> The
>> > FCP I provided feedback on died. It was a good start on a plan, but was
>> > just dropped with my feedback completely ignored.
>> >
>>
>> Hi Warner,
>>
>> I have asked miwi@ to keep that huge patch on the review because of the
>> lack of coordination and discussion between different groups and also
>> because there is not a clear plan how to bring OpenRC into FreeBSD. So in
>> that way people could try the patch easily without chasing different open
>> reviews, and to be honest, without further discussion regarding to how the
>> transition would happens between rcd and OpenRC, there is nothing much to
>> review there.
>>
>
> Just making a small suggestion here, does our Phabricator support
> "stacked" diffs? That is the defacto way for a group of diffs on
> Phabricator to be logically grouped so they are easy to navigate and review
> separately.
>

It does support Parent and Child reviews.


>
>
>> IMHO, if we want to move forward with OpenRC on FreeBSD we would need a
>> broad discussion, because it will impacts not only the base system but
>> also
>> ports, and also docs needs to get involved because we eventually would
>> need
>> to update our documentation. We have people that wants OpenRC also in
>> other
>> hands we have people that wants to keep things as it is.
>>
>> NOTE: I have updated the review with the same content of this email just
>> to
>> make it registered there.
>>
>> I agree for review purpose small chunks are better, however I don't see
>> yet
>> a plan for all this migration between rcd and OpenRC.
>> Best,
>>
>>
>> >
>> > Warner
>> >
>> >
>> >> - Martin
>> >>
>> >> On 19 Dec 2018, at 10:51 PM, Warner Losh <[hidden email]> wrote:
>> >>
>> >>
>> >>
>> >> On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke <[hidden email]> wrote:
>> >>
>> >>> Hi
>> >>>
>> >>> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically
>> this
>> >>> is the second attempt to get it into FreeBSD.
>> >>>
>> >>> I've opened a review here with a working patch for CURRENT,
>> >>> https://reviews.freebsd.org/D18578
>> >>>
>> >>>
>> >>> To recap the discussion
>> >>>     * First attempt of RFC in March of 2018:
>> >>>
>> https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.html
>> >>>     * Working group at BSDCan:
>> >>> https://wiki.freebsd.org/DevSummit/201806/OpenRC
>> >>>
>> >>> Here some key points:
>> >>>
>> >>> OpenRC provides additional features for service management without
>> >>> requiring kernel changes or replacing pid 1, unlike launchd and other
>> >>> solutions.  All rc.d scripts have been converted with a few changes,
>> >>> typically changing the shebang and making sure the start function is
>> named
>> >>> start(). Most service scripts are simplified, usually needing only
>> name,
>> >>> command, and, if required, depends statements.
>> >>>
>> >>> History:
>> >>> OpenRC started out as an init system by Roy Marples, developed for the
>> >>> Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into
>> Gentoo
>> >>> as baselayout v2, and was then split off as a separate BSD-licensed
>> >>> project. It is under active development, portable, and remains BSD
>> licensed
>> >>> today.
>> >>>
>> >>> OpenRC and RC:
>> >>> Both can coexist and be chosen with a setting in /boot/loader.conf.
>> >>>
>> >>> OpenRC Features:
>> >>>
>> >>> Service supervision and service monitoring: any service can be
>> >>> supervised. Supervised services that crash are automatically
>> restarted. The
>> >>> rc-status command shows how many times a service has restarted.
>> >>>
>> >>> Device hotplug support and event-driven service management: the
>> hotplug
>> >>> feature allows devd to take actions when devices are connected. For
>> >>> example, a USB wifi adapter can create additional network services
>> when
>> >>> attached. The net-online service can, for example, detect when a
>> network
>> >>> connection is restored, and restart ntp.
>> >>>
>> >>> Network profiles: using stacked runlevels, different profiles can be
>> >>> established for different networking settings. For instance, different
>> >>> profiles can be used for wired or wireless networking, or for
>> differing
>> >>> wireless networks, as well as dependency caching and parallel startup
>> speed
>> >>> up booting.
>> >>>
>> >>> Interactive mode:
>> >>> The boot process can be run interactively for more effective
>> debugging.
>> >>>
>> >>> OpenRC uses the term “runlevels” to refer to the context in which a
>> >>> script is running. There are only three at present:
>> >>> sysinit (the OpenRC system is starting), boot (start base services
>> when
>> >>> the computer is booting), and default (normal execution).
>> >>>
>> >>> OpenRC, by default, provides a “colorized” text boot, using ANSI color
>> >>> sequences. This can be disabled.
>> >>>
>> >>> Ports:
>> >>> As of July 2017, iXsystems has created OpenRC versions of port service
>> >>> scripts for the entire ports tree. These scripts coexist with the rc.d
>> >>> versions.
>> >>>
>> >>> License:
>> >>> OpenRC is a BSD licensed RC init system written in C. From a user
>> >>> perspective, it is very similar to the FreeBSD rc.d init system,
>> making it
>> >>> easy to use and learn.
>> >>>
>> >>> Tested: OpenRC has been used as the init system for TrueOS since
>> October
>> >>> 2016.
>> >>>
>> >>> Ken Moore has an OpenRC vs RC.d comparison which can be found here:
>> >>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf <
>> >>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf>
>> >>> I look forward to discuss the features and capabilities of OpenRC.
>> >>>
>> >>
>> >> This is cool technology.
>> >>
>> >> However, what was missing last time was a written plan that could be
>> >> critiqued for fit with the project's needs. The result of the working
>> group
>> >> was that this was to be produced, and we'd iterate through it to ease
>> the
>> >> landing of openrc in the tree. I think there's wide agreement this is
>> cool,
>> >> and that we'd like tot have both it and rc.d in the tree for a
>> transition
>> >> period. Absent a plan, though, it's not really possible to say 'go do
>> it'
>> >> or 'that's insane'.
>> >>
>> >> So maybe start there?
>> >>
>> >> Warner
>> >>
>> >>
>> >>
>>
>> --
>>
>> --
>> Marcelo Araujo            (__)[hidden email]
>> \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/>   \/  \ ^
>> Power To Server.         .\. /_)
>> _______________________________________________
>> [hidden email] mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "[hidden email]
>> "
>>
>

--

--
Marcelo Araujo            (__)[hidden email]
\\\'',)http://www.FreeBSD.org <http://www.freebsd.org/>   \/  \ ^
Power To Server.         .\. /_)
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: OpenRC on FreeBSD

Marcelo Araujo-7
In reply to this post by Warner Losh
Em qua, 19 de dez de 2018 às 23:58, Warner Losh <[hidden email]> escreveu:

>
>
> On Wed, Dec 19, 2018 at 8:48 AM Marcelo Araujo <[hidden email]>
> wrote:
>
>>
>>
>> Em qua, 19 de dez de 2018 às 23:02, Warner Losh <[hidden email]>
>> escreveu:
>>
>>>
>>>
>>> On Wed, Dec 19, 2018 at 7:57 AM Martin Wilke <[hidden email]> wrote:
>>>
>>>> Hi,
>>>>
>>>> The missing bit was actually the flag for switching the rc’s which have
>>>> been resolved.
>>>>
>>>
>>> No. The missing bit is an articulated plan. While that minor sub-issue
>>> may be resolved, I see no plan for integration into the tree. Unless the
>>> plan is 'commit the review in one big push' which really isn't a viable
>>> plan. There are problems with the review (it's too large to be successful,
>>> and has issues that need to be discussed in a less massively huge
>>> environment). This isn't what the working group's conclusion would be the
>>> next steps. The FCP I provided feedback on died. It was a good start on a
>>> plan, but was just dropped with my feedback completely ignored.
>>>
>>
>> Hi Warner,
>>
>> I have asked miwi@ to keep that huge patch on the review because of the
>> lack of coordination and discussion between different groups and also
>> because there is not a clear plan how to bring OpenRC into FreeBSD. So in
>> that way people could try the patch easily without chasing different open
>> reviews, and to be honest, without further discussion regarding to how the
>> transition would happens between rcd and OpenRC, there is nothing much to
>> review there.
>>
>> IMHO, if we want to move forward with OpenRC on FreeBSD we would need a
>> broad discussion, because it will impacts not only the base system but also
>> ports, and also docs needs to get involved because we eventually would need
>> to update our documentation. We have people that wants OpenRC also in other
>> hands we have people that wants to keep things as it is.
>>
>> NOTE: I have updated the review with the same content of this email just
>> to make it registered there.
>>
>> I agree for review purpose small chunks are better, however I don't see
>> yet a plan for all this migration between rcd and OpenRC.
>>
>
> Reviews aren't patch delivery devices. They are to review the code
> present. You can't do that with the super-monster review that's there. If
> you want to have one patch file, that's great! You can always link each
> review to that patch file or have a dummy master review to do that. Reviews
> this large in the past have failed to reach consensus and frustrated the
> authors. I'd kinda like to avoid that outcome here because I really want to
> see forward progress here. Maybe once we've hashed out the plan on
> integration, we can move to breaking up the patch into manageable pieces.
>

Agree with that, as soon as there is a plan on integration, breaking up the
patch will be easier for review! But without a plan, as I said, there is
nothing to review to be honest. :(


>
> So what's my next step for saying that the verbatim copy of devd.conf into
> devd-openrc.conf is not going to work, that problem needs to be solved
> properly without such copying. Eg, moving the openrc dependency out of
> devd.conf and into pccard-ether or its replacement to hide this detail.  I
> don't know if this is emblematic of a poor design, or just a sloppy
> short-cut.
>
> Warner
>
>
>> Best,
>>
>>
>>>
>>> Warner
>>>
>>>
>>>> - Martin
>>>>
>>>> On 19 Dec 2018, at 10:51 PM, Warner Losh <[hidden email]> wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke <[hidden email]> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically
>>>>> this is the second attempt to get it into FreeBSD.
>>>>>
>>>>> I've opened a review here with a working patch for CURRENT,
>>>>> https://reviews.freebsd.org/D18578
>>>>>
>>>>>
>>>>> To recap the discussion
>>>>>     * First attempt of RFC in March of 2018:
>>>>> https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.html
>>>>>     * Working group at BSDCan:
>>>>> https://wiki.freebsd.org/DevSummit/201806/OpenRC
>>>>>
>>>>> Here some key points:
>>>>>
>>>>> OpenRC provides additional features for service management without
>>>>> requiring kernel changes or replacing pid 1, unlike launchd and other
>>>>> solutions.  All rc.d scripts have been converted with a few changes,
>>>>> typically changing the shebang and making sure the start function is named
>>>>> start(). Most service scripts are simplified, usually needing only name,
>>>>> command, and, if required, depends statements.
>>>>>
>>>>> History:
>>>>> OpenRC started out as an init system by Roy Marples, developed for the
>>>>> Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into Gentoo
>>>>> as baselayout v2, and was then split off as a separate BSD-licensed
>>>>> project. It is under active development, portable, and remains BSD licensed
>>>>> today.
>>>>>
>>>>> OpenRC and RC:
>>>>> Both can coexist and be chosen with a setting in /boot/loader.conf.
>>>>>
>>>>> OpenRC Features:
>>>>>
>>>>> Service supervision and service monitoring: any service can be
>>>>> supervised. Supervised services that crash are automatically restarted. The
>>>>> rc-status command shows how many times a service has restarted.
>>>>>
>>>>> Device hotplug support and event-driven service management: the
>>>>> hotplug feature allows devd to take actions when devices are connected. For
>>>>> example, a USB wifi adapter can create additional network services when
>>>>> attached. The net-online service can, for example, detect when a network
>>>>> connection is restored, and restart ntp.
>>>>>
>>>>> Network profiles: using stacked runlevels, different profiles can be
>>>>> established for different networking settings. For instance, different
>>>>> profiles can be used for wired or wireless networking, or for differing
>>>>> wireless networks, as well as dependency caching and parallel startup speed
>>>>> up booting.
>>>>>
>>>>> Interactive mode:
>>>>> The boot process can be run interactively for more effective debugging.
>>>>>
>>>>> OpenRC uses the term “runlevels” to refer to the context in which a
>>>>> script is running. There are only three at present:
>>>>> sysinit (the OpenRC system is starting), boot (start base services
>>>>> when the computer is booting), and default (normal execution).
>>>>>
>>>>> OpenRC, by default, provides a “colorized” text boot, using ANSI color
>>>>> sequences. This can be disabled.
>>>>>
>>>>> Ports:
>>>>> As of July 2017, iXsystems has created OpenRC versions of port service
>>>>> scripts for the entire ports tree. These scripts coexist with the rc.d
>>>>> versions.
>>>>>
>>>>> License:
>>>>> OpenRC is a BSD licensed RC init system written in C. From a user
>>>>> perspective, it is very similar to the FreeBSD rc.d init system, making it
>>>>> easy to use and learn.
>>>>>
>>>>> Tested: OpenRC has been used as the init system for TrueOS since
>>>>> October 2016.
>>>>>
>>>>> Ken Moore has an OpenRC vs RC.d comparison which can be found here:
>>>>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf <
>>>>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf>
>>>>> I look forward to discuss the features and capabilities of OpenRC.
>>>>>
>>>>
>>>> This is cool technology.
>>>>
>>>> However, what was missing last time was a written plan that could be
>>>> critiqued for fit with the project's needs. The result of the working group
>>>> was that this was to be produced, and we'd iterate through it to ease the
>>>> landing of openrc in the tree. I think there's wide agreement this is cool,
>>>> and that we'd like tot have both it and rc.d in the tree for a transition
>>>> period. Absent a plan, though, it's not really possible to say 'go do it'
>>>> or 'that's insane'.
>>>>
>>>> So maybe start there?
>>>>
>>>> Warner
>>>>
>>>>
>>>>
>>
>> --
>>
>> --
>> Marcelo Araujo            (__)[hidden email]     \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/>   \/  \ ^
>> Power To Server.         .\. /_)
>>
>>

--

--
Marcelo Araujo            (__)[hidden email]
\\\'',)http://www.FreeBSD.org <http://www.freebsd.org/>   \/  \ ^
Power To Server.         .\. /_)
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: OpenRC on FreeBSD

D. Ebdrup
In reply to this post by Martin Wilke-9
On 12/19/18, Martin Wilke <[hidden email]> wrote:

> Hi
>
> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically this is
> the second attempt to get it into FreeBSD.
>
> I've opened a review here with a working patch for CURRENT,
> https://reviews.freebsd.org/D18578
>
>
> To recap the discussion
>     * First attempt of RFC in March of 2018:
> https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358.html
>     * Working group at BSDCan:
> https://wiki.freebsd.org/DevSummit/201806/OpenRC
>
> Here some key points:
>
> OpenRC provides additional features for service management without requiring
> kernel changes or replacing pid 1, unlike launchd and other solutions.  All
> rc.d scripts have been converted with a few changes, typically changing the
> shebang and making sure the start function is named start(). Most service
> scripts are simplified, usually needing only name, command, and, if
> required, depends statements.
>
> History:
> OpenRC started out as an init system by Roy Marples, developed for the
> Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into Gentoo
> as baselayout v2, and was then split off as a separate BSD-licensed project.
> It is under active development, portable, and remains BSD licensed today.
>
> OpenRC and RC:
> Both can coexist and be chosen with a setting in /boot/loader.conf.
>
> OpenRC Features:
>
> Service supervision and service monitoring: any service can be supervised.
> Supervised services that crash are automatically restarted. The rc-status
> command shows how many times a service has restarted.
>
> Device hotplug support and event-driven service management: the hotplug
> feature allows devd to take actions when devices are connected. For example,
> a USB wifi adapter can create additional network services when attached. The
> net-online service can, for example, detect when a network connection is
> restored, and restart ntp.
>
> Network profiles: using stacked runlevels, different profiles can be
> established for different networking settings. For instance, different
> profiles can be used for wired or wireless networking, or for differing
> wireless networks, as well as dependency caching and parallel startup speed
> up booting.
>
> Interactive mode:
> The boot process can be run interactively for more effective debugging.
>
> OpenRC uses the term “runlevels” to refer to the context in which a script
> is running. There are only three at present:
> sysinit (the OpenRC system is starting), boot (start base services when the
> computer is booting), and default (normal execution).
>
> OpenRC, by default, provides a “colorized” text boot, using ANSI color
> sequences. This can be disabled.
>
> Ports:
> As of July 2017, iXsystems has created OpenRC versions of port service
> scripts for the entire ports tree. These scripts coexist with the rc.d
> versions.
>
> License:
> OpenRC is a BSD licensed RC init system written in C. From a user
> perspective, it is very similar to the FreeBSD rc.d init system, making it
> easy to use and learn.
>
> Tested: OpenRC has been used as the init system for TrueOS since October
> 2016.
>
> Ken Moore has an OpenRC vs RC.d comparison which can be found here:
> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf
> <http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf>
> I look forward to discuss the features and capabilities of OpenRC.
>
> Regards,
> Martin
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
>

You mention parallel service startup as an advantage of OpenRC, but to
the best of my knowledge it is turned off by default everywhere, and
there's no actual guarentee that parallel service startup won't
randomly break.

Indeed, there are two outstanding bugs for this very issue, [1] has
been open/connfirmed since 2011 and [2] has been open/with nobody
assigned since 2014 - neither of them seem to be fixed, from what I
can tell?

It seems to me that if this is indeed a feature that people want (and
I can see why, if you're starting a few hundred jails with only few
inter-dependencies) - but I feel sure that people won't want it if it
means that the system will no longer boot reliably.

So what I'm really asking for, rather than not enabling parallel
startup by default (despite this being what most projects apppear to
have done), can the problem be fixed before OpenRC is in FreeBSD, such
that FreeBSD can have parallel startup that reliably works?

I wish I had the talent to contribute in any meaningful way, but I'm
just a sysadmin and as a coder I'm a pretty poor florist.

[1]: https://bugs.gentoo.org/391945
[2]: https://github.com/OpenRC/openrc/pull/12
--
Daniel Ebdrup aka. D. Ebdrup.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: OpenRC on FreeBSD

Shawn Webb-3
In reply to this post by Martin Wilke-9
On Wed, Dec 19, 2018 at 10:36:04PM +0800, Martin Wilke wrote:
> Service supervision and service monitoring: any service can be supervised. Supervised services that crash are automatically restarted. The rc-status command shows how many times a service has restarted.

Can automatic restart be globally disabled? Automatic restart can
cause security issues, especially in operating systems without
modern exploit mitigations.

Thanks,

--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:    +1 443-546-8752
Tor+XMPP+OTR:        [hidden email]
GPG Key ID:          0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE

signature.asc (849 bytes) Download Attachment