Re: [gentoo-dev] rfc: OpenRC network provides revisited

2012-08-27 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/08/12 04:16 PM, William Hubbs wrote: > > The bottom line here is: I don't think all of the services we have > set up to "need net" in their default configuration should be set > up that way. It would make OpenRC work out of the box for many >

Re: [gentoo-dev] rfc: OpenRC network provides revisited

2012-08-25 Thread William Hubbs
On Sat, Aug 25, 2012 at 02:49:39PM -0400, Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 25/08/12 11:53 AM, William Hubbs wrote: > > On Sat, Aug 25, 2012 at 03:19:24PM +0900, hero...@gentoo.org > > wrote: > >> If we set rc_provide="net" in rc.conf, the services

Re: [gentoo-dev] rfc: OpenRC network provides revisited

2012-08-25 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/08/12 11:53 AM, William Hubbs wrote: > On Sat, Aug 25, 2012 at 03:19:24PM +0900, hero...@gentoo.org > wrote: >> If we set rc_provide="net" in rc.conf, the services that need net >> can be tricked as we intended to. This makes more sense to me

Re: [gentoo-dev] rfc: OpenRC network provides revisited

2012-08-25 Thread William Hubbs
On Sat, Aug 25, 2012 at 03:19:24PM +0900, hero...@gentoo.org wrote: > If we set rc_provide="net" in rc.conf, the services that need net can be > tricked as we intended to. Setting rc_provide, rc_need, rc_use, etc in rc.conf is definitely not recommended. Remember that this affects all services on

Re: [gentoo-dev] rfc: OpenRC network provides revisited

2012-08-24 Thread heroxbd
William Hubbs writes: > If you are running services that "need net" and you have turned off all > of the "net" providers by adding something like rc_provide="!net" to > their conf.d files, the services that need net will fail hard even > though they shouldn't. If we set rc_provide="net" in rc.co

Re: [gentoo-dev] rfc: OpenRC network provides revisited

2012-08-24 Thread Diego Elio Pettenò
On 24/08/2012 20:57, William Hubbs wrote: > in your /etc/conf.d/sshd file. Looks good.. most people who have especially complex configurations would already be doing this. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP d

Re: [gentoo-dev] rfc: OpenRC network provides revisited

2012-08-24 Thread William Hubbs
On Fri, Aug 24, 2012 at 09:22:15PM -0400, Ian Stakenvicius wrote: > I think this may again come down to the meaning of "net" -- in the > case where rc_depend_strict="no" then "net" just means that the > network interface infrastructure is up and running (ie net.lo); this > should be true and imo is

Re: [gentoo-dev] rfc: OpenRC network provides revisited

2012-08-24 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 24/08/12 07:48 PM, William Hubbs wrote: > On Sat, Aug 25, 2012 at 07:40:43AM +0900, hero...@gentoo.org > wrote: >> Besides, IMHO, we should avoid changing OpenRC's default >> dependency too often. The solution for one user can be received >> as a

Re: [gentoo-dev] rfc: OpenRC network provides revisited

2012-08-24 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 24/08/12 03:58 PM, William Hubbs wrote: > On Fri, Aug 24, 2012 at 01:50:14PM -0400, Alexandre Rostovtsev > wrote: >> On Fri, 2012-08-24 at 12:10 -0500, William Hubbs wrote: >>> The second question this bug brings up is whether services >>> should

Re: [gentoo-dev] rfc: OpenRC network provides revisited

2012-08-24 Thread William Hubbs
On Sat, Aug 25, 2012 at 07:40:43AM +0900, hero...@gentoo.org wrote: > Besides, IMHO, we should avoid changing OpenRC's default dependency too > often. The solution for one user can be received as a regression to > others. > > People file bugs saying "it worked for OpenRC-0.9 but not 0.10". For > d

Re: [gentoo-dev] rfc: OpenRC network provides revisited

2012-08-24 Thread heroxbd
Besides, IMHO, we should avoid changing OpenRC's default dependency too often. The solution for one user can be received as a regression to others. People file bugs saying "it worked for OpenRC-0.9 but not 0.10". For devs, we know we just changed default value of something perfectly configurable.

Re: [gentoo-dev] rfc: OpenRC network provides revisited

2012-08-24 Thread heroxbd
Hi William, William Hubbs writes: > When network interfaces are pre-configured, our network scripts > shouldn't run at all, but they can be forced to run if other services > have "need net" in their dependencies. > > So my question is, should we change our services to "use net" instead of > "nee

Re: [gentoo-dev] rfc: OpenRC network provides revisited

2012-08-24 Thread Diego Elio Pettenò
On 24/08/2012 12:58, William Hubbs wrote: > This user is running with pre-configured interfaces (root is nfs > mounted). The network interface configuration should not be touched by > openrc. That would be nice for LCX as well, just so you know. -- Diego Elio Pettenò — Flameeyes flamee...@fla

Re: [gentoo-dev] rfc: OpenRC network provides revisited

2012-08-24 Thread William Hubbs
On Fri, Aug 24, 2012 at 01:50:14PM -0400, Alexandre Rostovtsev wrote: > On Fri, 2012-08-24 at 12:10 -0500, William Hubbs wrote: > > The second question this bug brings up is whether services should "need" > > or "use" net. Remember that the "need" dependency will try to run the > > needed service e

Re: [gentoo-dev] rfc: OpenRC network provides revisited

2012-08-24 Thread Alexandre Rostovtsev
On Fri, 2012-08-24 at 12:10 -0500, William Hubbs wrote: > The second question this bug brings up is whether services should "need" > or "use" net. Remember that the "need" dependency will try to run the > needed service even if it is in init.d but not in a runlevel. Presumably that depends on the

[gentoo-dev] rfc: OpenRC network provides revisited

2012-08-24 Thread William Hubbs
All, bugs like this one [1] are making me question the net/lo provides again, and I want to know what everyone thinks. First, do we need a provide for the loopback at all? I do not know of any scenario in which a linux or *bsd system will not have an active loopback interface. If we just make sur