I apologize ahead of time if my question is lower than what you are use
to seeing.

I having the daunting task in front of me of relocating dozens o
servers from one physical location to another and want to fee
comfortable that I have put everything in place. The physical server i
moving.

I need to know what Sun Solaris commands I should run to find ou
important information about a server. Phrased another way, wha
commands would a seasoned Solaris Admin run to find out what
particular server is all about. I use: ifconfig -a for interfaces
prtconf, prtdiag, df-k. What other commands would you run?

Also what is the best way to find out what applications are running o
a server?

These servers are running either Solaris 8,9,10



Thank you ahead of time for your patienc

--
perpetualma
-----------------------------------------------------------------------
perpetualman's Profile: http://unixadmintalk.com/97
View this thread: http://unixadmintalk.com/showthread.php?t=26142 (How to know version of glibc installed through Sun Studio 11?)

perpetualman wrote:
> I apologize ahead of time if my question is lower than what you are used
> to seeing.
>
> I having the daunting task in front of me of relocating dozens of
> servers from one physical location to another and want to feel
> comfortable that I have put everything in place. The physical server is
> moving.
>
> I need to know what Sun Solaris commands I should run to find out
> important information about a server. Phrased another way, what
> commands would a seasoned Solaris Admin run to find out what a
> particular server is all about. I use: ifconfig -a for interfaces,
> prtconf, prtdiag, df-k. What other commands would you run?
>
> Also what is the best way to find out what applications are running on
> a server?
>
> These servers are running either Solaris 8,9,10
>
>
>
> Thank you ahead of time for your patience
>
>

It's a hell of a time to be figuring out what's important about a server!!

Doesn't anybody in the Unix world document anything? It seems to me
that every "production" system should have at least some documentation
showing what applications are installed, what version of each
application if it's a commercial product, who "owns" each application,
etc. Keeping this stuff in your head may work for a while but what
happens when you have a heart attack, are out sick for eight weeks, and
somebody needs to take over for you?

In my working days, I could have shown you documentation for the
configuration, hardware and software, of every system I was responsible for.

AFAIK there are no commands you can execute to show you everything
that's installed. You can look in /opt which is where stuff "should" be
installed and see what you find. You may find a /usr/local tree on the
system with applications installed; it's a bad idea but some people do
it. You can do a "ps -ef" and see what's running, which might or might
not tell you something useful.

Given the Unix community's naming "conventions" the names may tell more
about what people were smoking when the apps were created, than they
will about what the apps are supposed to do.

In article <45C3BC03.2030001@comcast.net>,
"Richard B. gilbert" <rgilbert88@comcast.net> wrote:

> perpetualman wrote:
> > I apologize ahead of time if my question is lower than what you are used
> > to seeing.
> >
> > I having the daunting task in front of me of relocating dozens of
> > servers from one physical location to another and want to feel
> > comfortable that I have put everything in place. The physical server is
> > moving.
> >
> > I need to know what Sun Solaris commands I should run to find out
> > important information about a server. Phrased another way, what
> > commands would a seasoned Solaris Admin run to find out what a
> > particular server is all about. I use: ifconfig -a for interfaces,
> > prtconf, prtdiag, df-k. What other commands would you run?
> >
> > Also what is the best way to find out what applications are running on
> > a server?
> >
> > These servers are running either Solaris 8,9,10
> >
> >
> >
> > Thank you ahead of time for your patience
> >
> >
>
> It's a hell of a time to be figuring out what's important about a server!!
>
> Doesn't anybody in the Unix world document anything? It seems to me
> that every "production" system should have at least some documentation
> showing what applications are installed, what version of each
> application if it's a commercial product, who "owns" each application,
> etc. Keeping this stuff in your head may work for a while but what
> happens when you have a heart attack, are out sick for eight weeks, and
> somebody needs to take over for you?
>
> In my working days, I could have shown you documentation for the
> configuration, hardware and software, of every system I was responsible for.
>
> AFAIK there are no commands you can execute to show you everything
> that's installed. You can look in /opt which is where stuff "should" be
> installed and see what you find. You may find a /usr/local tree on the
> system with applications installed; it's a bad idea but some people do
> it. You can do a "ps -ef" and see what's running, which might or might
> not tell you something useful.
>
> Given the Unix community's naming "conventions" the names may tell more
> about what people were smoking when the apps were created, than they
> will about what the apps are supposed to do.

