On 27 May, 18:25, sdhaya wrote:
> While using SCOADMIN to create new accounts after inputting the
> require fields, the process does not complete and instead I see stars
> (*****) on top of the menu. To rectify the problem, we have to restart
> the machines. Please advice how to correct the problem without
> restarting the Server. Is there any process which needs to be killed.
> In the first place why is this happening.
>
> Please advise..
>
> Dhaya

Hard to tell: what does 'useradd' say if you try to create an account
manually? As near as I can tell, that's the command that is actually
called by the scoadmin tool. And what does the 'ap' tool say about
recording account information?

It may also be that you've introduced a discrepancy between /etc/
passwd and /etc/shadow by editing manually, or that some clever person
screwed up /etc/passwd.

sdhaya wrote:
> While using SCOADMIN to create new accounts after inputting the
> require fields, the process does not complete and instead I see stars
> (*****) on top of the menu. To rectify the problem, we have to restart
> the machines.

That should not be necessary.

> Please advice how to correct the problem without
> restarting the Server. Is there any process which needs to be killed.

Possibly. There's perhaps some process that emitted an error message
somewhere and then died prematurely leaving the front end waiting.

I'd use 'ps -ef' to identify the "hanging" process. I'd then maybe make
judicious use of kill starting with the gentler signal levels.

> In the first place why is this happening.

You don't provide much information. This is OpenServer 5.0.something
with MP.somenumber isn't it? OSR has tools to verify critical files,
that might or might not help.

--
RGB

On May 27, 9:45*pm, Nico Kadel-Garcia wrote:
> On 27 May, 18:25, sdhaya wrote:
>
> > While using SCOADMIN to create new accounts after inputting the
> > require fields, the process does not complete and instead I see stars
> > (*****) on top of the menu. To rectify the problem, we have to restart
> > the machines. Please advice how to correct the problem without
> > restarting the Server. Is there any process which needs to be killed.
> > In the first place why is this happening.
>
> > Please advise..
>
> > Dhaya
>
> Hard to tell: what does 'useradd' say if you try to create an account
> manually? As near as I can tell, that's the command that is actually
> called by the scoadmin tool. And what does the 'ap' tool say about
> recording account information?
>
> It may also be that you've introduced a discrepancy between /etc/
> passwd and /etc/shadow by editing manually, or that some clever person
> screwed up /etc/passwd.

If star's appear in the SCOAdmin, the user "useradd" function also
hangs. Not tried the "ap" tool. Can this solve the issue?.

Thanks

Dhaya

On May 27, 11:43*pm, RedGrittyBrick
wrote:
> sdhaya wrote:
> > While using SCOADMIN to create new accounts after inputting the
> > require fields, the process does not complete and instead I see stars
> > (*****) on top of the menu. To rectify the problem, we have to restart
> > the machines.
>
> That should not be necessary.
>
> > Please advice how to correct the problem without
> > restarting the Server. Is there any process which needs to be killed.
>
> Possibly. There's perhaps some process that emitted an error message
> somewhere and then died prematurely leaving the front end waiting.
>
> I'd use 'ps -ef' to identify the "hanging" process. I'd then maybe make
> judicious use of kill starting with the gentler signal levels.
>
> > In the first place why is this happening.
>
> You don't provide much information. This is OpenServer 5.0.something
> with MP.somenumber isn't it? OSR has tools to verify critical files,
> that might or might not help.
>
> --
> RGB

We are using SCO Open Server 5.0.6 with SMP. ( 4 Processors ). I am
unable to pinpoint the process which is used by scoadmin account
creation. Any clues.

Dhaya

On 28 May, 03:45, sdhaya wrote:
> On May 27, 11:43*pm, RedGrittyBrick
> wrote:
>
>
>
>
>
> > sdhaya wrote:
> > > While using SCOADMIN to create new accounts after inputting the
> > > require fields, the process does not complete and instead I see stars
> > > (*****) on top of the menu. To rectify the problem, we have to restart
> > > the machines.
>
> > That should not be necessary.
>
> > > Please advice how to correct the problem without
> > > restarting the Server. Is there any process which needs to be killed.
>
> > Possibly. There's perhaps some process that emitted an error message
> > somewhere and then died prematurely leaving the front end waiting.
>
> > I'd use 'ps -ef' to identify the "hanging" process. I'd then maybe make
> > judicious use of kill starting with the gentler signal levels.
>
> > > In the first place why is this happening.
>
> > You don't provide much information. This is OpenServer 5.0.something
> > with MP.somenumber isn't it? OSR has tools to verify critical files,
> > that might or might not help.
>
> > --
> > RGB
>
> We are using SCO Open Server 5.0.6 with SMP. ( 4 Processors ). I am
> unable to pinpoint the process which is used by scoadmin account
> creation. Any clues.
>
> Dhaya- Hide quoted text -
>
> - Show quoted text -

