Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
"Brian" == Brian Mays <bem5r@virginia.edu> writes:
> Yann Dirson <ydirson@a2points.com> writes:
>> Adam P. Harris writes:
>>> I think that /etc/ppp/ip-up and /etc/ppp/ip-down should use
>>> 'run-parts' against, say, the directories /etc/ppp/ip-{up,down}.d/.
>>>
>>> This would allow, for instance, MTA packages to ship little scripts to
>>> flush the mail queue when the link comes up, pop-deamons to start up,
[...]
>> I had the idea of adding such actions (flush mailqueue, fetch mail,
>> etc.) to my ip-up, but I didn't do that.
>> This is because some of these actions (eg. mail fetching) may be
>> quite long to complete,
That's just a question of looking into how run-parts serializes
execution, and maybe using backgrounded subshell for faster script
completion.
>> and may act badly if interrupted by a
>> 'poff' (eg. fetched messages from the interrupted session not
>> erased from my POP account - guess it's a security feature in
>> fetchmail).
Well, that's an example of an application that works fine when the
link goes down in midstream! No worries!
I'm sure some processes aren't as graceful. However, the system I'm
proposing (and there's no guarantee Phil Hands won't adopt some
radically different scheme), which just talks about:
/etc/ppp/ip-up.d/<up-script>
/etc/ppp/ip-down.d/<down-script>
Wouldn't be making the situation any worse than it already is. Not
that that's an excuse, but the fact is, by the time the scripts in
ip-down.d are run, it's too late anyhow!
>> The solution I used was to manually ask to fetch my mail.
Yeah, me too, but that sucks!
>> Another
>> would be to have a (hopefully generic) mean of forcing the line to
>> stay up while such an action is taking place.
Well, that's outside of the scope of what I was trying to propose, it
takes power away from the user, etc etc.
>> * we can't decide for the sysadmin what actions will take place on
>> boot.
We do have an initial descision, which is what 98% of users will
stick with. Yes, allow them to override, of course.
>> * if we build such a system, a standard way of disabling parts of
>> these directories (maybe like what /etc/init.d/rc allows with 'S'
>> and 'K' names ?)
I just feel that the SYSVINIT model is too elaborate for what we're
doing here (running scripts on link up and link down). 'run-parts is
stock debian, and already used by cron etc.
> Yes. Definitely ensure that it is easy to disable (and of course
> re-enable) these automatic scripts, and ship everything _off_ by
> default. IMO nothing is more annoying than these kind of surprises.
> I want to know what is being started when I dial into my ISP.
But of course. Actually, it would be up to the individual packages to
be reasonable.
The beauty of run-parts is that all a local sysadmin has to do is say
`chmod a-x <file>' to disable a file.
> For example, I have configured my ip-up script to start fetchmail
> (in daemon mode) and grab articles for my local news spool unless
> the file /etc/no_mail exists. Therefore, if I need to quickly dial
> in, say to fetch a file, I create this file before starting pppd so
> that I can hang up as soon as I am done without waiting for POP and
> NNTP transfers to finish.
I'm not sure we can accomodate this ;)
My goal is to find a 90% solution. If it doesn't work for 10%'ers,
well, those 10%ers are generally hacker types and they are generally
able to hack on the system to get it to work "their way".
.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: