I was wondering if it was possible to change something on my apache server. Forgive me if this is a dumb question, but I'm kind of new to this.

So, if my default root directory started as:

/var/www/html/

But I want my change my startup page to be from:

/usr/local/someprogram/html/

How do I pull pages back from:

/var/www/html/info/


When I change the documentroot to '/usr/local/someprogram/html/' I can no longer see the pages that are linked from '/var/www/html/info'. I'm sure it's something simple, but I'm scared to mess-up my config.

Always make a backup of your config file. That way, if you muck it up too badly, you can copy the file back over and be back where you were. :_)

Okay, now to your problem: You have it almost right. What you're probably forgetting is to set up the permissions.

At the top of your apache configuration file, there is a section that states what user apache runs as. For mine, it's "www-data". I chown all the files I want to serve to www-data:www-data ( user : group ) so that Apache has permission to read the files. Try copying a test file into your /usr/local/someprogram/html/, name it index.html and typing this in: (I'll use the apache user and group that I have on my system. Yours will probably be different, unless you're running Debian.)

chown www-data:www-data /usr/local/someprogram/html/ -R

and then attempt to browse to it.

A few notes: Remember when you change something in apache that you need to restart apache for the changes to take effect. This can be safely done in most cases by running the command

apachectl graceful
(This will make sure that everything looks proper in the apache configuration file, and if it does, do a restart of it. )

Also, note that it's not a *great* idea to run your website from within /usr/local/ anything. At the least, I would suggest that you make a symbolic link to that directory somewhere else. An example is if you were to rename /var/www/html and then type in the command

[b] ln -s /usr/local/someprogram/html /var/www/html/info[b]

You're still going to want to make sure you check the permissions on things.

I hope this helps.

hi mijohnst,

i think what you're looking to do here would involve setting up virtual hosting, whereby content can be served from a different 'root' directory of a virtual server.

have a look in your httpd.conf file and you should see an example of a virtual host setup, commented out.

i'm not in front of my machine at the moment so i can't really help further, but have a go and see how you get on.

oh, and from memory, i *think* that you will have to put the name of any virtual host name that you choose into your /etc/hosts file...

Wolven

Thanks for your reply! I see everything that you're talking about and I made the changes you suggested, but I still get an error 404 when I try to connect back to that page. Is there a place in the httpd.conf file where I can just add in /var/www/http/info so that it knows to allow it? Thanks!

Mike

The nicest and easiest to maintain setup I saw is to set up a /home directory for all of the files being served by the web-server, and separate /home directories for all of the files for any other services which have data/files.

Everything which was not specifically applications or O.S. had their respective locations in a /home/service-name directory.

Those directories were then linked only if there was no means of adjusting the configuration files to point to them. (And a README.SERVICE_NAME was added to the /home/README directory to be read when doing restoration from back-ups, so the links could be restored.) Very clean, and quite POSIX. Obvously, /home could be a (RAID) for performance.

I believe it was in one of Rusty's Unreliable Guides.
(/***Wrong*** What is worse, I can't find it. My favorites (windows book marks) has 25 different directories and god knows how many links(hundreds and hundreds)--many of which were not renamed into something which can be easily catagorized or searched. Okay, so I'm an idiot. I am not going to re-do the search and re-read every linked document to find it. So, I'm a lazy idiot. ***/)

You do not under any circumstances want to get sloppy and have files all over the place. The more complexity, the more opportunity for others to crack your system, and for you to hose it up. It also makes backups a serious pain in the *ss.

