Basesoft Solaris HowTo (under construction)

This Basesoft Solaris HowTo (FAQ) page gives some, hopefully useful, instructions about solving some advanced problems in networked solutions, that we have encountered and where solutions have not easily been found on the net. This includes both usage of Solaris servers, server software producs and open source solutions as well as different kind of clients - UNIX, Linux, Windows and thin clients such as SunRay.

Problems with SunRay Administration after installing CAM

Server does not answer SunRay DHCP BOOT requests

Sun SparcStation does not boot with error - invalid IDPROM

../ Back to SSL Secure Pages Overview

Problems with SunRay Administration after installing CAM
Initially we installed SunRay Server Software (SRSS 3.0) without enabling CAM (Controlled Access Mode). To be able to configure this in the WEB Administration WEB GUI, you first have to run utconfig again (in /opt/SUNWut/sbin/). Unfortunately there seems to be some problem in this script. It removes the existing admin user account utwww, and then deletes its group utadmin. Next it tries to add the user utwww again, but this fails since the group utadmin no longer exist. Then it adds the group utadmin again. After this you will no longer be able to log in to the WEB SunRay Administration GUI (assuming you have put back your previously working httpd configuration - hint save a copy of your /etc/apache/httpd.conf before you start, and put it back again after running utconfig - this will be another hint ...).

If you look in the /var/opt/SUNWut/log/messages file you vill se log entries such as:
Dec 28 14:01:22 tillie main[2193]: [ID 702911 user.info] create_session_id(): could not open session file (Permission denied)
Dec 28 14:01:22 tillie main[2193]: [ID 702911 user.info] Internal Error: create_session_id() returned NULL!

The workaround to fix this is:
1. Put the user utwww manually back to e.g. /etc/passwd, e.g. something like:
utwww:x:9513:1201:ut admin web server cgi user:/tmp:/bin/sh #where 1201 is the group id for utadmin.
2. Modify the access rights to /var/opt/SUNWut/cgitokens:
chgrp utadmin /var/opt/SUNWut/cgitokens
chmod 770 /var/opt/SUNWut/cgitokens
#(was e.g. 700 root:other)
[Updated 2005-DEC-28/JH]

Server does not answer SunRay DHCP BOOT requests
When the SunRays boot, they send a DHCPDISCOVER broadcast request. You can see this request on your server, e.g. by snoop -d eri0, but your server does not reply, and hence the SunRays do not boot (the SunRay screen hangs on status 21).

OLD-BROADCAST -> BROADCAST DHCP/BOOTP DHCPDISCOVER

This may happen if you are running SunScreen on your SunRay server shared network interface. The SunScreen "sits" in-between the network interface and your applications. If the SunRays boot, when you shut sunscreen down, e.g. /etc/init.d/sunscreen stop, the "fix" is found below.

HowTo configure SunScreen (Solaris 9) for SunRay in shared network configuration:

(1) copy original Screen to newscreen (e.g. on http://localhost:3852)

(2) copy original Service bootp to bootp_sunray:
"bootp_sunray" SINGLE FORWARD "udpall" BROADCAST 67
PARAMETERS 60 0 3 COMMENT "sunray dhcp/bootp dhcpdiscover"

(3) add a rule before your more restrictive rules (e.g. as #1) such as:
1 * bootp_sunray * srss_server_hostname allow * sunray

Explanation: The SunRay boot request originates from src->dest, port, IP: 68->67 0.0.0.0 -> 255.255.255.255, and this is not allowed as default. You can see this uf you turn on LOG_DETAIL for this new rule (advanced view), and look at the log in SunScreen Information page.
[Updated 2005-NOV-29]

Sun SparcStation does not boot with error - invalid IDPROM
We moved our Sun SparcStation 5 running SunOS 5.5.1 that had been up and running for about 10 years without any problems. Now it was powered off for a couple of days. When we started it up, it tried to turn on the fan, but then went all quiet. Network (loopback) tests failed. The main problem seemed to be "The IDPROM contents are invalid".

DISCLAIMER. Please carry out these instructions at your own risk, we do not take responsibility of any consequences possibly caused by following the instructions below.

We fixed it (approximately) as follows:
(1) fix it to boot somehow - do set-defaults at the ok prompt (all this might have to do with the Nvram and that the battery has lost its power).
(2) reset (and boot), you will now probably get messages such as "Warning IDPROM checksum error"
(3) notice the possible wrong ethernet(MAC) adress (e.g. "9:0:41:75:e3:b5") and wrong hostid (e.g. "8015eb65")
(4) find your correct and valid original hostid from your records e.g. on the disks mounted on this temporary boot (network will not work)
(5) shut down to the ok prompt, e.g. shutdown -i0 -g0 -y
(6) write the following commands (omit the "ok"), assuming a original hostid of 3456abcd:
(a) ok 0 0 mkp
(b) ok 3 4 20 56 ab cd 3456abcd mkpl
(c) <CTRL>-D<CTRL>-R
(d) ok reset
(7) if this did not work, or you get a message like "STACK UNDERFLOW", check that the hostid and ether adress are correct, and notice the <SPACE> in the first two hex digits of the hostid.
Repeat step (6) with:
(a) ok 1 1 mkp
instead.
(8) check that the ether adress and hostid are correct when booting, e.g. 3:4:20:56:ab:cd and 3456abcd
(9) fix the date (which was at the time of shut down and poweroff in multiuser mode, e.g. by /usr/bin/rdate ntp1.org.dom or manually by the date command.
[Updated 2006-MAY-30]

../ Back to SSL Secure Pages Overview