>
>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:
>http://httpd.apache.org/userslist.html#archives
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
list.
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:
ServerName www.justken.net
DocumentRoot "C:/wwwroot"
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory "C:/wwwroot">
Options All MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
then later on...
<IfModule mod_alias.c>
Alias /samples/ "D:/WWW/samples/" # which work just fine at
justken.net/samples
<Directory "D:/WWW/samples/">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
and my virtual config...
NameVirtualHost *
<VirtualHost *> #notice this one is redundant, or else i get nothing at all.
ServerAdmin justken@rogers.com
ServerName justken.net
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>
<VirtualHost *>
ServerAdmin justken@rogers.com
ServerName admin.youthcircle.net
DocumentRoot D:/WWW/CYCs/Admin
ErrorLog D:/WWW/CYCs/Admin/Logs/admn_error.log
LogLevel error
</VirtualHost>
<VirtualHost *>
ServerAdmin justken@rogers.com
ServerName toronto.youthcircle.net
DocumentRoot D:/WWW/CYCs/Toronto
ErrorLog D:/WWW/CYCs/toronto/logs/tor_error.log
LogLevel error
</VirtualHost>
#end
i'd also love to see some examples of placing cgi-bin for each of my named
servers as follows.
/user1/cgi-bin/ www.user1.net/cgi-bin #client rwx
/user1/public/ www.user1.net #client rw
/root/cgi-bin www.user1.net/cgi #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.net
justken@rogers.com
justken web programming and technical support.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
>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:
>http://httpd.apache.org/userslist.html#archives
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
list.
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:
ServerName www.justken.net
DocumentRoot "C:/wwwroot"
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory "C:/wwwroot">
Options All MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
then later on...
<IfModule mod_alias.c>
Alias /samples/ "D:/WWW/samples/" # which work just fine at
justken.net/samples
<Directory "D:/WWW/samples/">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
and my virtual config...
NameVirtualHost *
<VirtualHost *> #notice this one is redundant, or else i get nothing at all.
ServerAdmin justken@rogers.com
ServerName justken.net
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>
<VirtualHost *>
ServerAdmin justken@rogers.com
ServerName admin.youthcircle.net
DocumentRoot D:/WWW/CYCs/Admin
ErrorLog D:/WWW/CYCs/Admin/Logs/admn_error.log
LogLevel error
</VirtualHost>
<VirtualHost *>
ServerAdmin justken@rogers.com
ServerName toronto.youthcircle.net
DocumentRoot D:/WWW/CYCs/Toronto
ErrorLog D:/WWW/CYCs/toronto/logs/tor_error.log
LogLevel error
</VirtualHost>
#end
i'd also love to see some examples of placing cgi-bin for each of my named
servers as follows.
/user1/cgi-bin/ www.user1.net/cgi-bin #client rwx
/user1/public/ www.user1.net #client rw
/root/cgi-bin www.user1.net/cgi #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.net
justken@rogers.com
justken web programming and technical support.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org