[CentOS-docs] Mail / Web server guides

[Christian Salway]

Ok,  The scripts have been rewritten :)

All packages are now downloaded from base or IUS (or rpmforge for
perl-file-clamav) and I've left selinux enabled, writing some te files :)

Changes have been uploaded http://www.itmanx.com/downloads/scripts.tar.gz

The only problem now is when I log into phpmyadmin, I get the following and
I can't find a solution.

Your PHP MySQL library version 5.1.61 differs from your MySQL server version
5.5.30. This may cause unpredictable behavior.

# rpm -qa mysql*
mysql55-libs-5.5.30-1.ius.el6.x86_64
mysql55-5.5.30-1.ius.el6.x86_64
mysqlclient16-5.1.61-1.ius.el6.x86_64
mysql55-server-5.5.30-1.ius.el6.x86_64


Kind regards,
Christian Salway

-----Original Message-----
From: centos-docs-bounces at centos.org [mailto:centos-docs-bounces at centos.org]
On Behalf Of John R. Dennison
Sent: 25 March 2013 13:17
To: centos-docs at centos.org
Subject: Re: [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