HyperDrive – Virtual Engine Ltd

19th November 2012

The Anywhere Home Drive

I thought I’d put pen to paper to discuss a topic that was raised during the most recent UK Citrix User Group meeting. Discussions in the afternoon session were focused around user data, mobility and possibly the end of the user home drive as we know it. There has been lots of talk about how insecure DropBox is and the desire for businesses to implement an on premise solution. Obviously there are other commercial and open source services/products in market today that were not covered, e.g. Box, Google Drive and SkyDrive etc.

Ultimately we had AppSense, Citrix and RES in the same room demonstrating their respective products; DataNow, ShareFile and HyperDrive.

The ways in which these products are implemented varies significantly and they’re seemingly targeted at different markets or are trying to solve slightly different problems (some of which I’m not convinced really exist). For example, AppSense take a data aggregation perspective whereas RES are outwardly targeting DropBox with their current release.

From a UEM perspective there is obviously the desire for both AppSense and RES that the users’ personalisation is moved to a solution that also enables ubiquitous access within their respective UEM solutions. Synchronisation of favourites and signatures etc. regardless of device would be a massive boon for corporate users. Microsoft are doing some of this with Windows 8 today via SkyDrive.

My feeling is that regardless of what solution is implemented the vendors need to make using their product easier to use than “free” consumer products. I’m sure the majority of corporate users will happily utilise an alternative solution if it’s as easy or easier to use then their existing tool of choice. Key to this process is ensuring that a user does not have to move their data to a new solution and that their existing workflows continue to work. How many linked spread sheets are entrenched within businesses today?

Out of the solutions demonstrated the other week AppSense appear to have a head start. DataNow will currently (only) make a user’s existing home drive/directory available via the DataNow client on iOS and Android devices. This will be extended to other SMB shares and SharePoint in the future with the DataNow Enterprise product. You never know, it might actually make using SharePoint bearable!

Contrary to the DataNow product, the HyperDrive appliance is targeted directly at replacing DropBox with an on premise alternative. The caveat here is that data still needs to be moved from its existing location to a secured area managed by HyperDrive. Now don’t get me wrong; DropBox users do this already so this should not be huge undertaking. However, moving and duplicating data is not a long term solution.

Citrix announced at Synergy in Barcelona that the “Control Plane” that federates authentication and management for it’s ShareFile product is now available within the EU (Germany). For European organisations that was always going to be necessary requirement. One can only assume that this will be extended to further geographies in the near future?

The introduction of Storage Zones for ShareFile enabling on-premise data storage is something of a (welcome) surprise considering the relationship Citrix have with both AppSense and RES. OK; I’m not really surprised but it has happened quicker than I thought it would. Unfortunately for Citrix, until the Control Plane is able to run on-site it is likely there will still be some reluctance from enterprises as you’re still reliant on Citrix data centres for access to your data.

In summary all three of the products still need some development before they’re adopted by enterprises en masse, if at all.

The DataNow Enterprise product isn’t currently shipping (the Essentials version is) so it’s hard to recommend but looks promising.
HyperDrive is functional although a “little rough around the edges” but this should be expected for a v1 product. As a direct replacement for DropBox it is workable.
ShareFile has some fantastic opportunities with the Citrix Receiver integration but you’ll need both ShareFile Enterprise and CloudGateway Enterprise to the get the most out it. Would a smaller “point” solution be cheaper and easier to implement?

So who can deliver first…?

16th August 2012

Installing RES HyperDrive Hypervisor Tools

RES Software have finally released RES HyperDrive and it’s available as a virtual appliance for VMware vSphere, VMware Workstation, Citrix XenServer and Microsoft Hyper-V. One thing that might surprise you is that the relevant hypervisor integration tools are not preinstalled. It surprised me, but then I thought about it; how will RES know what particular build of vSphere or XenServer you’ll be running?!

Installing the integration tools will allow the RES HyperDrive appliance to play nicely with the hypervisor and permit migration and dynamic memory support etc. Whilst there are numerous articles on the internet, I thought I’d put a few notes together in one place to make it easy for people to evaluate or deploy the virtual appliance into production.

VMware Workstation 8 and vSphere 5

