Lighttpd error 403 forbidden for php files.

Tar.Aldarion · 09-05-2013 10:11am #1

I am trying to install this on a router using buildroot, I added it to the build. When I use a .html file it works fine, I can see a test page. However I get a forbidden message for .php files.

So I added fastcgi in modules.conf. And also included it:

server.modules = (
  "mod_access",
  "mod_fastcgi",
#  "mod_alias",
#  "mod_auth",
#  "mod_evasive",
#  "mod_redirect",
#  "mod_rewrite",
#  "mod_setenv",
#  "mod_usertrack",
)

include "conf.d/fastcgi.conf"

I then edited lighttpd.conf and removed .pl and .php from the list of excluded extensions. Now looks like:

static-file.exclude-extensions = ( ".fcgi", ".scgi" )

So I tried a test page on IE and it just prints out the code from whatever file I use, it doesn't run it:

<?php phpinfo(); ?>

If I try it in chrome no page is displayed but a file called 'download' is downloaded.

What is happening and how do I fix it? It sounds like php is not working at all. Could this jsut be some path problem in one of my files.

Tar.Aldarion · 09-05-2013 11:18am

Ah, tried a different config and something is printed to the error log, guess that was it!

2013-03-22 13:47:20: (log.c.172) server started 
2013-03-22 13:47:20: (mod_fastcgi.c.1087) the fastcgi-backend /usr/bin/php-cgi failed to start: 
2013-03-22 13:47:20: (mod_fastcgi.c.1091) child exited with status 2 /usr/bin/php-cgi 
2013-03-22 13:47:20: (mod_fastcgi.c.1094) If you're trying to run your app as a FastCGI backend, make sure you're using the FastCGI-enabled version.
If this is PHP on Gentoo, add 'fastcgi' to the USE flags. 
2013-03-22 13:47:20: (mod_fastcgi.c.1398) [ERROR]: spawning fcgi failed. 
2013-03-22 13:47:20: (server.c.928) Configuration of plugins failed. Going down.

Tar.Aldarion · 09-05-2013 12:15pm

Solved that by changing buildroot options. Onto a new bug!

Webpage now says SoapClient can not be found so I uncommented php_soap.dll in php.ini, now I get in an error:

PHP Warning:  PHP Startup: Cannot dynamically load php_soap.dll - dynamic modules are not supported in Unknown on line 0

Tar.Aldarion · 09-05-2013 12:21pm

Wait dlls are windows specific and I'm on linux, fail. Now how to get soap on linux /google.

Trojan · 09-05-2013 12:37pm

Glad to be of help!

Tar.Aldarion · 09-05-2013 1:44pm

You're ruining my monologue :pac:

returnNull · 09-05-2013 2:21pm

Tar.Aldarion wrote: »

You're ruining my monologue :pac:

lol

Tar.Aldarion · 09-05-2013 3:28pm

Still getting:

Fatal error Class 'SoapClient' not found

I went to php.ini and uncommented `extension=php_soap.dll` (changed .dll to .so as I'm on linux, this right?) I also stuck in `cgi.fix_pathinfo = 1`

The error is still there, any ideas?

Do I have to enable some option so that soap is supported? Can't see it in buildroot. I can't find php_soap anywhere, I'm guessing I should...

Tar.Aldarion · 09-05-2013 9:38pm

Solved.

Colonel Panic · 09-05-2013 10:10pm

Quick, tell us the solution before you get XKCD'd!

Tar.Aldarion · 09-05-2013 10:35pm

Haha I was going to, I fecking HATE when I find a forum post and they are like...yup found the solution to your rare problem, but it is a secret :pac:

It was just a case of needing --enable-soap and --enable-simplexml in the php.mk file, but buildroot wasn't picking these up until I deleted my old php install.

For future travellers:

ChRoMe · 10-05-2013 12:15pm

Its threads like this that just reinforce the complete bloody mess that PHP is.

Trojan · 10-05-2013 12:30pm

ChRoMe wrote: »

Its threads like this that just reinforce the complete bloody mess that PHP is.

Ah now, c'mon!

Yes PHP is a bloody mess, but we can't blame it every time someone is unable to set up a web stack in a new environment (sorry Tar')!

Colonel Panic · 10-05-2013 12:33pm

ChRoMe wrote: »

Its threads like this that just reinforce the complete bloody mess that PHP is.

Getting any kind of scripted language, be it PHP, Python or whatever is a bit more involved when you're working with lighttpd or Nginx.

Tar.Aldarion · 10-05-2013 1:52pm

Trojan wrote: »

Ah now, c'mon!

Yes PHP is a bloody mess, but we can't blame it every time someone is unable to set up a web stack in a new environment (sorry Tar')!

It should have been a lot easier than it was, for instance none of the lighttpd guys or stackoverflow knew what to do. All the answers were completely wrong, for such an easy thing

You shouldn't have to go into php.ini and this file and that file uncommenting and commenting things, changing 5 build options as well, just to enable soap. Not all phps doing of course.

Colonel Panic · 10-05-2013 2:34pm

It's a bit less of a pain for Nginx for what it's worth, if you're looking for a more lightweight web server it's quite similar to Lighttpd in that regard.

ChRoMe · 10-05-2013 2:42pm

Trojan wrote: »

Ah now, c'mon!

Yes PHP is a bloody mess, but we can't blame it every time someone is unable to set up a web stack in a new environment (sorry Tar')!

This **** is basic and still shouldn't be causing any developer (including even Tar

) to lose time in this fashion.

