[Bug 1307215] Re: destroy-environment fails to clear lxc containers
Correct. Attached is a juju-deployer config that reproduces the issue when used with the juju local provider and /var/lib/lxc in the host backed onto btrfs. If you deploy it and run juju destroy-environment --force -y local, it should fail. This is because Ceph sees that /srv/ceph is on btrfs and makes use of it. ubuntu@vagrant-local-machine-1:~$ mount /dev/sda2 on / type btrfs (rw) So you'll end up with lots of snapshots created by Ceph inside LXC. These will be visible by running `btrfs subvolume list /var/lib/lxc` in the host: (.venv-ubuntu)vagrant@vagrant-ubuntu-trusty-64:~$ sudo btrfs subvolume list /var/lib/lxc ID 256 gen 9268 top level 5 path @lxc ID 257 gen 8126 top level 256 path juju-precise-template/rootfs ID 285 gen 8006 top level 256 path juju-trusty-template/rootfs ID 762 gen 9208 top level 256 path vagrant-local-machine-25/rootfs ID 763 gen 9208 top level 256 path vagrant-local-machine-26/rootfs ID 764 gen 9208 top level 256 path vagrant-local-machine-27/rootfs ID 925 gen 9208 top level 256 path vagrant-local-machine-27/rootfs/srv/ceph/current ID 934 gen 9208 top level 256 path vagrant-local-machine-26/rootfs/srv/ceph/current ID 944 gen 9208 top level 256 path vagrant-local-machine-25/rootfs/srv/ceph/current ID 951 gen 9208 top level 256 path vagrant-local-machine-26/rootfs/srv/ceph/snap_4426 ID 954 gen 9208 top level 256 path vagrant-local-machine-26/rootfs/srv/ceph/snap_4483 ID 957 gen 9208 top level 256 path vagrant-local-machine-25/rootfs/srv/ceph/snap_4767 ID 958 gen 9208 top level 256 path vagrant-local-machine-27/rootfs/srv/ceph/snap_5753 ID 959 gen 9208 top level 256 path vagrant-local-machine-25/rootfs/srv/ceph/snap_4845 ID 960 gen 9208 top level 256 path vagrant-local-machine-27/rootfs/srv/ceph/snap_5754 ** Attachment added: object-storage.yaml https://bugs.launchpad.net/juju-core/+bug/1307215/+attachment/4154884/+files/object-storage.yaml -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1307215 Title: destroy-environment fails to clear lxc containers To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1307215/+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 1307215] Re: destroy-environment fails to clear lxc containers
To further clarify, this isn't a juju bug. lxc should be smart enough to delete dependent subvolumes before it deletes the rootfs subvolume. I took a stab at this over the weekend, but ran out of time. btrfs_destroy(struct bdev *orig) is what you're after. ** Also affects: lxc (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1307215 Title: destroy-environment fails to clear lxc containers To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1307215/+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: errors.ubuntu.com: mechanism on Server
On 17 June 2013 22:24, Scott Kitterman ubu...@kitterman.com wrote: On Friday, June 07, 2013 11:15:17 AM Evan Dandrea wrote: On 7 June 2013 10:00, Robie Basak robie.ba...@canonical.com wrote: On Thu, Jun 06, 2013 at 04:19:46PM -0400, Scott Kitterman wrote: Of course this should be defaulted to no.Given that the reports to e.u.c are treated as more sensitive than crash reports to Launchpad, it is at best counter-intuitive to expect that sending reports is a reasonable default. Actually, reports to Launchpad are not intended to be treated as any less sensitive. We've just been slow to move access to crash report data in Launchpad bugs over to the NDA. The same concern is there: without an NDA, there's absolutely no recourse to someone doing malicious things with the private data found in those reports, whether they be on errors.ubuntu.com or bugs.launchpad.net. ~ubuntu-bugcontrol was expedient and well-intentioned, but it's a gamble. Perhaps I'm misunderstanding what you're saying, Scott? I don't see how having the contract between our users and the developers wishing to look at that potentially sensitive data, laying out the terms for doing so, makes sending the reports an unreasonable default when compared against not having such an agreement in place. I don't understand why it's required for e.u.c, but no Launchpad. It doesn't make any sense to require it for one and not the other. I explained this above. We have every intention of requiring for access to error reports submitted to Launchpad. https://errors.ubuntu.com was done first because it has mountains more information than Launchpad bugs. I doubt the NDA gives Canonical much in the way of recourse in any case. I'm not sure we let you see bug reports so you can work on fixing our product for free would qualify as consideration sufficient to make the NDA an actual contract (IANAL, so who knows really). A lawyer knows. Seriously, there's no need to idly speculate on this one. It was drafted by myself and Canonical's legal department to give us recourse against those who would use the information in the Error Tracker database for nefarious purposes. Neither myself nor those talented individuals would be wasting our respective time if we didn't think that: A) There is a risk in giving people unencumbered access to a mountain of data that could possibly contain some sensitive information. B) It is therefore acceptable to place restrictions on this access via a legally binding agreement. C) This agreement, if violated, could be leveraged against the guilty party. Also, fixing our product for free? Come on, Scott. This is open source software. Have we ever had a problem with developers not treating crash reports with sufficient care? If not, I wonder why it's worth inhibiting access to useful data in order to solve a problem we aren't having. Should we wait until we do have a problem? I would like to leave the users of Ubuntu with a sense that we're doing everything we feasibly can to take care of the data they've entrusted us with. If a developer wants to remain anonymous and not agree to some fairly simple ground rules, that's their choice, but they will not get access to this potentially sensitive data. It's a more than fair arrangement. You'd also need to check what priority questions debconf is set to ask if you're going to default it to true (which I think is a mistake - I think people interested in contributing will flip the switch, while defaulting to true will cause people who don't care to contribute to have a negative opinion about Ubuntu Server). Depending on how the question priorities are set, your question may never get asked. If you're not fussed, by definition you're not going to take the time to read through a page of text and find a box to tick. If you do care, the heading is going to catch your eye. You'll read it and you'll make your decision. This matches the behaviour we already have in Ubuntu Desktop on millions and millions of machines for well over a year. Honestly, the only complaints I've heard are, can we show these less often and can I please just have it always send? The structure of the debconf question is an implementation detail. We'll make sure this page always gets shown when not preseeding, and that preseeding defaults to no thank you. P.S. Replying to all since apparently not everyone is subscribed to the server list That's fixed now. :) -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: errors.ubuntu.com: support for Server?
On 12 June 2013 22:01, Jorge O. Castro jo...@ubuntu.com wrote: On Fri, Jun 7, 2013 at 5:02 AM, Robie Basak robie.ba...@canonical.com wrote: I'm intimately familiar with preseeding, that being my former life and all, but I'm afraid I don't know what you mean by global level. I take it that's something related to MAAS? What I mean is that MAAS would have an option in its web UI that adjusts this preseed option for everything in one go, rather than the user having to customize preseeds manually. One thing we could also do is making an error submission subordinate charm that we can encourage people to use on their development and testing environments. That way people exploring certain stacks can enable the submissions via an option in the Juju GUI but still run clean in production. I like the idea. Let's work closely with the design team for juju to find the most usable way of exposing the error reporting toggle, then find an implementation to match. Jorge, last we spoke you were going to bring this up with the Juju GUI team. Shall we move this thread over to one of their lists? -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: errors.ubuntu.com: mechanism on Server
On 7 June 2013 10:00, Robie Basak robie.ba...@canonical.com wrote: On Thu, Jun 06, 2013 at 04:19:46PM -0400, Scott Kitterman wrote: Of course this should be defaulted to no.Given that the reports to e.u.c are treated as more sensitive than crash reports to Launchpad, it is at best counter-intuitive to expect that sending reports is a reasonable default. Actually, reports to Launchpad are not intended to be treated as any less sensitive. We've just been slow to move access to crash report data in Launchpad bugs over to the NDA. The same concern is there: without an NDA, there's absolutely no recourse to someone doing malicious things with the private data found in those reports, whether they be on errors.ubuntu.com or bugs.launchpad.net. ~ubuntu-bugcontrol was expedient and well-intentioned, but it's a gamble. Perhaps I'm misunderstanding what you're saying, Scott? I don't see how having the contract between our users and the developers wishing to look at that potentially sensitive data, laying out the terms for doing so, makes sending the reports an unreasonable default when compared against not having such an agreement in place. On Thu, Jun 06, 2013 at 12:44:47PM -0700, Clint Byrum wrote: Turning this on without explicit user authorization would be a breach of confidence in Ubuntu Server. More info: https://wiki.ubuntu.com/ServerTeam That was not suggested. This is not a default without consent. For the interactive case, the user has a section of text explaining the choice in front of them, with the default cursor position being on Yes, I would like to help make Ubuntu better by submitting error reports. This does not turn on something behind the backs of users who wouldn't want it, but it does make less work for the vast majority who would find the notion of Ubuntu getting better as result of sending a small amount of data a worthy proposition. Now, Alex makes a really good point: On 6 June 2013 20:01, Alex Muntada al...@alexm.org wrote: Though i understand that enabling it by default the number of reports will be much bigger, i'd prefer a more conservative approach and set the default to No. Even if one can set that value via preseed, it's difficult to make so unless one's aware of its existence first. And providing that many server installations are unattended nowadays, i see that the Yes default could raise many concerns about the privacy of the reports. We should definitely not do this. If the value is not preseeded, it should not default to true. We have not explained to those people what they'd be agreeing to. However, I believe it still makes sense to have the default action within an interactive d-i session to be yes. All of this is achievable in the debconf protocol. The error reporting system is nothing new. We have an excellent track record in being protective of the data submitted to this system from lots of desktop systems, giving data access only to those who can sign a legally-binding agreement to not misuse it, provide us with real world contact details, and demonstrate a valid use for their access. Abusers can and will be prosecuted, but we know our development community; these are good people. There have already been well documented cases of serious issues being discovered by https://errors.ubuntu.com that would've never been uncovered using the old developer-centric opt-in approach of apport reporting into Launchpad bugs. It is not a stretch to say there's a strong connection between the variety of reports we get and our further understanding of what the most important issues in Ubuntu are. On the desktop, we already present exactly this kind of question that's being proposed for d-i, with the default being to agree to send. To date, none of the owners of the millions of systems reporting into errors.ubuntu.com have burned my house down. So is it realistic to think when presented with an option of yes, I would like to make Ubuntu better (given I'm kind of relying on it for my computer to function) and no thanks, the negative response is the more likely choice? I think we're doing our users a disservice by being so pessimistic, assuming they're uninterested in participating in making the best operating system we can. Thanks for listening. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: errors.ubuntu.com: support for Server?
On 24 May 2013 17:20, Robie Basak robie.ba...@canonical.com wrote: On Thu, May 16, 2013 at 07:01:54AM -0700, Evan Dandrea wrote: What I mean is that data does not get uploaded without the user knowing about it. So in my terms, error reporting on the desktop _is_ opt-in. In the Desktop case, the user knows about it when the error reporting dialog pops up. In the Server case, this is more difficult to achieve, since there is not necessarily any UI available to prompt the user after an error. Ah, thank you for clarifying. I'd prefer that we kept with the existing model of not asking questions, as this has been core to the redesign of apport and the development of the error tracker. OK, but we do effectively ask a single question on the desktop, right? We do. By not asking questions I mean not asking any questions beyond what is absolutely necessary. So yes, at some point we need to ask for their consent in sending all error reports, with each one, or even some combination of both – saying no to automatic error reporting could still notify you via motd that you have reports to manually process. What I do not think we should do is ask questions beyond that. Historically they've been confusing to our audience, but more importantly they reduce the likelihood that someone will respond. It's extra work, and they might not have the time for it. There are better ways. We can use scale to our advantage and given a report that's missing some critical detail we didn't anticipate, programmatically tell the next reporter's system to attach additional information. This involves no additional human interaction and is theoretically as fast as a few seconds as opposed to the usual Launchpad bug response time of days or weeks, if ever. 2) Any extra bit of work you put between a user and submitting an error report will cause some of those users to not send the report. They'll be hesitant to send subsequent reports if the process was previously onerous. Agreed - we need to make sure that the UX is as simple as possible. Great! Production server operators may want to vet reports before agreeing to send them, so an interactive CLI like aa-logprof(8) or apport-cli(1) that allows users to see exactly what they are submitting would be useful. So essentially a CLI equivalent of the GUI error reporting dialog. The documentation for apport discusses one possible approach: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/README#L51 The problem I have with this is that it's a very manual step. I'm not convinced many people who would otherwise be okay with automatic reporting will actually notice the message and follow through. It also delays our knowing the frequency of serious issues by relying on server administrators to log in and process the reports. Could this be reasonable as one fallback position for those who ask d-i to turn off automatic uploads, or if we choose not to follow that path? Yes, I think unless the user explicitly disables the collection of reports (disabling apport in /etc/default/apport), we should still tell them what it's doing and how they can further process the results. So I would be very happy in taking that .bashrc chunk from apport and putting it in motd as a first step. So where do we go from here? It seems that we have two proposals: 0) I presume that with both proposals we have the option of choosing different defaults between stable and development releases? Yes, though do keep in mind that if we restrict ourselves to just development releases we are going to miss out on problems that would only crop up post-release. We've had serious ones with each new release of the desktop OS. 1) A d-i prompt asking about error reporting. Outcome: automatic uploads of error reports, or not. I understand that you want this to default to automatic uploads, and your reasons. Yes please. 2) The bash prompt modification at [1] by default. Yes please. :) For MAAS, I presume that we could make the d-i preseed configurable at a global level. I'm intimately familiar with preseeding, that being my former life and all, but I'm afraid I don't know what you mean by global level. I take it that's something related to MAAS? I'm not sure about juju without MAAS. Perhaps a configuration parameter for the environment could feed cloud-init? That's vaguely what I was thinking. Either using constraints or kindly requesting that a new environments.yaml option be added to represent error reporting. The benefit of the latter is that's it's more discoverable, even if disabled by default. We could automatically populate it into environments.yaml with a comment explaining what it does and asking them to help make Ubuntu better by turning it on. We should ask them directly though, perhaps as a separate discussion to this one. Thanks! -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
Re: errors.ubuntu.com: mechanism on Server
Sounds good to me :). Thanks Robie! -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: errors.ubuntu.com: benefits on Server?
Hi Robie, On 6 June 2013 11:38, Robie Basak robie.ba...@canonical.com wrote: I thought I'd split this thread into two. One question is about what benefits error reporting on Server might bring, and that's what I'd like to discuss here. [Daviey] Just need to work out, *if* it is worth doing... Is it worth doing? What sorts of errors will we pick up on right now? Do these errors happen in the real world? With us diverting effort to this, are we going to neglect some category of errors that we currently won't pick up this way? Some categories of errors come to mind: I would be careful in extrapolating based off what you get right now from Launchpad bugs. This wont just produce the same set of issues in greater numbers. When you introduce post-release reporting and remove the barriers to sending reports (no SSO, no forms), you get a much broader view of what's out there. I honestly don't know if it's worth doing, but fortunately that's not entirely my call to make. I also don't think we'll know until we try. 1) Segfaults leading to core dumps. I don't see many bug reports of these at all. We do get the occasional excellent bug report though. My feeling is that segfaults on server are actually quite rare. You probably don't see reports of these because any process that drops privileges does not produce a core dump. I really want to turn this on, making the reports owned by root. Kees sounded okay with it about a year ago and was going to look into it (/proc/sys/kernel/setuid_dumpable to 2), but I don't think he ever found the time. I can bring this back up with the security team. 2) Maintainer script failures. We get lots of these reports. Most of them are due to local misconfiguration or sysadmin error in a way that I don't think it's possible or reasonable for us to fix. This is because most use cases of server packages involve sysadmin configuration file editing. Perhaps this can be fixed at a higher layer (eg. charms being careful to not introduce these kinds of errors). I think these reports aren't useful individually for this reason, but may be useful in aggregate to identify real bugs. So it seems to me that error reporting for these would be really useful. We've had some difficulty finding a good way of bucketing these together, so that you see them in aggregate. Martin, Brian, and I sat down at the client sprint and came up with what I hope is a better solution: https://lists.ubuntu.com/archives/raring-changes/2013-June/010150.html 3) Perhaps daemon start failures that aren't from maintainer script failures? This is subject to the same sysadmin misconfiguration problem above though; I'm not sure how useful this would be. What other kinds of errors will we initially pick up on? What categories have I missed, or does anyone disagree with my analysis above? Recoverable problems. We created /usr/share/apport/recoverable_problem for applications that can handle an exception, but would still like to know that it occurred. Often, this may be that the exception was handled but the experience is degraded as a result, so on the desktop is produces a popup as well. All developers have to do is feed it nul-separated key-value pairs over stdin, ensuring they provide a DuplicateSignature field. Right now it works off the ppid, but I believe Ted Gould was patching it to support the pid to trace being passed in. You could patch applications to use this, as Ted is doing with glib. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: errors.ubuntu.com: support for Server?
Hi Robie, Thanks for kicking off this discussion. On Thu, May 16, 2013 at 12:10 AM, Robie Basak robie.ba...@canonical.com wrote: that will cause us to misinterpret the results? Is there any need to categorise the reports at submission time (eg. perhaps ask the reporter a question)? I'd prefer that we kept with the existing model of not asking questions, as this has been core to the redesign of apport and the development of the error tracker. Two points on this: 1) We have been historically quite bad at understanding our audience when programmatically communicating with them. Thanks for reporting this bug. It seems you have unity running. Is the issue you are reporting is related to unity itself rather than compiz? What's Unity? What's Compiz? Even if I know what both of those are, how on Earth do I know which one is responsible for my bug? I'm just going to close this thing because I don't know what the correct answer is. 2) Any extra bit of work you put between a user and submitting an error report will cause some of those users to not send the report. They'll be hesitant to send subsequent reports if the process was previously onerous. What should the UX be? How should we protect privacy and avoid reports inadvertently being submitted by users who do not wish to submit them? Should we have different UX defaults between the development and production releases? If the system is opt-in (which I assume it will be), will we have enough users opting in for the system to be useful? Why do you assume an opt-in system? Error reporting on the desktop is not opt-in, and for good reason: our data would be heavily skewed to the types of people who already know that the error reporting functionality exists, can find the toggle to turn it on, and are so passionate about providing error data that they do turn it on. On the desktop, this is handled by a checkbox that's ticked by default with the heading: Send an error report to help fix this problem. I think we should find a solution with that balance in mind. I've suggested in the past that we do this at installation time with the default option being to enable error reporting. So in the case of debian-installer, a d-i component that asks whether you want to disable error reporting. In the case of juju and maas, I'm not sure. Some implmentation ideas: Production server operators may want to vet reports before agreeing to send them, so an interactive CLI like aa-logprof(8) or apport-cli(1) that allows users to see exactly what they are submitting would be useful. So essentially a CLI equivalent of the GUI error reporting dialog. The documentation for apport discusses one possible approach: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/README#L51 The problem I have with this is that it's a very manual step. I'm not convinced many people who would otherwise be okay with automatic reporting will actually notice the message and follow through. It also delays our knowing the frequency of serious issues by relying on server administrators to log in and process the reports. Or perhaps some kind of remote ssh enhancement to the existing GUI error reporting dialog, so users get the same UI on a desktop machine that connects to a server machine, picks up the crash reports there generates and sends reports via the local GUI? That assumes they're running Ubuntu everywhere. It's presumably confusing as you're suddenly getting error reports out of the blue. We've been bitten hard by this with the system internal error reports that pop up, confusing users who thought they hadn't actually done anything. But most importantly, it's extra work for the end-users to get going. Lets make the barrier to sending these reports as low as possible. An update-motd enhancement to notify server operators that crash reports are pending. This could provide the command to type to enter the interactive CLI to submit them and a reference to a manpage with more details on how to turn off local crash report collection. A bash prompt enhancement present only during development, which prompts users with a shorter version of the motd prompt. Or would this be too intrusive? I thought of it because I imagine users not logging in much to test servers, and so might not see the motd prompt (I rarely see the motd prompt when I test, since I use ssh shared connections and short-lived cloud instances). Other thoughts: Right now I feel that the information we get from users about Server quality is poor. As always, some bug reports are awesome, are from competent submitters, and highlight real problems which we need to fix. But many bugs filed appear to be automatic and in response to postinst failures due to local misconfigurations. I think this overrepresents the set of users who are experimenting and underrepresents the users who are using Server in production. I'm not sure we get any other real feedback about quality right now,
[Bug 959308] Re: kvm does not generate a system uuid by default
** Changed in: whoopsie-daisy (Ubuntu) Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu-kvm in Ubuntu. https://bugs.launchpad.net/bugs/959308 Title: kvm does not generate a system uuid by default To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/959308/+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 735072] Re: The hostname proposed by installer is too long for file sharing to work correctly.
Some commentary from IRC: zul: ev: ping for the samba bug, couldnt ubiquity do something sensible and not allow more that 16 characters in a hostname? [18:04] ScottK: Why is a 16 character hostname limit sensible? [18:04] ev: zul: this is a limitation in netbios, not linux. [18:05] ev: ScottK: indeed [18:06] ev: I think this is best solved where the problem arises, in Samba. I can talk to another machine with more than 16 characters in its hostname using every other network protocol I can think of. [18:06] ev: equally, you can set the hostname outside of the installer, so even if we did this in ubiquity, the problem would remain. [18:07] zul: ev: right its a problem with netbios...so something like print a warning or something [18:08] ScottK: RFC 1123 says Host software MUST handle host names of up to 63 characters and SHOULD handle host names of up to 255 characters. [18:08] zul: ScottK: right ill get on changing the netbios protocol [18:09] ScottK: I understand the problem. [18:09] • ScottK imagines a netbios equivalent for hostnames of 8.3 long/short filenames. I am firmly against modifying ubiquity to work around limitations in the NetBIOS protocol. This belongs in Samba. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to samba in Ubuntu. https://bugs.launchpad.net/bugs/735072 Title: The hostname proposed by installer is too long for file sharing to work correctly. -- 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 735072] Re: The hostname proposed by installer is too long for file sharing to work correctly.
I'm moving this to Samba, after conferring with Steve Langasek. The samba package should detect the case where the hostname is longer than the limit set by NetBIOS and truncate it for its own configuration. ** Also affects: samba (Ubuntu) Importance: Undecided Status: New ** Changed in: ubiquity (Ubuntu) Status: Confirmed = Invalid ** Changed in: samba (Ubuntu) Importance: Undecided = High ** Changed in: samba (Ubuntu) Status: New = Confirmed -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to samba in Ubuntu. https://bugs.launchpad.net/bugs/735072 Title: The hostname proposed by installer is too long for file sharing to work correctly. -- 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 348633] Re: Fails to boot from CD after reboot: CDROM boot failure code: 0003
I think this deserves a higher priority than wishlist. This bit me hard over the past two days in testing Wubi. wubildr (grub2) would hang on reading from the CDROM on first boot, since it had been ejected and left in that state. -- Fails to boot from CD after reboot: CDROM boot failure code: 0003 https://bugs.launchpad.net/bugs/348633 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to kvm 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 327348] Re: keep losing ability to type in guest
For what it's worth, I cannot reproduce this bug with the -vnc option, but I can reproduce it in Karmic without it (SDL). To reproduce, boot a live CD using the SDL frontend, then call apt-get -y install from a terminal with a large package. Hit ctrl-alt and then ctrl-alt-arrow to move away from that desktop for a while. Come back to it in five minutes or so and notice that the download has not progressed. -- keep losing ability to type in guest https://bugs.launchpad.net/bugs/327348 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to kvm 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
[Blueprint server-karmic-encrypted-swap-as-an-option] Encrypted Swap as an Option
Blueprint changed by Evan Dandrea: Definition Status: Drafting = Review Whiteboard changed to: Discussion Points: * UDS Buy-in (main use case is hibernate): * karmic implementation: * encrypted home in installer - setup swap encryption (ecryptfs-setup-swap), document hibernation incompatibility * randomly generate key on boot (no passphrase wrapping) * open wishlist bug for hibernation resume support * need UI changes to Applications Accessories Passwords and Encryption Keys * post-karmic implementation (hard): * algorithm: wrap randomly generated password with PAM system passphrase on login (for multiple users), store in LUKS keyslot * teach resume scripts to prompt for user's wrapping passphrase on resume, decrypt swap, resume * possible regressions and workarounds: * /tmp contents are still viewable, worked around in short term by using tmpfs for /tmp when system has some amount X of RAM, worked around in long term by moving /tmp into ~/.tmp * additional notes: * see who is using encrypted home and encrypted swap * Original suggested design: * encrypt swap, using a randomly generated key every boot * by default, use a static wrapping password like ubuntu, and store the wrapped swap key in LUKS * teach hibernation resume (init?) to try this static default passphrase first * if that doesn't work, then prompt the user for the wrapping passphrase * in System-Administration, provide a utility that allows the administrator switch from the insecure default ubuntu wrapping passphrase to a PAM-based wrapping passphrase * teach PAM to take a successful login passphrase and re-wrap the randomly generated swap passphrase with the login passphrase if secure swap is enabled, (possibly populating 1 or more of the LUKS keyslots) * On hibernate event, ensure that the current user's passphrase has been used to wrap the swap passphrase in one of the LUKS keyslots * would need to prompt for a passphrase here, if this was an auto-login and the user wants secure-swap -- Dustin Kirkland (steve.langasek) When I migrated my laptop from hardy to intrepid, I turned on encrypted swap at the same time (swap LV on top of LVM+encryption). Anything that makes heavy use of swap on my desktop now brings the whole system to its knees. Please be cognizant of performance issues when implementing this - I fear this may be untenable as a default for desktop systems. (Roderick Greening) It would never be expected to encrypt a swap file which exists in a LVM encrypted drive. Given that to build a LVM system, you have to use the alternate cd, the user would be in total control of these choices. Via the regular live CD/DVD, LVM is not a option (that I recall), so encrypting the swap by default should not be problematic. (Paul Klapperich) As far as encrypted swap working with hibernate, it sounds like this goes nicely on computers that have a TPM as per the second link. I don't have one to test. For computers without a tpm, I don't know how ecryptfs works, but for luks we could perhaps use a pam module to hold the user account password for the duration of the login and set it as an alternate key for the luks swap partition (which previously had a random key only) if the user initiates a hibernate. Alternatively a global swap password could be created instead of (or somehow in addition to) random key encryption, but that's an extra password that now all users of the system would be required to know. It would, however, allow a resume from hibernate followed by a switch user if the person who hibernated is not present. (Przemysław Kulczycki) Will this block the system's ability to write crash dumps to swap partition and to save it from swap partition to file after a reboot? (Jerone Young) How can we start talking about something like this being by default when it has not even had field testing. If Jaunty is about stability this is not the way to go. Also since (from what I know) this is not being done in the kernel but rather in userspace, which is going to cause big performance issues when writing to swap. Another thing is where are the keys kept to decrypt the swap? How is a machine going to wake up from hibernation? This also will not work with the grub fast hibernation patches. Not a good idea to do at this time. Got sign off from Dustin on the content of the specification, ready for review -- evand -- Encrypted Swap as an Option https://blueprints.edge.launchpad.net/ubuntu/+spec/server-karmic-encrypted-swap-as-an-option -- 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
