from:"Phil"

Postfix and SASL

2003-05-07 Thread phil

I'm having some trouble getting Postfix SMTP auth working. I'm using unstable 
postfix and 
postfix-tls on testing, with unstable libsasl2 and libsasl2-modules. Whenever I 
try to send a 
message from my mail client (KMail) on another box, I get this in 
/var/log/mail.log: 
 
May  6 23:54:38 rama postfix/smtpd[21897]: connect from 
h24-70-240-178.ed.shawcable.net[24.70.240.1 
78] 
May  6 23:54:39 rama postfix/smtpd[21897]: TLS connection established from 
h24-70-240-178.ed.shawca 
ble.net[24.70.240.178]: TLSv1 with cipher RC4-MD5 (128/128 bits) 
May  6 23:54:39 rama postfix/smtpd[21897]: warning: SASL authentication 
failure: cannot 
connect to 
saslauthd server: Connection refused 
May  6 23:54:39 rama postfix/smtpd[21897]: warning: 
h24-70-240-178.ed.shawcable.net[24.70.240.178]: 
 SASL LOGIN authentication failed 
May  6 23:54:40 rama postfix/smtpd[21897]: disconnect from 
h24-70-240-178.ed.shawcable.net[24.70.24 
0.178] 
 
My /etc/postfix/sasl/smtpd.conf looks like this: 
 
# This sets smtpd to authenticate using the saslauthd daemon. 
pwcheck_method: saslauthd 
# This allows only plain and login as the authentication mechanisms. 
mech_list: plain login 
# Path to saslauthd run directory 
saslauthd_path: /var/run/saslauthd/ 
 
The relevant portions of main.cf: 
 
smtpd_sasl_auth_enable = yes 
smtpd_sasl_local_domain = 
smtpd_sasl_security_options = noanonymous 
broken_sasl_auth_clients = yes 
 
I suspect that postfix is trying to use the wrong socket, or something like 
that. I did a 
netstat -ap, and found that saslauthd is indeed listening on 
/var/run/saslauthd/mux. I'd really 
appreciate any ideas anyone has on this. 
 
Thanks, Philip Bock

re: LDAP in an ISP

2002-07-23 Thread Phil

We used cistron radius, pam-ldap, ldap, all from debian installs.
we modified radius to work out the time on-line from the stop record and 
update a total in ldap (billing purposes).

The ldap is used for single point for user id, account status 
radius for portslave login, static ips, dsl logins etc

Phil

>Does anyone run an LDAP back end within an ISP ? Im looking to rebuild
> the ISP and use ldap with some sort of radius configuration. Has anyone
> got any sort of expeirence with this? Basically im just wanting to know
> what to use, livingston/cistron ? and is LDAP really what I should be
> using,


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

re: LDAP in an ISP

2002-07-23 Thread Phil


We used cistron radius, pam-ldap, ldap, all from debian installs.
we modified radius to work out the time on-line from the stop record and 
update a total in ldap (billing purposes).

The ldap is used for single point for user id, account status 
radius for portslave login, static ips, dsl logins etc

Phil

>Does anyone run an LDAP back end within an ISP ? Im looking to rebuild
> the ISP and use ldap with some sort of radius configuration. Has anyone
> got any sort of expeirence with this? Basically im just wanting to know
> what to use, livingston/cistron ? and is LDAP really what I should be
> using,


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FTP upload by email

2000-04-13 Thread Phil Pennock

Typing away merrily, [EMAIL PROTECTED] produced the immortal words:
> procmail can not do this, can it ? 

Can't it?

Something like (untested):

< ~upload/.procmailrc >-
:0
* ^From [EMAIL PROTECTED]
{
:0 hc
* ^X-Authenticate-token: \/.*
| my_test_program "$MATCH"

:0 ab:
* ^X-Filename: \/.*
dropdirectory/$MATCH

:0
/dev/null
}
-< cut here >---

Ideally, given that it's cleartext, you'd either modify this to first
issue a challenge and store the issued challenge, and then check the
reply, or use cryptographic signatures (for sake of example, GPG) and
change the 'hc' rule to 'bc', require a more appropriate header (using
PGP/MIME for instance) and let the external program invoke gpg to
perform the checks.  Then change the ``dropdirectory/$MATCH'' to, eg,
``| my_strip_gpg_and_store "$MATCH"''.

