This content has been marked as final. Show 9 replies
Personally I'd blow away the operating system and start over because I've never seen this before and the fact that you are makes it very suspicious that something, somewhere, is corrupt.
The SA who set it up is having a look before we go that route. But there certainly are not two accounts with a uid of 0 in the /etc/paswd file.
We were missing a couple of RPM's as well, now that they are on I'll have another go next week.
I'd also look for
- any duplicated UID entries (other than '0') in both the password and shadow password file
- any issues with GID 0, and whether the Oracle user is allowed GID 0
- the state of SELinux ... I've found 'interesting' side effects when enabled so I currently only use permissive.
SELinux is disabled.
I cannot see that the shadow file contains a uid.
Thanks for the suggestions though.
I think it maybe because this machine is set-up with NIS accounts and one of them has a UID of 0, but I decided to log an SR with Oracle.
To test your NIS theory: ypcat | grep :0:
To test your dupe UID: cat /etc/passwd | grep :0: && cat /etc/shadow | grep :0:
Also take a look at your /etc/nsswitch.conf for anything interesting... (or unusual).
Hope this helps or even answers your question!
Well my SR with Oracle made me none the wiser about what's being done. The analyst refused to answer the question about what the installer is actually doing.
Never mind, not a big deal, just ignore this check.
Thank you for pointing out that ignoring the silly check works. FYI - for silent install, can pass in the -ignorePrereq param to bypass this.
2 years on from this I am seeing the same issue with server install. In my case I know that there are duplicate uid 0 users. We intentionally create named root users e.g adm_jblogs which are uid 0. In this way we can give root access to a number of engineers without having to share the root password which the auditors are so against.
(Basically if an engineer needs to be restricted from access e.g when leaving we disable his account only)
Also in this way we can see who is logged in at any one time instead of seeing anoymous "root" session.
Anyway enough of background ...... What is the actual issue with the installer seeing these duplicate uid 0 acccounts?
Is there way of disabling this check.
Worse is when you try and run any of the de-install scripts they will claim you are not root because your username is not root.