[Bug 1564832] [NEW] Apparmor profile for NTPd needs to allow read/write access to /dev/ppsX
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" profile="/usr/sbin/ntpd" name="/dev/pps0" pid=1668 comm="ntpd" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0 Adding this to the usr.sbin.ntpd apparmor profile eliminated the error: /dev/pps[0-9]* rw, I'm not sure why ntpd needs *write* access to ppsN though, perhaps that can be improved. ** Affects: ntp (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1564832 Title: Apparmor profile for NTPd needs to allow read/write access to /dev/ppsX To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1564832/+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
Re: [Bug 1349949] Re: Juju's mongodb does not need to log every command in syslog
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 to mongodb in Ubuntu. https://bugs.launchpad.net/bugs/1349949 Title: Juju's mongodb does not need to log every command in syslog To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1349949/+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
Re: [Bug 1512980] Re: Please enable PPS in the Ubuntu build of ntpd
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 about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1512980/+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
Re: [Bug 1349949] Re: Juju's mongodb does not need to log every command in syslog
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 is subscribed to mongodb in Ubuntu. https://bugs.launchpad.net/bugs/1349949 Title: Juju's mongodb does not need to log every command in syslog To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1349949/+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 1512980] Re: Please enable PPS in the Ubuntu build of ntpd
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: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1512980/+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 1460164] Re: upgrade of openvswitch-switch can sometimes break neutron-plugin-openvswitch-agent
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 of openvswitch-switch can sometimes break neutron-plugin- openvswitch-agent To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1460164/+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
Re: [Bug 1512980] Re: Please enable PPS in the Ubuntu build of ntpd
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. https://bugs.launchpad.net/bugs/1512980 Title: Please enable PPS in the Ubuntu build of ntpd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1512980/+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 1512980] [NEW] Please enable PPS in the Ubuntu build of ntpd
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 in Ubuntu's build of NTP? http://doc.ntp.org/4.2.6/drivers/driver22.html Thanks, Mark ** Affects: ntp (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1512980 Title: Please enable PPS in the Ubuntu build of ntpd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1512980/+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
Re: [Bug 1349949] Re: Juju's mongodb does not need to log every command in syslog
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 every command in syslog To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1349949/+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 1349949] Re: Juju's mongodb does not need to log every command in syslog
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. https://bugs.launchpad.net/bugs/1349949 Title: Juju's mongodb does not need to log every command in syslog To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1349949/+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 1355813] Re: Interface MTU management across MAAS/juju
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 / encapsulation overhead. I've seen cases where your internal interface needs to have, say 20 byte smaller MTUs than the host. Perhaps THAT's the bit that we should focus on specifying. So MAAS gets told just jumbo frames here and then everything else focuses on understanding and allowing for overhead, but maximising MTU subject to that overhead. -- 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/1355813 Title: Interface MTU management across MAAS/juju To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1355813/+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
Re: [Bug 1300507] Re: Rabbit password is reset on every upgrade which forces lockstep cluster restarts
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 restarts To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1300507/+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 1362052] [NEW] Provide Juju details on Horizon
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 use-floating-ip: true network: default-network-for-project tenant-name: project-name username: username password: Your Password Here authorized-keys: your ssh public key i.e. pre-fill network, tenant, and username, and invite the user to provide password. This should be provided on the Horizon Overview page (and is specific to the combination of tenant and user) until we have the Juju GUI integrated to Horizon. ** Affects: horizon (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to horizon in Ubuntu. https://bugs.launchpad.net/bugs/1362052 Title: Provide Juju details on Horizon To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/horizon/+bug/1362052/+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 1362053] [NEW] Provide Juju details on Horizon
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 use-floating-ip: true network: default-network-for-project tenant-name: project-name username: username password: Your Password Here authorized-keys: your ssh public key i.e. pre-fill network, tenant, and username, and invite the user to provide password. This should be provided on the Horizon Overview page (and is specific to the combination of tenant and user) until we have the Juju GUI integrated to Horizon. ** Affects: horizon (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to horizon in Ubuntu. https://bugs.launchpad.net/bugs/1362053 Title: Provide Juju details on Horizon To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/horizon/+bug/1362053/+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
Re: [Bug 1318366] Re: jujud on state server panic misses transaction in queue
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. Alternatively, I can provide ssh access to an environment which demonstrates the crash-and-restart behaviour. Mark -- 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 transaction in queue To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1318366/+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 1318366] Re: jujud on state server panic misses transaction in queue
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 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 transaction in queue To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1318366/+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 1318366] Re: jujud on state server panic misses transaction in queue
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 transaction in queue To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1318366/+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 1318366] Re: jujud on state server panic misses transaction in queue
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 Ubuntu. https://bugs.launchpad.net/bugs/1318366 Title: jujud on state server panic misses transaction in queue To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1318366/+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 1318366] Re: jujud on state server panic misses transaction in queue
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 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 transaction in queue To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1318366/+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 1318366] Re: jujud on state server panic misses transaction in queue
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 https://bugs.launchpad.net/juju-core/+bug/1318366/+attachment/4165278/+files/syslog.mongorestarts.log -- 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 transaction in queue To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1318366/+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 1318366] Re: jujud on state server panic misses transaction in queue
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 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 transaction in queue To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1318366/+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 1318366] Re: jujud on state server panic misses transaction in queue
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 state server panic misses transaction in queue To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1318366/+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
Re: [Bug 1305839] Re: FFe: Support for Third Party Driver Installation
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 don't see a significant moral issue. 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/1305839 Title: FFe: Support for Third Party Driver Installation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1305839/+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 1305839] Re: FFe: Support for Third Party Driver Installation
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 popular, common device that was required for system installation in a large percentage of cases required a non-free driver to be on the disk and used by default. We would certainly opt to make that device installable; consider our approach on phones, where we accept binary blobs and invest a lot to deliver a free userspace. I don't think we're crossing a significant new line here. There are many pieces of no-charge proprietary software we COULD be installing to make the product better, but we don't, given our values. In this case, I see no moral high ground in crippling the install unless someone answered an ideological question. We often forget how hard it is for new users to come up to speed - we know all the permutations and combinations and tradeoffs, most users do not. Consider also how comfortable we are enabling people to run Ubuntu on proprietary clouds - where they will never see the code beneath the code, as it were. Having said all this, I didn't clarify earlier that this mechanism should only be used for hardware which has no free driver. We should always silently select the free driver if such a driver exists, and if people want to go hunting for a proprietary one, ensure they can find them in a standard, supportable, upgradeable fashion, but not use it by default. -- 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/1305839 Title: FFe: Support for Third Party Driver Installation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1305839/+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 1305839] Re: FFe: Support for Third Party Driver Installation
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 other words - thank you for calling out the late change :) * I have asked and the MAAS team have assured that all SRU changes will come with appropriate test suites * I would expect to see a test suite for this change and would expect that test suite to have been run on the appropriate hardware. Separately, we'll arrange to have MAAS CI and testing integrated to the OIL lab, which has a rapidly growing range of hardware. * installing the necessary drivers is the norm in the linux environment; warning the user about the consequences of this is the norm in the Ubuntu environment. * I'd ask that we accept this FFE once tests are in place, or if needed, with a commitment to tests as a zero-day SRU * I'd ask that the MAAS team commit to flagging the installation of such drivers in the MAAS node UI, possibly also with a flag on the node listing * all of this assumes the existence of a setting which enables a system administrator to tell MAAS not to do this by default on any given machine without explicit approval As general guidance, this is an area that will evolve fast in the coming months and years, so I've asked the MAAS team to keep developing on 14.04 LTS as their primary platform, introducing no dependencies that are not in 14.04, so we can SRU. If we need to move to universe to make that more comfortable for the release team, let's do that. We got stuck in 12.04 with old versions of key tools that should have been moved - stuck because of bad thinking on the deps front, and perceived dogma on the RM front. We can do better this time by requiring rigorous CI and testing on SRUs, and being sensible about deps. That goes for maas, juju and related tools, all of which need to be current and useful in the coming two years. -- 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/1305839 Title: FFe: Support for Third Party Driver Installation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1305839/+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 1305839] Re: FFe: Support for Third Party Driver Installation
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 drivers. -- 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/1305839 Title: FFe: Support for Third Party Driver Installation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1305839/+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 1246236] Re: pxe boot from maas fails due to time out
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. https://bugs.launchpad.net/bugs/1246236 Title: pxe boot from maas fails due to time out To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1246236/+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 1246236] Re: pxe boot from maas fails due to time out
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 bug go to: https://bugs.launchpad.net/maas/+bug/1246236/+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
Re: [ubuntu-cloud] Cloud Setup
On 04/02/11 04:15, Ashok Kumar wrote: How can we setup a private cloud for my organization. Please let me know which OS and Server, we should use for it. Ashok, you're in the right place. The standard Ubuntu server install should work on most common x86 servers, there's a list of certified ones at http://www.ubuntu.com/certification/search/?search=server Also, check out the announcement of pre-installed Ubuntu Enterprise Cloud on Dell's PowerEdge C servers, you can order a fully setup cloud to get going, then add to it over time as your need for scale increases. If you run into problems, there is official support from Canonical (available direct if you set it up yourself, and also available with the Dell offering). Discussions on the ubuntu-cl...@lists.ubuntu.com mailing list are not support oriented, they are more focused on where the cloud infrastructure will go in future and how to embrace all sorts of new cloud offerings and options. Mark -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
[Bug 454519] [NEW] Public IP addresses should be assignable by DHCP
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 such IP addresses dynamically using DHCP. When an instance is started, the node controller should ask the DHCP server for a public address for the instance. If it is unable to get one, then the instance should fail to start in the same way that it might fail if there were a shortage of any other kind of resource needed for the instance. ** Affects: eucalyptus (Ubuntu) Importance: Undecided Status: New -- Public IP addresses should be assignable by DHCP https://bugs.launchpad.net/bugs/454519 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to eucalyptus in ubuntu. -- 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 454521] [NEW] Eucalyptus installer should skip range-of-public-ip's question in favour of DHCP
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 works configuration should assume the existence of a DHCP server and act accordingly. ** Affects: eucalyptus (Ubuntu) Importance: Undecided Status: New -- Eucalyptus installer should skip range-of-public-ip's question in favour of DHCP https://bugs.launchpad.net/bugs/454521 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to eucalyptus in ubuntu. -- 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 454540] [NEW] DHCP requests for public IPs should use DHCP options
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 custom options which identify the image used (the EMI) then it would be possible to configure the DHCP server to assign IP addresses from specific ranges to specific EMI's. If the DHCP request also included as an option an indicator of a persistent identify then the DHCP server can attempt to assign a persistent IP address. DHCP options are described in the dhcp-options(5) man page. As an example, we could create the Canonical encapsulated option space, and then have options like: Canonical.UPC.mi = text (the machine image identifier) Canonical.UPC.id = text (some persistence identifier) We would update the DHCP server documentation to make it very easy for people to assign ranges of IP addresses for use in their cloud, or for specific machine images etc. ** Affects: eucalyptus (Ubuntu) Importance: Undecided Status: New -- DHCP requests for public IPs should use DHCP options https://bugs.launchpad.net/bugs/454540 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to eucalyptus in ubuntu. -- 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 454519] Re: Public IP addresses should be assignable by DHCP
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 include some custom options to help configure IP ranges neatly -- Public IP addresses should be assignable by DHCP https://bugs.launchpad.net/bugs/454519 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to eucalyptus in ubuntu. -- 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 454540] Re: DHCP requests for public IPs should use DHCP options
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 include some custom options to help configure IP ranges neatly -- DHCP requests for public IPs should use DHCP options https://bugs.launchpad.net/bugs/454540 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to eucalyptus in ubuntu. -- 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 454521] Re: Eucalyptus installer should skip range-of-public-ip's question in favour of DHCP
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 include some custom options to help configure IP ranges neatly -- Eucalyptus installer should skip range-of-public-ip's question in favour of DHCP https://bugs.launchpad.net/bugs/454521 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to eucalyptus in ubuntu. -- 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 333711] [NEW] AppArmor profile for sbin.dhclient3 should handle connman
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 profile which addresses that. I'm not sure whether AppArmor configurations can extend one another. If so, it may be better to extend the dhclient profiles (/sbin/dhclient3, /sbin/dhclient-script, /usr/lib/connman/scripts/dhclient-script) in a separate apparmor.d file added by the connman package. For the moment this patch just extends the profile added by the dhcp3-client package. ** Affects: connman (Ubuntu) Importance: Undecided Status: New ** Affects: dhcp3 (Ubuntu) Importance: Undecided Status: New -- AppArmor profile for sbin.dhclient3 should handle connman https://bugs.launchpad.net/bugs/333711 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dhcp3 in ubuntu. -- 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 333711] Re: AppArmor profile for sbin.dhclient3 should handle connman
** 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 handle connman https://bugs.launchpad.net/bugs/333711 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dhcp3 in ubuntu. -- 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 333711] Re: AppArmor profile for sbin.dhclient3 should handle connman
** 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 https://bugs.launchpad.net/bugs/333711 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dhcp3 in ubuntu. -- 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