man procmailrc(1).
-- 
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
 We believe in world peace through extortionate license fees."  -Bluemeat

Re: it's safe to run a web hosting server with the unstable distributions ?

2000-04-10 Thread Phil Pennock

Typing away merrily, [EMAIL PROTECTED] produced the immortal words:
> Actually, all of the scripts we maintain do "register" their existence
> and location in syslog each time called.

Interesting.  Why not just parse the server logs?

> This is not just a perl issue.  What about header files, /usr/src/linux
> and so forth?  What if client linked to libc4 krb4 libs?  (No
> that is not made up.)

We don't support the use of binary CGIs.  We reserve the right to make
changes which may cause them to fail.  We support the use of Perl for
CGIs.

The CGI environment of just about all services doesn't include, eg,
/bin/sh, /bin/rm, etc.

> At a certain point, a customer that does NOT want to upgrade is 
> increasing your costs and complexity.  That complexity (and associated
> costs) apply to all users.  Worst case, imagine the extra expense
> caused to 1500 perl users because just one doesn't want to upgrade
> from legacy /usr/bin/perl -> perl4 to current.  I'd guess that
> ASPs might have contracts that addressed this fairly well.  H.

If we can justify to senior management the man hours of getting our
customers away from */bin/perl -> perl4 then we could do it.  It's not
"expense to 1500 users" though - we're never again going to have a
web-environment where the interpreter filename doesn't map to a very
specific version.  Well, never in so far as "all current sysadmin (which
includes my boss) will fight tooth&nail".

The blurb sent to new accounts states the interpreter naming thing.  The
web-site help docs state it.  Support know about it.  Very occasionally
a new/clueless support bob might have to escalate a problem because they
can't see what's going on.  But yes, removing the unversioned perl
interpreters is a goal.

Actually, a major way of doing this is by having the newer web offerings
get it right from the start and pricing them lower.  Quite a few
customers are making the migration.

> Anyway, management of legacy code is WAY OT from can you 
> run "unstable" server.  ;^)

Is it?  "Can you run an unstable server" is not boolean unless you first
provide much more detail.  How much time do you later want to spend
sorting out problems, either technical or legal?

> Be careful next time you quote a job to make a minor modification; you 
> might end up rewriting the entire package!

NOCOL sucks[1].  I'm investigating NetSaint and MON.  Does anyone have
any operational experience of these packages please?  Any feedback that
you'd care to give?


[1] Technical term.  Well, okay, mostly it's the module interface which
sucks[2], and the inability to make a chain of system dependencies,
so you can't say "if BigRouter goes down, just report that, and not
the 300 LittleServices behind it".
[2] Mostly nocollib.pl which is unclean and leaks memory and I don't
want to have to maintain a new custom Nocol.pm so I've had to look
at solutions which have more long-term viability.
-- 
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
 We believe in world peace through extortionate license fees."  -Bluemeat

Re: it's safe to run a web hosting server with the unstable distributions ?

2000-04-10 Thread Phil Pennock

Typing away merrily, John Haggerty produced the immortal words:
> If you need source that badly or ever need it in the future just get some
> copies of everything and burn some CDs for permanent archival storage. You
> can't go wrong there.

We've now made sure that it's on a central CVS server in the UK.  Much
redundancy in the RAID, and backed up.

Somehow, someone had neglected to ensure that we had perl4 source
around.  Not all _that_ surprising - at the time it was probably taken
for granted that it was widely available.

> I think in upgrading something like perl4 you could hire say one
> programmer to do a temporary job and be on call for you. Then fix
> everything. I may be incorrect but isn't most of the core language of perl
> pretty much constant? Kind of like C/C++ or perl/delphi

It tends to be backwards compatible - new features are added, so you can
test for a minimum version number.  The move from perl4 to perl5 was hot
entirely backwards compatible, though.  As an example of the most
commonly encountered problem, in perl 4 arrays were not interpolated
into double-quoted strings.  So, given:
  @foo=(alpha, beta);
  $bar="x @foo x\n";
and the default output field separator of a single space, printing $bar
will give you:
 perl4: x @foo x
 perl5: x alpha beta x
which causes problems with, for example, email addresses (in the very
common case where double-quotes have been used unnecessarily, or it's
inside a here-document, or whatever).

