Category: IT

You can create an LVM physical volume directly on a raw block device, but I avoid it. It can cause confusion later about what the disk is used for, and it can break some of LVM’s auto-discovery if its configuration files are missing. Instead, I put a single LVM partition on each disk first.

1. Partition the Disk with parted

This creates a GPT label with one partition spanning the whole drive and sets the LVM flag. The 1M start offset ensures proper alignment. mkpart requires a filesystem type, but it doesn’t actually create a filesystem (a long-standing parted quirk).

parted /dev/sdb
mklabel GPT
mkpart primary ext2 1M 100%
set 1 lvm on
quit

2. Create the Physical Volume, Volume Group, and Logical Volume

pvcreate /dev/sdb1
pvdisplay
vgcreate vg_name /dev/sdb1 /dev/sdc1 /dev/sdd1
vgdisplay
lvcreate --extents 100%FREE -n lv_name vg_name
lvdisplay

The vgcreate example combines three prepared disks (sdb1, sdc1, sdd1) into one volume group. Replace vg_name and lv_name with your own names.

3. Create the Filesystem and Check It

mkfs.xfs -f /dev/mapper/vg_name-lv_name
df -ah

To grow an existing volume instead, see how to extend an LVM logical volume on CentOS.

Older CentOS servers use sysklogd, which can’t forward logs over TCP with a disk queue. Here’s how to swap it for rsyslog and send everything to Splunk.

1. Swap sysklogd for rsyslog

Use yum shell to remove and install in one transaction:

yum shell
remove sysklogd
install rsyslog
run
exit

2. Add the Splunk Forwarding Rule

Edit /etc/rsyslog.conf and paste in this block, replacing your-splunk-server with your Splunk host:

# ### begin forwarding rule ###
# The statement between the begin ... end define a SINGLE forwarding
# rule. They belong together, do NOT split them. If you create multiple
# forwarding rules, duplicate the whole block!
# Remote Logging (we use TCP for reliable delivery)
#
# An on-disk queue is created for this action. If the remote host is
# down, messages are spooled to disk and sent when it is up again.
$WorkDirectory /var/lib/rsyslog # where to place spool files
$ActionQueueFileName fwdRule1 # unique name prefix for spool files
$ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible)
$ActionQueueSaveOnShutdown on # save messages to disk on shutdown
$ActionQueueType LinkedList # run asynchronously
$ActionResumeRetryCount -1 # infinite retries if host is down
# remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional
*.* @@your-splunk-server:514
# ### end of the forwarding rule ###

3. Enable and Restart rsyslog

chkconfig rsyslog on
service rsyslog restart

See also forwarding CentOS syslog to Splunk with rsyslog.

Our new Dell PowerEdge R815 hosts had strange latency on iSCSI traffic running over Broadcom NICs on a dedicated, segregated storage LAN.

The Fix: Update the Broadcom NetXtreme II Driver

The solution was the updated Broadcom NetXtreme II driver bundle:

BCM-NetXtremeII-5.0-offline_bundle-940344.zip

1. Import the offline bundle into VMware Update Manager.
2. Attach it to the hosts in a baseline and remediate.
3. Reboot each host.

After one reboot, the latency was gone and everyone was happy.

On VMware ESX/ESXi, changes to the root crontab are lost when the host reboots. Here’s how to add a cron job that survives reboots by re-creating it from /etc/rc.local.

Enable SSH on the host first, then log in as root.

1. Add the Job to the Root Crontab

1. Edit /var/spool/cron/crontabs/root.
2. Add your job on a single line, for example:

5 0 * * * /full/path/to/script arguments/with/full/path > /full/path/to/logfile 2>&1

3. The file is read-only, so save and quit vi with Esc then :wq!.

5 0 * * * means 5 minutes past midnight every day. See the crontab(5) man page for the full schedule syntax.

2. Re-create the Job at Boot via /etc/rc.local

Edit /etc/rc.local (for example, vi /etc/rc.local) and add these three lines at the end. The first stops crond, the second appends your job to the root crontab, and the third starts crond again:

/bin/kill $(cat /var/run/crond.pid)
/bin/echo '5 0 * * * /full/path/to/script arguments/with/full/path > /full/path/to/logfile 2>&1' >> /var/spool/cron/crontabs/root
/bin/busybox crond

Save and exit, then run the command below so your /etc/rc.local change itself survives a reboot:

auto-backup.sh

Remember: every time you change the cron job, update /etc/rc.local too and run auto-backup.sh again.

If WordPress “post name” permalinks return 404 errors on an Apache server, Apache probably isn’t allowing the .htaccess rewrite rules WordPress depends on. The fix is a one-line change.

Steps

1. Open the Apache configuration file at /etc/httpd/conf/httpd.conf.
2. Find the Directory block for your DocumentRoot, normally <Directory "/var/www/html">.
3. Change AllowOverride None to AllowOverride All.
4. Restart Apache.

<Directory "/var/www/html">
    AllowOverride All
</Directory>

service httpd restart

This step is essential for WordPress post name permalinks to work.

Before installing WordPress on a CentOS server, you need a web server, PHP, and a MySQL database with a dedicated user. Here’s the quick setup I use.

1. Install MySQL and Apache

yum install mysql
yum install mysql-server
chkconfig mysqld on
service mysqld start
sudo yum install php-gd
yum install httpd
chkconfig httpd on
service httpd start

2. Create the WordPress Database and User

Open the MySQL client and create a database, then grant a user full rights on it. Replace databasename, username, hostname, and password with your own values:

$ mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> CREATE DATABASE databasename;
Query OK, 1 row affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON databasename.* TO "username"@"hostname"
    -> IDENTIFIED BY "password";
Query OK, 0 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)

mysql> EXIT
Bye

Use these database details in wp-config.php when you install WordPress. For pretty permalinks, also enable mod_rewrite in Apache.