Description of problem: Installation of Satellite 3.4 failed for a system which had NIS enabled. Disabling NIS allowed proper installation to proceed. Installer failure indications did not suggest the underlying cause. Version-Release number of selected component (if applicable): Satellite 3.4.0-38. The installer failed at the point where the database instance was first created. Failure dialog gave text "sat-install db connect errors: (rhnsat/rhnsat@(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521)) ) (CONNECT_DATA = (SID = rhnsat) ) )): 12541: ORA-12541: TNS:no listener" The underlying cause ended up being that user/group oracle was/were already defined in NIS. Installation succeeded after NIS was shutdown (service ypbind stop). I suggest that the installer better test for the possibility of username collision and abort with an obvious error message. I suggest that the installer documentation indicate the possibility of name collision.
I encountered this same issue, and had in my inbox to create a bugzilla on this to have documented that NIS + Satellite does not always mix well. I would suggest to change the satellite install script logging to show exit status and/or command output - reviewing the log file you do not know/see that the usermod command failed. It took me some tracking down before I relealised that the cause of my installer failure was due to not being able to correctly add/modify the oracle user group permissions. Cliff. + mkdir -p /rhnsat + chown oracle:dba /rhnsat + usermod -G oracle,dba,apache oracle + su - oracle -c '~/admin/9.2.0/create-db.sh --db rhnsat --user rhnsat -- password rhnsat --datadir /rhnsat/data/rhnsat --admindir /rhnsat/admin/rhnsat'
mass reassign to mmccune