Go to a local drug store and buy a carton of RID. Use the fine-toothed
comb included in the box to go through your server directory by
directory reviewing the stuff that's on the servers. If you're lucky
there may still be people around who can tell you stuff like "Yeah, that
was a software trial. We decided we didn't have the budget for it." or
"This is a beta version of X that fixed a particular bug we had with
printing. The latest release fixed that."

Wasn't this one of the labors of Hercules--something to do with
stables...

--
DeeDee, don't press that button! DeeDee! NO! Dee...

On 2007-01-31 18:08:52 +0000, perpetualman
<perpetualman.2le2dg@no-mx.unixadmintalk.com> said:
>
>
> I having the daunting task in front of me of relocating dozens of
> servers from one physical location to another and want to feel
> comfortable that I have put everything in place. The physical server is
> moving.

A horrible task if things are not documented, yes!

>
> I need to know what Sun Solaris commands I should run to find out
> important information about a server. Phrased another way, what
> commands would a seasoned Solaris Admin run to find out what a
> particular server is all about. I use: ifconfig -a for interfaces,
> prtconf, prtdiag, df-k. What other commands would you run?


Downloading and running the Sun explorer tool is a good thing to do: it
does a lot of grovelling over the machine and produces a vast amount of
output (stored in a tar file somewhere). Sun use it to get information
about the configuration of a machine for support purposes. It's not
everything you need, but it's a start.

Another thing, boring but necessary, is to carefully, and with a proper
labeller, label all the physical connections to the box.

--tim

On Wed, 31 Jan 2007 10:08:52 -0800, perpetualman <perpetualman.2le2dg@no-mx.unixadmintalk.com>
wrote:

>I apologize ahead of time if my question is lower than what you are used
>to seeing.
>
>I having the daunting task in front of me of relocating dozens of
>servers from one physical location to another and want to feel
>comfortable that I have put everything in place. The physical server is
>moving.
>
>I need to know what Sun Solaris commands I should run to find out
>important information about a server. Phrased another way, what
>commands would a seasoned Solaris Admin run to find out what a
>particular server is all about. I use: ifconfig -a for interfaces,
>prtconf, prtdiag, df-k. What other commands would you run?
>
>Also what is the best way to find out what applications are running on
>a server?
>
>These servers are running either Solaris 8,9,10
>
>
>
>Thank you ahead of time for your patience

Can't you just move the server and hook it up the same as before the move?
No need to know how the server is configured.

>--
>perpetualman

Barry
=====
Home page
http://members.iinet.net.au/~barry.og

Hey, Thanks for all the responses so far I will definately add thos
items to my "toolbox". I cant trust any Docs. , yes they were writte
when the servers rolled out in 2002, but not kept current.
Barry asked by not just move them? I need to know what servers ar
sharing applications or data so that I move that group all together.

I knew this wasnt going to be easy, but I thought it was more to d
with not being super savvy with unix but it sounds like what I a
looking for just plain ole dont exist.

What do you guys(not gender specific) do when you walk into a plac
cold and need to get your arms around a server?

I am losing sleep over this mess:confused

--
perpetualma
-----------------------------------------------------------------------
perpetualman's Profile: http://unixadmintalk.com/97
View this thread: http://unixadmintalk.com/showthread.php?t=26142 (How to know version of glibc installed through Sun Studio 11?)

perpetualman wrote:
> Hey, Thanks for all the responses so far I will definately add those
> items to my "toolbox". I cant trust any Docs. , yes they were written
> when the servers rolled out in 2002, but not kept current.
> Barry asked by not just move them? I need to know what servers are
> sharing applications or data so that I move that group all together.
>
> I knew this wasnt going to be easy, but I thought it was more to do
> with not being super savvy with unix but it sounds like what I am
> looking for just plain ole dont exist.
>
> What do you guys(not gender specific) do when you walk into a place
> cold and need to get your arms around a server?
>
> I am losing sleep over this mess
>
>

