Re: [SunRay-Users] THINGS WORKING! Re: more help needed - Advice: Sunray on Solaris 11/SPARC with private interconnect
Dear Jim, jimkli...@cos.ru said: > Well, the default route like any other can come from announcements. > Text-file-based overrides for the in.routed process can also be in / > etc/gateways and maybe in /etc/inet/static-routes or somesuch. Yes, my entry is in /etc/inet/static_routes so that is one mystery solved. jimkli...@cos.ru said: > svcprop '*' | grep '192.168.199.1' That produced some interesting output... I changed the numbers and then just did the svcprop '*' bit and it ends with... svc:/system/config-user:default/:properties/tm_proppat_nt_configured_user_login/type astring astring svcprop: Unexpected libscf error: object has been deleted. Exiting. root@wiked:/etc# So, I am now presuming I have something else broken somewhere I wonder if it might be related to my SunRay experiments? Any thoughts? I have not yet "re-run" my SunRay installation on a fresh BE from an earlier milestone in my experiments as I have been marking resit exam papers and assignments all day :-( Dave Price ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users
Re: [SunRay-Users] THINGS WORKING! Re: more help needed - Advice: Sunray on Solaris 11/SPARC with private interconnect
Default route on S11 can be specified via the -p (persistent) option to the route command, rather than via the defaultrouter file. This should have nothing to do with adapting utadm to S11, however. It's true that much of the underlying configuration for the network is now in SMF properties, but we provide more reasonable UIs for the common configuration options. Another important change is that /etc/nodename is now gone, in favor of the 'hostname' command which now persistently stores the hostname as - you guessed it, an SMF property. -Bob On 08/24/12 12:09, Jim Klimov wrote: 2012-08-24 12:09, Dave Price wrote: and I have RIP running on the router and that has led to other routes being learnt too. I am fairly sure that the defauly route is fixed statically but I have not yet spotted where it is. It is certainly not in /etc/defaultrouter as that simply does not exist. I will dig about a bit more. Well, the default route like any other can come from announcements. Text-file-based overrides for the in.routed process can also be in /etc/gateways and maybe in /etc/inet/static-routes or somesuch. For Solaris 11's way of moving basic things into SMF (now reminds of Windows registry in a bad way), you can try running svcprop '*' | grep '192.168.199.1' (obvisously, grepping for your suspected default router) - this should list SMF properties of ALL services, finding the one you need if it is at all there. HTH, //Jim ___ 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
Re: [SunRay-Users] THINGS WORKING! Re: more help needed - Advice: Sunray on Solaris 11/SPARC with private interconnect
2012-08-24 12:09, Dave Price wrote: and I have RIP running on the router and that has led to other routes being learnt too. I am fairly sure that the defauly route is fixed statically but I have not yet spotted where it is. It is certainly not in /etc/defaultrouter as that simply does not exist. I will dig about a bit more. Well, the default route like any other can come from announcements. Text-file-based overrides for the in.routed process can also be in /etc/gateways and maybe in /etc/inet/static-routes or somesuch. For Solaris 11's way of moving basic things into SMF (now reminds of Windows registry in a bad way), you can try running svcprop '*' | grep '192.168.199.1' (obvisously, grepping for your suspected default router) - this should list SMF properties of ALL services, finding the one you need if it is at all there. HTH, //Jim ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users
Re: [SunRay-Users] THINGS WORKING! Re: more help needed - Advice: Sunray on Solaris 11/SPARC with private interconnect
Dear Craig and All, Adding to my earlier posting, the sequence of events that led me to get things working *had* left LAN service on. So, this morning I ran utadm -l Off and I am delighted to report that after cold restarting SunRay services it is still serving my private interconnect just fine... craig.ben...@oracle.com said: > Did the vendor class tags get inserted into DHCP macros? I think it has... === root@wiked:/etc# dhtadm -P NameTypeValue == 192.168.199.0 Macro :Include=SunRay-net1:Subnet=255.255.255.0:FWSrvr=192.168.199.7:Intf="net1":Broadcst=192.168.199.255:MTU=1500:Router=192.168.199.7:NewTVer="11.0.1.0_05_2012.05.29.21.30": SunRay-net1 Macro :Include=SunRay:AuthSrvr=192.168.199.7:AltAuth=192.168.199.7: SunRay Macro :LeaseTim=86400:LeaseNeg:AuthPort=7009:LogHost=193.60.11.7:LogKern=6:LogNet=6:LogUSB=6:LogVid=6:LogAppl=6: wiked Macro :Include=Locale:Timeserv=193.60.11.7:LeaseTim=86400:LeaseNeg:DNSdmain="dcs.aber.ac.uk":DNSserv=193.60.11.252 193.60.11.253: Locale Macro :UTCoffst=0: BarrierLevelSymbol Vendor=SUNW.NewT.SUNW,36,NUMBER,4,1 NewTFlags Symbol Vendor=SUNW.NewT.SUNW,34,NUMBER,4,1 IntfSymbol Vendor=SUNW.NewT.SUNW,33,ASCII,1,0 FWSrvr Symbol Vendor=SUNW.NewT.SUNW,31,IP,1,1 LogAppl Symbol Vendor=SUNW.NewT.SUNW,29,NUMBER,1,1 LogVid Symbol Vendor=SUNW.NewT.SUNW,28,NUMBER,1,1 LogUSB Symbol Vendor=SUNW.NewT.SUNW,27,NUMBER,1,1 LogNet Symbol Vendor=SUNW.NewT.SUNW,26,NUMBER,1,1 LogKern Symbol Vendor=SUNW.NewT.SUNW,25,NUMBER,1,1 LogHost Symbol Vendor=SUNW.NewT.SUNW,24,IP,1,1 NewTBW Symbol Vendor=SUNW.NewT.SUNW,30,NUMBER,4,1 NewTVer Symbol Vendor=SUNW.NewT.SUNW,23,ASCII,1,0 AuthPortSymbol Vendor=SUNW.NewT.SUNW,22,NUMBER,2,1 AltAuth Symbol Vendor=SUNW.NewT.SUNW,35,IP,1,0 AuthSrvrSymbol Vendor=SUNW.NewT.SUNW,21,IP,1,1 root@wiked:/etc# == which to me looks very close to what I see on my old Solaris 10 SunRay private interconnect connection. Here's my output of utadm -x root@wiked:/etc# /opt/SUNWut/sbin/utadm -x begin general allowlanconnection=false serviceonline=true end begin interface interface=net1 hostname=wiked-net1 ip=192.168.199.7 network=192.168.199.0 netmask=255.255.255.0 broadcast=192.168.199.255 end root@wiked:/etc# So, I think I may have things working o.k.? Do folks agree? My reason for going against the LAN option, as I said before, is that we have always seen various "performance" issues with SunRay screens refreshing and so what I am trying to do is to eliminate any network factors by having the SunRay traffic, and only the SunRay traffic all running in one isolated network. SunRay not leaking to other and others not leaking traffic to the SunRays. To make sure this was happening, I re-rigged five SunRays and the interface to the Solaris 11 SunRay server on to a new, completely isolated network swicth this morning and that's working fine. We normally run 40 SunRays fed from two T5140s. I have not yet added the "set hires_tick=1" entry to /etc/system. I presume that will still work in Solaris 11?? These are used by students doing software development and/or learning to use Unix. So, some usage is low demand command line tools (editors, awk, sed, shell scripting an fso on) and other usage is more demanding software development, typically Netbeans being used to develop C and/or C++ code etc. I would be *VERY* interested to hear from other people using a SunRay service in this way and whether or not you have experienced problems with "slow interactive response" in tools like netbeans or web browsers etc. So, I am now going to backtrack to an earlier BE and see if I can again recreate what I have working now but with less random steps :-) Thanks, folks. Dave Price ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users
Re: [SunRay-Users] THINGS WORKING! Re: more help needed - Advice: Sunray on Solaris 11/SPARC with private interconnect
Dear Craig,
I hve just come back into work and am glancing through your reply.
I'll answer a few things now, based on what I have, and then I'll
answer more when I run again from a new BE from
a milestore or so back.
craig.ben...@oracle.com said:
> You would have had to have at least created /etc/hostname. and /
> etc/defaultrouter as those aren't part of S11 anymore and also, was
> this an interface you had already plumbed up?
I definitely did not create a file called /etc/defaultrouter at all
and indeed, checking that is not there.
I used a text installer from DVD to install Solaris 11 and
I set a fixed IP address for net0 as part of that process and
the IP address of the router as reached via the net0 interface.
netstat -rn
shows a proper line for "default". I do have
root@wiked:/etc# !svcs
svcs | grep rou
online 19:55:30 svc:/network/routing-setup:default
online 19:55:33 svc:/network/routing/route:default
online 19:55:41 svc:/network/routing/ndp:default
root@wiked:/etc#
and I have RIP running on the router and that has led to other
routes being learnt too. I am fairly sure that the defauly
route is fixed statically but I have not yet spotted where it
is. It is certainly not in /etc/defaultrouter
as that simply does not exist. I will dig about
a bit more.
At various points I did create
/etc/hostname. for both net0 and net1, but if my brain remembers
correctly, I finally removed the net1 version. Also, as part
of my sequence (when earlier I tried to use utam -A), I had used ipadm
to manually configure and indeed give an IP address to net1. I removed at least
some of that before use utm -a, but I probably would effectively
have at least left net1 plumbed in, but via my ipadm
command not via using ifconfig.
craig.ben...@oracle.com said:
> Did the vendor class tags get inserted into DHCP macros?
Not sure, I will check that shortly.
craig.ben...@oracle.com said:
> Part of a private interface is that it starts with a unplumbed NIC.
> Which is why utadm -a takes an interface arg. utadm -A can look a lot
> like private interconnect but it's for a subnet, not a NIC. There
> are several other differences, but NIC vs Subnet is one of the
> largest.
I did of course try -A first, but that would not
let me have an easy way to set up DHCP things it seemed.
I then later tried utadm -a so I may have a bit of a hybrid...
craig.ben...@oracle.com said:
> -A is not considered a private interconnect. It's a LAN based
> interconnect with the ability to serve DHCP vendor class tags for many
> different (even non-local) subnets with DHCP Helpers on routers.
I believe my -A "broke" the final thing that I did get to run
was utadm -a 192.168.199.0 and that eventually
asked all the setup questions re DHCP and firmware
servers and so on and seemed to them work.
craig.ben...@oracle.com said:
> Basic networking config, prior to S11, was done through files. No
> longer the case, and one of the reasons utadm -a is broken. So if you
> really created a private interconnect, you'd would have had to use
> dladm/ipadm to manually configure the NIC.
Yes, I did definitely make some use of ip[adm in an active way
but I did not directly use dladm.
craig.ben...@oracle.com said:
> Another observation/question. It sounds like will have multiple DHCP
> servers on the same segment? At least that's how I understood your
> range comment.
> Is that true?
> If so, how are you preventing PC's from using the Sun Ray Server's
> DHCP and vice versa?
There will be two on 192.168.199.0 on the two SunRay servers
each allocated a slice of the IP range each (one gets 16 -> 19
and the other gets 80-143). We do NOT have any devices other
than the SunRays and the interfaces to the two SunRay
server machines on 192.168.199.0. I am hoping (but I must check)
that the SunRay server will NOT attempt to hand out those, or any
other IP addresses, on the SunRay servers other IP interfaces.
As I commented before, we normally bring up three interfaces (0,2,3)
leading to mixed networks of servers and personal computers etc
and just use net1 to lead to the other SunRay server and the SunRays themslves.
craig.ben...@oracle.com said:
> I can tell you why it work would, even if a Sun Ray gets an address
> the other server, it's because when the Sun Ray didn't get all of the
> info it needed to connect, so it sent out a DHCPInform request, which
> the DHCP Server on the Sun Ray answered (even it if didn't provide
> the IP address). You'd actually see this via utquery. You'd have
> two different values for DHCP server and DHCPInform server. The
> default of -A is not to offer IP addresses.
Well, all I can say is that my "test" SunRay definitely got
given an IP{ address from the range allocated by me
on the new SunRay server last night (the other server uses
different addresses as noted above) and the test SunRay then
loaded firmware etc and after various reboot type events latched
onto th
Re: [SunRay-Users] THINGS WORKING! Re: more help needed - Advice: Sunray on Solaris 11/SPARC with private interconnect
Scratch the first part, won't make a difference it you created those files. I mistook utadm -a looking for them vs creating them. It creates them (duh! which is why you start with an unplumbed NIC). Those files have no Use in S11 and have been replaced by dladm/ipadm. Regardless, a lot of work. LAN based is the way to go. If you really need private interconnects while running S11, you'll have to hack away with current release. On Aug 23, 2012, at 12:27 PM, Craig Bender wrote: > Hi Dave, > > You would have had to have at least created /etc/hostname. and > /etc/defaultrouter as those aren't part of S11 anymore and also, was this an > interface you had already plumbed up? > > Did the vendor class tags get inserted into DHCP macros? > > Part of a private interface is that it starts with a unplumbed NIC. Which is > why utadm -a takes an interface arg. utadm -A can look a lot like private > interconnect but it's for a subnet, not a NIC. There are several other > differences, but NIC vs Subnet is one of the largest. > > -A is not considered a private interconnect. It's a LAN based interconnect > with the ability to serve DHCP vendor class tags for many different (even > non-local) subnets with DHCP Helpers on routers. > > Basic networking config, prior to S11, was done through files. No longer the > case, and one of the reasons utadm -a is broken. So if you really created a > private interconnect, you'd would have had to use dladm/ipadm to manually > configure the NIC. > > > Another observation/question. It sounds like will have multiple DHCP servers > on the same segment? At least that's how I understood your range comment. > > Is that true? > > If so, how are you preventing PC's from using the Sun Ray Server's DHCP and > vice versa? > > I can tell you why it work would, even if a Sun Ray gets an address the other > server, it's because when the Sun Ray didn't get all of the info it needed to > connect, so it sent out a DHCPInform request, which the DHCP Server on the > Sun Ray answered (even it if didn't provide the IP address). You'd actually > see this via utquery. You'd have two different values for DHCP server and > DHCPInform server. The default of -A is not to offer IP addresses. > > > If that's how you been used to doing things, then there really is no reason > to do anything but LAN only connections. > > On the DHCP server that was serving the PCs, you could set option 66 > (tftpserver) and point it to the Sun Ray Server. This was you are > provision/controlling the Sun Ray clients from via parameter files. There is > also DHCP option 49, but option 49 will just let the Sun Ray find the server > for a session, it won't tell it the firmware server. > > There are a few other options, such using DNS names. > sunray-config-servers.fqdn is like option 66 > sunray-servers.fqdn is like option 49 > > So instead worrying about making changes to many dhcp servers or messing with > vendor class options, LAN based interconnects with these more standardized > provisioning options is far easier. > > > > > > > On 8/23/12 11:50 AM, Dave Price wrote: >> Daer Craig, Toomas and all other who offered advice... >> >> I am not yet totally sure what final sequence of hacking >> working, but I just manage to get "private interconnect" >> wokking on Solaris 11!! >> >> I copied in /etc/init.d/dhcp into a local directory >> >> I then bodged utadm to pick up my local copy.. >> >> then I bodged around trying to get the -A option working... >> >> then I tried to look at dhcp with dhtadm and pntadm >> but only had bits of stuff and... >> >> Then I hacked about with some /etc/hostname.net? files >> then I removed one, then I messed about with /etc/inet/hosts >> >> and then I thought I would have a final go at running >> my bodged utadm with the -a option again >> >> and, suddenly things seems to be playing the game... >> >> then I did utstart -c >> >> and then I went and restart one of my SunRays... >> >> first attempt it latched on to my (other) Solaris 10 >> server, then I tried again, and this time it latched on the the Solaris 11 >> server, updated its firmware, then gave a log on display >> and then I logged in to Solaris 11, on a private interconnect >> from a SunRay!! >> >> I had been taking copious notes, but then as frustration >> rose, I dropped into "hacking" and only taking partial notes! >> >> I now need to look back carefully through my bash history file and try >> to decide what caused it to finally work! >> >> I will then revert back to an earlier BE, make a new >> one and then try to repeat the final steps again >> taking proper notes again! I will not destroy my "current" BE and then if >> things go pear-shaped I can come back to this and >> try to spot differences. >> >> So, I am now MUCh more happy, but frustrated that I allowed >> myself to drop into "hacking" and ceasing to take proper notes! >> >> More tomorrow, n
Re: [SunRay-Users] THINGS WORKING! Re: more help needed - Advice: Sunray on Solaris 11/SPARC with private interconnect
Hi Dave, You would have had to have at least created /etc/hostname. and /etc/defaultrouter as those aren't part of S11 anymore and also, was this an interface you had already plumbed up? Did the vendor class tags get inserted into DHCP macros? Part of a private interface is that it starts with a unplumbed NIC. Which is why utadm -a takes an interface arg. utadm -A can look a lot like private interconnect but it's for a subnet, not a NIC. There are several other differences, but NIC vs Subnet is one of the largest. -A is not considered a private interconnect. It's a LAN based interconnect with the ability to serve DHCP vendor class tags for many different (even non-local) subnets with DHCP Helpers on routers. Basic networking config, prior to S11, was done through files. No longer the case, and one of the reasons utadm -a is broken. So if you really created a private interconnect, you'd would have had to use dladm/ipadm to manually configure the NIC. Another observation/question. It sounds like will have multiple DHCP servers on the same segment? At least that's how I understood your range comment. Is that true? If so, how are you preventing PC's from using the Sun Ray Server's DHCP and vice versa? I can tell you why it work would, even if a Sun Ray gets an address the other server, it's because when the Sun Ray didn't get all of the info it needed to connect, so it sent out a DHCPInform request, which the DHCP Server on the Sun Ray answered (even it if didn't provide the IP address). You'd actually see this via utquery. You'd have two different values for DHCP server and DHCPInform server. The default of -A is not to offer IP addresses. If that's how you been used to doing things, then there really is no reason to do anything but LAN only connections. On the DHCP server that was serving the PCs, you could set option 66 (tftpserver) and point it to the Sun Ray Server. This was you are provision/controlling the Sun Ray clients from via parameter files. There is also DHCP option 49, but option 49 will just let the Sun Ray find the server for a session, it won't tell it the firmware server. There are a few other options, such using DNS names. sunray-config-servers.fqdn is like option 66 sunray-servers.fqdn is like option 49 So instead worrying about making changes to many dhcp servers or messing with vendor class options, LAN based interconnects with these more standardized provisioning options is far easier. On 8/23/12 11:50 AM, Dave Price wrote: Daer Craig, Toomas and all other who offered advice... I am not yet totally sure what final sequence of hacking working, but I just manage to get "private interconnect" wokking on Solaris 11!! I copied in /etc/init.d/dhcp into a local directory I then bodged utadm to pick up my local copy.. then I bodged around trying to get the -A option working... then I tried to look at dhcp with dhtadm and pntadm but only had bits of stuff and... Then I hacked about with some /etc/hostname.net? files then I removed one, then I messed about with /etc/inet/hosts and then I thought I would have a final go at running my bodged utadm with the -a option again and, suddenly things seems to be playing the game... then I did utstart -c and then I went and restart one of my SunRays... first attempt it latched on to my (other) Solaris 10 server, then I tried again, and this time it latched on the the Solaris 11 server, updated its firmware, then gave a log on display and then I logged in to Solaris 11, on a private interconnect from a SunRay!! I had been taking copious notes, but then as frustration rose, I dropped into "hacking" and only taking partial notes! I now need to look back carefully through my bash history file and try to decide what caused it to finally work! I will then revert back to an earlier BE, make a new one and then try to repeat the final steps again taking proper notes again! I will not destroy my "current" BE and then if things go pear-shaped I can come back to this and try to spot differences. So, I am now MUCh more happy, but frustrated that I allowed myself to drop into "hacking" and ceasing to take proper notes! More tomorrow, nearly 8pm here in the UK so I think I have had enough and I may stop before I go and break something! Dave Price ___ 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
Re: [SunRay-Users] THINGS WORKING! Re: more help needed - Advice: Sunray on Solaris 11/SPARC with private interconnect
Really annoyed with myself now, I knew I should have stopped before I got too tired! I just rebooted it and realised I had not noted down my bash history and on reboot, history has been wiped! So, I am going to have to do a bit of re-discovery to work out my final sequence of commands. On the bright side, SunRay service has come up again and I can still connect from my test SunRay. Thanks folks, Dave Price ___ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users
