Red Hat Bugzilla – Bug 484673
unable to install without TTY
Last modified: 2009-09-10 16:32:46 EDT
Description of problem: I'm unable to install 20090206.1 RHEL-5 Satellite using RHTS script (I was able to install 5.2.0 Satellite) - installer wants TTY. I can fix the test to provide it, but automated installation (with answers file) should not enforce it. Version-Release number of selected component (if applicable): Satellite-5.3.0-RHEL5-re20090206.1 How reproducible: always Steps to Reproduce: 1. /mnt/redhat/devel/candidate-trees/Satellite-5.3.0-RHEL5-re20090206.1/i386/i386//install.pl --answer-file=/mnt/tests/CoreOS/RHN-Satellite/Inter-Satellite-Sync/Sanity/general/answers.txt --non-interactive --disconnected --run-updater Actual results: * Enabling Monitoring. sudo: sorry, you must have a tty to run sudo RHN::Exception: There was a problem updating your configuration. See the webserver error log for details. RHN::SatInstall /usr/lib/perl5/vendor_perl/5.8.8/RHN/SatInstall.pm 117 RHN::Exception::throw main /usr/bin/spacewalk-setup 1194 RHN::SatInstall::write_config main /usr/bin/spacewalk-setup 132 main::setup_monitoring Expected results: Installation works Additional info: RHTS test in question: http://rhts.redhat.com/cgi-bin/rhts/jobs.cgi?id=45285 Logs for i386 system: http://rhts.redhat.com/testlogs/45285/154425/1290317/logs.45285_154425_1290317.tar.gz
Approved. It appears the problem is with: RHN::SatInstall->write_config({ monitoringDOTscout_shared_key => $scout_shared being used instead of standard write_config used elsewhere in /usr/bin/spacewalk-setup. *Theoretically* just changing the 'RHN::SatInstall->write_config' to 'write_config' may solve the problem. But then we have the next question, of why do we have a local write_config and another write_config function in RHN/SatInstall.pm. Regardless, Cliff and I both think it should be fixed as we don't want to have QA doing workarounds in the installation automation efforts.
In fact, I changed that write_config invocation today in Spacewalk, independently from this bugzilla. So this problem should not appear anymore because that sudo will not be run. However: we should really make sure that the sudoers is sane upon installation. So: why didn't sudo work in this situation? Was it the first time non-tty installation was tried?
Assume the fairly new RHTS automated installer path high lighted this issue. Cliff Care to move to modified Jan? :)
Modified in Spacewalk, commit fac483b1bb84aaa57bb15227418293f7da74da71.
VERIFIED with Satellite-5.3.0-RHEL5-re20090327.0-x86_64 [...] * Enabling Monitoring. * Configuring apache SSL virtual host. [...]
Installed Satellite multiple times without this issue.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-1434.html