Installing VMware Tools into both VMware Workstation and VMware vSphere is relatively straight forward.

Mount the VMware Tools CD/DVD by choosing the “Install VMware Tools” option within VMware Workstation/vSphere client
Logon to the HyperDrive console or access the virtual appliance via SSH
Mount the CD image with mount /dev/cdrom /mnt
Copy the installation files to the temp directory cp /mnt/VMwareTools-x.x.x-xxxxx.tar.gz /tmp
Change the temp directory cd /tmp
Extract the Tarball tar zxpf /mnt/VMwareTools-x.x.x-xxxxx.tar.gz
Dismount the CD image with umount /dev/cdrom
Install VMware Tools by running ./vmware-tools-distrib/vmware-install.pl
Accept all the defaults and select a default resolution for X support (not that it appears to be used on the appliance!)
Reboot the virtual appliance
If using vSphere the tools should be reported as installed

If you need to reconfigure the VMware tools configuration simply rerun the /usr/bin/vmware-config-tools.pl command as and when required.

Citrix XenServer 6

This is where the fun begins.. Installing the XenTools into the XenServer virtual appliance image is just as easy as VMware Worksstation/vSphere.

Mount the Citrix XenTools CD/DVD by choosing the “Install XenServer Tools” or manually mount the xs-tools.iso image within XenCenter
Logon to the HyperDrive console or access the virtual appliance via SSH
Mount the CD image with mount /dev/cdrom /mnt
Install XenTools by running /mnt/Linux/install.sh
Accept all the default prompts
Reboot the virtual appliance

Once you reboot the appliance you may find that XenCenter still reports that XenTools are still not installed?! After some investigation (and not being a Linux expert) it appears that the kernel used to build the appliance in not paravirtualization (PV) aware, rather in HVM mode. Therefore, without recompiling the kernel it’s impossible to get the XenServer tools installed to support live migrations. Hopefully this is a simple oversight on RES’s part and will be rectified in future builds (I hope!).

In the meantime I will try to find out how to recompile the HyperDrive appliance kernel. I’ll let you if I’m successful but it doesn’t look particularly easy. There appears to be an issue with the configured Nomadesk YUM repository and it won’t retrieve the package list correctly to install the additional kernel. My recommendation at this point would be utilise the VMware appliances wherever possible or live with the fact that you’ll need to shut the HyperDrive appliance down to move it to another host.. Sad smile

I’ve not played with the Hyper-V appliance as we have no customers running it but please let me know if it works and how to install them!

13th August 2012

Replacing the RES HyperDrive SSL Certificate

We’ve had to replace numerous HyperDrive SSL certificates already as the self-signed SSL certificates generated by the RES HyperDrive appliance won’t cut it if you want to use the appliance in production or if iOS/OS X devices are deployed. Fellow RES guru Rob Aarts has an article published on RESguru.com, but I’ve had differing experiences and our process is slightly different.

Unfortunately (for seemingly me in particular) I always appear to receive a “SSL key not valid” error when trying to import the certificate via the wizard (Nomadesk are aware of the problem and are investigating):

RES do have a KB article (login required) that details how to manually replace the certificate. There are some fairly simple steps that you follow, but as with all the RES HyperDrive documentation so far, there are some holes in it if you’ve never performed the actions before.

In the post I will assume that you have you SSL certificate in 2 parts; the public certificate (.crt file) and the private key (.key file). If you need to know how to generate these files from a .pfx file, I suggest you refer to the instructions in the Replacing the Default XenServer WSS Certificate post first and look for the “Converting the Certificate to a .CRT and .KEY Pair” section. Note: there must not be a password on the .key file!

Additionally you will need to be comfortable with Transferring Files to RES HyperDrive and probably Remotely Administering RES HyperDrive.

Preparing the Files

The RES HyperDrive appliance requires 3 files; the public certificate file, the private key file and the CA intermediaries. These files need to be named localhost.crt, localhost.key and ca-bundle.crt respectively.

It is probably easier to rename these files before copying them to the appliance (and it’ll keep the post shorter!).

Backup the Self-Signed Certificate

Once connected to the RES HyperDrive appliance console you can backup the existing certificate files with the following commands:

