I agree. And yes, even if you have a Desktop that executes as root, you will
still
need to really be root fairly frequently. And someone with the power to shut
down
the network should certainly be trusted with the management station.
I've put Netview in for over 50 different customers, and in most cases the box
is owned
and supported by the network group themselves. Yes, this means they risk
wrecking it
because they are not highly skilled AIX administrators, but then they do know
how to take
a backup, and they generally get along OK.
At large sites there is often a Unix admin group which supports all AIX boxes,
and if you don't do it their way they won't help you at all. Those sites need
to compromise. 'Sudo' is a painful way; having someone come over and type in
the password for you is an inconvenient way. Changing file permissions all over
the place is risky, I think, as well as incomplete.
The worst cases are those in which every unix box in the company has the same
root password, and so no one can know what it is. I have seen two of those.
I would suggest setting up an id that can do most of the administrative function
without being root (especially for map ownership). Use that id most of the time,
but reserve the right to be root when you need to. Like restoring the map
database!
I have a clause in my statement-of-work that says while I am onsite installing
and customizing the product I will have root access to the box, and if the
TMR server is on a different box I will also have access to an Administrator's
desktop that executes as root. I have had to invoke this on serveral occasions
as it is the only way to do the job effectively.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
This is my two cents on this issue. I usually get in trouble when I express my
opinions on this list, because what I have to say often disturbs people, so let
me say that this is my opinion and not official Tivoli doctrine.
I feel compelled to comment on this because I think it needs to be said that
NetView is designed (and this is about a decade old) around the assumption that
the NetView administrator, like the NetView installer, will be, and should be,
root.
This assumption is not unreasonable. The NetView box should only be running
NetView and other network-related apps like Nways, CiscoView, and so on. Note
that we are talking about an "administrator" here, one who changes or configures
things, and thus decides how they should be run, as opposed to an "operator" who
just uses what the administrator has set up. We expect the NetView
administrator to be totally in charge of the NetView box. We expect him to
start and stop any and all daemons( not just our own but snmpd and perhaps
others too), to expand the /usr filesystem before it gets full, to expand
paging space as needed, and even to reboot the box as required. We make no
bones about this. There are many, many places in NetView code where we
explicitly check to see if the user running a command is root. You can see
this in the even the script to start the GUI: netview. If a required daemon is
down, and root runs netview, it will be restarted, but otherwise not. You
cannot configure trapd.conf using xnmtrap nor edit production rulesets unless
you are root, and I don't believe this is just a matter of permissions. (I
could be wrong of course or perhaps you could find a way around that too).
Now I am glad that Leslie knows a way that the Tivoli desktop functions can be
performed by a non-root user, and that's fine if everything you ever want to do
is provided in the desktop GUI. But I doubt that it is. And sooner or later I
think you will need to be root to do something to the box on behalf of NetView.
If you don't like this, then you can complain to development via a note to
netview@tivoli.com when you run into such a problem, but as of right now, these
are the facts, and we have no stated direction to provide for a pseudo-root user
to do everything you might need to do to administer NetView. Besides, even if
we did, it would then ultimately be only a question of semantics, because if the
pseudo-root user gets authority to do absolutely everything he might need to do,
then he might as well be called "root".
One man's opinion, and speaking only for myself, of course, the NetView
administrator should be root. Else you had better be real good friends with
whoever has that authority and make sure that they are available whenever you
are.
James Shanks
Tivoli (NetView for UNIX) L3 Support
---------------------- Forwarded by James Shanks/Tivoli Systems on 09/10/99
11:24 AM ---------------------------
Leslie Clark <lclark@US.IBM.COM> on 09/09/99 01:49:59 PM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on NetView
<NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: James Shanks/Tivoli Systems)
Subject: Re: NV 5.1.1 non-root administrator
Alain, this is a pretty painful process at sites where there are very strict
rules about the use of root. You just keep on finding things that you need
root for. The simplest approach is to take advantage of the Tivoli Framework
facilities, if your security folks will accept it. Here's how:
You Create a Tivoli Administrator with only the NetviewServer balloon-thing
on it. Under Logins, you put the unix login of your non-root administrator,
perhaps
limiting it to <userid>@<hostname>. So when that userid invokes 'tivoli' they,
will
get that desktop, and only that user can get that desktop. Under Properties,
where it says user and group, you put root and system or something. So functions
you execute from that Desktop will execute as root, but you never have to know
the
root password, and you cannot execute anything except the menu functions on the
NetviewServer icon.
This passes muster with all customers except those who object to having
any processes running under root except operating system processes,
and they are a real minority.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
(NV 5.1.1 on 1IX 4.2.1)
Hi all,
Due to extensive security, we have to create a user who will be the NetView
administrator; some permissions of files can be changed to satisfy this
request (netview user security, trapd.conf, ...) but what about daemons
management (configure, maintain on the Tivoli desktop, start, stop, options,
...) ? Is this possible ?
Thanks
Alain
-----------------------
Alain Menezes
ASLK-CGER Services GIE *: +32 2 228.55.74
Rue Foss
é-aux-Loups, 48 *: +32 2 228.83.69
1000 Bruxelles *:
Alain.Menezes@fortisbank.com
SDFG
|