X2go and Qindel collaborating in NX development

Hi all,

Lately we have been in touch with Mike Gabriel from X2Go. We are happy to found people to help in the maintenance of nx-libs and push forward the NX development and after some mailing we have decide to join forces in the NX maintenance.

We have started to pull the nx-libs from the X2Go git and we are going to collaborate with them.

Current common interests are:

o bring NX to mobile devices
o make playing multimedia content enjoyable inside NX sessions
o fix open issues in NX
o port NX to latest X.Org code base

We hope that this collaboration will be profitable for both parts and all the open source community.

X2Go
Qindel
The QVD
X2Go Git
qvd-nx git

Seamless Windows Applications in QVD

QVD provides access to Linux desktops which provide a variety of applications and suites out of the box and is extremely customizable. The time may come, however, when you wish to provide access to a Windows program. Since you are already virtualizing your user’s desktop, we are going to look today at doing that seamlessly inside the QVD desktop. The assumption will be that you have a Windows server available on your LAN, you may even be using that server to authenticate against Active Directory.

The first thing you will need to do is install SeamlessRDP on your server. This entails registering with Cendio and downloading the ThinLinc Server Bundle. Once you receive a confirmation email, follow the link provided and download the zip file presented, at the time of writing, tl-4.1.1-server.zip. Unzip this, and locate the tl-wts-tools.exe installable under the windows-tools folder. On your Windows server, install this file. This will provide you with the SeamlessRDP executable and related files, in our instance located at %ProgramFiles%\ThinLinc\WTSTools\seamlessrdpshell.exe.

Your next step is make sure that rdesktop is available to your users. If using KVM, locate the DI and run it in KVM. For LXC, consult the QVD Administration Manual to see how you can use bind mounts to make changes to your DI. The latest stable version of rdesktop (1.8.1 at time of writing) contains several enhancements to the window handling in SeamlessRDP, so it is strongly recommended that you either compile it from source or find a repository for your distro (there is an Ubuntu ppa for example).

Once you have rdesktop installed, you can test it by running the following command inside the DI:

# rdesktop 10.0.7.33 -A 'C:\Program Files\ThinLinc\WTSTools\seamlessrdpshell.exe' \
-S "iexplore.exe"-u 'DOMAIN \ user'-p XXXXXXX

This should invoke the SeamlessRDP executable on your server, which should in turn invoke the specified startup shell which launches the desired application through SeamlessRDP, in this instance Internet Explorer. Note the domain name, user, and address of your server will all need to be specified, and you may need to specify the full path of your executable if it is not in the PATH of the Windows server.

Once you are satisfied that everything is working as expected, zip up and deploy your DI across your QVD nodes. If you wish to provide one click access to your Windows app to your users, here is a suggested implementation. Firstly, create a text file in /etc/skel/Desktop that each user will have available in their desktops. In this instance we could call it /etc/skel/Desktop/explorer.desktop. We will point this shortcut to a bash script to avoid filling it with passwords and other sensitive data. Here it is:

[Desktop Entry]
Name=Explorer
Exec=/usr/local/bin/startexplorer.sh
Icon=qvd
Type=Application
Categories=Network
Terminal=False

The next step is to create the script itself:

#!/bin/bash
homeurl=http://www.google.com
rdesktopserver=10.0.7.33
[ -r $HOME/.qvdpassthrough ] && . $HOME/.qvdpassthrough
if [ -z "$qvduser" -o -z "$qvdpassword" ]; thenhe 
 cat <<EOF | xmessage -file -
There was an unexpected error
Please contact support.
Referencia tecnica: qvdpassthrough
EOF
 exit 1
fi
echo $qvdpassword | rdesktop 10.0.7.33 -A 'C:\Program Files\ThinLinc\WTSTools\seamlessrdpshell.exe' -s "iexplore.exe $homeurl" -u $qvduser -p -

.
 The script simply sets a url for our Windows browser and passes the user’s authentication email to rdesktop. This should be available on each user’s desktop and invoke the application when opened.

