-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/02/12 03:28 AM, Alexandre Rostovtsev wrote:
> 
> If I want to connect to pool.ntp.org to sync the system clock, or
> to my company's vpn gateway for telecommuting, or to tor to encrypt
> my traffic, or to a dynamic dns provider to update my machine's
> record, I do not care in the least which interface I use.


This is not actually true.  You care, in that you want to be sure that
the iface connects to the internet (or at least the network that said
target sits on).

Many systems that have multiple interfaces have only some of them that
route out to the rest of the world, and when depending on a generic
'net' that includes -all- of them, it's more likely that the, say,
static private net iface will be configured (and therefore 'net'
considered started) significantly before the one that can route to the
internet, and therefore ntp-client's attempts at connecting to
pool.ntp.org will fail.

I think that "Category 2" needs to be separated into "2a - any
network", and "2b - any public network".  For instance, the service
'net' (for 2a) and service 'inet' (for 2b).  If this were the default
case, then Cat.2 packages that by default want to connect to the
internet could 'need inet', and then the user would only have to
define which interfaces are included (or excluded) from satisfying 'inet'.

The trick that I see here is that init.d scripts have to have their
'depends' set up in such a way that the services can be separated
based on their need for public network or any network, so that the
user doesn't have to mess with those.  By default I think it makes
sense to keep both the 'net' and 'inet' pools the same (ie, all ifaces
but net.lo*), but have a simple ability to separate interfaces from
the 'public net' pool in rc.conf when they do not provide a public
network connection.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk8xN5IACgkQAJxUfCtlWe3hDQD+JKD7AWVep/+v8u7WcdP2ZbxB
k9Vmo5NT39WqvWPP3TYA/ReAYy4nAyYC8nbc/dRO53LwXqEP9g8rf+0WJ/aPHXkW
=2VMQ
-----END PGP SIGNATURE-----

Reply via email to