There are some other smaller gotchas as well, but I don't remember them
off the top of my head as the vast majority of problems arise from the
above scenario.
-- 
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
 We believe in world peace through extortionate license fees."  -Bluemeat

Re: it's safe to run a web hosting server with the unstable distributions ?

2000-04-10 Thread Phil Pennock

Typing away merrily, [EMAIL PROTECTED] produced the immortal words:
> So perl is perl4.  That creates problems for users typing in perl and

On one service, yes.  But that service predates perl5.

Upgrading the hardware for Y2k was fun - when was the last time that you
tried finding the source for perl4?

> expecting it to work.  At a certain point it is simply cheaper for you
> to bite the bullet and upgrade them for free, no?  Because you are starting
> to twist everything else too.  And then when you do that free upgrade
> all of a sudden you own everything else that goes wrong too, even if
> you made **less** go wrong.  Been there - we start year 7 on May 1.  :-)

It would be nice to be allowed to just use find/ed to change all scripts
with /bin/perl to /bin/perl4 - but first you, eg, need customer
permission for that.  And to sort out who's liable if something breaks.
Eg, the find/ed isn't as simple as it might appear at first sight -
remember the perl trick of using /bin/sh and the first three lines sort
out finding the interpreter for you?  I think that service is the one
where the root directory for customers logged in with a shell is the
same as the one for the web-server, so /bin/sh is available, so that
trick may very well be in use.

But yes, I don't want to be in the position of still having /bin/perl be
v4 in five years time.  But, given the workload in working through 1,500
customers' scripts, you'd be looking at:
 * people to co-ordinate this with the customers
 * people to fix the scripts
 * people to test
which leaves you with one of:
 * heavier workloads for various departments, perhaps an extra employee
   in various places, just for upgrading perl
 * a dedicated temporary team, hired to manage this upgrade

Methinks it would be more appropriate, given out situation, to find a
way to get permission to automatically replace /bin/perl with
/bin/perl4, do so, run some scripts which try to look for monstrosities
like scripts which invoke perl interpreters, fix those, remove the
/bin/perl link and then just never ever let /bin/perl exist again.


> I think you are on right track with phase-out policy.  It really is
> a business service issue and needs to be addressed that way.  What 
> do you provide, etc

