One thign that puzzles me that I have yet to figure out:
The machine boots and I get 'unknown console login' at the
console. Log in, and 'hostname' reveals 'unknown' as the hostname.
Run /etc/init.d/network and it complains 'shcat' cannot be found.
I edit that script to change 'shcat' to 'cat' and it works, restores
the
hostname to the normal hostname.
Reboot and rcS complains 'cat' is an unknown command, does not
successfully
run the network script! Still an 'unknown' hostname after the boot.
Run network script again, all is well. Hostname set, networking
intact.
So am I stuck? With shcat, nothing works after booting. With cat
instead,
it'll work but I have to go in and manually run the network script,
which is obviously
a robustness issue (I can't keep doing that).
Has anyone run into this before and is there a cure-all for what ails
this box?
Not the first box this has happened to after this patch cluster
install.
Box is Solaris 9, SPARC.
Thanks in advance to anyone who can help.
>On a SunFire server I did a Solaris patch cluster installation and
>after it completed
>I noticed that the installation had replaced a lot of my (customized)
>config files in /etc/
>and elsewhere (e.g., erasing static routes). I found (e.g.) /etc/
>inetsvc was new with
>a /etc/inetsvc.patch# being the old one with the customizations.
It's dangerous to change the Sun-supplied scripts. Instead, interpose
your own scripts, with your own names.
`shcat' is a shell function defined in /etc/rcS . There are many
of these. All uses of shcat are in /etc/rcS.d/S30network.sh .
--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-
Hardware watchdog
enabled
configuring IPv4 interfaces:
bge0.
RPC: Timed
out
Hostname:
unknown
The system is coming up. Please
wait.
checking ufs
filesystems
/dev/md/rdsk/d35: is
clean.
/dev/md/rdsk/d36: is
clean.
open of /dev/ce failed: No such device or
address
open of /dev/ce failed: No such device or
address
open of /dev/ip_ip_respond_to_timestamp_broadcast failed: No such file
or
directory
starting rpc services: rpcbind
done.
Setting netmask of bge0 to
255.255.255.224
Setting default IPv4 interface for multicast: add net 224.0/4: gateway
unknown
unknown: bad
value
syslog service
starting.
metaset: unknown: metad client create: RPC: Unknown
host
volume management
starting.
The system is ready.
On Nov 12, 1:26 pm, Gary Mills <mi...@cc.umanitoba.ca> wrote:
Forget the time- and bandwidth-consuming patch clusters, and use pca
instead:
pca --safe --askauth --install missingrs
Using the "safe" option, pca will check the files each patch will
overwrite. If any of the files has local modifications, it will not
install this patch, and tell you the names of the affected file(s).
mp.
--
Systems Administrator | Institute of Scientific Computing | Univ. of Vienna
| http://www.par.univie.ac.at/solaris/pca/
Patch Check Advanced | Analyze, download and install patches for Sun
Solaris
/etc/init.d/network is not meant to run interactively.
Change "cat" back to "shcat"!
Ensure that /etc/nodename contains the hostname!
If /etc/.UNCONFIGURED exists, remove it!
--
Michael Tosch @ hp : com
cat is in /usr/bin which will not be available at the time
/etc/rcS.d/S30network.sh (a hard link to /etc/init.d/network) is run.
To get around this, /sbin/rcS (which runs the stuff in /etc/rcS.d)
defines a shell function called shcat.
You might check that /etc/rcS.d/S30network.sh exists and is in fact the
same as /etc/init.d/network (it probably is given the above error about
cat being an unknown command). I don't know what else to suggest other
than checking the contents of /etc/nodename.
--
Tom Schulz
sch...@adi.com
Lemme guess: your first exposure to *N*X was Linux systems?
At any rate, /etc/init.d/network is NOT meant to be run interactively,
and it is *definitely* never meant to be run while the system is at any
run level-beyond "S".
>I edit that script to change 'shcat' to 'cat' and it works, restores
>the
>hostname to the normal hostname.
Yeah... Kind of a sledgehammer approach to things...
>
>Reboot and rcS complains 'cat' is an unknown command, does not
>successfully
>run the network script! Still an 'unknown' hostname after the boot.
Thus the danger of the sledgehammer approach to system administration.
>Run network script again, all is well. Hostname set, networking
>intact.
>So am I stuck? With shcat, nothing works after booting. With cat
>instead,
>it'll work but I have to go in and manually run the network script,
>which is obviously
>a robustness issue (I can't keep doing that).
>
>Has anyone run into this before and is there a cure-all for what ails
>this box?
Technically, the only problem that existed, previously, existed with the
administrator, not with the program. Solve the real problem and the
system should be fine.
>Not the first box this has happened to after this patch cluster
>install.
No, I don't imagine that it is, not if you're making the same errors
over and over.
--
"You can only be -so- accurate with a claw-hammer." --me
How about answering the OP's question/solving his problem instead of
beating him over the head with your superiority??
Here's an idea: how about *you* work on your reading comprehension skills?
The OP's problems were self-induced. He misused a system script, the
/etc/init.d/network script, and caused his own breakage. Where I've most
often seen this particular mistake made before has been by junior admins
that made the jump from Linux to Solaris (thus my question regarding where
he learned *N*X). Thus, the "solution" is, and I stated this in my prior
reply, "don't use the /etc/init.d/network script interactively". There's
also the whole lesson of "don't modify SUN-supplied init scripts".
Fortunately, the /etc/init.d/network bugaboo no longer appears to be
possible in Solaris 10:
# uname -sr ; ls /etc/init.d/network
SunOS 5.10
/etc/init.d/network: No such file or directory
So, won't won't have to worry about someone running /etc/init.d/network
on a Solaris box and having the system no longer able to figure out its
own name.
On the other hand, if you weren't too busy feeling self righteous, you
could actually offer a resonable suggestion.
After all, just because Sun/Solaris does thing bass-ackwards sometimes
does not mean the rest of the """*N*X""" world does.
I think it is completely reasonable to expect to be able to run the
Network RC script at any run level.
Especially since the network script really only starts interfaces, and
does not typically stop them.
Be aware: for Solaris, the /etc/rcS.d/S*network run-level script is
cometimes a seperate copy from the /etc/init.d/network copy. Although
you will often see one as a link to the other.
Here is a reasonable suggestion for fixing the silliness in this
particular Network script:
Of Course, make a copy of the network script first:
cp -p /etc/init.d/network /etc/init.d/network.orig
add this at the beginning of the script
scriptname=$0
case $scriptname in
*S*network ) CAT=shcat ;;
network ) CAT=cat ;;
esac
### Then replace each occurrence of shcat with $CAT
Hopefully this was more helpful. After all, not everyone has been
languishing in the same in the same Sun Solaris environment for years
and years.
Cheers,
- Charles
And just be PAINFULLY AWARE that if you make these changes to the named
scripts as suggested above, that you face the very real possibility that
your "fix" will be blown away each and every time you patch the box. Thus,
if you continue with habits that are bad in a Solaris context and implement
"fixes" that allow yourself to continue those habits, you'll be having to
rely ever more on fixing and fixing your systems. This is fine if you're
the only one to ever use those systems. However, if that's not the case or
may not always be the case, you're simply creating a pathological
environment.