In <1194888453.446834.100730@v3g2000hsg.googlegroups.c om> The Derfer writes:

>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-

In <1194888453.446834.100730@v3g2000hsg.googlegroups.c om> The Derfer writes:

>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-

On Nov 12, 9:27 am, The Derfer wrote:
> 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.
> Thanks, Sun; took a
> while to figure that one out.

And that wasnt a big enough clue stick?
This is really an administration question so I wont cross post all
over..

> 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.

Its a function that is sourced. The fact that it cant be sourced
is a bad thing...
On Solaris 10 its been moved but the contents say:

# shcat file
# Simulates cat in sh so it doesn't need to be on the root filesystem.

> 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).

Then dont

> Has anyone run into this before and is there a cure-all for what ails
> this box?

Unfortunately you are the disease in this case : <
Take your medicine???

> Not the first box this has happened to after this patch cluster
> install.
> Box is Solaris 9, SPARC.

Thats a bit useful but really I suggest a re-install/re-patch and put
your
custom stuff in places that WONT be over-written by patching...
Assuming its needed at all.

live upgrade is probably a good way to go about it.
But youll need disk space for that

> Thanks in advance to anyone who can help.

Here are the relevant boot messages I see:
A good question is why is the hostname 'unknown' so early in the
process? All the filenames are set with the hostname so it's not
that.


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 wrote:
> In <1194888453.446834.100...@v3g2000hsg.googlegroups.c om> The Derfer writes:
>
> >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-

Here are the relevant boot messages I see:
A good question is why is the hostname 'unknown' so early in the
process? All the filenames are set with the hostname so it's not
that.


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 wrote:
> In <1194888453.446834.100...@v3g2000hsg.googlegroups.c om> The Derfer writes:
>
> >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-

The Derfer wrote:
> 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.
> Thanks, Sun; took a
> while to figure that one out.
>
> 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.
>

/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

The Derfer wrote:
> 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.
> Thanks, Sun; took a
> while to figure that one out.
>
> 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.
>

/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

In article ,
Michael Tosch wrote:
>The Derfer wrote:
>> 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.
>> Thanks, Sun; took a
>> while to figure that one out.
>>
>> 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.
>
>/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
schulz@adi.com

In article ,
Michael Tosch wrote:
>The Derfer wrote:
>> 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.
>> Thanks, Sun; took a
>> while to figure that one out.
>>
>> 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.
>
>/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
schulz@adi.com

In article <1194888453.446834.100730@v3g2000hsg.googlegroups.c om>,
The Derfer wrote:
>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.

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

In article <1194888453.446834.100730@v3g2000hsg.googlegroups.c om>,
The Derfer wrote:
>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.

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

Thomas H Jones II wrote:
> In article <1194888453.446834.100730@v3g2000hsg.googlegroups.c om>,
> The Derfer wrote:
>
>>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.
>
>
> 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.

How about answering the OP's question/solving his problem instead of
beating him over the head with your superiority??

Thomas H Jones II wrote:
> In article <1194888453.446834.100730@v3g2000hsg.googlegroups.c om>,
> The Derfer wrote:
>
>>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.
>
>
> 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.

How about answering the OP's question/solving his problem instead of
beating him over the head with your superiority??

In article <4744EB66.9000402@comcast.net>,
Richard B. Gilbert wrote:
>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.
--

"You can only be -so- accurate with a claw-hammer." --me

In article <4744EB66.9000402@comcast.net>,
Richard B. Gilbert wrote:
>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.
--

"You can only be -so- accurate with a claw-hammer." --me

On Nov 21, 11:08 pm, fer...@xanthia.com (Thomas H Jones II) wrote:
> In article <4744EB66.9000...@comcast.net>,
> Richard B. Gilbert wrote:
>
> >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.
> --
>
> "You can only be -so- accurate with a claw-hammer." --me

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

On Nov 21, 11:08 pm, fer...@xanthia.com (Thomas H Jones II) wrote:
> In article <4744EB66.9000...@comcast.net>,
> Richard B. Gilbert wrote:
>
> >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.
> --
>
> "You can only be -so- accurate with a claw-hammer." --me

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

In article <7c2bcdb9-2cf3-4e6b-8c3e-fca15f18fb92@j20g2000hsi.googlegroups.com>,
wrote:
>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.

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.
--

"You can only be -so- accurate with a claw-hammer." --me

In article <7c2bcdb9-2cf3-4e6b-8c3e-fca15f18fb92@j20g2000hsi.googlegroups.com>,
wrote:
>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.

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.
--

"You can only be -so- accurate with a claw-hammer." --me