Well, for VMS I wrote a script the prints out the hardware
configuration, the software licenses (VMS has a license database), the
print queues, etc, etc. Unix does not have the same toolset. You can
find out the hardware configuration fairly easily but not what software
is installed.

I'd suggest starting with the documentation you have and trying to
verify as much of it as you can. Ask people who use the system which
applications they use. See what's running on the system. Use the tools
you have to find out who runs what. Ask some more. You'll need to
observe over a period of time, at least a month, to be sure of catching
most of the applications in use.

Unless your job has some really great features, I'd suggest looking for
another one. As things now stand you are likely to alternate between
working your butt off and having it kicked off!!!

In article <45D1F59B.2090302@comcast.net>,
"Richard B. gilbert" <rgilbert88@comcast.net> wrote:

> perpetualman wrote:
> > Hey, Thanks for all the responses so far I will definately add those
> > items to my "toolbox". I cant trust any Docs. , yes they were written
> > when the servers rolled out in 2002, but not kept current.
> > Barry asked by not just move them? I need to know what servers are
> > sharing applications or data so that I move that group all together.
> >
> > I knew this wasnt going to be easy, but I thought it was more to do
> > with not being super savvy with unix but it sounds like what I am
> > looking for just plain ole dont exist.
> >
> > What do you guys(not gender specific) do when you walk into a place
> > cold and need to get your arms around a server?
> >
> > I am losing sleep over this mess
> >
> >
>
> Well, for VMS I wrote a script the prints out the hardware
> configuration, the software licenses (VMS has a license database), the
> print queues, etc, etc. Unix does not have the same toolset. You can
> find out the hardware configuration fairly easily but not what software
> is installed.
>
> I'd suggest starting with the documentation you have and trying to
> verify as much of it as you can. Ask people who use the system which
> applications they use. See what's running on the system. Use the tools
> you have to find out who runs what. Ask some more. You'll need to
> observe over a period of time, at least a month, to be sure of catching
> most of the applications in use.
>
> Unless your job has some really great features, I'd suggest looking for
> another one. As things now stand you are likely to alternate between
> working your butt off and having it kicked off!!!

VMS had the luxury of a DEC-supplied VMSINSTAL utility that was fully
documented and maintained. Other OS' use different methods--MacOS X's
Install packages, various Linux's RPM, and even Solaris' pkg framework.
The problem is that someone like HP's printer group didn't want to
reinvent the wheel, so they created a tarball/install script that
hopefully ran on all the UNIX boxes for their Jetadmin software.

Part of my prior experience as a consultant is to know a good part of
what's supposed to be on a vanilla install of the OS in front of me. If
you don't have that, you'd better learn ASAP. Or tell your PHB you're
in over your head and need some expert help or the project is going to
take much longer.

The older, more interdependent the systems are, the more will break if
you look at them wrong. AND the longer it's going to take to do the
sort of consolidation you've been tasked with. Unless management
doesn't care what's disrupted, I wouldn't imaging this taking anything
less than 6 months.

Start with a full system audit of each box:

main purpose
responsible people (who gets the 2am phone call if it's not working)
hardware
software
easy: directory by directory analysis
hard: file by file thumbprint analysis comparied with a vanilla system
cron jobs (what runs when)
how is it backed up?
how would it be restored from scratch if it bit the big one?
anything running that depends on other systems?
anything running that other systems depend on?
What breaks on other systems if this system is down?
What breaks on this system when other systems are down?
Who has accounts on this box and why?
When did the get them and who authorized it?

I seem to recall a desktop system at Synopsys that was part of a group
relocation to Oregon. We went through inventoring and tagging all of
them, shut them down, and had them packed and moved to the trucks. A
day later, I got a call from a supervisor on the loading dock.
Apparently their package tracking system was running on an informix
database on one of those systems. They weren't to happy to find out
it's fate and that there was nothing anyone could do about it as it was
no longer a Synopsys asset.

--
DeeDee, don't press that button! DeeDee! NO! Dee...

Michael Vilain wrote:
> In article <45D1F59B.2090302@comcast.net>,
> "Richard B. gilbert" <rgilbert88@comcast.net> wrote:
>
>
>>perpetualman wrote:
>>
>>>Hey, Thanks for all the responses so far I will definately add those
>>>items to my "toolbox". I cant trust any Docs. , yes they were written
>>>when the servers rolled out in 2002, but not kept current.
>>>Barry asked by not just move them? I need to know what servers are
>>>sharing applications or data so that I move that group all together.
>>>
>>>I knew this wasnt going to be easy, but I thought it was more to do
>>>with not being super savvy with unix but it sounds like what I am
>>>looking for just plain ole dont exist.
>>>
>>>What do you guys(not gender specific) do when you walk into a place
>>>cold and need to get your arms around a server?
>>>
>>>I am losing sleep over this mess
>>>
>>>
>>
>>Well, for VMS I wrote a script the prints out the hardware
>>configuration, the software licenses (VMS has a license database), the
>>print queues, etc, etc. Unix does not have the same toolset. You can
>>find out the hardware configuration fairly easily but not what software
>>is installed.
>>
>>I'd suggest starting with the documentation you have and trying to
>>verify as much of it as you can. Ask people who use the system which
>>applications they use. See what's running on the system. Use the tools
>>you have to find out who runs what. Ask some more. You'll need to
>>observe over a period of time, at least a month, to be sure of catching
>>most of the applications in use.
>>
>>Unless your job has some really great features, I'd suggest looking for
>>another one. As things now stand you are likely to alternate between
>>working your butt off and having it kicked off!!!
>
>
> VMS had the luxury of a DEC-supplied VMSINSTAL utility that was fully
> documented and maintained. Other OS' use different methods--MacOS X's
> Install packages, various Linux's RPM, and even Solaris' pkg framework.
> The problem is that someone like HP's printer group didn't want to
> reinvent the wheel, so they created a tarball/install script that
> hopefully ran on all the UNIX boxes for their Jetadmin software.
>
> Part of my prior experience as a consultant is to know a good part of
> what's supposed to be on a vanilla install of the OS in front of me. If
> you don't have that, you'd better learn ASAP. Or tell your PHB you're
> in over your head and need some expert help or the project is going to
> take much longer.
>
> The older, more interdependent the systems are, the more will break if
> you look at them wrong. AND the longer it's going to take to do the
> sort of consolidation you've been tasked with. Unless management
> doesn't care what's disrupted, I wouldn't imaging this taking anything
> less than 6 months.
>
> Start with a full system audit of each box:
>
> main purpose
> responsible people (who gets the 2am phone call if it's not working)
> hardware
> software
> easy: directory by directory analysis
> hard: file by file thumbprint analysis comparied with a vanilla system
> cron jobs (what runs when)
> how is it backed up?
> how would it be restored from scratch if it bit the big one?
> anything running that depends on other systems?
> anything running that other systems depend on?
> What breaks on other systems if this system is down?
> What breaks on this system when other systems are down?
> Who has accounts on this box and why?
> When did the get them and who authorized it?

Excellent advice!

>
> I seem to recall a desktop system at Synopsys that was part of a group
> relocation to Oregon. We went through inventoring and tagging all of
> them, shut them down, and had them packed and moved to the trucks. A
> day later, I got a call from a supervisor on the loading dock.
> Apparently their package tracking system was running on an informix
> database on one of those systems. They weren't to happy to find out
> it's fate and that there was nothing anyone could do about it as it was
> no longer a Synopsys asset.
>

Doesn't just about every company have at least one system that
everything depends on? At my last job we had this old Novell server
that we wanted to shut down and drop in the dumpster. Every time we
tried, we found yet another thing somewhere in the building that
depended on that box!

Of course the box had been in service for five or six years, there was
NO documentation, etc, etc.

The moral of this story is DOCUMENT and KEEP IT UP-TO-DATE.

bump update any

--
perpetualma
-----------------------------------------------------------------------
perpetualman's Profile: http://unixadmintalk.com/97
View this thread: http://unixadmintalk.com/showthread.php?t=26142 (How to know version of glibc installed through Sun Studio 11?)