httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From justken <>
Subject Re-> help getting help - more specific.
Date Mon, 31 Dec 2001 20:27:03 GMT

>Yes, the documentation was originally written for people already running a
>webserver (NCSA httpd in particular) wanting to upgrade to apache.  The
>documentation always needs to assume some base level, but perhaps it is a
>little too high at the moment.

I transfered from PWS on win me, as i am a web programmer not a web master. 
my need for a server was fairly limited, now i need something that is more 
robust, and not such a security concern. moving from a gui,  to a text 
based config system, where there is a Single host name to virtual hosting 
capabilities - never mind load balancing, clustering etc... and i can see 
many many people (the smart ones hit by the iis worms especially) making 
the move to apache from a Win version.
How's that for a base level?

> >
> > what i would like to have before i started:
> >
> > 1) it would be helpful to have an archive of this apache list.
>Actually, this list is brand new, so it doesn't have much of an archive yet.
>But there is a little bit, plus there is a big usenet archive.  They are
>both linked from here:

the archives link is a redundant link back to itself, and the link at the 
bottom of the page takes me to google usenet, and is a very general server 
setting up a list archive should be very simple, and adding a basic search 
shouldn't take too much - i'd volunteer to put that software together 
myself. the archive just needs somewhere nice to live.

>To be honest, I'm not sure exactly what you mean here.  Most of the stuff in
>the FAQ applies to all OSes.

while having problems with my apache server serving pdf files from a 
directory in my scripts path, any search i did in the doc's faq or 
usegroups, pointed to a bug in solaris. now not all the messages in the 
thread mentioned solaris, adding confusion to the problem. i have noticed 
this before, especially to do with bugs, when trying to configure something 
more specific, like a certain file type.

> > 2) i'd love to see a "deprecated" list
>I assume you mean you want clearer documentation on what has changed between
>versions.  This is certainly a problem area, I agree.  The CHANGES file is
>the only relatively complete list, and I most users aren't going to want to
>read through that.

correct, it too technical. and it's by version, not feature. i've always 
belive that "changes files" were for users who are upgrading one or two 
generations of a program, not newly installing the program, and trying to 
figure out what par of the doc's are still relevant and which ones are 
missleading. For example the AddModule in favour of loadModule, in the 
newer conf file between 1.3.20 and 1.3.22, has a clearModules command right 
after the loadModule, the file also has some comments about this change, 
but since it's a "this new way is better but the old way still works" it's 
not clearly documented. and how to take an existing new module (the 
coldfusion in my case) and get it too work, took hours of time, and in the 
end, just good human deduction that "clear" was not a good thing if i 
wanted it to exist.
i know it's a lot of work, but the documentation needs to be version 
specific. when i update my software, especially when implementing new 
features, these new features don't start getting utilized till i've 
documented them, and often provided clear examples. i think of it now as 
the use::help if i'm going to take the time to write good software, i'll 
take the required to to write the documentation - and further to that, i 
have my editors run thru the doc's to see if they make sence, and provide 
revisions, so it's not written to technically.
it ends up saving time in long run, because i can then get on and work on 
the next version, or a new project, and not spend most of my time tech 
supporting the stuff i've already done.

>The documentation on name-based virtual hosting was rewritten a few months
>ago.  Is it any clearer now?  Are there specific confusing things you can
>point to?  (Specific is always more helpful than general.)

I think that the last time i set up my server it was with the new docs. 
thanks for pointing that out though. (i'm using the doc's that came with 
3.1.22) my conf file was destroyed in sept. and my backup was out of date 
(lesson learned - again), so i had to rebuild, i still like the way the old 
one worked, but for some reason can't get it back the way it was.
my biggest problem was when i cut and past a chunk from the doc's and 
edited my paths, the server wouldn't even start, it took me a while just to 
implement the very very basic 2 URL's, one the default and one virtual.

still today, my config file has the root path redundant see below, i'm sure 
it wasn't like that with my first attempt:


DocumentRoot "C:/wwwroot"

<Directory />
     Options FollowSymLinks
     AllowOverride None

<Directory "C:/wwwroot">
     Options All MultiViews
     AllowOverride None
     Order allow,deny
     Allow from all

then later on...

<IfModule mod_alias.c>

Alias /samples/ "D:/WWW/samples/"  # which work just fine at

     <Directory "D:/WWW/samples/">
         Options Indexes MultiViews
         AllowOverride None
         Order allow,deny
         Allow from all

and my virtual config...

NameVirtualHost *

<VirtualHost *> #notice this one is redundant, or else i get nothing at all.
     DocumentRoot C:/wwwroot

     ErrorLog C:/wwwroot/cgi-bin/logs/main_error.log  #and why do i have to 
put my logs into the cgi-bin for them to be written,
     LogLevel warn                                                   #i 
tried them elsewhere, including the default.


<VirtualHost *>
     DocumentRoot D:/WWW/CYCs/Admin

    ErrorLog D:/WWW/CYCs/Admin/Logs/admn_error.log
    LogLevel error


<VirtualHost *>
     DocumentRoot D:/WWW/CYCs/Toronto

     ErrorLog D:/WWW/CYCs/toronto/logs/tor_error.log
     LogLevel error



i'd also love to see some examples of placing cgi-bin for each of my named 
servers as follows.

/user1/cgi-bin/   #client rwx
/user1/public/              #client rw
/root/cgi-bin       #client x  (shared cgi-bin)

i think that this question is back on the list just this morning? it get's 
my vote for being in the faq!

ken easson
justken web programming and technical support.

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message