Public bug reported:
Connection manager (connman) runs /sbin/dhclient using some specific
actions and stores leases in different locations to NetworkManager. The
new sbin.dhclient3 AppArmor profile prevents connman from acquiring an
IP address and storing the lease, I include a patch to the
** Attachment added: Amends the apparmor profile to allow for connman's
pattern of usage of dhclient
http://launchpadlibrarian.net/23042638/connman-dhclient.patch
** Also affects: connman (Ubuntu)
Importance: Undecided
Status: New
--
AppArmor profile for sbin.dhclient3 should
** Bug watch added: bugzilla.moblin.org/ #1009
https://bugzilla.moblin.org/show_bug.cgi?id=1009
** Also affects: connman via
https://bugzilla.moblin.org/show_bug.cgi?id=1009
Importance: Unknown
Status: Unknown
--
AppArmor profile for sbin.dhclient3 should handle connman
Public bug reported:
During the installation of Eucalyptus on Ubuntu, one is asked for the IP
addresses for publicly visible images. These IP addresses must
necessarily be on a subnet that the nodes can see (because they will
proxy for the virtual machines), so it should be possible to assign
Public bug reported:
Once Eucalyptus supports the use of DHCP for dynamic public IP
assignment to instances running in the cloud, the cloud installer in
Ubuntu should skip the question asking about a range of public IP
addresses. Such a range can be configured manually if needed, the
default just
Public bug reported:
As described in bug #454519 it should be possible to assign public IP's
for cloud instances dynamically using DHCP. The DHCP requests should
include some custom dhcp options that allow for smarter configuration of
the DHCP server.
For example, if the DHCP request includes
There are three related bug reports in this set:
#454519 - Eucalyptus node controllers should be able to get a DHCP address
for public instances
#454521 - The Ubuntu private cloud installation should skip public IP range
question in favour of DHCP
#454540 - Cloud DHCP requests should
There are three related bug reports in this set:
#454519 - Eucalyptus node controllers should be able to get a DHCP address
for public instances
#454521 - The Ubuntu private cloud installation should skip public IP range
question in favour of DHCP
#454540 - Cloud DHCP requests should
There are three related bug reports in this set:
#454519 - Eucalyptus node controllers should be able to get a DHCP address
for public instances
#454521 - The Ubuntu private cloud installation should skip public IP range
question in favour of DHCP
#454540 - Cloud DHCP requests should
I'm seeing this error in the Garage MAAS today. As it happens, also have
two interfaces on the network on that machine. Will try reducing to one
and reboot.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
Was not able to reproduce after a reboot.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1246236
Title:
pxe boot from maas fails due to time out
To manage notifications about this
Thanks all for the comments and discussion.
Responding to some key points:
* building confidence in code changes both for this FFE and subsequent
SRUs is important, the archive and RM teams have a mandate to seek
comfort on that front before ack'ing an upload under either
circumstances
* in
Also, thank you Adam for pointing out that we need to do the same sort
of ubiquity- and jockey-like calling out of the issues associated with
binary blobs on servers that we do on the PC. I'll get the MAAS folks to
make that very clear on the node page as a way of socialising the
benefits of open
The key difference in my mind is recoverability. In the server case, the
install is by nature largely automated, and often will fail altogether
if you don't for example have the ability to configure your hard drives.
Perhaps an analogy for the desktop would be to ask the question - what
if a
To Robbie's point - yes, it makes no sense to make the install break
mysteriously when we can get it to work, any more so on a server or a
phone. It does make sense to flag in the UI when we have used drivers
outside of the normal Ubuntu kernel set. We're not installing
proprietary applications, I
I've got this in a live environment from the cloud-installer too. How do
I know where to point mongodump?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/1318366
Title:
jujud on
Yes, I saw the same restarting of Mongo, looks like every 10-15 seconds.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/1318366
Title:
jujud on state server panic misses
Attached is a dump of the Juju database in this case.
** Attachment added: dump.tgz
https://bugs.launchpad.net/juju-core/+bug/1318366/+attachment/4164924/+files/dump.tgz
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in
After some experiments in compression options, here are all the Juju
logs you could ever want :)
http://people.canonical.com/~mark/juju-server-crash-logs.tar.xz
68M compressed, about 1.9G uncompressed. That's /var/log/juju/ from
machine 0.
--
You received this bug notification because you are
Here is a snippet of syslog showing two cycles of Mongo starts and
restarts. This is happening constantly!
Gustavo and I are wondering whether the numactl advice might be
relevant.
** Attachment added: syslog.mongorestarts.log
Digging in further, it appears that jujud is writing to /etc/init/juju-
db.conf (the Upstart job for its database) every few seconds. I'll file
a separate bug about this because it plausibly is the root cause of the
mongo restarts we're seeing.
--
You received this bug notification because you
Is there a way to run Go processes under a debugger and generate very
high-resolution debugging output? I'm seeing this every second or third
attempt to build a cloud. It might be that debugging overhead makes the
problem vanish (yay Heisenberg) but it might give us a useful picture.
Thanks Gustavo, this is 50% of the issues I see on cloud builds so am
excited to get a build of the tools with this fix applied. Curtis, think
we can spin a build through CI asap that would show up in the testing
tools bucket on S3?
--
You received this bug notification because you are a member
Public bug reported:
Please can we restore the ability to view a Juju stanza for a user of Ubuntu
OpenStack?
It should take the form:
environment-name:
type: openstack
auth-url: http://192.168.9.97:5000/v2.0
region: region
auth-mode: userpass
Public bug reported:
Please can we restore the ability to view a Juju stanza for a user of Ubuntu
OpenStack?
It should take the form:
environment-name:
type: openstack
auth-url: http://192.168.9.97:5000/v2.0
region: region
auth-mode: userpass
We'll SRU 1.7 once it's super-solid!
Mark
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1300507
Title:
Rabbit password is reset on every upgrade which forces lockstep
cluster
Do we need to take into account any overhead being added by the protocol
stack along the way?
For example, if the underlying MAAS machine can be told to use 9000 byte
MTUs and jumbo frames, then each layer up could adopt that, but might
need to chop off some of that for protocol / tunnel /
Can we put that fragment in the jujud blob, so it's installed when Juju
is installed? 99-jujud.conf might be a better name for it.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to mongodb in Ubuntu.
Thank you Christian!
Let's go with 4.2.8 for all the obvious reasons, get it done in Ubuntu
and offer up the patch to Debian.
Mark
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
Public bug reported:
NTPD includes a reference clock driver called "pps" which uses a modern
kernel mechanism for pulse-per-second devices for very accurate
timekeeping. PPS is particularly useful for anybody building a stratum 0
GPS-disciplined time server. Please could we enable the PPS driver
I believe the fix here is in the work to rev to mongo 3.0 or 3.2 in 16.04.
Mark
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to mongodb in Ubuntu.
https://bugs.launchpad.net/bugs/1349949
Title:
Juju's mongodb does not need to log
Is the fix here to ensure that restarts of one are automatically
sequenced with restarts of the other service?
--
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/1460164
Title:
upgrade
Thanks kick-d :)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1512980
Title:
Please enable PPS in the Ubuntu build of ntpd
To manage notifications about this bug go to:
Paul, I believe the plan is to move to MongoDB 3.2 with Juju 2.0, which
solves the issue. I am not sure when we will have an upgrade mechanism
from 1.x to 2.x but we intend to do that in due course.
Mark
--
You received this bug notification because you are a member of Ubuntu
Server Team, which
Thanks Robie, excited to take it for a spin :)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1512980
Title:
Please enable PPS in the Ubuntu build of ntpd
To manage notifications
Sorry about this. I do believe it's addressed by our move to Mongo 3.2,
but I haven't tested that as the branch hasn't quite landed. It is
targeted to Juju 2.0 and Ubuntu 16.04 though.
Mark
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed
Public bug reported:
Am trying to get NTP to work with the kernel PPS subsystem, for high-
accuracy GPS-based clocks. On startup of NTPd I see this:
Apr 1 11:18:58 doorway kernel: [ 300.387443] audit: type=1400
audit(1459505938.042:9): apparmor="DENIED" operation="open"
37 matches
Mail list logo