Test Driving QVD Shared Folders

QVD 3.4 arrived in the new year with a few killer features, shared folders and an application server prototype amongst them. For this post we are going to concentrate on testing the shared folders functionality of QVD 3.4 using the QVD demo. If you are using a linux desktop, you’ll need to ensure you have the openssh server installed as the folder sharing requires the built in sftp server binary. There is no need to enable the openssh service, nor is this step necessary for the Windows client. If you haven’t done so already install the client for your platform, register for the demo, check your email for you login details and let’s get started.

Firstly, start up the client and enter the credentials you have been sent by the QVD.

qvd_demo_login

Within moments you will be logged into the QVD demo which is currently serving a LXDE desktop although it could be any Linux desktop environment. So far so good, but what sets QVD 3.4 apart from its predecessors is the ability to access your local files directly from within your QVD desktop. Let’s try that. Next to the “Start” Menu QVD ladybird is an icon for the default file manager, PCManFM. Click that and you will be presented with your home folder within the QVD desktop, which is as it should be. But you’ll notice within your home folder is a folder called Redirected which is a special folder created by the QVD to give you a convenient link to your local files. By default file sharing is enabled and will display your local home directory (on Windows this will be %USERPROFILE%, for Linux it will be /home/$USER) and removable storage (on Linux, /media, on Windows all existing drives available in My Computer: c:, d:, …). This is neatly illustrated by the following image, which shows my home and media folders.

qvd_demo_redirected_folders1

Digging down into the home folder and then Documents, we can see my local documents are now available directly from the QVD desktop.

qvd_demo_redirected_documents

These files can edited directly in the QVD desktop and any changes will be saved over the QVD’s custom built protocol right back on to your local desktop. Alternatively, copy the files to the QVD desktop and back again when you have finished with them. This seamless integration between local and remote desktops provides considerable convenience to remote users.

QVD 3.4 Released

QVD is delighted to announce the release of version 3.4 of our flagship VDI which provides several important new features along with stability enhancements and bug fixes. QVD 3.4 provides an improved user experience as well as enhancements to the backend that will make administration even easier.

  • Shared Folders
    QVD users can now effortlessly share folders between their desktops and their QVD session. Enabled by default, users will be able to see their home folders within QVD, as well as any locally attached drives.
  • Expiration of images
    QVD 3.4 provides a mechanism for upgrading images by setting time limits on a disk image. Soft limits can be used to notify a user of an available upgrade and to request the user to reboot as soon as is convenient. Hard limits can be used to forcibly reboot an desktop (and thus upgrade to the next available version).
  • Mac OS Client
    The QVD client for all platforms has been rewritten from the ground up and is more stable and offers basic settings changes to the user. In addition to the Windows and Linux clients, we now offer an OS X client (unsupported) enabling your users to connect to your QVD farm from Mac desktops.
  • QVD Spy
    QVD Spy allows your administrators to directly access your users’ desktops, making desktop support that much easier.
  • Application Server
    QVD 3.4 comes with a technical preview of our forthcoming application server. This will allow administrators to deploy stand-alone desktops directly to the user without the attendant Linux desktop. Please note that this feature is still under heavy development and may change over the coming weeks. It is also, as yet, undocumented.

Other functionalities and improvements that offered by QVD 3.4 include:

  • Resetting the desktop session from the client.
  • Improvements in the client interface.
  • Improvements in certificate management.
  • Integration with improved Linux cgroups management.
  • Improved integration with LDAP.
  • Refactored backend.

The QVD Appliance has been rebuilt by the development team to demonstrate the new features. All you need to do is download the OVA archive and import it into VirtualBox to try out QVD 3.4 today.

To view the full list of changes and for QVD 3.4, please refer to the Release Notes, which provide a list of the new features and changes, along with instructions to install or upgrade QVD 3.4 for your environment. Note that 3.4 also heralds the arrival of the new home for the QVD documentation which now resides at http://docs.theqvd.com. The docs are now available in additional formats and includes a table of contents for the HTML version which hopefully makes them easier to digest.