I'm pretty sure, from it's behavior, that it's 'usreadd'. It sounds
like some sort of error has crept into your /etc/passwod and/or your /
etc/shadow files, but I can't swear to that. Are you running NIS or
another other tools that also handle user accounts? And can you review
your passwd nad shadow files for consistency, and for formatting
errors?

I've seen so many people screw up passwd files with badly written
account generation tools, it's just scary.

sdhaya wrote:
> On May 27, 11:43 pm, RedGrittyBrick
> wrote:
>> sdhaya wrote:
>>> While using SCOADMIN to create new accounts after inputting the
>>> require fields, the process does not complete and instead I see stars
>>> (*****) on top of the menu. To rectify the problem, we have to restart
>>> the machines.
>> That should not be necessary.
>>
>>> Please advice how to correct the problem without
>>> restarting the Server. Is there any process which needs to be killed.
>> Possibly. There's perhaps some process that emitted an error message
>> somewhere and then died prematurely leaving the front end waiting.
>>
>> I'd use 'ps -ef' to identify the "hanging" process. I'd then maybe make
>> judicious use of kill starting with the gentler signal levels.
>>
>>> In the first place why is this happening.
>> You don't provide much information. This is OpenServer 5.0.something
>> with MP.somenumber isn't it? OSR has tools to verify critical files,
>> that might or might not help.
>>
> We are using SCO Open Server 5.0.6 with SMP. ( 4 Processors ). I am
> unable to pinpoint the process which is used by scoadmin account
> creation. Any clues.
>

I logged in as root, used `tty` to find my tty number then ran scoadmin.
On another terminal I used ...

> ps -e | grep ttyp0
764 ttyp0 00:00:00 ksh
828 ttyp0 00:00:00 sh
834 ttyp0 00:00:00 scoadmin
835 ttyp0 00:00:00 cm_vtcld
837 ttyp0 00:00:00 activate.scoad
839 ttyp0 00:00:00 accountGUI


--
RGB

On May 28, 12:06*pm, RedGrittyBrick
wrote:
> sdhaya wrote:
> > On May 27, 11:43 pm, RedGrittyBrick
> > wrote:
> >> sdhaya wrote:
> >>> While using SCOADMIN to create new accounts after inputting the
> >>> require fields, the process does not complete and instead I see stars
> >>> (*****) on top of the menu. To rectify the problem, we have to restart
> >>> the machines.
> >> That should not be necessary.
>
> >>> Please advice how to correct the problem without
> >>> restarting the Server. Is there any process which needs to be killed.
> >> Possibly. There's perhaps some process that emitted an error message
> >> somewhere and then died prematurely leaving the front end waiting.
>
> >> I'd use 'ps -ef' to identify the "hanging" process. I'd then maybe make
> >> judicious use of kill starting with the gentler signal levels.
>
> >>> In the first place why is this happening.
> >> You don't provide much information. This is OpenServer 5.0.something
> >> with MP.somenumber isn't it? OSR has tools to verify critical files,
> >> that might or might not help.
>
> > We are using SCO Open Server 5.0.6 with SMP. ( 4 Processors ). I am
> > unable to pinpoint the process which is used by scoadmin account
> > creation. Any clues.
>
> I logged in as root, used `tty` to find my tty number then ran scoadmin.
> On another terminal I used ...
>
> *> ps -e | grep ttyp0
> * *764 * ttyp0 * *00:00:00 ksh
> * *828 * ttyp0 * *00:00:00 sh
> * *834 * ttyp0 * *00:00:00 scoadmin
> * *835 * ttyp0 * *00:00:00 cm_vtcld
> * *837 * ttyp0 * *00:00:00 activate.scoad
> * *839 * ttyp0 * *00:00:00 accountGUI
>
> --
> RGB- Hide quoted text -
>
> - Show quoted text -

Thanks for the info.. Will try it out

On 27 May, 18:25, sdhaya wrote:
> While using SCOADMIN to create new accounts after inputting the
> require fields, the process does not complete and instead I see stars
> (*****) on top of the menu. To rectify the problem, we have to restart
> the machines. Please advice how to correct the problem without
> restarting the Server. Is there any process which needs to be killed.
> In the first place why is this happening.
>
> Please advise..
>
> Dhaya

See section 4 of:

http://www.sco.com/ta/104907

to check and see what is wrong with the integrity of the
security subsystem.

John

On Tue, 27 May 2008 10:25:45 -0700 (PDT), sdhaya
wrote:

>While using SCOADMIN to create new accounts after inputting the
>require fields, the process does not complete and instead I see stars
>(*****) on top of the menu. To rectify the problem, we have to restart
>the machines. Please advice how to correct the problem without
>restarting the Server. Is there any process which needs to be killed.
>In the first place why is this happening.
>
>Please advise..
>
>Dhaya

If scoadmin is producing any errors they should be found in
/usr/adm/syslog or /usr/adm/messages.


Scott McMillan

On May 28, 4:08*pm, Scott McMillan wrote:
> On Tue, 27 May 2008 10:25:45 -0700 (PDT), sdhaya
>
> wrote:
> >While using SCOADMIN to create new accounts after inputting the
> >require fields, the process does not complete and instead I see stars
> >(*****) on top of the menu. To rectify the problem, we have to restart
> >the machines. Please advice how to correct the problem without
> >restarting the Server. Is there any process which needs to be killed.
> >In the first place why is this happening.
>
> >Please advise..
>
> >Dhaya
>
> If scoadmin is producing any errors they should be found in
> /usr/adm/syslog or /usr/adm/messages.
>
> Scott McMillan

Is the scoadmin multi Users. Can 3 or 4 users create/delete/amend User
profiles at the same time?

Dhaya

sdhaya wrote:
> On May 28, 4:08 pm, Scott McMillan wrote:
>> On Tue, 27 May 2008 10:25:45 -0700 (PDT), sdhaya
>>
>> wrote:
>>> While using SCOADMIN to create new accounts after inputting the
>>> require fields, the process does not complete and instead I see stars
>>> (*****) on top of the menu. To rectify the problem, we have to restart
>>> the machines. Please advice how to correct the problem without
>>> restarting the Server. Is there any process which needs to be killed.
>>> In the first place why is this happening.
>>> Please advise..
>>> Dhaya
>> If scoadmin is producing any errors they should be found in
>> /usr/adm/syslog or /usr/adm/messages.
>>
>> Scott McMillan
>
> Is the scoadmin multi Users. Can 3 or 4 users create/delete/amend User
> profiles at the same time?
>
> Dhaya

Without source code, it's difficult to tell. If the tool is using 'useradd'
and 'usermod' behind the scenes, which is consistent with the interface's
options, useradd uses lock files to prevent simultaneous editing. It's tricky,
though: one root user's request to change a user's password or shell may be
superceded by another user's request, very shortly thereafter, and become
quite confusing.

This is a fundamental limit of the /etc/passwd, /etc/group, /etc/shadow, etc.
flat file system technology for storing account information. Way back in the
old days of UNIX, you had *one* admin, or people who worked together gracefully.

If you need to do this sort of multiple-admin handling of a lot of accounts,
or complex account setups, use 'webmin' rather than scoadmin: it's a much
saner, open sourced, and well-understood interface.

On May 31, 2:49*pm, Nico Kadel-Garcia wrote:
> sdhaya wrote:
> > On May 28, 4:08 pm, Scott McMillan wrote:
> >> On Tue, 27 May 2008 10:25:45 -0700 (PDT), sdhaya
>
> >> wrote:
> >>> While using SCOADMIN to create new accounts after inputting the
> >>> require fields, the process does not complete and instead I see stars
> >>> (*****) on top of the menu. To rectify the problem, we have to restart
> >>> the machines. Please advice how to correct the problem without
> >>> restarting the Server. Is there any process which needs to be killed.
> >>> In the first place why is this happening.
> >>> Please advise..
> >>> Dhaya
> >> If scoadmin is producing any errors they should be found in
> >> /usr/adm/syslog or /usr/adm/messages.
>
> >> Scott McMillan
>
> > Is the scoadmin multi Users. Can 3 or 4 users create/delete/amend User
> > profiles at the same time?
>
> > Dhaya
>
> Without source code, it's difficult to tell. If the tool is using 'useradd'
> and 'usermod' behind the scenes, which is consistent with the interface's
> options, useradd uses lock files to prevent simultaneous editing. It's tricky,
> though: one root user's request to change a user's password or shell may be
> superceded by another user's request, very shortly thereafter, and become
> quite confusing.
>
> This is a fundamental limit of the /etc/passwd, /etc/group, /etc/shadow, etc.
> flat file system technology for storing account information. Way back in the
> old days of UNIX, you had *one* admin, or people who worked together gracefully.
>
> If you need to do this sort of multiple-admin handling of a lot of accounts,
> or complex account setups, use 'webmin' rather than scoadmin: it's a much
> saner, open sourced, and well-understood interface.- Hide quoted text -
>
> - Show quoted text -

