http proxy:suggestion

Glenn Steen glenn.steen at gmail.com
Tue Feb 26 22:23:35 GMT 2008


On 26/02/2008, Rick Cooper <rcooper at dwford.com> wrote:
>
>
>   > -----Original Message-----
>   > From: mailscanner-bounces at lists.mailscanner.info
>   > [mailto:mailscanner-bounces at lists.mailscanner.info] On
>
>  > Behalf Of Glenn Steen
>   > Sent: Tuesday, February 26, 2008 9:45 AM
>   > To: MailScanner discussion
>
>  > Subject: Re: http proxy:suggestion
>   >
>   > On 26/02/2008, Rick Cooper <rcooper at dwford.com> wrote:
>   > >
>   > >
>   > >   > -----Original Message-----
>   > >   > From: mailscanner-bounces at lists.mailscanner.info
>   > >   > [mailto:mailscanner-bounces at lists.mailscanner.info] On
>   > >
>   > >  > Behalf Of David Lee
>   > >   > Sent: Tuesday, February 26, 2008 5:29 AM
>   > >   > To: MailScanner discussion
>   > >
>   > >  > Subject: RE: http proxy:suggestion
>   > >   >
>   > >   > On Fri, 22 Feb 2008, Rick Cooper wrote:
>   > >   >
>   > >   > >  > <t.d.lee at durham.ac.uk> wrote:
>   > >   > >  > >  [...]
>   > >   > >  > >>  What still seems absent is recognising
>   > "http_proxy" when
>   > >   > >  > run under "cron".
>   > >   > >  > >>
>   > >   > >  > >>  Those scripts already do:
>   > >   > >  > >>    if [ -f /etc/sysconfig/MailScanner ] ; then
>   > >   > >  > >>         . /etc/sysconfig/MailScanner
>   > >   > >  > >>    fi
>   > >   > >  > >>
>   > >   > >  > >>  But that file seems oriented to variables specific to
>   > >   > >  > "MailScanner.conf".
>   > >   > >  > >>
>   > >   > >  > >>  Could there also be a "/etc/sysconfig/MailScannerEnv"
>   > >   > >  > (or similar) whose
>   > >   > >  > >>  purpose would be for environment variables
>   > for scripts?
>   > >   > >
>   > >   > > [...] That said, why not use the (.)?wgetrc and
>   > (.)?curlrc files to
>   > >   > > enter the default proxy/user/password information on
>   > >   > systems that need this
>   > >   > > information? I have done this in the past for a specific
>   > >   > server for a
>   > >   > > specific reason.
>   > >   >
>   > >   > Good idea.  Thanks. I've just tried it (/etc/wgetrc)
>   > and it seems to
>   > >   > work... for the 'update_phishing_sites' and
>   > >   > 'update_bad_phishing_sites'
>   > >   > cron jobs.
>   > >   >
>   > >   > That just leaves the MS 'update_spamassassin' cron job; is
>   > >   > there some way
>   > >   > to arrange for it, when run under 'cron', to obtain
>   > >   > 'http_proxy' somehow
>   > >   > from somewhere?
>   > >   >
>   > >   >
>   > >
>   > >
>   > > Well if you are running linux you can just add the ENV
>   > item at the top of
>   > >  the correct user's crontab. It seems like solaris doesn't
>   > allow for that.
>   > >  Remember it's not exported though, it's in the format of
>   > >
>   > >  VAR=VALUE
>   > >
>   > >  Since sa-update uses LWP I don't believe there are any rc
>   > files to handle
>   > >  that.
>   > >
>   > >
>   > >  Rick
>   > >
>   > Correct me if I'm wrong, but this "issue" is only an issue on
>   > platforms where the install will actually set up the cron jobs for
>   > you, right? I don't think the stock source install does that... So
>   > what Solaris or whatever use for cron is rather immaterial, since
>   > it'll be you (as admin) that will be doing those entries
>   > anyway... And
>   > the timetested sh -c "<set env>;<do command>" would work well
>   > enough... Right?
>   > Or am I missing something obvious? To my eyes, the http_proxy setting
>   > for LWP could well go anywhere, on the installs that need
>   > them. Having
>   > another conf file to massage afterwards would just confuse the matter
>   > (IMO:-). So put it in the sysconfig file... commented out with
>   > something nice above for us to read:-)... Less changes for Jules,
>   > little real "semantic" problems...
>   >
>
>
> I think the original problem was that all distros don't use the sysconfig
>  file... Mostly a redhat thing, and I think someone said deb. Using the sh -c
>  option would work but the script he specifically mentioned clearly states at
>  the top not to edit it, I assume this means it's overwritten on upgrade. If
>  he adds the environment proxy stuff at the top of the crontab for the user
>  that runs the script in question it would be immune to upgrade tampering.
>
>  The easiest answer is to allow the server in question to pass the proxy. I
>  assume http(s) traffic is being redirected via an Iptables rule and simply
>  adding a PREROUTINING rule (before the redirect) that does an ACCEPT for
>  that server on outbound connections to the ports being trapped would exempt
>  it from forced proxy usage and the problem is then mute.
>
>  It's just an opinion but I have found that, even in this day and age, *many*
>  programs are not proxy friendly and in the case of wget or curl you can
>  handle that with an rc file, not so with LWP, or others without specific ENV
>  items. If you need it and your OS supports it then crontab is a good place
>  for them because they are then available to scripts/programs that require
>  them and do not make specific configuration allowances for them.
>
I'm with you all the way Rick, no argument. My sh -c ... thingie
pertains to use in a crontab, to be just that ... upgrade friendly;-)
If the cron version you use don't support setting environment, then
call a shell explicitly that does... oldest "trick" (and very
basic/simple) in the book:-).
So there really is no argument from me.
I to have a vague recollection (and am too lazy to look through the
thread:-) of someone mentioning debian.... well, if James does the
repo thing to ... freshen... things in that department, he can do the
similar thing for that packaging that Jules would do for the sysconfig
thing (and J-P for the FBSD port ... :-)... And Peter for the
blastwave ...:D

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se


More information about the MailScanner mailing list