As always, the source code is available to download from our GitHub mirror. We welcome your thoughts, so please get in touch with your thoughts, questions and comments.

 

 

New QVD Client Binaries

We’ve been quietly rewriting the QVD clients for all platforms, refactoring old code and implementing some of our new ideas and today we provide the first access to the reworked clients. With the exception of the Windows and OS X clients, these are statically linked binaries which means they can be run without any dependencies, just download and execute the files.

The binaries have a few mandatory options which can be obtained by using the -? switch, for example

$ ./qvdclient -?

You may wish to set environment variables for debugging purposes and to prevent your credentials being visible. The following are available:

QVDHOST : Specifies the host to connect to, if not specified with -h
QVDLOGIN : Specifies the username, if not specified with -u
QVDPASSWORD : Specifies the password, if not specified with -w
QVD_DEBUG : Enables debugging, can also be enabled with -d
QVD_DEBUG_FILE : Enables the file were debugging should go to

Currently the following binaries are available to download:

  • Linux
    These should run under any recent distribution without additional libraries, simply set the executable bit and run.

  • Free BSD
    As above, simply set the executable bit and run.

  • Mac
    OS X and IOS clients.

  • Windows
    The Windows binary requires a base cygwin install. You will need to set the DISPLAY environment variable as follows:
    $ export DISPLAY=localhost:0
    Then execute the binary from within the cygwin shell. Alternatively create a shell script (ending .sh) setting the DISPLAY variable and invoking the client, then configure Windows to open such files with C:/cygwin/bin/sh.exe

  • Android
    As with the IOS clients, this will require a working X server. Again, it is probably best to use the available client in the Android store for now.

  • Raspberry Pi
    A working Raspberry Pi binary that will run under X.

QVD Shared Folders

QVD 3.4 is coming soon and it offers some exciting new features which we will cover over the next couple of weeks. The first one we’re going to take a look at is shared folders, a feature which bridges the gap between your local desktop and the QVD desktop.

Shared folders gives the user direct access to the documents and media folders on their own computer, providing a convenient way for users to access their local files. OS agnostic, this works whether your user is accessing the QVD desktop from Windows, OS X, or Linux. If your users choose to do some work from home on their own system, they can quickly and easily access those files from within the QVD desktop with a minimum of fuss.

So how does it all work? We’ve written our own custom protocol that runs on top of the NX stack, ensuring both security and optimal transfer speeds. File sharing is enabled by default, redirecting the user’s home directory (on Windows, %USERPROFILE%) and removable storage (on Linux, /media, on Windows all existing drives available in My Computer: c:, d:, …).

The local folders will be available folders appears by their names in a directory called Redirected in the home folder of the user’s virtual machine. If you use Gnome or another modern Linux desktop environment a shortcut will also be shown on the desktop. The user is able to access their local folders, editing and saving them in a seamless manner as though they were local.

Let’s take a look at a screen shot to show this at work. Our user, David, is logged into his QVD desktop from his Linux PC. As shown in his file manager, he has access to not only his home directory in QVD, but also his local home directory and his media devices, all neatly mounted for easy access. David can copy his files over to his QVD desktop or just start working right away over the network – convenience at the click of a mouse.

shared_folders

It may be that you prefer to contain files from the QVD desktop locally, in which case folder sharing can be disabled with a simple directive in your disk images should you wish. Additionally, Linux users can share folders other than the defaults using the qvd-slaveclient command. Our intention is to make this functionality cross platform and accessible from within a future release of the QVD client, we’re not yet there yet but keep an eye out for in it future releases.

That about wraps up our introduction to shared folders in QVD 3.4, providing convenience to your users with no setup overhead. QVD 3.4 will build on our rock solid software, adding features to the lowest footprint VDI suite in the game that you and your users will love. Next time we will cover disk image ageing in QVD which will give your administrators the ability to expire disk images and ensure that your users are always using the most up to date desktop. Stay tuned!

