I read through a bunch of forum posts, and they’d say to set the index of a specific snd-driver to 0, but they never mentioned how you figured out which snd-driver you were using. So, when I finally figured it out, I decided to make a quick post!

To check which kernel driver/modules your sound is using, type:
lspci -v

Scroll down to the relevant section, for me it was:
01:06.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
Subsystem: Creative Labs CT4832 SBLive! Value
Flags: bus master, medium devsel, latency 64, IRQ 19
I/O ports at bc00 [size=32]
Capabilities: [dc] Power Management version 1
Kernel driver in use: snd_emu10k1

and:
03:00.1 Audio device: NVIDIA Corporation High Definition Audio Controller (rev a1)
Subsystem: ASUSTeK Computer Inc. Device 8334
Flags: bus master, fast devsel, latency 0, IRQ 18
Memory at fde7c000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Kernel driver in use: snd_hda_intel

So here you can see for my sounddriver, it’s using snd_emu10k1, and for my onboard nvidia card it was using snd_hda_intel. So with this in mind I put the following at the top of my /etc/modprobe.d/alsa-base.conf:
alias snd-card-0 snd-emu10k1
options snd-emu10k1 index=0

alias snd-card-1 snd_hda_intel
options snd_hda_intel index=1

Now my soundblaster card is the primary sound device. I only use my onboard sound for my headset for phone calls, etc. I loathe wearing headphones so I was getting tired of having my sound default through them.

I just had the most amazing idea while trying to figure out why this customers server was down. Typically they will look something like this:
1.2.3.4 – – [19/Feb/2014:11:57:17 -0800] “POST /wp-login.php HTTP/1.1” 200 292 “-” “-”

So I had this brilliant idea that if they are trying to brute force in this method, they likely got brute forced the same way, and why can’t I just redirect them back on themselves? I think most of these brute forces happen via IP address from someone scanning for ip addresses that have a wp-login.php. So I wrote up this redirect rule:
RewriteEngine On
RewriteCond %{THE_REQUEST} POST
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule wp-login.php http://%{REMOTE_ADDR}/wp-login.php [R,L]
RewriteCond %{THE_REQUEST} POST
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule xmlrpc.php http://%{REMOTE_ADDR}/xmlrpc.php [R,L]

This can typically just be dropped into the .htaccess, and if someone is trying to hit your wp-login.php, it will redirect them back to their own ip address and hit their own wp-login.php. Hopefully, whomevers server was compromised in the first place will go and fix their security hole instead of letting it spread further 🙂

edit — Updated to do the same thing for scumbags hitting xmlrpc.php

With the newer installs of Railo it uses mod_proxy instead of mod_jk to pass the requests to tomcat. A familiar complaint is customers can no longer use:
#cgi.remote_host#

As it returns 127.0.0.1. A different option would be to use the following:
CFSET myHeaders = GetHttpRequestData()
#myHeaders.headers[‘X-Forwarded-For’]#

That should return the IP address that was desired, and only marginally more work.

You’ll need to know the SR UUID for local storage that you’re migrating to, You can find this by running:
xe sr-list host={name of the host platform} name-label=Local\ storage params=uuid --minimal
(this is expecting a default of SR named Local storage).

You’ll also need to know the vm uuid which can be found running:
xe vm-list name-label={name of vm} params=uuid --minimal

Then you can run:
xe vm-migrate --live vm={vm uuid or name} remote-master={pool master name} remote-address={platform in pool you want to migrate to, name or uuid} remote-username=root remote-network={name of interface you want to use to transfer, I used xenbr1 because we didn't want to migrate over the management network} remote-password={root pw} destination-sr-uuid={SR uuid on platform you're migrating to}

Recently we had someone upload a malicious script onto a customer wordpress site. After tracking it down and removing it, there was still a ton of random username@customer_domain.tld mail kicking around in the queue. To remedy I stumbled upon a command that would clear out all of the email associated to that user. In my example I will use customer_domain.tld, but you’d use whatever the fqdn is.
mailq | grep customer_domain.tld | awk ‘{print $1}’ | sed -e ‘s/\*//g’ | postsuper -d –

Likely there will be a lot of returned mail as well, so to clean that out you can use:
mailq | grep MAILER-DAEMON | awk ‘{print $1}’ | sed -e ‘s/\*//g’ | postsuper -d –

The spamming had gone on for quite a while unnoticed by the customer, and it ended up running all night and removing over 1.5 million articles of spam.

*I piped it through sed to remove the asterisk because some of the mailq id’s had an asterisk in them, but if you tried to pipe that to postsuper -d it came back with a ID not found.

Originally trying to upgrade our platform servers running XenServer 5.6SP2 on a LSI 9750 3ware Raid card wasn’t working correctly, as they weren’t seeing the old data to upgrade. So what I ended up doing was loading the raid drivers before the installer ever started. Here is a brief checklist of the steps I took to successfully upgrade the servers:

Required Items:
USB CD Rom
XenServer 6.1 9750 Driver Disk (created using the DDK)
XenServer 6.1 Installation ISO (Downloaded off the XenServer Website)

9750 driver disk in usb
XenServer 6.1 Installation ISO in ipmi virtual storage
boot: shell
-(When prompted to press enter for an installation or upgrade, instead type in shell and hit enter.)
mkdir driver
mount -o loop /dev/cdrom driver
rpm -i driver/3ware-modules-*
cp /lib/modules/2.6.32*xen/extra/3w-sas.ko /lib/modules/2.6.32.*xen/kernel/drivers/scsi
insmod /lib/modules/2.6.32.*xen/kernel/drivers/scsi/3w-sas.ko
lsmod|grep 3w
-(double check the driver is actually loaded)
exit
proceed with upgrade.

Unplug the USB cdrom before the server boots back up.

I went and got the latest DDK from Citrix and imported it into the XenServer I wanted to make a driver for. On boot up you give it a password, but I also gave it an ip address so I could ssh into it (working in the console is not fun).

I went to the lsi-3ware site and got a copy of the latest code set and scp’d it over to the ddk VM. Since the DDK comes with the latest kernel, I went and checked which kernel it currently was using (2.6.32 in my case), unzipped the code set, and found the 2.6.32 .tgz file. I made a new folder in root to work in, and copied over the helloworld.spec and Makefile from /root/examples/driver/. Then I altered them to reflect the 3ware driver I wanted to make, i.e. wherever there was a reference to helloworld, I’d change it to 3w-sas. Since the driver expects the .tgz to be under /usr/src/redhat/SOURCES/ I went ahead and put it there. Running the make build-srctarballs command was supposed to unzip the .tgz file into the current directory, but because the contents of that .tgz is in a subfolder I manually unzipped it into place. Running make build-iso finished the process, and I was able to copy over the .iso to the dom0 and install the kernel module so under the new kernel we could use the 3ware card.