Re: [CentOS-docs] reference page for Apache test page & the project
On Sat, Jun 23, 2018 at 4:17 PM, Trevor Hemsley wrote: > On 23/06/18 21:03, John R. Dennison wrote: > > On Fri, Jun 22, 2018 at 04:58:21PM -0700, Karsten Wade wrote: > >> * Is there a better page I can point at? > > 'Better' is quite subjective; however this all goes back to > > > > https://web.archive.org/web/20060523223519/https://www. > centos.org/modules/news/article.php?storyid=127 > > > > and is as good of a reference as any. > > > > I would urge someone to scrape the gist of that thread and preserve it > > on wiki.c.o somewhere. > > > > If no one else does I will do it later today or tomorrow when I have a > > bit of time and motivation. > > You know, perhaps this is approaching this from the wrong direction. > Maybe the correct solution would be to change that welcome page to be > more explicit about what it is and why it's there so the question > doesn't arise in the first place. It *is* better than it used to be but > it could be better. If we just move the "The CentOS Project has nothing > to do with this website or its content, it just provides the software > that makes the website run." up to immediately after the "This server > powered by CentOS" under the Testing 123... heading. > > Does the attached patch make it more clear more easily? It gets the > essential message into the top paragrpah which is the one that gets > read. Having it off the bottom of the page where it resides in the > current version means you're reliant on people advancing to the next page. > > Trevor > How long does one need to be in IT to realize that people simply will not read things, period? Adding more text to an already long-winded page that clearly no one is reading will not solve the problem. The only solution is to eschew vanity completely and make a page that has nothing but "Testing 123" or something equally terse, and possibly mentioning Apache, if that is a requirement somewhere. The only mention of CentOS, should be the "powered by" badge and that's it. I would remove the "powered by CentOS" in the blue header, and then ALL of the text "About CentOS" and below. I understand the intention of trying to help users and admins, but it clearly isn't. As we have seen in the past, this page causes well-known problems, and afaik provides almost no benefit so should be removed. ~ Brian Mathis @orev ___ CentOS-docs mailing list CentOS-docs@centos.org https://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS-docs] Not Installing Properly
On Thu, Jan 10, 2013 at 12:18 PM, R P Herrold herr...@centos.org wrote: On Thu, 10 Jan 2013, sumit gupta wrote: I tried installing Cent-OS 6.3 in my laptop. Its not getting installed normally, i've to install it using basic graphics drivers. post installation my laptop is running hot and when i am trying to install ATI graphix card drivers,its getting stuck at the boot screen. Please help in installing it in my machine. My laptop is HP Pavillion g series. and what documentation that centos ships is wrong? This is not a support venue -- Russ Herrold What Russ is trying to say (allow me to translate from curmudgeon to normal human), is that this list is specifically for discussing CentOS documentation, and is not meant to support users. Please join the discussion and information mailing list, which you can find here: http://lists.centos.org/mailman/listinfo/centos ) where you will (hopefully) receive a warmer reception. ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS-docs] Access request to page TipsAndTricks/ApacheVhostDir
Hi Ed, I appreciate you considering my suggestions. Comments below. On Thu, Jul 12, 2012 at 3:07 PM, Ed Heron e...@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
[CentOS-docs] Access request to page TipsAndTricks/ApacheVhostDir
Requesting access to edit page TipsAndTricks/ApacheVhostDir Looking to make some small edits for clarity. ❧ Brian Mathis ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS-docs] Access request to page TipsAndTricks/ApacheVhostDir
On Wed, Jul 11, 2012 at 11:26 AM, Ed Heron e...@heron-ent.com wrote: On Wed, 2012-07-11 at 10:42 -0400, Brian Mathis wrote: Requesting access to edit page TipsAndTricks/ApacheVhostDir Looking to make some small edits for clarity. ❧ Brian Mathis Yay, somebody read it! What are you suggesting? 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. 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. 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? 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. ❧ Brian Mathis ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS-docs] Contributing Wiki article on tmpfs
Looks good. I appreciate the discussion on the priority of the RAM space used and issues to think about as far as swap space size and when it starts using disk. One thing that concerns me in the tmpfs.txt file is this statement: If you oversize your tmpfs instances the machine will deadlock since the OOM handler will not be able to free that memory. I assume that means you shouldn't allocate more to tmpfs than you have physical memory, but I've also seen other sites suggesting to use size=100% (vmware server tuning). So far I think 100% would be fine, just not 110%. I'm not sure if you have any further insight into that. Anyway, thanks for taking the time to address my comments. On Wed, Nov 4, 2009 at 4:19 PM, Jasper Siepkes jas...@siepkes.nl wrote: Hi, First of all sorry for the long delay and thanks for the constructive feedback. I've made some additions to the Wiki article ( http://wiki.centos.org/TipsAndTricks/TmpOnTmpfs ): -Added the 'Practical details' section to explain how tmpfs, swap and memory relate. -Added a 'Pitfalls' section to warn people of an (IMHO) somewhat misguided piece of advice in the official documentation and maybe some other pitfalls when I think of them. About ramdisks; I will add something later about how tmpfs relates to other ramdisk implementations like cramfs and squashfs. But I haven't done much with the former two so I will need to research those a bit before I can write something down. I'm not the best writer on this continent (Shakespeare beat me by half a point, but I suspect foul play ;-) but I think I've made some steps in the right direction with the article. Please let me know what you think and where I should make some additional improvements. Regards, Jasper On Tue, 2009-10-20 at 14:38 -0400, Brian Mathis wrote: On Tue, Oct 20, 2009 at 1:46 PM, Jasper Siepkes jas...@siepkes.nl wrote: Hi, I've made a first attempt at writing the tmpfs CentOS Tips and tricks item and I'm looking for some feedback. Does it need more (or less) background info ? Or more (or less) substance perhaps ? Regards, Jasper I'd like to see more info on things like: - What is the relationship with swap? - How/when does swap get used instead of RAM? - How do I determine the size of RAM to use? - What impact does using 100% of RAM have on the active memory in the system? - What happens if all system RAM is full, and tmpfs is also full? I think your doc is a good start, but as of now it's got the same info as all the other tmpfs docs out there, and they don't go into much detail about the real impact on a system when using tmpfs. Tmpfs is billed as a more sophisticated ramdisk, so docs addressing it should go into the details of what makes it better. A simple ramdisk just allocates a chunk of RAM, so why is tmpfs better? ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS-docs] Contributing Wiki article on tmpfs
On Tue, Oct 20, 2009 at 1:46 PM, Jasper Siepkes jas...@siepkes.nl wrote: Hi, I've made a first attempt at writing the tmpfs CentOS Tips and tricks item and I'm looking for some feedback. Does it need more (or less) background info ? Or more (or less) substance perhaps ? Regards, Jasper I'd like to see more info on things like: - What is the relationship with swap? - How/when does swap get used instead of RAM? - How do I determine the size of RAM to use? - What impact does using 100% of RAM have on the active memory in the system? - What happens if all system RAM is full, and tmpfs is also full? I think your doc is a good start, but as of now it's got the same info as all the other tmpfs docs out there, and they don't go into much detail about the real impact on a system when using tmpfs. Tmpfs is billed as a more sophisticated ramdisk, so docs addressing it should go into the details of what makes it better. A simple ramdisk just allocates a chunk of RAM, so why is tmpfs better? ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS-docs] New User Wishes to Contribute
On Tue, Oct 6, 2009 at 2:53 PM, R P Herrold herr...@centos.org wrote: On Tue, 6 Oct 2009, Ed Heron wrote: It appears that the people who are preferring the more restricted content guidelines are saying they will accept content separation. But having 2 separate content systems seems redundant. Is there a way to have a section (directory) of the wiki that is core and an expanded section? This might satisfy both sides? Goodness -- wiki.centos.org and wiki.projects.centos.org is too hard or better somehow than wiki.centos.org and wiki.centos.org/projects/ where './projects' content carries a 'this content is not as carefully vetted' disclaimer? The second approach sounds like more of a slam than living in a 'projects.' sub-domain to me. A refactoring of the personal homepages will have to happen in any event, and perhaps we should simply have a './personal/' in the main wiki and move all such into it ... but this then carries the expense of refactoring all the 'at the ./' point documentary narrative down a level as well. ACL errors will be harder to avoid as well By carrying two wiki, we avoid that workload, and can have a self-serve model for getting commits in the 'projects.' one, and the moderated approach on the vetted one. My $0.02 -- Russ herrold All of this debate is dancing around the real issue, and that issue is how the project defines itself. That definition should be arrived at by both the project maintainers and also the community of users. The way I see it, there are 2 main choices: 1) Run the project with a 1-way push model where all the participants are vetted and push out software, documentation, etc... out to all of the users. This places all of the burden on the project maintainers, but the end result is potentially higher quality documentation and product. This seems to be the general model followed right now. One cannot really contribute until going through the approval process, but you make sure that each page has an owner and and the quality is (theoretically) better. 2) Follow the currently more popular community model that is in use in other OSS projects. That means the wiki is generally open to anyone with an account. This model would yield a larger community of people willing to contribute, at the cost of potentially lower quality content (however, I don't not believe that will actually be the case). This model would be a shift in approach from where the project currently seems to be focused. The model for #2 has an escape valve, which is that all of the messy community stuff can happen in the wiki, while the official stuff that has been discussed here would live on the actual centos web site outside of the wiki. If you just so happen to use wiki software to run that official part of the web site, then that should not be called the wiki. ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS-docs] New User Wishes to Contribute
On Thu, Oct 1, 2009 at 3:45 PM, R P Herrold herr...@centos.org wrote: On Thu, 1 Oct 2009, Marcus Moeller wrote: Why not granting Edit rights (and I mean full Edit Group Access) to anyone who has already contributed good stuff. Then there should be something like a Wiki Admin group which will track changes and correct them || start discussion on the MLs if necessary. because creating a problem and fixing it ex post is harder than not creating it in the first place -- Russ herrold Spam issues aside, that is the very concept of Wikipedia and other wikis, and also for all modern VCS tools, and most of them have proven that line of thinking really doesn't hold up. Old VCS tools used the locking model to try to prevent errors before they happened. This created an issue every time someone needed a file, even if they didn't need to change it, and pushed the problem onto everyone all the time. You also needed a dedicated admin who could resolve old locks, etc Modern VCS systems recognize that the problem should only be pushed onto users if there's actually a conflict, and it allows everyone else to work while avoiding problems most of the time. What you currently have is the lock model, and with few admins the idea of opening up the system seems like a bad one because those admins will need to deal with all those errors, but this is not the case. As soon as it's open, you'll have more people monitoring and more people who can fix errors as they are introduced. ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS-docs] document proposal: TipsAndTricks/ApacheVHostDir
On Sat, Aug 22, 2009 at 4:00 PM, Manuel Wolfshantwo...@nobugconsulting.ro wrote: On 08/22/2009 10:29 PM, Ed Heron wrote: It may be my 'heritage' but separate directories is how it is done in Gentoo. While we are at it, let's also add a folder for all existing modules and another one for symlinks of active modules, pointing back to the first folder. And also, let's have all vhosts in a folder, but all active vhosts should be symlinks to them, from another folder. And why not compile the binary from source, that's how gentoo does it ! There's a saying in the US: If you have nothing nice to say, say nothing at all. I think that could be modified a bit to something like If you have nothing constructive to add, and prefer to make passive-aggressive pot-shots from the sidelines, say nothing at all. As for the topic at hand... I am not what one might call an advanced user of apache -- I usually host one or two sites, and even with that minimal config I find it difficult to configure apache by only creating files in the conf.d directory. I've not done a complete analysis, but often it seems like settings in the main httpd.conf file do not get overridden completely for every case. I always end up editing the httpd.conf file when the main purpose for a server is to act as a web server. I'd really like to know how to handle this as close to the CentOS Way as possible. ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS-docs] document proposal: TipsAndTricks/ApacheVHostDir
On Fri, Aug 21, 2009 at 3:41 PM, Ed Herone...@heron-ent.com wrote: I use named virtual hosts on my web servers, as I'm sure many others do. I'm used to the method of using a vhost directory for the container files. I didn't find documentation for it in the CentOS docs or the Apache docs. I'm not sure if I should take it as a hint that it is depreciated... If I've missed something, please point me to it. I've written a quick little article detailing how to create a vhost directory under CentOS. It is at http://wiki.centos.org/EdHeron/ApacheVhostDir Please, consider this a request to create the page TipsAndTricks/ApacheVhostDir with access given to wiki user EdHeron. Ed Heron I always figured that the CentOS way to handle that was to put them into the conf.d folder. Is there an advantage to using this method? One thing I can think of is that the conf.d is included in the middle of the httpd.conf file, while this would be at the bottom. ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS-docs] document proposal: TipsAndTricks/ApacheVHostDir
On Fri, Aug 21, 2009 at 3:41 PM, Ed Herone...@heron-ent.com wrote: I use named virtual hosts on my web servers, as I'm sure many others do. I'm used to the method of using a vhost directory for the container files. I didn't find documentation for it in the CentOS docs or the Apache docs. I'm not sure if I should take it as a hint that it is depreciated... If I've missed something, please point me to it. I've written a quick little article detailing how to create a vhost directory under CentOS. It is at http://wiki.centos.org/EdHeron/ApacheVhostDir Please, consider this a request to create the page TipsAndTricks/ApacheVhostDir with access given to wiki user EdHeron. Ed Heron PS. You could also service reload instead of restart for a more graceful reconfiguration. ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS-docs] Wiki access request
On Thu, Aug 13, 2009 at 7:07 PM, Karanbir Singhmail-li...@karan.org wrote: On 08/13/2009 02:58 PM, Brian Mathis wrote: I wanted to fix an issue that came up on the centos mailing list, and I've also done a bit of work on aligning partitions with RAID stripes. Evolution had added a section on that, and I may be able to elaborate on it. btw, you didnt mention what part of the wiki / pages you wanted edit rights for. Ralph is away from his interwebs for a few days, so perhaps if you are more specific someone else might be able to help! SoftwareRAIDonCentOS5 Disk_Optimization ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS-docs] [CentOS] Dangerous Software Raid instructions on Wiki
On Mon, Aug 17, 2009 at 9:21 AM, Phil Schaffnerphilip.r.schaff...@nasa.gov wrote: Brian Mathis wrote: On Thu, Aug 13, 2009 at 10:06 AM, Phil Schaffnerphilip.r.schaff...@nasa.gov wrote: ... but left /dev/sda and /dev/sdb in place as changing to /dev/sdX|Y looked very awkward to me. ... Phil That's exactly the point of using something like X/Y. It stands out and looks awkward, which draws attention to it and makes people stop and think instead of copy/paste. Feel free to fix it: This page created and maintained by PhilSchaffner. Other Wiki contributors with edit rights are invited to make corrections or additions. Phil I requested access to edit the Wiki last week, but as I only have minor edits to contribute thus far, it has not been granted. Apparently I need to write a dissertation before rights are granted -- proving that I'm not a spammer seems to not be enough. ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS-docs] Wiki access request
On Thu, Aug 13, 2009 at 5:12 AM, Alan Bartletta...@elrepo.org wrote: On 12/08/2009, Brian Mathis brian.mathis+centosd...@gmail.com wrote: Requesting access for BrianMathis on the wiki to make misc edits and contributions. Will you please elaborate on what you have in mind. Alan. I wanted to fix an issue that came up on the centos mailing list, and I've also done a bit of work on aligning partitions with RAID stripes. Evolution had added a section on that, and I may be able to elaborate on it. However, I think that asking people to justify why they want Wiki access highlights the issues that have been brought up in the CentOS Project Infrastructure thread, as far as openness of the project goes. It really seems like contributions are discouraged at every turn. Most projects have an open wiki, but the one on CentOS is closed. The stated reason for that is to prevent spam. That's an acceptable reason, marginally, but one that people can deal with. But the bar then is raised even further where users have to go through this whole process of proposing a topic, submitting ideas, and waiting for them to be approved. That isn't a wiki, that's a peer-reviewed journal -- and it's not what makes OSS communities strong. So do we need to ask for access to ensure we're not spammers, or because some people want control over everything? ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS-docs] [CentOS] Dangerous Software Raid instructions on Wiki
On Thu, Aug 13, 2009 at 10:06 AM, Phil Schaffnerphilip.r.schaff...@nasa.gov wrote: ... but left /dev/sda and /dev/sdb in place as changing to /dev/sdX|Y looked very awkward to me. ... Phil That's exactly the point of using something like X/Y. It stands out and looks awkward, which draws attention to it and makes people stop and think instead of copy/paste. ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
[CentOS-docs] Wiki access request
Requesting access for BrianMathis on the wiki to make misc edits and contributions. ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs