CentOS docs - Dec 2009 - "TipsAndTricks/ApacheVhostDir" changes for virtual host source files

I see someone has noticed my lack of suggestions or recommendations for 
placement of virtual host source files...

  Since there are many places to put virtual host source files, I had 
intentionally avoided the discussion due to the complexities and to keep the 
document restricted to a single topic.  I had planned to create a separate 
document devoted to the discussion.  Specifically, there are a couple of 
SELinux related issues to work out with a couple of them.  I would start a 
discussion of the various places to put virtual host source files and the 
issues associated with them.  Where should such a discussion take place?  In 
one of the forums or on this list?

  However, I'm not sure what is meant by " The following section is the
approach advocated by its initial author, EdHeron. It is not clear that 
varying from the approach above is warranted, and by the version from him, 
does not explain the needed SElinux changes."
  It appears to suggest my disclaimer, "Another method, for those of us
that
might have a tendency to 'over engineer', is creating a new directory, 
vhost.d for example, and putting an include where the configuration, as 
distributed, has the virtual host example. This retains the position of the 
virtual host definitions in the Apache configuration", isn't enough to 
discourage most system administrators from using it or explain my reasons 
and give a reader a hint that there are other ways, even, from the three 
discussed?
  As far as the SELinux issue, from the directory listing that accompanies 
the directory creation instruction, a reader might notice that the SELinux 
user is listed as root instead of system_u.  The SELinux user discrepancy is 
resolved with the chcon command shown.  Is there a desire for additional 
explanation of the process?
  The additional warning against the vhost.d/ section seems to excessively 
disparage my contribution and discourage other options.  Certainly, it could 
be considered impolite to expand and significantly modify the content of a 
document when the author is available and willing to make changes.  As well, 
I seek to improve my documentation technique and by-passing me deprives me 
of the opportunity.

  I'd like to know the process that culminated in the changes to my 
document.  Are there a large number of people reading the document, not 
understanding it but making non standard changes to their systems, and 
requesting support?

--------------------
Ed Heron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: attention.png
Type: image/png
Size: 164 bytes
Desc: not available
URL:
<http://lists.centos.org/pipermail/centos-docs/attachments/20091216/4ee25a92/attachment-0006.png>

On Wed, 16 Dec 2009, Ed Heron wrote:
> I see someone has noticed my lack of suggestions or recommendations for 
> placement of virtual host source files...
That would be me

A questioner reading the page in IRC today was confused by the 
article.  I added the pointer to the 'official' doco location 
for the conf files, a sample stanza showing an approach 
without alias wildcarding, and a reasonable approach 
consistent with SELinux for location of content pages and CGI 
that does not break SElinux expectations.
> Since there are many places to put virtual host source files, I had 
> intentionally avoided the discussion due to the complexities and to keep
the
> document restricted to a single topic.  I had planned to create a separate 
> document devoted to the discussion.  Specifically, there are a couple of 
> SELinux related issues to work out with a couple of them.  I would start a 
> discussion of the various places to put virtual host source files and the 
> issues associated with them.  Where should such a discussion take place? 
In
> one of the forums or on this list?
The wiki diff's speak, this mailing list speaks; as noted in 
the reorg discussion on web presence, the Forums seem to 
attract a different type of editor; it drew a proposal for yet 
another FAQ, it drew Les M with a request for (but no work 
done to make) a recap of the mailing list with editorial 
cleanup.

The issue remains: Who does work and who cleans up when there 
is not funding to incentivize such, and why?  My answer is to 
clean up when CentOS' reputation is impaired.  As I read it, 
this particular content has rotted (seemingly half done 
without warning guards, as I read your comment) with your 
'inside' "intent to come back to the topic" unknown and 
unknowable to an outside observer.
> However, I'm not sure what is meant by " The following section is
the
> approach advocated by its initial author, EdHeron. It is not clear that 
> varying from the approach above is warranted, and by the version from him, 
> does not explain the needed SElinux changes."
> It appears to suggest my disclaimer, "Another method, for those of us
that
> might have a tendency to 'over engineer', is creating a new
directory,
> vhost.d for example, and putting an include where the configuration, as 
> distributed, has the virtual host example. This retains the position of the
> virtual host definitions in the Apache configuration", isn't
enough to
> discourage most system administrators from using it or explain my reasons
and
> give a reader a hint that there are other ways, even, from the three 
> discussed?
Do you explain a _good_ reason that warrants a non-standard 
approach?  I sure don't see one.  More on SElinux matters in a 
bit

I put the discouragement in because the reader was confused. 
In so far as the questioner was reading it -- the absence of a 
set off, and no <!> caused him to ** not ** see the issues. 
As such I added the

