@techadmin
Before I put this topic to rest again I need a clarification.
This article www.debian-administration.org/articles/412
says the following:


The article does not mention any modification to the /etc/hosts file.
It is dated 6 Jul 2006, so it could be outdated.
I have done this and also modified the /etc/hosts file as per your instructions, and got the error reported above, which was cleared after deleting file.
You don't mention the virtual.conf file at all (I understand that it can be named arbitrarily).
Webmin sees the virtual host without any need for the virtual.conf file.
So I am thinking that it is one or the other, and I would rather stick to the addition in the /etc/hosts file.
Am I correct?
Back to top

If you have not done what I suggested, but insist on reading poorly written how tos, it's hard for me to really keep making suggestions.

The stuff I post is from working live apache configurations, slightly examplified.

Of course /etc/hosts has to be set up, otherwise how will your localhost system know to direct the requested site to your local apache server?

That's a given, why even discuss this at all now, you shouldn't be asking that question in my opinion, to do so shows a fairly serious misunderstanding of how this process actually works and what is happening.

Enabling virtualhosts has NOTHING to do with /etc/hosts, zero, nada, zip. The only connection is if you are using a dev server and testing sites locally, that is, the only connection is that the website virtual name in sites available section has to correspond to the /etc/hosts name.

As I've now said several times, you create a sites available file, that can have as many sites as you want in it. You create a symbolic link to that file in sites enabled. Sites enabled is only a set of symbolic links to sites available, period.

There may be other stuff I've forgotten, but that has nothing to do withe the correctness of what I am writing here, that's simply another step that might be required, which could well be the case, I don't remember everything. One thing I do know is that directions for setting up virtual host serving on a local dev machine are absolutely terrible in general, some of the worst stuff out there on the internet in my opinion, so I ignore them as a rule.

All directions for apache 1.3x are useless and should be ignored, only follow directions for 2.x. That doesn't mean that stuff for 1.3 doesn't work, it's just better to use the stuff taken from working 2.x apache installations. 2.x is more picky, and uses multiple files, and each distribution might have these slightly differently arranged. But overall, these methods are not that hard once you create a working set of configurations.

One reason I don't think about this much is that with a few exceptions when a major update to apache forces some configuration changes, or when I am setting up a local test ssl type system, https that is, I just copy and paste, anyway, it's because once you have it set up and working, it works for years, so of course I forget the details over time, since the only thing I usually do is add more sites available, and sometimes, set up remote internet access to a test site.

Once you have one site running correctly in a sites available file, you have all your sites running correctly. Unless you make copy and paste errors, or path errors, and so on. Failing to set document root correctly will result in failure of the site to work, it's a given. If it's set correctly, then it will load. If it loads, the site is working, period. That is why I never use the default apache test page, the only function that serves is to show that apache itself is running on a test.

Debian has gotten absurdly anal about having sub fiiles in .d directories, I don't pay much attention that that, I have no idea why they do that, I guess for some core script upgrades and stuff it helps, I don't know, I don't use that.

I don't use a virtual.conf file in .d, mine is in /etc/apache2/sites-available, where it's always been. .

I don't remember where NameVirtualHost * is set, I see it commented out in a variety of files.

Oh, I found it, it's in
ports.conf:8:
NameVirtualHost 127.0.0.1:80

that's where I assign all standard port 80 requests to apache. I also have my system set up so I can turn on remote access using different ports so other devs or clients can take a look at the sites over the internet, from remote, that is.

Now I remember, the /sites-available/virtualhosts.conf file is a sample file, nothing more, nothing less, to let you see how it would look. That's all that file is, I don't use it myself, it exists, but not in sites-enabled, ie, it is not used.
Back to top

re zen cart, all I can tell you is that I have set up zen cart on my local system fine, and then moved that to the remote site fine, I used a switcher for the key configuration data so it loads the right paths and things, but there's no way I'm going to try to debug zencart cr#p for free, that is way out of the realm of what is fun or interesting, I already am 100% aware that the only thing worse than zencart on the internet is oscommerce, no need to refresh my memory there, I wouldn't touch that garbage for under $100 an hour.

It doesn't surprise me at all that zencart doesn't run right on php 5.4, I would expect nothing less, they use garbage code, and insist on using deprecated methods because of stupid concerns for a single developer who might still be stuck on a server using that garbage.

However, I am not interested in diagnosing issues related to zen cart, all I can tell you is that if you set it up right, and have set the configuration files to properly set all local and remote paths ( I do that with if /then condititionals, using the server / site name as php knows it to assign the proper values dynamically on site load, that avoids accidentally uploading the wrong config file), anyway, if you have done that all right, and if you a version of php that zen cart can understand (but what exactly are you planning on doing if the server upgrades its php version in the future?), then zen cart will work. that's also assuming zen cart was set up right, that it wasn't hacked to modify something internally, and many other assumptions that it's not safe to make.

However, on a general level, I can tell you this: if you are not able to get zencart running on your local dev server, you do not have the code under control, and working on it live is VERY DANGEROUS, you may not be able to fix errors if you make them.

I had no problem getting zencart to run locally/remotely, none at all, just the regular headaches setting up https stuff locally, but even that I got running, though it is a headache. Takes a lot of reading, I'm sure I probably posted some of that here on these forums, can't remember.

Again, let me stress, forget zen cart, focus on making a fully functional real site, that can use includes, that has document root correct, then once that is all debugged, move to zencart site, using exactly the same methods. If you cannot get a basic site running on the dev server, there's no way you can get a pos like zencart running, there are too many paths of the bugs and failures to follow to know which is which.
Back to top

