On Mon, Mar 25, 2013 at 10:41:31AM -0000, Christian Salway wrote: > > Firstly, "If such issues could possibly be resolved I feel these scripts > would be very beneficial to many users.", who better to help out with that > than you by the sounds of it. I've already worked this space and have had solutions in place for such provisioning for many, many years; I was not including myself in that "many users" category :) > Anyway, although I would love a perfect system the way CentOS org intended > it, there are many reasons why I have done the scripts the way I have. > Mainly because there is not always the documentation out there to be able to > achieve the centos perfect result, or the packages available in the > 'preferred' repos are out-of-date, so people like me find the 'best' > solution they can. But the point is... your solution leaves one wide-open for security problems down the road from 1) lack of policy enforcement and 2) unpackaged solutions that will, more than likely, end up missing some updates down the line. Especially when you are talking about such poor codebases as phpmyadmin with <sarcasm>it's absolutely stellar record of no security issues</sarcasm>. > selinux > I'm all about security but there just isn't any good documentation for > managing selinux! That's patently untrue. > If there was, SELINUX would still be enabled. For > instance, how to allow selinux to let pureftp and apache share the same > files, show me a simple guide on that! You mean like the one on the centos wiki or any of the documentation provided by Redhat and Fedora? Here's a list of links to get you started: http://wiki.centos.org/HowTos/SELinux http://wiki.centos.org/TipsAndTricks/SelinuxBooleans http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/ http://fedorasolved.org/security-solutions/selinux-module-building http://centoshelp.org/security/selinux-common-commands-troubleshooting There are, of course, many, many additional resources. Really... this endless loop I hear about lack of documentation might have been true a number of years ago but it is not the case, nor has it been the case for quite some time. > perl-File-Scan-ClamAV > I used http://wiki.apache.org/spamassassin/ClamAVPlugin to interact ClamAV > and spamassassin which mentions File::Scan::ClamAV but which wasn't > available in the repositories I had chosen, so clicking on the link took me > to cpan, which I then found a way to automate the install off. I see no > reason why it wasn't a good way of doing it as you get the latest version > and it's only an add-on module to perl. And it's unpackaged, therefore rpm/yum know absolutely nothing about it which may well lead to conflicts down the road. There is also the "it's unpackaged so therefore it may well lack in applied updates" issue. While _you_ may well be disciplined enough to check for and apply updates as necessary, the people that would be relying on your scripts may not be as disciplined - cookie cutter solutions such as _packaged_ applications are a better fit for most. perl-File-Scan-ClamAV is in rpmforge. If you are unhappy with the version they offer and you are willing to maintain it yourself then you can use cpanspec or cpan2rpm and create a binary rpm package; this process will use the sources available from cpan and build up an arch (i386/x86_64) or noarch binary package as necessary. > phpmyadmin > What is so wrong about downloading the latest html files direct from the > developers website? Nothing is 'installed' into the system and the > repositories rarely have the latest version. You are basically asking the > CentOS uses to stay in the dark from new and improved versions of software > until you 'have the time' to add them to the repositories! Because latest != greatest. Oh! Shiny! isn't generally worth the trouble that comes with it. And phpmyadmin is a very good example. The versions in rpmforge/epel are tested and vetted which is more than can be said for phpmyadmin itself. And I am not asking users to do anything except understand what an enterprise system is and how to work with it instead of against it. It's your box, do with it as you please. But when you are writing solutions for others it's best to stay with Best Practice for the platform. > UTC timezone > The timezone script was for simplicity with my setup only and can obviously > be removed. Although I'm sure a half-witted donkey can figure out how to > change it. That's not the point. You are making a change to someone else's box that may have significant operational impact. Yes, it can be argued that people should review scripts before they run them, but let's face it, most people don't bother. > Remi over rpmforge > I tried to install mysql from rpmforge but it just wasn't happening. Their > mysql_libs are still old and thus causes a warning in phpmyadmin. Why would you go outside the distribution for an alternate mysql package for something as ridiculous as phpmyadmin? Additionally rpmforge has never shipped a newer mysql as for as I know. If you would have used a packaged phpmyadmin this would be a non-issue as the packaged versions work with the native mysql out of the box. If for some reason you require (require, not want) a newer mysql use that which is distributed by IUS. Incidently, IUS is the public repo from Rackspace and contains newer versions of packages that CentOS provides; but they do it in an intelligent manner that prevents most common problems from such practices. It's also very well vetted and can be trusted as it's what Rackspace themselves use for their paying customers. Information on rpmforge, EPEL, IUS and other known and vetted 3rd-party repos can be found at: http://wiki.centos.org/AdditionalResources/Repositories. > Although CentOS may be a packaged managed system, most of the time the > packages in the repositories are way behind, resulting in system > administrators like myself having to install versions with security > concerns, bugs or unavailable useful features that is just simply > ridiculous, all because you want users to follow suit. I cry foul. You really don't understand the enterprise linux ecosystem at all. As this is documented on the centos wiki and many other locations I'm not going to attempt to illuminate you here. I would urge you to spend some time reading up on the concepts of an Enterprise Linux distribution, esp that regarding selinux, packaging and backports. You may find backports in particular an interesting read: http://www.redhat.com/security/updates/backporting/?sc_cid=3093 > If you would like to add your tweaks to the scripts, I would be more than > happy to re-upload them to my downloads area... but something tells me the > answer will be 'when I have time'. I may well have been willing to add the minimal changes to your scripts to satisfy the engineering issues I have with them. At least until the "when I have time" comment and what I see as senseless defense of your choose direction. > Nb. I'm just testing CentOS6.4 as it was just released, so these scripts > might change again. There is no reason anything should have to change due to 6.4; 6.X should be compatible at the API / ABI layer from 6.X-1 and 6.X-2, etc. Christian, Please do not let my comments detract you from further enhancement of your scripts. As I said, I believe they fill a niche and that a number of people would make use of them. But please address the concerns I've mentioned here. If you do, I would be happy to have another look at them when you're done. John -- Much of what looks like rudeness in hacker circles is not intended to give offense. Rather, it's the product of the direct, cut-through-the-bullshit communications style that is natural to people who are more concerned about solving problems than making others feel warm and fuzzy. http://www.tuxedo.org/~esr/faqs/smart-questions.html
Attachment:
pgpEL3adbluys.pgp
Description: PGP signature
_______________________________________________ CentOS-docs mailing list CentOS-docs@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos-docs
