@techadmin
Taking advantage of the wonders of Debian, I just use the a2ensite command which is less error-prone.
Speaking of the above wonders, this morning the dist-upgrade added two new packages that cannot be configured: rsync and wdm, total 6.
Let me get that straightened out and will be back here with my findings.
Back to top

Hmm, this is not working for me.
Copied and pasted your example into a new file localhost in sites-available, enabled it but getting conflicts.
Here is my /etc/hosts

Still getting mix-ups only showing the dumb index.html when typing localhost, dumbsite or zctest.
Recent upgrades to apache2 removed all my sites-enabled, had to recreate them, not good.
Back to top

You had apache2 update overwrite your config file, so of course, it's back to default.

When debian updates files you have modified, it asks you if you want to do that. If you say yes, then you lose all your mods, but there is a copy of the file made in the directory.

The problem here isn't with debian, this is how debian always works , you have to know what files you modified, then when apt asks yyou if you want to keep your updated file or use maintainer, of course you use yours, or you lose all your updates.

My suspicion is that your stuff is getting messy, somehow you've made something that is very easy very hard, the error you got was from two entries for the same host, or something else, can't really say.

At some point with this stuff you have to learn the basics, it just works better that way. one of the basics is that if you've updated apache config files, you don't then overwrite those every time debian updates that package, you say, no, keep my version.

anyway, can't tell you more, the examples I've posted are literal copies that are just made examples by changing paths, my feeling is that there are some core things you don't quite understand about the process, and you might want to clarify a bit before you do that.

for example, really, making a symbolic link from one directory to another, that's not something you need a tool for, all you need is:

ln -h
and it will tell you how to do that, and when you do that, you will understand what it is you have done, and why you don't need a tool to do that link.

I think you should take some time and read the basic documentation, the kinds of errors you make indicate something isn't clear at a core level, and I don't think I can clarify those things any further.

For example, if you have two localhost sites declared, that's one mistake, if you overwrote the apache config file that says what sites enabled to use, that's another mistake. php.ini is another config file it's sometimes worth reading as well, and once that's customized, one doesn't update that unless you know what or why the update is needed.

i see these types of problems all the time by the way, the real problem is those lamp type packages that let people setup stuff with no idea what they are doing, then bad habits form, and it's not hard to figure out why so many linux servers get hacked every single day on the internet.

anyway, as I said, if you can't consistently get the basics working reliably, then by all means DO NOT CONTINUE until you have figured out why something totally basic like running default apache localhost web page, the page it shows you always by default, but which at some point you had to have removed, and then trying to run a second site, like dumbsite, doesn't work.

this is why you always start with default apache localhost page, then add the first enabled site file, I put many sites per file by the way, it's easier to see what's going on, that debian thing of making tons of sub files is a pain in the a#s to actually maintain.

You should use kate code editor in root mode and open up every single apache file you have touched in one session, then look at them all until you start to see where you have gone wrong.

Using proper tools helps a lot, and kate is a good one for that, way way better than gedit for session management.
Back to top

@techadmin
thanks for answering so much in depth.
Don't worry about not changing config files, I know the default is N and I always choose that.
Maybe this time I didn't because I wanted to hose everything and start over, which I did.
Already set php.ini to development level, re-enabled sites.
Thanks for the tip about kate, I was using mcedit, but I don't think that makes much of a difference.
Anyway, mix-up continued, and I could not get rid of it until I got back to putting sites on different networks, which works fine.
With that scheme, to have or not a virtual host for localhost makes no difference, I chose not to have it, it is redundant.
So, yes, I will have to read the docs, test a lot, and think.
Only problem is time, I am very caught up for this year, ain't easy.
Back to top

If you have to use different networks, which I've never even heard of as solution it means you do NOT have virtual hosting working, period.

Virtual hosting is very simple, apache listens to the assigned port on the assigned IP address, then uses the domain names or site nics listed in each virtual host entry to assign the request to the proper apache thread/process.

I can't tell you how you did this since I've never seen it. I've seen the inital setup exit with errors, but I've never seen apache not have virtual hosts work once no errors on start occurs.
Back to top

Well, there is always a first time :-).
I loaded LAMP via smxi, never modified core files, and everything works fine, except for this pesky little thing.
Once I set sites in same network (127.0.01:80) I get the warning I posted, which disappears when sites are on different networks.
Warning mentions the NameVirtualHost directive which should have
already been loaded from ports.conf.
I will have to dedicate time to this matter, which I don't have at present.
I understand that you cannot say more or reproduce error.
So, let's give this topic a rest.
I'll post the solution here, eventually.
Back to top

google the precise error you get minus any specific paths you get in the error message, using "" around the literal words, then you will find out what you misconfigured.

Then learn how to read the main apache config file and understand where the things load, and make sure the things you need to load, like ports, virtualhosts etc, are actually loading.

Again, having different ip addresses required means that it's not working.

The examples I post are not exact because I have no idea what you actually have done at this point, they are just different ways of doing things that work., but them working assumes that the apache2 configs are properly done.

Default debian apache2 configs are useless for anything other than getting a single website up and running.

I have always found the iinformation out there on setting up virtual hosting to be total and utter cr#p, no idea why, it's not hard to do, all it requires is doing the proper steps, setup apache, test, test php, then setup first simple virtual host directory, enable it, test.

Error messages like you get of course are not something you ignore, they are cause for stopping, googling, fixing, then going on only once you have solved that problem.

Apache is professional software, which is why it runs a big chunk of the internet, and it's not written for kids and amateurs, but that doesn't mean anyone can't learn it, but as with all professional tools, you have to follow the right steps and not skip things in the process, and you most certainly never skip error messages that have to be resolved before continuing.

Use a root session of Kate, create a session of all apache2 config files, then you can easily see them in the code editor and flip around in them.

learn how to use ls, ls -l, to see what the actual sites and other things do in terms of symbolic links, don't use short cut software tools that do something you may or may not understand, for examploe, using a piece of software to create a symbolic link in sites-enabled means you have really no idea what happened or why, which is the problem here I believe, you are following various online sources, including this one, without actually knowing what the steps are meaning, some may conflict, but you have to know that so you don't do the conflicting steps.

The only way to learn this is step by step,, and the steps have to be in order, it's just like learning any other thing that is engineering based, or math, or science.

Skipping steps means you simply have confused things so greatly that it gets very hard for anyone to help you.

If you start at the beginning, then go step by step, and stop and solve problems as they occur, it's very easy to help, since you can state:

setup apache, localhost works
setup php, test.php works
setup first shared virtualhost, failed.
Back to top

SOLVED!
Such a stupid mistake.
There was a mismatch between NameVirtualHost *:80 in ports.conf and <VirtualHost 127.0.0.1:80> in the sites-available file.
If NameVirtualHost directive is *:80 then all your virtual hosts should start with that.
Poor apache2 was getting confused with those overlapping sites, now it knows where to direct its requests.
Credits go to techadmin for telling me to google the error.
Thanks techadmin, yo man is great.
Back to top

excellent, nice going. Believe me, I know the feeling well when some 'little mistake' that is in fact not little until you know the solution is fixed, in fact, that's most of my working life with computers, lol.

It's only a stupid mistake if you knew not to do it, but when one is starting, it's all these little squiqgles on arcane config files, and it's not at all obvious what is right or wrong, but you are on the right track now, you persevered, and didn't give up, then found the actual problem. I can't tell you how many seriously hard problems I've dealt with that when I found the solution, which took sometimes years, often months, usually weeks, and the solution turned out to be absurdly simple.

But good for you to find it and fix it, that's really how you learn this stuff in the end.

Now as to the set of problem that not only not are simple, but are never going to be simple to find solutions to.. that's another story, which I won't get into here.
Back to top

To wrap it up, apache was saying that the first instance takes precedence but...
my /etc/hosts had
127.0.0.1 localhost dumbsite
which is the first one here?
Apparently it is localhost, but apache sorts alphabetically and that is why dumbsite appeared first.
Glad to have contributed to a solution in this forum.
Back to top