Re: Bug#19129: sendmail: support PPP links --- use /etc/ppp/ip-up.d
Hi,
>>"Adam" == Adam P Harris <apharris@onshore.com> writes:
Adam> "Manoj" == Manoj Srivastava <srivasta@datasync.com> writes:
>>> "aph" == aph <aph@debian.org> writes:
>> This is not policy, and for good reason: the ip-up.d idea does not
>> seem to have been thought through.
Adam> Your opinion; not the opinion of the great mass of people on
Adam> debian-devel, the exim maintainer, the ppp maintainer, the
Adam> fetchmail maintainer, and myself.
Nevertheless, there are problems with this proposal, that if I
need to turn anything off I need to edit a script, and that script
being a conffile, I shall be botherd everytime it is enhanced. Also,
we are supposed to be minimizing the number of conffiles if at all
possible. Here it is.
A simple policy of looking in /etc/ppp/ip.conf for a line which
matches the (Perl) expression: /^\s*$PKGNAME.*UP=YES/ would allow
the users a simple way of controlling exactly what happens at ip-up
and ip-down time, without having to edit scripts directly and thus
have a modified conffile.
Secondly, we should minimize conffiles. This mechanism allows
me to control the script without having it necessarily be a
conffile.
Adam> If you disagree with the concept of /etc/ppp/ip-up.d, then I
Adam> suggest you review the January conversations on debian-devel
Adam> (which was unanimously approving, if you'll please note, Manoj),
Adam> think it over, and maybe submit a bug against ppp or a followup
Adam> to debian-devel?
Firstly, I do not disagree with the concept. The concept is
nice. What I disagree with is the implementation of some of the
scripts, (slrn does it right, but I would rather look in one file for
my ip scripts, rather than have them scattered all over /etc)
The unanimity was for the concept. Not this implementation.
Secondly, this is a matter of deciding on policy, and should
be on debian-policy, not on debian-devel, which is cluttered up
enough already.
Once we deicide, I shall indeed fire off bugs as needed (ppp
is doing nothing wrong, as far as I can see. Packages providing the
scripts are the ones who need to do this)
Adam> As for the MTA, why on earth would you *not* want the MTA to
Adam> fire off the mail queue when the link comes up? (And MTAs were
Adam> the majority of the targets for my wishes here).
My machine. I decide when the MTA queues are run. How can
anyone presume to know better than the sysadmins out there? I have
decided when my MTA runs. I do not have to explain that to anybody.
The idea is that our users know best. We should minimize
hassles for them, especially since the solution is inserting
one line in the scripts:
egrep "^$PROGNAME.*UP=YES" /etc/ppp/ip.conf || exit 0;
or
egrep "^$PROGNAME.*DOWN=YES" /etc/ppp/ip.conf || exit 0;
Not so hard, is it? I can see at a glance which scripts are
going off, and when.
Adam> I'm sitting here scratching my head and wonding why you wouldn't
Adam> want outbound mail to in fact get a kick in the butt and go out
Adam> when the link comes up, and say I have multiple links, what's
Adam> the big bother?
Why should I have to explain this to you? I have my
reasons. Moreever, I am proposing a Policy for *ALL* ip-up/down
scripts, and providing a single point of control. The format is
simple enough that one can even hook up a GUI for ip-control.
There.
>> If the directory and scripts make things easier for people,
>> Fine. But there should be a means of turning thisng on and off
>> easily.
Adam> Yuh! That's why I suggested they be conffiles! And hey,
Adam> they're even under /etc. ;)
Minimize conffiles; in this case they may not be needed.
>> There is no easy way, short of hacking or removing the scripts to
>> suddenly have junk happening when I do not wish it to.
Adam> Oh come on --- *conffile*
Exactly. A one line solution -- and you prefer the overhead of
conffiles, and making users edit scripts. And *I* am the one often
accused of being user unfreindly? ;-)
manoj
--
Forewarned is half an octopus. --anonymous
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: