H Jarvis – Support Software Case Study – dotUK
Originally From H Jarvis – Support Software Case Study – dotUK
Andy Flisher is a Software Developer based in the North East of England specialising in cross platform development. Mobile Development experience includes Windows Phone, Android, and iPhone Apps. Desktop Software Development includes bespoke Windows, Linux, and Mac Applications. Web Development Skills include PHP, Perl, Python, ASP (Classic and .NET) – Andy Flisher on Google+
H Jarvis, a North East and Marske based Quality Windows and Doors manufacturer head a need to improve upon existing quality control and customer support processes, increase efficiencies in service engineer response, and to allow end users to self service their own support cases
- Client H Jarvis – North East based window fabricator
- Platforms Web, Web Services, Outlook Calendar Sync
- Technologies PHP, CSS, JQuery, Javascript, MySQL, REST API, iCal / Webcal, JSON
H Jarvis are a multi site company with bases of operation in Marske (North East England) and Blantyre (Scotland), and had an existing interconnected IT infrastructure linking the two sites. With that in mind it made sense to build a Web Based Software Solution, in this case utilising dotUK’s own bespoke web services framework.
his framework, built for purpose, is built upon a PHP, MySQL REST based API framework that allows seamless, consistent, and secure data exchange from the hosted API hub and the end client’s browser. Again utilising PHP and JQuery in the web client we were able to offer an improved experience to the end user, without the traditional stop, start, or click and wait frustrations of traditional web software.
Functionality wise have built a central support system for all sites which registers and manages all currently active customer support cases, with SLA support and comprehensive management reporting. In addition to case reporting the system also offers manufacturing build orders for remedial work and iCal calendar synchronisation with Outlook.
Fitter appointments are booked by the agents on an informed intelligence basis to minimise unwanted travel time by allocating cases to geographic zones and forward looking appointments to ensure that fitters are booked in when next in the appropriate locale. This appointment picking process also includes real time estimates of travel time so the most informed appointment booking decision can be made.
End use wise the system also includes a web based portal for key clients to view and manage their support cases, including any updates, notes or case changes. This allows end users real time access to updates when they need it, yet at the same time freeing Agent staff from fielding update enquires directly .
The solution is built upon dotUK’s managed web services platform hosted in the North East which allows for scalable database clustering, high availability, and includes 24/7 monitoring and management, and full data backups to an offsite datacentre
The iPhone App for Zenoss – That’d be KyK
The iPhone App for Zenoss – That’d be KyK then
Andy Flisher is a Software Developer based in the North East of England specialising in cross platform development. Mobile Development experience includes Windows Phone, Android, and iPhone Apps. Desktop Software Development includes bespoke Windows, Linux, and Mac Applications. Web Development Skills include PHP, Perl, Python, ASP (Classic and .NET) – Andy Flisher on Google+
Kyk - The iPhone App for Zenoss
Zenoss is a monitoring system, we use it the office, and basically it sits on one of our servers out in the Cloud (the Internet to most people) and regularly monitors our kit, servers, and our clients kit too, to make sure they’re still up and doing what they should. If something disappears, a disk gets full, or a server overloaded it alerts our Engineering team and we swoop into action. When there’s an alert it keeps on alerting until you respond and acknowledge it – that’s where KyK comes in.
KyK?- It’s from the Afrikaans for ‘Watching’ – which is the easiest way to explain what Zenoss does.
Yes, yes, very clever – but what is it? Well, it’s an iPhone App, an iPhone client for Zenoss if you will, although not just iPhone, it will work on any handheld iOS device, so that’s the iPod Touch and the iPad – Oh, and I wrote it, I’m an App Developer too you know, so that’s Web Based Software, Desktop Software, and Mobile Software – clever me 
Back to the top, when there’s an alert in Zenoss you have to get on line, login, see the agent and acknowledge it. Alerts don’t happen at convenient times, so KyK is aimed at making it easier. Fire up the App, it automatically polls your Zenoss server and lists any events. New events are highlighted at the top, tap, confirm, acknowledged – that simple, convenient, mobile. You can also view more detail and alert history for events too if you want.
What’s next? Well KyK (and KyK Lite – a free version that lets you see events but not acknowledge them) is out there now in the Apple iOS App Store, there’s a version for Android in Beta (that basically means half done and in testing) and it may expand beyond that, I have half an idea for an enhanced iPad / Tablet version with a lot more management features, but we’ll have to canvas demand to justify developing that.
How’s KyK doing, setting the Zenoss Community on fire? Not yet, but it’s only been out for a few weeks, we have customers in Mexico, Canada, the US, South Africa, and of course the UK – it’s interesting being global – but also a challenge. I deliberately wrote a support / feedback mechanism into the app so users can contact us as easily as possible, it’ll also send me useful debug logs so I can understand what has and hasn’t happened, so that makes life easier, but of course we have timezones and languages to deal with, thankfully most people internationally speak better English than we do. Today I’ve released version 1.1 which fixes a couple of minor bugs and user interface anomalies, and massively adds support for Zenoss 4 and above (Annoyingly Zenoss 4 came out of Beta whilst KyK was in the worlds longest App Review, so we had no opportunity to test and ensure compatibility before release), and have a few features to add for the next release. The big milestone will be 1.2 when it’ll go live for Android too, just need a Tardis and a few round-too-it’s and we’ll be there.
Bigger plans, commercially, we’d like to talk to Zenoss themselves, or their clients, KyK is written in such a way that it could easily be re-branded, or custom re-written as an Enterprise App to be deployed large scale – but that sounds a lot like Marketing, which is for another day and the right frame of mind, step 1 (and 1.1) complete.
In the meantime if you use Zenoss, or know someone that does, and have an iPhone in your hands, buy KyK for Zenoss on the iPhone, leave a nice review (if you can), and make me smile, thus justifying a lot of long hours and thought!
Andy works for dotUK (www.dotuk.net) a North Based Web and Software Development firm he helped found.
BTServer causing high CPU utilization (When wake from Sleep)
Symptoms are that your Mac wakes from sleep and CPU usage spikes to 100%, Activity Monitor show’s it the BTServer process using it all and you have to quit it. This happens, 100% reproducible, when you’ve used the iOS Simulator at some point since the last reboot.
This isn’t a perfect solution, in fact it’s ruddy useless of the iPhone / iPad app you’re developing uses Bluetooth, but if it doesn’t then you can get away without BTServer, so we disable it.
Thanks to ‘Frankie’ via the Apple Support Forums
Re: BTServer causing high CPU utilization
Mar 4, 2012 5:51 AM (in response to Ryan Homer)
I have the same issue. My mac is 10.6.8 and I’m using XCode 4.2.
Just try:
Go to the Macintosh HD > Developer > Platforms > iPhoneSimulator.platform > Developer > SDKs > iPhoneSimulator5.0.sdk > System > Library > LaunchDaemons directory and then open the plist file from there. Locate the “Disabled” key and change its value from “NO” to “YES”.
You need to change permission in the file and also its parent folder in order to save the new permission of plist file before modifying in XCode.
Hope this help.
Frankie
via BTServer causing high CPU utilization: Apple Support Communities.
Andy Flisher is a Software Developer based in the North East of England specialising in cross platform development. Mobile Development experience includes Windows Phone, Android, and iPhone Apps. Desktop Software Development includes bespoke Windows, Linux, and Mac Applications. Web Development Skills include PHP, Perl, Python, ASP (Classic and .NET) – Andy Flisher on Google+
Convert a Version 7 vmdk Disk to Version 4
This post is to highlight how you can convert a Version 7 vmdk disk to version 4. Basically the background is that since Vsphere 4.0 the default Virtual Machine Hardware Version is version 7, under Esx or Esxi 3.5 it was virual machine version 5 (I think versions 5 and 6 are under VMWare workstation), so if you have any need to take a virtual machine from 4.0 / 4.1 / 5.0 etc backwards to a 3.5 host you’re (by default), knackered.
The easiest solution by the way is to use VMware convert, point at source and destination and it will sort it out, but sometimes this isn’t an option. In my case I had the vmdk file (the small 1kb descriptor file and the 20GB *-flat.vmdk disk image it references), and nothing else. Except that I knew my source was a version 7 vmware disk image. I had copied the vmdk image files to the esxi 3.5 host but on creating a new virtual machine it basically pretended it couldn’t see the disk image, browsing the datastore to add the virtual disk showed nothing, no clue it even existed. As always, this is what I did, take a backup first, your fault if you screw it up, etc, etc.
Using vi, or any other text editor, open up the vmdk file (the small one, *NOT* the big one), eg in my case I had;
/vmfs/volumes/49b13e24-6619f880-49fd-00151798cc79/Linuxx64 # ls -hlat
-rw------- 1 root root 20.0G Jan 9 16:11 Linux x64 Clone-flat.vmdk
-rw------- 1 root root 486 Jan 9 16:09 Linux x64 Clone.vmdk
drwxr-xr-t 1 root root 2.9k Jan 9 15:58 ..
drwxr-xr-x 1 root root 560 Jan 9 15:45 .
/vmfs/volumes/49b13e24-6619f880-49fd-00151798cc79/Linuxx64 #
It’s the highlighted orange one we want, the *-flat.vmsk is the actual disk image data. Once opened you will have something like;
# Disk DescriptorFile version=3 CID=7d8e12e8 parentCID=ffffffff createType="vmfs" # Extent description RW 524288000 VMFS "Linux x64 Clone-flat.vmdk" # The Disk Data Base #DDB ddb.toolsVersion = "7458" ddb.adapterType = "lsilogic" ddb.geometry.sectors = "63" ddb.geometry.heads = "255" ddb.geometry.cylinders = "32635" ddb.uuid = "60 00 C2 93 7a c9 31 2b-8d 11 61 d1 30 66 5c 41" ddb.virtualHWVersion = "7"
Note the highlighted values simply change to;
# Disk DescriptorFile version=1 CID=7d8e12e8 parentCID=ffffffff createType="vmfs" # Extent description RW 524288000 VMFS "Linux x64 Clone-flat.vmdk" # The Disk Data Base #DDB ddb.toolsVersion = "7458" ddb.adapterType = "lsilogic" ddb.geometry.sectors = "63" ddb.geometry.heads = "255" ddb.geometry.cylinders = "32635" ddb.uuid = "60 00 C2 93 7a c9 31 2b-8d 11 61 d1 30 66 5c 41" ddb.virtualHWVersion = "4"
That simple, honest, edit in a text file and you’d done. If you try and and this to Virtual Machine under Esx or Esxi 3.5 it will now see the vmdk and work just fine, in my case at least
Andy Flisher is a Software Developer based in the North East of England specialising in cross platform development. Mobile Development experience includes Windows Phone, Android, and iPhone Apps. Desktop Software Development includes bespoke Windows, Linux, and Mac Applications. Web Development Skills include PHP, Perl, Python, ASP (Classic and .NET) – Andy Flisher on Google+
Buffalo Terastation Raid Recovery (PPC) under Linux (i386)
Buffalo Terastation Raid Recovery (PPC) under Linux (i386)
First off, a caveat, the data I had on my Terastation was not life or death, if this had failed the world would not have ended, in fact this had sat for 6 months un-attempted, that’s how un-important it was. Getting the data back was a ‘nice to have’, so this is not a safe or guaranteed process. If in doubt investigate using dd to backup partitions before atttempting – Don’t blame me! – But in essence Buffalo Terastation raid recovery is possible using an i386 generation donor box.
So, history, I had a Buffalo Terastation (model TS-1.0GL/R5) which is a Power PC (PPC) based NAS, fitted with 4x 250GB Western Digital drives. It went Pop 
In my case it was configured to use all the drives as one large pot, although that’s not really important, underlying I knew it was basically software raid (mdraid) and the XFS file system.
First attempt was using a Centos 6 (32bit) box I had to hand, guess what, no XFS support under 32 bit, try again. So I used the Openfiler 2.3 install CD I had (intention was to present the recovered data as a NAS again – but never quite got that far). Importantly Openfiler supports XFS and software raid, and is in essence a minimised Linux distro with a web front end.
Once booted up (hasten to add boot / OS drive was another drive, I’ve literally added the Terastation drives as additional SATA drives and done nothing with them), I ran fdisk on the first Terastation drive and saw;
fdisk /dev/sda: 250.0 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 1 48 385528+ 83 Linux /dev/sda2 49 65 136552+ 82 Linux swap / Solaris /dev/sda3 66 30378 243481141 83 Linux /dev/sda4 30378 30401 192779 83 Linux
Which was promising, in fact all 4 drives had identical partition structures. The first partition (/dev/sda1) is actually a raw xfs partition and is the / partition of the Terastation if you want to be nosy.
/dev/sda2 is swap, if I’m honest I have no idea what /dev/sda4 is (/boot maybe? I didn’t look), but /dev/sda3 (and /dev/sdb3, /dev/sdc3, and /dev/sds3 are the big ones with my data, and the software raid). There was lots of poking, prodding, reading, giving up as a lost cause at this point. I’m more than comfortable hacking about in Linux, it’s part of my day job, but Software Raid and mdadm are not my regular toys, and whilst a Mac fan my indoctrination didn’t come till the Intel days, so am not a Power PC expert. But, end result was discovering that in essence a software raid array, created on a PPC (Big Endian) device was not going to ‘appear’ under an i386 Linux (Little Endian) appliance, so give up … or google a little more.
At this point mdadm –examine was seeing nothing, there was no hint of a software raid, it might as well have been not there, but I *knew* it was. Turns out that you can change the byte order (Big Endian vs Little Endian – google it if you want), you need to do this on all components of the array, so basically;
mdadm -A /dev/md0 --update=byteorder /dev/sda3 mdadm -A /dev/md0 --update=byteorder /dev/sdb3 mdadm -A /dev/md0 --update=byteorder /dev/sdc3 mdadm -A /dev/md0 --update=byteorder /dev/sdd3
At this point we can ask mdadm to have a look, and you should get something similar to;
mdadm --examine /dev/sdb3 /dev/sdb3: Magic : a92b4efc Version : 00.90.02 UUID : 39b220be:f9b75e99:849a28e5:f10c758f Creation Time : Sat Aug 29 11:09:31 2009 Raid Level : linear Raid Devices : 4 Total Devices : 4 Preferred Minor : 1 Update Time : Sun Mar 6 17:05:45 2011 State : active Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0 Checksum : f8cc653a - correct Events : 0.8 Rounding : 64K Number Major Minor RaidDevice State this 3 8 51 3 active sync /dev/sdd3 0 0 8 3 0 active sync /dev/sda3 1 1 8 19 1 active sync /dev/sdb3 2 2 8 35 2 active sync /dev/sdc3 3 3 8 51 3 active sync /dev/sdd3
Bingo, we’re now acknowledging the raid array components, so stich back together with;
mdadm --assemble /dev/md0 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3 mdadm: /dev/md0 has been started with 4 drives.
Then give it somewhere to mount (but read only for now, to be safe);
mkdir /mount/md0 mount -o ro -t xfs /dev/md0 /mount/md0 mount: /dev/md0: can't read superblock
Cock At this point you may be laughing and busy copying off your data, but not for me. Am not an XFS filesystem expert, but some more googling suggested some options, and lots of warnings that *this may further corrupt your data* remember, I wasn’t too concerned if it ended badly, so you’ve been warned, at least twice!
xfs_repair /dev/md0 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this.
You have now been warned three times! Pressing on …
xfs_repair -L /dev/md0
… followed by similar output to above, confirming that the log had been zapped and recreated, but nothing else fatal, then to be sure;
xfs_check /dev/md0
Again nothing, so, try again;
mount -o ro -t xfs /dev/md0 /mount/md0
Bingo!
Openfiler saw the software raid array we’ve just re-created, but I’m assuming that because it relies mostly on LVM volume groups on top of physical disks / arrays it couldn’t do anything for me with an array of existing data, so I just fired up an SFTP client and copied everything off.
Hope this helps, please heed my warnings if your data is critical, but then if it were critical you’d have a backup, right?
Andy Flisher is a Software Developer based in the North East of England specialising in cross platform development. Mobile Development experience includes Windows Phone, Android, and iPhone Apps. Desktop Software Development includes bespoke Windows, Linux, and Mac Applications. Web Development Skills include PHP, Perl, Python, ASP (Classic and .NET) – Andy Flisher on Google+
Flickr-age
Backchat