mv /etc/pki/tls/certs/localhost.crt /etc/pki/tls/certs/localhost.crt.old
mv /etc/pki/tls/certs/ca-bundle.crt /etc/pki/tls/certs/ca-bundle.crt.old
mv /etc/pki/tls/private/localhost.key /etc/pki/tls/private/localhost.key.old

If you get any permissions errors, remember to elevate to root with the su – command first.

Transfer the Files

The next step is to transfer the files to the HyperDrive appliance. I’ll assume that you’ve copied these to the appliance via SSH/SCP and they reside in the /home/hyperdrive directory. If you’ve used RES Automation Manager you can put them wherever needed 😉

Move the Files

Now that we’ve backed up the original self-signed certificate and copied the new files in they’ll need to be relocated. Move the files with the following commands:

mv /home/hyperdrive/localhost.crt /etc/pki/tls/certs/
mv /home/hyperdrive/ca-bundle.crt /etc/pki/tls/certs/
mv /home/hyperdrive/localhost.key /etc/pki/tls/private/

Fixing Permissions

I don’t actually know what permissions are needed by RES HyperDrive but my assumption is that they probably need to mirror what was there before. Fix the permissions by running the following commands:

chmod 0644 /etc/pki/tls/certs/localhost.crt
chmod 0644 /etc/pki/tls/certs/ca-bundle.crt
chmod 0600 /etc/pki/tls/private/localhost.key

If you copied the files in via SSH/SCP then they will be owned by the hyperdrive account. To reset the file owner on the files back, run:

chown root:root /etc/pki/tls/certs/localhost.crt
chown root:root /etc/pki/tls/certs/ca-bundle.crt
chown root:root /etc/pki/tls/private/localhost.key

Restart the Web Server

Once the files have been replaced and updated, restart the web server by running the service httpd restart command and BINGO!

Pre-canned RES AM Building Blocks

If you have integrated RES HyperDrive with an existing RES Automation Manager installation (remember you get a complimentary RES AM license) I’ve included a building block (click the red brick to download) that will perform the required configuration for you. Note: remember to replace the localhost.crt, ca-bundle.crt and localhost.key files in the \virtualengine.co.uk\RES HyperDrive\ resources folder before running it!

[wpdm_file id=10]

29th July 2012

Upgrading RES AM Linux Agents

There comes a time when RES Automation Manager Linux agents need upgrading. A typical example is with the GA release of RES HyperDrive. Now that RES Automation Manager 2012 SR1 has been released, there is a newer Linux agent that isn’t (currently) is the RES HyperDrive appliance.

If you’re like me, you’ll want to upgrade this. The Getting Started with RES Automation Manager Agent for Linux guide will point you in the right direction, but unless you’re a fairly competent Linux administrator you may struggle with certain aspects. For example, to upgrade the RES AM Linux agent all you need to do is:

1. Stop the currently installed RES Automation Manager Agent for Linux by using the command /etc/init.d/resamad stop.
2. Uninstall the RES Automation Manager Agent for Linux.
3. Install the new version of the RES Automation Manager Agent for Linux.
4. Start the new RES Automation Manager Agent for Linux.

So there you have it – simple!

I’ll actually take you through the individual steps to upgrade the Linux agent installed in a RES HyperDrive appliance. These steps are equally applicable to any Linux installation but this will no doubt be a common scenario. As an overview the steps required are:

Find installed RES Automation Manager Agent for Linux version;
Uninstall existing RES Automation Manager Agent for Linux;
Copy new RES Automation Manager Agent for Linux;
Extract RES Automation Manager Agent for Linux;
Install RES Automation Manager Agent for Linux;
Configure RES Automation Manager Agent for Linux;
Start the RES Automation Manager Agent for Linux.

Connecting

Firstly you’ll need to connect to the RES HyperDrive virtual appliance via SSH (see Remotely Administering RES HyperDrive) or connect to the console session.

Uninstall Existing Version

To uninstall the existing RES Automation Manager Agent for Linux you’ll need to find the currently installed version before you can actually remove it. To find the existing version run:

[code]rpm –qa | grep –i res-am[/code]
This will display the current version. Make a note as you’ll need it in a minute or two! Here’s an example screenshot from the RC2 appliance:

To uninstall the agent run:

[code]rpm –e <res-am-agent-version>[/code]

The <res-am-agent-version> is listed in the first command, for example res-am-agent-6.5-0.102354. If successful the agent service should be stopped and the agent uninstalled.

Note: I have seen multiple agents installed in both the RC2 and GA releases. It looks like an oversight and the 6.4-2 version is not actually installed. If you want to remove both entries then the second rpm –e command may give you an error but it will be removed from the list.

Copy Agent Files

You will need to download the latest Linux agent version from the RES support portal as they’re not included in the management console like the Windows clients. Once you’ve downloaded the tarball, copy it to the RES HyperDrive appliance (see Transferring Files to RES HyperDrive) into the /home/hyperdrive directory.

From your SSH/console session run:

[code]mv /home/hyperdrive/res-am-agent-<version>.tgz /tmp[/code]

This will move the file into the /tmp directory. Note: If you don’t have permissions to do this run the ‘su –‘ command first, enter the root password and try again.

Extracting the Agent Installer

As the RES Automation Manager Agent for Linux is compressed it needs extracting before it can be installed. Change the working directory and extract the archive by running the tar command:

[code]cd /tmp
tar xvzf ./res-am-agent-<version>.tgz[/code]

This expands the files into the /tmp/AIX, /tmp/RedHat and /tmp/Suse directories. As CentOS is based on RedHat 5 we need to install this agent version. Install the new agent version by running:

[code]rpm –i /tmp/RedHat/Release5/x86_64/res-am-agent-<version>.x86_64.rpm[/code]

Configuring the Agent

To connect the RES Automation Manager Agent for Linux, we either need to enable auto discovery or specify a Dispatcher list. If you wish to enable auto discovery you can configure the agent with the following command:

[code]/usr/local/bin/resamad –d m[/code]

If you wish to specify a Dispatcher run this instead:

[code]/usr/local/bin/resamad –dd<Dispatcher>[/code]

For example, if your Dispatcher was called RESAMDISP01 (with an IP address of 192.168.0.100) you could either run

[code]/usr/local/bin/resamad –ddRESAMDISP01[/code]

[code]/usr/local/bin/resamad –dd192.168.0.100[/code]

Starting/Stopping the Agent

After the upgrade you’ll probably need to start the agent. To do this you can simply run:

[code]service resamad start[/code]

If you check the RES Automation Manager console you should see your agent online. The version shown below (6.00.111676) is the RES Automation Manager 2012 SR1 Agent for Linux.

If you need to restart the RES Automation Manager Agent for Linux run service resamad stop and then service resamad start. Why there is no service resamad restart command I don’t know! If I wasn’t lazy I’d create the required script but as the appliance is supposed to be “rip and replace” I don’t think I’ll bother 🙂

Phew – hopefully someone finds this useful? Iain

10th July 2012

Transferring Files to RES HyperDrive

As I’ve discussed previously, connecting the RES HyperDrive appliance via SSH is more involved than is typical for other Linux appliances. My assumption is that, as SSH is used by OS X clients and is exposed to the big bad world, it needs be secured. And tightly!

I have come across numerous times that I’ve needed to transfer files to or from the virtual appliance. This normally involves copying SSL certificates and keys and grabbing log files etc. Various people have asked me how they can achieve this so I thought I’d document the process. It’s fairly straight forward and assuming you have have your SSH private key and have downloaded WinSCP (or your SCP client of choice) you’re all set. WinSCP will transfer files over SSH and therefore, the process is almost identical to the earlier Remotely Administering RES HyperDrive post.

Note: If you have RES Automation Manager 2012 deployed then you can always transfer files to the appliance with the built-in Linux/Unix Resource Download task. If you don’t or want to know how to do this manually, feel free to continue..

After launching WinSCP you need to enter the connection information. Enter the hostname/FQDN, port number, username and private key as highlighted below (replace the hostname accordingly!). Make sure that you enter the username as hyperdrive and leave the password blank!:

When you connect by clicking the Login button you’ll be asked whether you trust the server’s key, so go ahead and do so. Once connected you should be able to transfer and drag ‘n drop files from left to right.

