So a follow up to our lockup issue. We added an iptable rule to RHEL5 and it seems to have cleared things up.
-A RH-Firewall-1-INPUT -s xxx.xxx.xxx.xxx -p tcp -m tcp --sport 3389 -j ACCEPT where xxx.xxx.xxx.xxx is the IP of the Win2008r2 remote server. We added this after the rule that allows related/established connections. This effectively works as a keep-alive. Which prompts me to ask if keepalive was changed in rdesktop 1.7? Since this has only been in about a week, I am still monitoring. We have not replaced rdesktop 1.6 with 1.7 yet. We are going one thing at a time. thanks for the input! /paul On Tue, Sep 27, 2011 at 11:04 PM, Craig Bender <[email protected]>wrote: > Mud, yeah. Still not clear where the portmapper runs. There's no reason > for the printer name as mapped to windows should ever change. You should > have a utaction set to update the default printer for the user on the Sun > Ray session. The name should never change as far the user or Windows is > concerned as it's just a pass-through. This is really just follow-me > printing that's been done forever. > > > > On 9/27/11 6:29 PM, Paul Whitener wrote: > >> Hi Craig, >> >> Our print setup is simply a function of the rdesktop command line. When >> you login to Rhel5, we use an .Xclient script to launch rdesktop in full >> screen with printers being passed on the command line. Every user gets >> the same command line. They login to Win2008 and it then launches the >> medical application the doctors use. >> >> We noticed that when we tried to use uttsc and kiosk mode, the >> portmapper file would have the printers set on one set of ports. When a >> card was pulled and reinserted on a different DTU, the ports in the file >> changed, causing the printers to have different numbers associated with >> them. So for example, on first card insert a printer in the list may >> look like laserjet(3). When the card is moved to a different DTU and >> the user prints again, the printer may say laserjet(7). It also would >> not always print. We do not see this behavior with rdesktop. >> >> But now we see occasional lockups as I mentioned. >> >> Clear as mud huh? >> >> /paul >> >> On Tue, Sep 27, 2011 at 9:46 AM, Craig Bender <[email protected] >> <mailto:Craig.Bender@oracle.**com <[email protected]>>> wrote: >> >> Can you clarify what you mean by port mapper? Are you talking about >> follow me printing? >> >> >> On 9/27/11 6:43 AM, Paul Whitener wrote: >> >> Thanks Peter! I will check it out! >> >> On Tue, Sep 27, 2011 at 8:31 AM, Peter Åstrand >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> >> >> I have a RHEL5 server with 4GB ram running SRSS 5.1. We >> have >> about 10 users across 15 DTUs. We "were" using uttsc to >> connect to a remote (states >> away) Win2008R2 termserver that once logged in pushes a >> single >> app. We >> found that when a user pulled their card to move to >> another DTU, the >> portmapper in RHEL5 changed the printer ports from the >> original >> session used to new ports. This caused printers not to >> redirect >> to the new session >> correctly and caused all kind of print fun for the >> users! If >> they did >> redirect, the "printer number" changed and the this >> confused the >> users. >> >> So we moved to using RHEL5's rdesktop implementation. >> It does >> not seem to >> have issues with the mapper and the session and printers >> stay >> statefull. >> Printers work great. However, as DTU usage has >> increased with >> students in >> full session, we are seeing lockups on the DTUs. The >> lockups >> seem to be >> random. We can not pin it to any one operation done on the >> Win2008R2 >> server. Interestingly enough, if the user goes to a >> laptop and >> pulls the >> rdesktop session to it, the session unfreezes and they can >> work. They then pull it back to the DTUs and continue. >> >> >> Are you running rdesktop in full screen mode, or in a >> window? RHEL5 >> ships with rdesktop 1.6.0, which does not work very well >> with 2008 >> R2. I suggest that you try rdesktop 1.7.0 instead. If the >> problem >> persists, try a "strace" on the rdesktop process. That >> should give you >> a clue about what's going on. >> >> Best regards, --- >> Peter Åstrand ThinLinc Chief Developer >> Cendio AB http://www.cendio.com >> Wallenbergs gata 4 >> 583 30 Linköping Phone: +46-13-21 46 00 >> <tel:%2B46-13-21%2046%2000> >> <tel:%2B46-13-21%2046%2000> >> >> >> >> >> ______________________________**___________________ >> SunRay-Users mailing list >> [email protected] >> <mailto:SunRay-Users@filibeto.**org<[email protected]> >> > >> >> http://www.filibeto.org/__**mailman/listinfo/sunray-users<http://www.filibeto.org/__mailman/listinfo/sunray-users> >> >> <http://www.filibeto.org/**mailman/listinfo/sunray-users<http://www.filibeto.org/mailman/listinfo/sunray-users> >> > >> >> ______________________________**___________________ >> SunRay-Users mailing list >> [email protected] >> <mailto:SunRay-Users@filibeto.**org<[email protected]> >> > >> >> http://www.filibeto.org/__**mailman/listinfo/sunray-users<http://www.filibeto.org/__mailman/listinfo/sunray-users> >> >> >> <http://www.filibeto.org/**mailman/listinfo/sunray-users<http://www.filibeto.org/mailman/listinfo/sunray-users> >> > >> >> >> >> >> ______________________________**_________________ >> SunRay-Users mailing list >> [email protected] >> http://www.filibeto.org/**mailman/listinfo/sunray-users<http://www.filibeto.org/mailman/listinfo/sunray-users> >> > ______________________________**_________________ > SunRay-Users mailing list > [email protected] > http://www.filibeto.org/**mailman/listinfo/sunray-users<http://www.filibeto.org/mailman/listinfo/sunray-users> >
_______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