Wow, and I was thinking of giving this topic a rest!
There's a lot of meat to digest, including the bashing, which I don't mind if it is accompanied by all the other goodies.
I did manage to get ZC to work on my local site, and for the PHP issues I was thinking of posting in their forums, which I have not frequented in years.
Yes, it does install locally and remotely, it only breaks locally when installing IH4, which is a critical mod for me, I just didn't want to get into too much detail in a forum that is not related to it.
I just wanted to make sure that breakages were not caused by me, because I have never had to set up virtual hosts before, I just uncompress those archives into /var/www, set up a database and fire up the installer, never needed anything else.
Same for Drupal and WP.
It is only that the kind of fatal error I was experiencing pointed to something else.
Here is, not asking you to troubleshoot it, just info.

Now, query_factory.php is in that path.
These are lines 52 through 57 of sessions.php:

This server is using PHP's default path for includes, which never happened before, so I thought that setting up a virtual host and forcing an include path would solve the problem, but it didn't.
More research is warranted on my part.
Again, not asking you to troubleshoot anything and thank you very much for the detailed info.
All the best.
PS. I think I spotted an error in the ZC file, it is not showing the full path to query_factory.php, last directory is missing. POS.
Back to top

@techadmin
Followed your instructions and forgot about Zen Cart.
Created the simplest of folders in /var/www called dumbsite, it only has an index.html file that I modified from the apache default, just to tell them apart.
Created a file in sites-available by copying over the default and then modifying it to its simplest form, here is:

and my hosts file looks like this:

Ran command a2ensite as root, which prompted me to reload service apache2.
Reloaded, then typed dumbsite in address bar and my dumb index.html appeared in all its glory.
In short, success!
It is really a very simple procedure, it was just getting complicated with damn Zen Cart.
So that's that.
I could never find a virtualhost.conf file in apache2, maybe some legacy file left over in your system?
Maybe you created it?
It don't matter, it is not needed.
Also, the instruction to create a file with the NameVirtualHost directive in /etc/apache2/conf.d is wrong, as you pointed out.
This directive is already loaded through ports.conf.
BTW it is exactly as above now, not ports.conf:8, maybe that was a typo.
I am going to call this thread SOLVED now, no need to write anything else here.
There are many other Apache questions I will probably ask in other threads.
My time is very limited now, and it will be like that probably for the remainder of this year, so won't be able to contribute much.
Lastly, regarding Zen Cart, I need to update a website written in a previous version of it, and I don't have time to do it in Drupal, that is the only reason why I am still using it.
As they say in the old country: mas vale malo conocido que bueno por conocer.
Big THANK YOU.
Back to top

good for you, now can I suggest one more dumbsite excercise.

Add the folloowing line in your config for that dumbsite:

php_value include_path ".:/var/www/includes/dumbsite"

then create the folders: /var/www/includes/dumbsite

then inside that dumbsite folder, create a folder: test

restart apache2.

make a file in test called one.php

contents:



Now create a page: test.php in the main dumbsite directory.

In the html place this:



save the page, then load: dumbsite/test.php
in your browser.

You should see the text for the echo there.

Once you have this working, you know know the following:

your apache virtual host file is working
your ports.conf listen directives are working.

You know these two now, and that's where you always want to start, to make sure the very basics are working.

With the php include, you will know two more things:
php is working
your include path is also set and working.

At this point, most things should be working, although you'd still have to test mysql to make sure those connections are working, but that's another topic.
Back to top

I did the exercise and everything is working, yay!
I did one modification though.
I was noticing that when typing localhost in address bar the default index.html was not loading, the one for dumbsite was loading instead.
So I put dumbsite in 127.0.0.2 in /etc/hosts and changed file dumbsite in sites-available accordingly.
Now both are neatly separated.
I suppose that I can either continue sequentially for each site or simply load all in 127.0.0.2 in same line.
I have other stuff in the root of localhost like a phpinfo.php file, to check on the PHP settings, so I find it convenient to leave the root alone.
But that's me, maybe other people would find a different setup more convenient.
Thanks again.
Back to top

NO.... lol, no no.

If you do not see the apache default index page, that is wrong.

If you needed to use 127.0.0.2, that is wrong.

These things mean something is not working right.

When you type in: localhost
and hit enter, one and only one things should happen:

you see the apache default page. Period.

When you type in: dumbsite, one and only one thing should happen: you see dumbsite.

Apache looks in the /var/www directory for index.html, finds it, shows it, when default localhost is put in.

I have to assume that you changed something in your config files along the way, since apache wlll always show localhost as the default index page, although I don't know what it will do if you remove that file.

In the sites-available, there should be a file called: default

that should have this:



I also have this:


in one of my other sites-available files, which is really all that's 'needed. Not sure why I have the two to be honest, since I rarely need to touch my local apache install, I don't remember why I did certain config things.

this should then be linked in sites-enabled

and that is that.

If anything other than this is happening, something is wrong in your configuration files.
Back to top

This is my default file, never touched anything there, although there are some slight differences with what you posted:
1.
After your last line I have another block.
2.
In directory /var/www I have
AllowOverride all

I never created a virtual host for localhost.
As I said, when typing localhost there is a mixup.
Maybe the additional virtual host for localhost solves it.
Cannot test much now because damn us mirror is borked, or maybe wheezy upgrades are borked, and mysql server and other 3 packages are borked, so will have to wait until later to test.
Thanks a lot for taking the time to answer.
Back to top

Remember basic with apache2 configuration:
sites-enabled do not exist until you create a symbolic link to that file in sites-enabled, pointing to the right file in sites-available

you have the same rough default as me, and I wonder if I added in the second one because the *:80 was not working.
Back to top