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

[Peter]

On 08/24/2009 08:30 AM, Jon Jensen wrote:
> Nice guide, Peter!

Thanks :-)

> 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?

Well the eventual plans are to stick all of it into a wiki broken up
into multiple pages.  I could leave out the Rackspace stuff but it's not
bad to point a newbie at a good host and give them the extra steps
needed to work with that particular host.  I'll consider renaming it,
though, but would probably rename it just to Centos 5 because at the end
of the day it will work with any point release since the very first step
will update that release to 5.3 (or the latest 5.x) anyways.  Also it
would work with fairly minor tweaks to 4.x and almost certainly will
work fine with 6.x (whenever that is released).

> 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

Good point.

> 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.

Yes, I had that mentioned before and I really should have written it for
nano.  I will change it.  Nano comes in the base install for centos
anyways (even a minimal install) so I can remove the step of installing
the editor that way.

> 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.

The script that I use actually does use the service iptables (or
actually /etc/init.d/iptables which is the same thing) internally in the
script.  At any rate, the service can be used to start and stop iptables
but I like the script for defining the rules for the simple reason that
it is possible for the service to overwrite /etc/sysconfig/iptables.  In
fact a bad update could overwrite that file accidentally as well, then
you've corrupted or lost all your rules.  By putting them into a shell
script that loads them all up (and then saves them with
/etc/init.d/iptables save) you needn't worry about what fate may befall
/etc/sysconfig/iptables as you can merrily re-run the script and all
will be good again.

> 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.

Good thinking and Rackspace provides an easy control panel to do that.

> 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.

Good point, I'll change the text to reflect that.

> 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.

I personally like going with the latest Postgresql when starting a new
install because I know that barring a dump and reload (and probably a
few other headaches as well) I will be stuck with that major version for
a long time, and I have had experience in the past where the RedHat
supplied version became rather old and lacking some features that I
wanted very quickly.  Granted this is not the problem nowadays as it
used to be, though.  I think that when this gets wikified I will push
this step off to a separate page and make it an optional step.

> 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.

I thought so too but when I did the yum install it tried to install some
packages from the Centos Base repository and ended up complaining about
version dependencies.  Adding the exclude line fixed 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).

Good point, I'll change that.  Old habits, heh.

> 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

I wasn't aware of that, thanks.

> 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.

It's the stock CentOS value (/etc/httpd).  As pointed out before I
linked everything into /var/www, though to keep it all in one place.
/etc/httpd should work fine, though as well.

>      + 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.

A patch file won't help a newbie to set his domain name at a certain
place and the temptation will be there to simply apply the patch and
leave it which won't work either.  I actually didn't write this in html,
I just dumped it to html when I was done.  I'll see if I can do
something for readability when it gets wikified.  I'm open to other
suggestions on how to make it easier to find the correct line in the file.

> 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

That was an accidental omission.  Good catch.

> 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.

Good point, I'll change the line.

> 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.

I actually knew that but wanted to keep it relatively simple.  I'll add
something to that effect, though, thanks.

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

hehehe, old habits.

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

I appreciate it and will be making a lot of the changes that you suggest.


Peter