Hi Ed, I appreciate you considering my suggestions. Comments below. On Thu, Jul 12, 2012 at 3:07 PM, Ed Heron <Ed at heron-ent.com> 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. Thanks for incorporating that. However, I think having both forms is even more confusing. I really do like your bash shortcut, but it simply doesn't belong in a document about apache. Maybe there's another page, like BashTipsAndTricks, that it would fit on better? Any time you need to stop and say "hmm, what is going on there", that's not related to the topic at hand, it only slows and confuses the learning process. You may think it's obvious, but that's quite firmly in the "bash guru" category. >> 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. The comment about long-form options was just an aside, and not my main point, but thanks for taking a look at it. >> 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. A wiki page on the CentOS site conveys a certain level of authority. With that authority, one should recommend a consistent and obvious way to do things, since as you say, many people just want a recipe (and there's nothing wrong with that). Being verbose removes any ambiguity about what is going on, and potentially sets a good practice for people to follow. Using the "_" relies too heavily on knowing that the httpd.conf file uses a pattern match for "*.conf" only, and if I was not thoroughly familiar with the httpd.conf file setup and logged into a server the had some files with ".conf", and others with ".conf_", it could be easy to miss. A big fat label of "disabled" makes it quite clear what's going on. In a document like this, the proportion of typing you are saving is insignificant. If someone has an existing convention they use, they won't need to read this document. And, as you say, people are free to set their own conventions, and you would be free to do the same in your internal policies, but for an educational document, it's better to spell things out. >> 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 think the only potential problem with this would have been if the vhosts were somehow order-specific as they relate to the rest of the httpd.conf file, but since they always come last (except that the first vhost overrides the non-vhost config settings, afaik), it shouldn't cause any problems. I like the idea of keeping them separate from conf.d, just because they seem to categorize more nicely that way. ❧ Brian Mathis