The problem has occured again. Now when we invoke "scoadmin" and
select "Account Manager", the users list does not appear. I have
managed to get the processes related to sco currently running :-

# ps -ef | grep -i "sco"
root 65 59 0 May-26 ? 00:00:00 /etc/sco_cpd
root 245 1 0 May-26 ? 00:00:00 /opt/K/SCO/lli/
5.0.6a/bin/dlpid /var/opt/K/SCO/lli/5.0.6a/dlpidPIPE
root 463 1 0 May-26 ? 00:00:00 /usr/lib/scosh/
calserver
root 465 463 0 May-26 ? 00:00:00 /usr/lib/scosh/
calserver
root 450 1 0 May-26 ? 00:00:00 /var/scohttp/
scohttpd -d /var/scohttp
root 556 1 0 May-26 ? 00:00:00 /usr/lib/scosh/
caldaemon
root 13611 9975 2 07:21:56 ttyp12 00:00:00 grep -i sco
root 22920 22879 0 Jun-02 ? 00:00:00 dlvr_audit
1212381561 12 26 22879 sco_C_osa 0 auth 12 Updated passwd file entry
root 22879 1 0 Jun-02 ? 00:00:00 /opt/K/SCO/Unix/
5.0.6Ga/sa/account/userOsa
root 4848 1 0 09:04:48 ? 00:00:00 /opt/K/SCO/Unix/
5.0.6Ga/sa/account/userOsa
root 4871 1 0 09:05:33 ? 00:00:00 /opt/K/SCO/Unix/
5.0.6Ga/sa/account/userOsa
root 5122 1 0 09:25:08 ? 00:00:00 /opt/K/SCO/Unix/
5.0.6Ga/sa/account/userOsa

Can anybody advice if any of the above processes are holding the
passwd/shadow files and not releasing. Can we kill these processes and
try. We are running our core authorization system in this box and I
don't want to take any chances.

Dhaya

