Tuesday, February 12, 2013

I must be one lucky schmuck

A few years back, I invested in some N computing thin clients, that divvie up a windows xp computer into multiple user desktops, for a couple hundred a pop, and running silently with only 5 watt power consumption.

Fast forward a few years, and microsoft got smart, and updated their user agreement in vista and win7, so that even though the technology works still, you need to buy licenses for each session to stay legal.  They also work with windows server, but you have to choose between regular terminal services, or ncomputing devices, as both wont work together on one server.

LINUX TO THE RESCUE.   It seems that the n computing devices are happy as a clam to work with ubuntu 12.04 64 bit.  I was able to log on from rdp and ncomputing at the same time with no ill effect,  so I wont have to replace my terminals.   They deliver a nice linux desktop environment to each user, totally isolated from the other.

So I will wait until after some scheduled travel, and then bring the 64 bit machine online at work. And go linux on the thin clients.

Saturday, February 9, 2013

3 weeks and no explosions

Biggest accomplishment this week, was figuring out the intracacies of the dymo drivers for linux.   We have at least 3 flavors of dymo printer, but once you get the counterintuitive settings right, its all good.

Also had one document that wouldnt merge right, but it turns out it was something hidden in the document itself as a fresh copy with the same merge words works.

I created some more user accounts, and have had as many as 8 rdp sessions live with no slowdown apparent.   This is with the server also hosting a virtual machine that runs my pacs system.   Got a couple of error messages on one terminal that had admin rights when ubuntu popped up that it wanted to update but overall a very stable environment, stable log ins and log outs.   I even did a few experimental setting things on the main machine that kludged it desktop session, but everything else just kept running, even when I logged in and out of the main administrative account.

I will probably roll out a couple more sessions next week, and then hopefully convert the thin clients over.

3 of the machines are in the lab, pharmacy area, one of the busiest places in the clinic.   No crash, no hiccup.

I also found out that ncomputing now has server software that should work natively in linux, just updated to Ubuntu 12.04, which is what i am running,so I will probably play with that and see if it peacefully coexists with the other rdp sessions.   I know that on a windows server, you have to choose either or..  Rdp, or ncomputing vspace...  It looks like vspace for linux uses lightdm display manager, so I am hopeful.

I am also recreating and documenting my footsteps on a fresh install, to make sure I can replicate this experiment, in an organized straight forward fashion, because there were many dead ends along the way.

If I can figure out a way to have a bogus research database, without real clients,  I might be inclined to put a demo machine online for the curious to log in to.

Friday, February 1, 2013

So why does it work now?

I have a sneaking suspicion, that I just gave up too soon, when a few years back, Avimark seemed to "kind of work" in Linux.  Fully resolving the file addresses across the network is the crux of it.  Initially, I tried running the linux session off of an xp share...  And of course it failed when some files could not be accessed.  Could have been address resolution, file permissions, or both.

A few years of running windows machnes off a linux server gave me some insight into file permissions, file ownership, and file locking.

Some digging into why one method of logging on to a windows share seemed to work, and others didn't was the biggest clue.

It seems that networked machines use any of about 4 methods to resolve a netbios address for the location of a file that is needed.  The linux workstation may run through the 4 methods trying to find the right file in the right place on the network.  You may get lucky if your linux machine has the right choices intalled in the right order, or if not, it may be "close but no cigar".

One clue as to whether your share is resolving the avimark directory correctly is if you display the directory in icon mode rather than list.  If avimark.exe is displaying with the real avimark icon, you are golden.   If not, and it displays with a generic icon, you are only getting partial name resolution for your file, and some of the calls (whiteboard in particular) will hang...looking to access a file that never answers.  I'm sure every windows user has seen this as well when starting a machine, and the avimark icon is generic.  The icon file isnt being found..you are having some sort of communication or disk problem.

Why in the world are there 4 methods?  History...   Way back in the dinosaur ages we found files on a network from a hard coded list.  Later machines on a peer to peer negotiated who kept the list and how it was updated.  Shares periodically broadcasted themselves across the network to all listening.  Later,   You could set one machine to be master, and update, and search only from it...Then we move into different protocols for Server class machines with domains.

You can set your linux machine to use any of these, and even the order in which they are tried when a file is called for,. But alas.. Not all linux distros have for example WINS installed by default...so the whiteboard, across certain network shares will fail.  

THE GOOD NEWS.  It makes much less difference running natively on one machine, and running multiple terminal sessions on that machine.  This gets rid of the futzy network resolution, and gains you the speed of not doing all the database heavy lifting over the network..only the screen and keyboard events cross back and forth.