Freebsd apache issue

M

millhouse

Limp Gawd
Joined
Jul 19, 2004
Messages
173
Running FreeBSD 6.1 and Apache 2.2.2 (installed from ports). Now, I just got done installing gallery2 from ports and when I browse to http://mywebsite.com/gallery2 I get an Index page of files and directories instead of the website.

When I try to click on the index.php link in that index listing it wants to open the page for editing in dreamweaver!!

I know I did something fundamentally wrong here I just cant put my finger on it. Any ideas?
 
You need to install php and add lines to your apache configuration to have it use php to parse the page before outputting it to the browser. A good how to on how to do this can be found on the freeBSD website here.

After that, you will find in general that although ports is awesome for system packages, it's not so hot with web applications. Specifically things like phpmyadmin, squirrelmail, gallery, etc. These things are still best to install and maintain by your self. It's easy to do so since they require nothing more then extracting flat files (no compiling and such).
 
Tweakin said:
You need to install php and add lines to your apache configuration to have it use php to parse the page before outputting it to the browser. A good how to on how to do this can be found on the freeBSD website here.

After that, you will find in general that although ports is awesome for system packages, it's not so hot with web applications. Specifically things like phpmyadmin, squirrelmail, gallery, etc. These things are still best to install and maintain by your self. It's easy to do so since they require nothing more then extracting flat files (no compiling and such).
Click to expand...

Thanks for the info. I know I shouldnt use ports for this type of thing but I have zero time to do this and need to get the site up.


Thanks again!
 
Tweakin said:
After that, you will find in general that although ports is awesome for system packages, it's not so hot with web applications. Specifically things like phpmyadmin, squirrelmail, gallery, etc. These things are still best to install and maintain by your self. It's easy to do so since they require nothing more then extracting flat files (no compiling and such).
Click to expand...
...No. I run everything I can from ports and everything works quite well if you actually understand why they're doing what they're doing. I'm curious to hear your logic behind this statement, mostly cause it goes against...Ohhh, everything I've ever heard from any experienced FreeBSD admins and encountered from personal experience.

What's your problem with squirrelmail from ports (besides the general BS that comes from PHP)?
 
[H]EMI_426 said:
...No. I run everything I can from ports and everything works quite well if you actually understand why they're doing what they're doing. I'm curious to hear your logic behind this statement, mostly cause it goes against...Ohhh, everything I've ever heard from any experienced FreeBSD admins and encountered from personal experience.

What's your problem with squirrelmail from ports (besides the general BS that comes from PHP)?
Click to expand...

I love ports and portage, they are the ideal way to handle package management in my eyes. I certainly am not trying to say don't use them- but there are particular areas where the user can maintain the software better directly. A simple web application is probably one of them. Another area is binary drivers or other software that can take a long time to test but that is needed to run, for instance, 'bleeding edge' hardware. Just because a system has ports (or in most of my cases portage) does not mean that should be the only way a user should be told to install software, because it is not.

If you are running a higher profile site and a cross-site exploit is released for phpBB, do you want to wait a week for that update to hit package managers or simply patch over the 1-2 files your self with an update downloaded directly from the developer? phpBB is watched pretty closely, so maybe you are fine with waiting (it won't take long) but what about obscure software in ports that is not so watched?

This is generally different then system applications because there is genuine system stability concerns there. However, with a simple web application (such as the few I listed, and maybe a couple thousand more) it's a different scenario. And as I said, this is not a case of downloading, configuring, making, and installing some piece of system or server software, this is downloading and extracting a few flat files into a web directory.

I understand you question my advice and just wanted an explanation, but perhaps you could have come up with a nicer way to ask :)
 
If an exploit comes up for something that I run from ports, I'll "make patch" to extract/apply the FreeBSD-specific patches, apply the vendor patch for whatever I'm trying to patch or make the few source changes by hand in the extracted port source, then rebuild/install as usual. Sometimes you have to do "make extract" and then apply the vendor patch before you continue depending on if the vendor patch applies cleanly to the FreeBSD-patched source or not, but you get the point. Works quite well, actually. The ports framework makes allowances for you to apply third-party patches...It would fairly suck if such things weren't allowed or weren't possible.

