php: developing on linux, running on windows

[Thuleman]

The Bing was full of info about running PHP code on Windows with IIS and FastCGI, but as always I put more trust in the opinions of [H]ers than just random dudes on the net.

It's understood that some PECL extensions are not available on Windows, but apart from that, what, if any, are the factual drawbacks of serving PHP on Windows, especially considering that the overall load will be light (i.e. 2,000 hits a day).

As far as I can tell, just as long as the dev is aware that the production box is Windows, there shouldn't be any show-stoppers. As far as mod_rewrite goes, there's micronovae IIS Mod-Rewrite for that.

 

[Sgraffite]

Some random stuff that comes to mind, I don't even know the answers myself so take it with a grain of salt:

1. If the dev will be doing any sort of remote administration from linux, I would think it would be much easier to remote administer a linux box since you can just ssh in. I've never tried any remote administration of a windows box from a linux box, so maybe that is easy as well.

2. As far as security, is there a way to give the database login different permissions than the apache user? This would be so that SQL can't write php files into the php webserver area, and be accessed through the webserver. I know that's a long shot, but something to keep in mind I guess.

3. Will the dev need to use cron scripts, or an equivalent? If so is there a way for him to do that on a windows box from a linux box?

 

[ameoba]

If you know you're going to be forced to deploy on a Windows box, you should be doing your development on a Windows box. If your tied to Win+IIS, why not do some ASP - a platform that actually targets your server?

PHP on Windows generally works, but there's a bunch of little things that can get in the way. Windows+IIS is a shitty environment for PHP - Win+Apache is better, but *nix+Apache is really where you should be.

 

[Thuleman]

The premise is that the Windows environment is mandated, the dev isn't involved in the system admin side of things, and the dev knows PHP, not ASP/.Net.

Basically the scope of the work is to run Wordpress, some Google Apps API stuff (i.e. calendar, and then look into developing simple apps or customize existing ones, such as an image catalog, etc.

I saw that on http://php.iis.net Wordpress is one of the apps that seems to be well supported on IIS, so that's likely one less thing to worry about.

 

[Whatsisname]

Developing on gnu/linux then running on windows makes no sense whatsoever.

 

[Digital Cro-Magnon]

You should try to have your dev environment match your production. It makes it easier to deploy and will reduce the hidden snafu's you may encounter in moving code from linux to windows.

Also, you can remotely administer windows from linux using some variation of rdesktop or rdc (Remote Desktop), which is has encryption enabled.

 

[PTNL]

PHP and IIS, while not necessarily ideal from some perspectives, can still work. And it looks like you've already done some research on the bigger show-stopper (Wordpress), and you've confirmed that it should be fine.

As long as the developer knows what the target environment is, that should be sufficient. It's the developer's responsibility to manage their code, source control, and file promotions. The server admin(s) have the responsibility for setting up PHP in IIS, user accounts, server configuration(s), and any other preliminary communication. Once PHP and the necessary account(s) are created, the developer should only need FTP/SFTP access to promote content to the web server or staging location. Any additional needs and requests should be routed through the server admin(s). RDP access to the server is not necessary for the developer, and granting such access to a production environment can create issues.

Developing on gnu/linux then running on windows makes no sense whatsoever.

You'd do better by providing some concrete considerations/consequences that you foresee of this potential arrangement.

 

[ameoba]

You'd do better by providing some concrete considerations/consequences that you foresee of this potential arrangement.

Nope. It's precisely because you -don't- know what might go wrong that you should have your dev environment mimic production.

 

[:LJ:]

One problem which often occurs is where you subsequently move from hosting it on Windows to hosting on Linux (you can never predict Random Acts of Management), yet your lazy Windows developers haven't taken any notice of case sensitivity in the file structure, thus making it *only* work on Windows.

Developing on Linux should mitigate this to a certain degree, though.

Incidentally, you do realise that you can run Apache on Windows side-by-side with IIS, and have each one bound to different IP addresses....right? It might help you with the teething problems of getting PHP running under IIS.

 

[eeyrjmr]

php being an interpreted language should only have variations across platform downto the build of php for lin or win.

HOWEVER you mention IIS for window, this could be more of a problem

You can get portable Apache+mysql+php for windows to prove out if the php works fine on windows, reducing the problem downto IIS

would be better if you went Apache in windows but hey...

 

[PTNL]

Nope. It's precisely because you -don't- know what might go wrong that you should have your dev environment mimic production.

I agree that this is ideal. However, you may have missed the true meaning of my post where I requested something concrete for the OP to consider (ie: something better than "makes no sense whatsoever").

One problem which often occurs is where you subsequently move from hosting it on Windows to hosting on Linux (you can never predict Random Acts of Management), yet your lazy Windows developers haven't taken any notice of case sensitivity in the file structure, thus making it *only* work on Windows.

Apathy and bad design choices rest solely on the developer, and not inherent to the deployment environment's OS. And really, this example is niche and not a deal breaker.

 

[Thuleman]

In the end the root cause for the particular issues we are facing are not technical in nature. When you hire someone who's in his mid 40's and has 25 years of "professional experience", you take a gamble. Either you end up with someone who's just plain awesome, or you end up with someone who's set in his ways being too old and inflexible to change/adapt. Which is how you end up in rather impossible situations.

 

[Digital Cro-Magnon]

When you hire someone who's in his mid 40's and has 25 years of "professional experience", you take a gamble. Either you end up with someone who's just plain awesome, or you end up with someone who's set in his ways being too old and inflexible to change/adapt. Which is how you end up in rather impossible situations.

I worked with people in their 20's that could be just as inflexible, mostly I think due to too much hubris. A sign of a good developer regardless of age, is someone who is willing to work with a team and collaborate on ideas and is willing to learn new things. For me, that is why I got into technology, not to just learn COBOL and stay stagnant. Actually, I don't even know COBOL, but I like the example.