Disk Image Aging

We’ve been busy at the QVD with a bunch of new features due in our upcoming release. Last week we talked about QVD Shared Folders which provides your users with instant access to their local files, convenience at a click of the mouse. This week we take a look at  Disk Image Aging, a feature aimed more at helping your business and making the lives of your administrators easier.

So what is Disk Image Ageing exactly and how can it help your business? Let’s take an example and say your company deploys the QVD along with a desktop application to your users. The desktops and indeed your application will need to be maintained to keep the software up to date with new releases and security fixes. The image can be updated manually or using a configuration management system such as cfengine. That done, the application could be updated using a script, for example:

# cd /var/lib/qvd/image/default/opt/myapplication
# rsync -avz remoterepository:/stableversion/myapplication/ .
# version=$(awk '$1 ~ /version:/ {print $2}' /etc/myapplicationversion)
# cd /var/lib/qvd/image/default/
# tar cfz /var/lib/qvd/storage/staging/myimagedi-$version-$(date +%Y-%m-%d).tgz .

This will create a tgz of your new disk image, complete with the updated application, in your QVD staging folder. To deploy the disk image, simply use the QVD administration tool:

# qa di add path=/var/lib/qvd/storage/staging/myimagedi-9.3-2013-09-23.tgz osf_id=1 version=9.3

This will add your fresh disk image which will be allocated the tag head. Assuming your install is set up to use the image with the default tag and not head, find out the di_id and tag it as default.

# qa di tag di_id=15 tag=default

So far this is pretty simple. However, there are a couple of problematic scenarios that may arise in this situation. The first is that a running VM that is in a disconnected state will of course continue to server the outdated disk image. This is easily solved; once you are sure that the new image has been deployed on each QVD node (we use a helper script for this), your update script can stop these VMs and thus ensure that each new user is served the new image.

The second issue is that of users still running the now outdated disk image and still actually connected. This would imply that the user is in an active session with the QVD desktop and randomly disconnecting them would not be desirable. This is where QVD image ageing comes to the fore. QVD 3.4 will provide a system for ageing disk images, in the form of hard and soft limits that can be set by the administrator to ensure that users are upgraded to the latest disk image in a timely fashion. This is achieved by setting one or both limits when adding or tagging a disk image (each is optional and interdependent of the other).  This is achieved using the expire-soft=DATE and expire-hard=DATE options with either the tagging or adding of a new disk image:

# qa di tag di_id=15 tag=default expire-soft=now expire-hard="NEXT SAT"

As you can see, the parameters for the date itself can be pretty user friendly. They follow the same format as the at command in Linux, which allows pretty complex specifications while at the same time being fairly human readable. See the at man page for further info.

The soft limits can be set to trigger a hook or mechanism of the administrator’s choosing to alert the user of the need to log out as soon as is feasible. This hook would also be responsible for ensuring that a VM is restarted when the user disconnects, allowing QVD to serve up the new disk image. The great thing about soft limits is that they are extremely flexible – the hook can be any Linux executable, meaning that the administrator chooses how they want to react the the soft limit being reached.

 By contrast, hard limits are a much simpler proposition. For particularly trenchant users who are perhaps indisposed or choose to ignore requests to log out, hard limits provides an option to forcibly restart a VM. This means that the administrator can set a limit to ensure that all users are using the latest disk image with whatever new features and security upgrades are deemed necessary

The pretty much covers the expiration limits coming up in the next version of QVD. They are simple and yet, in the case of the soft limits, as powerful as you need them to be. Next time we’ll take a look at Shared Folders, another fantastic feature that’s in the pipeline which bridges the gap between your local client and the QVD desktop by providing access to your local folders within QVD itself.

Authenticating Against Active Directory

Following on from last week’s post on authenticating the QVD against LDAP, this week we turn to Active Directory, another common single sign-on authentication service provided by companies. Since AD makes use of Lightweight Directory Access Protocol (LDAP) versions 2 and 3, the process is pretty similar.

Testing Your Active Directory Server

