conf/121452: /etc/rc.d/ppp not working as expected

[Manfred Usselmann]

Brooks Davis <brooks at freebsd.org> schrieb am Fri, 7 Mar 2008 13:41:06
-0600:

> On Fri, Mar 07, 2008 at 10:43:26AM -0800, Maksim Yevmenkin wrote:
> > On Fri, Mar 7, 2008 at 10:09 AM, Brooks Davis <brooks at freebsd.org>
> > wrote:
> > > On Fri, Mar 07, 2008 at 09:34:06AM -0800, Maksim Yevmenkin wrote:
> > >  > On Fri, Mar 7, 2008 at 7:49 AM, Brooks Davis
> > >  > <brooks at freebsd.org> wrote:
> > >  > > The following patch should allow profile name to contain
> > >  > > ".-/+" characters as we do with interfaces.  It also
> > >  > > documents the previous undocumnted per-profile overrides of
> > >  > > _mode and _nat which were the cause of the problem. If
> > >  > > someone who uses ppp could test this, I'd be happy to commit
> > >  > > it.

I could test that it is working in my case with 't-dsl'. But a complete
test would of course involve multiple profiles with mode overrides. Not
sure how to test this with the one ISP I'm using.


> > >  >
> > >  > i'm not so sure about this one. if i have "t-dsl" as a profile
> > >  > name, i will not be able to specify any overrides for this
> > >  > profile, because shell won't let me have "ppp_t-dsl_mode"
> > >  > and/or "ppp_t-dsl_nat" variable. 

The questions is would I want to. I took t-dsl as profile name because
this is the name of the product I'm using (from German Telekom). 

I'm using this name since 4.x times and I believe it was used in an
example still linked from the handbook

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/pppoe.html 

"Nutzung von T-DSL und T-Online mit FreeBSD by Udo Erdelhoff (in
German)." <http://www.ruhr.de/home/nathan/FreeBSD/tdsl-freebsd.html> 

The links seems to be no longer available though.

Anyhow I was not aware that something was wrong with this name and I
was not even aware that it is possible to use multiple profiles in
rc.conf and overrides per profile.

Most probably most people are not aware of this. Even 'man rc.conf'
doesn't mention that possibility!

The only way I became aware of it was when I couldn't access our box via
ssh from a customer because the automatic redial had failed. After
some investigation I noticed that /usr/sbin/ppp was running with -auto
instead of -ddial as specified in rc.conf. OK, I simply restarted ppp
with the correct parameter and was very surprised a few days later when
the problem reoccured. 

> > >  > so, the translation here is
> > >  > not really needed, imo, 

The translation is needed to make the script work again for the
standard case (only ppp_mode is used) and thereby provide backwards
compatibility. 

> > >  > and, perhaps, could even be considered
> > >  > harmful. perhaps we should do one of the following
> > >
> > >  The point of the patch is to change all ".-/+" characters to _
> > > which means the variable will be ppp_t_dsl_(mode|nat) so you can
> > > use the profile overrides.  

Well, if you want to use the new functionality (the overrides) you
should probably use a more suitable profile name. IMO the main point of
the patch is to make it work for the standard case as well. Currently
as a side effect of the added flexibility ppp_mode and ppp_nat are no
longer working. They are silently ignored, if you use something like
t-dsl as profile name what was perfectly possible for many years.

> > > It's an exact copy of the code we use
> > > for interface variables.
> > 
> > i get that. what i was trying to say is that overrides for the
> > "t-dsl" profile (with hyphen) are now, obviously, "ppp_t_dsl_mode"
> > and/or "ppp_t_dsl_nat".  to me, it is somewhat confusing. another
> > (pretty weak :) argument is that all ".-/+" characters are mapped
> > onto single "_"  character. this could potentially create a
> > collision in variable names. i realize that you have done exactly
> > the same thing as in get_if_var() in network.subr. are there any
> > examples of network interface variable names that are not "shell
> > clean"?
> 
> When I added the functionality it was to handle '.', but I figured I'd
> add other common separators at the same time and figured collisions
> aren't likely.  For other variables there may be argument for
> rejecting values that aren't shell clean, but it's not clear to me
> how to write such a shell function.  If someone could figure that out
> it would make a good addition to rc.subr and I wouldn't mind taking
> that approach here. I just figured that we've got precedent for the
> other approach.
> 
> -- Brooks
> 
> > >  > 1) demand that ppp profile names should be "shell clean" and
> > >  > document it

This could break old configurations because profile names valid until
now would become invalid.

> > >  >
> > >  > or
> > >  >
> > >  > 2)  if a ppp profile name is not "shell clean" simply do not
> > >  > evaluate profile overrides and use defaults

Yes, I believe it is a fair assumption that somebody using a "wrong"
profile name is not aware of the overrides and doesn't want to use them.

This would be ok for me since the overrides are pretty new, not "shell
clean" ppp profiles have anyhow never worked with overrides and someone
adopting this new functionality will probably test it and notice the
problem. But it should be documented that shell clean names are needed
for overrides to work.


> > >  I'm opposed to 2.  I'd be OK with 1, but think folding common
> > >  punctuation into _ may be a better option given that we're
> > > already doing it elsewhere.

I believe this is a valid point. If it is not appropriate here it
should probably changed at the other place as well.

But I believe that folding common punctuation into _ is a good
workaround because not everybody running a FreeBSD system is an expert
in shell scripting and aware of the fact that a ppp profile name now
needs to be "shell clean" and what exactly this means...

On the other hand somebody who wants to use the overrides needs to
delve into the problem a bit more and will see the relationship between
profile name and variable names for the mode and nat overrides.

> > i'm still not sure :) however, please do not take it as an objection
> > :) since we already have similar code (and no one, including me,
> > complained :), it probably makes more sense to do the same here.
> > 
> > thanks,
> > max
> > 

Regards,
Manfred 

-- 
________________________________________________________________________
 Manfred Usselmann                            usselmann.m at icg-online.de