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