[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [LONG] ppp-udeb: A succesful installation using it, some ideas and some requests for advices

On 5/16/06, Marco d'Itri <md@linux.it> wrote:
eddy.petrisor@gmail.com wrote:

>> Yes. I already explained this multiple times. An IP address is not
>> *needed* on the ethernet interface, but always configuring one is
>> simpler and may prevent problems later.
>If I am going to do that on the connection from my provider, I will
>have my contract termitated in a second because I am not allowed to
>use other IPs in their network than the ones given by thier servers,
>and believe me, there is NO configuration given for the ethernet card.
You are supposed to use a private IP address then.

INTERFACE WITH ANY IP. The ppp interface is the only one which is
allowed to be up with an IP which must be given by their server.

I had problems because of this (not exagerating) from day one, when my
laptop was put as a router for the internal network and on the used
interface it had on private class IP. One guy from the techincal body
of the ISP has visited me in the intent to disconnect me _just_
because I had an IP (an IP) other than the one provided by them.

>Or ifconfig ethX up with no IP, as in my case, so AFAICT, the postinst
>should detect if an Ethernet card is up, and if it is, try to probe
>for a concentrator. If the card is not yet up with an IP, the
>ppp-udeb.postinst script should just up it, wiithout an IP. At least
>that's how it seems logical to me.
But it's not. I already explained how this should be implemented.

Please explain non-logic for _my_ particular case.

It is not *necessary* to have an IP to search for the concentrator,
but it is *sufficient* to have the possibility to probe for
So, AFAICT, if probing must be done for eth0 then thi should be done
according to the following algorithm:
- is eth0 up? if yes, probe for concentrators
- if eth0 is down, _just_ up the interface (no IP) then probe

Any objection to this approach?

>So the question remains, how does one determine which interfaces were
>brought up by the ppp-udeb script (probably simple, as they might be
>ones with no IP set) and which are they associated to (more difficult
>for multiple ppp connections)? Bonus points for the association in
>subsequent runs of the postinst.
I do not understand what you mean.

See debian policy, about the idempotency of the postinst scripts.

ppp-udeb's postinst must allow running it an infinite number of times,
but the result should be the same. Curently this is not true because
for each run of the postinst, another pppoe connection is configured,
although it should not.

The problem is that this issue must be solved and one will have to
know (for multiple netcard system) on which ethX a pppY was
configured, so that once the pppY is down, _if_ the associated ethX
was upped by ppp-udeb's postinst previousely, it should be downed if
no concentrator was found on it.

Bringing down every interface on which there is no IP configured is
suboptimal, becasue we will assume that PPPoE is the only postinst
which brings up interfaces without assigning IPs to them (good for
now, but flawed from a design POV and might break other scripts that
might up interfaces without IPs, at some point in the future).

>> >1) the ppp related stuff was not installed by default
>> It is supposed to be.
>by whom?
>> >2) the configuration of pppoe on the target system was not the same as
>> >the one in the d-i envronment.
>> I do not know what this means, but the d-i configuration will work in
>> the installed system as well.
>The question is still "who will put the configuration there, in the
>target system?".
Yet another script.

So ppp-udeb should depend on another udeb which should provide a
PPP-config-saver udeb which should take care of this copying after the
target is installed.

"Imagination is more important than knowledge" A.Einstein

Reply to: