Suele ser bastante común que algunos blogs tengan entradas patrocinadas, en las que hacen publicidad descarada de productos a cambio de algún tipo de beneficio. En Nolife llegamos más allá, y tendremos no-patrocinación para hablar de no-cosas.

Hoy vamos a hablar sobre la ONG a la que pertenece uno de nuestros no-compañeros (por no decir fundador), llamada "Platos Vacíos Sin Vergüenza".

Continua leyendo "Entrada no-patrocinada: Platos Vacíos Sin Vergüenza"

In a previous entry Remote Desktop Protocol (RDP) was discussed and a custom portlet was presented. The portlet shows some applications (that were previously registered in Microsoft Remote Desktop Services) and it lets the user click any of them to download a RDP connection settings file that silently starts client-side RDP application. The solution was tested on a Windows XP box. Windows and Mac have free Microsoft RDC client application, but Linux is a complete different story.

Rdesktop is the traditional, and I think the only one, open source RDP solution. Until the time I faced that pre-sale I was not aware of the poor status of this project. Last rdesktop 1.6.0 version only supports version 5.2 of the remote desktop protocol and its releases are becoming more and more infrequent (1.6.0 was released in May 2008, 1.5.0 in September 2006, 1.4.1 in May 2005 and so on). The request to support RDP protocol 6.0 was open in the summer of 2007 (a year after 6.0 version was released with Windows Vista) and it is still not assigned. But, you know, this is open source, do not complain and do not wait others to do your job, fix it yourself! Now talking seriously, if somebody has enough time and skills and wants to participate in the never-ending war against Microsoft this is a good project that needs some love.

Coming back to the RDP portlet, Linux only has rdesktop and the portlet must work with it. The main restriction is that this program cannot use TS gateway, so only typical plain RDP (3389 TCP port) communication is possible (remember gateway can use the more secure, easier to integrate HTTPS protocol). This limitation makes absolutely compulsory the use of a VPN in order to establish a secure channel between an internet user and the server. And, of course, 5.2 protocol seems to be more bandwidth-hungry than 6.0/7.0 but nothing can be done with this issue.

Nevertheless seamless remote application was introduced in 1.5.0 rdesktop version. I am not really sure if this feature uses RDP 6.0 protocol or it was done ad hoc but, after all, rdesktop has the -A option to run a remote application. SeamlessRDP extension was a contribution of Cendio to rdesktop in another example of how open source works. This feature needs to install a server side windows program called seamlessrdpshell which is invoked by rdesktop as the alternate shell with the remote application to execute as an argument. For example:

$ rdesktop -A -s "seamlessrdpshell.exe c:\Windows\System32\mspaint.exe"

In my windows 2008 server installation this program was installed under c:\Windows\System32\ directory (this way it is always found in the execution path). Besides the executable was published as a valid TS Remote Aplication with command line parameters enabled (TS Server lets it run with arguments).

Other issue is rdesktop does not understand rdp files (it is just a common linux command with several execution options). Some other graphical applications (like tsclient) can parse rdp files and call rdesktop accordingly but none of them (at least I could not find anyone) understands the seamless rdp integration (-A option). So I had to code a little python example that reads the rdp file and transforms the file tags into rdesktop options (plaease do not blame me, I already know there is room for improvement). The script needs two minor changes in the generated rdp file (now the alternate shell is specified with the full path to the application and the username is also supplied) but it still works for Microsoft client. Here it is a wordpad.rdp example. Finally the password to rdesktop invocation is hardcoded inside the script (I have commented the script is improvable, haven't I?).

With all the commented limitations the portlet solution is ready to be executed in linux. Now when the application link is clicked the downloaded rdp file will be executed by the python script, which will run rdesktop with the seamless application option. The video is very similar to the presented in the previous entry but with Debian as OS and firefox/iceweasel as browser. If you see when rdesktop is launched the usual windows login page is presented, automatically fulfilled, and then it disappears, the reason is rdesktop does not have Network Level Authentication (new feature of 6.1 version of the protocol).



In summary, this time linux solution is less practical (internet access needs a VPN, a better RDP file parser would be necessary in a real deployment and some bandwidth improvements are lost) but thinking in a global solition, I mean, a solution for all type of clients, is always a good thing and, this way, nobody will say I did not try it.

Keep the faith!

La publicidad muchas veces intenta convencer de que el cielo es rojo, de que los perfumes dan la felicidad o las galletas caseras arreglan familias rotas. Por suerte, en Nologin no tenemos que recurrir a trucos como el que se ve en este video, tan..., representativo de la realidad.

Today another entry about changes in the blog. First I have decided to add some information about myself in the left part. The previous weekend I requested my facebook account to be deleted, I did not use it. So I will try to post some personal entries from time to time and maybe make the blog a place where I can contact some distant friends (but of course this does not depend on me). This decision does not affect the usual topics which I want to keep on publishing. Second, this blog installation does not send any email to me (maybe I can discuss this issue with my company mates but I am afraid it is for some security reasons), so I have also added the last comments plugin in the left frame. This way I quickly know when someone has made one.

Cheers!

Hay dos maneras de hacer negocios: resolviendo problemas o necesidades, y creando problemas o necesidades. A veces la separación entre resolver y crear es realmente estrecha porque la mayoría de los usuarios no tienen conciencia del problema al que se han acostumbrado. Los usuarios no saben lo bien que les vendría tener dientes nuevos porque se han acostumbrado a los viejos. Y allí entra un buen comercial, uno mejor que Coco, por supuesto:

At the end of 2009 I participated in a pre-sale involving a portal migration in a governmental environment. The portal had some content management, portlets and an uncommon feature: citrix. This customer worked in a quite special way, their employees usually were out of their own installations but they needed regular access to some internal applications. The problem was part of these programs were very old dos/windows desktop applications which could not be easily moved to the web (customer had upgraded some to new web technologies but a lot of them still worked following this old-fashioned way). The portal used an old version of Citrix XenApp to place these old windows applications the customer really needed inside the portal. Besides that, typical requirements in a portal developing were demanded (sso, cms, eye-candy,...). An one more thing, customer wanted to change citrix for other solution and themselves also talked about the new features of windows Terminal Services.

Remote Desktop Protocol or RDP is a proprietary protocol developed by Microsoft to provide graphical interface access from one computer to another remote one. This technology is also known as Terminal Services because of the former name of Microsoft RDP server software (now called Remote Desktop Services or RDS). Windows 2008R2 introduced the new 7.0 version of the protocol at the end of the last year but the main improvements were done in the jump between 5.2 and 6.0/6.1 versions. Let's summarize the changes:

• Version 6.0 (November 2006 - Windows Vista):
  
  
  • Terminal Services Remote Applications. Remote Programs are a feature of Windows Server Terminal Services that lets client computers connect to a remote computer and execute programs that are installed on it instead of the complete windows desktop. The experience is the same as running a program that is installed on the local computer. An administrator must first publish the programs for end-users to access them.
    
  • Terminal Services Gateway servers. TS Gateway server is a type of gateway that enables authorized users to connect to remote computers on a corporate network. TS Gateway uses RDP together with HTTPS protocol to help create a more secure, encrypted connection. A TS Gateway server uses port 443 and transmits data through a Secure Sockets Layer (SSL) tunnel. TS Gateway opens usual RDP intranet solution up to the world wide web.
    
  • Improved bandwidth tuning for RDP clients.
  
  
• Version 6.1 (February 2008 - Windows Server 2008):
  
  
  • Terminal Services Web Access. TS Web Access is a service that makes Windows Server programs (TS RemoteApp) available to users from a Web browser. TS Web Acces is a kind of application inside IIS that lets user start remote applications from a web browser. This feature is not a protocol improvement but a new feature of the windows server and client.
    
  • Network level server authentication. Technology that requires the user to authenticate himself before a session is established with the server. Originally the server loaded the login screen for the remote user, this used up resources on the server, and was a potential area for denial of service attacks.
  
  
• Version 7.0 (October 2009 - Windows Server 2008R2 and Windows 7):
  
  
  • Web Single Sign-On (SSO) and Web forms-based authentication. Web SSO makes sure that after a user is logged on, no additional passwords are required for RD Gateway, RD Web Access, RD Session Host servers and RemoteApp programs.
    
  • Multiple improvements in bandwidth (aero glass composed desktop support, smooth fonts, audio and video redirection).
    
  • Multiple features to Virtual Desktop Infrastructure or VDI integration (virtual desktops and pools).

So now RDP alone accomplishes all common client requirements. Remote Applications gives to the user a seamless desktop integration, TS Gateway moves RDP and Remote Applications to the internet, Web Access moves again RDP to the web and finally it seems there have been several bandwidth improvements to make a better experience (Microsoft published a good whitepaper about RDP bandwidth when 6.1 version was released).

Now the main problem is how to integrate RDP inside a portal. The easiest way is just using the TS Web Access inside an iframe (the same technique I used in the sudoku entry to show you the html design). Liferay for example has an IFrame portlet that lets you point the portlet region to another page (TS Web Access server in our case), integrating TS web application easily in your portal. But, in my opinion, TS Web Access is not the best option because it works using an ActiveX element which directly bans any OS different than Windows, any web browser different than internet explorer, any RDP client different than windows Remote Desktop Connection (RDC).

As always my solution is maybe more complex but I am sure it is more open and funny. Based on the fact that RDP connection settings can be saved in a RDP file (this way these files can be easily edited, copied, and distributed), my idea is developing a little portlet which shows to the user the remote applications configured and, when clicked, a generated rdp file is downloaded to be executed by local remote desktop client. This way the solution works in any system that has a RDP compatible application. Microsoft has free Remote Desktop Connection 7.0 for windows OSes and Microsoft Remote Desktop Connection 2.0.1 Client for Mac (it supports RDP 6.0). In a similar way I did with Skype, browser can be configured to open rdp files (application/x-rdp mime type) with the selected client-side application. Linux and other *nix OSes are another question and I will try to face this problem in a future post.

The solution is a simple JSF 2.0 portlet (deployed on liferay 6.0.2) that uses cassandra as repository to store the application data (remember I already commented this to you in a previous entry about cassandra database). Portlet implementation saves the complete rdp file (the same that is generated and exported from TS Remote Administration application) in the database. When you click the application link the rdp file is fetched from cassandra and downloaded to the client.

This time the video shows the following: on the right a Windows 2008 60-day evaluation version configured as TS Server; on the left my Windows XP with RDC 7.0 installed; using IE8 I access to liferay and search for Notepad application; after clicking on it the rdp file is downloaded from my portlet and the browser asks to open it; accepting the offer RDC client remotely opens Notepad; when a simple text file is saved on administrator desktop it can be shown on windows 2008 server. Take into account I could not install 2008R2 (cos Microsoft only distributes 64 bit version and my laptop is i386), so the server only supports protocol version 6.1. This version lacks new SSO features and TS client application does not ask for user and password cos I locally saved my credentials before and it is reusing them.



Clearly notepad is a useless program but integrating this kind of remote applications can be very very important in some environments (legacy applications, programs with expensive licenses, binaries with local limited access,...). RDP protocol and its new features open up a lot of new possibilities and portlet integration makes its management easier for end users.

Finally I want to point out the use of cassandra as repository and portletfaces bridge as portlet/JSF 2.0 joint. I already stated the worth of the first one in the commented cassandra entry but I had never talked about the second piece of software. Neil Griffin heads this java project to create a portlet bridge for the new JSF 2.0 specification. I used alpha 1 version in my skype/pidgin VoIP solution and alpha 3 in this TS portlet, and I have to mention the outstanding progress. Good job Neil!

Cuando uno es usuario o cliente de lo que sea (desde un restaurante o una tienda a una ventanilla pública o una consultoría), se siente demasiadas veces como el comensal del chiste de Coco...

En Nologin sabemos lo que es eso y por eso nos adaptamos a las necesidades de nuestros clientes, para que ellos no se tengan que adaptar a nosotros que bastante tienen con lo suyo. Y eso hemos intentado transmitir con nuestra nueva página web, en la que confiamos que encontréis lo que necesitáis. Si no es así, no dudéis en poneros en contacto con nosotros.

Si trabajas administrando sistemas, es posible que te hayas encontrado en la tesitura de tener que acceder a la consola de administración de algún dispositivo a través de un túnel SSH, redirigiendo algún puerto de la máquina de destino a otro local. Al hacer esto, puedes encontrarte con la circunstancia de que la aplicación a la que estás accediendo tiene referencias estáticas a su IP real, lo cual provoca que no puedas acceder correctamente a ella.

Si este es tu caso, y estás utilizando GNU/Linux, puedes hacer uso de iptables para salvar el escollo. Por ejemplo con

iptables -t nat -A OUTPUT -p tcp --dport 9000 -j DNAT --to 127.0.0.1:9000

estaríamos redigiriendo todo el tráfico saliente hacia el puerto 9000, al mismo puerto en nuestra máquina local.