sdhaya wrote:
> On May 31, 2:49 pm, Nico Kadel-Garcia wrote:
>> sdhaya wrote:
>>> On May 28, 4:08 pm, Scott McMillan wrote:
>>>> On Tue, 27 May 2008 10:25:45 -0700 (PDT), sdhaya
>>>> wrote:
>>>>> While using SCOADMIN to create new accounts after inputting the
>>>>> require fields, the process does not complete and instead I see stars
>>>>> (*****) on top of the menu. To rectify the problem, we have to restart
>>>>> the machines. Please advice how to correct the problem without
>>>>> restarting the Server. Is there any process which needs to be killed.
>>>>> In the first place why is this happening.
>>>>> Please advise..
>>>>> Dhaya
>>>> If scoadmin is producing any errors they should be found in
>>>> /usr/adm/syslog or /usr/adm/messages.
>>>> Scott McMillan
>>> Is the scoadmin multi Users. Can 3 or 4 users create/delete/amend User
>>> profiles at the same time?
>>> Dhaya
>> Without source code, it's difficult to tell. If the tool is using 'useradd'
>> and 'usermod' behind the scenes, which is consistent with the interface's
>> options, useradd uses lock files to prevent simultaneous editing. It's tricky,
>> though: one root user's request to change a user's password or shell may be
>> superceded by another user's request, very shortly thereafter, and become
>> quite confusing.
>>
>> This is a fundamental limit of the /etc/passwd, /etc/group, /etc/shadow, etc.
>> flat file system technology for storing account information. Way back in the
>> old days of UNIX, you had *one* admin, or people who worked together gracefully.
>>
>> If you need to do this sort of multiple-admin handling of a lot of accounts,
>> or complex account setups, use 'webmin' rather than scoadmin: it's a much
>> saner, open sourced, and well-understood interface.- Hide quoted text -
>>
>> - Show quoted text -
>
> The problem has occured again. Now when we invoke "scoadmin" and
> select "Account Manager", the users list does not appear. I have
> managed to get the processes related to sco currently running :-
>
> # ps -ef | grep -i "sco"
> root 65 59 0 May-26 ? 00:00:00 /etc/sco_cpd
> root 245 1 0 May-26 ? 00:00:00 /opt/K/SCO/lli/
> 5.0.6a/bin/dlpid /var/opt/K/SCO/lli/5.0.6a/dlpidPIPE
> root 463 1 0 May-26 ? 00:00:00 /usr/lib/scosh/
> calserver
> root 465 463 0 May-26 ? 00:00:00 /usr/lib/scosh/
> calserver
> root 450 1 0 May-26 ? 00:00:00 /var/scohttp/
> scohttpd -d /var/scohttp
> root 556 1 0 May-26 ? 00:00:00 /usr/lib/scosh/
> caldaemon
> root 13611 9975 2 07:21:56 ttyp12 00:00:00 grep -i sco
> root 22920 22879 0 Jun-02 ? 00:00:00 dlvr_audit
> 1212381561 12 26 22879 sco_C_osa 0 auth 12 Updated passwd file entry
> root 22879 1 0 Jun-02 ? 00:00:00 /opt/K/SCO/Unix/
> 5.0.6Ga/sa/account/userOsa
> root 4848 1 0 09:04:48 ? 00:00:00 /opt/K/SCO/Unix/
> 5.0.6Ga/sa/account/userOsa
> root 4871 1 0 09:05:33 ? 00:00:00 /opt/K/SCO/Unix/
> 5.0.6Ga/sa/account/userOsa
> root 5122 1 0 09:25:08 ? 00:00:00 /opt/K/SCO/Unix/
> 5.0.6Ga/sa/account/userOsa
>
> Can anybody advice if any of the above processes are holding the
> passwd/shadow files and not releasing. Can we kill these processes and
> try. We are running our core authorization system in this box and I
> don't want to take any chances.
>
> Dhaya

Have you rebooted this box? And my working guess is that you've got various
'users0a' because those are various copies of the scoadmin tool that you're
running. Shut them all *down*, and work with 'useradd' or 'usermod' directly.
If those don't work, I suspect your /etc/passwd or /etc/shadow or /etc/group
may be munged up and need editing manually. But at least you'll get readable
command-line error messages.

The scoadmin tool is not a complete tool. It is a *wrapper* for other tools,
and not a very good one in my experience with OpenServer 5.0.6. Thus, assuming
that processes named 'sco' are all the processes related to SCO is a bad
assumption, since SCO need not appear in the name at all. And all processes
from /opt/K/SCO/ will have it in their name, anyway.

Dhaya wrote:

> The problem has occured again. Now when we invoke "scoadmin" and
> select "Account Manager", the users list does not appear. I have
> managed to get the processes related to sco currently running :-
>
> # ps -ef | grep -i "sco"
....
> root 22920 22879 0 Jun-02 ? 00:00:00 dlvr_audit 1212381561 12 26 22879 sco_C_osa 0 auth 12 Updated passwd file entry

> Can anybody advice if any of the above processes are holding the
> passwd/shadow files and not releasing. Can we kill these processes and
> try. We are running our core authorization system in this box and I
> don't want to take any chances.

Nico Kadel-Garcia replied:

> The scoadmin tool is not a complete tool. It is a *wrapper* for other tools,
> and not a very good one in my experience with OpenServer 5.0.6. Thus, assuming
> that processes named 'sco' are all the processes related to SCO is a bad
> assumption, since SCO need not appear in the name at all. And all processes
> from /opt/K/SCO/ will have it in their name, anyway.

You are right that his assumption was bad, but as I've picked out above,
he did actually capture the issue.

Dhaya, this is a Frequently Asked Question. There are about 20 threads
about it in the comp.unix.sco.misc archives (on groups.google.com), and
SCO has a Technical Article with the solution:

http://www.sco.com/ta/109461

The oldest online solution I can find recently had its 11th birthday:

http://groups.google.com/group/comp....61894b35de9ecc

>Bela<