Hi Guys,
In our environment, our security office requires us to use static DHCP
and put Sunrays that reside different buildings on different subnets.
Don't ask:) We are allowed to configure our two SRSS servers to run with
IPs on the remote subnets so that we can serve SRSS and DHCP to the
various subnets. At the moment I serve three subnets from three
physical NIC cards on my Sunfire V490s with no problems (ce0, ce1, and
hme0). Failover works because I configure each Sunray with two
different static IP addresses (one on each SRSS server). I just received
a new requirement to serve 2 Sunrays in a remote building that have to
be on yet another subnet. Rather than adding another physical NIC card
to my system to serve two Sunrays, I decided to setup a virtual NIC
instead:
%utadm -a hme0:1
I configured this virtual NIC to have a 138.109.207.133 IP address and
to serve 138.109.207.134 to 138.109.207.249.
The problem is that DHCP does not seem to work from my virtual
interface. I use dhcpmgr to manage my pools of IP addresses and lock
them in statically to the Sunrays MAC addresses, but for some reason I
cannot serve out to this subnet on my virtual interface. Does DHCP not
work from virtual interfaces? Is there anything published by Sun
addressing this?
I can go grab another NIC card and install it, but if the number of
subnets continues to grow, I will soon run out of PCI slots and have to
buy another two servers. Any ideas?
Thanks,
Brian Whyte
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, May 31, 2007 5:05
To: [email protected]
Subject: SunRay-Users Digest, Vol 40, Issue 48
Send SunRay-Users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://node1.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. SunRay "blank squares" on screen update. (Brian Knoblauch)
2. Re: SRWC 1.1 bug (Trevor Dell)
3. RE: Soft Ray client? (LeBar, Russell J)
4. Re: DTUs resetting constantly (Curtis Cunningham)
5. Re: DTUs resetting constantly (Craig Bender)
----------------------------------------------------------------------
Message: 1
Date: Wed, 30 May 2007 08:43:38 -0400
From: Brian Knoblauch <[EMAIL PROTECTED]>
Subject: [SunRay-Users] SunRay "blank squares" on screen update.
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain
Well, I finally made my way out to the client site with a cable
tester. Went around and found which SunRays were listed in utcapture as
dropping packets, etc. Unfortunately, that doesn't appear to be my
problem.
The SunRays that were dropping packets are NOT the SunRays
showing the screen refresh issues. The SunRays that ARE having the
screen refresh issue don't appear to have any packet loss issues! Note
that my problems are ONLY with StarOffice too.
Perhaps the question is best posted on a StarOffice user's group
:-)
Thanks!
--
Brian Knoblauch, ITSS
DoX Systems, LLC
4625 West Bancroft Street
Toledo, OH 43615-3945
419-654-1607
http://www.doxsystems.com
------------------------------
Message: 2
Date: Wed, 30 May 2007 09:50:51 -0600
From: Trevor Dell <[EMAIL PROTECTED]>
Subject: Re: [SunRay-Users] SRWC 1.1 bug
To: SunRay-Users mailing list <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Just got a reply..
"The bug id is 6563015.
Engineering still working on it, I don't have a ETA for a T-patch or IDR
right now."
- Trev
Cuny, David wrote:
Do you have an ETA on a fix or a bug number? I just got my first
customer complaint on this issue and it has jumped up in priority.
------------------------------
Message: 3
Date: Wed, 30 May 2007 11:40:08 -0500
From: "LeBar, Russell J" <[EMAIL PROTECTED]>
Subject: RE: [SunRay-Users] Soft Ray client?
To: SunRay-Users mailing list <[email protected]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
-----Original Message-----
From: The Fat Bloke
If I understand correctly, Trev is right.
SGD is licensed by concurrent user.
So you could buy, in this example, 25-50 SGD licenses, which
are shared amongst your 500 potential users.
Yes, but if you want users to be able to connect to the same session
whether running SRSS or SGD then you either have to have them always use
a SGD session or use SRSS and SGD as a jumping off point to get to the
real session on a different server which would typically imply RDP and
Windows Terminal Services. Since that would not apply to the environment
I am in we would have to go with the first option which means a license
for every user.
Thanks for the reminder though, it's easy to forget the difference in
licensing between the two products.
-- Russ
------------------------------
Message: 4
Date: Wed, 30 May 2007 14:11:54 -0700
From: Curtis Cunningham <[EMAIL PROTECTED]>
Subject: Re: [SunRay-Users] DTUs resetting constantly
To: [EMAIL PROTECTED], SunRay-Users mailing list
<[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
http://node1.filibeto.org/pipermail/sunray-users/attachments/20070530/8a
39b18a/attachment-0001.htm
------------------------------
Message: 5
Date: Wed, 30 May 2007 14:32:02 -0700
From: Craig Bender <[EMAIL PROTECTED]>
Subject: Re: [SunRay-Users] DTUs resetting constantly
To: SunRay-Users mailing list <[email protected]>
Cc: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Another thing to check is that you have enabled TS (Control Panel,
Add/Remove, Windows Components) and are not just using the default admin
RDP connections that allow for only two connections. This would result
in each DTU stealing the last connection and would duplicate your
symptoms exactly.
Curtis Cunningham wrote:
Daniel,
do you definitely have your CAM script set to critical?
Curtis.
Daniel Doby wrote:
I am setting it up in CAM config mode, with a custom
script to point the user to their desktop (vmware
windows xp instance). I have also setup a new script
to do exactly what you say and just start an xterm
window and it still resets.
By resetting, here is what I see. I power on the DTU,
it gets an IP address from the DHCP server, gets it's
configuration, then starts whatever session is thinks
it should start (uttsc or the pre-outlined xterm
window). No matter what the script calls to do, it
starts it then about 3-5 seconds later (regardless if
you do anything or not) it resets, and does the DHCP
all over again (basically like from power-on).
I did fix it, by rebooting the Sun Ray Server itself,
but it has done this in the past (previously thought
it was the script) so I am sure it will happen again
in a few days.
Any ideas what could be causing the issue though?
--- Curtis Cunningham <[EMAIL PROTECTED]>
wrote:
Daniel ..
are you setup in a CAM configuration with a script
that starts ttatsc to
point at a WTS server? Your email would imply that.
You also say you
constantly get the WTS login screen and then it
resets. Please confirm.
If this is not what you see, please describe exactly
what you see from
power on of the DTU. What's the last OSD icon you
see before the reset?
i.e. is it getting DHCP address, finding Sun Ray
server, connecting, etc.
Are you running a CAM script? If so, make a new
script for CAM mode that
just launches an xterm. Start that script and if you
get the xterm as
expected, try executing the previous problem CAM
script (that makes
connection to WTS using ttatsc) from the command
line inside the xterm
and see what failure you get.
Curtis.
Daniel Doby wrote:
Anyone have any experience with the SunRay DTU's
constantly resetting? Everything was working fine
this
morning, I was testing out some USB hot plugging
and
after I disconnected my current session (uttsc
session) and the DTU recycled, came back to
windows
login screen and reset. It's been doing that ever
since. I did a utrestart -c and now all of them
are
resetting (just three test).
It's done this several times before and each time
we
thought it was just our script to control where
the
user's session is directed, but if I put
/usr/openwin/bin/xterm at the top of the script
before
it actually does anything else, it still
resets(and
resets, etc, etc).
Any ideas? I am wondering if our DHCP setup isn't
the
culprit. We are using our regular desktop dhcp
server
with the option 49 set to the ip address of our
sunray
server, which is running dhcp, just not leasing
out
the ip addresses to the DTUs.
While I am sure it's something minute and an
oversight
for our implementation, but I have yet to pinpoint
the
cause.
Daniel
________________________________________________________________________
____________
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html
_______________________________________________
SunRay-Users mailing list
[email protected]
http://node1.filibeto.org/mailman/listinfo/sunray-users
--
Desktop Technical Specialist
Sun Microsystems
accessline: (310) 464-6289
internal: 41621
_______________________________________________
SunRay-Users mailing list
[email protected]
http://node1.filibeto.org/mailman/listinfo/sunray-users
________________________________________________________________________
____________Looking for a deal? Find great prices on flights and hotels
with Yahoo! FareChase.
http://farechase.yahoo.com/
_______________________________________________
SunRay-Users mailing list
[email protected]
http://node1.filibeto.org/mailman/listinfo/sunray-users
--
Desktop Technical Specialist
Sun Microsystems
accessline: (310) 464-6289
internal: 41621
------------------------------------------------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://node1.filibeto.org/mailman/listinfo/sunray-users
------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://node1.filibeto.org/mailman/listinfo/sunray-users
End of SunRay-Users Digest, Vol 40, Issue 48
********************************************
_______________________________________________
SunRay-Users mailing list
[email protected]
http://node1.filibeto.org/mailman/listinfo/sunray-users
