|IIS7: Mapping script handlers||Tuesday 31st January 2012|
There are instances when you may want to force a script handler onto a file with a different extension when web-hosting - or more usefully, with no extension at all.|
The main reason you'd want to do this is so you can have what effectively looks like a long URL of directories, when actually they're directives for a script - and save having to use all those nasty search-engine unfriendly GET ?arguments...
To do this in Apache is easy, you just add or update your ".htaccess" file to include something to the effect of:
<Files "myroot">This will make the file called "myroot" (with no extension) run in the same way as any .php file would. The last line makes it the default file for the directory.
In IIS7 you can do a similar thing, but being IIS it requires clicking about.
First open the "Handler Mappings" page, search through for your existing handler, e.g. "*.php" and edit it so you can copy the executable path.
Secondly create a new Module Mapping and add your new magic file into the Request Path box. Select the Module type as per your existing entry (probably FastCgiModule), and add in the executable path.
If you have spaces in the executable path ensure you wrap them in quotes (even though the original didn't show any quotes).
e.g. "C:\Program Files (x86)\PHP\php-cgi.exe"
Thirdly you need to go into the Default Document page and add your new file name in at the top of the list.
|Catching WCF Faults in BizTalk Orchestrations||Friday 20th January 2012|
Whether WCF is actually good or not is a debate for another day, the simple fact is with BizTalk it's replaced the SOAP adapter - and does bring some flexibility in making things loose.|
When it comes to Fault messages though it's a bit... naff. When consuming a WCF service in BizTalk you are likely to get a Fault operation with a Message Direction of Fault. But it doesn't matter what you do, there doesn't appear to be a way of attaching a receive shape to it.
Instead you have to use an Exception handler to catch the fault. The Exception type will be generated when you consumed the service, so it will be available in the Exception Object Type drop down. The SOAP Fault will still be an XML message and you treat the object as a multi-part message. It will most likely be document based so you'll either have to find the generated fault schema and promote the properties you're interested in; or use the xpath() function to pull out the data.
This is though, was only the beginning. As it's WCF you have to setup the Send Port correctly. Assuming you've already cottoned onto having to put the SOAP action into the send port instead of it working it out automatically (thank you one port for each damn action)... we now have to configure how the SOAP message is handled.
On the Messages tab we have the ability to "Propagate fault message". This essentially translates to "send fault message through to the Orchestration".
If you don't have it enabled then the adapter will throw an Exception and will suspend the Send message instance. If you're using a one-way send this might be handy if you want to resume from here. As most web-services have at least a response to confirm receipt you'll likely to already have soft-error handling in your Orchestration. HAT will record this as a transmission failure, with the fault message content as the exception.
If you enable propagation then the adapter won't view a fault as an exception, so won't suspend the message instance, and instead return it as a message to your Orchestration. This generally results in much tears as it's an unexpected message. And your nice exception handler catering for the fault completely fails to catch.
As a SOAP:Fault node is a child of SOAP:Body and not an alternative you will receive the SOAP:Fault as a root element and not the content of it. Pain in the arse. In order to avoid this you need to customise the Inbound BizTalk message body with the "Path" option. Use a Body path expression of:
/*[namespace-uri()='http://schemas.xmlsoap.org/soap/envelope/' and local-name()='Fault']/detail/* | /*[not(namespace-uri()='http://schemas.xmlsoap.org/soap/envelope/')]
This XPath will return anything that is not a SOAP component (i.e. your normal message body that you'd expect 99% of the time), OR the child of the detail node of a SOAP:Fault message.
BizTalk can now recognise the SOAP Fault and your exception handler will now catch it.
|Fixing an Ikea Lagan Single-lever mixer tap||Wednesday 18th January 2012|
My kitchen tap took a turn for the worse at the weekend and completely jammed up. With a lot of force I could get it on and then panic that I couldn't turn it off.|
A rummage under the sink put removing the tap out of the question. The thing was impossible to reach to unbolt.
This time YouTube came up trumps with a guide on how to replace cartridges in taps. Apparently most mixer taps have cartridges, generally made out of ceramic (to withstand the forces or something). And these are standard parts, you just unscrew the top, slot in a new one, and screw it back up.
Super, so Sunday I took it apart and went to B&Q, Wickes and Homebase. All looked blankly at the cartridge and had no idea what I was talking about.
Monday I trekked round three trade plumbing outlets. Only one knew what it was - but told me they're not standard and I'd have to get the manufacturer details and contact them.
Being an Ikea tap this is easier said than done, especially as I can't find a tap that looks exactly the same in the catalogue any more. I believe it's a previous incarnation of the Lagan tap, which is very close, but a few subtle differences.
Still, I was recommended Lunns as a web-site to try for spare parts if I could match it up. Five minutes with a ruler I found the part I needed Aqafix Dual-T47/190B 47mm Single Lever Cassette.
At twenty quid more expensive than the current Ikea tap I was a bit reluctant to cough up the money, but there was no way I was getting that tap off without tools or a plumber, so figured I'd cough up the extra. It arrived today and it was just a case of slotting it in and putting the tap back together.
Hope this helps somebody one day, but more likely it'll help me in five years when it breaks again.
|Extending LVM physical volumes||Tuesday 17th January 2012|
I'm considering switching from Xen Type-2 to ESXi Type-1 hypervisor for my general do anything server.|
The problem with this is, ESXi is thin on the ground when it comes to managing the host - where a Type 2 can sit on top of Linux and take advantage of all sort of useful things, such as UPS and Soft-RAID. ESXi is pretty dumb when it comes to acting as an Operating System to the host machine.
On of my reservations with this move is how to organise my files. As virtual images would be stored outside of my primary machine/guest, but my primary guest acts as my NAS and stores a lot of data on it. Putting in bigger disks is also tricky due to physical space in the box and the fact that the existing disks are already pretty huge. As a result, I need to balance up my need for spare space in ESXi's datastores for new virtual machines (which being a general server will range between 1 and however many things I'm currently tinkering with). Against having enough space in my primary guest to store the gigs of files.
I figured if I'm stingy on the space for the primary guest, I could later grow the disks when needed. Find in theory, but putting it into practice can be a little tricky. Especially when you also chuck in RAID striping.
In this example I have two physical data-stores in ESXi. Each store has one virtual drive for the guest OS (to allow striping/RAID from the guest). I also created a small 64MB drive to hold a boot partition to keep aligning things easier in my stripe.
The two main drives were filled up with a single LVM partition, and then this was jammed with logical volumes (/, /home & swap) maxing out the capacity of the virtual drives.
I then grew the virtual disks in ESXi. When I returned to Linux I used openSUSE's YaST Partitioner to view the LVM. I was unable to increase the size of my physical volume to make use of the extra space in the disk - although I could add other disks (so an alternative here is to add new virtual drives in ESXi and just tag them in). A bit of searching turned up this process:
echo 1 > /sys/block/sdb/device/rescan
echo 1 > /sys/block/sdc/device/rescan
Now I ran this without looking in too much detail whether it was required - looks harmless though! I have two drives to I ran it on both (sdb and sbc).
Then the magic is with the "pv" commands. "pvdisplay" will show you your current LVM setup, which should show your previous disk sizes for each drive.
Running the command:
This increased the size of the physical volume to the new capacity of the hard drives.
Again, the YaST partitioner bailed when trying to increase the logical volume sizes, so back to the console with:
lvresize -L+2GB /dev/base/data
This will increase the volume by 2GB (so put whatever you want in), and the volume is listed as /dev/base/data, so replace with whatever you called yours.
You will still need to resize the filesystem, I am currently using btrfs, so the command is:
btrfs filesystem resize 1:max /home
The 1: is the device id, max means fill it up, and the path is where I had the flesystem mounted to (not the btrfs path). Use btrfs filesystem show to get details.