Setting up a phpMyAdmin auto-update

Posted by on Friday, 4th May, 2012 Comments Off

Well, just like everybody else, I’ve been using phpMyAdmin to do my casual MySQL fixing/work on this website. However, recently the phpMyAdmin developers switched to Git on SourceForge and then to GitHub shortly after that.

So, the guy over at Network Jack wrote down what I had already been doing:

git clone --depth=1 git://phpmyadmin.git.sf.net/gitroot/phpmyadmin/phpmyadmin
cd phpmyadmin
git checkout --track -b PMASTABLE origin/STABLE

However, as I said before, they switched from SourceForge to GitHub, thus you need another URL.

git clone --depth=1 git://github.com/phpmyadmin/phpmyadmin.git
cd phpmyadmin
git checkout --track -b PMASTABLE origin/STABLE

After that, you just need to add a simple cronjob that enters the directory and runs git pull.

vm-online-backup – Another day, another PowerCLI script

Posted by on Monday, 30th April, 2012 Comments Off

Well, on Friday I had a short chat with someone from one of our application departments, stating he wanted a backup copy of a VM (ain’t to hard), but a) they don’t want any downtime and b) it has to be identical to the original.

So I sat down today, googled for a bit and actually found something that pretty much does what I want, though I had to fix it up a bit … So find attached a script, which creates a hot-clone from a snapshot and then only if the latest clone was successful deletes the old one.

param( [string] $vCenter )

# Add the VI-Snapin if it isn't loaded already
if ( (Get-PSSnapin -Name "VMware.VimAutomation.Core" -ErrorAction SilentlyContinue) -eq $null )
{
	Add-PSSnapin -Name "VMware.VimAutomation.Core"
}

if ( !($vCenter) ) {
	Write-Host ""
	Write-Host "vm-create-snapshot-clone: <vcenter> <VM-Name> <Target Datastore>"
	Write-Host "    <vcenter>          - Hostname of the vCenter Server instance for this script"
	Write-Host "                         to work on."
	Write-Host ""
	exit 1
}
# Based on http://www.simonlong.co.uk/blog/2010/05/05/powercli-a-simple-vm-backup-script/

# Import Backup CSV
$backupinfo =  Import-Csv C:\Scripts\TEMP\backupvms.csv
 
#Set Date format for clone names
$date = Get-Date -Format "yyyyMMdd"
 
#Set Date format for emails
$time = (Get-Date -f "HH:MM")
 
#Connect to vCenter
Connect-VIServer $vCenter
 
foreach ($customer in $backupinfo)
{
    $vm = Get-VM $customer.MasterVM
	$SCRIPTS = "C:\Scripts\TEMP\$( $customer.MasterVM ).txt"
 
    # Create new snapshot for clone
    $vm | New-Snapshot -Name "Clone Snapshot" -Description (get-date -format "'Created: 'yyyy-MM-dd HH:mm")
 
    # Get managed object view
    $vmView = $vm | Get-View
 
    # Get folder managed object reference
    $cloneFolder = $vmView.parent
 
    # Build clone specification
    $cloneSpec = new-object Vmware.Vim.VirtualMachineCloneSpec
    $cloneSpec.Snapshot = $vmView.Snapshot.CurrentSnapshot
 
    # Make linked disk specification
    $cloneSpec.Location = new-object Vmware.Vim.VirtualMachineRelocateSpec
    $cloneSpec.Location.Datastore = (Get-Datastore -Name $customer.BackupDS | Get-View).MoRef
    $cloneSpec.Location.Transform =  [Vmware.Vim.VirtualMachineRelocateTransformation]::sparse
 
    $cloneName = "$vm-$date"
 
    # Create clone
    $vmView.CloneVM( $cloneFolder, $cloneName, $cloneSpec )
	
	if (( Test-Path -Path $SCRIPTS) -ne $true ) {
		$cloneName | Out-File $SCRIPTS
	} else {
		$old_vm = Get-Content $SCRIPTS
		$cloneName | Out-File $SCRIPTS
		
		Get-VM $old_vm | Remove-VM -DeletePermanently -Confirm:$false
	}
 
    # Remove Snapshot created for clone
    Get-Snapshot -VM $vm -Name "Clone Snapshot" | Remove-Snapshot -confirm:$False
}
#Disconnect from vCenter
Disconnect-VIServer -Server $vCenter -Confirm:$false

