csütörtök aug. 25, 2005
hétfő júl. 18, 2005
By csj on júl. 18, 2005
Sun Ray 3.0 introduced some enhancements to the ALP (Appliance Link Protocol) that make Sun Ray thin clients adapt to lower bandwidth scenarios (like connecting to a server on the other side of a WAN link, or through an ADSL line - more about this setup can be found in the Sun Rays at Home white paper).
Last week I did a technology demo at a long time Sun Ray customer who is still using SRSS 2.0 and Solaris 8. I've used my notebook running Nevada build 18 and the SRSS 3.1 public beta (it runs fine - though it's a bit difficult to have the same Solaris instance set up for both SRSS demos and normal office work). Their conclusions were quite interesting:
- they seemed to like JDS
- Hungarian localization of JDS was a great plus (they also made me login with Slovak and Romanian locale, but these weren't completely translated)
- Exchange connectivity of Evolution is something that really started them thinking (some of their thin client users need Citrix licenses only to access Outlook running on a remote Windows Server - obviously there is a chance that utilizing Evolution they would not need to buy additional licenses when the staff grows)
Limiting bandwidth to 512k and showing how audio still worked ("AM radio" quality) while opening windows and browsing directories) was also impressive. It's interesting though how early graphical quality starts to decrease: you don't want to run any application requiring sharp graphics over an 512k link. Gnome terminal really suffered from low bandwidth while xterm and dtterm gives the user much better font quality (obviously gnome-terminal is drawing into offscreen pixmaps to "enhance" performance which in turn decreases it considerably on a Sun Ray remote client).
How to limit the bandwidth of a Sun Ray? There is a DHCP vendor parameter available for some time (I've used it with SRSS 2.0 as well) called NewTBW which can be added to a DHCP macro. The parameter accepts a numeric value which is interpreted as the number of bits allowed to be transmitted in one second to the thin client.
The easiest way to add the parameter to your config is via the GUI DHCP config tool available at /usr/sadm/admin/bin/dhcpmgr. You can also use the CLI:
dhtadm -M -m 192.168.79.0 -e NewTBW=1000000 svcadm restart dhcp-serverThis command limits all thin clients on the 192.168.79.0 network to a maximum bandwidth of 1 million bits/sec at their next DHCP renew interval (or power-on).
Note: low bandwidth is also about latency, so limiting the pipe gives you only one half the impression of a real low bandwidth/WAN setup.
Note2: a bandwidth limit of 1 Mbit/sec was quite acceptable, even with the default JDS look & feel. Medium sized flash animations also worked nice.
szerda máj. 25, 2005
By csj on máj. 25, 2005
A question came up on an internal alias asking how to setup a Sun Ray failover group that is running Solaris 9/Gnome 2.0(.2) if the customer wants to edit Gnome menus in one place. I've setup such a system last year for 300 users and 10 separate Sun Ray servers. I'm copying my answer here for reference.
Step 1: check /etc/gnome/gnome-vfs-2.0/vfolders/applications-all-users.vfolder-info
You will find a number of <ItemDir> tags in the file which tell Gnome where to look for .desktop files that should be included in the menu. Also there is a <DesktopDir> that tells Gnome where to look for the .directory files, which specify the localizations and the icons of each menuitem folder.
Also the file lists all of the folders that are to be displayed in the menu, and assigns a .directory file and a number of categories that should be included in the specified folder.
Step 2: make two directories on a network share called applications and vfolders. Copy all .desktop files from the specified <ItemDir> directories to this new applications directory. Also copy all .directory files from the <DesktopDir> directory to the vfolders directory.
Step 3: now you can edit the file in Step 1 to include only one ItemDir and only one DesktopDir reference: the ones you just created on the network share. If you are brave enough, you can put the applications-all-users.vfolder.info on the network share too and make it a symlink on the Sun Ray servers: this probably works although I've never tried it...
Step 4: customize the files. Do what you like, you can remove .desktop files, rearrange folders, etc.
If you want to add a new application to the menu, you need to create a new .desktop file and put it into the vfolders directory. It will appear in user menus instantly.
The .desktop files that you can create on your desktop with a few mouse clicks have no category assigned to them. Just edit it with a text editor and add a category line like this:
One of the semicolon separated category strings should match one of the category strings specified in the applications-all-users.vfolder-info file for the menu item to appear in a menu folder.
hétfő máj. 23, 2005
By csj on máj. 23, 2005
The title says it all: I'm going to hold a technology demo to a number of IT journalist in the Budapest office this Friday. I've started the preparations today to be sure I have enough time to troubleshoot the setup, but putting it together was very fast. By early afternoon everything was working: a click on the APOC web interface and 30 seconds later the desktop background on a connected Sun Ray 170 changed from default JDS background to the velvet one... Pretty amazing stuff. However, I miss a closer integration between Sun Ray Server Software and APOC. It would be so much fun to provision thin client user desktops not only by the user's identity but also by the location the session is hotdesked to.
Still, I wouldn't have thought a year ago that I will be demoing Sun's desktop products (both software and hardware) running from a notebook. Solaris 10 x86 + Sun Ray 3.1 (currently in alpha) just feels so right...
Anybody interested in a detailed cookbook.txt?
I'm spending my evening writing some XML manifests to convert the installed JES R3 components (directory server, application server) and the web console to the new service management facility. Wish me luck
kedd máj. 17, 2005
By csj on máj. 17, 2005
I first heard about Raymote W\*Admin - an application written by a Slovak company called Unit s.r.o - about two years ago when I asked a question on an internal Sun Ray alias on how to implement different policies for different smart card tokens in a Sun Ray environment. The project I needed the functionality for ended up using custom developed shell scripts and the Controlled Access Mode feature of SRSS. The customer gave up the need to use CAM for one card and a fully authenticated Gnome session for another card - a feature that is still impossible to do with the upcoming Sun Ray 3.1 release, but possible with RayMote since the first day.
About a year ago I've attended a presentation in Bratislava(SK)/Pozsony(HU)/Pressburg(DE) about SNAP - a Sun Ray "solution" developed for the government sector (Sun Rays with Trusted Solaris). Fortunately Unit.sk was also invited to this presentation and they gave us a demo of their technology.
To make it short: in many aspects RayMote is the missing link from Sun's current Sun Ray ("best kept secret") story. If you've ever tried to integrate Sun Ray Server Software into an existing Windows environment, if you've ever tried to get Samba3 authenticate from a Sun Directory server to provide Active Directorish features to Windows standalone PCs (that remain in the migrated Sun Ray environment mainly to run non-thin-client-friendly applications like AutoCAD, or simply to act as media stations capable of writing CDs/DVDs) - then you may find the features of RayMote interesting.
RayMote has a number of components:
- Sun Java Directory Server (LDAP) which stores the users, groups, data about the configuration and user profiles. It can also be used by the customer for other activities (in other words it can be THE directory server of the company) and with the Samba3 integration it can provide Active Directory functinality on the network (or join an existing Windows Domain).
- RayMote core and a number of plugins that are used to implement the policy of the installation. Each plugin enhances the RayMote functionality with a new feature (like PIN authentication, application display through Citrix, application display through rdesktop, etc). Unit also integrated some best of breed open source applications (so CUPS is used for printing, there is an fvwm window manager available that will only give a user a menu with the allowed applications, etc). Some demons are installed on top of Sun Ray Server Software on each of the frontend Sun Ray servers. These provide some of the advanced features like follow-me-printing and are basically there to help enhance the user experience with small modifications. Also the Sun Ray servers are modified to authenticate from LDAP
- An SQL database that is storing events and logs used to generate reports on user activities.
- A web administration interface that completely replaces the current Sun Ray administration interface. It allows you to add applications (called actions - basically a combination of a path to run (either on Windows or on UNIX) a name and an icon... plus some properties) to the system. You can group these applications into user profiles. You can assign profiles to groups and add users to these groups (these will be standard posix groups in Solaris/Linux and Security groups in Windows). If you add a new user through the web interface, it will register a smart card for him (you don't need a token reader: just plug in any smart card into any Sun Ray and the web interface will list it as an unconfigured card that can be added to a new user), it will add it to the LDAP - the user will be visible from Windows, the software creates the home directory and assigns the user to the specified group(s). If the group has a default profile assigned, it will be assigned to the user (so if he's a Marketing employee, and Marketing people get a JDS desktop by default, then he will log into a JDS desktop after authentication). If a card is registered for a user, no other users will be able to login with the card - which is stricter than the default SRSS behaviour, but still most customer I meet find it more natural than the current SRSS "it's just a token and anybody can log in using it" feature.
So, to sum up: from an administration point of view RayMote is a pretty straightforward replacement of the default Sun Ray administration interface. You don't need sysadmins with deep Solaris/Windows/Terminal Services/Sun Ray skills, you don't need to write custom shell scripts to add new users to LDAP. From an integrator's point of view, RayMote eliminates most of the risk associated with a mixed Solaris/Windows/Sun Ray environment. I participated in one particular project that run 4 times longer than it should have because of issues with Samba/Active Directory integration and the application migration (from standalone PCs to centralized Terminal Servers) nightmare. Using Raymote I think we could have finished the project at least 2-3 months earlier.