Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Feb 2007 07:36:16 -0800
From:      Jeremy Chadwick <koitsu@FreeBSD.org>
To:        freebsd-stable@FreeBSD.ORG, kevin@insidesystems.net, brooks@FreeBSD.ORG, joao@matik.com.br
Subject:   Re: Desired behaviour of "ifconfig -alias"
Message-ID:  <20070212153616.GA38483@icarus.home.lan>
In-Reply-To: <200702121426.l1CEQIF4031564@lurza.secnetix.de>
References:  <200702092300.35420.joao@matik.com.br> <200702121426.l1CEQIF4031564@lurza.secnetix.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 12, 2007 at 03:26:18PM +0100, Oliver Fromme wrote:
> Changing the behaviour of tools always involves a certain
> danegr of breaking existing script.  That's especially true
> for symstem administration commands such as ifconfig that
> are running in automated scripts, and people depend on them
> for booting their machines remotely.

If anyone depends on "ifconfig iface -alias" I'll be surprised.
(Ed. - I see you do rely on it, just with "delete" not "-alias").

> I'm not saying that people are intentionally using that
> syntax ...  Maybe they are, maybe not.  But you also should
> take into accounts that there might be scripts that use the
> syntax inadvertantly and happen to work correctly because
> of the current behaviour.

If the problem with -alias without any inet/inet6 arguments is
addressed, it's going to break things for administrators who have
custom in-house scripts that rely on this behaviour.  There's
absolutely nothing we can do about that, other than put an entry
in UPDATING about the change.  This has been standard practise for
quite some time now -- administrators are *expected* to look at
UPDATING when rebuilding world.

Changing this functionality also means one must go through all
existing scripts throughout src-all as well as possibly ports-all to
see if anything "might" rely on this behaviour: and then change
those appropriately.

> I'm also _not_ saying that the behaviour must not be changed
> at all.  But it should be done carefully, i.e. first to
> -current, with proper "heads up" warnings.  Don't change
> it in RELENG_6 without warning and expect evrybody to be
> happy.

I absolutely agree with this, however, to play the devil's advocate,
I'll point out that hardly anyone using FreeBSD in a production
environment runs -CURRENT.  Therefore, when changes are made to
-STABLE, one can expect people to come out of the woodwork wielding
sharp, pointy objects on mailing lists.

> The "-alias" parameter simply removes an address from an
> interface.  The term "alias" should really be avoided
> because it is misleading.  You can use "delete" or "remove"
> which do the same thing.  I think "-alias" should really
> be regarded to exist for backwards compatibility only.
> Personally I always use "delete".
>
> If no IP address is specified, then it's not completely
> nonsensical to remove the first address.  In fact I've
> used that short-cut to quickly remove the only address
> from an interface.  I've used "ifconfig xyz0 delete"
> quite a lot.

Great.  Okay, so now we have someone who does in fact rely on this
behaviour, except with "delete" not -alias.

FWIW, I still use alias/-alias.  Mainly because that's what has
existed historically, and the term "alias" is what is used in
reference to rc.conf ifconfig_iface_aliasX entries.

Thus, it may be worthwhile to fix this only for the -alias option,
but leave "delete" and "remove" how they are.

>  > and ifconfig nic -alias on a nic w/o ip returns "can't assign 
>  > requested address" ...
> 
> That error corresponds to EADDRNOTAVAIL, which is the
> correct errno to return, because there's no address left
> on the interface.  However, I agree that the message is
> a bit confusing to the unfamiliar.

Agreed.  In the case of -alias, this should probably result in a more
user-friendly message.  Then again, I've found similar confusing
entries when it comes to other parts of the networking stack, such as
ipfw deny entries resulting in "Permission denied" when trying to do
socket-level operations.  Took me a while to figure out that it was
ipfw inducing that.

-- 
| Jeremy Chadwick                                 jdc at parodius.com |
| Parodius Networking                        http://www.parodius.com/ |
| UNIX Systems Administrator                   Mountain View, CA, USA |
| Making life hard for others since 1977.               PGP: 4BD6C0CB |




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070212153616.GA38483>