As with LDAP, it’s probably a good idea to make sure you can connect to your AD server from the command line of your QVD node before you begin any configuration changes. This will narrow the scope of your troubleshooting should you run into problems down the line. To do you will need to have the ldap-utils (Ubuntu) or the openldap2-client (SLES) package installed as it provides a series of useful tools for communicating with an LDAP instance. That done, run the following command from your QVD node command line:

ldapsearch -LLL -H ldap://example.com:389 -b ‘dc=example,dc=com’ -D ‘EXAMPLE\jdoe’ -w ‘password’ ‘(sAMAccountName=jdoe)’

Of course, point the host (after the -H flag) to your own LDAP server (and change ldap to ldaps if you have a secure setup) and alter the search base (-b) and account name as is appropriate for your setup. This should return something similar to the following:

dn: CN=John Doe,CN=Users,DC=example,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: John Doe
sn: Doe
givenName: John
distinguishedName: CN=John Doe,CN=Users,DC=example,DC=com
instanceType: 4
whenCreated: 20130417152557.0Z
whenChanged: 20130417152612.0Z
displayName: John Doe
uSNCreated: 20553
memberOf: CN=Users,CN=Builtin,DC=example,DC=com
uSNChanged: 20563
name: John Doe
objectGUID:: r7URCgubR0GGxTnxDQkdTg==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 130106859571806640
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAbhS4Tz7BzIZCZsndUgQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: jdoe
sAMAccountType: 805306368
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=example,DC=com
dSCorePropagationData: 20130417152557.0Z
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 130106859725400390

So once you have successfully logged into the AD server and retrieved the account information for a user on your domain you are ready to continue.

Basic Active Directory Configuration

As with the LDAP configuration, you will need to install the LDAP Authentication Plugin on your node server to connect to Active Directory. For Ubuntu, that will mean installing perl-qvd-l7r-authenticator-plugin-ldap, and for SLES 11 perl-QVD-L7R-Authenticator-Plugin-Ldap. These should be available through your package manager since you installed the node server.

That done, you will need to configure your QVD node to authenticate against Active Directory. Use the administration tool qa for each of these settings and remember to enclose all values inside single quotes to prevent any shell expansion issues with brackets and the other special characters.

qa config set l7r.auth.mode='ldap' 
qa config set auth.ldap.host='ldap://example.com:389' 
qa config set auth.ldap.base='OU=People,DC=example,DC=com' 
qa config set auth.ldap.scope='sub' 
qa config set auth.ldap.binddn='CN=Administrator,CN=Users,DC=example,DC=com' 
qa config set auth.ldap.bindpass='password' 
qa config set auth.ldap.filter='(sAMAccountName=%u)' 

l7r.auth.mode  simply tells QVD that you wish to authenticate against an LDAP server (Active Directory in this case), whilst  will point to your LDAP server. You may wish to use ldaps if you are using SSL.

The LDAP base  tells QVD where in the directory tree to begin searching and setting the scope to sub  tells it to look anywhere below the base. The Bind DN  will be a user on the AD server permitted to search the directory within the defined search base, in this instance the Administrative user. You may well opt to add another user for this purpose to increase security. The bindpass key  is then used to authenticate this user.

Finally you tell QVD to match the user’s name against sAMAccountName  which, as you can see in the above example, is the  logon name for Windows user. If AD finds a match against this user, it will authenticate the user to access the QVD.

Once you have configured your LDAP settings, restart the l7r service (service qvd-l7r restart) and QVD is ready to start authenticating against Active Directory.

Auto Provisioning of Desktops

Whilst the above setup will allow you to authenticate users against Active Directory, you will still need to create a machine for each user in the directory. So QVD comes with an automatic user provisioning plugin that creates desktops for your users on the fly when they authenticate successfully against LDAP or Active Directory.

You’ll need to install the plugin, again with your package manager. It’s called perl-qvd-l7r-authenticator-plugin-auto for Ubuntu, for SLES, install perl-QVD-L7R-Authenticator-Plugin-Auto. Make the necessary changes with the qa tool:

