We wish to organize our Linux server as follows: UD3 will serve a share to Windows network clients for running OpenInsight. At the same time, the Linux box will provide OIL through LTSP (that's terminal services in the Linux world) to direct-connected terminals.

We would like the OIL installation to use the same repository and application files as the Windows copy, so that there is really only one version of the application to maintain. A couple of years ago, BobC said that separate copies of OI could share Repository files "because UD3 supports virtual directory paths."

Is there any more information which will help us to accomplish this with our Linux server?

Thanks,

Gerald

Hi Gerald

Indeed I have used the same repository with Windows and OIL

Approach 1 - SAMBA share required

The trick is to simply copy your entire OI for windows installation atop the Linux OI repository,

then have the windows clients access OI via the SAMBA share. Test your locking with this.

Approach 2 - No SAMBA needed, use UD3 virtual directories

Linux data server ( assume servername=maira)

 UD3 daemon running

 LH3Srvc.ini 

     share named REVBOOT,  points to /var/opt/openinsight

     share named APPDATA, points to  /var/opt/appdata

/opt/openinsight/bin

  Standard install

/var/opt/openinsight

  Standard install

  Add a revparam with   

  ServerOnly=1

  Servername=maira

  TcpIpPort= 19993

  NamedPipeName=None

  ShareName=REVBOOT

/var/opt/openinsight

  Add a revparam with   

  ServerOnly=1

  Servername=maira

  TcpIpPort= 19993

  NamedPipeName=None

  ShareName=APPDATA

Windows server (assume servername=tartaros)

\revsoft\openinsight721

    Standard install, UD3.x driver

    remove all .OV, .LK files

    note: keep the .dbt files

    add a revparam which points to the REVBOOT share on the linux server

  ServerOnly=1

  Servername=maira

  TcpIpPort= 19993

  NamedPipeName=None

  ShareName=REVBOOT

\revsoft\openinsight\appdata

    Nothing here except a revparam

which points to the APPDATA share on the linux server

  ServerOnly=1

  Servername=maira

  TcpIpPort= 19993

  NamedPipeName=None

  ShareName=APPDATA

In Windows, attach the data as \revsoft\openinsight\appdata In Linux attach the data as /var/opt/appdata

The data and repository will be the same for each system.

The binaries will be different

The dbt's will be different. You need to attach, save in windows and again in Linux henver you change the default set of tables or rebuild all indexes on a table.

Locking will work.

Hope this helps

Bob C,

Great! My able assistant will be back Monday to work on this. Once the problems with glibc in Fedora Core 5 are addressed, we'll be up and running, I'm sure.

Gerald

Bob C,

Approach 2 assumes the existence of a Windows server, so I guess that approach 1 is the likely candidate.

You mention the problem of having different .dbt files for Linux and Windows, which must be resynchronized if index files are rebuilt (or if new data volumes are added). The ATLAS index rebuilding routine recreates index files without the file rename and consequent .dbt invalidation. Also, my program will create missing .dbt files when a data volume is attached. Since Linux and Windows would be looking in different places for the .dbt, volumes created in Windows would get a new .dbt in Linux with the first login, and vice versa; at least in theory. I am looking forward to testing this and demonstrating that it will work.

Gerald

I think that if you do the samba share and the UD3 you can even get away with a single dbt.

BTW, if you are using a Linux thin-client solution such as LTSP or NoMachine Nx or FreeNx, do you need to use the OI windows binaries?

Also, FWIW I believe that you can install FreeNx on the server and the No Machine client on all the windows workstations.

Bob,

I am unfamiliar with FreeNx and NoMachine, so this is news. VNC I know about. I have LTSP terminals ($50 each, want some?), but I am expecting my customers to have Windows PCs at the desktop. Right now OIL is not running on Fedora Core 5, so using OIL is a moot point at least temporarily. LTSP is generally configured to run in a private subnet on a separate NIC – i.e., 192.168.2.nnn on eth1, where the LAN is 192.168.1.nnn on eth0 of the Linux box. This could be reconfigured to run on eth0 if the DHCP in Linux is set to non-authoritative. (Don't think I know any of this stuff – my able helper explains it all.)

Knowing these details, our goal is to respond to Linux logins with terminal sessions from the internet. Since we will not be booting dumb terminals, LTSP is not needed. Configuration is easier with LTSP though, so it will be installed and used in case the customer wants dummy terminals. The basic idea is to provide WAN connection to OI through OIL in terminal sessions, LAN connections through SAMBA, and local terminals through LTSP.

What I have seen of Fedora Core 5 says the free, stable Linux desktop/server is finally here. My able helper is gone 'til Monday though, so I'll post an update of our progress then.

Gerald

No Machine NX sounds like exactly what you want.

It similar to terminal server – connections can com in across the web, each connection gets its own virtual machine. OpenInsight runs on it.

The NoMachine server is not free, the noMachine client is free. There are Linux and Windows clients.

FreeNx is an open source version of the server, which I am told (have not tested it) is compatible with the client.

As far as stable desktop environments go, My impression is that the debian distro's are doing well there. They seem to have concluded that RedHat has sewn up the server market, so they are aiming the desktop. We have great luck with some of these:

Xandros

Linspire

Knoppix

SUSE

Ubunto and

Gentoo are other popular distros - I am not sure we have tested those.

The Fedora Core 5 problem was a surprise. We work great on FC4.

Redhat changed the default locations for some components and there is a (from our perspective) broken dependency on some libraries which were present in FC4. I think the fix requires re-working the RPM installer, rather than any major change to OIL itself.

fwiw, things seem to be fine on the Debian based distros, and with Gnome. Full regression and detailed testing hasn't been done, but general usage has not brought up anything.

Also, Ubuntu comes with a nice remote access client, can't recall it's name right now. Does VNC and terminal server access through the same client.

Ubuntu's become the personal machine at this developer's home, for anyone who cares about what's being used.

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Which release/flavor of Ubuntu? When Fedora Core 4 was released, Ubuntu was not yet up to speed. I would be glad to revisit this OS flavor now.

Latest and greatest.

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

<img src=http://www.sprezzatura.com/zz.gif"

Thanks. I'll put the able assistant on that Monday.

I am an idiot w/ respect to real programming, but my Able Assistant hints that adding 'BuildRequires: glibc-kernheaders' when compiling a package will cause version dependency. He doubts that reorganizing the RPMs will fix this issue.

Meanwhile, what is the likelihood of OIL working with FC5 by July 1, when I am supposed to start shipping systems?

Gerald,

It is in the queue, but I would not expect it to be solved by July 1st. There are a number of other distros, including FC4 that OIL runs in.

Cheers,

Kevin

View this thread on the Works forum...