I'm currently working on a rapidly redeployable Gentoo-based virtual machine for service monitoring, statistics graphing and trending and centralized log file collection and analysis. So far it's just a pretty menu and a collection of third party apps but before I release it I intend on drawing them together through single-sign on. Access is provided over VPN and SSL only.
Xen users frequently deal with raw file system image files. While this isn't the ideal method for managing virtual machine storage it is the format of choice for redistribution. This article is a simple cheat sheet that will help you deal with sparse and regular image files.
To create a blank image file run:
dd if=/dev/zero bs=1M count=X > image.img
Where X is the size of the file in MB.
To enlarge an image file run:
dd if=/dev/zero bs=1M count=X >> image.img
Where X is the amount of space you want to add in MB.
To create a sparse file run:
dd if=/dev/zero of=image.img seek=X bs=1M count=0
Where X is the size of the image in MB.
ℹImportant! Sparse files are a nuanced topic. Please read this article as well if you intend to use them: Everything You Never Wanted to But Absolutely Have to Know About Sparse Files
To enlarge a sparse file run:
dd if=/dev/zero of=image.img seek=X bs=1M count=0
Where seek=X should be the current size of the sparse file plus the amount of space you wish to grow the image by in MB.
To enlarge an ext2 or ext3 file system to fill an expanded disk image run:
e2fsck -f image.img
e2resizefs image.img
e2fsck -f image.img
To create an ext2 file system on an image file run:
mke2fs image.img
To create an ext3 file system on an image file run:
mke2fs -j image.img
I often find that mke2fs' defaults for file systems between 2 and 6 gigs are not efficient for full linux installs, make sure you have enough inodes and to really save on space reduce the block size to 1KB. Optionally you can force the defaults for a "small" file system by using the -T flag:
mke2fs -j -T small image.img
This helps clip off a lot of the wasted space created by the (Gentoo in particular but any given flavour's) large number of small files.
To make a reiserfs file system run:
mkreiserfs image.img
Note that reiser's ability to incorporate files smaller than the block size into its B-* tree probably makes assigning a smaller (than 4096B) block size more costly than it's worth.
To expand a reiserfs file system to fill the available space in an image file run
resize_reiserfs image.img
To make an XFS file system run:
mkfs.xfs image.img
XFS caches heavily making it on one hand a decent file-based image performer at the cost of being slightly more fragile than other solutions. Another bonus is it is designed to scale up easily, however I tend to only use XFS as the "mother" FS on battery-backed hardware RAID setups and use ext3 for VM images due to its comparative resilience and the higher level of crash vulnerability virtual machines have over their host counterparts.
To expand an XFS file system to use all available space on a partition image run:
mount -o loop image.img /mnt/image
xfs_growfs /mnt/image
To mount an image file run
mount -o loop image.img /mnt/image
Remember not to perform any operations (like DD) on an image file while it is mounted.
To chroot into an image file with a working linux installation after mounting run:
mount -o bind /dev /mnt/image/dev
mount -t proc none /mnt/image/proc
chroot /mnt/image /bin/bash
Include /bin/bash where the default shell might be less permissive, i.e. standard sh or leave it off if the type of shell is unimportant.
To copy a file system's contents verbatim to another file system mount both then run:
cp -ax /mnt/image1/* /mnt/image2/
You should do this to a freshly created sparse or regular file to increase the effectiveness of compression when redistributing an image. In a regular file, the empty space that would otherwise be completely zeroed out instead contains remnants of deleted files.
I just bought my first cellphone in years. I know that sounds strange coming from an IT guy but my logic is sound: if you don't have one your boss can't call it. One of my colleagues is a big VoIP genius and he pointed out that by using a dial-out gateway and Telus' one-number-unlimited feature it's possible to have the equivalent of unlimited calling for $7 per month on a prepaid phone - plus the one-time cost of provisioning a phone number that forwards incoming calls back through the gateway (about $25). I've been horny for the newer android-based phones that are in circulation in the states but most of the ones I want don't operate on the Canadian bands yet and/or it will take a long time before they are rolled out up here, thus I decided for unlimited calling at $7 a month I may as well settle for a cheap phone in the mean time. I decided to tack on $10/month unlimited web browsing because it makes the e-mail and instant messaging packages moot.
The Keybo 2 is the closest thing to a smart phone in Telus' prepaid lineup, and at the time of writing the most expensive - clocking in at a modest $99. It sports a 160x96px external screen and flips open to reveal a large QWERTY keyboard and 320x240px internal screen. There are stereo speakers mounted on either side of the internal screen and to be perfectly frank they are better sounding than my laptop's. The Keybo 2 has a 3.2MP flash camera that takes decent pictures but crappy closeups.
In the United States (and possibly elsewhere) the Keybo 2 is marketed as the enV3. The Canadian model number is CX9200 and the US model is VX9200; as far as I can tell the difference is cosmetic. Verizon seems to be the main carrier for enVs in the states and Koodo is popular in Canada as well. Interestingly the Koodo and Verizon firmwares of the phone do not include Java support. It would seem that the popular thing to do with your Keybo is flash it to Telus' firmware if you're on a different provider. Unfortunately Telus' firmware is so locked down that one wonders just how bad Verizon's could be.
I've had a hell of a time over the past few days trying to find information on hacking the Keybo 2, most of the results I have found thus far only apply to the original Keybo (aka enV2 or VX9100), for example it no longer seems possible to simply overwrite application slots with other java apps to install them on the phone. Telus' proxy prevents users from downloading apps from the web that don't come from their store. I have tried altering the proxy settings to use a personal proxy on ports 8118, 80 and 110 but the browser fails to connect. I even tried popping the opera mini .jad and .jar files onto an SSL site and altering the .jad to pull from the new URL to no avail - the download begins, posts, then returns this error:
Issue has been reported. Please try again later. 950 Server Error (-1289)
then the browser bounces back to the Telus apps store. I tried renaming the .jar to .jax (and updating the .jad accordingly) also to no avail. I am beginning to suspect that the firmware has been modified to enforce some sort of DRM for applications. Custom ringtones are a pain in the ass as they definitely require DRM, fortunately they can be dropped into the phone's filesystem at /brew/shared/ringtone/ with BitPim (1.0.7+ supports the CX9200) and given DRM with the Sony-Ericsson DRM Packager.
I couldn't find the right SPC code for my particular phone anywhere (unlike the old Keybo/enV2 it does not have nvm_XXXX files) so I had to grab it with CDMA Workshop (it's 105495 by the way). With the correct SPC you can access the programming menus for your phone by dialing:
##DEBUG ##TELUS ##BROWSER ##TEST ##DATA
Note that you can get into ##DEBUG on any LG phone with the unlock code 183729.
Overall, this phone pisses me off because it could do so much more but Telus makes it extremely difficult to modify. While there is some community support for the Keybo/enV2 those of us with the new Keybo 2s and enV3s are practically on our own at present time. The fact that the Telus firmware is considered "the good firmware" is extremely discouraging, flashing your old Verizon enV2 to Telus' old Keybo firmware may let you load on some java apps but how to do this successfully on the newer Keybo 2's firmware is as yet a mystery.
Once your hosting clients are all settled in you may find one day that you need to change their MySQL server address or other configuration parameters. Naturally it's not going to look good on you or be a very good use of your time to contact every webmaster and have them update their settings. Worse, juggling two active database servers would be a nightmare. Fortunately Oracle came up with mysql-proxy, a lightweight app that sits between your clients and MySQL server(s) which acts as a drop-in replacement for mysqld. Users connect to the proxy like they would the actual server and it transports data to and fro. You can do all sorts of neat things to the data while it's in motion with lua scripts but that goes beyond the focus of this article.
By default mysql-proxy listens on port tcp/4040 and mysqld listens on tcp/3306. In my experience most users who come from other ISPs are already wired to use localhost as their default SQL host and I don't want to make them have to remember the port number, which is typically defaulted in most webapps. If you're running mysqld on the same host you're serving web from you'll need to change the port it listens on in /etc/mysql/my.cnf.
MySQL has a contentious age-old convention of changing "localhost" to "use the local socket" rather than resolving localhost to 127.0.0.1 and connecting via TCP. That's because at the time the decision was made local sockets were far more efficient than using TCP, now it's not so much an issue. We need to configure mysql-proxy to listen to a socket too or our users will have to use the numeric address, lest they encounter this error:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
This can be specified - not all too intuitively - by replacing the proxy-address value in /etc/mysql/mysql-proxy.cnf with the default path to the local socket, thus:
proxy-address = /var/run/mysqld/mysqld.sock
Configure the proxy-backend-address variable to reflect the actual server's location and port number. Restart mysql-proxy and you now have a working, default-looking configuration that can be redirected anywhere. Thanks to the lua capability of the proxy you can even implement fast and easy load balancing and failover, but that will be the topic of another article!
Yesterday I posted an article regarding the importance of ACLs in BIND because a client's DNS server was under extreme load and, at the time, I believed it was because a network of web form spammers was outsourcing their lookups to the target. Upon further investigation it turned out that this was not the case - the hosts were indeed a part of some sort of spamming ring/botnet but they were actually performing endless repeated ANY lookups on isc.org - the producers of BIND, among other things.
The whole attack doesn't make any sense; if they wanted to involve this server in the attack against isc they would be wasting reams of bandwidth that could otherwise have been applied directly, unless they knew both recursive lookups were allowed and caching was disabled. Even with no recursive ACL at the time the only server suffering was my client's thanks to caching and there is no conceivable reason, in my mind, that a spam network would be targeting this specific dns server among many in its address space - from one source address at a time. Fortunately adding a recursive ACL reduced the bandwidth impact but it did not stop the scans, and bandwidth is a pricey commodity after all.
I whipped out wireshark and took a sample capture, these are the contents of a typical request packet:
0000Â 00 16 3e bb 00 02 00 16Â 3e cc 00 02 08 00 45 00Â Â ..>..... >.....E.
0010Â 00 40 8b 0d 00 00 e9 11Â d7 93 d1 0b f2 7b 00 00Â Â .@...... .....{..
0020 00 00 63 01 00 35 00 2c 00 00 2a 39 01 00 00 01  ..c..5., ..*9....
0030Â 00 00 00 00 00 01 03 69Â 73 63 03 6f 72 67 00 00Â Â .......i sc.org..
0040Â ff 00 01 00 00 29 10 00Â 00 00 80 00 00 00Â Â Â Â Â Â Â Â .....).. ......
Next it was just a matter of crafting a suitable snort rule for the upstream gateway:
alert udp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"DNS isc.org DDoS"; content:"|03 69 73 63 03 6f 72 67 00|"; reference:foxpa.ws,369; classtype:attempted-dos; sid:4000002; rev:1; fwsam: src, 1 day;)
Now I'm kicking back, watching the spammer network expose itself as its constituent hosts smack against the firewall like bugs against a windshield.
If only I had some beer.