qa config set l7r.auth.plugins='auto,ldap' 
qa config set auth.auto.osf_id=1 

The plugins setting  tells your QVD installation that you wish to provide auto provisioning (along with LDAP), whilst will configure your install to use OSF id 1 which you should adjust accordingly. Restart the l7r service and the next time a user successfully authenticates against your LDAP server, QVD will create a VM for them using the OSF you have set, and and serve it to them seamlessly.

Restrictions of QVD and Active Directory

It’s important to note, as with the LDAP configuration, that QVD’s Active Directory support is read-only. QVD is not able to make changes to your Active Directory, so once you’ve enabled AD support, all user and password management must take place therein. With the notable exception of the QVD WAT admin user, changes or additions to user accounts and passwords in the QVD database will be ignored by the system. This is by design, we couldn’t take the risk that the QVD would interfere with an existing Active Directory setup tools that you already have in place.

Troubleshooting

If you run into trouble, ensure that you can authenticate against your Active Directory server directly from the command line in your QVD node, as described above. Also take a look at the log file /var/log/qvd/qvd.log – it will contain any authentication errors that have happened.

For a man page style list of all available AD and LDAP configuration settings, please refer to the perldoc of the QVD LDAP plugin as follows:

/usr/lib/qvd/bin/perldoc QVD::L7R::Authenticator::Plugin::Ldap

Also refer to our administration guide for additional information and feel free to contact us if you need any assistance.

Authenticating Against LDAP

QVD comes with user management built into the database, and adding them through the Web Administration Tool is really simple. However, for larger organisations, the chances are you’ll already have some kind of central authentication in place, commonly LDAP or Active Directory. In the first of a two part series, let’s look at getting your system authenticating against an LDAP server first, and next week we will look at AD.

Testing Your LDAP Server

The first thing you will need to do is ensure that the your node server can successfully connect to your LDAP server from the command line. Doing this first will ensure that you don’t run into problems that may be hard to identify later. Make sure you have the ldap-utils (Ubuntu) or the openldap2-client (SLES) package installed as it provides a series of useful tools for communicating with an LDAP instance.

ldapsearch -xLLL -H ldap://example.com -b "dc=example,dc=com" cn=admin cn

Of course, point the host (after the -H flag) to your own LDAP server (and change ldap to ldaps if you have a secure setup) and alter the search base (-b) as is appropriate for your setup. This should return something similar to the following:

dn: cn=admin,dc=example,dc=com
cn: admin

At this point you should be satisfied that read access to your LDAP server is possible from your QVD node and you are ready to continue.

Basic LDAP Configuration

Next you will need to install the LDAP Authentication Plugin on your node server. For Ubuntu, that will mean installing perl-qvd-l7r-authenticator-plugin-ldap, and for SLES 11 perl-QVD-L7R-Authenticator-Plugin-Ldap, so go ahead and install that using apt-get or zypper.

That done, you will need to configure your QVD node to authenticate against LDAP. Use the administration tool qa for each of these settings as the QVD database takes precedence over /etc/qvd/node.conf file and will ensure that all nodes will see the changes. Enclose settings in single quotes to save yourself the trouble of having to escape all those brackets and other special characters that an LDAP schema throws up.

qa config set l7r.auth.mode='ldap' 
qa config set auth.ldap.host='ldap://example.com:389' 
qa config set auth.ldap.base='ou=People,dc=example,dc=com' 
qa config set auth.ldap.filter='(&(objectClass=inetOrgPerson)(cn=%u))' 
qa config set auth.ldap.scope='sub' 

Let’s walk through some of those options. simply tells QVD that you wish to authenticate against LDAP, whilst points it to your LDAP server. Next you want to tell QVD where the base of the Directory Information Tree, or DIT is, and that is exactly what you do with step does. Next you tell QVD how you would like to filter against the database, in this instance by inetOrgPerson (your users) and using their common name, assuming that this is their username. Finally you instruct QVD to use the LDAP scope of sub which permits it to look down the subtree until it finds the cn.

That done, restart the l7r service (service qvd-l7r restart) and QVD is ready to start authenticating against LDAP, it’s that simple.

Auto Provisioning of Desktops

However, this method is not quite the full picture and perhaps a little simplistic for a real world example, as you will still need to create each machine for each user and it’s unlikely that this is desirable. So QVD comes with an automatic user provisioning plugin that creates desktops for your users on the fly when they authenticate successfully against LDAP.

You’ll need to install the plugin, again with your package manager. It’s called perl-qvd-l7r-authenticator-plugin-auto for Ubuntu, for SLES, install perl-QVD-L7R-Authenticator-Plugin-Auto. Again with the administrative tool, make the following changes:

qa config set l7r.auth.plugins='auto,ldap' 
qa config set auth.auto.osf_id=1 

tells your QVD installation that you with to provide auto provisioning (along with LDAP), whilst will configure your install to use OSF id 1 which you should adjust accordingly. Restart the l7r service and the next time a user successfully authenticates against your LDAP server, QVD will create a VM for them using the OSF you have set, and and serve it to them seamlessly.

Restrictions of QVD and LDAP

QVD’s LDAP implementation provides an extremely powerful tool for enterprises to roll out desktops to their users quickly and painlessly, particularly in the event that you already have an LDAP server up and running and populated with your user data. However, we were very careful to make sure that we don’t have any negative effects on your existing systems, so the QVD software is not able to make any write access to your data store. This means that the user management inside QVD Web Administration Tool becomes read only, and adding and changing credentials therein will have no effect. Data will be stored inside the QVD database but since it is configured to authenticate against LDAP, that data is effectively ignored by the system. This is absolutely by design, we couldn’t take the risk that the QVD would interfere with existing LDAP tools that you already use, and it is to these you will now need to turn to manage your users.

Troubleshooting

If you run into trouble, ensure that you can authenticate against your LDAP server directly from the command line in your QVD node, as described above. Also take a look at the log file /var/log/qvd/qvd.log – it will contain any authentication errors that have happened.

For a man page style list of all available AD and LDAP configuration settings, please refer to the perldoc of the QVD LDAP plugin as follows:

/usr/lib/qvd/bin/perldoc QVD::L7R::Authenticator::Plugin::Ldap

Active Directory

Next time we will take a look at Active Directory. AD is of course a very common directory service amongst enterprises the QVD offers full support for it along with LDAP. Inspired by LDAP, configuration is somewhat similar and, like the QVD LDAP setup, it’s easy when you know how.

For further information including a full list of all the LDAP options, please refer to our administration guide or get in touch.

Documentation Update: Creating Disk Images for QVD

Creating a disk image for the QVD is incredibly simple and customizing each image for your users similarly so. We’ve updated our documentation section to include new sections on this important task for a QVD administrator with dedicated sections for disk image creation for SLES and 0penSUSE (pdf) and Ubuntu ((pdf):

The guides will walk you through installing a base system using KVM and then either customizing that system for use as a Virtual Desktop, or going on to use that base system to build an LXC container for the same. We’ve used the Lightweight X11 Desktop Environment or LXDE as it provides a stable and intuitive environment with a low memory footprint and thus makes an excellent base for your customized environment.

As you will see, customizing a disk image is very simple. Before you roll it out to your users, you will be running each image locally and from there your imagination is the limit. All the software and
customizations you make to each image will be rolled out to every user who makes used of that image. So you can install the things that are important to your users once, and rest assured that they will have that software available immediately you deploy the image.

Once your image is ready, deploying it is a simple matter of unzipping it into QVD’s staging folder and rolling it out using the Web Administration Tool we provide.

We finish up the guides with a few tips and tricks – remote logging of your desktops with syslog and installing a couple of commonly used apps as well as optimizing the image by removing unnecessary services. Again, nothing that anyone with a modicum of Linux experience would find challenging, the whole process is painless and easy.