I heard about WebHostingTalk’s security breach recently and after reading the comments on Slashdot, I became a bit concerned people were missing the issue. People discussed offsite backups and offline backups, but while that might have mitigated the issue, its not what’s at fault.
What’s at fault is the fact that their database servers could be connected to from their backup servers. Backup servers should only be able to be connected to from the boxes they’re backing up data from. You should send your data there, not download your your data to the backup server.
My sss/rsync scripts run from the box I’m backing up and that box has no way to connect back to the box I’m backing up from. If that’s the way WebHostingTalk’s servers were set up, there would be no hack. Yes, they might have been able to delete the backups, but not be able to connect to the database servers and wipe the tables on them.
Ryan Networking backup, database, hack, server, webhostingtalk
I recently had to reboot a machine following a kernel upgrade and was getting the “ATA: Slow to respond” error. Googling the error message left me with nothing but the fact it was a kernel issue. I made some changes and rebooted the machine to the previous kernel version. Before I even got that far, I noticed BIOS was hanging when detecting the drives.
Great, I have a bad hard drive. Luckilly they were mirrored, which was why the system still booted. I decided to power it down and just double check the all the cables. When I booted it up again, it detected the drive fine and the system booted without an issue. The system is running fine now and I haven’t determined it the drive is going bad, the cable is bad, or the SATA port on the motherboard is going bad.
Either way, if you start getting random “ATA: Slow to respond” errors, check the cables and check BIOS to make sure the drive is even recognized.
Ryan linux hardware, linux, server
Currently, when I create a new Xen DomU, I have to create a new logical volume, edit a configuration template, install the OS, and finally modify the configuration file to its final post-install parameters. This is a time-consuming process that should be avoided if at all possible, yet I have not been able to find tools to do so.
I came across xen-tools, but its mainly for Debian based systems. It does have some tools to assist in deploying rpm based systems, but they appear to be clunky. The required rinse tool basically downloads packages twice to do the install. Why?
There is also the Red Hat provided Virtual Machine Manager which is GUI based. I like to stick to command line, but that’s OK since they have a tool called virt-install that will either prompt you for information or will accept arguments to configure the new DomU. The issue here is that virt-install creates the sxp file in /var/lib/xend/domains/(hex number)/ making it impossible to restart the machine after it has been started, as well as place a copy in the /etc/xen/auto folder for automatic startup at boot. However, there is a tool to parse the sxp formatted configuration file, back to the normal format… but its an extra step. Why can’t it just use the simple configuration file format from the start?
All I want is a simple tool that I can throw a few arguments at such as hostname and ip addreess to pass to kickstart, something I can have create the LVM partitions for me, and something that will properly output the configuration file to /etc/xen. Why is this so hard and why has this not been done yet?
Ryan xen linux, server, virtualization, xen
This morning somebody posted on the Plesk Support Forums that they had a fix for the Mailman issues in Plesk 9.0. They suggested symlinking the mm_wrapper file to the location it should be. On my server, Plesk had a mm_wrapper file at
/usr/lib/plesk-9.0/mm_wrapper
To put it in the correct place run:
cd \var\qmail\bin
ln -s /usr/lib/plesk-9.0/mm_wrapper mm_wrapper
So far, the test emails are going through and being sent back via Mailman with no errors.
Ryan Plesk linux, mailman, Plesk, server
For those of you out there that use Plesk and Mailman, if you have not yet upgraded to 9.0, hold off. Once I upgraded to 9.0, Mailman stopped working. Any email sent to the lists return with this error:
Hi. This is the qmail-send program at xxxxxxxxxx.com.
I’m afraid I wasn’t able to deliver your message to the following addresses.
This is a permanent error; I’ve given up. Sorry it didn’t work out.
<xxxx-xxx@xxxxxxx.org>:
preline: fatal: unable to run /var/qmail/bin/mm_wrapper: file does not exist
This has been noted on the Parallels Plesk forums and a few tickets have been opened with Parallels, but no response so far. This seems to be the same treatment we get every time Plesk is upgraded. Parallels breaks things and then expects you to pay for them to be fixed. Its a horrible business model and a lose-lose for Parallels customers.
Ryan Plesk linux, mailman, Plesk, server