And this is much easier if you can manage easily which version of perl
is being used.  So, when someone asks how to go about things, they can
get one of three responses from me:
 * silence (I'm too busy)
 * just install /bin/perl (I really don't like them)
 * the advice I gave about numbered versions (I'm in a helpful mood and
   trying to save them headaches later)

Relying on timely response from customers from customers does not scale.
Searching for a magic bullet is naive.  Trying to design things right
first time isn't perfect, but it makes life easier in the long run, at
the expense of more work at start-up time.
-- 
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
 We believe in world peace through extortionate license fees."  -Bluemeat

Re: it's safe to run a web hosting server with the unstable distributions ?

2000-04-10 Thread Phil Pennock

Typing away merrily, John Haggerty produced the immortal words:
> Is there say a test that can be implimented that would test to determine
> wheather the program you are running will work under perl and
> then pick that version of perl? That would really rock and would possibly
> be quite easy considering perl is a great tool for text manipulation and
> analysis.

At run-time of request?  Erk!

If you're using a web-server which pre-determines mime-types, such as
wn, you could conceivable use perl_version -c script, making sure that
you handle -T (taint-checking) on the command-line.

But if the script is syntactically valid in a version where it would
actually fail, then your "test" becomes a competent human perl
programmer.  Or non-human, if you employ such.

The best way IME is to not have /bin/perl exist - always encode the
version number, and let the #! line be your switch for picking the perl
version.


Oh, and the boss says that we have a large proportion of 1,500 customers
of the relevant service whose scripts all date from perl4-only days and
if I want to phase out /bin/perl as perl4 then I can do it all by
myself.  I think that fairly neatly ends that discussion - I'm already
trying to juggle too many things at work.
-- 
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
 We believe in world peace through extortionate license fees."  -Bluemeat

Re: it's safe to run a web hosting server with the unstable distributions ?

2000-04-10 Thread Phil Pennock

Typing away merrily, [EMAIL PROTECTED] produced the immortal words:
> You **need** clients to complain loudly when something breaks; otherwise
> how will you know?  As for the lawyers, you'll hear from them 
> if you upgrade or if you fail to upgrade.  ;^)  We've just found
> it easier to maintain consistent upgrades as a matter of **policy**.

We found with experience that this doesn't scale all that well.  Mind,
I work for a reasonably large ISP.

When you have large corporate customers who make money from their sites,
they can be _very_ reluctant to make changes.  Policy be damned if it's
not utterly and clearly specified in the contract and your customers
lose a few cents.  :^(

Result: despite trying to ensure /bin/perl5.003_03 etc, the fact that
we'd previously had /bin/perl as perl4 means that we had to give in and
put it back as just that.  Unfortunately, this means that customers who
don't read the docs and just type /bin/perl get perl4.  :^(  Legacy
support is a problem, and a large one, which applies to more than just
web-sites.  This is part of what support-departments are for, though -
pointing out to customers the stuff which is already documented clearly.
*coughs*

I tried suggesting a phase-out policy for the contracts.  I don't think
our contracts have that, unfortunately.  Certainly not the oldest ones,
who are the ones most likely to be using perl4, etc.

Hrm .. time to talk to the boss about having another go at phasing out
perl4 on the servers ...
-- 
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
 We believe in world peace through extortionate license fees."  -Bluemeat

Re: it's safe to run a web hosting server with the unstable distributions ?

2000-04-10 Thread Phil Pennock

Typing away merrily, John Haggerty produced the immortal words:
> Then you could have the solution of say changing the name of the package
> to perhaps reflect that in fact you have perl4 or something and just
> install incremental upgrades for the packages that aren't prone to
> breakage. Eventually as people upgrade their stuff. You could slowly
> retire the old stuff while supporting the new.

Erm, as I understand what I wrote, that's part of what I said:
> If you have, eg, /bin/perl5.005_03 etc within the customer-facing root
> and maintain those properly, you can introduce new versions and allow
> the customers to manage the migration themselves; if you want to be able
> to retire older versions which are broken, make sure that the customer
> is aware of this fact and that they agree to a time-limit for phasing
> out older versions (contracts time again).

>From the Date: header in your mail, I see that it's still morning there.
Monday-morning.  This explains a lot.  :^)  Another coffee?

(Note that I also warned about libperl - we recently got caught by this,
 more than once.  The best solution seems to be static compilation of
 perl.  Forcing perl to be entirely static is apparently not as
 straight-forward as it should be; I don't know, though, as a couple of
 colleagues handled this)
-- 
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
 We believe in world peace through extortionate license fees."  -Bluemeat

Re: it's safe to run a web hosting server with the unstable distributions ?

2000-04-10 Thread Phil Pennock

Typing away merrily, John Haggerty produced the immortal words:
> Is there a good example of something in debian breaking a general
> script/program server side?

Not that comes to mind.

But what happens when, eg, perl is upgraded to 5.6?  The perl4 -> perl5
transition broke enough stuff.  Will this new one break things?  If so,
will Debian fork perl just to maintain backwards compatibility?

The ISP where I work still has perl4 on its servers, for this very
reason.  When a customer has something which works, they can be very
reluctant to make modifications just to use a newer version.

Predicting the future is tricky.  Being defensive in the way that you
set things up can help you bypass some of the uncertainty.

Defensive SysAdmin-ing as opposed to Defensive Programming.  :^)
-- 
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
 We believe in world peace through extortionate license fees."  -Bluemeat

Re: it's safe to run a web hosting server with the unstable distributions ?

2000-04-10 Thread Phil Pennock

Typing away merrily, John Haggerty produced the immortal words:
> I think that would work quite well. Just make sure to upgrade the system
> regularly. That will keep you abreast of all the problems and allow for a
> nice system.

Customers can complain quite loudly when something which used to work
has suddenly stopped working because of an upgrade.

How likely are your customers to have lawyers?

Another approach is to go for something stable, specify perl versions
with an embedded version number (watch out for the libperl linking) and
put something in the customer contract about being allowed to make
changes which break their scripts if there are security reasons for
doing so - this allows you to patch your system or temporarily disable
certain functionality.

If you have, eg, /bin/perl5.005_03 etc within the customer-facing root
and maintain those properly, you can introduce new versions and allow
the customers to manage the migration themselves; if you want to be able
to retire older versions which are broken, make sure that the customer
is aware of this fact and that they agree to a time-limit for phasing
out older versions (contracts time again).

