[31852] in Perl-Users-Digest
Perl-Users Digest, Issue: 3115 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Sep 4 11:09:20 2010
Date: Sat, 4 Sep 2010 08:09:04 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 4 Sep 2010 Volume: 11 Number: 3115
Today's topics:
Re: Multidimensional array <paul@pstech-inc.com>
Re: Multidimensional array <tadmc@seesig.invalid>
Re: Multidimensional array <jurgenex@hotmail.com>
Re: Multidimensional array <hjp-usenet2@hjp.at>
Re: Multidimensional array <m@rtij.nl.invlalid>
Re: Multidimensional array <paul@pstech-inc.com>
Re: Multidimensional array <ben@morrow.me.uk>
Re: Multidimensional array <mvdwege@mail.com>
Re: Multidimensional array <notvalid@cox.net.invalid>
Re: Multidimensional array <jurgenex@hotmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 3 Sep 2010 18:55:11 -0400
From: "Paul E. Schoen" <paul@pstech-inc.com>
Subject: Re: Multidimensional array
Message-Id: <o1fgo.12619$IH1.1035@newsfe18.iad>
"Tad McClellan" <tadmc@seesig.invalid> wrote in message
news:slrni82a6f.6j3.tadmc@tadbox.sbcglobal.net...
> Jim Gibson <jimsgibson@gmail.com> wrote:
>> In article <jbg18695fd08g0nfb7h1l5j3tm8eq9g9fr@4ax.com>, Jürgen Exner
>><jurgenex@hotmail.com> wrote:
>>
>>> "Paul E. Schoen" <paul@pstech-inc.com> wrote:
>>>
>>> >The server that will most likely host this is Apache. But as mentioned
>>> >elsewhere setting it up is non-trivial and one more thing I don't want
>>> >to
>>> >mess with at this point. I can run the script locally but I had to use
>>> >goto
>>> >statements to spaghetti code around the CGI stuff and simulate the data
>>> >from
>>> >the HTML page.
>>>
>>> ???
>>> You did read the section "DEBUGGING" in "perldoc CGI", didn't you?
>>
>> As far as I can tell, Paul is not using the CGI module.
>
>
> Despite being shown how it can be a drop-in replacement for
> what he is using with only 2 lines of code.
>
> If Paul feels free to ignore the advice given here, then it will likely
> become the case that folks will feel free to ignore his posts
> altogether...
>
> You reap what you sow.
I'm not intentionally ignoring your advice, but I am trying to achieve a
working level of proficiency and understanding, which is mostly having
something that does most of what I aim to do. Today I tried using command
line parameters as well as using "< textfile" to simulate the HTTP request
from the HTML form. But I could not get it to work on my local machine or on
the Smart.net host.
Then I added a debug file that would be written to at several key places in
the script. This helped me to see that the DBI module seemed to be lacking
on the remote host, as well as the DateTime module. So I had one problem
running the script on my local machine, and another on the remote host. I
tried to contact the Smart.net administrator, but no reply yet.
I had an email reminder that my free 30 day Dreamhost account was about to
expire and it was set for autorenewal on my credit card which was about $35
for a year. So I uploaded the local website to that host, which required a
few changes to the EventProcessor.pl script, and now it seems to be working
perfectly. I had some security issues but I used chmod 711 for the cgi-bin
and now I don't get the directory of files as I had previously.
The Dreamhost forum was very helpful in finding the problem with the
location of sendmail, and the reply to the OP also showed a security
problem: http://discussion.dreamhost.com/thread-126568.html. I did not
realize that user-provided data could be used for exploit by spammers, but
the fix provided seems simple enough.
Thanks for being patient and providing much needed help.
Paul
------------------------------
Date: Fri, 03 Sep 2010 19:05:33 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Multidimensional array
Message-Id: <slrni832t7.7n3.tadmc@tadbox.sbcglobal.net>
Paul E. Schoen <paul@pstech-inc.com> wrote:
>
> "Tad McClellan" <tadmc@seesig.invalid> wrote in message
> news:slrni82a6f.6j3.tadmc@tadbox.sbcglobal.net...
>> Jim Gibson <jimsgibson@gmail.com> wrote:
>>> In article <jbg18695fd08g0nfb7h1l5j3tm8eq9g9fr@4ax.com>, Jürgen Exner
>>><jurgenex@hotmail.com> wrote:
>>>
>>>> "Paul E. Schoen" <paul@pstech-inc.com> wrote:
>>>>
>>>> >The server that will most likely host this is Apache. But as mentioned
>>>> >elsewhere setting it up is non-trivial and one more thing I don't want
>>>> >to
>>>> >mess with at this point. I can run the script locally but I had to use
>>>> >goto
>>>> >statements to spaghetti code around the CGI stuff and simulate the data
>>>> >from
>>>> >the HTML page.
>>>>
>>>> ???
>>>> You did read the section "DEBUGGING" in "perldoc CGI", didn't you?
>>>
>>> As far as I can tell, Paul is not using the CGI module.
>>
>>
>> Despite being shown how it can be a drop-in replacement for
>> what he is using with only 2 lines of code.
>>
>> If Paul feels free to ignore the advice given here, then it will likely
>> become the case that folks will feel free to ignore his posts
>> altogether...
>>
>> You reap what you sow.
>
> I'm not intentionally ignoring your advice, but I am trying to achieve a
> working level of proficiency and understanding,
Replace the 2 lines that I showed you, and your working program
(with the hokey library) should continue to work (with CGI.pm).
> Today I tried using command
> line parameters as well as using "< textfile" to simulate the HTTP request
> from the HTML form. But I could not get it to work on my local machine or on
> the Smart.net host.
With CGI.pm you would test it from the command line thus:
someprog name=Paul email='paul@pstech-inc.com'
Simple!
> I had some security issues
^^^
^^^
Past tense?
I am quite certain that you are being overly optimistic there.
The code you showed some time ago was vulnerable to a Denial Of
Service attack. Have you mitigated that one somehow?
> I did not
> realize that user-provided data could be used for exploit by spammers,
You will be cracked. I see it coming...
Perl has a feature called "taint checking" that can help mitigate
that risk:
perldoc perlsec
> but
> the fix provided seems simple enough.
The fix is ass backwards.
It specifies "bad" characters.
The proper approach is to specify "good" characters.
That is, you don't try and idenfify what might be harmful (what if you
miss one?) you instead specify what you will allow.
Since you are doing something with mail, you have surely searched
the Perl FAQ for that term
perldoc -q mail
and have seen the answer to
How do I check a valid mail address?
I trust.
If not, then use the FAQ Luke!
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Fri, 03 Sep 2010 19:36:29 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Multidimensional array
Message-Id: <tdb386t4ld8bt6fkihn54ps04hvvkf0ue1@4ax.com>
ccc31807 <cartercc@gmail.com> wrote:
>Your statement that "it is quite stupid to do any development work on
>a live web server" struck me as reasonable in general but as an
>overstatement. If you do 'development work' you HAVE to use a 'live
>web server.'
For eventual deployment obviously yes, for development most certainly
not.
>That doesn't mean that you screw around with production
>code,
So now you are saying you shouldn't develop on a live server? Maybe you
can make up your mind?
>although sometimes you will, either by necessity or by
>convenience or sometimes by sheer stupidity.
Not arguing those exceptions.
>Words have meanings, and we need to pay attention to the clear and
>plain meanings of words. If we want to communicate with others, we
>can't insist on idiosyncratic usage, but need to use words in their
>generally understood meaning.
Right. Then why don't you do that? "Live server" has a well established
and generally understood meaning in the relevant industry.
Or are you looking for scissors, needle, and thread, too, when your boss
asks you to move the "button" 2 cm to the right ?
>If I'm guilty of anything, it's a
>reluctance to use jargon and a preference for common usage as opposed
>to technical usage.
It has nothing to do with jargon, but with established industry-wide
terminology.
If you don't get the difference between a live server and an alive
server, then that is certainly not my problem.
*PLONK*
jue
------------------------------
Date: Sat, 4 Sep 2010 09:29:10 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Multidimensional array
Message-Id: <slrni83ta7.ue6.hjp-usenet2@hrunkner.hjp.at>
On 2010-09-03 01:03, Jürgen Exner <jurgenex@hotmail.com> wrote:
> Absolutely. Developing on a test server has significant advantages over
> developing on a live server:
> - If you make a mistake you are taking down only the test server, not
> the live server with maybe hundreds of thousands of customers
> - It is far less likely that crackers can break into the system due to
> security holes in the unfinished code, because the system is not open to
> the public
> - Even if they do manage to break in the rewards are meager: they only
> get access to mockup data instead of PII, financial, confidential and
> other critical customer data
> - You can try your code without risking to majorly screw up your live
> customer data
> - You can try unusual and rare data combinations without messing up your
> live data, e.g. have the fictitious visiting business man in Bangkok
> enter his name in Hangul and his current location in full lenght Thai
> (http://en.wikipedia.org/wiki/Bangkok#Full_name).
>
> Still, it has some serious drawbacks:
> - the test team will be upset because you are changing their test
> environment constantly. Therefore there is no way to create a reliable
> repro scenario
It's still better if your test team is upset than if your
customers/users are upset because you are changing their work
environment constantly :-).
If a constantly changing (due to development) testing environment is a
problem, you probably want to add another layer, not subtract one. So
you would have a development system, a test system and a production
system.
> - management will be upset because the vast majority of bugs found will
> be of the kind "Server Error 500: Syntax error in line 42", which could
> have been found much much cheaper by running "perl -c" instead of having
> a human actually call the site in a browser.
How would a test server prevent me from invoking "perl -c"? Especially
compared to a production server which often has a much more restrictive
environment?
> - everyone will be upset because they are blocked from doing anything
> until you fix that syntax error. And even worse, nobody knows if you are
> actively working on a fix, are taking an urgent leak, or have gone home
> for a 2 week vacation.
Again, that's an advantage of the test server, not a disadvantage. If
your test server is down because of a syntax error "everyone" is just
the test team (and possibly your co-developers). If that happens on your
production system, "everyone" is all your users.
For me the most important drawback of a test server is that it isn't
identical to the live server:
* often you don't have the same data, only mockups.
* real users use the system differently than testers
* the load is (usually) smaller
* hard- and software may be different
So it may be difficult to reproduce problems on the test system.
hp
------------------------------
Date: Sat, 4 Sep 2010 11:06:07 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Multidimensional array
Message-Id: <voe9l7-556.ln1@news.rtij.nl>
On Sat, 04 Sep 2010 09:29:10 +0200, Peter J. Holzer wrote:
>
> If a constantly changing (due to development) testing environment is a
> problem, you probably want to add another layer, not subtract one. So
> you would have a development system, a test system and a production
> system.
>
But then the people doing testing will change the test server! That's not
acceptable to the people doing acceptance. So lets another layer and add
an acceptance server. Let's call it Development-Test-Acceptance-
Production (DTAP). What a novel concept! :-)
M4
------------------------------
Date: Sat, 4 Sep 2010 05:37:21 -0400
From: "Paul E. Schoen" <paul@pstech-inc.com>
Subject: Re: Multidimensional array
Message-Id: <trogo.33180$LL1.6655@newsfe24.iad>
"Tad McClellan" <tadmc@seesig.invalid> wrote in message
news:slrni832t7.7n3.tadmc@tadbox.sbcglobal.net...
> Paul E. Schoen <paul@pstech-inc.com> wrote:
>
>> I'm not intentionally ignoring your advice, but I am trying to achieve a
>> working level of proficiency and understanding,
>
> Replace the 2 lines that I showed you, and your working program
> (with the hokey library) should continue to work (with CGI.pm).
I did that, and it works very well. I did not really understand the package
concept, but it is really very much like the USES statement in Delphi. But I
didn't realize that the CGI package had the same function as the code in my
script for handling the vars.
>> Today I tried using command
>> line parameters as well as using "< textfile" to simulate the HTTP
>> request
>> from the HTML form. But I could not get it to work on my local machine or
>> on
>> the Smart.net host.
>
> With CGI.pm you would test it from the command line thus:
>
> someprog name=Paul email='paul@pstech-inc.com'
>
> Simple!
I was able to get that to work on my local machine, but there is a Full_Name
variable that has spaces in it, and I did not find any way to use it in
command line parameters. It. is important because I am using that as a form
of password. But I could change it for testing
>> I had some security issues
> ^^^
> ^^^
>
> Past tense?
>
> I am quite certain that you are being overly optimistic there.
>
> The code you showed some time ago was vulnerable to a Denial Of
> Service attack. Have you mitigated that one somehow?
I'm not sure how it is vulnerable to a DOS attack, or if that is likely to
occur. This form will be accessed by only a few Sierra Club members, and the
correct Full_Name must be provided in order to proceed. Otherwise it returns
"Unauthorized User". If the correct name is given, then the event
information is verified for reasonable values (in the Submission Form's
JavaScript), before it will make the HTTP request to the CGI script.
Of course anyone could look at the HTML source and find the URL of the perl
script so it could be accessed from another site. Perhaps the perl script
with the passwords in the cgi-bin could be examined and exploited in some
way, but it would just send emails to me indicating new events have been
posted, and the email includes the website URL where it originated (which
should be my hosts). The Email provided is only for further identification
of the senders.
>> I did not
>> realize that user-provided data could be used for exploit by spammers,
> You will be cracked. I see it coming...
>
> Perl has a feature called "taint checking" that can help mitigate
> that risk:
>
> perldoc perlsec
I am concerned about security and I'd like to know if this is really likely
to be subject to a malicious and debilitating attack, and find ways to
mitigate the damage or protect it. I'll look into the "taint checking"
>> but the fix provided seems simple enough.
>
>
> The fix is ass backwards.
>
> It specifies "bad" characters.
>
> The proper approach is to specify "good" characters.
>
> That is, you don't try and idenfify what might be harmful (what if you
> miss one?) you instead specify what you will allow.
>
> Since you are doing something with mail, you have surely searched
> the Perl FAQ for that term
>
> perldoc -q mail
>
> and have seen the answer to
>
> How do I check a valid mail address?
>
> I trust.
>
>
> If not, then use the FAQ Luke!
I can see that there is a huge amount of information to assimilate and this
may be more of a challenge than I want to tackle. But I'm learning a lot and
it's actually fun when I make progress. Sometimes I just don't know what to
look for or where to find it. I generally check the FAQ and do a web search,
but sometimes the resources are not very good, as was the case with this
simple mailer that I used and modified.
Now I have been working on the HTML submission form and JavaScript to make
sure the data is reasonable. I suppose it's best to do that at that level so
that the events will be consistently formatted. I added a simple date picker
that works pretty well, and I also found a simple calendar, but a fancier
version was just too complex. And of course that is OT for this NG, but it
helps to see the big picture from the input provided by the user to the
final usage in the website.
I appreciate the help, and I understand your frustration with my bumbling
attempts at getting this working.
Paul
------------------------------
Date: Sat, 4 Sep 2010 12:02:26 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Multidimensional array
Message-Id: <2jl9l7-qam2.ln1@osiris.mauzo.dyndns.org>
Quoth "Paul E. Schoen" <paul@pstech-inc.com>:
>
> "Tad McClellan" <tadmc@seesig.invalid> wrote in message
> news:slrni832t7.7n3.tadmc@tadbox.sbcglobal.net...
> >
> > With CGI.pm you would test it from the command line thus:
> >
> > someprog name=Paul email='paul@pstech-inc.com'
> >
> > Simple!
>
> I was able to get that to work on my local machine, but there is a Full_Name
> variable that has spaces in it, and I did not find any way to use it in
> command line parameters.
If you are using a Unix machine,
Full_Name='Some Value With Spaces'
If you are using Win32,
Full_Name="Some Value With Spaces"
Learn to use your OS.
> It. is important because I am using that as a form
> of password. But I could change it for testing
That's a pretty poor password.
> >> I had some security issues
> > ^^^
> > ^^^
> >
> > Past tense?
> >
> > I am quite certain that you are being overly optimistic there.
> >
> > The code you showed some time ago was vulnerable to a Denial Of
> > Service attack. Have you mitigated that one somehow?
>
> I'm not sure how it is vulnerable to a DOS attack, or if that is likely to
> occur. This form will be accessed by only a few Sierra Club members,
*BAD* assumption. The form will also be accessed by a whole lot of
crackers looking to cause troouble with it any way they can. Your job is
to make sure that's impossible, and to do so *before* you put the script
up on the public Internet.
> and the
> correct Full_Name must be provided in order to proceed. Otherwise it returns
> "Unauthorized User". If the correct name is given, then the event
> information is verified for reasonable values (in the Submission Form's
> JavaScript),
Not anywhere *near* good enough. It's trivial to make a request without
going through the JavaScript (Perl even provides a convenient library
for doing exactly that). You *must* do all your security checks
server-side. (If you want to do them client-side as well, that's OK, but
you mustn't rely on that having been done.)
A full name is also a *really* bad password. Give people real passwords.
There are programs (and, probably, websites) that will generate
reasonably-strong-but-reasonably-memorable passwords for you.
You should also not be storing passwords *anywhere* in plain text. Look
into using encrypted passwords (and don't use perl's builtin 'crypt'
unless you know the version on your system is strong enough).
> before it will make the HTTP request to the CGI script.
>
> Of course anyone could look at the HTML source and find the URL of the perl
> script so it could be accessed from another site. Perhaps the perl script
> with the passwords in the cgi-bin could be examined and exploited in some
> way, but it would just send emails to me indicating new events have been
> posted,
Uh... if this form just sends email to you, what's the point? (That is,
why can't your users just send you email?) If it does more than that,
like actually putting content up on the website, then it *will* be
exploited by spammers.
> > Perl has a feature called "taint checking" that can help mitigate
> > that risk:
> >
> > perldoc perlsec
>
> I am concerned about security and I'd like to know if this is really likely
> to be subject to a malicious and debilitating attack,
It is really likely. *Anything* Internet-accessible is.
> and find ways to
> mitigate the damage or protect it. I'll look into the "taint checking"
Good.
> Now I have been working on the HTML submission form and JavaScript to make
> sure the data is reasonable. I suppose it's best to do that at that level so
> that the events will be consistently formatted.
Nope. See above. You *mustn't* trust the client.
Ben
------------------------------
Date: Sat, 04 Sep 2010 15:53:22 +0200
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: Multidimensional array
Message-Id: <867hj162el.fsf@gareth.avalon.lan>
"Paul E. Schoen" <paul@pstech-inc.com> writes:
> "Tad McClellan" <tadmc@seesig.invalid> wrote in message
>>
>> Perl has a feature called "taint checking" that can help mitigate
>> that risk:
>>
>> perldoc perlsec
>
> I am concerned about security and I'd like to know if this is really
> likely to be subject to a malicious and debilitating attack, and find
> ways to mitigate the damage or protect it. I'll look into the "taint
> checking"
>
Let me don my professional hat here (I'm a security guy): yes, any code
that handles outside data is subject to attack.
Perl's taint mode is brilliant because it forces you to validate all
external inputs before processing. If you don't do any checking on
external inputs, your code will die.
Of course, taint mode will not stop you from writing stupid input
checks, but at least it will force you to think about input validation.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Sat, 04 Sep 2010 10:01:55 -0400
From: John Mason Jr <notvalid@cox.net.invalid>
Subject: Re: Multidimensional array
Message-Id: <i5tjgm$rcq$1@news.eternal-september.org>
On 9/4/2010 5:37 AM, Paul E. Schoen wrote:
>
> "Tad McClellan" <tadmc@seesig.invalid> wrote in message
> news:slrni832t7.7n3.tadmc@tadbox.sbcglobal.net...
>> Paul E. Schoen <paul@pstech-inc.com> wrote:
>>
>>> I'm not intentionally ignoring your advice, but I am trying to achieve a
>>> working level of proficiency and understanding,
>>
>> Replace the 2 lines that I showed you, and your working program
>> (with the hokey library) should continue to work (with CGI.pm).
>
> I did that, and it works very well. I did not really understand the
> package concept, but it is really very much like the USES statement in
> Delphi. But I didn't realize that the CGI package had the same function
> as the code in my script for handling the vars.
>
>>> Today I tried using command
>>> line parameters as well as using "< textfile" to simulate the HTTP
>>> request
>>> from the HTML form. But I could not get it to work on my local
>>> machine or on
>>> the Smart.net host.
>>
>> With CGI.pm you would test it from the command line thus:
>>
>> someprog name=Paul email='paul@pstech-inc.com'
>>
>> Simple!
>
> I was able to get that to work on my local machine, but there is a
> Full_Name variable that has spaces in it, and I did not find any way to
> use it in command line parameters. It. is important because I am using
> that as a form of password. But I could change it for testing
>
>
>>> I had some security issues
>> ^^^
>> ^^^
>>
>> Past tense?
>>
>> I am quite certain that you are being overly optimistic there.
>>
>> The code you showed some time ago was vulnerable to a Denial Of
>> Service attack. Have you mitigated that one somehow?
>
> I'm not sure how it is vulnerable to a DOS attack, or if that is likely
> to occur. This form will be accessed by only a few Sierra Club members,
> and the correct Full_Name must be provided in order to proceed.
> Otherwise it returns "Unauthorized User". If the correct name is given,
> then the event information is verified for reasonable values (in the
> Submission Form's JavaScript), before it will make the HTTP request to
> the CGI script.
>
> Of course anyone could look at the HTML source and find the URL of the
> perl script so it could be accessed from another site. Perhaps the perl
> script with the passwords in the cgi-bin could be examined and exploited
> in some way, but it would just send emails to me indicating new events
> have been posted, and the email includes the website URL where it
> originated (which should be my hosts). The Email provided is only for
> further identification of the senders.
>
>>> I did not
>>> realize that user-provided data could be used for exploit by spammers,
>
>> You will be cracked. I see it coming...
>>
>> Perl has a feature called "taint checking" that can help mitigate
>> that risk:
>>
>> perldoc perlsec
>
> I am concerned about security and I'd like to know if this is really
> likely to be subject to a malicious and debilitating attack, and find
> ways to mitigate the damage or protect it. I'll look into the "taint
> checking"
>
>
>>> but the fix provided seems simple enough.
>>
>>
>> The fix is ass backwards.
>>
>> It specifies "bad" characters.
>>
>> The proper approach is to specify "good" characters.
>>
>> That is, you don't try and idenfify what might be harmful (what if you
>> miss one?) you instead specify what you will allow.
Another good resource for web app security
http://www.owasp.org/index.php/Main_Page
and to get an idea of the problems you can face
http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
John
------------------------------
Date: Sat, 04 Sep 2010 07:14:40 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Multidimensional array
Message-Id: <r4j486papbs29ehegabbjvdiaq3m1j7lq0@4ax.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>On 2010-09-03 01:03, Jürgen Exner <jurgenex@hotmail.com> wrote:
>> Absolutely. Developing on a test server has significant advantages over
>> developing on a live server:
>> - If you make a mistake you are taking down only the test server, not
>> the live server with maybe hundreds of thousands of customers
>> - It is far less likely that crackers can break into the system due to
>> security holes in the unfinished code, because the system is not open to
>> the public
>> - Even if they do manage to break in the rewards are meager: they only
>> get access to mockup data instead of PII, financial, confidential and
>> other critical customer data
>> - You can try your code without risking to majorly screw up your live
>> customer data
>> - You can try unusual and rare data combinations without messing up your
>> live data, e.g. have the fictitious visiting business man in Bangkok
>> enter his name in Hangul and his current location in full lenght Thai
>> (http://en.wikipedia.org/wiki/Bangkok#Full_name).
>>
>> Still, it has some serious drawbacks:
>> - the test team will be upset because you are changing their test
>> environment constantly. Therefore there is no way to create a reliable
>> repro scenario
>
>It's still better if your test team is upset than if your
>customers/users are upset because you are changing their work
>environment constantly :-).
>
>If a constantly changing (due to development) testing environment is a
>problem, you probably want to add another layer, not subtract one. So
>you would have a development system, a test system and a production
>system.
Congratulations, you just won 100 points.
>> - management will be upset because the vast majority of bugs found will
>> be of the kind "Server Error 500: Syntax error in line 42", which could
>> have been found much much cheaper by running "perl -c" instead of having
>> a human actually call the site in a browser.
>
>How would a test server prevent me from invoking "perl -c"? Especially
>compared to a production server which often has a much more restrictive
>environment?
Nowhere did I say it prevents you from doing so. But _if_ you are
developing on the test server then the damage is already done the moment
you hit "Save" in your favourite editor, i.e. _before_ you even get a
chance to run perl -c.
Although certainly better than developing on the live server, test
servers are still not a good development environment. That's why you
have a development environment on your own local computer where you can
screw around and experiment to your hearts desire without affecting
anyone else when things go wrong.
>> - everyone will be upset because they are blocked from doing anything
>> until you fix that syntax error. And even worse, nobody knows if you are
>> actively working on a fix, are taking an urgent leak, or have gone home
>> for a 2 week vacation.
>
>Again, that's an advantage of the test server, not a disadvantage. If
>your test server is down because of a syntax error "everyone" is just
>the test team (and possibly your co-developers). If that happens on your
>production system, "everyone" is all your users.
Congratulations, you just won another 100 points. Keep up the good work
and you may reach 500 soon.
>For me the most important drawback of a test server is that it isn't
>identical to the live server:
Unfortunately that is quite true. While you can try to make them as
similar as possible more often than not this is impossible.
> * often you don't have the same data, only mockups.
Which on the other hand can be a good thing, too. It not only protects
potentially highly sensitive real data from theft and damage (where
there is no real data it cannot be stolen or damaged) but also allows
you to test data configurations that you couldn't use in the live
service.
> * real users use the system differently than testers
> * the load is (usually) smaller
True and true. But can be mitigated to some extend by carefully
designing the test plan and running load simulations. Still, you are
right, it is not the real deal.
> * hard- and software may be different
This is IMO the main problem. Even if you do invest in a large set of
identical hardware(*) there will always be some differences. That's one
reason why you want to keep the software suite running on a server as
minimal as possible. The smaller it is the easier it is to keep it
synchronized between different machines.
Unfortunately this goes only that far, e.g. the test team needs their
own test tools on their test servers. Or production wants to run their
own service monitoring tools on live servers. Which in turn you could
run on the test servers, too, but then you would have to simulate the
same load on the monitoring tools as in production, etc, etc, etc.
So yeah, at some point you will have to decide how similar is similar
enough.
*: and in the business world there are even contracts which guarantee
that identical hardware will be available for x years to come for
replacements and expansion of the system. Very expensive!
>So it may be difficult to reproduce problems on the test system.
Oh so true....
jue
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3115
***************************************
