Re: [Ddclient-support] Support for IPv6 (patch)

[Eduardo T. <etr...@gm...>]

>> No, it doesn't, you're right.  It's simply that Debian doesn't have
>> /sbin int its path for non root users.  You have to add it or call
>> /sbin/ifconfig directly but you do not need root privileges.
> 
> That seems broken.  The directory /sbin typically contains various
> utilities that normal users can legitimately execute to gather
> information, like dmesg, mount, ping, route, sysctl...
> In /usr/sbin, there is more useful stuff like apm, arp, chgrp,
> dig, fs, groupinfo, host, iostat, etc. etc.
> So deleting *sbin from the PATH looks rather stupid.

If your interested in understanding the reasoning please check this old
discussion[1], with the relevant information from the FHS.  It's by no
means stupid.  Arguable maybe, not stupid.

> Hell, deleting *sbin from the PATH breaks sudo(8) on top of that.
> Users can't even do things like "sudo halt" any longer if
> they dont have *sbin in their PATH.

sudo lives in /usr/bin!!  So this has nothing to do with it.  Please
check your assertions.

> So no, a PATH not containing /sbin is never sane, and i don't think
> we need to care about it (it is well known that a default Debian
> system usually requires some manual reconfiguration before it
> becomes usable).  Maybe the documentation should mention
> that running ddclient(8) requires a sane PATH giving access to
> common utilities (including ifconfig(8)).

I think I'd rather go back to ddclient, your knowledge or assumptions on
Debian and sane defaults and usability seem to be a little ... either
biased or outdated, just like the previous IPv6 ones.  I just said a
normal user in Debian does not have /sbin by default in the path.
Ddclient *runs as root*.  So that's not a problem!

> A usev6 option might indeed make sense, allowing different strategies
> for v4 and v6 to be used concurrently.  However, in that case, this
> chunk looks suspicious:
> 
> +			my $use = '';
> +		        $ipv6 = 1 if (defined $config{$h}{'usev6'});
> +			if ($ipv6) {
> +			    $use = $config{$h}{'usev6'} || opt('usev6');
> +			}
> +			else {
> +			    $use = $config{$h}{'use'} || opt('use');
> +			}
> 
> This will only allow to set either v4 or v6, right?

For each entry, yes, that is the whole idea.  To treat ipv6 hosts as
another host.  For me it's hard to pretend it's like an MX or something
like that and add a parameter.  It's hard because there is all the
strategy stuff.

> Maybe it's possible to support both in parallel?

Yes, by adding two configuration entries.

> It may require slightly more changes.
> If not, then it might be better to support just "use = ipv6',
> "use = ifv6", "use = webv6".

I started out the way you are suggesting.  But I really didn't like the
idea of namespace pollution, if you see what I mean.  "ifv6", "ipv6",
"webv6".  And they would do basically the same thing as their non-6
counterparts.  I'd call it configuration noise.  Say you want to have
both ipv4 and ipv6:

You can have two lines like this:

protocol=dyndns2
usev6=if, if=teredo
server=members.dyndns.org
login=user
password='my$password'
myteredohost.dyndns.tv

protocol=dyndns2
use=if, if=ppp0
server=members.dyndns.org
login=user
password='my$password'
myteredohost.dyndns.tv

Then you would have, at the same time, updates for ipv4 and ipv6.  Even
better, you *could* set different parameters to each one, whatever they
might be.

*BUT* the program hashes the definitions based on
'myteredohost.dyndns.tv' (as far as I can see, I've already stated I'm
not that fluent in perl).  In my original message I mentioned that
problem and  explicitily said I didn't know how to work around it.

I believe that it's better to have two definitions, one for ipv4 and one
ipv6 (as in the example above) and just a new keyword.  I looks cleaner.

> If ddclient(8) is to support ipv6 at all, them allowing to set both

It already does :).  For dyndns at least in four or five Debian/Ubuntu
computers.  Please keep in mind that not necessarily everybody will take
the same path as afraid.org / dyndns, that is parsing the address and
deciding which record to update (A or AAAAA).  Some of them may decide
to have a completely different update url, for example.

> families in parallel seems more attractive than being forced to
> choose either, so i'd prefer the use/usev6 direction.

Lets say that to achieve the same result it looks nicer and it's easier
both on humans and on the parsing code:

use=if, if=ppp0
usev6=if, if=teredo
use=ip, ip=204.23.12.99

[use, usev6, if, ip]

than:

use=if, if=ppp0
use=ifv6, ifv6=teredo
use=ipv6, ipv6=2001:0::2

[use, usev6, if, ifv6, ip, ipv6]

>> It's your call to ignore the patch, rewrite it or do as you wish,
> 
> Sorry, i don't have time for detailed testing and polishing
> this afternoon, but perhaps later, or perhaps others have...

It's ok, no hurry.  It works for me and has already paid off.  Just
wante to share the results back.  The tone of my sentence was because I
was in part reacting on the perceived uselessness of the patch.  That's
settled.

Eduardo.

[1] http://lists.debian.org/debian-devel/1999/12/msg00946.html