[SunRay-Users] SunRay and backing store
We have a problem where with some applications the graphics windows aren't refreshed on the SunRay display. I am running RedHat Linux. I found the following recommended fix for RedHat Linux on the internet: *** Problem In X-windows one is opening sessions on other computer and/or is working with programs such as DAMM, gf3 or PAW one expiences a serious problem. If an other window is moved over the window containing the graph, the graph is wiped out. Similar things happen when on minimizes the windows. For REDHAT-LINUX In Redhat Linux some things are done differently to get things right one should first check which display manager one is running. On the NSL machines running Redhat gdm is the default display manager. The changes to make the backing store work one has to do the following changes: In the file /etc/X11/gdm/gdm.conf the following section has to be changed from: [servers] 0=Standard to: 0=Standard +bs ** After a reboot the problem still exists. Then I see that patch 124388-01 addresses the issue of backing store cannot be enabled on linux. I haven't installed the patch yet, and I will, but I need to know if in addition to installing the patch, is modifying gdm.conf enough? Since if I understand correctly, Xnewt is spawned from gdm. Or is there some other file where Xnewt is executed where I need to give Xnewt the enable backing store option? Thanks, Suzanna . ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users
RE: [SunRay-Users] Multihead on non-failover group
Thank you for the input Bob. In regards to the work around I mentioned below, I first delete the multihead group from the server then I get the login screen on the secondary and after attaching the keyboard mouse to the secondary I can login and run utswitch. Works for so long as the secondary isn't powercycled. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Doolittle Sent: Monday, July 16, 2007 2:53 PM To: SunRay-Users mailing list Subject: Re: [SunRay-Users] Multihead on non-failover group Bemis, Suzanna K wrote: I have a Solaris Sunray Server on the same LAN as a Linux Sunray Server with the Solaris Sunray Server acting as the dhcp server too. They are not in failover. There are many multihead groups configured on the Solaris Server which I've configured on the Linux Server too. These multiheads are configured using Sunray 1's and 1G's. When a user switches from the Solaris server to the Linux server by any means possible, i.e. utswitch, utselect (Enter Server), the primary sunray switches to the Linux server but the secondary doesn't. Yes, this is by design to protect people against roaming multihead groups among FOGs with potentially inconsistent multihead configurations. You could imagine forwarding a multihead group to a FOG without a multihead configuration - you'd wind up with secondary heads (typically with no keyboards) showing greeter sessions (i.e. individual sessions of their own) that were inaccessible. This was considered sufficiently unpleasant to warrant defeating multihead roaming entirely, back in the days when we were first experimenting with roaming between FOGs. Work around is done by plugging a keyboard/mouse into the secondary and running utswitch, etc to get to the Linux server. I don't see how this can work, if you have the same multihead configuration everywhere. Secondary heads will merely show the wait for primary icon and you won't be able to run utswitch or anything else on them. I'm afraid there is no workaround for this situation, sorry. I suppose if you had the new 4.0 manual configuration firmware you could change the server list to the destination group, but that would be very cumbersome and possibly risky (a typo would prevent the Sun Ray from connecting anywhere until somebody intervened). We do have an RFE (6581172) open and if there was sufficient customer (or sales) interest we could implement it in a future release. What has been considered is to allow multihead groups to carry their own configuration information along with them when roaming between FOGs, and use it in preference to any local configuration (or lack thereof). This would avoid inconsistencies in multihead configuration in remote FOGs. -Bob Whenever the secondary sunray server is power cycled or the Linux server is rebooted, then the secondary goes back to the Solaris Server. I realize that if I broke up the addresses for DHCP and assigned IP's from the Linux sunray server to the secondary sunray's I'd get multihead on the Linux sunray server, but what if I wanted then to go back to the Solaris sunray server at that workstation? I've tried changing macros in the dhcpmgr on the Solaris server but that seems to break the authentication all together. 'utmhadm -a' command on the Linux sunray server indicates secondaryMAC not in admin database, but 'utdesktop' says it is. I deleted the utmhadm group and readded it, then it doesn't complain about not in admin database. Point is I want to maintain both the Solaris Sunray Server and Linux Sunray Server in non-failover but be able to switch back and forth between Solaris and Linux depending on user. Would AMGH help at all? I will be deploying SunRay 2fs's soon, and they work great in the multihead capacity, but in the meantime I need the 1's and 1G's to be flexible. Thanks, Suzie -- -- ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users
[SunRay-Users] Gnome or KDE with Linux Sunray Server?
Sun Ray Server Software requires it's own Sun Ray-enhanced GDM, but we still have the choice to run gnome or KDE. We want to limit users to one or the other as we do not want to have to support both gnome and KDE. We're on a tight schedule, and come from the CDE world so we don't have much knowledge of either. It's either gnome or KDE - no other options are on the table. We run RHEL4/U5. First question: Is there a way to disable one or the other so users can't get to it? Second question: In all of your expert opinions which is the better environment for use with the Sun Rays? (We customize menus and lockdown all desktop/screensaver/timeout type stuff) Third question: What is Sun's current support/compatability with KDE like? Fourth question: Is linux kiosk supported with gnome? KDE? Thank you, Suzanna ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://node1.filibeto.org/mailman/listinfo/sunray-users
RE: [SunRay-Users] Blacklisting users after several failed login attempts
Okay I took the line out of the pam.d/gdm and it's in system-auth right before pam_unix.so. I can lock my screen and come back in with no problem, and a tail on the /var/log/secure file prints out the debug basically writing out the contents of the pam_abl.conf file, then PAM_RHOST is NULL, and Checking user skbemis, and finally In Cleanup, err is 2000. When I try to login with a new sunray session, I still get Authentication Failed and cannot login, and there is no debug in the /var/log/secure file indicating where the problem is. When I remove the line from the system-auth file, everything works normally. Yes, I created the /var/lib/abl directory, and it is empty and remains empty even with the failed login attempts. And when I run the pam_abl command with the config file I get the contents of the pam_abl.conf file and the last two lines state Failed users: (blank), and Failed hosts: (blank). Perhaps I need to move this topic to another users group. I was just hoping someone in the SunRay users community would have either used pam_abl or have another method to blacklist. Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ottomeister Sent: Monday, June 04, 2007 9:16 PM To: SunRay-Users mailing list Subject: Re: [SunRay-Users] Blacklisting users after several failed login attempts On 6/4/07, Bemis, Suzanna K [EMAIL PROTECTED] wrote: I'm trying to use pam_abl right now and even a correct password is getting an Authentication Failed on a login attempt from the sunray. I'm not exactly sure in which pam module to insert the following line: auth required /lib/security/pam_abl.so config=/etc/security/pam_abl.conf So, I've put it in both the gdm and system-auth files in /etc/pam.d ... I've never used pam_abl but based on reading its documentation you should put that line into pam.d/system-auth, immediately above the auth sufficient /lib/security/$ISA/pam_unix.so ... line. The pam.d/gdm file executes the 'system-auth auth' stack by using the pam_stack module so if you put pam_abl into both places it will be executed twice. That probably means that it will count each login attempt twice. ... and I get Authentication Failed on all login attempts with a correct password. The pam_abl.conf file is the default one I got with the source. Did you create the directory /var/lib/abl where the config file tells the pam_abl module to place its user_db and host_db databases? What does the pam_abl command show when you run it with this config file? OttoM. __ ottomeister Disclaimer: These are my opinions. I do not speak for my employer. ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://node1.filibeto.org/mailman/listinfo/sunray-users ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://node1.filibeto.org/mailman/listinfo/sunray-users
RE: [SunRay-Users] Blacklisting users after several failed login attempts
I was able to get pam_abl to work when I try to ssh to my server from another server on the network. I was able to blacklist (lock the account) of a user after so many attempts to login with the incorrect password. So I know the implementation of pam_abl works. However, I still get Authentication Failed when I attempt to login at a sunray AND at the console with CORRECT username and password. I narrowed it down to gdm-2.4.4.7.2 which is installed with sunray services 3.1.1 and 4. When I removed sunray services and gdm-2.4.4.7.2-12 and reinstalled the gdm-2.6.0.5-7, I was able to login at the console with my regular user account. When I again installed sunray services and the required installation of gdm-2.4.4.7.2, I was back to the Authentication Failed at the console and could not login until I removed the pam_abl.so call from system-auth. Are there any plans to make sunray service compatible with a newer version of gdm? Thanks, Suzanna -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neal A. Lucier Sent: Tuesday, June 05, 2007 1:09 PM To: SunRay-Users mailing list Subject: Re: [SunRay-Users] Blacklisting users after several failed login attempts Bemis, Suzanna K wrote: Perhaps I need to move this topic to another users group. I was just hoping someone in the SunRay users community would have either used pam_abl or have another method to blacklist. I'm not entirely sure what you mean by blacklist, but various authentication sources have an Account Lockout feature where after n failed password attempts in j minutes the account is locked for m minutes or until an admin resets it. Sun's LDAP server is one such authentication source which can implement this. Neal ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://node1.filibeto.org/mailman/listinfo/sunray-users ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://node1.filibeto.org/mailman/listinfo/sunray-users
[SunRay-Users] Blacklisting users after several failed login attempts
Anyone have any information on how to blacklist users after 5 failed login attempts? I'm trying to use pam_abl right now and even a correct password is getting an Authentication Failed on a login attempt from the sunray. I'm not exactly sure in which pam module to insert the following line: auth required /lib/security/pam_abl.so config=/etc/security/pam_abl.conf So, I've put it in both the gdm and system-auth files in /etc/pam.d and I get Authentication Failed on all login attempts with a correct password. The pam_abl.conf file is the default one I got with the source. I turned on debug and no messages are printed in /var/log/secure after the failed attempt. Once I comment out the above line, I log in with no problem. Thanks, Suzie ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://node1.filibeto.org/mailman/listinfo/sunray-users
RE: [SunRay-Users] Utselect between solaris and linux not working
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Doolittle Sent: Thursday, February 22, 2007 3:05 PM To: SunRay-Users mailing list Subject: Re: [SunRay-Users] Utselect between solaris and linux not working It certainly looks to me like your network is flaky. Hopefully it's an artifact tickled by the multicast functionality, which will resolve itself once you change to broadcast... -Bob I unconfigured the sunray services on ndssr01 'utadm -r' and 'utconfig -u' and reran the 'utconfig' and 'utadm -a hme0' and still no 'U' between ndssr01 and pablo/skb-linux. I went ahead and upgraded to SRSS 3.1 on ndssr01 and it still wouldn't see skb-linux or pablo on the 192.1681.32.0 network with utgstatus. I physically moved pablo into the same room where ndssr01 is located, physically connected ndssr01 and pablo (192.168.132.0) via a crossover cable and got the 'U' between the two. Then I connected both to a 5-port linksys switch and used the 192.168.132.0 network to uplink it to the rest of the network. I was able to switch between the ndssr01 and pablo on the sunray's after that. Still couldn't see 'U' for skb-linux which is still in another room. Definitely a network issue. I assumed because the auth.props has enableMulticast=true commented out, that that implies enableMulticast=false. But not the case. I explicitly set enableMulticast=false on all three and now ALL computers see and switch between each other. Thanks for all your help Bob, OttoM, and Craig!! On to the next issue in another email to come. Suzie ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://node1.filibeto.org/mailman/listinfo/sunray-users
[SunRay-Users] Utswitch session behavior
I have two servers in failover group both running Solaris 9, SRSS2.0. I 'utswitch' or 'utselect' from SR server #1 to SR server #2 and when I log out of #2 (completely exit the session) I get sent right back to my session on #1. I want that same behavior for my two servers that don't run in failover mode. One is a Solaris 9, SRSS 3.1, and one is a RedHat Linux Ent 4, SRSS 3.1.1. What's happening is when I run 'utswitch -h linuxserver' on the Solaris machine, and get the new session on the linux machine I find the only way back to the Solaris session is a power cycle of my sunray, or 'utswitch' back to the solaris. Do they have to be in failover or is there another configuration I'm missing? Thanks Suzie ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://node1.filibeto.org/mailman/listinfo/sunray-users
RE: [SunRay-Users] Utselect between solaris and linux not working
This is going to be a problem, once you get things working smoothly. Unless you take special measures it'll be a roll of the dice as to what server you'll connect to. I recommend you follow OttoM's suggestion to revert to an Interconnect config (although I disagree with several of his statements, cockroaches notwithstanding, regarding the severity of using '-A' - it'll work fine for redirecting *between* FOGs, which is what I believe you care about and I verified this both by re-reading the code and trying it myself). An Interconnect config will work if you want to be able to redirect within a FOG also, and it allows you to use the primary hostname/IP when redirecting, so it's preferable. Get this working first. To avoid the die-roll sending you to the Linux boxes, you have a few options. - Just disable/shutdown DHCP on the Linux boxes after getting utadm set up the way you want it. Since the solaris box will offer DHCP the DTUs will be told to connect to it initially. This is your simplest option. - Use AMGH. This would allow you to configure your systems to send specific users where you want them. If you have some folks you want to be using Linux, and some not, this will make things seamless for you. You can specify the behavior per-Sun Ray, per-smartcard, per-user, or whatever works best for you. - Configure DHCP individually for each MAC, on both servers, to specify where you want each Sun Ray to go. Sounds painful, not your first option but I mention it for completeness. Your first step is to just get things working to a point where utswitch redirects work, without introducing any new variables. Then you can experiment with the options above to get more control over where the DTUs are connecting. -Bob I'll hopefully get some time to take ndssr01 down this weekend and reconfigure as per Bob's and OttoM's emails. In the meantime, and I wasn't making changes to anything, but I ran utgstatus on ndssr01 and got this (notice pablo's status on the 192.168.132.0 interface): bash-2.05# /opt/SUNWut/sbin/utgstatus host flagsinterface flagsinterface flags 134.222.187.0/24 192.168.132.0/24 ------ ndssr01 TN134.222.187.208 UA-192.168.132.1 UA- pablo -N134.222.187.81 UA-192.168.132.2 UAM skb-linux -N134.222.187.182 UA-192.168.132.3 -AM So I ran into the other office where there's a sunray connected to ndssr01, signed on thinking I'd try the utswitch to pablo, but ran utgstatus first and got this: bash-2.05# /opt/SUNWut/sbin/utgstatus host flagsinterface flagsinterface flags 134.222.187.0/24 192.168.132.0/24 ------ ndssr01 TN134.222.187.208 UA-192.168.132.1 UA- pablo -N134.222.187.81 UA-192.168.132.2 -AM skb-linux -N134.222.187.182 UA-192.168.132.3 -AM I don't know what happened in those few moments, but ndssr01 saw pablo as 'U' and then not. Suzie ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users
RE: [SunRay-Users] Utselect between solaris and linux not working
mask ff00 bcast c0a884ff lastpkt 600 sessions 0 idles 0 load 0.0 endhosts Connection to localhost closed by foreign host. OUTPUT of 'telnet localhost 7010;gstatus' from SKB-LINUX [EMAIL PROTECTED] sunray]# telnet localhost 7010 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. gstatus numhosts 5 host skb-linux lastseen 18 timeoff 0 addr 86debbb6 numifs 2 period 20 starttime 1172071839 ROUTER LAN_OK TRUSTED interface eth0 ip 86debbb6 mask ff00 bcast 86debbff lastpkt 18 LAN interface eth2 ip c0a88403 mask ff00 bcast c0a884ff lastpkt 18 sessions 1 idles 0 load 0.0 host pablo lastseen 2 timeoff -131 addr 86debb51 numifs 2 period 20 starttime 1172072364 ROUTER LAN_OK interface eth1 ip c0a88402 mask ff00 bcast c0a884ff lastpkt 2 interface eth0 ip 86debb51 mask ff00 bcast 86debbff lastpkt 2 LAN sessions 1 idles 0 load 0.0 host ndssr01 lastseen 3 timeoff 291 addr 86debbd0 numifs 2 period 20 starttime 1172070004 LAN_OK interface eri0 ip 86debbd0 mask ff00 bcast 86debbff lastpkt 3 LAN interface hme0 ip c0a88401 mask ff00 bcast c0a884ff lastpkt 723 LAN sessions 155 idles 62 load 0.4 endhosts Connection closed by foreign host. Thanks, - Suzanna Bemis, Suzanna K wrote: When I bring up 'utselect' gui on the solaris 9 machine I don't expect to see the names of the linux servers. I enter the name of either linux server in the Enter server field and nothing happens at all. No error messages no switching. When I type in 'utswitch -h linuxhost' again nothing happens. No error messages it just returns to the command line. I have all network interfaces in the /etc/hosts files of all three computers and again I don't get any error messages so name resolution is not an issue. The same symptoms, nothing, when I try the the utselect and utswitch from the linux to the solaris 9. 'utgstatus' on Solaris 9 (ndssr01): host flagsinterface flagsinterface flags 134.222.187.0/24 192.168.132.0/24 ------ ndssr01 TN134.222.187.208 U--192.168.132.1 U-- skb-linux -N134.222.187.182 U--192.168.132.3 -AM pablo -N134.222.187.81 U--192.168.132.2 -AM 'utgstatus' on linux (skb-linux): host flagsinterface flagsinterface flags 134.222.187.0/24 192.168.132.0/24 ------ skb-linux TN134.222.187.182 U--192.168.132.3 UAM pablo -N134.222.187.81 U--192.168.132.2 UAM ndssr01 -N134.222.187.208 U--192.168.132.1 --- Pablo is the other linux box. Utswitch and utselect work between linux boxes. Thanks, Suzie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Doolittle Sent: Tuesday, February 20, 2007 6:30 AM To: SunRay-Users mailing list Subject: Re: [SunRay-Users] Utselect between solaris and linux not working Note that utselect will *never* display hosts outside of the local FOG, is this perhaps what you are seeing? You can run it with the -R option to get a text-input field where you can type a server name, but that's the most you can do to deal with extra-FOG hosts - you can't get a chooser that lists hosts outside of your local FOG. It works fine between any OS platforms. I do this almost daily (although I use utswitch directly, which utselect also uses). -Bob ottomeister wrote: On 2/19/07, Bemis, Suzanna K [EMAIL PROTECTED] wrote: I have SRSS 3.1.1 on 2 Linux sunray servers (pablo and skb-linux) and SRSS 2.0 on Solaris 9 (ndssr01). 'utselect' won't work between a Linux SR server and the solaris 9 server ... In what way doesn't it work? (What do you see when you run it, how do you interact with it, what happens then?) Does it not work in both directions or only in one? What does 'utgstatus' show on these machines? On which of the networks that show in 'utgstatus' is the Sun Ray unit located? Does 'utswitch -h servername' work? OttoM. __ ottomeister Disclaimer: These are my opnions. I do not speak for my employer. ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users ___ SunRay-Users
RE: [SunRay-Users] Utselect between solaris and linux not working
I think so too. But I don't see a problem with using -A, what problem do you see? Craig is right that she'll have to use the 192.* addresses instead of the public IP addresses, however. Is this what you were referring to? That's the one advantage to using the Interconnect - it will translate the public IP to the appropriate private one internally. I strongly suspect that Suzanna never restarted SRSS after utadm -L on, otherwise we'd see U for all interfaces on all networks. I ran 'utadm -L on' followed by 'utrestart' on all computers. Last one was on ndssr01 and in fact users this morning were asking who's pablo? So when the utrestart on ndssr01 happened the sunray users lost the connection to 'ndssr01', and 'pablo' appeared on their sunray's. I had to disconnect the 192.168.132.0 network cable from pablo and skb-linux so ndssr01 would be the default. It's good to know that we could run the linux sunray servers, but the point is I need some users to know about the linux servers and use them, but I don't want ALL users to. We're still testing the linux environment in general. Craig asked earilier to try 'utswitch -h 192.168.132.3' on ndssr01 - same result as 'utswitch -h skb-linux' - it went to a 25D and showed 134.222.187.182. And, in answer to OttoM about the private network - 192.168.132.0 is only used for the sunray's. Administration, Internet, etc is done on the 134.222.187.0 network. So what might the 'utadm -A' option do that the 'utadm -a' didn't? All we have on the 192.168.132.0 network are sunray's and these three sunray servers. If you have questions about how the network is set up and routed from a physical perspective I can't answer any of those questions myself but if you tell me what to ask the Networking group I can do that much. All I can say is that I don't want to get an entire new LAN for the linux sunray servers because the infrastructure costs would be more than it's worth. Thanks again and still - Suzie -Bob Craig -- why do you think it isn't an isolated interconnect? Suzanna -- is this 192.168.132.0 supposed to be reachable from the rest of your network, or is it supposed to be a private isolated subnet? OttoM. __ ottomeister Disclaimer: These are my opinions. I do not speak for my employer. ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users
