Description of problem: When running engine-setup --generate-answer=file or when using an answer's file that includes answers to questions related to Apache Configuration it does not work. The question this fails on is: Apache httpd SSL was already configured in the past, but some needed changes are missing there. Configure again? (Automatic, Manual) [Automatic]: Manual When generating an answers file and answering manual or automatic, then using this answers file, the user is still prompted for input. Version-Release number of selected component (if applicable): 4.2.3 How reproducible: Steps to Reproduce: 1. generate answers file where the Apache config question above is asked 2. try to use the generated answers file 3. it will prompt for input Actual results: engine-setup prompts for input Expected results: The engine-setup completes without user intervention Additional info: I was able to work around this by adding this to the answers file: QUESTION/1/OVESETUP_APACHE_RECONFIG_SSL=str:'manual' The issue is not resolved though, as this should be handled automatically when the answers file is generated. Customer is requesting this to be fixed.
I'd rather not solve this bug, and suggest instead to use otopi-style answer files. These will be the default in 4.3, see bug 1518697. For how to generate/use these, see bug 1396925 comment 5 (and all of it). See also bug 1518697 (and bug 1541947 in 4.2) for a similar case, which QE agreed to not fix in 4.2. For now, moving to 4.3 and to MODIFIED. If you still want it in 4.2, please clone. Thanks.
To clarify: All of this already works in 4.2. The only difference in 4.3 will be that engine-setup will only generate otopi-style answer files, whereas in 4.2 it keeps generating by default its own style. If you use 'DIALOG/answerFile', it will generate both (only in 4.2, not 4.3). Mixing (parts of) these files is not considered supported nor fully tested, but does work, and in theory can be useful, which is exactly what you did in "Additional Info". You might consider also changing the linked article accordingly. BTW, there is no technical reason, code-wise, to not do the move in 4.2 (bug 1518697). The only reason was that we thought this was a rather large change, and wanted to first have some feedback from customers manually trying it (by manually using DIALOG/answerFile). If you feel otherwise, please ask to have bug 1518697 in 4.2.
I've tried to run 'engine-setup --generate-answer=answerfile' on engine and did not seen anything related to Apache during the session: http://pastebin.test.redhat.com/671107 These are answerfile contents: # OTOPI answer file, generated by human dialog [environment:default] QUESTION/1/DWH_VACUUM_FULL=str:no QUESTION/1/ENGINE_VACUUM_FULL=str:no QUESTION/1/OVESETUP_CORE_ENGINE_STOP=str:ok QUESTION/1/OVESETUP_DIALOG_CONFIRM_SETTINGS=str:ok QUESTION/1/OVESETUP_DWH_PERFORM_BACKUP=str:yes QUESTION/1/OVESETUP_RPMDISTRO_PACKAGE_UPGRADE=str:yes QUESTION/1/OVESETUP_UPDATE_FIREWALL=str:yes /root/answerfile (END) Can you explain if its an expected behavior?
(In reply to Nikolai Sednev from comment #7) > I've tried to run 'engine-setup --generate-answer=answerfile' on engine and > did not seen anything related to Apache during the session: > http://pastebin.test.redhat.com/671107 This seems like an upgrade to me, not a clean setup. > > These are answerfile contents: > > # OTOPI answer file, generated by human dialog > [environment:default] > QUESTION/1/DWH_VACUUM_FULL=str:no > QUESTION/1/ENGINE_VACUUM_FULL=str:no > QUESTION/1/OVESETUP_CORE_ENGINE_STOP=str:ok > QUESTION/1/OVESETUP_DIALOG_CONFIRM_SETTINGS=str:ok > QUESTION/1/OVESETUP_DWH_PERFORM_BACKUP=str:yes > QUESTION/1/OVESETUP_RPMDISTRO_PACKAGE_UPGRADE=str:yes > QUESTION/1/OVESETUP_UPDATE_FIREWALL=str:yes > /root/answerfile (END) > > Can you explain if its an expected behavior? It is. In the past, upgrade never reconfigured httpd, so never asked about it. Since bug 1558500 we ask and reconfigure, but only if needed (usually if upgraded from 4.0). Old-style answer files could have included values not asked about. The logic was complex and key-specific. New-style (otopi) ones are purely a copy of the actual questions and answers actually asked. So if we do not ask about httpd, you won't find anything about it in the answer file. (That is, ignoring more complex cases where you feed a partial answer file, or use accept-defaults ( https://gerrit.ovirt.org/88278 ), etc.)
Making previous comments public, even though the first one includes a private link, because I think it's a useful clarification to have public.
Worked well on these components: ovirt-engine-setup-4.3.0-0.2.master.20181121071050.gita8fcd23.el7.noarch I did not seen any Apache configuration prompts during install from answerfile. nsednev-he-4 ~]# engine-setup --config-append=/root/answerfile [ INFO ] Stage: Initializing [ INFO ] Stage: Environment setup Configuration files: ['/etc/ovirt-engine-setup.conf.d/10-packaging-jboss.conf', '/etc/ovirt-engine-setup.conf.d/10-packaging.conf', '/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf', '/root/answerfile'] Log file: /var/log/ovirt-engine/setup/ovirt-engine-setup-20181122104942-9tfl3s.log Version: otopi-1.8.0_master (otopi-1.8.0-0.0.master.20181023084106.git607968f.el7) [ INFO ] Stage: Environment packages setup [ INFO ] Stage: Programs detection [ INFO ] Stage: Environment setup (late) [ INFO ] Stage: Environment customization --== PRODUCT OPTIONS ==-- --== PACKAGES ==-- [ INFO ] Checking for product updates... [ INFO ] No product updates found --== NETWORK CONFIGURATION ==-- Setup can automatically configure the firewall on this system. Note: automatic configuration of the firewall may overwrite current settings. NOTICE: iptables is deprecated and will be removed in future releases Do you want Setup to configure the firewall? (Yes, No) [Yes]: provided answer: yes [ INFO ] firewalld will be configured as firewall manager. --== DATABASE CONFIGURATION ==-- --== OVIRT ENGINE CONFIGURATION ==-- Perform full vacuum on the engine database engine@localhost? This operation may take a while depending on this setup health and the configuration of the db vacuum process. See https://www.postgresql.org/docs/9.0/static/sql-vacuum.html (Yes, No) [No]: --== STORAGE CONFIGURATION ==-- --== PKI CONFIGURATION ==-- --== APACHE CONFIGURATION ==-- --== SYSTEM CONFIGURATION ==-- --== MISC CONFIGURATION ==-- --== END OF CONFIGURATION ==-- [ INFO ] Stage: Setup validation [WARNING] Cannot validate host name settings, reason: resolved host does not match any of the local addresses [WARNING] Less than 16384MB of memory is available [ INFO ] Cleaning stale zombie tasks and commands --== CONFIGURATION PREVIEW ==-- Default SAN wipe after delete : False Firewall manager : firewalld Update Firewall : True Host FQDN : nsednev-he-4.scl.lab.tlv.redhat.com Engine database secured connection : False Engine database user name : engine Engine database name : engine Engine database host : localhost Engine database port : 5432 Engine database host name validation : False Engine installation : True PKI organization : scl.lab.tlv.redhat.com Set up ovirt-provider-ovn : False Configure WebSocket Proxy : False DWH installation : False Configure local DWH database : False Configure Image I/O Proxy : False Configure VMConsole Proxy : True Please confirm installation settings (OK, Cancel) [OK]: provided answer: ok [ INFO ] Cleaning async tasks and compensations [ INFO ] Unlocking existing entities [ INFO ] Checking the Engine database consistency [ INFO ] Stage: Transaction setup [ INFO ] Stopping engine service [ INFO ] Stopping ovirt-fence-kdump-listener service [ INFO ] Stopping vmconsole-proxy service [ INFO ] Stage: Misc configuration (early) [ INFO ] Stage: Package installation [ INFO ] Stage: Misc configuration [ INFO ] Upgrading CA [ INFO ] Creating CA [ INFO ] Setting up ovirt-vmconsole proxy helper PKI artifacts [ INFO ] Backing up database localhost:engine to '/var/lib/ovirt-engine/backups/engine-20181122105021.galq7w.dump'. [ INFO ] Creating/refreshing Engine database schema [ INFO ] Creating/refreshing Engine 'internal' domain database schema Unregistering existing client registration info. [ INFO ] Generating post install configuration file '/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf' [ INFO ] Stage: Transaction commit [ INFO ] Stage: Closing up [ INFO ] Starting engine service [ INFO ] Restarting ovirt-vmconsole proxy service --== SUMMARY ==-- [ INFO ] Restarting httpd Web access is enabled at: http://nsednev-he-4.scl.lab.tlv.redhat.com:80/ovirt-engine https://nsednev-he-4.scl.lab.tlv.redhat.com:443/ovirt-engine Internal CA AE:93:28:4E:AA:74:33:FC:0A:74:1E:E0:86:1C:D1:2A:32:FB:E4:30 SSH fingerprint: SHA256:Q/OfU6SaxO3axweqS7QTKKPJGw2uYBkOjslbwHrEKFo [WARNING] Less than 16384MB of memory is available The engine requires access to the Data Warehouse database. Data Warehouse was not set up. Please set it up on some other machine and configure access to it on the engine. --== END OF SUMMARY ==-- [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20181122104942-9tfl3s.log [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20181122105112-setup.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ INFO ] Execution of setup completed successfully Moving to verified.
You can't really verify this bug in 4.3 by upgrading from a clean 4.2 engine, because its engine-setup already configured httpd. If you want to verify this flow in 4.3, you can do something like this: 1. Install and setup a 4.2 engine 2. Manually edit ssl.conf to have something other than 'SSLProtocol all -SSLv2 -SSLv3' (e.g. comment out this line, or set it to its default, 'all -SSLv2') 3. Add 4.3 repo and update setup packages 4. Take a snapshot of the machine 5. Run engine-setup interactively, it should ask about httpd and reconfigure it 6. Copy the generated answer file somewhere, revert the machine to the snapshot, copy back the answer file, and run engine-setup with it It should not prompt about httpd, but the output should clarify that it wanted to, but got the answer from the answer file.
(In reply to Yedidyah Bar David from comment #11) > You can't really verify this bug in 4.3 by upgrading from a clean 4.2 > engine, because its engine-setup already configured httpd. If you want to > verify this flow in 4.3, you can do something like this: > > 1. Install and setup a 4.2 engine > 2. Manually edit ssl.conf to have something other than 'SSLProtocol all > -SSLv2 -SSLv3' (e.g. comment out this line, or set it to its default, 'all > -SSLv2') > 3. Add 4.3 repo and update setup packages > 4. Take a snapshot of the machine > 5. Run engine-setup interactively, it should ask about httpd and reconfigure > it > 6. Copy the generated answer file somewhere, revert the machine to the > snapshot, copy back the answer file, and run engine-setup with it > > It should not prompt about httpd, but the output should clarify that it > wanted to, but got the answer from the answer file. I did not done any upgrade. I did clean installation and generated the answerfile, then removed the engine and then installed it again and then deployed using answerfile.
(In reply to Nikolai Sednev from comment #12) > I did not done any upgrade. > I did clean installation and generated the answerfile, then removed the > engine and then installed it again and then deployed using answerfile. Perhaps the flow in comment 0 was not clear enough. It never happens on clean install. The flow was, AFAIU: 1. Install and setup 4.1 engine 2. Upgrade to 4.2 interactively. It asks about httpd and reconfigures it 3. Try to use the generated answer file for an unattended upgrade from 4.1 The bug was that it still asks about httpd.
(In reply to Yedidyah Bar David from comment #14) > (In reply to Nikolai Sednev from comment #12) > > I did not done any upgrade. > > I did clean installation and generated the answerfile, then removed the > > engine and then installed it again and then deployed using answerfile. > > Perhaps the flow in comment 0 was not clear enough. It never happens on > clean install. > > The flow was, AFAIU: > > 1. Install and setup 4.1 engine > 2. Upgrade to 4.2 interactively. It asks about httpd and reconfigures it > 3. Try to use the generated answer file for an unattended upgrade from 4.1 > > The bug was that it still asks about httpd. Initial reproduction steps were: Steps to Reproduce: 1. generate answers file where the Apache config question above is asked 2. try to use the generated answers file 3. it will prompt for input There was no upgrade mentioned. So now you want me to test upgrade from 4.1 to 4.2, while using answerfile?
(In reply to Nikolai Sednev from comment #16) > (In reply to Yedidyah Bar David from comment #14) > > (In reply to Nikolai Sednev from comment #12) > > > I did not done any upgrade. > > > I did clean installation and generated the answerfile, then removed the > > > engine and then installed it again and then deployed using answerfile. > > > > Perhaps the flow in comment 0 was not clear enough. It never happens on > > clean install. > > > > The flow was, AFAIU: > > > > 1. Install and setup 4.1 engine > > 2. Upgrade to 4.2 interactively. It asks about httpd and reconfigures it > > 3. Try to use the generated answer file for an unattended upgrade from 4.1 > > > > The bug was that it still asks about httpd. > > Initial reproduction steps were: > Steps to Reproduce: > 1. generate answers file where the Apache config question above is asked Indeed. Did you do that? > 2. try to use the generated answers file > 3. it will prompt for input > > There was no upgrade mentioned. Indeed, but: 1. The mentioned question is only asked on upgrade 2. It was implied from the attached log files > > So now you want me to test upgrade from 4.1 to 4.2, while using answerfile? See comment 11 for a minimal reproduction/verification flow, AFAICS. If you start from a clean 4.1 setup, you should not be asked this question, because 4.1 already does what's needed. You can start from 4.0 and reply 'Manual' on upgrade to 4.1 (and do nothing), then to 4.2 (same) and 4.3 (current bug). That's also a good reproduction/verification flow (and is more realistic), but somewhat longer than comment 11.
(In reply to Yedidyah Bar David from comment #17) > (In reply to Nikolai Sednev from comment #16) > > (In reply to Yedidyah Bar David from comment #14) > > > (In reply to Nikolai Sednev from comment #12) > > > > I did not done any upgrade. > > > > I did clean installation and generated the answerfile, then removed the > > > > engine and then installed it again and then deployed using answerfile. > > > > > > Perhaps the flow in comment 0 was not clear enough. It never happens on > > > clean install. > > > > > > The flow was, AFAIU: > > > > > > 1. Install and setup 4.1 engine > > > 2. Upgrade to 4.2 interactively. It asks about httpd and reconfigures it > > > 3. Try to use the generated answer file for an unattended upgrade from 4.1 > > > > > > The bug was that it still asks about httpd. > > > > Initial reproduction steps were: > > Steps to Reproduce: > > 1. generate answers file where the Apache config question above is asked > > Indeed. Did you do that? Yes, I did. > > > 2. try to use the generated answers file > > 3. it will prompt for input > > > > There was no upgrade mentioned. > > Indeed, but: > 1. The mentioned question is only asked on upgrade > 2. It was implied from the attached log files > > > > > So now you want me to test upgrade from 4.1 to 4.2, while using answerfile? > > See comment 11 for a minimal reproduction/verification flow, AFAICS. > > If you start from a clean 4.1 setup, you should not be asked this question, > because 4.1 already does what's needed. This flow is feasible for reproduction. > > You can start from 4.0 and reply 'Manual' on upgrade to 4.1 (and do > nothing), then to 4.2 (same) and 4.3 (current bug). That's also a good > reproduction/verification flow (and is more realistic), but somewhat longer > than comment 11. This flow is not possible at the moment. QA does not posses of downstream 4.3.
WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ] For more info please contact: rhv-devops: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ] For more info please contact: rhv-devops
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2019:1085
sync2jira