As we’re connecting as the hyperdrive user account we can only really copy files into the hyperdrive user’s home directory (/home/hyperdrive). After you’ve copied the files into the home directory you’ll need to move the files via the command line, i.e. via the console/SSH (don’t forget to change the owner and permissions as required!). Reading files is generally less of an issue, but you might need to relocate them into the /home/hyperdrive directory before you can copy them out; diagnostic or log files for example.

Good luck! Iain

10th July 2012

Remotely Administering RES HyperDrive

Connecting and administering a RES HyperDrive appliance can be frustrating the first time you try. Therefore, I thought I’d put a few notes together on how to connect and transfer files to the appliance. If you’re planning on deploying SSL wildcard certificates, you’re going to need to know how to do this. Whilst you can always use the XenServer or vSphere console, connecting via SSH has many benefits.

The first thing to realise is that the HyperDrive appliance listens on port TCP port 80 for Windows client synchronisation and TCP port 8080 for OS X/Mac client sync. The OS X client tunnels over SSH and therefore the default SSH (TCP port 22) is not used.

Secondly you will also need the SSH RSA key to connect. After successfully completing the configuration wizard, you are offered the option to download the PuTTY or OpenSSH keys. Don’t worry if you never saved these somewhere safe as you can always download them later from the https://<ApplianceFQDN>/va/keys/putty or https://<ApplianceFQDN>/va/keys/rsa URLs (this doesn’t appear to work on the RC release). Notice that you will need to authenticate with the root password to download the keys (notice the typo?!):

Once you have the private key you can configure the PuTTY client. Fire up the PuTTY client and enter the RES HyperDrive appliance IP address or FQDN. You must make sure that the port is set to TCP port 8080.

Before continuing you need to import the SSH private key. Expand the Connection > SSH > Auth node and select the saved key file you downloaded earlier:

When you click the Open button you should be connected to the RES HyperDrive appliance and asked if whether you trust the server’s key:

Click Yes to trust the key and continue. You’ll be prompted for a username. As you’re authenticating with a key you won’t need to enter a password. You may not be aware, but you’re actually authenticating with the local “hyperdrive” user account key. Therefore, you must use a username of hyperdrive to connect. If you enter any other user account, e.g. root, you’ll be denied access.

Once you have access to the appliance you can switch users (SU/SUDO) to perform the required administrative tasks. Enjoy!

10th July 2012

Multi-Homing RES HyperDrive

In certain situations you may wish to install two network adapters into a RES HyperDrive appliance. For example, you may not want to route internal traffic via the same gateway interface as external traffic. In this scenario there are some things that you need to be aware of. The RES HyperDrive documentation intimates that the primary NIC is the internet facing interface.

This isn’t necessarily the case and either NIC can be used. What you do need to be aware of though, is that if you configure a default gateway on all NICs, CentOS 5.3 will use the highest interface gateway as the default route. Therefore, if you specify a default gateway on both NICs in multi-homed deployment, the eth1 gateway will be used for the default route. If you look closely at the example above you will notice (there are 2 x 10.0.1.1 firewalls!) that the eth1 interface has no gateway specified. I recommend that you do leave the internet facing NIC with the default gateway, but whether this is eth0 or eth1 is up to you.

If you wish to manually alter the IP addressing information you can find the configuration scripts in the /etc/sysconfig/network-scripts/ directory. There will be an ifcfg-eth0, ifcfg-eth1 for each attached NIC. Use your favourite text editor to update the appropriate file.

Once you have configured the correct IP address(es) and gateway you will need to add static routes to the “internal” network(s). The RES HyperDrive CentOS installation stores static routes in the route-<interface> file in the /etc/sysconfig/network-scripts/ directory. As an example, if our internal networks were 172.16.0.0/255.255.0.0 and 172.17.0.0/255.255.0.0 we would create the following entries in the /etc/sysconfig/network-scripts/route-eth1 file (assuming the internal gateway is actually 192.168.1.1 and not 10.0.1.1!):

[code]172.16.0.0/16 via 192.168.1.1 dev eth1
172.17.0.0/16 via 192.168.1.1 dev eth1[/code]

Once you’ve made all your changes you can restart the networking stack by running the service network restart or reboot the appliance. If you want to view the routing table, just run the route command. Simples!