From: "R P Herrold", Wednesday, December 16, 2009 4:24 PM
> 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.
Thanks. I appreciate the overview of your process.
>> 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.
I agree that the docs need to be clear. I have my documents in my watch
list specifically so I can maintain them. I will try to make them less
likely to be misinterpreted. Though I disagree with putting information
into this document about where to put virtual host source files.
>> 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
The terms, 'non-standard' and 'good', are fuzzy here. Many people use
vhost.d/ for virtual host container files. With Linux, the standard is as
people do. Upstream doesn't prohibit using vhost.d/ and it doesn't break
the standard. To satisfy the standard of 'good' for you is probably never
going to happen as you don't agree with segregating the module configuration
files and the virtual host container files. I don't have an issue with your
opinion being different from mine.
> 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.
I put the 'cute' over-engineering comment in there (and I don't deny that
it wasn't appropriate) because I didn't have a simpler cohesive reason for
using vhost.d/. I'm not the one that created the concept, but I like it for
it's esthetics. I am endevouring to explain the concept and reasons behind
it with updates to the article.
>> 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.
I'm aiming to have a document that allows for cutting and pasting commands
while including simple descriptions for people that do spend the time to
read. Of course, references to further reading for the ones (few?) that
wish to go further.
> 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.
I mentioned my desire to include a section on where to put virtual host
source files in a list e-mail on September 4th. There wasn't a response and
I haven't had the time, yet, to follow through on it. Thank you for
reminding me of the need.
> 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?
This concern was brought up in a previous discussion about my document on
September 3rd. Thanks to some prompting from Filipe, I found:
semanage fcontext -l | grep '/etc/httpd'
returns
/etc/httpd(/.*)? all files
system_u:object_r:httpd_config_t:s0
and doesn't specifically mention conf.d/, so conf.d/ and vhost.d/ should
survive filesystem relabelling equally well. Unless my understanding is
insufficient. I would appreciate some links to appropriate information if
that is the case.
>> 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 applaud you spending so much of your personal time assisting people on
IRC and other venues. I would prefer to be able to do that, as well. One
of the reasons for me participating in the wiki is because I wish to help
others. I see myself in a support role, so that more active people can
provide pointers to docs to streamline your process.
>> 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 ***
I've looked at the list of changes, when I have time, to see what has been
added and occasionally do some proof reading. It expands my knowledge of
CentOS and what people are doing with it. That TimothyLee is so responsive
with the translation of new and updated content is incredible. I am
impressed with his commitment. Thanks!
> 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