| 1 |
On Tue, Feb 07, 2012 at 09:39:14AM -0500, Ian Stakenvicius wrote: |
| 2 |
> On 07/02/12 03:28 AM, Alexandre Rostovtsev wrote: |
| 3 |
> > |
| 4 |
> > If I want to connect to pool.ntp.org to sync the system clock, or |
| 5 |
> > to my company's vpn gateway for telecommuting, or to tor to encrypt |
| 6 |
> > my traffic, or to a dynamic dns provider to update my machine's |
| 7 |
> > record, I do not care in the least which interface I use. |
| 8 |
> |
| 9 |
> This is not actually true. You care, in that you want to be sure that |
| 10 |
> the iface connects to the internet (or at least the network that said |
| 11 |
> target sits on). |
| 12 |
> |
| 13 |
> Many systems that have multiple interfaces have only some of them that |
| 14 |
> route out to the rest of the world, and when depending on a generic |
| 15 |
> 'net' that includes -all- of them, it's more likely that the, say, |
| 16 |
> static private net iface will be configured (and therefore 'net' |
| 17 |
> considered started) significantly before the one that can route to the |
| 18 |
> internet, and therefore ntp-client's attempts at connecting to |
| 19 |
> pool.ntp.org will fail. |
| 20 |
> |
| 21 |
> I think that "Category 2" needs to be separated into "2a - any |
| 22 |
> network", and "2b - any public network". For instance, the service |
| 23 |
> 'net' (for 2a) and service 'inet' (for 2b). If this were the default |
| 24 |
> case, then Cat.2 packages that by default want to connect to the |
| 25 |
> internet could 'need inet', and then the user would only have to |
| 26 |
> define which interfaces are included (or excluded) from satisfying 'inet'. |
| 27 |
|
| 28 |
You mean cat 1 actually; cat 2 are the listeners, like sshd, which don't |
| 29 |
care as long as some interface is active. |
| 30 |
|
| 31 |
> The trick that I see here is that init.d scripts have to have their |
| 32 |
> 'depends' set up in such a way that the services can be separated |
| 33 |
> based on their need for public network or any network, so that the |
| 34 |
> user doesn't have to mess with those. By default I think it makes |
| 35 |
> sense to keep both the 'net' and 'inet' pools the same (ie, all ifaces |
| 36 |
> but net.lo*), but have a simple ability to separate interfaces from |
| 37 |
> the 'public net' pool in rc.conf when they do not provide a public |
| 38 |
> network connection. |
| 39 |
|
| 40 |
If we add an internet pool, I would rather it start out with no |
| 41 |
interfaces and have the user be required to add the interface(s) to it. |
| 42 |
|
| 43 |
William |
Archives