(/**** I'll stand by that one to the death. As far as I'm concerned, no matter what the situation, everything which is being served needs to have it's place within the directory structure you set up specifically for that task. For one thing, you will want to be able to easily back it up. For another thing, you want to be able to find files so you can maintain them without having to read a configuration file to FIND THEM. No one has a memory which is that good. And, of course, there is that little known thing called security. I have enough trouble with permission structures--I don't need to add to it. ****/

I found the references to the non-standard setup of apache while I was searching for examples of partitioning and reasons why people partition the way that they do. This led to more reviews of more of the: HowTos, unreliable guides, user-groups, and newsgroups. I often get lost, reading this and that, when I am trying to explain something to someone--I have a tendency to try to double-check what I am saying, and look for better or different ways of explaining things.

(/***** Most of the time, I am reliable enough to never try to "shoot from the hip". I don't trust my memory, I hate getting caught paraphrasing things out of context, and I very much dislike giving bad information or something which is not understandable. When I was learning networking and other things, half the time I would swear people were playing the "torture the noobie" game. I pray that I haven't left any post uncorrected here. If I have, I am very sorry. *****/

This can, at times, lead to positively deranged explanations which I clean up as I go along.

Sometimes, I do things without remembering why I do it (precisely that way) and have to look it all up.

Sometimes, I dis-remember how I have done and am doing things; then when I try to explain them, not only is the explanation wrong, but I no longer can do it myself, and have to look it all up. Then, I have to remember to edit my post.

I was positively wrong about user local, I've been playing around with chroot and different setups for security and have been left brain-damaged and confused.

(/**There are those who believe that many things really belong in /opt, instead of /usr and /usr/local/* for several reasons.
One groups' reasoning is to try to make very clean and hard lines of what-goes-where for the purpose of defining the boundries between the function of the O.S. itself, and the applications which run on the O.S., the division between user and Administrator, and how these things are accessed. This group defines an application as just another user of the O.S. and under no circumstances should any user have need for /root permissions or membership in the same group as /root. This group of people preach that anything else is poor programming. (This group says that the "s" in /sbin stands for "super-user" or Administrator.)

A second reason for the placement of more items in /opt is one of size and managability. It is true that /usr in Redhat is by far the largest filesystem. And, you have to admit, it is getting pretty complex with an install of "everything". I have separate partitions mounted over: /usr, /usr/local, /usr/src; /var, /var/logs, /var/spool/up2date (I keep all of the updates and regularly back them up--I have RedHat.); /opt; /tmp; and of course--/boot.
Most will admit to directing error logs for the web-services and iptables to a partition/filesystem other than /var either by mounting or linking. That way you stay up through a DOS attack or other situations which would simply flood the logs until the filesystem containing /var ran out of space and the system crashed. And yes, I just re-read the Apache pages and found that you can direct the logs where-ever you want. I never have learned the correct syntax to do the same with syslogd.conf for net-filter.**/)

Some of the hardened setups and complex usages of chroot and other stuff I've been reading and playing with are enough to induce altzheimer's. I swear the more I play with chroot the more permanently confused I get. Is the fricking thing for rocket/computer scientists or what?

One of the things I found while floundering around, (I checked my SuSE docs,) is that document serving to an internal network is/can be approached separately, with its own permission structure--without running a separate service. Now, I'm even more confused.

So, try to forget I posted anything at all, will you?

Yep, apache is pretty flexible with it's config files.

Good try. When you change DocumentRoot, you can make links to old content in the new root or anywhere within it to make parts of old data available. Keep in mind that there are few other places in httpd.conf that have to point to whatever you change DocumentRoot to! Here's what I think your problem is: newer versions of apache are configured to NOT allow the access to locations outside of your DocumentRoot (or virtual server's root, etc.) So, in your httpd.conf look for settings related to "FollowSymLinks" and make sure that it is enabled. This should do it.

kevinatkins:
setting up a virtual server is an overkill and a bad way to allow access to a few extra dirs.

Wolven:
Always make a backup of your config file
I couldn't agree more! Learned the hard way
Also, note that it's not a *great* idea to run your website from within /usr/local/ anything.
Can you explain further? I see nothing wrong with that. If it was so bad, why would it be the default location in some major distros?
Permissions are important, although apache does not have to own what it serves, nor be in the group owning the files. If that was the case, serving user's home pages out of their ~/html/ wouldn't be possible, would it? After you chown your files, how do you edit them now that they're owned by apache and in it's group? And how do you make sure only people in web developers group can modify them? You edit them as root or chmod o+rw ? Shame on you! Not a concern 'cause you're the only user on the box? Not a serious approach.

Apache just needs execute permission on the entire path to where it needs to serve files from. Notice, it does not need read permission all the way to the directory that contains the website, just everything within it. Thus by setting chmod o+x-r on user's homedirs and html dirs and o+r on their html files you prevent other users from displaying one's home directory, but let apache serve the files.

Eqwatz
The concept is interesting but might break a lot of things. Yanking stuff from where it was meant to be placed... Yes, compile options and config files can bend a lot of stuff the way you like it, but if you're used to how apache is set up on most other systems - this setup would feel weird. Interesting, though.

I have to strongly object to this. Turning on FollowSymLinks is a potential security hole. This was a major thing that came up in a Security Audit of the web servers at the place I work for. Professional Security Goons say you should turn this off. Turn this off if it is turned on. Use a Directory block instead. That will allow you to provide the path AND apply some layer of security to it.

What you need is to add a section to your httpd.conf that looks like:

<Directory /var/www/html/info/>
Order allow,deny
allow from all
</Directory>
Alias /somePathToUseInABrowser /var/www/html/info/

Then when you refer to http://your.server.name/somePathToUseInABrowser you will get pages from /var/www/html/info.

My thinking on this might be to simplistic, but I think that is what you are looking for.

I aggree, this does create security issue if the box is accessible to anyone who might want to compromise it. If they're allowed to create links to system config files or other sensitive information - you're in trouble. The mitigating factor might be if the box is only accessible to authorized personnel or a personal use machine not accessible to haxorz. If the box has multiple shell users - you're right - it is not a good idea.

That's much more secure and a better way of doing it in most cases, although it might become annoying to have to restart apache each time you make a change like this if you do it frequently. The "FollowSymLinks" method is easier in this respect, but you're right - in most cases it is not worth the risk. It also complicates the config somewhat having multiple sections like this. Storing them in include files might make things clearer. That's what I do for my virtual domain configs, btw.

Thanks for bringing up the security issue. It's very important.

I didn't say it was a horrid idea. I just said it wasn't a great idea, either. You implicate that since some major distros do it, it isn't a bad idea. I won't make comment on that, as I think my opinion on that is obvious. :_) I prefer a nicely chrooted environment for myself, but that isn't what I'm going to recommend for everyone. Indeed, if you know exactly what you're doing, then you can stick apache's root under /, /proc, or whatever, and there will be nothing inherenly wrong with it. On my networks, I have none of the problems you seem to have associated with me. As a matter of fact, everything you've described as an alternative sounds patently ridiculous, which I'm sure was your point. As for backing up your file, Amen to that!


Now, back to the matter at hand. Mijohnst, have you gotten your problems resolved, or can we be of further assistance?

Sorry, I had to put this on the self for a while. Thank you all for the great responses... I was able to get this to work in a jiff thanks to you all...