And because I'm grumpy and on my weekly anti PHP rang the obligatory link to read is http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

Colonel Panic · 10-05-2013 2:47pm

That link, certain XKCDs, homework requests and comments about IDEs needing TBs of RAM define this forum!

Do you think people don't know PHP is garbage?

ChRoMe · 10-05-2013 2:54pm

Colonel Panic wrote: »

Do you think people don't know PHP is garbage?

I suspect many many dont, considering the amount of posts where people mention using it!

Edit: and even if most people have seen it, if each time its linked, it converts one more person, then its worth it

Tar.Aldarion · 10-05-2013 3:12pm

ChRoMe wrote: »

This **** is basic and still shouldn't be causing any developer (including even Tar ) to lose time in this fashion.

And because I'm grumpy and on my weekly anti PHP rang the obligatory link to read is http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

I think I've read that three times from you :pac:

It should just be basic, I had a senior developer look at it for a while (couple hours) and they didn't know how to fix it. So at least it wasn't just newbie tar.

ChRoMe · 10-05-2013 3:57pm

Tar.Aldarion wrote: »

I think I've read that three times from you :pac:

It should just be basic, I had a senior developer look at it for a while (couple hours) and they didn't know how to fix it. So at least it wasn't just newbie tar.

Maybe the 4th time it will stick then

So from what you are describing your company has lost about half a developer day trying to get it working? The defense rests your honor

Edit: I was only messing when I called you out by name, I wasnt seriously implying it was your skillset that was the issue, just wanted to clarify that.

Colonel Panic · 10-05-2013 4:06pm

But the problem had nothing to do with PHP's failings as a language or anything in that article, more to do with FastCGI, config files and the nature of getting these things working on Unix based systems.

That Tar asked a senior developer to look means nothing. Some senior devs I've worked with are all good and productive programmers, but they know nothing about gluing all the bits together.

It's like other senior programmers who treat SQL as fast CSV files. They're still senior developers, but they don't know everything. (They should, but I don't lose any sleep over it.)

ChRoMe · 10-05-2013 4:16pm

Colonel Panic wrote: »

But the problem had nothing to do with PHP's failings as a language or anything in that article, more to do with FastCGI, config files and the nature of getting these things working on Unix based systems.

That Tar asked a senior developer to look means nothing. Some senior devs I've worked with are all good and productive programmers, but they know nothing about gluing all the bits together.

It's like other senior programmers who treat SQL as fast CSV files. They're still senior developers, but they don't know everything. (They should, but I don't lose any sleep over it.)

My point was purely related to the amount of lost productivity relating to environment configuration that quite frankly should just work out of the box.

The failing is due to the language, perhaps not specifically the crazy syntax but the general environment it creates,inhabits.

Colonel Panic · 10-05-2013 4:22pm

There seems to be a logical fallacy here. Does that mean if I go to set up a language or framework you don't think is crap and have similar problems does that language then become as crap as PHP?

Plenty of amazing things don't work out of the box.

It's not a failing of PHP, it's a configuration issue. PHP et al just use FastCGI to run scripts on behalf of a web server.

I don't really have anything to gain from this discussion btw. I use open source PHP software but don't code in it if I can help it. I just enjoy these topics.

ChRoMe · 10-05-2013 4:32pm

Colonel Panic wrote: »

There seems to be a logical fallacy here. Does that mean if I go to set up a language or framework you don't think is crap and have similar problems does that language then become as crap as PHP?

Plenty of amazing things don't work out of the box.

It's not a failing of PHP, it's a configuration issue. PHP et al just use FastCGI to run scripts on behalf of a web server.

I don't really have anything to gain from this discussion btw. I use open source PHP software but don't code in it if I can help it. I just enjoy these topics.

Of course this is all just fun debate/discussion. What I'm saying is that stable,mature well designed languages generally don't have such configuration issues.

Edit: genuine question, are there even release management tools for PHP?

Tar.Aldarion · 10-05-2013 7:16pm

Colonel Panic wrote: »

But the problem had nothing to do with PHP's failings as a language or anything in that article, more to do with FastCGI, config files and the nature of getting these things working on Unix based systems.

That Tar asked a senior developer to look means nothing. Some senior devs I've worked with are all good and productive programmers, but they know nothing about gluing all the bits together.

It's like other senior programmers who treat SQL as fast CSV files. They're still senior developers, but they don't know everything. (They should, but I don't lose any sleep over it.)

My point was not whether the developer was good or bad, anybody capable like that with 30 years experience under their belt doing this stuff should have no problems, at the bottom or top of the talent scale. I mean I expect to be slow at it, never having heard of lighttpd, fastcgi, never looking at php before etc until yesterday but there is no way senior developers experienced in this should be. That means there's something wrong with the design imo.

As bill gates said, he was surprised new technology has not made more progress in simplifying these things.

Colonel Panic · 10-05-2013 7:23pm

First of all, I've been where you were, bashing my head off a wall trying to get things to work. I've learned loads from it.

For end users, I would agree that everything needs to work, but there's a lot of complicated behaviour underneath the simplicity that some developers aren't interested in and/or never come across. Understanding all of that, despite the awkward learning curve and lack of documentation is important.

Trojan · 10-05-2013 10:55pm

Some developers do degrees called things like "computer science" and while they can design hyper-efficient sorting algorithms in their sleep, give them a connected PC, an OS disk and a week and they still won't have a development stack set up

Lighttpd error 403 forbidden for php files.

Comments