Binary drivers? I'm running the NVIDIA driver from ports and management is (IMHO) easier than doing things manually...Particularly when NVIDIA does something silly that the FreeBSD folks patch around automatically before NVIDIA fixes it upstream. This happened when 6.0 came out...NVIDIA's virgin driver didn't support 6.x, even though it was just an extra check in one of the headers...A patch applied by the port made it work until NVIDIA fixed the oversight.

I'm not saying someone should run only ports. As a port maintainer, I realize that there's lots of applications that aren't in ports (and I'm actually working on making sure everything I use is in ports, plus has a maintainer). However, for the vast majority of cases, if something's in ports it's a good idea to stick with the port, particularly if you're going to be building other things that depend on that particular application. Also, installing stuff outside of the ports tree generally means you'll get no support from FreeBSD folks if that software does exist in the ports tree, cause you may be trying to duplicate work that's already done by the port (FreeBSD-specific patches, special install options, etc.) and at that point it becomes a problem for the application vendor, not FreeBSD.

Sorry, I've never been known for being particularly tactful, particularly when I think someone's getting information that isn't quite correct. It wasn't anything personal.
 
[H]EMI_426 said:
If an exploit comes up for something that I run from ports, I'll "make patch" to extract/apply the FreeBSD-specific patches, apply the vendor patch for whatever I'm trying to patch or make the few source changes by hand in the extracted port source, then rebuild/install as usual. Sometimes you have to do "make extract" and then apply the vendor patch before you continue depending on if the vendor patch applies cleanly to the FreeBSD-patched source or not, but you get the point. Works quite well, actually. The ports framework makes allowances for you to apply third-party patches...It would fairly suck if such things weren't allowed or weren't possible.

Binary drivers? I'm running the NVIDIA driver from ports and management is (IMHO) easier than doing things manually...Particularly when NVIDIA does something silly that the FreeBSD folks patch around automatically before NVIDIA fixes it upstream. This happened when 6.0 came out...NVIDIA's virgin driver didn't support 6.x, even though it was just an extra check in one of the headers...A patch applied by the port made it work until NVIDIA fixed the oversight.

I'm not saying someone should run only ports. As a port maintainer, I realize that there's lots of applications that aren't in ports (and I'm actually working on making sure everything I use is in ports, plus has a maintainer). However, for the vast majority of cases, if something's in ports it's a good idea to stick with the port, particularly if you're going to be building other things that depend on that particular application. Also, installing stuff outside of the ports tree generally means you'll get no support from FreeBSD folks if that software does exist in the ports tree, cause you may be trying to duplicate work that's already done by the port (FreeBSD-specific patches, special install options, etc.) and at that point it becomes a problem for the application vendor, not FreeBSD.

Sorry, I've never been known for being particularly tactful, particularly when I think someone's getting information that isn't quite correct. It wasn't anything personal.
Click to expand...

That's all very easily said for a ports maintainer, I'm sure :) However, a simple web admin might find it easier to download and extract a single archive (again, for a large selection of simple web applications)- I know I do.

Enough on that though, I am no ports expert to say the least, my knowledge is much more broad in linux land with portage, but I am quite confident my advice is applicable in many scenarios and I am glad I was able to help the OP figure out his apache problem.
 
HHunt said:
Just out of curiosity, what ports do you maintain?
Click to expand...
Heh. Nothing spectacular. One of them was something I used and wasn't in ports and the other was something someone wanted updated. The first update I did was very easy, but the second update (with support for apache22) was much more involved. I'm considering taking over a few more unmaintained ports (libdockapp for starters, which xscreensaver.app depends on), and f there's anything I get to using that isn't in ports I'll probably end up maintaining it, too.

You don't even need to be much of a programmer to maintain some smaller ports. I'm not much of a programmer at all and I seem to do all right. You do have to have some problem-solving ability, though.

By the way, the patching thing is clearly documented if you search for it, Tweakin. They don't try to hide the patching thing.
 
You must log in or register to reply here.
Back
Top