Category: IT

While you can just create a pv out of raw block device I normally try to avoid it as it can cause confusion as to what the block device is being used for. It may also break some of the auto discover routines that LVM can use if it’s missing it’s configuration files.

Here’s an example of using parted to create a GPT with 1 partition that is the whole drive and set the partition flag to be lvm. The mkpart requires that you specify a file system but it doesn’t create the file system. Seems to be a long standing bug in parted. Also the start offset of 1M is to ensure that you get proper alignment.

parted /dev/sdb
mklabel GPT
mkpart primary ext2 1M 100%
set 1 lvm on
quit
pvcreate /dev/sdb1
pvdisplay
vgcreate vg_*name* /dev/sdb1 /dev/sdc1 /dev/sdd1
vgdisplay
lvcreate –extents 100%FREE -n lv_*name* vg_*name*
lvdisplay
mkfs.xfs -f /dev/mapper/vg_*name*-lv_*name*
df -ah

yum shell
remove sysklogd
install rsyslog
run
exit

vi /etc/rsyslog.conf
paste in the below:
# ### 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 ###

chkconfig rsyslog on
service rsyslog restart

So we were having this weird latency issue with our new R815’s and the Broadcomm nics utilizing iSCSI on a segregated lan.

Turns out we needed the BCM-NetXtremeII-5.0-offline_bundle-940344.zip driver imported into update manager, a reboot later, we were all happy!

This explains how to add a cron job to VMware in such a way that it will still be there after reboots.

Having enabled ssh access to your ESX/ESXi server, ssh in as root.

First, add the cron job to the root crontab:

1. Edit /var/spool/cron/crontabs/root
2. Add the line (all on one line)
5 0 * * * /full/path/to/script arguments/with/full/path > /full/path/to/logfile 2>&1
3. When you quit, use Esc, :wq! to override the read only attribute.

For details of the meaning of “5 0 * * *” (5 minutes past midnight every day) read the man page for crontab(5) on any Unix/Linux server, or else on the web.

Now, add a command to /etc/rc.local to re-generate the cron job when ESX/ESXi reboots

1. Edit /etc/rc.local, using a command such as “vi /etc/rc.local”.
2. At the end of the file, add 3 lines (using “G” then “O” in vi). The first kills crond, the second adds the new cron job to the root crontab file, ad the third restarts crond:
/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
3. Save and exit the editor (Press the “Esc” key then “:wq” then press “Return” in vi)
4. Run the command “auto-backup.sh” so that the change to /etc/rc.local survives a reboot.

Every time you change the cron job, remember to update /etc/rc.local as well and run the “auto-backup.sh” command to backup the new /etc/rc.local file.

Open the Apache configuration file located at /etc/httpd/conf/httpd.conf
Change AllowOverride None to AllowOverride All inside the DocumentRoot Directory Directive, normally
This is very important for wordpress post name permalinks!!!

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

Create Database:

mysql

Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 5340 to server version: 3.23.54

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
$

# ### 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
*.* @@splunk:514

Logical Volume Management (AKA LVM) is for managing storage space.
In Centos, instead of installing the root filesystem directly to a fixed size partition, we setup LVM by default, and install the root filesystem to a Logical Volume, which may later be expanded, even across multiple physical devices.

How LVM works
In LVM, there are several layers, each builds on top of the other:

PV[s] (Physical Volumes) -> VG[s] (Volume Groups) -> LV[s] (Logical Volumes) -> Filesystems.

Logical Volumes are allocated/extended within the boundaries of their underlying storage pool which is called a Volume Group in LVM terminology.

For example, in Centos the filesystem is installed by default to the /dev/vg_prd00/lv_root Logical Volume, which is allocated within the vg_prd00 Volume Group:

— Logical volume —
LV Name /dev/vg_prd00/lv_root
VG Name vg_prd00
LV UUID —-uuid—-
LV Write Access read/write
LV Status available
# open 1
LV Size 50 GiB
Current LE 12800
Segments 1
Allocation inherit
Read ahead sectors auto
– currently set to 256
Block device 253:0
Out of the box the vg_prd00 Volume Group might not have enough free space for you:

# vgdisplay
— Volume group —
VG Name vg_prd00
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 3
Max PV 0
Cur PV 1
Act PV 1
VG Size 63.51 GiB
PE Size 4.00 MiB
Total PE 16258
Alloc PE / Size 16258 / 63.51 GiB
Free PE / Size 0 /0
VG UUID —-uuid—-
We can only extend a Logical Volume within the free space of the underlying Volume Group. How much free space we currently have within the Volume Group can be seen in this part of the output:

Free PE / Size 165 / 660.00 MiB
In the above example we only have 660 MB to allocate to LVMs within the vg_prd00 Volume Group. So if we want to extend the root LV we’ll have to first extend the VG backs it up.

Volume Groups group together Physical Volumes. That’s why they’re called Volume Groups. This command will show us which Physical Volumes have been registered into LVM, and to which volume groups they have been assigned:

# pvdisplay
— Physical volume —
PV Name /dev/sda2
VG Name vg_prd00
PV Size 18.15 GiB / not usable 4.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 4645
Free PE 165
Allocated PE 4480
PV UUID —-uuid—-
In this example we only have one Physical Volume (the /dev/sda2 partition) in the turnkey Volume Group.

Extending a Logical Volume
Bottom line: if the underlying Volume Group doesn’t have enough free space, to extend the Logical Volumeyou’ll first have to extend the underlying Volume Group by adding another Physical Volume to it.

In VMWare you could either create a new virtual hard disk device to add to the volume group, or extend an existing virtual hard disk device, create a new partition with cfdisk, and add the new partition to the Volume Group:

# example #1: you’ve added to VMWare a new virtual hard disk called /dev/sdb
pvcreate /dev/sdb
vgextend vg_prd00 /dev/sdb

# example #2: you’ve expanded the existing sda hard disk
cfdisk /dev/sda # creating /dev/sda3 (you need to reboot before you can see this)
pvcreate /dev/sda3
vgextend vg_prd00 /dev/sda3
After you’ve extended the Volume Group, you are free to extend the underlying Logical Volume:

# lvextend -L+10G /dev/vg_prd00/root
Extending logical volume root to XXXX GiB
Logical volume root successfully resized
Finally, you’ll have to resize the filesystem within /dev/turnkey/root so it can see that the underlying block device just got 10G bigger:

# resize2fs /dev/vg_prd00/root
resize2fs 1.41.11 (14-Mar-2010)
Filesystem at /dev/vg_prd00/root is mounted on /; on-line resizing required
old desc_blocks = 2, new_desc_blocks = 2
Performing an on-line resize of /dev/vg_prd00/root to XXXX (4k) blocks.
The filesystem on /dev/vg_prd00/root is now XXXX blocks longer.

or
#xfs_growfs /dev/vg_*name*/lv_*name*