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

[Brooks Davis]

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'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. so, the translation here is not really needed, imo, 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.  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
> >  >
> >  > or
> >  >
> >  > 2)  if a ppp profile name is not "shell clean" simply do not evaluate
> >  > profile overrides and use defaults
> >
> >  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'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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20080307/e03c9b72/attachment.pgp