The backupvms.csv looks pretty simple:

MasterVM,BackupDS
sles11-sp1,datastore2-nfs
sles10-sp4,datastore1-nfs

TSM and NetApp – Quick Hint

Posted by on Wednesday, 25th April, 2012 Comments Off

Well, to save everyone else the trouble (since it isn’t documented anywhere – and I just spent about an hour finding the cause for this), if you need to configure NDMP on your NetApp Filer, make sure you also configure an interface other than e0M.

Apparently the necessary controlport for NDMP (10000) is being blocked on e0M, thus ndmp may be configured and running, however TSM is gonna complain that it is unable to connect to the specified data mover.

ANR4728E Server connection to file server 172.31.76.100 failed. Please check
the attributes of the file server specified during definition of the datamover.
ANR2146E DEFINE DATAMOVER: Node NAS_DM is not registered.
ANS8001I Return code 11.

SLES11.1 and updated multipath-tools

Posted by on Saturday, 7th April, 2012 Comments Off

Well, after I scripted the installation the other day, I tried installing SLES11.1-Updates to the freshly installed systems. Guess what ? The thing broke. Initially (it was late Friday afternoon – like 6 PM – before my one week vacation) I didn’t have much time to debug the issue, so I sat down last week and looked at the issue.

During the installation, when first starting multipath via command line, the scsi-mpatha device appears, and each and every occurance of this is subsequentially being used (and other stuff replaced by this actually) during the whole installation phase.

But what is this multipath-tools update doing ? No clue what exactly, however after installing the update the system is bricked. The system is basically looking for /dev/scsi/by-id/scsi-disk-mpatha and waiting for this device to appear. But since the update robbed the device, the system is no longer starting.

So I went ahead and digged around in the /dev/disk/by-id directory. Turns out /dev/disk/by-id/scsi- is actually pointing to the right device, and thus I ended up using it. So I rewrote all my scripts (profile and chroot/post-chroot adjustments) as you can see below, and for now at least, I have a working installation that lets you install updates! (careful it gots electrolytes)

#!/bin/bash

cat << EOF > /etc/multipath.conf
defaults {
	user_friendly_names		no
	bindings_file			/etc/multipath_bindings
}

devices {
	device {
		vendor			"NETAPP"
		product			"LUN"
		getuid_callout		"/lib/udev/scsi_id -g -u --device=/dev/%n"
		features		"1 queue_if_no_path"
		hardware_handler	"1 alua"
		path_checker		tur
		path_selector		"round-robin 0"
		path_grouping_policy	group_by_prio
		failback		immediate
		rr_weight		uniform
		rr_min_io		128
		prio			alua
		max_fds			max
        }
}
EOF

sleep 1

# Disable the resume kernel
sed -e "s,resume=/dev/mapper/.*_part[0-9],noresume,g" -i \
	/etc/sysconfig/bootloader /boot/grub/menu.lst 

# Figure out the multipath ID
MD_ID="$( /sbin/multipath -l | head -n1 | cut -d\  -f1 )"

# Fix wrong root-path in /etc/fstab
sed -i "s/mapper\/.*_part/disk\/by-id\/scsi-${MD_ID}-part/" /etc/fstab

# Fix grub root-path and wrong root-partition
sed -i -e "s/mapper\/.*_part/disk\/by-id\/scsi-${MD_ID}-part/" \
	-e "s,scsi-${MD_ID}-part2,scsi-${MD_ID}-part3," /boot/grub/menu.lst

