Re: Access request to page TipsAndTricks/ApacheVhostDir

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2012-07-12 at 13:07 -0600, Ed Heron wrote:
> On Wed, 2012-07-11 at 19:40 -0400, Brian Mathis wrote:
> >  
> > The use of "mv -v ...{,_}" is too clever for this kind of educational
> > document, and should be changed to spell out the full "mv" command.  I
> > get what you're doing there, but the purpose of the document is not to
> > teach clever uses of bash, it's to make it obvious to people that
> > you're renaming the file.  It will trip up the flow of reading for all
> > but the most knowledgeable users, and users who don't understand it
> > will be totally lost.
> 
>   I'm not trying to be clever, I just don't like to type it twice if I
> can avoid it and the typing the higher the chance for a typo.  I don't
> have a problem having both forms.  I'll add it and see what you think.
> 
> > In most documents and scripts, I usually spell out the short form
> > options as well, such as using "--verbose".  Short forms save you
> > typing, but documentation should not trip people up if they don't know
> > what the option means.
> 
>   Normally, I expect, if people don't understand a command, they will
> refer to the man page for the command.  However, to my constant
> disappointment, I understand that many people aren't looking for long
> term knowledge improvement, they are looking for a recipe to blindly
> follow.
> 
> > Also, I find the use of "_" to be obtuse and highly error prone if one
> > were to actually run a server that way.  It's far more obvious to use
> > "disabled", which makes it very clear that those items are disabled.
> > It may work for you but only because that's a convention you came up
> > with so you're used to it, but we're not in dos 8.3 days with
> > filenames, so why not be more descriptive?
> 
>   Having both forms should make it plain that people can use any
> convention they wish.  System administration is not a fixed target.
> Like many things, there are many ways to accomplish the same result.
> When approaching a system that someone else is administrating, we should
> try to maintain the existing conventions instead of forcing our own
> ideas onto a server for which we are not the primary responsible party.
> 
> > In section 6.4, is there a reason not to make a "vhosts.conf" file
> > that contains the "Include" in the in the conf.d/ directory, instead
> > of appending to the httpd.conf, or do you run into ordering issues
> > there?  I try to avoid changing the distro files if possible.
> 
>   Sections 6 and 7 are optional.  There are certainly arguments against
> customization.  In the past, upgrades might have replaced all files
> including configuration files.  In that case, creating a vhosts.conf
> file in the conf.d directory to separate the directive would have been a
> must.  However, the Linux distributions I have used for the past decade
> or so have avoided replacing existing configuration files, expecting
> they might be customized.
> 
>   That said, I like the suggestion.  It would allow for the virtual host
> files to be packaged into an RPM file that could be installed on
> multiple web hosts.
> 
> > 
> > ❧ Brian Mathis

  I made the changes I've described about a week ago.  Brian, does that
satisfy your concerns?  Does anybody else agree with Brian?  Have the
changes I've made make it easier to read the document?


_______________________________________________
CentOS-docs mailing list
CentOS-docs@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos-docs



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Users]     [CentOS Virtualization]     [Linux Media]     [Asterisk]     [Netdev]     [X.org]     [Xfree86]     [Linux USB]     [Project Hail Cloud Computing]

  Powered by Linux