Of course, if you're dealing with smaller customers on a more informal
basis, where they're more likely to rely on you for direct technical
assistance with scripting and stuff, then you're much less likely to
need to bother with this in contracts (IANAL, please don't not use a
contract on the basis of this paragraph).

Larger ISPs sometimes have customers who _seem_ hostile to the ISP and
like to carp a lot, even with no real justification.  Although when
something which did work stops working and the customer starts losing
revenue because of this, they do have a point.  Try to make the customer
environment as stable as possible if there's money involved in the
websites.

You could always have two types of web-service.  One with a server which
is stable in the way I describe, one which is a current OS, regularly
upgraded and which has latest-and-greatest, but the customer assumes
some responsibility for changing their scripts appropriately.

All this IMnsHO.  HAND.
-- 
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
 We believe in world peace through extortionate license fees."  -Bluemeat

Re: tracing a PERL cgi script

2000-04-10 Thread Phil Pennock

Typing away merrily, Chad A. Adlawan produced the immortal words:
>were trying oto debug this _big_ PERL web application (lots of forms, etc, 
> whatever) and it seems like were really lost w/ its code.
>is there any way that you can do a line by line trace when a PERL code is 
> executed on the web that way, we'll have some idea w/c goes where ?

Do you control the programs installed on the server?

If so, install a second copy of perl, one with debugging support
enabled.  Then go and read perlrun(1) for information on -D switches.

Eg,
#!/bin/perl_debug -Dtls

-- 
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
 We believe in world peace through extortionate license fees."  -Bluemeat

Re: Strange message in logs

2000-04-10 Thread Phil Pennock

Typing away merrily, Robert Ruzbacky produced the immortal words:
> Apr  9 06:47:39 ns tcp-env[17281]: warning: /etc/hosts.allow, line 11: can't 
> verify hostname: gethostbyname(114.trusted.net) failed
> Apr  9 06:47:40 ns tcp-env[17281]: refused connect from 209.140.0.114
> Apr  9 06:56:54 ns tcp-env[17346]: connect from murphy.debian.org
> Apr  9 06:58:38 ns tcp-env[17364]: warning: /etc/hosts.allow, line 11: can't 
> verify hostname: gethostbyname(114.trusted.net) failed
> Apr  9 06:58:38 ns tcp-env[17364]: refused connect from 209.140.0.114
> 
> 
> Is this because my hosts.deny file is set to ALL: PARANOID 

No.  Your DNS setup is broken.

% host -t ptr 209.140.0.114
Name: 114.trusted.net
Address: 209.140.0.114

% host 114.trusted.net
114.trusted.net does not exist (Authoritative answer)


You need forward DNS which matches the reverse.  Otherwise, an attacker
could do something like the following ...

goodppl.example.net has 192.168.1/24
badppl.example.net have 192.168.6/24

Set reverse DNS for 192.168.6.66 to point to ours.goodppl.example.net.

Hey presto, badppl can bypass all your filters easily, and nothing you
can do about it.

Matching forward and reverse DNS is a Good Thing(tm).
-- 
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
 We believe in world peace through extortionate license fees."  -Bluemeat

Re: How do I add a second IP range to a network?

2000-04-10 Thread Phil Pennock

Typing away merrily, elyograg produced the immortal words:
> I was thinking about this recently, and here's what I reasoned (but have 
> never put to the test).  Due to the way that reverse DNS works, what would 
> have to happen is whatever body gave you the address space would have to 
> actually create an entry in their server for each address - yes, 62 
> entries, that delegates DNS for those addresses to your DNS server.  Either 
> that or they just have to provide the reverse DNS for you.
> 
> As for how to handle secondary DNS, I'm still scratching my head trying to 
> work that one out.

BCP 20.  Which is currently RFC 2317.  Titled "Classless IN-ADDR.ARPA
delegation".

Follow that, and most things should work, with the caveats stated
therein about older BIND servers.
-- 
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
 We believe in world peace through extortionate license fees."  -Bluemeat

Re: System clock

2000-04-07 Thread Phil Pennock

Typing away merrily, Doug Bean << Mr Bean's Internet >> produced the immortal 
words:
> I have a small problem with the way my system clocks are setup.
> What I am trying to do is sync my local time and UTC so they are the same.
> At the moment they seem to be 10 hours apart. I have tried tzconfig but that
> does not ask if i want my system clock and hwclock to be in sync or not to
> refer to the UTC at all.
> 
> My timezone is set correctly.
> I just need to sync UTC time with local time.

