back       next

centos

Upgrade CentOS 5.4 to 5.5 for OpenVZ containers

Edit "/vz/template/centos/5/{ARCH}/config/yum.conf", and change the base and updates repositories as below:

[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

#released updates
[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

Do a `vzyum {VEID} clean all`.

List updates:

vzyum {VEID} list updates

Update:

vzyum {VEID} update

Confirm that all VEs' have been updated to 5.5 with:

cat /vz/root/{VEID}/etc/redhat-release

You should see "CentOS release 5.5 (Final)".

Upgrade CentOS 5.3 to 5.4

Below is a clean method of updating, instead of doing a straight `yum update` which I have often done in the past and broken OS.

yum clean all
yum update glibc\*
yum update yum\* rpm\* python\*
yum clean all
yum update
shutdown -r now

My.Cnf File Issue on Linux Dedicated Server Running CentOS

Dear Anyone.

Hello i came across this website doing a search for My.Cnf tweeks or configurations for the SQL_Max_Connections and i was wondering some things. I have a Linux CentOS system with 2.5 gigs of Ram, Running Apache. and PHP. what would be the "proper" My.cnf file settings for a Music Website i keep getting a max connection overload on the network.

Matthew Nalett
New Music Promote
http://www.newmusicpromote.com

Here is my current My.Cnf settings.
Any Suggestions on how to optimize this for a Music Network?


[mysqld]
set-variable=local-infile=0

rpmdb: unable to lock mutex: Invalid argument

I was caught by this when upgrading CentOS servers from 5.2 to 5.3. Should make it a habit to atleast read the release notes!!

When upgrading from an earlier version of Red Hat
Enterprise Linux to 5.3, you may encounter the following
error:

Updating : mypackage ################### [
472/1655]rpmdb: unable to lock mutex: Invalid argument

The cause of the locking issue is that the shared futex
locking in glibc was enhanced with per-process futexes
between 5.2 and 5.3. As a result, programs running against
the 5.2 glibc can not properly perform shared futex locking
against programs running with the 5.3 glibc.

This particular error message is a side effect of a package
calling rpm as part of its install scripts. The rpm
instance performing the upgrade is using the prior glibc
throughout the upgrade, but the rpm instance launched from
within the script is using the new glibc.

To avoid this error, upgrade glibc first in a separate run,
ie

# yum update glibc
# yum update

You will also see this error if you downgrade glibc to an
earlier version on an installed 5.3 system.

SSH Chroot in ISPConfig Centos-4.6

Below is reference of how I have setup chroot SSH jail for users in CentOS-4.6 with ISPConfig installed replacing the openssh rpm with the one from chrootssh.sourceforge.net .

It's easy on ISPConfig as support for chroot SSH is now built in with the control panel, you simply need to get chrootSSH installed and then enable the ssh option located in the config file at "/home/admispconfig/ispconfig/lib/config.inc.php":

$go_info["server"]["ssh_chroot"] = 1;

If you need for the ssh chroot to access additional application, the file "/root/ispconfig/scripts/shell/create_chroot_env.sh" which builds the chroot needs to be edited. Also, check and edit the location of mysql socket file.

Migrating ISPConfig CentOS server

Recently did a full server migration with ISPConfig installed. Luckily it was within the same distro but an updated version of CentOS-4.5, had to add centos-4.5 support to ispconfig conf file prior to the install. I also made sure that I was installing the same version of ISPConfig on the new server, and upgrading to the latest once the migration was complete and the server stable.

These are just notes I took down for later reference, just in case it happens again!!

Preparation:

In preparation for the migration, create A records to point to the new server IP, for all domains to do temporary redirection:

{newhost.domain.tld} : xx.xx.xx.xx
www1.{domain.tld}    : xx.xx.xx.xx

Syndicate content