Saturday, June 14. 2014
Updating the old RDP portlet (Part II)
In a previous entry the updating process of the old RDP portlet was starting. The main new idea is using the FreeRDP project as the local program which launches the Remote Desktop / Terminal Services applications. This project presents all the features the portlet needs (RemoteApp for displaying the non-local applications seamlessly in the user's desktop, the gateway to use RDP over HTTPS and managing exported RDP files) but some of them are just supported in the beta version 1.1 and, in general, they need some love for polishing final details.
This second entry is dedicated to the portlet itself. The portlet was originally developed in the times that JSF 2.0 was being introduced and the technology was starting to be supported inside a portlet. Besides, instead of using a normal relational database, Cassandra NoSQL was used. Therefore the portlet used some curious technologies and projects which have been improved a lot since that time and, I think, some little summary is required.
The Cassandra project has been moved from version 0.6 to 2.0.7 and now everything is different. The old thrift client library (which was explained in detail in another entry of this blog) is now deprecated and a new CQL (Cassandra Query Language) client is recommended. This language is much more similar to standard SQL and working with it in java is easier for developers with experience in JDBC.
Another important piece of the portlet was the portletfaces-bridge, the library that made possible the use of JSF 2.0 inside a portlet. In the old entry this library was in alpha state but now it is part of the liferay community. Besides it is bundled with more libraries in a project called liferay faces. Therefore the bridge is now stable and the only feature which is quite new is CDI. The Context Injection was being introduced in the last versions of these libraries.
Finally the liferay portal is updated from 6.0.2 to 6.2 version. It is a less important change because a portlet is standardized enough to move smoothly from one version of liferay to another.
With all the information provided it is easy to understand that the portlet has been practically re-developed. The Cassandra manager (the class that interacts with the NoSQL database) changed from using the old thrift to the new CQL library. All the beans use the new CDI technology. And finally everything were updated to the new versions. There were also some changes because liferay (or the portlet bridge) does not support in-line images and constantly throws annoying errors with those types of links (the exception thrown was the same that is commented in this forum entry because the link of a in-line image has a uri of type data:image/png;base64,...). The solution is now using servlets for downloading icons and RDP files (I have re-used this fabulous file servlet coded by balusc). Here it is the link for the netbeans project for the tswebclient2 portlet.
And finally it is needed to change the script used to launch the FreeRDP command. In the past I did a horrible python script that parsed the RDP file and lauched the rdesktop application with the corresponding command line options. Now I have just created a little shell script that only requests the login information (domain, username and password) using zenity. Again it is very improbable and a real solution needs a better launcher. Here it is the freerdp-ask.sh script. Using firefox / iceweasel the script should be chosen to open RDP files (see the following image in which I configured iceweasel to always open those files with the script in the Edit → Preferences → Applications tab).
A video is presented below. A user accesses to the portal using iceweasel in a linux box. The portlet is displayed in the second tab of the portal. The mspaint application is clicked and immediately the script asks for the login information. Once the information is introduced the FreeRDP command is executed against the gateway server. As in the previous entry the nasty shifted cursor issue happens.
This is the last entry of a new series about Remote Desktop or Terminal Services. I tried to improve the previous solution, which was very limited in linux clients, with a new project called FreeRDP. Now the solution seems promising but it is still not ready for a real deployment. It is needed that the FreeRDP project supports RemoteApp feature and understands RDP files flawlessly. (It would be wonderful that the program would open a RDP file without the need of options, domain and username options should be used for gateway and host servers. A way of specifying the password somehow or, at least, requesting it graphically would be nice too).
Remote Regards!
Saturday, May 10. 2014
Updating the old RDP portlet (Part I)
In a very old series of the blog a portlet was developed to manage Remote Desktop Protocol (RDP) applications inside a portal (specifically liferay). The series consisted in two complementary entries, the first one presented the solution using a windows client and the second post used a linux box. The portlet listed some windows applications and, when one of them was clicked, an RDP file was downloaded to be opened by a local RDP program. The windows entry worked perfectly (using the common Remote Desktop Connection or mstsc), but the linux solution was very limited because of the old rdesktop project. At that time it was not very active. Now it seems that it is getting traction again, releasing new versions and acquiring new features more frequently. If you re-check the previous entries some features were important to get a good integration of RDP applications inside a corporate portal.
RemoteApp: feature that displays the windows applications seamlessly inside the local desktop (instead of displaying the whole windows desktop only the selected application window is displayed integrated within the local desktop). This characteristic is basic to not scare the common user.
Gateway: a kind of proxy which wraps the RDP protocol over HTTPS, another basic feature which extends Terminal Services from the intranet to the internet. A necessary feature for avoiding a VPN in the final architecture.
RDP files: The last feature is managing RDP files, any RDP connection can be exported to a text file which can be edited, copied and distributed in an easy way. Indeed the portlet just downloads RDP files in order to be executed by a local application in the user computer.
The rdesktop program supports RemoteApp (but I am not sure if this is supported in a straight way) but it does not manage gateways or RDP files (same situation than in the old linux entry). Nevertheless some weeks ago I realized that there is a new project that deals with RDP: FreeRDP. The project is immature right now but it is improving quickly and, to my surprise, the last version 1.1 (in beta status) gives an initial support to gateway proxies and also understands RDP files. As soon as I notice this I decided to update my old portlet and try to make it work using FreeRDP in linux.
The first step was installing the windows Terminal Services server. I decided to use two 2012R2 servers, one is used as the internal box, session host and broker (win2012int), and the other would have been placed in the DMZ, acting as web access and gateway server (win2012ext). At this point the solution was tested using a windows 7 client from which I accessed the Remote Desktop Web application (another optional element of a TS deployment which exposes some previously configured applications inside an IIS application, it can be said that it is the Microsoft version of my little portlet).
Then the branch 1.1 of the FreeRDP was compiled (debian testing currently provides only version 1.0.2). I followed the instructions of the ifconfig.dk blog.
git clone -b stable-1.1 git://github.com/FreeRDP/FreeRDP.git cd FreeRDP/ cmake -DCMAKE_BUILD_TYPE=Debug -DWITH_SSE2=ON \ -DCMAKE_INSTALL_PREFIX=/home/ricky/apps/FreeRDP -DWITH_DEBUG_ALL=false make make install cd /home/ricky/apps/FreeRDP/bin ./xfreerdp /version This is FreeRDP version 1.1.0-beta1 (git 1.1.0-beta+2013071101-127-g01865)
I tested the resulting command and it worked with the gateway but it had a very nasty issue when using the RemoteApp feature. The window (or the pointer) was shifted (the mouse pointer in the windows application was shifted from the real one in the linux X server). I checked that this issue did not happen when using the gateway with the complete desktop and it did happen when using a RemoteApp without the gateway. So it seems that the problem is only related with the remote applications. I even tried with the master branch (1.2.0-beta1 (git 1.1.0-beta+2013071101-1641-g4da5c) version) and the results were mixed. The gateway did not work (it core dumped with a segmentation fault) and the RemoteApp (without the gateway) did not present the nasty shifted issue but it has problems refreshing the window when menus were popped out. Finally I decided to stay in version 1.1 because the gateway was a basic feature in the solution presented in this entry.
The options of the command are quite complicated (and there are some errors when they are combined with an RDP file), for this reason the following examples are listed.
Launching the complete desktop using normal port 3389 for RDP (not using the gateway):
./xfreerdp /d:DEMO /u:ricky /p:xxxxx \ /v:win2012int.demo.test /cert-ignore
Launching the desktop but using the gateway (the same user is used for the gateway http login and the desktop session):
./xfreerdp /d:DEMO /u:ricky /p:xxxxx /v:win2012int.demo.test \ /g:win2012ext.demo.test /cert-ignore
Launching the mspaint application (previously configured in the collection to be a valid remoteapp) without the gateway:
./xfreerdp -d:DEMO /u:ricky /p:xxxxx /app:"||mspaint" \ /v:win2012int.demo.test /cert-ignore
Launching the mspaint application with the gateway:
./xfreerdp -d:DEMO /u:ricky /p:xxxxx /app:"||mspaint" \ /v:win2012int.demo.test /g:win2012ext.demo.test /cert-ignore
Using an RDP file for mspaint (the file was directly downloaded from the RD web access application). The file does not contain any user or password and, I do not know why, the domain, user and password information should be passed twice, for the gateway and the session. It is like, when using a file, the information is not re-used for both. Besides the domain should be passed as the domain itself and as part of the username options (I think there are errors with those options when using an RDP file). All the rest of the information is read from the file (but there are also problems because, for example, clipboard redirection is not activated although the property redirectclipboard is set and FreeRDP supports it with the +clipboard option in the command line).
./xfreerdp /home/ricky/paint.rdp /d:DEMO /u:"DEMO\ricky" \ /gd:DEMO /gu:"DEMO\ricky" /p:xxxxx /gp:xxxxx /cert-ignore
FreeRDP project is definitely an immature software (at least the features I wanted to use, I did not tested typical intranet features like audio, video or device redirection). I was not able to combine the three desired features (remoteapp, gateway and rdp files) in a reasonable way. The version 1.1 (remember it is now in beta status) has a nasty shift issue and, although it supports RDP files, you still need something to request the domain, user and password and some properties are not parsed completely. I am going to present a little video which shows the last command, how the FreeRDP command is used for interpreting a RDP file obtained from the RD Web Access to launch the mspaint application. As you see the cursor position is shifted (even more when the windows is first displayed than when it is placed back to front).
Although the results are not very satisfactory a second part for this series is on the way. The FreeRDP needs some time to handle the three needed features in a proper way (it is mainly done, there are only minor problems although they are very annoying) but I am going to update my old portlet anyway. It will be nice to work again with liferay, cassandra and the portlet faces bridge. Despite all the previous comments it is great to see another project dealing with RDP in linux. FreeRDP is quickly being improved and there are a lot of contributors working on the project, so I hope all this annoying issues will be fixed before version 1.1 was final.
Stay tuned for the next entry!
Sunday, September 22. 2013
Copy-n-Paste in KVM
A quick entry this time, it is just a tip I had been looking for for a long time. Sometimes I need to use a windows box inside the KVM virtualization of my debian box. I know, I do not like it either, but sometimes you have no other choice. I always complained about the copy-n-paste thing, what I copied inside the virtual windows guest cannot be pasted to my debian host and vice-versa. I always supposed that there should be any solution but I had never found any, although I have to admit that I did not spend much time on it. These last weeks I have had to use the windows guest more continuously and finally I was forced to find a proper solution.
The solution is based on spice, a project to provide a high-quality remote access to QEMU and, therefore, KVM. In theory there are a lot of advantages in using spice instead normal VNC protocol and one of those is the copy-n-paste feature. The steps to provide this functionality between KVM guest and host are more or less explained inside the kvm documentation, but the problem is that the example is for a fedora guest, not windows. My dummy how-to is presented below.
First the spice virtual drivers were installed inside the windows OS. I tried first the spice-guest-tools version 0.59 (the version that is listed in the downloads page) but virtual IO serial device for copy-n-paste hanged (exactly what I wanted to use, you know, Murphy's law). Finally I discovered that there was also a version 0.65 but it is still not listed as a download, and with that one I got it working.
Once the spice tools are installed in the guest box I configured my KVM machine to use spice (using graphical tool, virt-manager). The display was changed from VNC to SPICE.
Then a channel should be added in order to provide the copy-n-paste feature.
After that configuration I checked that the following options had been added to the kvm command line:
- -spice port=5900,addr=127.0.0.1,disable-ticketing
- -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
- -chardev spicevmc,id=charchannel0,name=vdagent
The first one activates the SPICE server. Now you can connect to the host using the spice client:
$ spicec -h localhost -p 5900
But it is not needed cos virt-manager already has an integrated spice client. The other two options are for the copy-n-paste (very weird options indeed). All this options are also explained in the KVM page I linked before.
The last step is booting again the windows guest. At startup time it discovered the new hardware, I selected not to connect to windows update or the internet and then to install the software automatically. The system found the drivers previously installed and chose two of them (the QLX driver for the display and a VirtIO for the character device).
As I explained in the first point I had several problems with the virtIO serial driver for copy-n-paste. It hanged at installation, exactly at this point. After a lot of hangs and reboots it let me replace 0.59 version for the new 0.65 and finally it booted without any issue.
So That is all. I finally has copy-n-paste in my windows guest using KVM and virt-manager. This entry is a little summary of what I did just to remember the next time I need it again. I hope that it helps someone else too.
Cheerio!
Comments