| Sandy,
How about suggesting that they use edauth instead? With edauth
you can do things like write scripts to add or modify bunches of
users, etc. I'd suggest useradd and usermod, but I've heard of
problems with them.
Another suggestion would be to leave the dxaccounts window up all
the time (assuming that the major time lag is at startup and not
in adding/modifying users accounts). Of course, they've probably
already thought of this. Unfortunately, I'm not sure if a combination
of edauth and dxaccounts would work very well, I think dxaccounts
might not always "see" changes made by edauth.
Has the customer converted to the .db format databases? I know that
the old text databases were causing a variety of slow responses.
How many users does the customer have?
Ann
[Posted by WWW Notes gateway]
|
|
Paul,
How many user accounts are on the machine? From the slow startup time
I'm guessing several thousand. The current GUI will not scale to this
number of accounts (1K acounts takes about a minute of startup time
and it gets exponentionally worse).
The problem is one that we aware of in V4.0 but didn't have time to fix.
We just fixed it and and the fix will be in the next major release of
Digital UNIX. It's a large change so it's not clear at this point
if we can get it into a patch kit.
The root of the problem is CDE/Motif's drop-site registration and
keyboard traversal. You can drag and drop a user icon to a group icon
and vice versa. That menas that each icon is registered as a valid drop site.
The problem is that as you add each new drop site Motif does a linear
search of the existing drop site list. It does the same thing for keyboard
traversal. For the next release we changed the code to
not do per-icon drop site registrations at all. We have to handle all the
drag over/drag under effects manually and also manually calculate the proper
drop site based on the x,y of the drop. There was actually a lot of other
issues/cleanups, but this is the gist of the performance improvements.
It's a lot more code but the good news is that the performance is order of
magnitude better. Our startup time for 10,000 users is now approximately 24
seconds (this is for base security. I don't have a C2 number handy).
For V4.0 this took over an hour.
I haven't tried this personally, but if you don't use the drag and drop
feature you can use a resource to disable it. This might bypass the
performance hits of the per-icon drop site registration. To do this, specify
the
following resources:
*.dragInitiatorProtocolStyle: DRAG_NONE
*.dragReceiverProtocolStyle: DRAG_NONE
For example, you can run dxaccounts using the following syntax:
dxaccounts -xrm "*.dragInitiatorProtocolStyle: DRAG_NONE" \
-xrm "*.dragReceiverProtocolStyle: DRAG_NONE"
or simply place these resources in /usr/lib/X11/app-defaults/Dxaccounts
or /Dxaccounts. Please let me know if these resources help you out .
A related question. Assuming dxaccounts did not have this performance
issue, what do you think of it? Does it help you to manage your
accounts? What additional features would you like to see added to it?
Thanks,
pete
+-------------------------------------------------------------------------+
|Peter Wolfe, UNIX Systems Management Engineering [email protected] |
|Digital Equipment Corp (908) 577-6010 |
|200 Rt 9 North, Manalapan, NJ 07726 |
+-------------------------------------------------------------------------+
>From [email protected] Wed Apr 9 19:45:08 1997
Sender: [email protected]
Followup-To: poster
Precedence: bulk
Date: Wed, 9 Apr 1997 18:35:42 -0500 (CDT)
From: "Paul N. Youngblood" <[email protected]>
To: [email protected]
Subject: dxaccounts GUI has VERY SLOW Startup
Hello Digital UNIX Managers,
I am running DU v4.0B with patch kit 2 on an AlphaServer 2100.
All file systems are AdvFS, and we run the C2 Security option.
This 2100 has 128 Mb of RAM. It functions as an email server,
never has more that 40 users logged on simultaneously, and runs
no user applications, compilers, or anything else. It is just
an email server - most people log in to check their mail with
pine, with a very few using the POP server software that it runs.
My problem is with the Account Manager GUI, dxaccounts.
Once invoked, it literally takes a full 7 minutes for this GUI
to appear at the console. If I invoke it from a remote workstation,
it takes 16 to 20 minutes to appear! Before we installed the patch
kit from Digital for this version of Digital UNIX, the problem was
MUCH, MUCH worse. Swap space seems fine during this time, so I
don't think that is the problem. Does anyone have suggestions on
how to speed up the startup time for this GUI ??? I will
certainly summarize.
Paul Youngblood
University of Alabama in Huntsville
[email protected]
|
| What I didn't tell him is what .1 said. No matter how many accounts
the gui handles well there will always be cases where you want more
and the current design simply won't scale there. Do you really
want to look at 10K icons or 10K entries in a list box/combo box?
Assuming 10K is OK what about 100K or a million? GUI's don't do well
with this large number of objects. The standard workaround at that point
is to not use the GUI and instead use cli commands like edauth,
useradd/mod/del, groupadd/mod/del.
Pete
|
| Yes, the cli commands work with c2 but in V4.0, you have little/no control over
individual C2 attributes. The account gets whatever is in the default template
in terms of attributes. The only exception is the -e expire and -f inactive
flags. In the next major release of the OS, we are planning on enhancing
this to provide control over more attributes.
Pete
|