Craig,
Thanks for your instructions on this it did allow me to get a bit further, as Windows has allowed me to map COM5 to the "b" port on the 170, however I keep getting Segmentation Faults in uttsc when the device tries to open the COM Port which causes uttsc to drop my Windows Session.
I have made sure that the device setting are matching the COM port settings that you specified below.
Any ideas?
Thanks,
Joe Toth
Tier 5 Solutions Group
________________________________
From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]
Sent: Thu 10/5/2006 5:00 AM
To: [email protected]
Subject: SunRay-Users Digest, Vol 33, Issue 8
Send SunRay-Users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.filibeto.org/mailman/listinfo/sunray-users
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of SunRay-Users digest..."
Today's Topics:
1. Re: Patch Update Procedures (ottomeister)
2. Re: resetting DTU with PC kbd (ottomeister)
3. Re: Windows Connector SunRay COM Port Mapping Problem
(Craig Bender)
4. Re: Windows Connector SunRay COM Port Mapping Problem
(Craig Bender)
5. Re: Quatech QSU-100 (P.S.M. Swamiji)
----------------------------------------------------------------------
Message: 1
Date: Wed, 4 Oct 2006 17:43:21 -0700
From: ottomeister <[EMAIL PROTECTED]>
Subject: Re: [SunRay-Users] Patch Update Procedures
To: "SunRay-Users mailing list" <[email protected]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 10/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Should we do the primary server first, along with two of the secondary servers,
reboot and do the rest of the servers after testing the patch? Or should we
patch each server one at a time then start the firmware updates after all have
been rebooted?
I would patch one of the secondaries first. Mark it "offline" ('utadm
-f') as far
ahead of the planned downtime as possible so that user sessions naturally
migrate away from it, leaving (hopefully) relatively few sessions to be
kicked off when the time comes. When you're ready to apply the patch turn
off firmware downloads on all of the servers (just like the patch README
says) then apply the patch, reboot and leave the secondary "offline" until
you've tested it and satisified yourself that the patch is solid. (Test it by
utswitch'ing or utselect'ing to this server. The "offline" status should
prevent sessions from being placed there automatically but an explicit
utswitch will place a session there.)
When you're satisfied that the patch is good then mark this server "online"
('utadm -n') and roll through the rest of the secondaries, marking each one
"offline" as soon as you've finished the previous one. Do one at a time over
a period of a few days or weeks. If you let people know what the schedule
for the remaining secondaries is they can plan their migrations around the
schedule, so nobody should have to log out more than twice and nobody
should have to get kicked off at an inconvenient time. When you've done
all of the secondaries you can re-enable firmware downloads (there's no
need to wait for the primary if it doesn't participate in offering firmware)
and then finish up by patching the primary. Try to do that at a quiet time,
because while the primary is down no changes can be made to the Data
Store contents.
Testing the patch firmware is a little tricky. The easiest way is to set up a
private interconnect subnet off a patched standalone test server or off the
first patched secondary and configure firmware downloads for that subnet.
Then you can put the patch firmware into selected Sun Rays by plugging
them into that subnet, then carry them back to the live subnet. If you
can't set aside a subnet like that then you can configure DHCP on the
patched server to deliver firmware updates only to selected DTUs. That's
a more complex process.
OttoM.
__
ottomeister
Disclaimer: These are my opinions. I do not speak for my employer.
------------------------------
Message: 2
Date: Wed, 4 Oct 2006 17:51:15 -0700
From: ottomeister <[EMAIL PROTECTED]>
Subject: Re: [SunRay-Users] resetting DTU with PC kbd
To: "SunRay-Users mailing list" <[email protected]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 10/3/06, Anil <[EMAIL PROTECTED]> wrote:
How is that done? (which combination of keys)
Use Control+Power, just as you would on a Sun keyboard.
If your keyboard doesn't have a Power key (it might have something
that looks like a Power key but really doesn't report as one) then you
can't reset the DTU from the keyboard. You'll have to wait for the
next release, which should include a firmware update that will allow
you to reset the DTU by using a sequence of keystrokes involving
only keys that are present on most PC keyboards.
OttoM.
__
ottomeister
Disclaimer: These are my opinions. I do not speak for my employer.
------------------------------
Message: 3
Date: Wed, 04 Oct 2006 18:00:23 -0700
From: Craig Bender <[EMAIL PROTECTED]>
Subject: Re: [SunRay-Users] Windows Connector SunRay COM Port Mapping
Problem
To: SunRay-Users mailing list <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Hi Joe,
The correct command would be
comport:com1=/tmp/SUNWut/units/IEEE802.00144f2179c7/dev/term/b
Now a couple of things:
I mention using using /dev/term/b because /dev/term/a is not a full
fledged port.
You application should list serial ports and your should see \\tslcient\com1
If your application does not see those ports list you can do the following:
net use com5: \\tsclient\com1
Now you could use com1 or com2 in the net use statement, but those are
most likely physically on your computer. In order to use those via RDP
you would have to disable them in the bios.
Hope that helps.
Joe Toth wrote:
Greetings,
I am working on a pilot deployment of SunRay's and I am having some
trouble getting the COM Ports on a SunRay 170 to map over to an RDP
Session using the SunRay Windows Connector. I have a Topaz Systems
electronic signature pad connected to the SR that I am trying to use
inside of Windows.
The connector starts up without error but the COM port is not available
in Windows.
Here is the command that I am using to start the SunRay connector and
connect it to the Windows Host, which in this case is a Windows XP Pro
machine.
uttsc -m -r comport:1=/tmp/SUNWut/units/IEEE802.00144f2179c7/dev/term/a
192.168.0.XXX
I was hoping that someone could take a look at the command and let me
know if the Syntax is correct to allow this port to be mapped into
Windows XP. I am new to using the SunRay's and I can't seem to find any
examples of the proper usage of this command, as Sun seems to refer to
the COM ports as A and B where in Windows I assume that they should be
showing up as COM 1 and 2. I'm guessing that something in the COM name
or device path is probably incorrect so I hope that someone might be
able to provide an example of what the proper Syntax to map COM1 on a
SunRay 170 as well as using a USB/Serial Adapter on a SunRay 2 to map
COM1 would look like.
Thanks in advance
Joe Toth
Tier 5 Solutions Group
E: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
P: (866) 661-6736
F: (866)-888-4613
------------------------------------------------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
------------------------------
Message: 4
Date: Wed, 04 Oct 2006 20:40:26 -0700
From: Craig Bender <[EMAIL PROTECTED]>
Subject: Re: [SunRay-Users] Windows Connector SunRay COM Port Mapping
Problem
To: SunRay-Users mailing list <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
One more item.
If your program does not programatically set the baud/parity/stop bits,
etc you will need to set your device to 9600, 8, N, 1 to match the
defaults of utseriald.
An example would be a serial printer that defaults from the factory at
19200/8/N/1. Since you can't configure export comports via the control
panel ports util, you have to make the printer match the default of
utseriald.
If you ever have to do this for an Epson Dot Matrix printer, I feel for you.
Craig Bender wrote:
Hi Joe,
The correct command would be
comport:com1=/tmp/SUNWut/units/IEEE802.00144f2179c7/dev/term/b
Now a couple of things:
I mention using using /dev/term/b because /dev/term/a is not a full
fledged port.
You application should list serial ports and your should see
\\tslcient\com1
If your application does not see those ports list you can do the
following:
net use com5: \\tsclient\com1
Now you could use com1 or com2 in the net use statement, but those are
most likely physically on your computer. In order to use those via
RDP you would have to disable them in the bios.
Hope that helps.
Joe Toth wrote:
Greetings,
I am working on a pilot deployment of SunRay's and I am having some
trouble getting the COM Ports on a SunRay 170 to map over to an RDP
Session using the SunRay Windows Connector. I have a Topaz Systems
electronic signature pad connected to the SR that I am trying to use
inside of Windows.
The connector starts up without error but the COM port is not
available in Windows.
Here is the command that I am using to start the SunRay connector and
connect it to the Windows Host, which in this case is a Windows XP
Pro machine.
uttsc -m -r
comport:1=/tmp/SUNWut/units/IEEE802.00144f2179c7/dev/term/a
192.168.0.XXX
I was hoping that someone could take a look at the command and let me
know if the Syntax is correct to allow this port to be mapped into
Windows XP. I am new to using the SunRay's and I can't seem to find
any examples of the proper usage of this command, as Sun seems to
refer to the COM ports as A and B where in Windows I assume that they
should be showing up as COM 1 and 2. I'm guessing that something in
the COM name or device path is probably incorrect so I hope that
someone might be able to provide an example of what the proper Syntax
to map COM1 on a SunRay 170 as well as using a USB/Serial Adapter on
a SunRay 2 to map COM1 would look like.
Thanks in advance
Joe Toth
Tier 5 Solutions Group
E: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
P: (866) 661-6736
F: (866)-888-4613
------------------------------------------------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
------------------------------
Message: 5
Date: Thu, 05 Oct 2006 09:32:56 +0530
From: "P.S.M. Swamiji" <[EMAIL PROTECTED]>
Subject: Re: [SunRay-Users] Quatech QSU-100
To: SunRay-Users mailing list <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Marc Brünink wrote:
Hi all,
after 6 weeks of waiting we got a Quatech QSU-100 (finally). However:
I plugged it into my SunRay 2 and nothing happened. I 'd expect some
devices in /tmp/SUNWut/units/../dev/term/. Am I wrong?
I noticed that this is the new version of the adapter (QSU2-100). This
one supports USB 2.0. So they switched chipsets once more. Anyone got
this working? Any hints?
SRSS only supports the Quatech USB 1.1 units currently.
It won't recognize the Quatech USB 2.0 units at this time.
Thanks
P.S.M.Swamiji
Note:These are my personal opinions , nothing to do with my employer
Many Thanks,
Marc
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
End of SunRay-Users Digest, Vol 33, Issue 8
*******************************************
------------------------------------------------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
