[CentOS-docs] Mail / Web server guides

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/centos-docs/attachments/20130325/91ccfae8/attachment.sig>