This doesn't make sense.  If your local time isn't UTC/GMT, then you
can't sync them - the localtime is _defined_ as an offset from GMT/UTC
(I know I know, there's a difference between UTC & GMT ...)

What exactly do you really mean?  You want the hardware clock to reflect
local time?  This is a bad idea, because it makes the summertime
transitions much harder and confuses the issue of remote logins.
However, if you're dual-booting to another operating system which
insists on storing localtime in the BIOS clock (in which case, why is
this on debian-isp?) then try the --localclock option to /sbin/hwclock
as documented in the manual-page.  I've never tried this, so can't
comment.
-- 
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
 We believe in world peace through extortionate license fees."  -Bluemeat

Re: Email confirmation...

2000-04-05 Thread Phil Pennock

Typing away merrily, Jerzy Miszczyk produced the immortal words:
> Is there a program or a script which sends a info to the sender that the 
> email was successfully downloaded from the server by the receiver?

Not directly.  Email works with co-operating systems using a given
protocol.  The base protocol doesn't allow for that.

Options:
 (1) Work with the protocol.  Use DSN - Delivery Status Notification -
 which relies upon the mail client at the far side honouring it, or
 perhaps a POP3 server could send the notification.  I'm not
 familiar enough with it.
 (2) I'll stress that I'm not personally familiar with this option
 either.  However ... if the remote person is using Windows or a
 web-browser to read their mail (relatively likely) then unless
 they've been keeping up to date on security patches, there will be
 ways to embed JavaScript in the mail.

Either way, you're not going to really succeed in promoting this.  The
only realistic option is if you can control the choice of software used
by the recipient, in which case you're probably the sysadmin (or
interfering manager ;^) in an organisation and installing, eg, Lotus
Notes or other 'group' software.  If you control the mail servers used
by the sender and recipient, then I _think_ you can enable DSN receipts
from there.  I'm not sure.

The general Internet doesn't really use DSN and isn't likely to take it
up in large numbers - many regard it as an invasion of privacy.

mutt(1) can support use of DSN, but it's not enabled by default.

See also RFC 1894.
-- 
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
 We believe in world peace through extortionate license fees."  -Bluemeat

Re: Perl/C programmers, help pls

2000-04-03 Thread Phil Pennock

Typing away merrily, Phil Pennock produced the immortal words:
> shell_prompt$ perl -i.old \
>   -e 's{http://209.155.163.97/}{http://www.pexchange.com/}g' \
>   $(find THOSE_DIRECTORIES -name \*.cgi -print)

Need more coffee.  Hopefully it's obvious that THOSE_DIRECTORIES should
be replaced with a whitespace-separated list of the top-level
directories where those .cgi files are.  I should have mentioned that
before.  Sorry.
-- 
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
 We believe in world peace through extortionate license fees."  -Bluemeat

Re: Perl/C programmers, help pls

2000-04-03 Thread Phil Pennock

Typing away merrily, Chad A. Adlawan produced the immortal words:
> we have something like 30,000 ++ small files lying around different 
> subdirectories, named 01.cgi ++.  (from Ultimate Bulletin Board, 
> www.ultimatebb.com, and let me add that their customer support sucks and 
> their documentation is even worse)

You poor bastard.  I had to examine the code for their commercial
version after the BugTraq alerts.  I have never seen such a pile of
shite which someone has dared to charge money for.  Methinks I made my
opinion clear enough to the guy who manages the site run with it.  ;^)

>  can someone please help me with a script w/c searches the contents of 
> all those small files and looks for __"http://209.155.163.97/__ and then 
> replaces them with __"http://www.pexchange.com/__ ? 

man perlrun(1) to see about being able to edit files in place, saving
backups.  Then, from shell-prompt (and this in untested, so take backups
and lots of them :^) :
shell_prompt$ perl -i.old \
  -e 's{http://209.155.163.97/}{http://www.pexchange.com/}g' \
  $(find THOSE_DIRECTORIES -name \*.cgi -print)

which should do the job quite nicely.  Note the backslashes - you can
omit them if you make sure to type those three lines as one.

HTH
-- 
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
 We believe in world peace through extortionate license fees."  -Bluemeat

