conf/122127: [rc.d] ppp unit not settable

[Peter Much]

>Number:         122127
>Category:       conf
>Synopsis:       [rc.d] ppp unit not settable
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Wed Mar 26 19:50:03 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator:     Peter Much
>Release:        FreeBSD 6.3-RELEASE-p1 i386
>Organization:
n/a
>Environment:
System: FreeBSD disp.oper.dinoex.org 6.3-RELEASE-p1 FreeBSD 6.3-RELEASE-p1 #4: Tue Feb 26 15:01:43 CET 2008 root at disp.oper.dinoex.org:/usr/src/sys/i386/compile/D1R63V1 i386


>Description:

The ppp program usually opens the next available tunX device.

There is a good reason to override this and give a specific number
of tunX device to use, that is when the interface name will be used
in firewall definitions. 
But this can only be done via command-line, with the -unitX option.

In earlier FBSD releases the following could be used in rc.conf and 
would do the trick:
	ppp_profile="-unit0 t-adsl"

This is no longer working now, because the name of the profile is
now used as part of shell-variable names in /etc/rc.d/ppp, and
this makes spaces in that value illegal.
So the possibility to set the unit number thru the rc.d mechanics is 
now lacking.

BTW: If you try this out, you will notice that minus-signs
within the profile-name, while perfectly legal for ppp, are for
the same reason also no longer working from rc.conf.

>How-To-Repeat:

see description.

>Fix:

The most simple and straightforward solution is to add another
variable "ppp_cmdopts" to rc.conf, which gets promoted into the
actual command line.
(I for my part prefer to continue using the old script from rel. 5.5, 
since I luckily do not need multiple ppp sessions brought up early.)

The more general idea would be to think about some healthy
self-restriction when putting all too complex features into the
rc.d mechanics, because they tend to break some facets of the more
simple configurations. At some point of complexity people are in
the need to create their individual scripts anyway.
>Release-Note:
>Audit-Trail:
>Unformatted: