[ic] New guide for setting up a Centos / RHEL 5 server and installing Interchange

[Jon Jensen]

On Mon, 24 Aug 2009, Peter wrote:

> I have just completed documenting the process I use to fully configure 
> and secure and Rackspace cloud server with a Centos5.3 image.  While 
> this guide has some sections that are specific to Rackspace it should be 
> easy to use it for nearly any Centos or Redhat system.
>
> The guide is at: 
> <http://cloud.github.com/downloads/pajamian/stuff/Rackspace_Interchange_Setup.html>
>
> Thanks in advance for any feedback.

Nice guide, Peter!

Looking it over, it seems it would be better named the "CentOS 5.3 
Interchange Setup", because it has almost nothing to do with Rackspace's 
particular offering, so that unnecessarily limits its audience. You could 
still have a section that is Rackspace-specific at the beginning, but 
everything else is generic CentOS 5.3 stuff, right?

Here are some notes I made of things you may want to consider:

Where you say:

     Run updates:

     # yum update

     * Answer "Y" to all the prompts.

Whenever you say to answer yes to all prompts without even thinking about 
what they're asking, you'd might as well skip the questions by suggesting:

     yum update -y

If you're writing for an audience that doesn't much know CentOS, it may be 
good to mention other simpler editors than emacs, such as nano which is 
available in CentOS.

For iptables you say:

     * recommend that you put all your iptables rules in a shell script and
     run that script to update the rules. You can download and edit the
     basic script that I use to setup iptables.

     $ cd ~
     $ wget http://github.com/pajamian/stuff/raw/1d652316f87fbbbbec1212e0d7de55c85b522b18/centos/iptables_cfg.sh
     $ chmod 700 iptables_cfg.sh
     $ emacs iptables_cfg.sh

With only a little tweaking you can move your iptables rules into a 
standard RHEL iptables file in /etc/sysconfig/iptables, and then use 
"service iptables {stop,start,restart}" and chkconfig to deal with it 
instead of a nonstandard script. Take a look at the existing file, as it's 
very similar to manual invocations of iptables and easy to adapt to.

Under DNS, you may want to mention setting up reverse DNS if you want any 
hope of email (receipts, etc.) being successfully sent from the machine.

About Postgres you say:

     "The version of PostgreSQL available from the Centos YUM repositories 
is old and not kept updated."

That's not quite accurate. The version of PostgreSQL is pegged to the 
major version that was current when CentOS 5 was released, Postgres 8.1, 
because of the upgrading issues you mention. But it *is* kept updated by 
Red Hat. New point releases are made, and important fixes are backported 
from newer releases. It is quite safe and sane to use the stock CentOS 5 
Postgres if you don't need newer features from later versions.

It's great to show people how to upgrade Postgres, but you may want to 
consider skipping that actually because then you don't have to mess with 
re-adding implicit casts, and have one less nonstandard thing to add to 
CentOS. But in any case, it should be made clear that the version in 
CentOS *is* kept updated for bugfixes etc.

Also, if you do have users upgrade Postgres, this should not be necessary:

     sudo emacs /etc/yum.repos.d/CentOS-Base.repo

     * at the end of the [base] section right after the gpgkey line add the following line:

     exclude=postgres*

Because RHEL/CentOS won't release a newer major version of Postgres than 
is in the repo, there's no need to exclude it.

A style consideration: For several releases of RHEL/CentOS, the 
/sbin/service facility has been the standard way to manage services, 
rather than calling /etc/init.d scripts directly. It's not functionally 
much different at the moment, but does some environmental stuff and is 
meant to plan for a future that doesn't necessarily revolve around 
SysV-style init scripts living in /etc/init.d. So I suggest replacing 
/etc/init.d/ with /sbin/service (or just "service" if you aren't using 
sudo and have root's default PATH).

On connecting with psql:

     sudo -u postgres psql template1

Starting with Postgres 8.0, IIRC, there is a new "postgres" default 
database that is the recommended and default database for connecting to, 
instead of "template1". This keeps template1 from being polluted if 
someone makes a mistake in where they create objects, and prevents locking 
problems where you can't create a new database because some user is 
connected to template1.

So everywhere you connect to template1, instead just don't say anything 
and psql will connect to "postgres" instead:

     sudo -u postgres psql

A typographical suggestion: s/Centos/CentOS/g to match the way CentOS 
capitalizes their own name and, for me at least, to improve readability.

Apache config:

Why do you change ServerRoot? I don't know what Rackspace's defaulted to, 
but you shouldn't need to change it if it's the stock CentOS value.

     + Line 761: Uncomment to allow compression of pages to save on bandwidth

     AddEncoding x-compress .Z
     AddEncoding x-gzip .gz .tgz

Unless you're actually manually compressing static files in your docroot 
and leaving the .gz files there, the above has no effect. It definitely 
doesn't do anything with Interchange pages or anything automatically.

A more commonly useful suggestion would be to enable mod_deflate to 
compress most output, including Interchange pages. See:

     http://httpd.apache.org/docs/2.2/mod/mod_deflate.html

All those mentions of line numbers in httpd.conf is very fragile. At the 
least I would recommend you also include a patch file, and since it's 
HTML, you can colorize it for even easier readability.

Afterwards you say "Start Apache" but I didn't see you show how is 
standard on CentOS. Might as well show it: /sbin/service httpd start

Later in discussing Postgres setup, you say:

     create user interch password 'password';

That should really be:

     create user interch with encrypted password 'password';

Otherwise a plaintext password gets stored in the database and shuttled 
around during connections.

But also note that by default, Postgres as configured in pg_hba.conf does 
ident authentication, not password, so connections from the local machine 
don't actually use a password at all but instead allow only the system 
"interch" user to connect as the Postgres "interch" user. If you want to 
change that, edit /var/lib/pgsql/data/pg_hba.conf.

Minor save the tildes suggestion: "cd ~" can be replaced by simply "cd", 
because $HOME is cd's anyway.

Again, nice writeup, and I hope you find this of some use.

Thanks,
Jon

--
Jon Jensen
End Point Corporation
http://www.endpoint.com/