[Bug 1560714] Re: linuxbridge agent configuration file path is wrong for RDO packaging
Wrong project, meant to use puppet-neutron. ** Changed in: neutron (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1560714 Title: linuxbridge agent configuration file path is wrong for RDO packaging To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1560714/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1560714] [NEW] linuxbridge agent configuration file path is wrong for RDO packaging
Public bug reported: When trying to setup linuxbridge with puppet-neutron, we see the following error: Error: Could not set 'present' on ensure: No such file or directory - /etc/neutron/plugins/linuxbridge/linuxbridge_conf.ini at 110:/var/tmp/packstack/cfb205b46dae4130be410b551917440b/modules/neutron/manifests/agents/ml2/linuxbridge.pp Indeed, this path is specified in the provider: https://github.com/openstack/puppet-neutron/blob/43997b339471ad3e122b589d2d81345bcc27f842/lib/puppet/provider/neutron_agent_linuxbridge/ini_setting.rb The path provided by the RDO packaging is: /etc/neutron/plugins/ml2/linuxbridge_agent.ini The OVS path, in comparison, is correct in: https://github.com/openstack/puppet-neutron/blob/43997b339471ad3e122b589d2d81345bcc27f842/lib/puppet/provider/neutron_agent_ovs/ini_setting.rb At /etc/neutron/plugins/ml2/openvswitch_agent.ini ** Affects: neutron (Ubuntu) Importance: Undecided Status: Invalid -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to neutron in Ubuntu. https://bugs.launchpad.net/bugs/1560714 Title: linuxbridge agent configuration file path is wrong for RDO packaging To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1560714/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1560714] [NEW] linuxbridge agent configuration file path is wrong for RDO packaging
Public bug reported: When trying to setup linuxbridge with puppet-neutron, we see the following error: Error: Could not set 'present' on ensure: No such file or directory - /etc/neutron/plugins/linuxbridge/linuxbridge_conf.ini at 110:/var/tmp/packstack/cfb205b46dae4130be410b551917440b/modules/neutron/manifests/agents/ml2/linuxbridge.pp Indeed, this path is specified in the provider: https://github.com/openstack/puppet-neutron/blob/43997b339471ad3e122b589d2d81345bcc27f842/lib/puppet/provider/neutron_agent_linuxbridge/ini_setting.rb The path provided by the RDO packaging is: /etc/neutron/plugins/ml2/linuxbridge_agent.ini The OVS path, in comparison, is correct in: https://github.com/openstack/puppet-neutron/blob/43997b339471ad3e122b589d2d81345bcc27f842/lib/puppet/provider/neutron_agent_ovs/ini_setting.rb At /etc/neutron/plugins/ml2/openvswitch_agent.ini ** Affects: neutron (Ubuntu) Importance: Undecided Status: Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1560714 Title: linuxbridge agent configuration file path is wrong for RDO packaging To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1560714/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1560714] Re: linuxbridge agent configuration file path is wrong for RDO packaging
Wrong project, meant to use puppet-neutron. ** Changed in: neutron (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to neutron in Ubuntu. https://bugs.launchpad.net/bugs/1560714 Title: linuxbridge agent configuration file path is wrong for RDO packaging To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1560714/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1315501] Re: cloud-init does not use interfaces.d in trusty
@Bobby My workaround is applied to the image the instance is spawned with. You must modify the image, upload that modified image and you will be able to successfully boot VMs without this issue. If you do not have access to do that, the only other way I would see would be to spawn a VM using the image with this problem but pass user- data to cloud-init to grant you console access, a bit like this: #cloud-config users: - name: root lock-passwd: false chpasswd: list: | root:root expire: false This will allow you to login as root (with password 'root') in the VM console where you'll be able to either delete the extra eth0 file or diagnose the problem from there. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cloud-init in Ubuntu. https://bugs.launchpad.net/bugs/1315501 Title: cloud-init does not use interfaces.d in trusty To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1315501/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1315501] Re: cloud-init does not use interfaces.d in trusty
@Bobby My workaround is applied to the image the instance is spawned with. You must modify the image, upload that modified image and you will be able to successfully boot VMs without this issue. If you do not have access to do that, the only other way I would see would be to spawn a VM using the image with this problem but pass user- data to cloud-init to grant you console access, a bit like this: #cloud-config users: - name: root lock-passwd: false chpasswd: list: | root:root expire: false This will allow you to login as root (with password 'root') in the VM console where you'll be able to either delete the extra eth0 file or diagnose the problem from there. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1315501 Title: cloud-init does not use interfaces.d in trusty To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1315501/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1315501] Re: cloud-init does not use interfaces.d in trusty
Lots of people asking for workarounds, I figured I would post mine - it involves deleting the eth0 file from /etc/network/interfaces.d prior to using the image. So it goes a bit like this: # Install qemu-utils apt-get install qemu-utils # Mount the Ubuntu cloud image modprobe nbd max_part=63 qemu-nbd -c /dev/nbd0 trusty-server-cloudimg-amd64-disk1.img mount /dev/nbd0p1 /mnt/ rm /mnt/etc/network/interaces.d/eth0 umount /mnt # Upload and use the edited image -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cloud-init in Ubuntu. https://bugs.launchpad.net/bugs/1315501 Title: cloud-init does not use interfaces.d in trusty To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1315501/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1315501] Re: cloud-init does not use interfaces.d in trusty
Lots of people asking for workarounds, I figured I would post mine - it involves deleting the eth0 file from /etc/network/interfaces.d prior to using the image. So it goes a bit like this: # Install qemu-utils apt-get install qemu-utils # Mount the Ubuntu cloud image modprobe nbd max_part=63 qemu-nbd -c /dev/nbd0 trusty-server-cloudimg-amd64-disk1.img mount /dev/nbd0p1 /mnt/ rm /mnt/etc/network/interaces.d/eth0 umount /mnt # Upload and use the edited image -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1315501 Title: cloud-init does not use interfaces.d in trusty To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1315501/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1434684] Re: Pacemaker is not started and stopped automatically with Corosync
** Description changed: In Ubuntu 12.04 with: # dpkg -l |egrep pacemaker|corosync ii corosync 1.4.2-2ubuntu0.2 Standards-based cluster framework (daemon and modules) ii pacemaker1.1.6-2ubuntu3.3 HA cluster resource manager When I start corosync, it'll start the pacemaker resources: # ps aux |egrep (heartbeat|corosync) root 27043 0.2 0.0 511172 3756 ?Ssl 19:43 0:00 /usr/sbin/corosync root 27051 0.0 0.0 84716 3124 ?S19:43 0:00 /usr/lib/heartbeat/stonithd 109 27052 0.1 0.1 88768 5856 ?S19:43 0:00 /usr/lib/heartbeat/cib root 27053 0.1 0.0 97432 3256 ?S19:43 0:00 /usr/lib/heartbeat/lrmd 109 27054 0.0 0.0 84756 3364 ?S19:43 0:00 /usr/lib/heartbeat/attrd 109 27055 0.0 0.0 79040 2872 ?S19:43 0:00 /usr/lib/heartbeat/pengine 109 27056 0.0 0.0 95476 4028 ?S19:43 0:00 /usr/lib/heartbeat/crmd When I stop corosync, it'll stop them as well. In Ubuntu 14.04 with: # dpkg -l |egrep pacemaker|corosync ii corosync2.3.3-1ubuntu1 amd64Standards-based cluster framework (daemon and modules) ii crmsh 1.2.5+hg1034-1ubuntu4all CRM shell for the pacemaker cluster manager ii libcorosync-common4 2.3.3-1ubuntu1 amd64Standards-based cluster framework, common library ii pacemaker 1.1.10+git20130802-1ubuntu2.3 amd64HA cluster resource manager ii pacemaker-cli-utils 1.1.10+git20130802-1ubuntu2.3 amd64Command line interface utilities for Pacemaker When I start corosync, it will NOT start the pacemaker resources. I need to start pacemaker manually (service pacemaker start or /etc/init.d/pacemaker start). This results in nothing working until I figured that out. Yielding errors such as: --- # crm status Could not establish cib_ro connection: Connection refused (111) ERROR: crm_mon exited with code 107 and said: Connection to cluster failed: Transport endpoint is not connected --- # crm_mon Attempting connection to the cluster...Could not establish cib_ro connection: Connection refused (111) --- + In my testing, both the precise and trusty releases had Pacemaker in the service.d directory as such: + --- + service { + name: pacemaker + ver: 0 + } + --- + Is this a bug or is it expected that Pacemaker is no longer started and stopped by corosync ? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1434684 Title: Pacemaker is not started and stopped automatically with Corosync To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1434684/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1434684] Re: Pacemaker is not started and stopped automatically with Corosync
** Description changed: In Ubuntu 12.04 with: # dpkg -l |egrep pacemaker|corosync ii corosync 1.4.2-2ubuntu0.2 Standards-based cluster framework (daemon and modules) ii pacemaker1.1.6-2ubuntu3.3 HA cluster resource manager When I start corosync, it'll start the pacemaker resources: # ps aux |egrep (heartbeat|corosync) root 27043 0.2 0.0 511172 3756 ?Ssl 19:43 0:00 /usr/sbin/corosync root 27051 0.0 0.0 84716 3124 ?S19:43 0:00 /usr/lib/heartbeat/stonithd 109 27052 0.1 0.1 88768 5856 ?S19:43 0:00 /usr/lib/heartbeat/cib root 27053 0.1 0.0 97432 3256 ?S19:43 0:00 /usr/lib/heartbeat/lrmd 109 27054 0.0 0.0 84756 3364 ?S19:43 0:00 /usr/lib/heartbeat/attrd 109 27055 0.0 0.0 79040 2872 ?S19:43 0:00 /usr/lib/heartbeat/pengine 109 27056 0.0 0.0 95476 4028 ?S19:43 0:00 /usr/lib/heartbeat/crmd When I stop corosync, it'll stop them as well. In Ubuntu 14.04 with: # dpkg -l |egrep pacemaker|corosync ii corosync2.3.3-1ubuntu1 amd64Standards-based cluster framework (daemon and modules) ii crmsh 1.2.5+hg1034-1ubuntu4all CRM shell for the pacemaker cluster manager ii libcorosync-common4 2.3.3-1ubuntu1 amd64Standards-based cluster framework, common library ii pacemaker 1.1.10+git20130802-1ubuntu2.3 amd64HA cluster resource manager ii pacemaker-cli-utils 1.1.10+git20130802-1ubuntu2.3 amd64Command line interface utilities for Pacemaker When I start corosync, it will NOT start the pacemaker resources. I need to start pacemaker manually (service pacemaker start or /etc/init.d/pacemaker start). This results in nothing working until I figured that out. Yielding errors such as: --- # crm status Could not establish cib_ro connection: Connection refused (111) ERROR: crm_mon exited with code 107 and said: Connection to cluster failed: Transport endpoint is not connected --- # crm_mon Attempting connection to the cluster...Could not establish cib_ro connection: Connection refused (111) --- + In my testing, both the precise and trusty releases had Pacemaker in the service.d directory as such: + --- + service { + name: pacemaker + ver: 0 + } + --- + Is this a bug or is it expected that Pacemaker is no longer started and stopped by corosync ? -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/1434684 Title: Pacemaker is not started and stopped automatically with Corosync To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1434684/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1434684] [NEW] Pacemaker is not started and stopped automatically with Corosync
Public bug reported: In Ubuntu 12.04 with: # dpkg -l |egrep pacemaker|corosync ii corosync 1.4.2-2ubuntu0.2 Standards-based cluster framework (daemon and modules) ii pacemaker1.1.6-2ubuntu3.3 HA cluster resource manager When I start corosync, it'll start the pacemaker resources: # ps aux |egrep (heartbeat|corosync) root 27043 0.2 0.0 511172 3756 ?Ssl 19:43 0:00 /usr/sbin/corosync root 27051 0.0 0.0 84716 3124 ?S19:43 0:00 /usr/lib/heartbeat/stonithd 109 27052 0.1 0.1 88768 5856 ?S19:43 0:00 /usr/lib/heartbeat/cib root 27053 0.1 0.0 97432 3256 ?S19:43 0:00 /usr/lib/heartbeat/lrmd 109 27054 0.0 0.0 84756 3364 ?S19:43 0:00 /usr/lib/heartbeat/attrd 109 27055 0.0 0.0 79040 2872 ?S19:43 0:00 /usr/lib/heartbeat/pengine 109 27056 0.0 0.0 95476 4028 ?S19:43 0:00 /usr/lib/heartbeat/crmd When I stop corosync, it'll stop them as well. In Ubuntu 14.04 with: # dpkg -l |egrep pacemaker|corosync ii corosync2.3.3-1ubuntu1 amd64 Standards-based cluster framework (daemon and modules) ii crmsh 1.2.5+hg1034-1ubuntu4all CRM shell for the pacemaker cluster manager ii libcorosync-common4 2.3.3-1ubuntu1 amd64 Standards-based cluster framework, common library ii pacemaker 1.1.10+git20130802-1ubuntu2.3amd64 HA cluster resource manager ii pacemaker-cli-utils 1.1.10+git20130802-1ubuntu2.3amd64 Command line interface utilities for Pacemaker When I start corosync, it will NOT start the pacemaker resources. I need to start pacemaker manually (service pacemaker start or /etc/init.d/pacemaker start). This results in nothing working until I figured that out. Yielding errors such as: --- # crm status Could not establish cib_ro connection: Connection refused (111) ERROR: crm_mon exited with code 107 and said: Connection to cluster failed: Transport endpoint is not connected --- # crm_mon Attempting connection to the cluster...Could not establish cib_ro connection: Connection refused (111) --- Is this a bug or is it expected that Pacemaker is no longer started and stopped by corosync ? ** Affects: corosync (Ubuntu) Importance: Undecided Status: New ** Summary changed: - Pacemaker is not started automatically with Corosync + Pacemaker is not started and stopped automatically with Corosync -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/1434684 Title: Pacemaker is not started and stopped automatically with Corosync To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1434684/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1434684] [NEW] Pacemaker is not started and stopped automatically with Corosync
Public bug reported: In Ubuntu 12.04 with: # dpkg -l |egrep pacemaker|corosync ii corosync 1.4.2-2ubuntu0.2 Standards-based cluster framework (daemon and modules) ii pacemaker1.1.6-2ubuntu3.3 HA cluster resource manager When I start corosync, it'll start the pacemaker resources: # ps aux |egrep (heartbeat|corosync) root 27043 0.2 0.0 511172 3756 ?Ssl 19:43 0:00 /usr/sbin/corosync root 27051 0.0 0.0 84716 3124 ?S19:43 0:00 /usr/lib/heartbeat/stonithd 109 27052 0.1 0.1 88768 5856 ?S19:43 0:00 /usr/lib/heartbeat/cib root 27053 0.1 0.0 97432 3256 ?S19:43 0:00 /usr/lib/heartbeat/lrmd 109 27054 0.0 0.0 84756 3364 ?S19:43 0:00 /usr/lib/heartbeat/attrd 109 27055 0.0 0.0 79040 2872 ?S19:43 0:00 /usr/lib/heartbeat/pengine 109 27056 0.0 0.0 95476 4028 ?S19:43 0:00 /usr/lib/heartbeat/crmd When I stop corosync, it'll stop them as well. In Ubuntu 14.04 with: # dpkg -l |egrep pacemaker|corosync ii corosync2.3.3-1ubuntu1 amd64 Standards-based cluster framework (daemon and modules) ii crmsh 1.2.5+hg1034-1ubuntu4all CRM shell for the pacemaker cluster manager ii libcorosync-common4 2.3.3-1ubuntu1 amd64 Standards-based cluster framework, common library ii pacemaker 1.1.10+git20130802-1ubuntu2.3amd64 HA cluster resource manager ii pacemaker-cli-utils 1.1.10+git20130802-1ubuntu2.3amd64 Command line interface utilities for Pacemaker When I start corosync, it will NOT start the pacemaker resources. I need to start pacemaker manually (service pacemaker start or /etc/init.d/pacemaker start). This results in nothing working until I figured that out. Yielding errors such as: --- # crm status Could not establish cib_ro connection: Connection refused (111) ERROR: crm_mon exited with code 107 and said: Connection to cluster failed: Transport endpoint is not connected --- # crm_mon Attempting connection to the cluster...Could not establish cib_ro connection: Connection refused (111) --- Is this a bug or is it expected that Pacemaker is no longer started and stopped by corosync ? ** Affects: corosync (Ubuntu) Importance: Undecided Status: New ** Summary changed: - Pacemaker is not started automatically with Corosync + Pacemaker is not started and stopped automatically with Corosync -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1434684 Title: Pacemaker is not started and stopped automatically with Corosync To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1434684/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1412979] [NEW] iptables-persistent fails to save if ipv6 is disabled
Public bug reported: This bug was fixed upstream by Debian: https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=651903 Essentially, service iptables-persistent save will always attempt to save both ipv4 and ipv6 rules. If ipv6 is disabled, aka: - net.ipv6.conf.all.disable_ipv6 = 1 - net.ipv6.conf.default.disable_ipv6 = 1 - net.ipv6.conf.lo.disable_ipv6 = 1 iptables-persistent will fail with the following message: # service iptables-persistent save * Saving rules... * IPv4... * IPv6... ip6tables-save v1.4.12: Cannot initialize: Address family not supported by protocol Hitting this bug under Ubuntu 12.04 currently with the latest version of these packages: ii iptables 1.4.12-1ubuntu5 administration tools for packet filtering and NAT ii iptables-persistent 0.5.3ubuntu2 boot-time loader for iptables rules It doesn't look like I'm able to reproduce this on Ubuntu 14.04 with the latest version of these packages: ii iptables1.4.21-1ubuntu1 amd64 administration tools for packet filtering and NAT ii iptables-persistent 0.5.7all boot-time loader for iptables rules Can we backport the necessary patch to precise ? ** Affects: iptables-persistent (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1412979 Title: iptables-persistent fails to save if ipv6 is disabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables-persistent/+bug/1412979/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1367791] [NEW] check_ntp_time returns unknown with peer reporting stratum 0
Public bug reported: Lots of reference reading: - http://serverfault.com/questions/625027/nagios-check-ntp-time-offset-unknown - http://serverfault.com/questions/269701/nagios-ntp-discarding-peer - http://sourceforge.net/p/nagiosplug/mailman/message/24582375/ Using this check on more than a hundred servers configured similarly, the check fails like so on just a few nodes (5): sending request to peer 0 response from peer 0: offset -0.08336162567 sending request to peer 0 response from peer 0: offset -0.08346772194 sending request to peer 0 response from peer 0: offset -0.08303678036 sending request to peer 0 response from peer 0: offset -0.08342885971 discarding peer 0: stratum=0 overall average offset: 0 NTP CRITICAL: Offset unknown| = ## # Monitoring node ## # /usr/lib/nagios/plugins/check_ntp_time -V check_ntp_time v1.5 (nagios-plugins 1.5) # dpkg -l |grep nagios-plugins ii nagios-plugins 1.5-3ubuntu1 all Plugins for nagios compatible monitoring systems (metapackage) ii nagios-plugins-basic 1.5-3ubuntu1 amd64 Plugins for nagios compatible monitoring systems ii nagios-plugins-common1.5-3ubuntu1 amd64 Common files for plugins for nagios compatible monitoring ii nagios-plugins-standard 1.5-3ubuntu1 amd64 Plugins for nagios compatible monitoring systems # cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION=Ubuntu 14.04.1 LTS # uname -a Linux node01 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux # ntpq -c rv associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync, version=ntpd 4.2.6p5@1.2349-o Wed Oct 9 19:08:06 UTC 2013 (1), processor=x86_64, system=Linux/3.13.0-24-generic, leap=00, stratum=3, precision=-21, rootdelay=92.244, rootdisp=76.080, refid=91.189.94.4, reftime=d7bae397.935fbf98 Wed, Sep 10 2014 10:49:59.575, clock=d7bae3ec.1dd1b78d Wed, Sep 10 2014 10:51:24.116, peer=29730, tc=7, mintc=3, offset=0.334, frequency=-10.289, sys_jitter=0.508, clk_jitter=0.803, clk_wander=0.047 # On the ntp peer client (monitored server): # ntpq -c rv associd=0 status=c012 leap_alarm, sync_unspec, 1 event, freq_set, version=ntpd 4.2.6p3@1.2290-o Tue Jun 5 20:12:08 UTC 2012 (1), processor=x86_64, system=Linux/3.5.0-23-generic, leap=11, stratum=16, precision=-19, rootdelay=0.000, rootdisp=27.810, refid=INIT, reftime=. Mon, Jan 1 1900 0:00:00.000, clock=d7bae3d4.d1ed6996 Wed, Sep 10 2014 14:51:00.820, peer=0, tc=3, mintc=3, offset=0.000, frequency=-0.600, sys_jitter=0.000, clk_jitter=0.002, clk_wander=0.000 ** Affects: nagios-plugins (Ubuntu) Importance: Undecided Status: New ** Summary changed: - check_ntp_time fails when peer reports stratum 0 + check_ntp_time returns unknown with peer reporting stratum 0 ** Description changed: Lots of reference reading: - http://serverfault.com/questions/625027/nagios-check-ntp-time-offset-unknown - http://serverfault.com/questions/269701/nagios-ntp-discarding-peer - http://sourceforge.net/p/nagiosplug/mailman/message/24582375/ Using this check on more than a hundred servers configured similarly, the check fails like so on just a few nodes (5): sending request to peer 0 response from peer 0: offset -0.08336162567 sending request to peer 0 response from peer 0: offset -0.08346772194 sending request to peer 0 response from peer 0: offset -0.08303678036 sending request to peer 0 response from peer 0: offset -0.08342885971 discarding peer 0: stratum=0 overall average offset: 0 NTP CRITICAL: Offset unknown| = + ## + # Monitoring node + ## # /usr/lib/nagios/plugins/check_ntp_time -V check_ntp_time v1.5 (nagios-plugins 1.5) # dpkg -l |grep nagios-plugins ii nagios-plugins 1.5-3ubuntu1 all Plugins for nagios compatible monitoring systems (metapackage) ii nagios-plugins-basic 1.5-3ubuntu1 amd64 Plugins for nagios compatible monitoring systems ii nagios-plugins-common1.5-3ubuntu1 amd64 Common files for plugins for nagios compatible monitoring ii nagios-plugins-standard 1.5-3ubuntu1 amd64 Plugins for nagios compatible monitoring systems # cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION=Ubuntu 14.04.1 LTS # uname -a Linux node01 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux + + # ntpq -c rv + associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync, + version=ntpd 4.2.6p5@1.2349-o Wed Oct 9 19:08:06 UTC 2013 (1), + processor=x86_64, system=Linux/3.13.0-24-generic, leap=00, stratum=3, + precision=-21,
[Bug 1367791] [NEW] check_ntp_time returns unknown with peer reporting stratum 0
Public bug reported: Lots of reference reading: - http://serverfault.com/questions/625027/nagios-check-ntp-time-offset-unknown - http://serverfault.com/questions/269701/nagios-ntp-discarding-peer - http://sourceforge.net/p/nagiosplug/mailman/message/24582375/ Using this check on more than a hundred servers configured similarly, the check fails like so on just a few nodes (5): sending request to peer 0 response from peer 0: offset -0.08336162567 sending request to peer 0 response from peer 0: offset -0.08346772194 sending request to peer 0 response from peer 0: offset -0.08303678036 sending request to peer 0 response from peer 0: offset -0.08342885971 discarding peer 0: stratum=0 overall average offset: 0 NTP CRITICAL: Offset unknown| = ## # Monitoring node ## # /usr/lib/nagios/plugins/check_ntp_time -V check_ntp_time v1.5 (nagios-plugins 1.5) # dpkg -l |grep nagios-plugins ii nagios-plugins 1.5-3ubuntu1 all Plugins for nagios compatible monitoring systems (metapackage) ii nagios-plugins-basic 1.5-3ubuntu1 amd64 Plugins for nagios compatible monitoring systems ii nagios-plugins-common1.5-3ubuntu1 amd64 Common files for plugins for nagios compatible monitoring ii nagios-plugins-standard 1.5-3ubuntu1 amd64 Plugins for nagios compatible monitoring systems # cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION=Ubuntu 14.04.1 LTS # uname -a Linux node01 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux # ntpq -c rv associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync, version=ntpd 4.2.6p5@1.2349-o Wed Oct 9 19:08:06 UTC 2013 (1), processor=x86_64, system=Linux/3.13.0-24-generic, leap=00, stratum=3, precision=-21, rootdelay=92.244, rootdisp=76.080, refid=91.189.94.4, reftime=d7bae397.935fbf98 Wed, Sep 10 2014 10:49:59.575, clock=d7bae3ec.1dd1b78d Wed, Sep 10 2014 10:51:24.116, peer=29730, tc=7, mintc=3, offset=0.334, frequency=-10.289, sys_jitter=0.508, clk_jitter=0.803, clk_wander=0.047 # On the ntp peer client (monitored server): # ntpq -c rv associd=0 status=c012 leap_alarm, sync_unspec, 1 event, freq_set, version=ntpd 4.2.6p3@1.2290-o Tue Jun 5 20:12:08 UTC 2012 (1), processor=x86_64, system=Linux/3.5.0-23-generic, leap=11, stratum=16, precision=-19, rootdelay=0.000, rootdisp=27.810, refid=INIT, reftime=. Mon, Jan 1 1900 0:00:00.000, clock=d7bae3d4.d1ed6996 Wed, Sep 10 2014 14:51:00.820, peer=0, tc=3, mintc=3, offset=0.000, frequency=-0.600, sys_jitter=0.000, clk_jitter=0.002, clk_wander=0.000 ** Affects: nagios-plugins (Ubuntu) Importance: Undecided Status: New ** Summary changed: - check_ntp_time fails when peer reports stratum 0 + check_ntp_time returns unknown with peer reporting stratum 0 ** Description changed: Lots of reference reading: - http://serverfault.com/questions/625027/nagios-check-ntp-time-offset-unknown - http://serverfault.com/questions/269701/nagios-ntp-discarding-peer - http://sourceforge.net/p/nagiosplug/mailman/message/24582375/ Using this check on more than a hundred servers configured similarly, the check fails like so on just a few nodes (5): sending request to peer 0 response from peer 0: offset -0.08336162567 sending request to peer 0 response from peer 0: offset -0.08346772194 sending request to peer 0 response from peer 0: offset -0.08303678036 sending request to peer 0 response from peer 0: offset -0.08342885971 discarding peer 0: stratum=0 overall average offset: 0 NTP CRITICAL: Offset unknown| = + ## + # Monitoring node + ## # /usr/lib/nagios/plugins/check_ntp_time -V check_ntp_time v1.5 (nagios-plugins 1.5) # dpkg -l |grep nagios-plugins ii nagios-plugins 1.5-3ubuntu1 all Plugins for nagios compatible monitoring systems (metapackage) ii nagios-plugins-basic 1.5-3ubuntu1 amd64 Plugins for nagios compatible monitoring systems ii nagios-plugins-common1.5-3ubuntu1 amd64 Common files for plugins for nagios compatible monitoring ii nagios-plugins-standard 1.5-3ubuntu1 amd64 Plugins for nagios compatible monitoring systems # cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION=Ubuntu 14.04.1 LTS # uname -a Linux node01 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux + + # ntpq -c rv + associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync, + version=ntpd 4.2.6p5@1.2349-o Wed Oct 9 19:08:06 UTC 2013 (1), + processor=x86_64, system=Linux/3.13.0-24-generic, leap=00, stratum=3, + precision=-21,
[Bug 1324557] [NEW] swift-recon --objmd5 is no longer valid
Public bug reported: Using package versions: ii python-swift1.13.1-0ubuntu1~cloud0 distributed virtual object store - Python libraries ii python-swiftclient 1:2.0.3-0ubuntu1~cloud0 Client library for Openstack Swift API. ii swift 1.13.1-0ubuntu1~cloud0 distributed virtual object store - common files ii swift-proxy 1.13.1-0ubuntu1~cloud0 distributed virtual object store - proxy server check_swift_object_servers uses swift-recon --objmd5. This command no longer exists, it is now swift-recon --md5. ** Affects: nagios-plugins-openstack (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1324557 Title: swift-recon --objmd5 is no longer valid To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nagios-plugins-openstack/+bug/1324557/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1317381] Re: [SRU] swift-proxy needs python-happybase 0.5 !=0.7, but 0.7 is present in the repository when used with ceilometer
Scott / James: What is the general process for the cloud archive ? Are the fixes backported/cherry-picked from the current stable branch (trusty) once they make it out of proposed ? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1317381 Title: [SRU] swift-proxy needs python-happybase 0.5 !=0.7, but 0.7 is present in the repository when used with ceilometer To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1317381/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1317147] Re: Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present
** Also affects: cloud-archive Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to swift in Ubuntu. https://bugs.launchpad.net/bugs/1317147 Title: Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1317147/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1317381] Re: Swift-proxy needs python-happybase 0.5 !=0.7, but 0.7 is present in the repository
This is linked to another dependency problem in bug https://bugs.launchpad.net/ubuntu/+source/swift/+bug/1317147. ** Also affects: cloud-archive Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to swift in Ubuntu. https://bugs.launchpad.net/bugs/1317381 Title: Swift-proxy needs python-happybase 0.5 !=0.7, but 0.7 is present in the repository To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1317381/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1317147] Re: Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present
See: https://ask.openstack.org/en/question/27951/pecan-version-for- ceilometer-in-icehouse-swift-proxy/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1317147 Title: Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1317147/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1317147] Re: Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present
I'm also affected, using the cloud-archive repository for Icehouse on Ubuntu precise. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1317147 Title: Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1317147/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1317147] Re: Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present
** Also affects: cloud-archive Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1317147 Title: Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1317147/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1317147] Re: Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present
Once the pecan dependency is manually fixed, it also complains about another incorrect version: pkg_resources.VersionConflict: (happybase 0.7 (/usr/lib/python2.7/dist- packages), Requirement.parse('happybase=0.5,!=0.7')) This would need to be fixed as well. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1317147 Title: Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1317147/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1317381] Re: Swift-proxy needs python-happybase 0.5 !=0.7, but 0.7 is present in the repository
This is linked to another dependency problem in bug https://bugs.launchpad.net/ubuntu/+source/swift/+bug/1317147. ** Also affects: cloud-archive Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1317381 Title: Swift-proxy needs python-happybase 0.5 !=0.7, but 0.7 is present in the repository To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1317381/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1317147] Re: Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present
Oh, sorry for the spam. The happybase bug is reported in another bug: https://bugs.launchpad.net/ubuntu/+source/swift/+bug/1317381 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1317147 Title: Swift-proxy needs python-pecan =0.4.5, but 0.3.0 is present To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1317147/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1315501] Re: cloud-init does not use interfaces.d in trusty
Hi Scott, You're correct, we use config drive in our implementation (using_config_drive=True for nova-compute). The template used by nova is located here: https://github.com/openstack/nova/blob/master/nova/virt/interfaces.template I also see your point that Nova could also implement a fix for this. I will check with them and refer to this bug. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cloud-init in Ubuntu. https://bugs.launchpad.net/bugs/1315501 Title: cloud-init does not use interfaces.d in trusty To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1315501/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1315501] Re: cloud-init does not use interfaces.d in trusty
Adding the openstack nova bug for cross reference: https://bugs.launchpad.net/nova/+bug/1319117 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cloud-init in Ubuntu. https://bugs.launchpad.net/bugs/1315501 Title: cloud-init does not use interfaces.d in trusty To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1315501/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1315501] Re: cloud-init does not use interfaces.d in trusty
Hi Scott, You're correct, we use config drive in our implementation (using_config_drive=True for nova-compute). The template used by nova is located here: https://github.com/openstack/nova/blob/master/nova/virt/interfaces.template I also see your point that Nova could also implement a fix for this. I will check with them and refer to this bug. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1315501 Title: cloud-init does not use interfaces.d in trusty To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1315501/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1315501] Re: cloud-init does not use interfaces.d in trusty
Adding the openstack nova bug for cross reference: https://bugs.launchpad.net/nova/+bug/1319117 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1315501 Title: cloud-init does not use interfaces.d in trusty To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1315501/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs