Project News

Over the last month, I have been in heavy development with several projects, one of which is the LAVA project.

I wanted to update my blog and give an overview of some of the things I am doing with Ubuntu:

• LAVA editions: CD, Plus, and Development Editions are pretty much done.
• LAVA Terminal Server
• LAVA LAMP: Apache, PHP, Webmin, ProFTP
• LAVA Secure: Security toolkit CD
• LAVA Share: Fileserver
• LAVA Mailer: Email Platform: Picked Citadel as Exchange replacement.
  

I have worked the last several months outlining the changes for each edition with the specific goal of replacing Window servers in my datacenter as well as a viable desktop for my user's workstations.

I am still open with the Terminal Server. So far I have been able to build a terminal server without LTSP (Linux Terminal Server Project) For my users and customers. I find the LTSP too limiting for serveral reasons. It assumes the client pcs are on the same network.

The client pcs I am servicing are not and therefore, I cannot give them an IP from dhcp or require that they run Linux on their PC.

The whole value of hosting apps or an environment to me, means giving them the app or desktop to any device, anywhere. This means running it without installing anything on their desktop and running it reliable across; Windows, Mac, and Linux.

Phase One:
User Desktop
Using UPX has made this possible by bunding all the required OS dlls, exes, and resources into a single binary that can run without installing. SO I am able to make a client exe that connects to the terminal server and runs the desktop or application. I have been able to build a client exe that rdps into a server, a client exe that ssh into server and runs either app or desktop, and a NX client that connects to freenx on server.

Phase Two:
Picking a Terminal server on Linux.

Solution One: TO X or Not
Linux has always had a terminal server built into it via X. The ability to have remote X served to clients has always been available for as long as X has been around. But making it easy to implement has not been. Using openssh on the backend server and connecting to it from Mac or Windows is easier now. Using opensource products such as JCraft or Xwin makes a connection to an X server easier. With UPX and alittle fine tuning and you can create a connection as well as shrink-wrap it into a single exe that you can distribute to your users without having to configure it and you have a solution that will work for even non-savy computer users.

Solution Two: XRDP
A recent entry into remote hosting is XRDP. Simply put, it makes Linux into a RDP terminal server so your window users do not even need a client. The normal Remote Desktop applet works fine.

MAC uses can use several RDP clients and they work rather well on my IMAC. Without running tests on performance and compression, this solution seems the best and easiest way to implement a terminal server from an IT standpoint as well as from a consumer standpoint. But because the technology is new and because it is based on RDP, I am leaning towards the normal X way of connecting.

Solution Three: FreeNX
FreeNX uses a custom protocol as well as custom client. There are several design problems I see with the current NX implementation.
1) It requires a custom port to be open on firewalls. Corporate America hates this and I hate it cause, my techs would have many calls just regarding connecting to the service. "DO you have XP firewall, Do you have MCAffee or Norton Firewalls installed? Do you know how to disable your firewall? What model Belkin do you have?" - Too much trouble just to make a connection. It needs to be painless.
2) In order to get printers to work the client has to 'SHARE' out their printer via SMB. I really, really hate this, most users do not know how to share out a printer let alone a folder. This also makes printing for MAC users very hard.
3) The custom client has multiple issues with VISTA.

Printing has always been an issue when it comes to remote hosting apps or desktops. Windows, Citrix, X, RDP, and even FreeNX all have somewhat broken ways of managing printing. I have bypassed this problem in two ways.

1) I have used a cups filter on the server to spool print jobs and attach to email which is forward to client. The client prints to the printer and a dialog box pops up asking for email address. They input it once and it remembers it by writing a txt file in the user's home directory. The filter than makes a PDF of the print output and uses sendmail to send to email address. This solution is simple and easy to implement.

Unfortunately it does not work if the user/client is hosting email with you via Evolution or such.

2) Solution two is in the works. It involves building a webservice on the server and serving print output as a pdf file via webdav to client exe which then opens the user's default pdf reader. This solves all the issues but requires some programming on my end for Windows and MAC binary clients. This is a longterm solution.

Selecting the terminal server: I am leaning towards X via SSH but will be testing each out over the next month.

Final Phase.
Building a web portal.
Ultimately I would like the client to download a single exe, possible 5mb. Which will have everything bundled in it, FREENX client or XWIN, SSH, etc. whichever i choose ultimately. It will have everything in the exe that it needs to connect to server farms without installing.

The exe will be a custom web browser using either IE, Mozilla or Safari - depending on the client platform to connect to a website I am designing that will allow the user to login, and serve them apps via txt xml files.

The site will have an admin section where we would create published apps which are stored in MYSQL.

When the client logs in the credentials are sent to OpenLDAP or ActiveDirectory. Their Username and Passwords as well as their group are stored in session variables. The site uses this information to pull the list of published apps the client has been given access to.

The published apps will be links to dynamicall created xml files that will have extensions such as .RDP or .X or .NX

When the client clicks on the links of the apps and the file is served back to the client via apache, the portal application will run either freenx client if it recieves a .NX file or a RDP client if it receives a .RDP file, etc. It then runs the appropriate client I bundled in the exe and makes the connection to the hosted app or desktop.

This way, the portal will really be a portal to apps and desktops both hosted by me or hosted by others.

I am currently writing a version in PHP with LDAP library and it works fine. So far I have the portal service .RDP, .VNC, and .X files. I wanted to do it in Ruby but I am not that efficient yet in the Ruby language. I do most of my web programming in .NET, PHP or Coldfusion. Since I am trying to make my datacenter all opensource, I choose PHP.

There is alot of work still to do, but because of Linux, because of Ubuntu, because of Open Source, it makes all this possible.