Description of problem: NTP package is not available in rhevm-appliance-20160229.0-1.el7ev.noarch rpm -qa didn't shown it. Version-Release number of selected component (if applicable): rhevm-appliance-20160229.0-1.el7ev.noarch How reproducible: 100% Steps to Reproduce: 1.Deploy HE and use rhevm-appliance-20160229.0-1.el7ev.noarch appliance from our repos. 2.Use cloud-inint during appliance deployment. 3. Actual results: There is no ntp package inside the appliance. Expected results: ntp package must be inside the appliance. Additional info:
If ntp is required, then it can be installed using yum. Is there another problem, besides that the time can not be synchronized?
NTP might be installed on el6.x manually, but it was previously already there, so I really don't see any reason to remove it from there, especially as it is crucial for the logs and rhevm, appliance has to be synchronized with the same time source as hosts, otherwise there will be many issues, also for rhevhs as they create certificates based on time that system have at the moment of certificate being created, there also will be problems for AAA if not synched with ntp. So for el6.x its vi /etc/ntp.conf -> server clock.redhat.com iburst -> service ntpd restart -> ntpd -gq -> date; For el7.x its vi /etc/ntp.conf -> server clock.redhat.com iburst -> systemctl restart chronyd->systemctl status chronyd->chronyc sources -v I did not seen anything problematic besides this issue in appliance, the only disadvantage is when I'm using cloud-inint, I still have to connect to the engine via VNC and remove "#" there in /etc/ssh/sshd_config, so I could login as root user over ssh. I think it's security measures, although our kikstarter does not prevent us from connecting as root to reprovisioned OSs from PXE.
We did not actively remove ntp. So it must have been a change in the inheritance tree. But this is actually platform issue. Having ntp running inside the appliance might be a security issue and not all customers want it (We've experienced this on RHEV-H). Moran, any opinion on the request to enable NTP by default?
(In reply to Fabian Deutsch from comment #3) > We did not actively remove ntp. > > So it must have been a change in the inheritance tree. > > But this is actually platform issue. Having ntp running inside the > appliance might be a security issue and not all customers want it (We've > experienced this on RHEV-H). > > Moran, any opinion on the request to enable NTP by default? RHEVH6.7/3.5 creates certificate with +2 hours shift from our time, after being reprovisioned on clean host from PXE and then rebooted, this creates a problem for customers, as they can't use this server until +2 hours expired. As WA we did not used the PXE, but installed RHEVH via ISO image through the ILO console and did not rebooted the server, once it finished it's RHEVH deployment. We changed the date manually as well as /etc/sysconfig/network <-set there correct FQDN, as after reboot RHEVH will loose it, then we rebooted RHEVH and certificate was created normally with current time and with correct FQDN instead of creating it as localhost.localdomain, as it would be done in case of PXE+reboot. I'm not aware of security issues with NTP, can you share them?
NTP is basically phoning home, which exposes informations about the presence of hosts using ntp.
After some discussion with others and caeful considerations, a summary: We still do not want to enable NTP by default inside the appliance. Some users do not like if a server (or appliance) is contacting a public NTP server. However, it is benefitial if the user could configure NTP inside the appliance prior to the HE setup flow, to ensure that all logs etc have correct timestamps. However, in the HE setup flow where the appliance is involved, this is not easily possible. One option (and this is what this bug is about) is to ask the user in the hosted-engine-setup flow, if NTP should be enabled inside the appliance. If such an option is given, then we could pre-install but disable ntp inside teh appliance, and he-setup could enable it on demand.
(In reply to Fabian Deutsch from comment #7) > After some discussion with others and caeful considerations, a summary: > > We still do not want to enable NTP by default inside the appliance. Some > users do not like if a server (or appliance) is contacting a public NTP > server. > > However, it is benefitial if the user could configure NTP inside the > appliance prior to the HE setup flow, to ensure that all logs etc have > correct timestamps. > > However, in the HE setup flow where the appliance is involved, this is not > easily possible. > One option (and this is what this bug is about) is to ask the user in the > hosted-engine-setup flow, if NTP should be enabled inside the appliance. > > If such an option is given, then we could pre-install but disable ntp inside > teh appliance, and he-setup could enable it on demand. Is it possible to give the customer a choice of: 1)Configure NTP during HE deployment. 2)Do not configure NTP and leave it disabled on appliance, but inherit currently configured time and date from host, on which HE being deployed by default, so this will automatically synchronize logs to the same time/date. 3)Provide option for manual time/date configuration.
All of this is possible, but we need to see what makes sense.
hosted-engine-setup is neither automatically syncing the timezone between the host and the deployed appliance and due to this correlating the logs requires to manually evaluate the time-shift.
We need a design for this feature and probably infra involvement if all the hosts and the engine have to be on the same timezone and synced on the same time.
(In reply to Sandro Bonazzola from comment #11) > We need a design for this feature and probably infra involvement if all the > hosts and the engine have to be on the same timezone and synced on the same > time. KISS: copy TZ settings from the first host. Set up NTP (if not already set up) and copy its setting (from the first host).
I don't think that oVirt is a configuration management project. IMO this should be handled by configuration management projects such as Foreman.
(In reply to Oved Ourfali from comment #13) > I don't think that oVirt is a configuration management project. IMO this > should be handled by configuration management projects such as Foreman. There is a constant flow of bugs related to these types of issues. The minimum is warning if this service if not running.
I agree on copying over the timezone setting with cloudinit. About ntp configuration, when the hosted engine starts has the same time of the host. After that I think that the admin should take care of the configuration of the appliance to their needs.
The fix for this issue should be included in oVirt 4.1.0 beta 1 released on December 1st. If not included please move back to modified.
Timezone was successfully taken from host to the appliance. Engine VM timezone: Asia/Jerusalem (this was printed in CLI during hosted-engine deployment). Works for me on these components on hosts: vdsm-4.18.999-1020.git1ff41b1.el7.centos.x86_64 ovirt-host-deploy-1.6.0-0.0.master.20161107121647.gitfd7ddcd.el7.centos.noarch libvirt-client-2.0.0-10.el7_3.2.x86_64 ovirt-vmconsole-1.0.4-1.el7ev.noarch ovirt-release41-pre-4.1.0-0.0.beta.20161201085255.git731841c.el7.centos.noarch qemu-kvm-rhev-2.6.0-28.el7_3.2.x86_64 ovirt-hosted-engine-ha-2.1.0-0.0.master.20161130135331.20161130135328.git3541725.el7.centos.noarch rhevm-appliance-20161116.0-1.el7ev.noarch sanlock-3.4.0-1.el7.x86_64 ovirt-setup-lib-1.1.0-0.0.master.20161107100014.gitb73abeb.el7.centos.noarch ovirt-engine-sdk-python-3.6.9.1-1.el7ev.noarch ovirt-imageio-common-0.5.0-0.201611201242.gitb02532b.el7.centos.noarch ovirt-vmconsole-host-1.0.4-1.el7ev.noarch mom-0.5.8-1.el7ev.noarch ovirt-hosted-engine-setup-2.1.0-0.0.master.20161130101611.gitb3ad261.el7.centos.noarch ovirt-imageio-daemon-0.5.0-0.201611201242.gitb02532b.el7.centos.noarch Linux version 3.10.0-514.2.2.el7.x86_64 (mockbuild.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Wed Nov 16 13:15:13 EST 2016 Linux 3.10.0-514.2.2.el7.x86_64 #1 SMP Wed Nov 16 13:15:13 EST 2016 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux Server release 7.3 (Maipo) Engine was deployed from rhevm-appliance-20161116.0-1.el7ev.noarch. The date shown on engine and hosts was the same and synchronized. Moving this RFE to verified.
Correction, engine was deployed from ovirt-engine-appliance.noarch 4.1-20161202.1.el7.centos.