Re: Quote of the day...

2000-04-03 Thread Phil Pennock

Typing away merrily, Matt Harmon produced the immortal words:
> At 23:01 4/2/00 +0200, Paul van Empelen wrote:
> ...
> > > A trolley with a console and keyboard (..) has been raised as a
> > > requirement for the Unix platform (..).  However, the canteen
> > > asked their trolley back, and Mike doesn't have budget to buy a
> > > new one.
> .
> >Now, do I work for a strange company, or does it sound familiar to you?
> 
> Something like this happens practically every d%%med day at my workplace. 
> It's lovely when the accountants drive everything at a company...They must 
> still be pissed that most payroll accounting is now handled by *computers*.

Check your contract.  See how much you can charge for having to come
into work out of normal hours.  Inflate this figure as much as you can.

Then point out how, in comparison, console servers are quite cheap.
With them, the need for a console & keyboard more of less disappears.
For those who aren't familiar: these devices typically have about 12
'cpu' serial connections each.  Each of those is attached to the serial
port of a Unix box, and provides things like history, etc.  The boxes
have an embedded OS, which allows you to switch between serial lines, go
into 'direct' mode, do some stuff, escape out, switch to another box,
etc.  The servers have a few other ports.  One of which you connect to
a serial port on a 'master' box which you can ssh into.  Then you just
ssh into that box, tip/kermit to the port connecting you to the console
server, and connect from there to the console of whichever machine you
want.

If you can choose for the interface machine a really reliable box, then
you're onto a winner.

Even more so if you can cost-justify a Remote Power-Bar.  Getting called
up at 3am and being able to just:
 (1) Stagger over to computer [i]
 (2) Log in, dial up, ssh in
 (3) Go to console server, from there go a an RPB
 (4) Remotely toggle the power-supply to a machine
 (5) Log out
 (6) Go back to bed
has numerous advantages to courses of action involving getting dressed
and staggering through a biting cold, probably rainy, night into work.

HTH HAND

[i] I really ought to get that WYSE terminal working - it's silent, so I
have it next to my bed.  I really want to be able to fix things
without getting out of bed and without having noisy computers in my
bedroom.
-- 
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
 We believe in world peace through extortionate license fees."  -Bluemeat

Re: restricted ftp (binded to a private net only)

2000-03-31 Thread Phil Pennock

Typing away merrily, Chad A. Adlawan produced the immortal words:
> our web server has 2 NIC's on it, one's a public IP and the other a 
> private 10.1.1.x.  
> can someone shed me some light as to how do i provide ftp service in that 
> server BUT the daemon has to be visible on the 10.1.1.x network only ?
> 
> this is because we want only ports 80, 25 & 22 to be visible from the 
> outside.

xinetd:
 
<http://cgi.debian.org/cgi-bin/search_packages.pl?keywords=xinetd&searchon=names&version=stable&release=all>

  Release  Quality Package   (size)
  stable   100%xinetd 2.2.1-8.1  (87.7k) 
replacement for inetd with many enhancements

Such enhancements including, eg, ability to bind to a specific interface
on a machine.

And the xinetd.conf syntax is signicantly cleaner than traditional
inetd.conf (IMHO).
-- 
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
 We believe in world peace through extortionate license fees."  -Bluemeat

Postfix and SASL

More Postfix and SASL excitement

More Postfix and SASL excitement

re: LDAP in an ISP

re: LDAP in an ISP

Re: FTP upload by email

Re: it's safe to run a web hosting server with the unstable distributions ?

Re: it's safe to run a web hosting server with the unstable distributions ?

Re: it's safe to run a web hosting server with the unstable distributions ?

Re: it's safe to run a web hosting server with the unstable distributions ?

Re: it's safe to run a web hosting server with the unstable distributions ?

Re: it's safe to run a web hosting server with the unstable distributions ?

Re: it's safe to run a web hosting server with the unstable distributions ?

Re: it's safe to run a web hosting server with the unstable distributions ?

Re: tracing a PERL cgi script

Re: Strange message in logs

Re: How do I add a second IP range to a network?

Re: System clock

Re: Email confirmation...

Re: Perl/C programmers, help pls

Re: Perl/C programmers, help pls

Re: Quote of the day...

Re: restricted ftp (binded to a private net only)

23 matches

Site Navigation

Mail list logo

Footer information