-----

and the <!>

and made the {{{ }}} box around it

I do not consider your approach some cute form of 
'over-engineering' but rather a method ignoring the well 
docoed ways in the doco we provide.  Personal makework 
perhaps, not rationalized as, say, part of a larger VHost 
management automation system.  Not durably integrated as 
the CentOS operating system reputation implies.  Change for 
its own sake, alone.   Basically, out of place.
> As far as the SELinux issue, from the directory listing 
that accompanies the 
> directory creation instruction, a reader might notice that the SELinux user
> is listed as root instead of system_u.  The SELinux user discrepancy is 
> resolved with the chcon command shown.  Is there a desire for additional 
> explanation of the process?
That a person *might* notice something -- gawd -- Compare to 
my added content's the express callouts (check the timestamps 
on the diffs) that expressly note two TLD, and an explained 
policy on the use of an Alias sub-line.  CentOS users don't 
sit down for a good read with our doco anyway and when under 
pressure, less so still, it seems.

To documentation 'gotcha' and playing 'hide and seek' games is 
not for me -- I'll rip it out or add guard rails, every time I 
see such, thanks.

Back to SElinux, as promised:  ... and does it build a 
persistent local policy add-on?  does it persist through 
relabels? how about updates affecting the directory by the RPM 
package management system, possibly mediated by yum, which 
does the restorecon?
> The additional warning against the vhost.d/ section seems to excessively 
> disparage my contribution and discourage other options.  Certainly, it
could
> be considered impolite to expand and significantly modify the content of a 
> document when the author is available and willing to make changes.  As
well,
> I seek to improve my documentation technique and by-passing me deprives me
of
> the opportunity.
I did not see you in the IRC channel, interacting with the 
questioner.  The wiki, when not 'according to Hoyle' as to the 
otherwise documented practice, will be edited at once [thus, 
a wiki]
> I'd like to know the process that culminated in the changes to my
document.
> Are there a large number of people reading the document, not understanding
it
> but making non standard changes to their systems, and requesting support?
great questions.  The answers are not state secrets

The wiki as set up provides the stats.  Does anyone but me 
read them?  I've said it here before, and it is still true: I 
read the diff's on every page, admittedly in arrears as it is 
dog dull, but I do and try to spot problems to edit. Then I 
see anohter editor catch proof reading edits; then I see the 
Chinese 'zh' translation picked up (but none of the other 
translators)

***  thanks, TimothyLee for being there for the project ***

Make me wonder why we are spending time thinking about 
alternative language subsites, when the wiki is not being 
translated as well by others.

-- Russ herrold

Ed Heron wrote:
>  I see someone has noticed my lack of suggestions or recommendations for 
> placement of virtual host source files...
> 
>  Since there are many places to put virtual host source files, I had 
> intentionally avoided the discussion due to the complexities and to keep 
> the document restricted to a single topic.  I had planned to create a 
> separate document devoted to the discussion.  Specifically, there are a 
> couple of SELinux related issues to work out with a couple of them.  I 
> would start a discussion of the various places to put virtual host 
> source files and the issues associated with them.  Where should such a 
> discussion take place?  In one of the forums or on this list?
> 
>  However, I'm not sure what is meant by " The following section is
the
> approach advocated by its initial author, EdHeron. It is not clear that 
> varying from the approach above is warranted, and by the version from 
> him, does not explain the needed SElinux changes."
>  It appears to suggest my disclaimer, "Another method, for those of us
> that might have a tendency to 'over engineer', is creating a new 
> directory, vhost.d for example, and putting an include where the 
> configuration, as distributed, has the virtual host example. This 
> retains the position of the virtual host definitions in the Apache 
> configuration", isn't enough to discourage most system
administrators
> from using it or explain my reasons and give a reader a hint that there 
> are other ways, even, from the three discussed?
>  The additional warning against the vhost.d/ section seems to 
> excessively disparage my contribution and discourage other options.  
> Certainly, it could be considered impolite to expand and significantly 
> modify the content of a document when the author is available and 
> willing to make changes.  As well, I seek to improve my documentation 
> technique and by-passing me deprives me of the opportunity.
> 
>  I'd like to know the process that culminated in the changes to my 
> document.  Are there a large number of people reading the document, not 
> understanding it but making non standard changes to their systems, and 
> requesting support?
> 
For what it's worth, Ed, I use the vhost.d container method as well. 
It's what I was taught and shown how to do. My IT manager has been doing 
so for years, and never had issues or troubles. Don't be discouraged, 
although it's easy to do in here anymore.

Regards,
Max