Impressions of b50
I installed Solaris Express build 50, inside VMware server on my Opteron box, gave it a larger than normal amount of ram 768MB, its going to host sun studio 11, and java creator, I also gave it a large 10GB of disk space with more added later to make a small ZFS pool. The install went mostly smooth, I haven’t installed on x86 in quite a while I think b39 was the last one I tried. The defaults for hard disk allocation were stupid as they have always been. Thus forcing a custom install, which once given decent numbers the install went very well and then rebooted into the normal Xorg server as usual with a default resolution of 800x600.
Deciding to try my usual remote X to access the machine to get a slightly faster desktop by forcing VMware to do less work because most of the work displaying X can be done on raw hardware instead of inside VMware. This has worked out of the box on all Solaris including Solaris Express build 36, and 39 as well as Solaris 8, 9 and 10. Yet on this latest build 50 it does not, I tried using another box as the font server this failed as well. I attempted this because the fc-cache builder seems broken in build 50, in addition to the print server that has been broke since Solaris 10. Still no luck I reviewed all the dt/config files looking if someone disabled remote logins because of rumored changes that Solaris will now be secure out of box, if those changes were made, I can find what they did to make ignore remote X logins.
On the other hand I gave VMware new support of Solaris including vmware-tools a try no automatic installer but I was able to mount the solaris.iso and got access to a tar ball that I un-tared using gtar since it was compressed. And proceeded to run the installer, that worked smoothly, logged out that restarted X and was able to move from vmware to desktop without the normal ctrl-alt sequence that is needed with out the vmware tools installed. I tried to run the vmware-toolbox command and found it was missing glib so I gave up on it, but at least no more stupid ctrl-alt sequence.
If anyone knows how to get remote X back working, please feel free to comment on this blog.
Deciding to try my usual remote X to access the machine to get a slightly faster desktop by forcing VMware to do less work because most of the work displaying X can be done on raw hardware instead of inside VMware. This has worked out of the box on all Solaris including Solaris Express build 36, and 39 as well as Solaris 8, 9 and 10. Yet on this latest build 50 it does not, I tried using another box as the font server this failed as well. I attempted this because the fc-cache builder seems broken in build 50, in addition to the print server that has been broke since Solaris 10. Still no luck I reviewed all the dt/config files looking if someone disabled remote logins because of rumored changes that Solaris will now be secure out of box, if those changes were made, I can find what they did to make ignore remote X logins.
$ svcs -x
svc:/application/print/server:default (LP print server)
State: disabled since Fri Oct 27 08:26:11 2006
Reason: Disabled by an administrator.
See: http://sun.com/msg/SMF-8000-05
See: lpsched(1M)
Impact: 1 dependent service is not running. (Use -v for list.)
svc:/application/font/fc-cache:default (FontConfig Cache Builder)
State: maintenance since Fri Oct 27 08:26:47 2006
Reason: Start method failed repeatedly, last dumped core on Segmentation Fault (11).
See: http://sun.com/msg/SMF-8000-KS
See: fc-cache(1M)
See: /var/svc/log/application-font-fc-cache:default.log
Impact: This service is not running.
$
On the other hand I gave VMware new support of Solaris including vmware-tools a try no automatic installer but I was able to mount the solaris.iso and got access to a tar ball that I un-tared using gtar since it was compressed. And proceeded to run the installer, that worked smoothly, logged out that restarted X and was able to move from vmware to desktop without the normal ctrl-alt sequence that is needed with out the vmware tools installed. I tried to run the vmware-toolbox command and found it was missing glib so I gave up on it, but at least no more stupid ctrl-alt sequence.
If anyone knows how to get remote X back working, please feel free to comment on this blog.
posted by jamesd_wi at Friday, October 27, 2006
7 Comments:
You've probably hit the SBD changes (secure by default) - where most of the services are either disabled or local-only. The quick way is to run netservices open (to restore the changes back to pre-B42) or use svccfg to set tcp_listen to true.
All remote connections other than ssh are disabled by default in Nevada builds 42 and later. More details and instructions on re-enabling can be found in the Secure by Default heads-up message on opensolaris.org and the OpenSolaris Secure-by-Default project page.
-alan
I ran "netservices open" X still won't accept remote X connections.
You need to restart your X session before it will take effect. When connections are blocked, ps should show the X server is being started with -nolisten tcp, when they're allowed, that option will not be present.
okay i got remote X working... guess i need to restart dtlogin, restarting X alone was not enough.
The vmware-toolbox problem is because the wrapper script that's supposed to make sure all the right libraries are linked gets confused by the new default LD_LIBRARY_PATH setting in Nevada (I just ran into this as well). It'll work if you run it with LD_LIBRARY_PATH unset. The wrapper script is being fixed as well.
The “new default LD_LIBRARY_PATH” is a bug in recent Nevada builds:
6462733: /usr/dt/config/Xsession.d/1099.br sets LD_LIBRARY_PATH in user environment
(unfortunately it's from a part of Solaris not yet open sourced so it's not visible on bugs.opensolaris.org)
Post a Comment
<< Home