# Fix the device.map
echo -e "(hd0)\t/dev/disk/by-id/scsi-${MD_ID}" > /boot/grub/device.map

sleep 1
mkinitrd -f multipath

Now what’s left to do for tomorrow is “fixing” the already (previous to those changes) installed systems, so we can install security updates on those too!

VMware Update Manager issues

Posted by on Saturday, 31st March, 2012 Comments Off

Well, I recently (last Wednesday) had a lot of trouble with Update Manager.

First I thought, upgrading vCenter and modules to 5.0U1 would solve my troubles, however it did not. Update Manager was still complaining about something. Since neither in the vCenter Update Manager nor the vCenter log itself were having any useful information I enabled SSHd and the ESXi Shell via the vCenter client:

SSH’ed into the ESX host and looked at /var/log/esxupdate.log, and found this particular log:

2012-03-28T16:18:26Z esxupdate: HostImage: INFO: Attempting to download VIB vmware-fdm
2012-03-28T16:18:26Z esxupdate: esxupdate: ERROR: An esxupdate error exception was caught:
2012-03-28T16:18:26Z esxupdate: esxupdate: ERROR: Traceback (most recent call last):
2012-03-28T16:18:26Z esxupdate: esxupdate: ERROR:   File "/usr/sbin/esxupdate", line 216, in main
2012-03-28T16:18:26Z esxupdate: esxupdate: ERROR:     cmd.Run()
2012-03-28T16:18:26Z esxupdate: esxupdate: ERROR:   File "/build/mts/release/bora-515841/bora/build/esx/release/python-2.6-lib-zip-stage/515841/visor/pylib/python2.6/site-packages/vmware/esx5update/Cmdline.py", line 144, in Run
2012-03-28T16:18:26Z esxupdate: esxupdate: ERROR:   File "/build/mts/release/bora-515841/bora/build/esx/release/python-2.6-lib-zip-stage/515841/visor/pylib/python2.6/site-packages/vmware/esximage/Transaction.py", line 243, in InstallVibsFromSources
2012-03-28T16:18:26Z esxupdate: esxupdate: ERROR:   File "/build/mts/release/bora-515841/bora/build/esx/release/python-2.6-lib-zip-stage/515841/visor/pylib/python2.6/site-packages/vmware/esximage/Transaction.py", line 345, in _installVibs
2012-03-28T16:18:26Z esxupdate: esxupdate: ERROR:   File "/build/mts/release/bora-515841/bora/build/esx/release/python-2.6-lib-zip-stage/515841/visor/pylib/python2.6/site-packages/vmware/esximage/Transaction.py", line 388, in _validateAndInstallProfile
2012-03-28T16:18:26Z esxupdate: esxupdate: ERROR:   File "/build/mts/release/bora-515841/bora/build/esx/release/python-2.6-lib-zip-stage/515841/visor/pylib/python2.6/site-packages/vmware/esximage/HostImage.py", line 630, in Stage
2012-03-28T16:18:26Z esxupdate: esxupdate: ERROR:   File "/build/mts/release/bora-515841/bora/build/esx/release/python-2.6-lib-zip-stage/515841/visor/pylib/python2.6/site-packages/vmware/esximage/HostImage.py", line 414, in _download_and_stage
2012-03-28T16:18:26Z esxupdate: esxupdate: ERROR: VibDownloadError: (<vmware.esximage.Vib.ArFileVib object at 0x86c79ac>, 'Unable to download VIB from any of the URLs ')
2012-03-28T16:18:26Z esxupdate: esxupdate: DEBUG: <<<

As you can see from the above log, for whatever reason, the Update Manager is trying to install an updated version of the VMware HA agent (vmware-fdm). Now, since that isn’t the job of Update Manager (afaik, vCenter handles that separately), I figured what the hell, let’s try and remove it as the ESX host was already in Maintainance Mode:

esxcli software vib remove -n=vmware-fdm

And guess what: after removing the package and then rerunning the Remediate task on the host, my troubles were gone.