Re: More diagnostics data from desktop
On Wed, Feb 21, 2018 at 11:32 AM, Jonty Gamao wrote: > Hi, > > I noticed in the mailing list that you guys only talked about users who are > installing Ubuntu for the first time, not upgrading from a previous version > (unless I totally missed it, or misunderstood it): > >> We would like to add a checkbox to the installer, exact wording TBD, but >> along the lines of “Send diagnostics information to help improve Ubuntu”. >> This would be checked by default. > > If I understood it right, then you guys haven't decided whether to leave it > enabled or disabled by default for users who are upgrading, right? > > In my opinion, I think you guys should make it an opt-in thing for users who > are upgrading from a previous version of Ubuntu. It leaves a sour thought > in people's minds when they get drafted to something they're against, even > though they have the option to leave (pretty sure you noticed how this move > became controversial and a hot topic right now). I suggest doing a pop up > right after the upgrade and reboot, or during the upgrade process, that asks > them whether they want to participate (with VERY detailed info on what > you'll be collecting) or not. And maybe leave it unticked. Yes, indeed, we agree -- upgrading users would need to purposely "opt-in" to this behavior, as that wasn't explicitly asked in the past. Upgrading users would need to purposefully enable diagnostics in System Preferences. We should look into a tasteful way of asking this question during the upgrade process. We'll leave that to the Ubuntu UI/UX team ;-) > Personally, I'll help out by giving you guys the data you're asking, but > there are others who are totally against this, especially the idea of > opt-in. > > Take care, > Jonas > > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: More diagnostics data from desktop
On Thu, Feb 15, 2018 at 1:10 AM, Juerg Haefliger wrote: > On 02/14/2018 04:22 PM, Will Cooke wrote: >> Dear all, >> >> We want to be able to focus our engineering efforts on the things that >> matter most to our users, and in order to do that we need to get some >> more data about sort of setups our users have and which software they >> are running on it. >> >> We would like to add a checkbox to the installer, exact wording TBD, but >> along the lines of “Send diagnostics information to help improve >> Ubuntu”. This would be checked by default. > > Please make this an opt-in rather than an opt-out. This just smells like > a trend towards a Windows/Android installation where you have to unset > gazillions of check boxes to prevent the machine from posting your life > to the vendor. We shouldn't go there. > > >> The result of having that box checked would be: >> >> * Information from the installation would be sent over HTTPS to a >> service run by Canonical’s IS team. This would be saved to disk and >> sent on first boot once there is a network connection. > > So sent only once or after every reboot? Only once. > >> The file >> containing this data would be available for the user to inspect. >> >> That data would include: >>* Ubuntu Flavour >>* Ubuntu Version >>* Network connectivity or not >>* CPU family >>* RAM >>* Disk(s) size >>* Screen(s) resolution >>* GPU vendor and model >>* OEM Manufacturer >>* Location (based on the location selection made by the user at >> install). No IP information would be gathered >>* Installation duration (time taken) >>* Auto login enabled or not >>* Disk layout selected >>* Third party software selected or not >>* Download updates during install or not >>* LivePatch enabled or not >> >> * Popcon would be installed. This will allow us to spot trends in >> package usage and help us to focus on the packages which are of most >> value to our users. > > Are you saying that popcon is automatically installed and enabled? I > haven't performed an Ubuntu install lately but isn't there an install > question asking whether to enable popcon or not (with the default being > no). Or is that Debian? There is currently no "enable popcon" install question in Ubuntu (maybe there is in Debian)? In Will's proposal, there's a single, simple, clear checkbox, along the lines of "[X] Send diagnostic information", which, if enabled, would: (1) post this initial list of installation options and hardware capability, (2) enable popcon to periodically report lists of installed packages, and (3) enable Apport to post crash reports Declining to send diagnostics, would disable all 3. >> * Apport would be configured to automatically send anonymous crash >> reports without user interruption. > > I hope this will be clearly articulated during install time. > > >> The results of this data would be made public. > > Same here. People need to know that their data is publicly (yet > anonymously) visible. Indeed. DockerHub does a nice job of making their statistics publicly available, and many, interesting 3rd party tools exist to treat that data. Here, you can see how many times the Ubuntu (or any other) Docker image has been pulled, updated in real time: $ wget -q -O- https://hub.docker.com/v2/repositories/library/ubuntu/ | python -m json.tool >> E.g. People would be >> able to see that X% of Ubuntu users are based in .de vs Y% in .za. Z% >> of our users run Dell hardware, and so on. >> The Ubuntu privacy policy would be updated to reflect this change. >> >> Any user can simply opt out by unchecking the box, which triggers one >> simple POST stating, “diagnostics=false”. > > Why does this require a POST (over the network)? Understanding the sample size, as a ratio to the total population, is an essential characteristic in determining statistical validity, and required to draw accurate inferences based on the data. >> There will be a corresponding >> checkbox in the Privacy panel of GNOME Settings to toggle the state of this. >> >> And to reiterate, the service which stores this data would *never* store >> IP addresses. >> >> We value your feedback and comments! > > I don't believe that sending data by default is 'a thing that matters > most to our users'. Quite the opposite in fact. MS was/is getting a lot > of heat for their data collection and we shouldn't go down that very > same route by making data gathering the default. I do believe that quality, stability, security, usability, and free availability are what matters most to Ubuntu users. We can drastically improve the quality of Ubuntu through tastefully, anonymously gathered diagnostics. We can significantly improve the stability of Ubuntu by automatically processing crash reports. We can seriously improve the security of Ubuntu by analyzing the package sets most frequently installed and focusing our resources on the software that matters most. Cheers! Dustin > ..
Re: More diagnostics data from desktop
On Thu, Feb 15, 2018 at 4:16 AM, Ernst Sjöstrand wrote: > Hi, > > "Send diagnostics information to help improve Ubuntu" sounds like > you're continuously reporting things, but your proposal looks more > like a single "installation ping" or something. > I guess the apport and popcon reports would be continuous though? The list that Will shared would be a one-time shot, after install, asynchronously after networking is up on first boot (unless opted-out). Popcon would report periodically, and Apport would report crashes (again, unless opted out). > If you do this you should really make sure everything has http proxy > (set in user session only?) support, so you can pick up some extra > corporate users. For sure! Good catch. > Sending it from the user session fits well with the privacy settings. > > Sounds reasonable otherwise. Are trackpads enought trouble to collect data on? Potentially. That's the exact sort thing that we need data on, to help make Ubuntu better :-) Cheers, Dustin > Regards > //Ernst > > 2018-02-14 16:22 GMT+01:00 Will Cooke : >> Dear all, >> >> We want to be able to focus our engineering efforts on the things that >> matter most to our users, and in order to do that we need to get some more >> data about sort of setups our users have and which software they are running >> on it. >> >> We would like to add a checkbox to the installer, exact wording TBD, but >> along the lines of “Send diagnostics information to help improve Ubuntu”. >> This would be checked by default. >> >> The result of having that box checked would be: >> >> * Information from the installation would be sent over HTTPS to a service >> run by Canonical’s IS team. This would be saved to disk and sent on first >> boot once there is a network connection. The file containing this data >> would be available for the user to inspect. >> >> That data would include: >>* Ubuntu Flavour >>* Ubuntu Version >>* Network connectivity or not >>* CPU family >>* RAM >>* Disk(s) size >>* Screen(s) resolution >>* GPU vendor and model >>* OEM Manufacturer >>* Location (based on the location selection made by the user at install). >> No IP information would be gathered >>* Installation duration (time taken) >>* Auto login enabled or not >>* Disk layout selected >>* Third party software selected or not >>* Download updates during install or not >>* LivePatch enabled or not >> >> * Popcon would be installed. This will allow us to spot trends in package >> usage and help us to focus on the packages which are of most value to our >> users. >> >> * Apport would be configured to automatically send anonymous crash reports >> without user interruption. >> >> The results of this data would be made public. E.g. People would be able to >> see that X% of Ubuntu users are based in .de vs Y% in .za. Z% of our users >> run Dell hardware, and so on. >> The Ubuntu privacy policy would be updated to reflect this change. >> >> Any user can simply opt out by unchecking the box, which triggers one simple >> POST stating, “diagnostics=false”. There will be a corresponding checkbox >> in the Privacy panel of GNOME Settings to toggle the state of this. >> >> And to reiterate, the service which stores this data would *never* store IP >> addresses. >> >> We value your feedback and comments! >> >> Cheers, Will >> On behalf of the Ubuntu Desktop Team >> >> >> -- >> ubuntu-devel mailing list >> ubuntu-devel@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel >> > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Ubuntu Desktop Favorite Apps
Howdy Ubuntu, Working with Will Cooke (Canonical's Ubuntu Desktop Engineering Manager), we've put together a short survey for you, the Ubuntu community, as well as the broader Linux ecosystem at large. We're seeking your input on your favorite apps for the Linux desktop. You're welcome to engage in discussion here, or in any one of the following venues where we've cross posted this request, in the interest of the broadest possible engagement with the Ubuntu community at large: Google Forms Survey: - https://ubu.one/apps1804 HackerNews: - https://news.ycombinator.com/item?id=14819508 Reddit: - https://www.reddit.com/r/Ubuntu/comments/6on93z/ubuntu_1804_lts_desktop_default_application_survey/ Slashdot: - https://slashdot.org/submission/7250965/ubuntu-1804-lts-desktop-default-application-survey Cheers, Dustin Kirkland Ubuntu Core Developer Ubuntu Product and Strategy @dustinkirkland -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposal: removing net-tools from ubuntu-minimal in 17.04
On Sat, Jan 14, 2017 at 12:27 PM, Steve Langasek wrote: > Hi all, > > Starting last month, Debian has been discussing dropping net-tools[1], which > prompted me to review its status in Ubuntu. This package, which provides > various commands like ifconfig and netstat, is currently part of > ubuntu-minimal. However, the tools in this package are largely considered > superseded by iproute2, providing 'ip' and 'ss' tools that interface much > better with modern kernels. And iproute2 is also part of ubuntu-minimal. > > Is there a reason to keep net-tools in ubuntu-minimal, or should we remove > it from the minimal set for 17.04? Packages / flavors that want it can > still depend on it (which they should technically already be doing anyway). I'm +1 on dropping net-tools from ubuntu-minimal, as long as we keep it in the ubuntu-server seed. There are lots of user scripts and tools that awk and grep their way around ifconfig output, that we should be careful not to break, in the default Ubuntu experience. But, I agree that the minimal Ubuntu image can certainly get by with just /sbin/ip. Thanks, Dustin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC on Cloud Images: Make /tmp a tmpfs
On Jan 22, 2016 11:52 AM, "Colin Watson" wrote: > > On Fri, Jan 22, 2016 at 09:09:10AM -0600, Dustin Kirkland wrote: > > According to the 502 servers surveyed, 97.2% use less than 1.5 GB of > > /tmp. > > I'm not expressing any particular view on the overall topic either way > here, but for the sake of accuracy, I believe that that is not in fact > what the data you collected says. It says that, at the point in time > when the data was collected, 97.2% of those servers were currently using > less than 1.5 GB of /tmp. Temporary files are temporary, and often > bursty; a single point sample might line up with the high-water-mark on > those servers, and it might not. But if you're going to quote > statistics to three significant figures, then people reading it might > reasonably expect more precision in their construction. That's absolutely true and I've tried to accurately express that when I've quoted these stats. You've identified a sentence where the wording was poor. In fairness, I stated the caveats, including that one, up front in the detailed analysis published at: http://blog.dustinkirkland.com/2016/01/data-driven-analysis-tmp-on-tmpfs.html I should have written: Of the 502 servers surveyed, 97.2% were using less than 1.5 GB of /tmp (at the time the data was collected). Thanks for the note. Dustin > -- > Colin Watson [cjwat...@ubuntu.com] > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC on Cloud Images: Make /tmp a tmpfs
On Thu, Jan 21, 2016 at 5:38 AM, Martin Pitt wrote: > Dimitri John Ledkov [2016-01-21 11:31 +]: >> Is it just me, or did the RFC asks about cloud-images alone, and we >> are diverging to discussing all the things, and all the form factors, >> and all the installation types. > > That's true, sorry for diverging this. > >> And, e.g. imho the default should be off for cloud-images as pointed >> out earlier. But others are advocating otherwise. > > FTR, I agree. I don't think it makes much sense for VMs to do this, > unless of course they have a r/o root (but then you don't have a > choice anyway, so this isn't part of this discussion). Respectfully, Martin, the data and research disagrees. I/O to EBS, Azure, or any other physical disks in the cloud is really quite painfully slow. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC on Cloud Images: Make /tmp a tmpfs
On Thu, Jan 21, 2016 at 4:14 AM, Martin Pitt wrote: > Robie Basak [2016-01-21 9:56 +]: >> I think we need a single canonical (small c) answer. Let's say that I'm >> an upstream maintainer of a project that currently uses large amounts of >> space in /tmp (say debdiff on kernel sources, for example). A user files >> a bug that his machine now explodes when he uses my program. How should >> I fix the bug? > > How is that any different than what we have now? systems with more > memory than space on the root partition do exist [1], systems with > /tmp on tmpfs do exist. We are *not* going from "/tmp has indefinite > space" to "/tmp has little space", we are just changing the limit (not > necessarily downwards even!) to a differently fuzzy definition. Martin is absolutely correct! Ubuntu's AWS images which are EBS backed -- the VAST majority of Ubuntu currently running in the world -- all have a root volume of 7.8 GB. Here's a fresh instance: ubuntu@ip-172-30-0-30:~⟫ df -h / Filesystem Size Used Avail Use% Mounted on /dev/disk/by-uuid/0a76513a-37fc-43df-9833-34f8f9598ada 7.8G 790M 6.6G 11% / With Ubuntu 14.04 LTS, /tmp is still on that root volume, giving me ~6.6 GB of usable space there: ubuntu@ip-172-30-0-30:~⟫ df -h /tmp/ Filesystem Size Used Avail Use% Mounted on /dev/disk/by-uuid/0a76513a-37fc-43df-9833-34f8f9598ada 7.8G 790M 6.6G 11% / However, the instance that I just launched has 16 GB of memory: ubuntu@ip-172-30-0-30:~⟫ free total used free sharedbuffers cached Mem: 16433132 380392 16052740428 8468 209584 -/+ buffers/cache: 162340 16270792 Swap:0 0 0 Let's remount /tmp on tmpfs: ubuntu@ip-172-30-0-30:~⟫ df -h /tmp/ Filesystem Size Used Avail Use% Mounted on tmpfs 7.9G 0 7.9G 0% /tmp How about that... My /tmp space actually went up! In fact, 27 of the 39 current AWS instance types have >15GB of memory. Oh, and EBS writes -- are SLOW! ubuntu@ip-172-30-0-30:~⟫ dd if=/dev/zero of=/tmp/zero bs=2G count=1 2147479552 bytes (2.1 GB) copied, 1.35841 s, 1.6 GB/s ubuntu@ip-172-30-0-30:~⟫ dd if=/dev/zero of=/home/ubuntu/zero bs=2G count=1 2147479552 bytes (2.1 GB) copied, 2.3478 s, 915 MB/s ubuntu@ip-172-30-0-30:~⟫ dd if=/dev/zero of=/tmp/zero bs=2G count=1 oflag=dsync 2147479552 bytes (2.1 GB) copied, 1.34014 s, 1.6 GB/s ubuntu@ip-172-30-0-30:~⟫ dd if=/dev/zero of=/home/ubuntu/zero bs=2G count=1 oflag=dsync 2147479552 bytes (2.1 GB) copied, 23.1934 s, 92.6 MB/s So on these instance types, /tmp on tmpfs provides both *more* storage, and *faster* storage! tmpfsffs, Dustin > If you program dumps vast amounts of data into /tmp, that is a problem > somewhere no matter what you do. /var/tmp/ has traditionally had a > better chance of carrying large files (but of course also not > guaranteed). > > Martin > > > [1] We've even had bug reports where people filled the root partition > and then weren't able to log in any more because /tmp/ could not be > written into. We detected this on boot and mounted a small tmpfs over > /tmp/ to mitigate this. > > -- > Martin Pitt| http://www.piware.de > Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC on Cloud Images: Make /tmp a tmpfs
On Thu, Jan 21, 2016 at 5:31 AM, Dimitri John Ledkov wrote: > Is it just me, or did the RFC asks about cloud-images alone, and we > are diverging to discussing all the things, and all the form factors, > and all the installation types. > > Certainly it should be easy to use tmp on tpmfs with cloud-images, > which i would presume would have a cloud-init on/off toggle, > irrespective of the default. > And, e.g. imho the default should be off for cloud-images as pointed > out earlier. But others are advocating otherwise. > > Dustin stats are for both physical and virtual machines... not sure > how that helps to make a decision for cloud-images in isolation. Given > that they are used quite differently. The Ubuntu Cloud Images will default to /tmp on tmpfs when the system has >3GB of RAM (which accounted for 89.6% of the 502 servers I surveyed), and allow override in either direction through cloud-init (and perhaps allow overiding that threshold of 3GB). tmpfs defaults to making half of the available RAM usable in /tmp (and that is configurable in /etc). According to the 502 servers surveyed, 97.2% use less than 1.5 GB of /tmp. Perhaps more importantly, based on that model, ALL of the servers surveyed who would have "qualified" for /tmp on tmpfs -- ie, all 450 servers with >3GB of RAM -- would fit all of the current contents of their /tmp in the tmpfs (in fact, within freely available memory). The Ubuntu Cloud Images are the same image used in public clouds (Amazon, Azure, GCE), private clouds (OpenStack), and for physical machines provisioned through MAAS. So physical Ubuntu servers will benefit from this change in default behavior, just like virtual machines. I cannot speak for the Ubuntu Desktop, and I'm not extending this proposal there too (but frankly, I know that it would be beneficial for the masses there too, and I'd be delighted to see someone fight that good fight). Finally, I just downloaded a Snappy amd64 image and booted it a KVM. And whattayaknow... /tmp is on tmpfs! I also downloaded Snappy armhf, and flashed it to my rpi2. And guess what... /tmp is on tmpfs! And Ben just launched Snappy in AWS, GCE, and Azure, and I just launched Snappy in OpenStack. Where's /tmp in all four cases? Yep. You guessed it. It's on tmpfs! Dustin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC on Cloud Images: Make /tmp a tmpfs
On Wed, Jan 20, 2016 at 5:45 PM, Robie Basak wrote: > On Wed, Jan 20, 2016 at 05:27:51AM +0100, Dustin Kirkland wrote: >> > I'd like to see even some rudimentary experiments done with realistic >> > workloads before saying this is a better idea than leaving things as >> > they are. We've all speculated and provided anecdotal evidence enough to >> > warrant such an investigation for those who speculate it will be a >> > worthwhile change. >> >> Sure, done! You can find a detailed statistical analysis, as well as >> the raw data for your download and treatment at: > > This is useful. Thank you for this research! > >> http://blog.dustinkirkland.com/2016/01/data-driven-analysis-tmp-on-tmpfs.html > > Are we sure that using /dev/zero is a fair test? I hope this isn't > shortcutted somehow in the tmpfs case. No, I'm not sure. But I also can't find any "faster" source of data than /dev/zero :-) /dev/urandom can't keep up, nor can any /dev/ Have a look at this page to understand how benchmarking with dd works, and what it actually does: https://romanrm.net/dd-benchmark I've also copied Colin King, who is the king of performance benchmarking, in my book :-) >> Based on a statistical analysis of 502 physical and virtual servers >> running production and test services at Canonical (including >> databases, websites, OpenStack, ubuntu.com, launchpad.net, et al.), >> 96.6% of them could fit all of the data they currently have in /tmp, >> entirely in half of the free memory available in the system. That >> ratio goes up to 99.2% of the systems surveyed (i.e., all but 4) when >> one takes into account both free available memory and available swap. >> The remaining 4 systems are are currently using [101 GB, 42 GB, 13 GB, >> and 10 GB] of swap, respectively, and are themselves somewhat special >> cases. > > Even if they are special cases, surely that's something we need to > consider for our users? If your data is representative, isn't that > around 1% of users who will be impacted or broken somehow by this change > in defaults? In fact it's our job as Ubuntu developers to make intelligent, informed, data-driven decisions about opinionated defaults that cover the vast majority of our users and clearly document solutions to problems affecting the remainder. We do this all the time, in all aspects of Ubuntu, from upstream project versions, to default package sets and default configuration options! It's important that we do so carefully, tastefully, scientifically, and that we course correct gracefully when we're wrong ;-) > What would be the guidance for 1) users; and 2) upstreams; if they want > large temporary filesystem space after this change? Would that be to use > /var/tmp in all relevant cases? And for upstreams, is this something > that they will accept that they can do universally, or is it behaviour > that they have to differentiate depending on the distro upon which they > are running? Good question... Solutions to insufficient available space in /tmp on tmpfs include any and all of the following: (a) commenting out the "tmpfs /tmp tmpfs rw,nosuid,nodev" line in /etc/fstab (b) setting $TMPDIR to /var/tmp (or elsewhere) in your shell profile (c) pointing your application at /var/tmp (or elsewhere) (d) allocating sufficiently large swap partition(s) or swap file(s) to overflow into (e) using the swapspace package to dynamically grow/shrink swap on demand >> Moreover, Ubuntu is hardly the first Linux/UNIX distribution that has >> considered putting /tmp on tmpfs by default. Solaris has used a tmpfs >> since 1994. Fedora moved to /tmp on tmpfs in 2012, as did ArchLinux. >> Things seem to be working okay there... > > This is really useful to know, thanks. > > Robie -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC on Cloud Images: Make /tmp a tmpfs
On Sat, Jan 16, 2016 at 7:49 PM, Clint Byrum wrote: > Excerpts from Dustin Kirkland's message of 2016-01-16 04:25:58 -0800: >> On Fri, Jan 15, 2016 at 2:25 AM, Seth Arnold >> wrote: >> > On Thu, Jan 14, 2016 at 12:27:58PM +0200, Dustin Kirkland wrote: >> >> Moreover, just 'sudo apt-get install swapspace' and watch as swapfiles >> >> are created/deleted as needed. If your root disk is lvm-encrypted, >> >> then obviously such swap files are encrypted, too. >> > >> > I've been severely skeptical of the swapspace package: >> > >> > - Swap is used when the system is already under pressure; a few hundred >> > megs is great and probably for the best but if the system is actively >> > pushing beyond that then it's being pushed too hard. >> > >> > - If the swap space is going to be allocated on the fly, that means the >> > disk blocks have to zeroed on the fly, when the system is under >> > pressure, rather than at some leisurely time beforehand. >> > >> > - If the swap space is allocated on a filesystem, it's probably being >> > allocated from a fragmented filesystem that's 90% full rather than a >> > nice contiguous block of space as it would with a swap partition. >> > >> > - Accessing further into a file may involve loading multiple indirect >> > blocks from disk into unswappable kernel memory. A swap partition does >> > not require indirection blocks. >> > >> > - If the swap space allocated from a filesystem pushes the filesystem to >> > 95% full (or whatever is left after accounting for reserved blocks), >> > programs will error and almost nothing handles "disk full" errors >> > gracefully. Swap partitions do not cause surprise gigabyte losses in >> > free space. >> > >> > - Swap files can't be allocated from btrfs filesystems and probably >> > shouldn't be allocated from zfs filesystems either. (Swap on zvols, >> > maybe.) >> > >> > Perhaps the swapspace package uses some tasteful tunables to mitigate >> > against my concerns but the end result is that it contributes extra load, >> > extra IO pressure, and extra uncertainty at a time when the system is >> > already experiencing too much load, too much IO pressure, and too much >> > uncertainty. >> > >> > The risks and downsides of swapspace feel like a lot compared to the >> > slight hassle of having the installer make a swap partition. >> >> I count 4 "if's", 3 "probably's", 2 "should/would's", and 1 "maybe" in >> that reply :-) >> >> Perhaps try it out? >> >> I've been running it and /tmp on tmpfs for several years (since before >> ~precise) on my desktop on an encrypted LVM partition. My machine has >> a lot of memory (16GB), though I do push it hard), and have never >> noticed a swapspace-related problem. I've also used this combination >> on hundreds of servers, and several production systems. >> > > The 'if' and 'probably' are missing in your anecdotal evidence though. > If you use the servers the way you have, it will probably work fine. > Also we're talking about cloud instances, not "servers", which have > quite different use and performance profiles. > > I'd like to see even some rudimentary experiments done with realistic > workloads before saying this is a better idea than leaving things as > they are. We've all speculated and provided anecdotal evidence enough to > warrant such an investigation for those who speculate it will be a > worthwhile change. Sure, done! You can find a detailed statistical analysis, as well as the raw data for your download and treatment at: http://blog.dustinkirkland.com/2016/01/data-driven-analysis-tmp-on-tmpfs.html Based on a statistical analysis of 502 physical and virtual servers running production and test services at Canonical (including databases, websites, OpenStack, ubuntu.com, launchpad.net, et al.), 96.6% of them could fit all of the data they currently have in /tmp, entirely in half of the free memory available in the system. That ratio goes up to 99.2% of the systems surveyed (i.e., all but 4) when one takes into account both free available memory and available swap. The remaining 4 systems are are currently using [101 GB, 42 GB, 13 GB, and 10 GB] of swap, respectively, and are themselves somewhat special cases. Moreover, Ubuntu is hardly the first Linux/UNIX distribution that has considered putting /tmp on tmpfs by
Re: RFC on Cloud Images: Make /tmp a tmpfs
On Fri, Jan 15, 2016 at 2:25 AM, Seth Arnold wrote: > On Thu, Jan 14, 2016 at 12:27:58PM +0200, Dustin Kirkland wrote: >> Moreover, just 'sudo apt-get install swapspace' and watch as swapfiles >> are created/deleted as needed. If your root disk is lvm-encrypted, >> then obviously such swap files are encrypted, too. > > I've been severely skeptical of the swapspace package: > > - Swap is used when the system is already under pressure; a few hundred > megs is great and probably for the best but if the system is actively > pushing beyond that then it's being pushed too hard. > > - If the swap space is going to be allocated on the fly, that means the > disk blocks have to zeroed on the fly, when the system is under > pressure, rather than at some leisurely time beforehand. > > - If the swap space is allocated on a filesystem, it's probably being > allocated from a fragmented filesystem that's 90% full rather than a > nice contiguous block of space as it would with a swap partition. > > - Accessing further into a file may involve loading multiple indirect > blocks from disk into unswappable kernel memory. A swap partition does > not require indirection blocks. > > - If the swap space allocated from a filesystem pushes the filesystem to > 95% full (or whatever is left after accounting for reserved blocks), > programs will error and almost nothing handles "disk full" errors > gracefully. Swap partitions do not cause surprise gigabyte losses in > free space. > > - Swap files can't be allocated from btrfs filesystems and probably > shouldn't be allocated from zfs filesystems either. (Swap on zvols, > maybe.) > > Perhaps the swapspace package uses some tasteful tunables to mitigate > against my concerns but the end result is that it contributes extra load, > extra IO pressure, and extra uncertainty at a time when the system is > already experiencing too much load, too much IO pressure, and too much > uncertainty. > > The risks and downsides of swapspace feel like a lot compared to the > slight hassle of having the installer make a swap partition. I count 4 "if's", 3 "probably's", 2 "should/would's", and 1 "maybe" in that reply :-) Perhaps try it out? I've been running it and /tmp on tmpfs for several years (since before ~precise) on my desktop on an encrypted LVM partition. My machine has a lot of memory (16GB), though I do push it hard), and have never noticed a swapspace-related problem. I've also used this combination on hundreds of servers, and several production systems. Here's /etc/swapspace.conf, with its tunables... http://paste.ubuntu.com/14516155/ -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC on Cloud Images: Make /tmp a tmpfs
On Thu, Jan 14, 2016 at 6:49 AM, Steve Langasek wrote: > On Wed, Jan 13, 2016 at 11:00:16PM +0100, Martin Pitt wrote: >> Ben Howard [2016-01-13 14:26 +0200]: >> > On the Ubuntu Cloud Images, we have a request to make /tmp a tmpfs. The >> > rationale, from the bug: >> > * Performance - much faster read/write access to data in /tmp >> > * Security - sensitive data would be cleared from memory on boot, >> >rather than written (leaked) to disk -- important for encryption >> >scenarios > >> > Since the Ubuntu Cloud Images are used by a wide number of users, I >> > wanted to gather feedback and gather consensus on whether or not we >> > should make this change. > >> I really wish we would do this in general for new installs, at least >> as the first thing after releasing 16.04 LTS. I also do this on my >> boxes, not only for the reasons above [1], but also because it is much >> more power efficient -- as I literally work in /tmp a lot of my time >> the disk doesn't need to spin up often. > >> The main reason AFAIK why we didn't yet do that was the concern that >> there is some broken software out there which potentially dumps really >> large files into /tmp (yes firefox, I'm looking at YOU!). These would >> need to be fixed to go to /var/tmp. This is a chicken-and-egg problem, >> though: We won't find out what's broken until we actually enable it on >> real-life installations. This problem applies to cloud image use cases >> just as much as desktop or "classic" servers. > >> My gut feeling is that we should do it if there is ≥ 4 GB RAM, so that >> /tmp as at least 2 GB of space (That should be a rather simple >> installer/cloud-init decision?). We don't want to do this on small >> embedded devices with 512 MB of RAM or so, but there is absolutely no >> reason to not do it on beefy servers or laptops. > > As a data point, I used to have my /tmp on tmpfs while I still had a > spinning disk, in order to address the power usage issues of disk flushing. > I found it to be a least-bad option which led to serious degradation of > desktop interactivity in the face of even moderate memory usage (at the > time, with 4GB RAM), and not because of excessive /tmp usage. > > And as others in this thread have noted, this same problem can occur in > cloud instances. Definitely. /tmp on tmpfs saves energy when you have a spinning HDD, and extends the life of your SSD by reducing the number of NAND flash writes! -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC on Cloud Images: Make /tmp a tmpfs
On Thu, Jan 14, 2016 at 12:56 PM, Oliver Grawert wrote: > hi, > Am Mittwoch, den 13.01.2016, 23:00 +0100 schrieb Martin Pitt: >> Ben Howard [2016-01-13 14:26 +0200]: >> > On the Ubuntu Cloud Images, we have a request to make /tmp a tmpfs. The >> > rationale, from the bug: >> > * Performance - much faster read/write access to data in /tmp >> > * Security - sensitive data would be cleared from memory on boot, >> >rather than written (leaked) to disk -- important for encryption >> >scenarios >> > >> > Since the Ubuntu Cloud Images are used by a wide number of users, I >> > wanted to gather feedback and gather consensus on whether or not we >> > should make this change. >> >> I really wish we would do this in general for new installs, at least >> as the first thing after releasing 16.04 LTS. > > while i'm all for it, lets please have a check for RAM size in that > code, you really dont want /tmp in ram on a low ram system with i.e. > 64-128MB (thin client, embedded box or whatever) by default. Totally agree! The bug is updated :-) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC on Cloud Images: Make /tmp a tmpfs
On Thu, Jan 14, 2016 at 1:42 PM, Robie Basak wrote: > On Thu, Jan 14, 2016 at 01:39:23PM +0200, Dustin Kirkland wrote: >> +1! MIR swapspace, add it to the images, and get rid of static swap >> partitions, please :-) > > Do we have a blueprint to track the tmpfs /tmp item? MIR swapspace > should be a work item on there in this case. There's this one, circa 2009: https://blueprints.launchpad.net/ubuntu/+spec/server-karmic-tmp-as-tmpfs -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC on Cloud Images: Make /tmp a tmpfs
On Thu, Jan 14, 2016 at 1:20 PM, Robie Basak wrote: > On Thu, Jan 14, 2016 at 12:27:58PM +0200, Dustin Kirkland wrote: >> Moreover, just 'sudo apt-get install swapspace' and watch as swapfiles >> are created/deleted as needed. If your root disk is lvm-encrypted, >> then obviously such swap files are encrypted, too. > > I didn't know about this package, thanks. :-) You're welcome. > Should we MIR it and make it available (maybe even installed by default, > whether enabled or disabled) on the cloud images at the same time? If > this becomes our standard answer for "but /tmp runs out of space in > tmpfs" then that feels appropriate to me. +1! MIR swapspace, add it to the images, and get rid of static swap partitions, please :-) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC on Cloud Images: Make /tmp a tmpfs
On Thu, Jan 14, 2016 at 12:05 AM, Seth Arnold wrote: > On Wed, Jan 13, 2016 at 11:00:16PM +0100, Martin Pitt wrote: >> In a perfect world we'd have some clever tmpfs file system which would >> use RAM as available and start overflowing onto a disk partition >> (which could be LUKS with a random key) when necessary.. But even > > In fact this is what happens, 'unused' data from tmpfs heads to swap. So > just configure swap space on your systems. Moreover, just 'sudo apt-get install swapspace' and watch as swapfiles are created/deleted as needed. If your root disk is lvm-encrypted, then obviously such swap files are encrypted, too. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Libav11 for Utopic
On Tue, Aug 19, 2014 at 7:16 AM, Reinhard Tartler wrote: > Hi, > > I'm wondering what people think about having Libav11 in Ubuntu. In > debian, this transition as coordinated in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757917 > > This time, Libav11 is source-code compatible to Libav10. While the > SONAMEs did change, packages just need to be recompiled and do not > require additional patching. Given that we just transitioned to > Libav10, I expect this to be rather painless in Ubuntu. I did a mass > recompilation in Debian, and it worked out pretty well. > > I realize that Feature Freeze is just around the corner, so time is > running out. I would therefore appreciate a quick decision on this. > > Thanks a lot for considering. Is there a PPA available for Libav11? If so, I'd be glad to test it out a bit, and ensure that our transcoding Juju charm [1] works well with it. http://blog.dustinkirkland.com/2014/07/scalable-parallel-video-transcoding-on.html Cheers, Dustin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu Server seeded package review
On Tue, Dec 3, 2013 at 4:50 PM, Barry Warsaw wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Dec 03, 2013, at 04:33 PM, James Page wrote: > >>As part of tidying for the next LTS release, the Server Team are >>proposing a review of server released seeded packages that are >>currently in Ubuntu main (proposed changes tracked in [0] for now). > > Continuing to demote Python 2, we want to get rid of it on server[*] if at all > possible. For example, I've identified byobu, landscape-common, and vim as > three packages with `Task: server` pulling in Python 2.7. > > For byobu, we have LP: #1253458, currently waiting on some feedback from > Dustin. This is incurring a bit of work for me upstream, in trying to continue producing a Byobu orig tarball that runs everywhere (back to Ubuntu 12.04, weird UNIXes, weird Linuxes)... But you have my commitment that it will be fixed for Ubuntu 14.04. Thanks ;-) > For vim, we have http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729924 > currently waiting on feedback from Debian Vim maintainers. I'm not a Vim > user, but if you want to help test this, a package is available in my PPA: > > https://launchpad.net/~barry/+archive/experimental > > Based on your feedback, I'd be willing to temporarily get ahead of Debian > here. > > landscape-client may be trickier because that gets us into some Twisted > packages, which aren't yet packaged for Python 3. > > See also (and add anything missing!): > > https://blueprints.launchpad.net/ubuntu/+spec/core-1311-python3-roadmap > http://tinyurl.com/mmj4y6a > >>http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.trusty/view/head:/server-ship > >>Description: Server ISO image >> >>nut, nut-cgi, nut-snmp (move to supported-misc-servers) >>likewise-open (largely unmaintained in distro - >>https://help.ubuntu.com/community/LikewiseOpen) >>powernap, powernap-server (still revelvant?) > > Looks like powernap still depends on Python 2. > >>quagga (maybe move to supported-misc-servers) >>backuppc >>python-beautifulsoup > > Whatever is pulling this one in should be ported to python3-bs4, or at least > python-bs4 since afaict beautifulsoup 3 is no longer being actively maintained > upstream (critical bug fixes only according to them). > >>python-genshi (will be pulled into main via supported-misc-servers ... > > Upstream 0.7 supports Python 3, but not yet Debian - BTS #731280. > >>python-pecan) > > Upstream 0.4.2 supports Python 3, but not yet Debian - BTS #731283. > > Cheers, > - -Barry > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.15 (GNU/Linux) > > iQIcBAEBCAAGBQJSnmBKAAoJEBJutWOnSwa/6vsP/jNdnhx9xIM7HiNvgaL0QIr0 > DTuZwxL87E086hdDY0X8fqTf/vT+Xo+zecuHwedePIOL8BZlA/mWX8Bsge7nQc3g > 1jInf6rBR6qNMgEos1gh/5xTJgvq+WS7zLLrPwabejWmOlyT7R13mPEEuJ5ozBfC > G8QcH5Hl61B84SbTd2Pfxjfr+ae6gxsfuqhQcYJ4JuIQ5EIvSV0txvG2tRJuUaCG > AXGg3kiX4IbjeKIMIr4MO9YRlNhgJTp1QR8j4wsZU8yH3xyjukOeBd5jlD+zItT8 > ZlCVdiXZaPR3qsBNIZTszVQ8W00h6515BOhdW/RydmyzA/bf15usaJPImlJjpQ0d > AWEpsO3a9RlKzJBmfiwNYAkUPBd+xRNT0DVDRF+XhVrUJLhee/U3VUl6luzu2I1V > rYC0XU8TneEp92D0XNHM9IyNft0/UyfYQbioTBfb2NBnPRoa6pR25JsPMpod4fBW > KBGvAcSg3Xkir7yghCQLNKIE5K6wb3gLufOXTjqnMSjajOk4NnRfI3hBHoiXMkh+ > 0fmkwpWHUeYbF7Hol+DYC297Nd/AbYxBfaE2FnC0ElE9Y6tjs/o9krarRtEX1Ay0 > kIYDTRMUBSMRhjm5TGY7LPKeOdMZHXfUTf75vtKdSecHk9Gt4hOvqR2J1Wh7nj82 > Vf7zIIz9Rl37N2JU8Hwe > =A7DV > -END PGP SIGNATURE- > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu Server seeded package review
On Tue, Dec 3, 2013 at 10:33 AM, James Page wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi Folks > > As part of tidying for the next LTS release, the Server Team are > proposing a review of server released seeded packages that are > currently in Ubuntu main (proposed changes tracked in [0] for now). > > Here's the initial review of seeds, and some proposed moves and drops > we are considering: > > Branch: > https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.trusty > > http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.trusty/view/head:/server > > Description: Default server install > > whoopsie (ack'ed by ev) > wireless-tools > wpasupplicant > > http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.trusty/view/head:/server-ship > > Description: Server ISO image > > nut, nut-cgi, nut-snmp (move to supported-misc-servers) > likewise-open (largely unmaintained in distro - > https://help.ubuntu.com/community/LikewiseOpen) > powernap, powernap-server (still revelvant?) No objection from me (co-maintainer) to drop PowerNap from the ISO. It's still easy to get post installation. > quagga (maybe move to supported-misc-servers) > backuppc > python-beautifulsoup > python-genshi (will be pulled into main via supported-misc-servers ... > python-pecan) > whoopsie (ack'ed by ev) > mutt > > http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.trusty/view/head:/cloud-image > > Description: Default cloud-image install > > whoopsie (ack'ed by ev) > tasksel (drops aptitude etc.) > euca2ools (move to supported-misc-servers) > > Branch: > https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.trusty > > http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.trusty/view/head:/supported-misc-servers > > Description: Other supported stuff which is not on the ISO > > No candidates identified > > And a few other packages that we'd like to not be part of the cloud > images (which include the 'cloud-image' and 'server' seeds). These > are not explicitly listed in either of these seeds but are pulled in > due to dependencies or Recommends. > > ppp > usbutils > os-prober > aptitude > memtest86 > > ... and discuss! > > I'd like to land any changes early in 2014 prior to feature freeze. > > Cheers > > James > > [0] http://pad.ubuntu.com/server-seed-review > > - -- > James Page > Ubuntu and Debian Developer > james.p...@ubuntu.com > jamesp...@debian.org > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.15 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJSngfVAAoJEL/srsug59jDDG4QAJbbX1aii7pw1mOVliFOjrHc > uDunTZ3acW9dpCL2CdnkHc1TDnEMczko/7Rm8VhdNqENkUc7Z3V6NEaq7itgG/a2 > w6dyszKm8c8MWvnr6lTpor1Hjb+7qomRZdqbQyQZGPCxQyrLbDR62ggEqYztVf36 > glatqylywKRIYhSdTCjD7OteDi9Sur76JOdmAkng+BsjWTnxFQgjju19qpl3MDvm > iOzmd2WQk0GAGQWmrU/8UrKwjglPD+qXJpRjpdSQ3N2iKZRzW3XRXoXMlybqalJC > dkXnfaDSv8sJsFZXatEA6T/3zcpZaByRcdxpEq8aP+EMTov1F6kDtBrXLfWquQGU > V9BRRbfQCA+xPci9lqpcaRha1boFCGTDbp8zOpPhWUoJQzbUS/x1aKjrSggbRj+v > jvrpPxsDud2xOVEcl5rIpmjEkv1YLTh0AVJL1rMI/CvXXvA52dlMwy2qoxN+i4JW > PHMWVH6M29lNfO37/n3uloznVlNde+qR1uuUkZyzd86piHOReTUejUS+Cw5DxtAl > EJooyuT/6eKVx2gY/MvkAWAiOxVXaHl8NaGr/l7sIZTOgL4eYw4flI1Z87X2O7X5 > fUM9iHX31wU8+jIjEehjeOWWaPNJ1WNMS+L8T9SiqCjy+PHvHAajhWd1hUrLiKs8 > HYRLA2uA4Zlf2pOuA6CL > =fbfY > -END PGP SIGNATURE- > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: indicator-weather broken, should we drop it from raring?
So... pywapi eventually landed in 13.04. Is there a Unity indicator that leverages this API now? indicator-weather was dropped after Quantal, and hasn't resurfaced for Saucy. Is there a new alternative for Saucy? :-Dustin Dustin Kirkland Ubuntu Core Developer On Fri, May 24, 2013 at 12:14 PM, Sebastien Bacher wrote: > Le 24/05/2013 19:03, Andrew Starr-Bochicchio a écrit : > >> Looking into updating pywapi in sid is actually on my TODO for the >> weekend. > > > Great, thanks Andrew! > > Cheers, > Sebastien Bacher > > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
On Mon, Apr 30, 2012 at 10:27 PM, Tim Gardner wrote: > Dustin, > > There is a blueprint started for cleaning old kernels. Perhaps you should > add your thoughts to it. > > https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-clean-old-kernels Perfect, thanks, Tim. I'm subscribed and will attend the session. -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
FYI, I have committed a version of a script and a manpage, purge-old-kernels, to lp:bikeshed: * http://bazaar.launchpad.net/~bikeshed/bikeshed/trunk/view/head:/purge-old-kernels * http://bazaar.launchpad.net/~bikeshed/bikeshed/trunk/view/head:/purge-old-kernels.1 It's based on the logic that Kees posted here. However, it will also: - always keep your currently running kernel + to remove your current current, reboot into a newer one, and then re-run the script - default to saving your 2 newest kernels + but that can be easily overridden at run time with --keep N - passes through any other parameters to apt-get + defaults to interactive prompt by apt-get, override with -y For example: $ sudo purge-old-kernels --keep 3 -qy Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: linux-headers-3.2.0-23-generic linux-headers-3.2.0-21 linux-headers-3.2.0-22 linux-headers-3.2.0-23 libcrypto++9 linux-headers-3.2.0-21-generic libnekohtml-java linux-headers-3.2.0-22-generic Use 'apt-get autoremove' to remove them. The following packages will be REMOVED: linux-image-2.6.38-10-generic* linux-image-3.0.0-10-generic* linux-image-3.0.0-11-generic* linux-image-3.0.0-16-generic* linux-image-3.0.0-7-generic* linux-image-3.0.0-8-generic* linux-image-3.0.0-9-generic* linux-image-3.2.0-17-generic* linux-image-3.2.0-18-generic* linux-image-3.2.0-19-generic* linux-image-3.2.0-20-generic* linux-image-3.2.0-21-generic* 0 upgraded, 0 newly installed, 12 to remove and 0 not upgraded. After this operation, 1,801 MB disk space will be freed. ... $ sudo apt-get autoremove -y Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: libcrypto++9 libnekohtml-java linux-headers-3.2.0-21 linux-headers-3.2.0-21-generic linux-headers-3.2.0-22 linux-headers-3.2.0-22-generic linux-headers-3.2.0-23 linux-headers-3.2.0-23-generic 0 upgraded, 0 newly installed, 8 to remove and 0 not upgraded. After this operation, 207 MB disk space will be freed. This cleaned out 2GB of old kernels and headers on my system. If we can decide on an appropriate package where this can land, I'm happy to clean it up and push it there. Otherwise, it can ship in bikeshed or in its own standalone package. Note, I'd *love* to SRU this to older supported Ubuntu's, once this lands in Quantal. Cheers! :-Dustin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, Feb 16, 2012 at 2:31 PM, Kees Cook wrote:
> On Thu, Feb 16, 2012 at 02:21:18PM -0500, Barry Warsaw wrote:
>> On Feb 16, 2012, at 10:11 AM, Dustin Kirkland wrote:
>> >I asked about this in IRC yesterday, and Colin Watson pointed me to
>> >the computer-janitor utility, which is intended to handle this.
>> >Seconds later, Barry Warsaw told me that computer-janitor should die
>> >:-)
>>
>> c-j needs attention, but I'm not particularly motivated to give it what it
>> needs. There's basic housekeeping, such as that the code for c-j is
>> sprinkled
>> between the update-manager and the computer-janitor packages, and even more
>> important problems such LP: #458872. What's demotivating though is that in
>> all the discussions we've had about the tool, most people think it's just not
>> user-friendly enough given today's emphasis on software-center.
>
> FWIW, this is the highly advanced system I use for my auto-updated VMs. It
> keeps the latest 2 kernels:
>
> OLD=$(ls -tr /boot/vmlinuz-* | head -n -2 | cut -d- -f2- | \
> awk '{print "linux-image-" $0}')
> if [ -n "$OLD" ]; then
> apt-get -qy remove --purge $OLD
> fi
>
> Be warned, of course, that if you don't reboot often, you can end up
> removing the kernel you're running. :P
Yeah, something like this, perhaps with a uname -r check, to also
exclude the current kernel you're running, which apparently *is* known
to work.
Regarding computer-janitor and the dbus discussion -- I certainly like
the idea of computer-janitor in general, but I think I agree with
Barry that it feels much more like a desktop than a server solution.
I guess what I would like to see is to take perhaps Kees' script as a
starting point, improve upon that logic slightly, and ship it within
Ubuntu as a consistent, supported, recommended mechanism for vacuuming
out unneeded kernels. Something like 'remove-old-kernels', perhaps
shipping in computer-janitor, or ideally more pervasive. In order to
be useful, though, we'd need to make that script available to
installed systems via SRU.
Barry, would you be willing to accept a shell script along these
lines, into computer-janitor, if I cleaned it up and proposed a merge
and shepherded it through the SRU process? Or, is there a better home
we can agree upon?
- --
:-Dustin
Dustin Kirkland
Ubuntu Core Developer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBCgAGBQJPPXZdAAoJEJXmQ3PxUpRpLaUP/0WaUkIv2keM+ajQ4WTaCIi5
2pLc3Y5Jeds2/TLqMBKxdlx6M/Hh1wuUaIxYBB3d/nELYKCXbeCxiADfaBraRiet
PbPxooNKti3sbVc/vrgpu8oC54E8vb5Jc8d4zPr0qDcnKNMzHGPbxA78z8MlR+TQ
vqAPcmZcvKF9jUESvrdkYd9pefaLsFludHSwLjt2Dw7+SPsyOrXRBLw8FConBzoV
CHZXiI+FyKaMANwsHVX/2O+RrcpsCgwahQpCEjBFghumR09xTI4ONRpfgqzBDSuN
SSdVTvVCC56ZJ15ufJGCaRVWY7ESTq8deuODnD5/4xIKyVetJtZigPenGLB6N81l
eRtM9brTQAgdLgJ/BDr6TxIibwmgEzJp/EEKDC3tHvd2I7ZJZJ5WqYoyFMdtJRnh
Rwsdt9iEbqIn2pv677rGMpQjldgrAIwBPu+EqgCIbCMTse0/s5oATxhP/953fBB5
S14J+PTSOQh4FwHuzjcyMMdtltQyvjAXRZwm989MvblGcABck0nNMH1VJqIDR7ke
ujI+5kYeQGDszeddFhy8qtyqAyPj8hpyzgnDzh+5kQdtftMv8Qvci8tuxAvqNjI2
473WDq2RcqKXFI/hMT63Z44dkxzsht8NXwI1ksR8643fT/owsSZiKzwdxUCgWyyD
7ETOc6yNLB/Gs7o2t7z9
=lFFF
-END PGP SIGNATURE-
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Distro-provided mechanism to clean up old kernels
I understand that I'm not the first to ask this question. In fact, I
see at least 10 similar questions at AskUbuntu.com, and many more
duplicates:
* http://askubuntu.com/search?q=remove+old+kernels
This week, I received a message from one of our commercial ISP/Cloud
Hosting Providers, saying:
>>> Unlike other Linux distributions, Ubuntu does not automatically remove
>>> older, unused kernel packages after an update. Over time, this will fill
>>> the boot partition and result in future updates failing.
The email continued, recommending that we clean up old Ubuntu kernels
using this command:
# dpkg --get-selections|grep 'linux-image*'|awk '{print $1}'|egrep
-v "linux-image-$(uname -r)|linux-image-generic" |while read n;do
apt-get -y remove $n;done
Truly, I connected to several of my Ubuntu servers, some of which have
been running for over 4 years, and I manually purged 3GB+ of old
kernels on some machines!
I don't want to go into all the ways and reasons that the one-liner
above is sub-optimal or even evil, but I would like to call attention
to the generic problem and suggest that as a distribution, we provide
a supported and recommended utility to handle this.
I asked about this in IRC yesterday, and Colin Watson pointed me to
the computer-janitor utility, which is intended to handle this.
Seconds later, Barry Warsaw told me that computer-janitor should die
:-) I tried computer-janitor on my desktop, and it seemed to work
okay. But then I tried it on my servers and it failed:
# sudo computer-janitor find
ERROR:dbus.proxies:Introspect error on :1.3:/:
dbus.exceptions.DBusException:
org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1
matched rules; type="method_call", sender=":1.8" (uid=0 pid=26155
comm="/usr/bin/python /usr/sbin/computer-janitor find ")
interface="org.freedesktop.DBus.Introspectable" member="Introspect"
error name="(unset)" requested_reply="0" destination=":1.3" (uid=0
pid=19905 comm="/usr/bin/python /usr/share/computerjanitor/janitor")
So I guess my questions are:
1) Surely we're not the only Ubuntu users whose /boot or root
partition has filled up with age-old kernels, are we?
2) Is computer-janitor here to stay, or to be abandoned in favor of
something else?
3) Can we expect computer-janitor to work on command-line only
environments (Ubuntu servers) too? If so, can we get SRUs out so that
it works on older distributions?
4) Can we, as a distro, provide and recommend a utility to clean out
specifically old kernels (perhaps aside from cleaning up userspace
cruft a la computer-janitor)?
--
:-Dustin
Dustin Kirkland
Ubuntu Core Developer
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: data.tar.xz support added to Launchpad
On Tue, Oct 25, 2011 at 3:18 PM, Micah Gersten wrote: > It's a check on upload and not during the build would be my guess. Maybe we > should add a lintian warning/error if it uses .xz debs w/out the Speaking of Lintian warnings, would it make sense to have lintian duplicate the original .gz, compress with xz, check the difference and if it's greater than $threshold percentage, print a warning (or info) that using xz compression would save $some %? -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: DMB: Proposal for a different review process
On Thu, Aug 4, 2011 at 9:56 AM, Mackenzie Morgan wrote: > On Thu, Aug 4, 2011 at 10:49 AM, Oliver Grawert wrote: >> hi, >> Am Donnerstag, den 04.08.2011, 10:12 -0400 schrieb Mackenzie Morgan: >>> More like: >>> Ugh, these two getting upset about the people they manage being >>> rejected. Again. How predictable! *eye roll* >> and what forbids them from being like that ? > > As far as I can tell: a rubber stamp. Someone on Dustin's team > applied. Better accept them if we want to avoid another fiasco! ... > Maybe the EMEA region has more folks with a problem with accepting bad > news, but in over a year on the Americas RMB and 6 months on the DMB, > I have ***NEVER*** seen ANYONE jump into a meeting to criticise the > board's decision...except Canonical employees. Period. It's like the > upset parent at a kid's baseball game yelling at the umpire because > the kid struck out. This getting a little personal and pejorative. I'll not take offense, but I would like to defend my name. I've been visibly disappointed with a DMB in IRC in two meetings in the past two months. In neither case, was I challenging the Board's decision. Decisions are for the Board itself. And while I don't consider such Boards infallible, arguing with Board decisions is not productive. And if you read the logs, that's not what I did. I raised concerns about three distinct parts of the DMB's review process, all of which have now shown up in the various threads on the topic. I have apologized publicly for any perceived personal attacks. I should have brought such concerns to the mailing list rather than the IRC channel during the meeting. Now, my concerns were: 1) The lack of a sufficient quorum to render a decision * http://irclogs.ubuntu.com/2011/06/20/%23ubuntu-meeting.html 2) A candidate being challenged as to whether his Ubuntu work was on-the-job (Canonical) work * http://irclogs.ubuntu.com/2011/06/20/%23ubuntu-meeting.html 3) A candidate's work on a Canonical-sponsored upstream project (Orchestra, in this case) being discounted as contributions to Ubuntu; admittedly the candidate himself fell into a trap question and clearly stated that Orchestra was not part of Ubuntu (which is incorrect, btw); the Board is justified in denying a candidate based on such a candidate's opinion; but the general applicability of such contributions toward Ubuntu membership is an important question * http://irclogs.ubuntu.com/2011/07/18/%23ubuntu-meeting.html To (1), there's been discussion on the list about adjusting meeting times to improve quorum. That would be a huge win for everyone. Woohoo. \o/ To (2), it seems that there are both Canonical and non-Canonical employees who believe that Canonical employment should not bias a decision for or against. It also seems many people are in agreement that no such bias exists. I'm fine with that. We've had a reasonable discussion on the topic now. I'm confident in the Board's ability to ensure that no such bias exists. Woohoo. \o/ To (3), the question of how upstream contributions (e.g. Debian, Unity, Orchestra, Ensemble) should or shouldn't be considered "Ubuntu contributions" has been asked, debated, and discussed. To me, this one isn't resolved, and I'd like to see an opinion or even a policy established by an appropriate authority (DMB? CC? TB?). Still, it's been a healthy discussion. A very important one. One that desperately needed to happen, I'm afraid. We'll be a better community because of it. Woohoo \o/ -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: DMB: Proposal for a different review process
On Wed, Aug 3, 2011 at 1:43 PM, Mackenzie Morgan wrote: > On Wed, Aug 3, 2011 at 2:32 PM, Chase Douglas > wrote: >> I don't think the DMB process is an important piece of community >> socialization at all. I doubt many people pay attention to it if they >> don't have a specific need to. There are much better and more important >> social pieces of Ubuntu. I just want to make this piece as painless as >> possible. > > I can think of one case where seeing the social interactions between > an applicant and board members in a meeting *should* have put up big > red flags around that applicant. Apparently they weren't big enough, > but he's gone now, and you can probably guess who I mean. Those red > flags, if they were being noticed, would have been the usefully > "social" part of the meeting. Perhaps. But as you say, this person is "gone now". So there are ways of dealing with mistakes. There are bad uploads to Ubuntu. Those are caught, fixed, replaced, expunged, etc. We all strive to make as few mistakes as possible, but there's a process for rectifying them. Even membership endowments. Ubuntu membership isn't exactly a seat on the US Supreme Court, although it seems that we put some people through a Congressional confirmation process, Clarence Thomas-style... -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: DMB: Proposal for a different review process
On Tue, Aug 2, 2011 at 11:33 AM, Chase Douglas wrote: > Yesterday I attempted to attend a DMB meeting, but unfortunately only > two members showed so there wasn't a quorum. I think I've been to about > an equal number of meetings where quorum has and has not been reached > :(. This led me to think that there must be a better way to handle DMB > proceedings. > > My proposal would be to do away with formal meetings, at least for > evaluating typical applications, and move them to Launchpad. Create a > project (maybe "ubuntu-developer-membership") and then have people open > bugs when they have something to bring up before the board. +1! I think it's a great idea and looks like many of the processes with which we're familiar. Authentication is a big advantage of LP, as is the asynchronous nature (lack of a quorum is so 1775). Having a long, running history for difficult applications would be nice. It would also lend itself better to statistical, historical analysis of approved and rejected applications (which currently require grepping mailing lists and IRC logs). Great idea, Chase. I hope we're up for the change. -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Understanding the definitions and expectations of our membership processes
On Thu, Jul 21, 2011 at 5:52 PM, Iain Lane wrote: > By the way, I am disturbed at the amount of implied criticism the DMB is > receiving in the past couple of weeks. Is it a coincidence that it comes > shortly after we defer some applications (for the first time in a long > while)? I am not just referring to this and the TB email thread, but > also comments that appear on IRC when individuals don't feel an > application is going the way they like. Perhaps this is a reference to some comments I've made in IRC recently. I admit that I am guilty of dishing out some such criticism. Where I've offended people with said criticism, I offer my humble, sincere apologies and hope to avoid offending individual board members in such ways again. I've already contacted these individuals privately, but I'll again offer my public apology here. Please understand that I am fully appreciative of the fact that all of the various Ubuntu governance councils are unpaid, volunteer work, and I am genuinely thankful for the time and thought that these individuals donate to Ubuntu. I declare that even in the face of decisions that I personally disagree with -- I still thank you for your service to our Community and our Project. I am glad that Jorge started this thread, though, as I have been disappointed with the handling of several applications lately. Not so much the final decision, but the process, which I think is more painful than it needs to be. In particular, I'll echo Jorge's concerns around: - The true value of sponsor endorsements. At this point, I'm becoming more and more reluctant to put time or effort into writing endorsements, as it seems to me that they are summarily dismissed in my experience. This is frustrating as an endorser/sponsor to be told over and over and over again, "Sorry, your endorsement is just wrong -- this person is not suitable for the $privileges they've applied for." I'm failing to understand how my personal standards (as well as those of the other 4 or 5 endorsing CoreDevs/MOTUs/Members) can be *so* far off base from the standards applied by the Board. (Speaking of "standards", see the next bullet...) - The pressing need for some standards for what counts as "enough". I've long been frustrated with the fuzzy, moving targets we have for membership and privileges in Ubuntu, and I think we are long, long overdue for some better published standards. I'm not suggesting tick boxes, but better guidelines for how much/long is enough. This would be a refreshing change to a process that makes me shudder every time I hear a friend or colleague is up for vote :-( I immediately offer condolences to them, as I know the pain they're about to feel, like some college fraternity pledge about to get hazed for silly, traditional reasons. Honestly, I'm so, so, *so* proud of what we accomplish in the project that is Ubuntu, but I'm really quite embarrassed by our membership/privilege according processes. I'm having a harder time encouraging any mature, professional developer in good faith to embark on the roller coaster that is Ubuntu membership or upload privileges. - Mostly, I just wish we were a more inclusive organization by nature, rather than defaulting to being so exclusive -- *especially* for non-uploading Memberships. The inclusiveness of Ubuntu (reflecting back on the definition of the word 'ubuntu') was what drew me to the project originally. I feel that we've slipped away from that in recent times, and I pray we find it again soon. -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Removing XULRunner from oneiric - call for help
On Wed, Jun 15, 2011 at 5:16 AM, Chris Coulson wrote: > I've already spent way too much on time on this and I really need to be > doing other things, so unless someone steps up now for a particular > application that they care about, the remaining pacakges depending on > xulrunner will be dropped from the archive by alpha 2. This includes: Hi Chris, Thank you very much for the heads-up. > - xiphos - needs either porting to Webkit (probably a lot of work, but > not sure yet) or switched to using is gtkhtml backend (easy, but gtkhtml > sucks). > - dehydra - already using Spidermonkey, but needs switching to use the > proper lib. Probably just minor build-system changes. > - mongodb - same as dehydra. I can't speak for any of the other packages that you mentioned, but MongoDB is still quite important to the Ubuntu Server Community, as it's about to become a dependency of the CloudFoundry PaaS packages. I know that you and Brian (on CC) have had a private conversation about this, but just for the rest of -devel's and -motu's awareness, Brian is in the process of migrating the mongodb package build to use the replacement library. Thanks! Dustin > - edbrowse - needs porting to Spidermonkey 1.8.5. Based on experience of > doing this already for couchdb, gxine and mongodb, this is probably > going to be a lot of work for the unfortunate victim who ends up doing > this. > > The list of remaining work can be found at > https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-mozilla-rapid-release-maintenance > > There are still other outstanding items not mentioned here, either > because people really shouldn't bother with them, they have someone > assigned or I still plan to look at them (eg, vlc, fennec and eclipse). > > If I've not heard anything by the end of the week, I will assume that > nobody cares about the remaining packages and will start filing removal > requests for them. Please don't remove mongodb, per above ;-) Thanks, -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Just gimme the IP!
Howdy ubuntu-devel!
I'm seeing quite a bit of code duplication in scripts and packaging in
Ubuntu around the determination of IP addresses.
Most are permutations of 'ifconfig' or 'ip addr', and four to six
pipes through awk, grep, sed, and/or cut. Some others dig through
/proc. Some are buggy (ie, more than one ip address on the system,
foreign locale but does not set LC_ALL=C, etc). Many of them do their
job well enough, but I can't help but think there's some room for
improvement.
Here are a few I've found in some server packages:
IP=`ifconfig | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2
| awk '{ print $1}'|head -n 1`
MYIP=$(ifconfig eth0 | grep "inet addr" | awk -F":" '{print $2}' |
awk '{print $1}')
addr_withprefix=$(ip addr show label $default_interface scope global
| awk '$1 == "inet" { print $2 }' | sed "s:/.*::")
In the interest of consistency, I'm wondering if it would make sense
to create and maintain a stable, definitive utility somewhere in
Ubuntu's default seed to provide the system's ip address,
*succinctly*, quickly, and reliably.
I'd think it should:
a) default to ipv4, but support a -6|--ipv6 option
b) default to the interface providing the default route, but support
an optional interface parameter
c) be very, very fast (ie, I looked at facter, but it's pretty slow)
I have what I think is a decent working implementation of the above at:
* http://people.canonical.com/~kirkland/ipaddr
$ ipaddr
192.168.1.109
$ ipaddr virbr0
192.168.122.1
$ time ./ipaddr tap0
10.13.17.92
real0m0.011s
What do you think? Have you seen scripts or packaging in Ubuntu that
would benefit from a solid, recommended ip determination utility?
Where should it live? net-tools? iproute? Somewhere else?
--
:-Dustin
Dustin Kirkland
Ubuntu Core Developer
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Thu, Jun 2, 2011 at 8:14 AM, Matt Zimmerman wrote: > On Fri, May 27, 2011 at 10:17:59AM -0700, Kees Cook wrote: >> On Fri, May 27, 2011 at 04:29:33PM +0100, Matt Zimmerman wrote: >> > On Thu, May 26, 2011 at 04:55:59PM -0700, Kees Cook wrote: >> > > I won't say it doesn't complicate things, but I would like to point out >> > > that everyone else's suggestion for this is to completely remove the >> > > values >> > > from the dmesg report itself, rendering it unavailable to any user, even >> > > root. >> > >> > It seems we are forced into this dichotomy because there is only one log, >> > which is mixing different types of information. Has anyone proposed >> > separating kernel debugging information from simple status logging, and >> > allowing the remainder to remain accessible to users? >> >> I don't think this would end up being sensible either, as the task of >> performing debugging may need access to both. I still don't see the problem >> of debugging as root. If you're not the system owner, you're not going to >> be able to _change_ the system in an effort to fix the problem you are >> debugging. > > Maybe I'm weird, but I use dmesg for a lot of "normal" tasks, not just > debugging problems which will require root to fix. The most common is > probably the traditional "what device node was assigned to that device I > just plugged in?" query. I also have a habit, surely derived from running > lots of bleeding edge code, of running dmesg from time to time just to check > if anything weird is going on. Yeah, I use it to check if a hotplug usb disk showed up, and what scsi device name it got assigned. I also use it (indirectly) to monitor wifi messages a la the wifi-status tool, which watches [iwconfig + ifconfig + dmesg]: * http://manpg.es/wifi-status I suppose wifi-status might need to move to /usr/sbin, and require sudo with your new changes, Kees? -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Uploading to multiple distros
On Thu, Jun 2, 2011 at 8:20 AM, Ian Jackson wrote: ... > One thing I have done a few times is to upload the very same package > simultaneously to (say) Debian and Ubuntu. > > Where the package wants to be identical, and the person doing the > upload is the same, it would be nice if this could be made simpler. > At the moment you basically need to build the whole thing twice with > minor edits to the changelog to set the target suite. > > It would be nice if this could be made simpler. In principle it would > be nice if you could use the same .changes file for uploading to two > distros (provided that only one of them wants binaries) but that may > be too much to ask. > > At the very least it should be possible to do one upload to two > distros without altering the debian/changelog. I handle this using a set of scripts in Ubuntu's bikeshed package: * http://manpg.es/release-build * http://manpg.es/release 'release-build' builds me one binary package, which I test locally, and gives me instructions on what to do next, if I want to proceed with the upstream release and upload to a bunch of different places simultaneously. It also builds source packages for each of the supported Ubuntu releases. If my testing goes well, I'm informed to run the 'release' command. 'release' then does a handful of things (like tagging the release, bumping and opening the next version), and prints a series of commands that I run manually, if I want to actually do the release (such as the bzr push to the trunk, lp-project-upload to put the tarball on Launchpad, dput of the backport changes file to that package's PPA, and dput to Ubuntu Oneiric). (If I had Debian Maintainer privileges, I'd also simultaneously dput to Debian too). I just used release-test, release-build, and release to publish bikeshed-1.15, and captured its log here: * http://paste.ubuntu.com/616969/ These helpers allow me to consistently release dozens of open source projects simultaneously to the current development series of Ubuntu, but also publish "backports" to PPAs of that same package for Lucid/Maverick/Natty. They keep me from making many of the most common mistakes and allow me to upload pretty effortlessly. These scripts are a little Ubuntu/Launchpad/Bzr specific, so I'm not advocating their use to you (Debian), but acknowledging and supporting Ian's suggestion to solve some duplication of effort! -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Missing panel items (was Re: Default Desktop Experience for 11.04 - User testing results)
On Mon, Apr 18, 2011 at 9:12 AM, Stefano Rivera wrote: > Hi Barry (2011.04.18_15:02:06_+0200) >> * The weather notifier is missing. I really like this little notifier so I >> know when to throw open the windows and get some fresh air! > > Having a configurable date format would also be really nice. > >> * System monitor. I like this little applet because it gives me a quick way >> to take the pulse of my system. How hard it's running, is there a lot of >> network activity going on, etc. > > Really really miss that. My laptop's fan volume is a poor substitute for > system-monitor. I feel blind without it. Shameless plug here, but Byobu supports monitoring everything system-monitor does (processor, memory, network, swap, load, disk), and many, many more (like Stefano's fan speed). For those that spend most of their time in a terminal, it might temporarily fill this gap until hopefully these land in Unity one day. I don't know if you're a user, Barry, if you file a bug against byobu for a weather status notification, I'll get that working too! -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: /etc/init.d/* status .. what to do when transitioning to an upstart job?
On Thu, Apr 14, 2011 at 3:11 PM, Kees Cook wrote: > On Thu, Dec 16, 2010 at 08:41:56AM +0100, Thierry Carrez wrote: >> Kees Cook wrote: >> >> /etc/service/status.d >> >> >> >> And if one exists for the job name, run it, otherwise just run the >> >> upstart status and provide an LSB compatible return code. >> >> >> >> This would also allow for the post-start stanza to call the same code if >> >> it is needed. >> >> >> >> Does anyone have strong thoughts on this? Given the service.d approach, >> >> it would seem the correct course of action is to open a feature request >> >> against sysvinit, document it in our upstart job writing best practices, >> >> and to document this feature in the server guide. >> > >> > Why should this be external to upstart? This seems to me like a clearly >> > missing feature in upstart itself. (i.e. a "status" stanza for services >> > that need a non-passive check.) I agree, and we did talk about it at UDS-Natty in Orlando. SJR disagreed with this vehemently, as I recall. >> +1 on an optional, specific "status" stanza in upstart scripts. When >> present, it could be automatically called as a post-start before >> "started" is emitted, and would also be called when "status" is used. > > Has anything happened with this? Would this make a good UDS topic? I'd think it would be a good one to re-visit, perhaps starting with a brief review of where we left it 6 months ago. This is *definitely* something I personally miss, once an init script is converted to an upstart job. "status $foo" tells me almost nothing interesting for most of my values of $foo today :-( -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Patch Pilot Report 2011-04-11
As today is Beta2 freeze, I spent most of my time on: * https://launchpad.net/ubuntu/+milestone/ubuntu-11.04-beta-2 triaging bugs there, and looking for anything to sponsor/fix. * 742857 * non-translated help documentation tweaks, reviewed, committed, uploaded * 678421 * reviewed code back and forth with developer in IRC * needs-fixing, gave him a cleaner/simpler function to use * will revisit when he updates merge proposal * 717166 * eucalyptus task invalid, but looks like there is a fix required against isc-dhcp * turns out this was fixed elsewhere, in another bug not linked to this one * 747090 * updated triage correctly * 732759 * FFe was granted on 3/15 * Checked with developer, this was already uploaded and in Natty, bug just wasn't closed * Marked fix-released * 716689 * Researched and confirmed fix has already landed in Natty * Marked fix-released * 610597 * eCryptfs related bug, talked to assigned dev (jjohansen) * was milestoned against b2, but not practical to fix in that timeframe, so updated milestone to ubuntu-later * 726572 * added cloud-initramfs-tools to uec seed * processed MIR archive promotion * 751807, 752910 * likewise bug fixes * comment added to 751807, as he's using /etc/init.d/* in a postinst, which is not recommended, but is consistent with ~30 other calls in the package's maintainer scripts; I directed the patch author to the Debian Policy Manual section 9.3.3: * http://www.debian.org/doc/debian-policy/ch-opersys.html * otherwise, approved and uploaded * 757540 * handled at ScottK's request * was kind of a pain, as the developer submitted a tarball of their debian packaging directory, rather than a debdiff or a merge proposal * also, I had to grab the upstream release tarball, extract it, rename the contained directory, and repack it * imported dsc to bzr packaging branch and uploaded -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Using something better than Gobby for session notes at UDS
On Sun, Apr 10, 2011 at 12:50 PM, James Page wrote: > On Fri, 2011-04-08 at 16:39 -0500, Dustin Kirkland wrote: >> It suffers from most the usual ailments endemic to large Java packages >> in Debian/Ubuntu. The debconf could use a little bit of love. And >> obviously the change from sunjdk -> openjdk needs a bit of testing. I >> can do a complete review of the packaging as an Archive Admin and >> publish my notes, if we want to consider it for inclusion in Universe >> for Oneiric, but I haven't done so thus far. > > Hi Dustin > > I started to take a look at the bundled Java dependencies last week; it > looked like all but 3 of them could be fulfilled through existing Java > libraries in the archive. > > Happy to integrate this into the packaging - do you have a branch I can > work against? Sorry, I did not use a branch for this first cut, however, that is a good idea. You can grab my source with: $ dget https://launchpad.net/~etherpad/+archive/ppa/+files/etherpad_1.1-0ubuntu1%7Eppa3.dsc And debdiff that against: $ dget http://apt.etherpad.org/dists/all/source/etherpad_1.1.dsc I have made you an administrator of the ~etherpad team in Launchpad, such that you can upload iterations of the etherpad packaging to the ppa:etherpad/ppa. Feel free to add any other teams or individuals who wants to help with this work. (Volunteers?) Looks like Elliot Murphy owns the etherpad project in Launchpad -- we should probably hook up this team/project together. Elliot -- I also added you as an administrator of team ~etherpad. Perhaps you can transfer ownership of project etherpad to team ~etherpad? >> James, is this a reasonable starting point? And is there anyone out >> there on ubuntu-devel@ who feels strongly enough about Etherpad/Gobby >> to pick up this packaging/testing and take it from here? > > I would be up for this; the upstream build process is completely > non-standard but we should be able to work it into something more > maintainable. You rock ;-) -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Using something better than Gobby for session notes at UDS
On Mon, Apr 11, 2011 at 2:11 AM, Thierry Carrez wrote: > Dustin Kirkland wrote: >> On Thu, Apr 7, 2011 at 4:32 PM, James Troup >> wrote: >>> I appreciate the frustration people have with gobby and I'd be happy to >>> run something better if that's what you guys want to do - the only thing >>> I'd ask is that someone package Etherpad first[1]. >> >> I started with some source packages for Etherpad 1.1 I found here: >> * http://apt.etherpad.org/dists/all/source/ >> >> I made a few minor modifications: >> 1) used openjdk instead of sun java >> 2) ported the most important subset of the (broken) init script to (a >> working) upstart configuration >> 3) updated debian/control and debian/rules accordingly > > Having discussed that issue with him in the past, I think James doesn't > just want "binary packages", he wants "packages fully built from source > that could end up in the main archive". > > The "source" packages at etherpad.org use prebuilt binary blobs in > traditional Java fashion (see under etherpad/lib). Packaging them in a > Debian policy compliant way is a bit more work, like JamesPage can tell > from repackaging Hudson :) So the reason why this wasn't done yet is > because it's non-trivial and time-consuming, not because of laziness. Right ;-) I'll get with James Page on that, and respond to his note separately. >> Perhaps Jorge/Daniel could get an instance running in a beefy Amazon >> EC2 instance (m2.4xlarge with 64GB of memory?) and drum up an >> Etherpad-testing-day ASAP with your requisite 100+ concurrent >> sessions. I suspect some configuration tweaks will be necessary, >> which should perhaps be folded back into the packaging itself. > > FWIW the OpenStack design summit will use Etherpad with ~400 attendees, > I'll let you know if it breaks :) Cool :-) Using the package built from binary blobs? Also, can you share with us the size (CPU, Memory) of the backing server, presumably in the Rackspace Cloud? -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Using something better than Gobby for session notes at UDS
On Thu, Apr 7, 2011 at 4:32 PM, James Troup wrote: > I appreciate the frustration people have with gobby and I'd be happy to > run something better if that's what you guys want to do - the only thing > I'd ask is that someone package Etherpad first[1]. Hi James, I started with some source packages for Etherpad 1.1 I found here: * http://apt.etherpad.org/dists/all/source/ I made a few minor modifications: 1) used openjdk instead of sun java 2) ported the most important subset of the (broken) init script to (a working) upstart configuration 3) updated debian/control and debian/rules accordingly With that, I've pushed it to ppa:etherpad/ppa: * https://launchpad.net/~etherpad/+archive/ppa/+packages This package is now apt-get installable on Natty. You have to answer a few debconf questions, setting passwords for mysql and etherpad, etc. There's certainly room for improvement there, but a few seconds later, I was able to use an Etherpad instance running on http://localhost:9000. Now I'm not necessarily volunteering to be the Etherpad maintainer for now and evermore, but perhaps some of the people here who are vocally opposed to Gobby might step up and help with the packaging? It suffers from most the usual ailments endemic to large Java packages in Debian/Ubuntu. The debconf could use a little bit of love. And obviously the change from sunjdk -> openjdk needs a bit of testing. I can do a complete review of the packaging as an Archive Admin and publish my notes, if we want to consider it for inclusion in Universe for Oneiric, but I haven't done so thus far. Perhaps Jorge/Daniel could get an instance running in a beefy Amazon EC2 instance (m2.4xlarge with 64GB of memory?) and drum up an Etherpad-testing-day ASAP with your requisite 100+ concurrent sessions. I suspect some configuration tweaks will be necessary, which should perhaps be folded back into the packaging itself. James, is this a reasonable starting point? And is there anyone out there on ubuntu-devel@ who feels strongly enough about Etherpad/Gobby to pick up this packaging/testing and take it from here? -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Should PPAs be forced to specify a ~ppa1 or similar in the package version?
On Sat, Apr 2, 2011 at 9:44 AM, Clint Byrum wrote: > Excerpts from Scott Ritchie's message of Sat Apr 02 06:56:04 -0700 2011: >> This has long been "good practice" for a variety of reasons >> >> 1) Independent PPA packages of new upstream versions can be >> automatically replaced when a proper distro update occurs. >> 2) If the PPA package itself gets promoted to the archive, it can be >> replaced by just dropping the ~ppa >> 3) It makes the version string more meaningful, as it prevents the >> possibility of an official and PPA package having the same version >> 4) If you are branching foo-0ubuntu1 and need multiple iterations you >> now have a proper number to increment without implying you've rebased >> off foo-0ubuntu2. >> >> Making such a change would have other value: >> >> 1) It makes it much easier to detect nonstandard packages on a system. >> This can be done with automated tools too without fear of false >> positives (in bug reports, with apport, with update manager, etc) >> 2) If all PPA packages were so branded, it would be much easier to >> implement a "remove all PPA packages" type of feature. > > Session or no, +1 from me. I have forgotten the ~ppaX a few times and > then been confused when the package doesn't update. I don't thin its > all that critical, but it would definitely prevent mistakes. > > If there is push back for some reason, it might make sense to have it > turned on by default but provide a checkbox to disable it. +1 to all what Clint said. I have also found myself training new Ubuntu packagers from time to time, and advising them on how to use PPAs, insisting that they use ~ppa1 or such on their packages, for all the reasons above. Occasionally they'll get advice from someone else who has a similar but slightly different scheme, perhaps the ~lucid1 model (which makes a lot of sense, too). So some standards here would be phenomenal. And if it's enforced by the archive, with a really useful/helpful source package rejection message would be awesome! -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Integrating new console colors in D-I (was Re: Call for testing: Aubergine-love for Server folks!)
On Sat, Mar 26, 2011 at 10:21 AM, Colin Watson wrote: > It would have to go on the kernel command line, not in the CD preseed > file. The latter is read too late for this. > > It would probably be better to add new values for the existing > FRONTEND_BACKGROUND environment variable (which can also go on the > kernel command line) rather than inventing a new preseeded template > which would basically just be a synonym for it. Great idea, Colin. I have this now working, with an upload of cdebconf-0.154ubuntu2 to Natty archive. This will not make Beta1, but should absolutely land in Beta2, and will need release-team approval. Note that it will also require a re-spin of debian-installer. I'm tracking this in Bug #730672. There's a debdiff for cdebconf there. As of that upload, any user of the text installer will be able to optionally specify a FRONTEND_BACKGROUND value on the kernel command line. The cdebconf-newt-udeb package provides the following: * dark -- high contrast, accessibility theme * original -- the traditional, legacy newt theme * ubuntu -- the aubergine theme (basically, s/blue/magenta/g) These are installed to: * /etc/newt/palette.dark * /etc/newt/palette.original * /etc/newt/palette.ubuntu By default, there is a symlink installed by cdebconf-newt-udeb in the ISO filesystem: * /etc/newt/palette -> /etc/newt/palette.ubuntu At debian-installer/cdebconf initialization of the newt frontend, if a kernel parameter FRONTEND_BACKGROUND= is found, then the symlink at /etc/newt/palette is broken and replaced with a symlink to /etc/newt/palette.. In this way, any derivative of Ubuntu can ship their own palette in a udeb that's included in their ISO build, install that palette at /etc/newt/palette.kubuntu, for example, and append FRONTEND_BACKGROUND=kubuntu to the kernel parameters. If you (or your Ubuntu derivative) just want the legacy behavior, then don't bother shipping your own palette, but simply append FRONTEND_BACKGROUND=original to the kernel parameters. I hope this helps with your calls for reconfigurability! I've enjoyed working with everyone on this ;-) Cheers, -- :-Dustin Dustin Kirkland Ubuntu Server, Core Developer Canonical, LTD -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Call for testing: Aubergine-love for Server folks!
On Sun, Mar 20, 2011 at 7:51 PM, Scott Kitterman wrote: > Dustin Kirkland wrote: > ... >>Cool? > > Mostly it looks to me like you breaking feature freeze and only partly > cleaning up the mess. It's great you made it configurable. Now please make > the old behavior the default so that other Ubuntu (the project) flavors > aren't forced to either accept broken (for them) branding or stop working on > other things they'd planned on to get ready for Beta 1. > > Configurability is good, but please either provide patches or make the old > behavior default. diff -Nru kubuntu-default-settings-11.04ubuntu6/debian/kubuntu-default-settings.postinst kubuntu-default-settings-11.04ubuntu7/debian/kubuntu-default-settings.postinst --- kubuntu-default-settings-11.04ubuntu6/debian/kubuntu-default-settings.postinst 2011-02-09 05:29:30.0 -0600 +++ kubuntu-default-settings-11.04ubuntu7/debian/kubuntu-default-settings.postinst 2011-03-20 22:22:39.0 -0500 @@ -5,6 +5,10 @@ case "$1" in configure) +# Kubuntu prefers legacy VGA and newt colors +update-alternatives --install /etc/vtrgb vtrgb /etc/console-setup/vtrgb.vga 60 +update-alternatives --install /etc/newt/palette newt-palette /etc/newt/palette.original 60 + # clean the driver database for kdeprint if [ -x /usr/sbin/foomatic-cleanupdrivers ]; then foomatic-cleanupdrivers -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Call for testing: Aubergine-love for Server folks!
On Fri, Mar 18, 2011 at 4:48 PM, Charlie Kravetz
wrote:
> On Fri, 18 Mar 2011 13:45:35 -0500
> Dustin Kirkland wrote:
>
>> On Fri, Mar 18, 2011 at 10:50 AM, Loïc Minier wrote:
>> > On Thu, Mar 17, 2011, Dustin Kirkland wrote:
>> >> After upgrading your local system's kbd and console-setup packages,
>> >> you should now have a crisp, new, clean color scheme in your tty.
>> >> There should be no affect whatsoever in [X, Gnome, KDE, XFCE,
>> >> gnome-terminal, konsole] or even SSH sessions to your server.
>> >
>> > Like Bryce, I'm pleased that the stress on my eyes is likely to reduce
>> > with these changes! And like Timo, I think grey vs white isn't
>> > obvious.
>>
>> Hi Loic,
>>
>> Thanks for the feedback. I'll note that to Marcus and see if we can
>> find a slightly better grey.
>>
>> > I've been poking gnome-terminal colors often to try to improve this
>> > myself; is there a plan to provide similar colors by default in
>> > xterm/gnome-terminal/others?
>>
>> That I'm not sure of. But I, too, really like the idea! I CC'd
>> Ivanka and Marcus on this response. Perhaps they can tell us if they
>> have plans, or would consider using this palette or designing another
>> for xterm/gnome-terminal... Ivanka?
>>
>> Thanks,
>
> I think it is fantastic that colors are being corrected for Ubuntu.
> Unfortunately, changes made to Ubuntu seem to affect Kubuntu and
> Xubuntu also. How do we get the colors to our own pallette?
Hi Charlie,
This should be relatively straightforward for Xubuntu and others to
configure. You could have a xubuntu-themes or some other package use
the update-alternatives simple install configurations at a higher
priority than the Ubuntu ones (which are set to priority 50, so
priority 60 should do it).
You'll need to use update-alternatives to change the targets pointed
to by two links:
1) /etc/vtrgb
2) /etc/newt/palette
See http://manpages.ubuntu.com/update-alternatives for documentation.
The first file, /etc/vtrgb, defines the 16 colors which are used by
the Linux virtual terminal consoles. The new contents of that file
are:
1,222,57,255,0,118,44,225,128,255,0,255,0,255,0,255
1,56,181,199,111,38,181,225,128,0,255,255,0,0,255,255
1,43,74,6,184,113,233,225,128,0,0,0,255,255,255,255
The first line are 16 red values, the second line are 16 green values,
and the third line are 16 blue values. If you want to change these,
have a look at http://en.wikipedia.org/wiki/ANSI_escape_code#Colors to
see the order of the colors. I'll quote you the order here, for
completeness:
* black, red, green, brown/yellow, blue, magenta, cyan, gray, dark
gray, bright red, bright green, bright yellow, bright blue, bright
magenta, bright cyan, white
The format is a little arcane. Sorry about that. But it's set to
mirror the Kernel's sysfs values:
$ cat /sys/module/vt/parameters/default_{red,grn,blu}
If you want to revert to the original vga colors, you should have some
package, such as a *-themes call this in its postinst:
update-alternatives --install /etc/vtrgb vtrgb /etc/console-setup/vtrgb.vga 60
As of a few minutes ago, the console-setup package now installs
/etc/console-setup/vtrgb.vga, for your easy reference and
configuration.
Note that "/etc/console-setup/vtrgb.vga" could instead be your own
values, perhaps set in /etc/console-setup/vtrgb.xubuntu or the like.
And note that the priority of 60 is higher than the priority of 50,
which is what the vtrgb.ubuntu is installed at.
Also, note that any individual system administrator could also run the
above command to revert back to the legacy vga colors!
Secondly, you may want to modify or revert the newt palette (which is
what ncurses based systems such as debconf use for their coloring).
This is now configured in the file /etc/newt/palette. This is a
comma-separated, no-white-space list of color values. There are
exactly 44 colors. The order and syntax are very, very important! It
needs to match the struct newtColors, in newt's newt.h header. Again,
for completeness, the order is:
struct newtColors {
char * rootFg, * rootBg;
char * borderFg, * borderBg;
char * windowFg, * windowBg;
char * shadowFg, * shadowBg;
char * titleFg, * titleBg;
char * buttonFg, * buttonBg;
char * actButtonFg, * actButtonBg;
char * checkboxFg, * checkboxBg;
char * actCheckboxFg, * actCheckboxBg;
char * entryFg, * entryBg;
char * labelFg, * labelBg;
char * listboxFg, * listboxBg;
char * actListboxFg, * actListboxBg;
char * textboxFg, * textboxBg;
char * actTextboxFg, * actTextboxBg;
char * helpLineFg, * helpLineBg;
char * rootTextFg, * rootTextBg;
char * emptyScale, * fullScale;
char
Re: Call for testing: Aubergine-love for Server folks!
On Fri, Mar 18, 2011 at 1:54 PM, Scott Kitterman wrote:
> On Thursday, March 17, 2011 10:01:51 pm Dustin Kirkland wrote:
>> Howdy Ubuntu-devel and Ubuntu-server,
>>
>> We just uploaded a couple of small patches a week ahead of
>> UserInterfaceFreeze to five packages that affect the console tty and
>> vt interface. We're hoping you can help test this on your hardware
>> and let us know if you find any adverse affects (please subscribe me
>> to the bug reports, if you do!) :-)
>>
>> The end goals were (Bug #730672):
>> 1) Improve the virtual terminal color palette
>> 2) Modernize the visual experience on Ubuntu servers
>>
>> To solve (1), we wrote a small C program that you should now find in
>> /sbin/setvtrgb. You can refer to the manpage for the full
>> documentation. It's a handy utility that reads a set of well-formed
>> RGB values from file and then uses an ioctl to dynamically apply them
>> to all consoles. This utility is currently provided in the kbd
>> package, and I'm working on getting that upstream into Debian.
>>
>> The default colors used by the Linux kernel are quite simply the
>> traditional 16 VGA colors, which you can find at:
>> * http://en.wikipedia.org/wiki/ANSI_escape_code#Colors
>>
>> While perhaps mathematically symmetric, some of those colors are a
>> pretty hard on the eyes. The Ubuntu Design Team has put quite a bit
>> of effort into selecting a distinctive color scheme for the Ubuntu
>> Desktop, and they have now carefully selected an 16 color palette for
>> server consoles too!
>>
>> So the next three pieces of (1) are solved by a series of uploads to:
>> * console-setup -- add a conffile at /etc/vtrgb (so that you can
>> customize your own console colors, if you don't like the ones Ubuntu
>> provides!), and an upstart job that applies them on boot with
>> 'setvtrgb /etc/vtrgb'
>> * rootskel -- call 'setvtrgb /etc/vtrgb' early in the Server and
>> Alternate installer for its virtual terminals
>> * bogl -- update the colors in the bterm palette used by
>> debian-installer (it happens to hard code them)
>>
>> After upgrading your local system's kbd and console-setup packages,
>> you should now have a crisp, new, clean color scheme in your tty.
>> There should be no affect whatsoever in [X, Gnome, KDE, XFCE,
>> gnome-terminal, konsole] or even SSH sessions to your server.
>> However, if you drop to a command prompt with ctrl-alt-F1, you should
>> see a nice difference. Note that if for some reason perhaps you
>> prefer the legacy VGA colors, you can revert the change simply with:
>> $ sudo setvtrgb vga
>> And if you want to make that permanent, follow with:
>> $ cat /sys/module/vt/parameters/default_{red,grn,blu} | sudo tee
>> /etc/vtrgb
>>
>> And as soon as the daily cdimage builder picks up the changes to
>> rootskel and bogl (within a day or two?), you should see the same
>> color improvements in the Natty Server and Alternate installer
>> screens.
>>
>> Now to address (2), we've made one minor change to the newt library,
>> which defines the color scheme for most curses-based utilities -- most
>> importantly, debconf and in turn, the debian-installer. If you've
>> ever installed an Ubuntu server, and in staring at the screen thought,
>> "That blue sure looks a lot like MS-DOS circa 1988," we're right there
>> with you. So we've swapped that aged "Microsoft blue" out for some
>> modern "Ubuntu aubergine"!
>>
>> So what does all of this look like? Here are some screen shots!
>> * On the console
>> * before: http://bit.ly/fvm16s
>> * after: http://bit.ly/dRF9yi
>> * And in the installer
>> * msdos6: http://bit.ly/gyQgJL
>> * before: http://bit.ly/i1cc5Q
>> * after: http://bit.ly/hRLDDI
>>
>> Spiffy, huh? Thanks to everyone who help spread some Aubergine-love
>> to Ubuntu Server folks!
>
> So now every Ubuntu flavor gets Aubergine even though that's not their color
> scheme?
Until now, Ubuntu and all Ubuntu flavors have inherited a color scheme
wasn't theirs either, actually.
> How do we over-ride this for Kubuntu (there have been complaints on #kubuntu-
> devel today)?
I filed and fixed Bug: #730672, on your behalf.
The newt library can now read its palette from a configuration file,
which is installed using update-alternatives.
+ update-alternatives --install /etc/newt/palette newt-palette
/usr/share/newt/palette.ubuntu 50
+ update-alternatives --install /etc/newt/palette newt-palette
/usr/share/newt/palette 20
Furthermore, the console-setup package now also installs its color
scheme using update-alternatives as well.
+update-alternatives --install /etc/vtrgb vtrgb
/usr/share/console-setup/vtrgb 50
Other packages can install palettes and different color schemes at
different priorities.
--
:-Dustin
Dustin Kirkland
Ubuntu Core Developer
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Call for testing: Aubergine-love for Server folks!
On Fri, Mar 18, 2011 at 10:50 AM, Loïc Minier wrote: > On Thu, Mar 17, 2011, Dustin Kirkland wrote: >> After upgrading your local system's kbd and console-setup packages, >> you should now have a crisp, new, clean color scheme in your tty. >> There should be no affect whatsoever in [X, Gnome, KDE, XFCE, >> gnome-terminal, konsole] or even SSH sessions to your server. > > Like Bryce, I'm pleased that the stress on my eyes is likely to reduce > with these changes! And like Timo, I think grey vs white isn't > obvious. Hi Loic, Thanks for the feedback. I'll note that to Marcus and see if we can find a slightly better grey. > I've been poking gnome-terminal colors often to try to improve this > myself; is there a plan to provide similar colors by default in > xterm/gnome-terminal/others? That I'm not sure of. But I, too, really like the idea! I CC'd Ivanka and Marcus on this response. Perhaps they can tell us if they have plans, or would consider using this palette or designing another for xterm/gnome-terminal... Ivanka? Thanks, -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Call for testing: Aubergine-love for Server folks!
Howdy Ubuntu-devel and Ubuntu-server,
We just uploaded a couple of small patches a week ahead of
UserInterfaceFreeze to five packages that affect the console tty and
vt interface. We're hoping you can help test this on your hardware
and let us know if you find any adverse affects (please subscribe me
to the bug reports, if you do!) :-)
The end goals were (Bug #730672):
1) Improve the virtual terminal color palette
2) Modernize the visual experience on Ubuntu servers
To solve (1), we wrote a small C program that you should now find in
/sbin/setvtrgb. You can refer to the manpage for the full
documentation. It's a handy utility that reads a set of well-formed
RGB values from file and then uses an ioctl to dynamically apply them
to all consoles. This utility is currently provided in the kbd
package, and I'm working on getting that upstream into Debian.
The default colors used by the Linux kernel are quite simply the
traditional 16 VGA colors, which you can find at:
* http://en.wikipedia.org/wiki/ANSI_escape_code#Colors
While perhaps mathematically symmetric, some of those colors are a
pretty hard on the eyes. The Ubuntu Design Team has put quite a bit
of effort into selecting a distinctive color scheme for the Ubuntu
Desktop, and they have now carefully selected an 16 color palette for
server consoles too!
So the next three pieces of (1) are solved by a series of uploads to:
* console-setup -- add a conffile at /etc/vtrgb (so that you can
customize your own console colors, if you don't like the ones Ubuntu
provides!), and an upstart job that applies them on boot with
'setvtrgb /etc/vtrgb'
* rootskel -- call 'setvtrgb /etc/vtrgb' early in the Server and
Alternate installer for its virtual terminals
* bogl -- update the colors in the bterm palette used by
debian-installer (it happens to hard code them)
After upgrading your local system's kbd and console-setup packages,
you should now have a crisp, new, clean color scheme in your tty.
There should be no affect whatsoever in [X, Gnome, KDE, XFCE,
gnome-terminal, konsole] or even SSH sessions to your server.
However, if you drop to a command prompt with ctrl-alt-F1, you should
see a nice difference. Note that if for some reason perhaps you
prefer the legacy VGA colors, you can revert the change simply with:
$ sudo setvtrgb vga
And if you want to make that permanent, follow with:
$ cat /sys/module/vt/parameters/default_{red,grn,blu} | sudo tee /etc/vtrgb
And as soon as the daily cdimage builder picks up the changes to
rootskel and bogl (within a day or two?), you should see the same
color improvements in the Natty Server and Alternate installer
screens.
Now to address (2), we've made one minor change to the newt library,
which defines the color scheme for most curses-based utilities -- most
importantly, debconf and in turn, the debian-installer. If you've
ever installed an Ubuntu server, and in staring at the screen thought,
"That blue sure looks a lot like MS-DOS circa 1988," we're right there
with you. So we've swapped that aged "Microsoft blue" out for some
modern "Ubuntu aubergine"!
So what does all of this look like? Here are some screen shots!
* On the console
* before: http://bit.ly/fvm16s
* after: http://bit.ly/dRF9yi
* And in the installer
* msdos6: http://bit.ly/gyQgJL
* before: http://bit.ly/i1cc5Q
* after: http://bit.ly/hRLDDI
Spiffy, huh? Thanks to everyone who help spread some Aubergine-love
to Ubuntu Server folks!
Enjoy,
--
:-Dustin
Dustin Kirkland
Ubuntu Core Developer
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Patch Pilot Report 2011-03-14
On Mon, Mar 14, 2011 at 3:35 PM, Micah Gersten wrote: > On 03/14/2011 12:37 PM, Dustin Kirkland wrote: >> >> * 734331 >> - fix little packaging/build bug > > This upload was lacking a proper E-Mail address in the changelog. I > don't see a requirement for this to be valid in Debian/Ubuntu policy > 4.4, but I wanted to ask anyways. Is this a requirement? Agreed. My mistake. I wonder if there was lintian error thrown and I just missed it... -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Patch Pilot Report 2011-03-14
* lp:~jamesodhunt/ubuntu/natty/vim/add-upstart-syntax - merged upstart vim syntax improvements, James has already sent upstream - tried to upload, and I see that it's already in the archive, udd branch out of sync - cjwatson offered to handle this one * 415586 - found that this patch was already applied upstream and is in Natty's xchat-gnome - marked bug fix-released, no action necessary * 734736 - grabbed code, tried to apply, and I see that it was uploaded 30 minutes ago - my copy of http://reports.qa.ubuntu.com/reports/sponsoring/ was out of date * 734331 - fix little packaging/build bug * 726182 - fix dkms build issue - reworked the diff to be a patch in debian/patches - uploaded * 357847 - talked to pitti, he'd rather review this one himself, as it's a new feature to apport and he's not quite happy with the implementation yet * 630383 - prepped SRU, and uploaded * 707479 - held off on uploading this one; seems that jhunt is nearly done with a big merge for natty; wait for that to complete * 722739 - prepared a debdiff, attached to the bug - declined to upload, though, as this seems to me to require an FFE * 733169 - examined, but it looks like the package maintainer is on top of this one I need to focus on other things now, but I'll be in IRC if anyone needs something specific sponsored through the rest of the day. Cheers! -- :-Dustin Dustin Kirkland Ubuntu Server, Core Developer Canonical, LTD -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Patch Pilot Report
On Fri, Feb 11, 2011 at 3:40 PM, Barry Warsaw wrote: > On Feb 11, 2011, at 03:33 PM, Dustin Kirkland wrote: > >>Note: I had to work my patch pilot day today from the customer lounge >>at the VW dealership (getting some service done on wife's car). >>Bazaar branches/checkouts require a LOT of bandwidth; something that I >>don't notice so much working from home where I have sufficient >>bandwidth, but on a low bandwidth connection, UDD is a PITA. apt-get >>source is much nicer. Just saying... > > Improving this is one of the big 2011 goals for the Bazaar team. \o/ Thanks. As Bryce pointed out to me privately, the other option is to ssh to a virtual machine somewhere with a bigger pipe and work from there. That's certainly a viable option for me, and will probably do that next time. -- :-Dustin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Patch Pilot Report
Bug #708080 -- facter does not recognize KVM VMs as 'virtual' * sponsored SRU to Lucid and Maverick Bug #697197 -- Empty password allows access to VNC in libvirt * ported debdiff to maverick-security * ported debdiff to lucid-security * uploaded to natty * asked submitted to post his diff to the qemu-devel mailing list for upstream acceptance * invalidated other tasks Bug #531912 -- /etc/init.d/ssh seems to work, but actually upstart is used * examined patch, looked good to me * pinged cjwatson in irc, he said he'd rather review it and merge/upload Bug #693341 -- FTBFS armel due to memory exhaustion * looked good, uploaded Bug #713237 -- shutdown segv due to race w/ free_waiter threads * looked good, uploaded Next, I spent the rest of my day preparing/building/testing/committing/uploading qemu-kvm (0.13.0+noroms-0ubuntu15) natty. My previous two uploads of qemu-kvm to Natty failed because qemu-linaro is now building some binary packages that qemu-kvm previously built. qemu-kvm had not yet been updated to prune those parts of the build out. It took quite a while to work over the build back to a functional state. Note: I had to work my patch pilot day today from the customer lounge at the VW dealership (getting some service done on wife's car). Bazaar branches/checkouts require a LOT of bandwidth; something that I don't notice so much working from home where I have sufficient bandwidth, but on a low bandwidth connection, UDD is a PITA. apt-get source is much nicer. Just saying... -- :-Dustin Dustin Kirkland Ubuntu Server, Core Developer Canonical, LTD -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: PostgreSQL 8.4 or 9.0 for Natty?
On Thu, Feb 10, 2011 at 7:20 AM, Martin Pitt wrote: > So I was wondering which version we should ship in Natty? 8.4, with > the usual set of packaged extensions, or 9.0 to provide the latest and > greatest, but with by and large no packaged extensions at all? > > My gut feeling and plan so far was the former (8.4), and to provide > 9.0 in my PPA for those who need it. Now that Debian has thawed, I > think we'll see extensions packaged for 9.0 soon, so that in 11.10 we > can finally switch over. Hey Martin, If the extensions aren't packaged, I think we risk regressing many users' Postgres functionality, and these users probably won't upgrade to 11.04 (or will upgrade, and be very disappointed with the experience). Your suggestion (stick with 8.4, and put 9.0 in a PPA) sounds reasonable to me. Dustin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: swf files in Ubuntu
On Tue, Jan 4, 2011 at 3:01 AM, Martin Pitt wrote: > Hello Charlie, > > Charlie Smotherman [2011-01-04 2:26 -0600]: >> I am curious as to whats Ubuntu's policy on having *.swf files in the >> archive? > > We (as in the archive admins) mostly stick to the Debian position and > DFSG, with some exceptions like we consider GFDL as "free". > > From a legal POV it's primarily a license question. Many "strict free" > licenses like the GPL mandate that you distribute the "preferred form > of modification" (aka. "source") for all files, which *.swf is not. > For the same reason we reject GPL packages which ship PDFs without a > source (like ODF or LaTeX). > > So if a package wants to ship an swf, it needs a "weaker" license like > BSD or MIT. If it's GPL, it's not distributable at all. > > However, I expect that we still would put a package with just an swf > into multiverse, as it still violates the "source available" clause of > the DFSG. I agree with everything Martin says above. For what it's worth, I packaged jPlayer recently for Natty, which uses mtasc to compile an swf file from source. If you're looking for a simple packaging example of how to build swf in a debian package, 'apt-get source jplayer'. Dustin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Ubuntu Server Meeting Minutes from 2010-12-07
The minutes from last week's meeting have been published at * http://ubuntuserver.wordpress.com/2010/12/14/ubuntu-server-meeting-minutes-from-2010-12-07/ Minutes Review ACTION points from previous meeting * ALL: please check the SRU tracker http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html for 'needs-verification' bugs * robbiew to review ServerTeam wiki * got status page up, but still reviewing * SpamapS to email a concrete proposal for addressing SRU verification backlog * done * Kernel team to follow up on bug 661294 * still in progress * SpamapS to setup trend line for server team natty work items * done * JamesPage to arrange URL for Hudson CI Server * still in progress * Natty Development * Alpha1 released * robbiew doesn't have much here for this week * Weekly Updates & Questions for the QA Team (hggdh) * 684304 is blocking UEC testing * Weekly Updates & Questions for the Kernel Team (smb) * working on a hard-to-reproduce nfs bug * Weekly Updates & Questions for the Documentation Team (sommer) * not much to say, more next week * Weekly Updates & Questions for the Ubuntu Community Team (kim0) * kim0 not around * http://cloud.ubuntu.com/ launched * Open Discussion * RoAkSoAx working on MIRs for the cluster stack in Natty * zul to request feedback on the install-service blueprint to the mailing list * Announce next meeting date and time Meeting Actions * ACTION: robbiew to review ServerTeam wiki * ACTION: Kernel team to follow up on 661294 * ACTION: JamesPage to arrange URL for Hudson CI Server * ACTION: spamaps to talk to his friend to try and get more info on Bug #684304 * ACTION: zul to request feedback on the install-service blueprint to the mailing list Detailed log at: * https://wiki.ubuntu.com/MeetingLogs/Server/20101207 -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Patch Pilot report 2010-12-08
I was on Patch Pilot duty today, and found it to be a nice way to spend most of the day. I applaud those responsible for organizing this effort and allocating time for us to work on it. Here are my results: LP: #497886 - merge needed a little cleanup, had to repack the orig tarball, fixed a minor/easy lintian warning about copyright encoding, uploaded to natty LP: #576949 - sponsored/uploaded to lucid-proposed for SRU, straightforward, easy enough LP: #627272, #575019, #534629, #572271, #574443, #575152, #625105, #591893, #621980 - needs fixing; two SRU merge proposals (lucid & maverick) for likewise, huge patches (958 & 1427 lines), fix 9 bugs, none of the bugs have SRU statements, will review again once those SRU statements are in place for each bug, advised that in the future, SRUs can go a little smoother LP: #677998 - fix looks good, ubuntu-dev doesn't have commit rights on the target branch, couldn't get the orig.tar.gz created, unsubscribing ubuntu-sponsors for now, contacted ubuntu-doc, noted this in my review LP: #682153 - patch was simple/clean/good, built and tested, works and looks better here, sponsored and pushed - however, seb128 raised an issue with my sponsoring this bug in IRC, noting that I should have talked to the DX team first; my bad (I thought it was pretty straightforward); perhaps we need some notes in the PatchPilot wiki page on what to do about design issues? LP: #685860 - this one is hard/messy, proposed branch has conflicts, not ready for sponsoring, marked incomplete, unsubscribed ubuntu-sponsors, subscribed myself, will take another look if someone can clean up the conflicts - author pinged me in IRC saying that there shouldn't be conflicts with his debdiff; I ran out of time today before having a chance to take a second look, sorry. Dustin Kirkland -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: SSH and the Ubuntu Server
On Fri, Nov 19, 2010 at 4:50 PM, Dustin Kirkland wrote: > I'm going to redraft the proposal, note that there was no general > consensus on the matter in the ubuntu-devel@ mailing list, and ask the > Tech Board for guidance. Thanks everyone for the lively discussion. Thank you for the discussions at UDS, in IRC, and in this thread. Colin's changes to the server tasksel (moving SSH to the top of the list, albeit "unchecked") is a reasonable step towards improving the usability of the server installer. Let's just roll with this for now and evaluate its effectiveness next cycle. Thanks again! :-) :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: SSH and the Ubuntu Server
Stephan Hermann wrote: > Hi Scott, > > On Fri, 2010-11-19 at 13:18 -0500, Scott Kitterman wrote: >> On Friday, November 19, 2010 12:02:33 pm Dustin Kirkland wrote: >> > Confirmed this on RHEL6 yesterday. I installed RHEL6 in multiple >> > different modes (minimal, default, developer workstation), all of >> > which a) were running sshd, b) had a root user with a password. >> >> Yes, but RHEL6 doesn't dhcp by default and Ubuntu Server does so the attack >> surface for a default RHEL6 install is rather more limited. > > To be honest, there is no difference in installing RHEL6 with a static > ip address or Ubuntu Server with DHCP enabled. > > I think we need to find out first, what user base we want to point at. > > The SysAdmin of a Company with Enterprise Classed Datacenter > or the guy/gal from around the corner who is testing ubuntu server? > > The SysAdmin will have network security in place (if not..oh well), and > mostly is he/she not using public IP addresses, and/or they setup their > DHCPd to match the MACs of the NICs inside their servers. > > I am now wondering if we really should change something. As long as I'm > thinking about the topic, I'm coming to my conclusion, that we just > should tick sshd by default during tasksel in the installer, and that's > it. For most of the admins out there, it really doesn't matter, because > they have other ways to deploy ubuntu server on their servers. I agree, Stephan. The installer complexity can be avoided by just ticking the "OpenSSH Server" in the top of the tasksel page as you suggest; document that change thoroughly and publish it far and wide; note the stronger sshd.conf configurations from Marc and the security team in the SSH help page. Unfortunately, I don't think we're reaching a consensus here on ubuntu-de...@. I'm going to redraft the proposal, note that there was no general consensus on the matter in the ubuntu-devel@ mailing list, and ask the Tech Board for guidance. Thanks everyone for the lively discussion. :-Dustin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: SSH and the Ubuntu Server
Stephan Hermann wrote: > Moins, > > On Thu, 2010-11-18 at 12:24 -0500, Luke Faraone wrote: >> On 11/18/2010 12:04 PM, Dustin Kirkland wrote: >> > On Thu, Nov 18, 2010 at 9:30 AM, Colin Watson wrote: >> >> No, it's not. In Maverick it was arguably buried. In Natty, it is the >> >> very top entry on the tasksel menu, and the cursor rests on it when you >> >> reach that screen. >> > [snip] >> > >> > I would gladly revise this proposal to simply: >> > * Automatically 'tick' OpenSSH Server by default on the Server Tasksel >> > screen >> > >> > Which would also sit there and wait for the user to consciously affirm >> > their selection, and would avoid the countless server installations >> > where people forget to install SSH and must make their way back to a >> > console on their newly installed system and add the openssh-server >> > package. >> >> As many people have mentioned, this will cause a surprise for users who >> click through the install dialogs expecting things to not change since >> they last used it. > > Sorry, but this is something which strucks me, really. When we don't > change things over time, we will never have a better user experience. > When we change something it needs to be documented in a public place > where everyone interested can read it first hand. +1 >> Also, since this occurs late in the install process, no dialogs to >> prompt the user to harden their password can be offered, as others have >> suggested. > > Oh well, we can change that inside the installer as well. Not prompting > for a user choice, but choosing a hardened password automatically and > showing it to the user > mkpasswd --chars=20 --crypt-md5 or whatever should be enough. that's > only a technical problem easily to solve. > > >> You say there are "countless" installations. I don't think anybody >> expects SSH to be automatically installed in a new server; it's a >> service that should be enabled carefully after consideration of your >> network environment and security needs. I feel that the potential for >> harm of accidental installation exceeds the increase in convenience from >> not having to explicitly select the task. > > I think we have more installations of RHEL or SLES in the enterprise > server market, and they do have sshd enabled by default. > Even when you install an VMWare ESX host, ssh is enabled by default, > without the questionable root access. Confirmed this on RHEL6 yesterday. I installed RHEL6 in multiple different modes (minimal, default, developer workstation), all of which a) were running sshd, b) had a root user with a password. Simply the fact that Ubuntu does not have an active root password by default means that network attacks via ssh must guess BOTH the username AND the password. Choose both wisely and you should be able to repel attacks between the time that your new Ubuntu Server reboots for the first time and the time it takes for you to login for the first time and configure sshd.conf to your liking. If you're actively working the installation, we're talking less than 5 minutes. If you've automated the deployment via puppet or somesuch, it can be far less than that. :-Dustin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Unity desktop and maverick backport
On Thu, Nov 18, 2010 at 9:20 PM, Jono Bacon wrote: > On Thu, 2010-11-18 at 17:58 -0600, Dustin Kirkland wrote: >> What about trying to use TestDrive for more widespread yet safe >> Unity-on-Natty testing? >> >> Andres Rodriguez put an awesome GTK front end on TestDrive for his >> GSoC project in the Maverick cycle. Now, you can configure it and >> sync and launch VMs from a GUI. You can optionally rsync/zsync the >> latest daily ISO and then launch it in either KVM or VirtualBox, all >> confined within a safe virtual machine environment. > > I think if the VM supports 3D acceleration, this would be cool. Would > you be happy to try it and see if it works? Will gladly try it, but I don't think we're going to get 3D acceleration in the VM. I was thinking of this as an approach for the 2D testing and the overall integration (minus 3D effects). Dustin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Unity desktop and maverick backport
Jono Bacon wrote: > On Thu, 2010-11-18 at 18:53 +, Shane Fagan wrote: >> Well there always is VMs and separate ubuntu installs for testing >> without breakages affecting your desktop usage. > > Not really for Unity; 3D often doesn't work so well in virtual > environments. I thought a good 2D experience was also one of the key objectives? :-Dustin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Unity desktop and maverick backport
Rick Spencer wrote: > In my opinion, for what it is worth, this sounds like an unfortunate, > but necessary trade off. > > I think we will lose a fairly large degree of testing and feedback, by > forcing interested contributors to move Natty so early. However, I think > it's rational to trade that for an increased focus on the ultimate > quality of the new compiz-based unity in Natty and beyond. > > I think we'll get the most useful feedback from people *using* Unity. > So, this means that we'll need to focus on supporting early Natty > adopters, for instance paying more attention to quickly resolving > adoption blocking bugs. What about trying to use TestDrive for more widespread yet safe Unity-on-Natty testing? Andres Rodriguez put an awesome GTK front end on TestDrive for his GSoC project in the Maverick cycle. Now, you can configure it and sync and launch VMs from a GUI. You can optionally rsync/zsync the latest daily ISO and then launch it in either KVM or VirtualBox, all confined within a safe virtual machine environment. Beyond that, Scott Moser and I are working on a blueprint related to Desktop-in-the-Cloud. This could be yet another way of "safely" testing and identifying blocking bugs. :-Dustin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Run From Pocket Drive Installer Option?
-- :-Dustin 8, 2010 at 5:01 PM, Jono Bacon wrote: > Hi All, > > Apologies if this is not the right place to ask, but one of the most > interesting and valuable features in Ubuntu for me, is the ability to > run an installation entirely from a USB disk. This is also particularly > attractive for encouraging our community to test developer releases and > help us bug reporting, triage, and fixing. > > Today the installer has two options: > > * Try Ubuntu > * Install Ubuntu > > I am wondering if we should provide a third option for those who have > booted from a USB disk with persistance switched on: "Run Ubuntu From > Your Pocket Driver" (or some better wording), which will allow you to > use the USB stick as the main disk. > > I think this could be a really valuable feature for (a) people trying > Ubuntu in more real-world situations where they set up their email, chat > accounts etc and run it from the USB stick, and (b) help us with > testing. We could probably just detect if you have a persistence file on the media, and if there's anything of value in it, and if so, then change the verbiage from "Try Ubuntu" to "Launch Your Live Ubuntu" or something more appropriate. :-Dustin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: SSH and the Ubuntu Server
Stefan Potyra wrote: > Hi, > > Am Thursday 18 November 2010 19:34:58 schrieb Robbie Williamson: >> On Thu, 2010-11-18 at 16:22 +, Colin Watson wrote: >> > On Thu, Nov 18, 2010 at 10:08:47AM -0600, Robbie Williamson wrote: >> > > On Thu, 2010-11-18 at 16:04 +, Colin Watson wrote: >> > > > On Thu, Nov 18, 2010 at 10:49:38AM -0500, Marc Deslauriers wrote: >> > > > > I think this screen is a good idea if in fact tasksel is moved to >> > > > > after the first boot. >> > > > >> > > > We used to have a two-stage installer and it was a nightmare to >> > > > maintain for several reasons. Since we moved to a single-stage >> > > > installer several years back, we've burned all the necessary code >> > > > with fire and enjoyed it. Please don't make me go back to that. >> > > >> > > What if the Server team maintained the 2nd stage? Then we'd be making >> > > life easier for you, right? ;) >> > >> > Er. :-) >> > >> > (In seriousness, any good-quality second stage would require some level >> > of cooperation from the first stage. We tried that and it was awful.) >> >> So I see the 1st stage as just installing the minimal server, then we >> boot to a login prompt...user logs in and can either do his/her business >> as desired or launch the 2nd stage (which they are told about in a 1st >> boot motd-type message). > > Would > command-to-start-second-stage-installer > amount to a better usability compared to > apt-get install openssh-server > with the original question in mind? If you didn't get SSH installed the first time around, you're going to have to mosey back down the datacenter to 'apt-get install openssh-server' before you can do anything remotely with your server. The aforementioned "command-to-start-second-stage-installer" could be displayed in the MOTD, like our cloud images. Something like "To finish customizing this server, you can run 'sudo tasksel' now" or whatever. But that assumes you can *get* to your server. I'm arguing that SSH is generally needed to access your server and get to the point where you can login and do useful things with it after installation (like a running second stage installer). :-Dustin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: SSH and the Ubuntu Server
On Thu, Nov 18, 2010 at 9:30 AM, Colin Watson wrote: > (Please, in future, do not cross-post between the moderated ubuntu-devel > and the unmoderated ubuntu-devel-discuss. Doing so produces time lags > which confuse people.) Dang. Sorry, Colin. Live and learn. > On Wed, Nov 17, 2010 at 03:38:53PM -0600, Dustin Kirkland wrote: >> I am asking for ubuntu-devel's consensus, and an eventual Ubuntu >> Technical Board approval of a new prompt in the Ubuntu Server ISO's >> text-based installer, which would read something like the following: >> >> -- >> | If you need a secure connection to this >> | server remotely, you may wish to install >> | the openssh-server package. Note that >> | this service will open TCP port 22 on >> | your system, and you should use a very >> | strong password. >> | >> | Do you want to install the SSH service? >> | >> | [[YES]] [no] >> -- >> >> Rest assured that the exact text will be word-smithed by an >> appropriate committee to hash out an optimum verbiage. > > Without wishing to express any opinion either way: this is an > excessively painful choice of implementation. If you want to default it > to yes, it would be sufficient, and much easier (take it from me, I'm > the one who gets to deal with the translation merge workload when you > guys add questions ...) to check the "SSH server" entry in tasksel by > default. > >> These key points map to the following considerations: >> 1) the current option to install SSH on Ubuntu servers is buried in >> the tasksel menu > > No, it's not. In Maverick it was arguably buried. In Natty, it is the > very top entry on the tasksel menu, and the cursor rests on it when you > reach that screen. Right, that's a great change. Makes it more obvious. I can concede your point that adding the proposed page to the installer would create work for you, which of course, is not my goal. I would gladly revise this proposal to simply: * Automatically 'tick' OpenSSH Server by default on the Server Tasksel screen Which would also sit there and wait for the user to consciously affirm their selection, and would avoid the countless server installations where people forget to install SSH and must make their way back to a console on their newly installed system and add the openssh-server package. :-Dustin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: SSH and the Ubuntu Server
On Thu, Nov 18, 2010 at 10:00 AM, Serge Hallyn wrote: > Quoting Clint Byrum (cl...@ubuntu.com): >> On Wed, 2010-11-17 at 15:38 -0600, Dustin Kirkland wrote: >> >> > >> > This proposal requests that: >> > 1) a new prompt be added to the Ubuntu Server installer >> > 2) this prompt be dedicated to the boolean installation, or >> > non-installation, of the SSH service, as an essential facet of a >> > typical server >> >> +1 for adding this prompt >> >> > 3) the cursor highlights the affirmative (yes, please install SSH), >> > but awaits the user's conscious decision >> > >> >> -1 for having it default to Yes. > > Forgive me if the answer is obvious - but how is this any > better then than simply expecting users to click 'ssh server' > in the tasksel window which always comes up? It's not any better, Serge. :-( :-Dustin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: SSH and the Ubuntu Server
I inadvertently left ubuntu-server@ off of the original distribution. Sorry about that. CC'ing now. There are a few responses already in the thread: * https://lists.ubuntu.com/archives/ubuntu-devel/2010-November/thread.html Thanks, Dustin On Wed, Nov 17, 2010 at 3:38 PM, Dustin Kirkland wrote: > Ubuntu has long maintained a "no open ports by default" policy. This > conservative approach arguably yields a more secure default > installation. Several exceptions have been granted to this policy, > which install services on the target system without the user's > explicit consent, but in the calculated interest and support of a > vastly more usable Ubuntu. > > Let me be clear: I am NOT requesting that sort of an exception. > > I am asking for ubuntu-devel's consensus, and an eventual Ubuntu > Technical Board approval of a new prompt in the Ubuntu Server ISO's > text-based installer, which would read something like the following: > > -- > | If you need a secure connection to this > | server remotely, you may wish to install > | the openssh-server package. Note that > | this service will open TCP port 22 on > | your system, and you should use a very > | strong password. > | > | Do you want to install the SSH service? > | > | [[YES]] [no] > -- > > Rest assured that the exact text will be word-smithed by an > appropriate committee to hash out an optimum verbiage. > > This proposal requests that: > 1) a new prompt be added to the Ubuntu Server installer > 2) this prompt be dedicated to the boolean installation, or > non-installation, of the SSH service, as an essential facet of a > typical server > 3) the cursor highlights the affirmative (yes, please install SSH), > but awaits the user's conscious decision > > These key points map to the following considerations: > 1) the current option to install SSH on Ubuntu servers is buried in > the tasksel menu > - SSH is more fundamental to a server than the higher level > profile selections for: > DNS Server, Mail Server, LAMP Stack, Virtualization Host, etc. > 2) users of the installation ISO will have the option to not install > SSH, as they so desire > - it is quite well understood that some users may not want SSH > installed on their server > 3) highlighting the "YES" option on this page is absolutely essential > to addressing this usability issue > - and that selection is easily overridden by hitting , > or by experienced admins in preseed configurations > > Please consider that the very definition of a "server" implies that > the system is running a "service". Moreover, our official Ubuntu > Server images as published for the Amazon EC2 cloud are, in fact, > running SSH by default listening on port 22 on the unrestricted > Internet (the 'ubuntu' has no password), and the Ubuntu Enterprise > Cloud installation by the very same ISO installs SSH on every every > UEC system deployed. This is not unprecedented. > > Having discussed the proposal with a subset of this audience (at UDS > and in IRC), here are some known FAQs: > > Q: WTF?!? Ubuntu has no open ports by default! > A: That depends on which "Ubuntu" you mean. Ubuntu-in-the-cloud runs > SSH. Ubuntu-as-the-cloud runs SSH. Ubuntu desktops run avahi. Most > importantly, this is not a "run by default" proposal. We have already > compromised on that subject, culminating in this proposal, which is > simply about providing Server users with an obvious way to install the > typically essential SSH service. > > Q: Why not default the cursor on that question to "No", instead of "Yes"? > A: That totally bypasses the value of this proposal, and is only > microscopically better than what we currently have, where Ubuntu > Server users must go out of their way to add one of the most > fundamental packages to almost any server installation. The proposal, > as it stands, is already a compromise from the original suggestion at > UDS; which was, "if you're installing a server, you're expecting to > run a service, so let's just install SSH by default". That idea is > entirely out of scope now. We are proposing this installer question > as a reasonable compromise. > > Q: What if the openssh-server package is compromised on the ISO? > A: Although this has happened before, it is relatively rare over the > history of Ubuntu. If/when this happens again, we would need to: > a) recommend that people choose "no" when prompted, and install > SSH post-in
SSH and the Ubuntu Server
what's shipped by default in Ubuntu, before running sshd? A: You sound like an advanced user; please preseed your installation, or add SSH after the initial install (as you would do now). Q: Do we have to add another question to the Server installer to accomplish this? A: Actually, we don't. We could possibly simplify or remove a couple of other questions. That discussion belongs in another thread, though. Sincerely, Dustin Kirkland Ubuntu Core Developer | Server Team | Guarded Gorilla http://bit.ly/5-gorillas -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: brainstorming for UDS-N - Package Selection and Defaults
On Tue, Oct 26, 2010 at 11:24 AM, Matt Zimmerman wrote: > On Tue, Sep 28, 2010 at 04:35:40PM -0500, C de-Avillez wrote: >> On Tue, 28 Sep 2010 21:47:04 +0200 >> Allison Randal wrote: >> >> > The Package Selection and Defaults track is about choosing the >> > best-of-breed packages (applications, libraries, etc), a common task >> > across all editions of Ubuntu. It includes considering the viability >> > of up-and-coming new software, the decline of end-of-life packages, >> > the risks and gains of upgrades and migrations. >> > >> > What's high on your list for this area? >> > Allison >> > >> >> I would like to see byobu as a default install for servers [1] >> >> Cheers, >> >> [1] https://bugs.edge.launchpad.net/ubuntu/+source/byobu/+bug/586546 > > There is an existing blueprint for that, which explains the conditions which > would need to be met in order to make this feasible. > > I don't have a link handy, but let's not repeat the same discussion a third > time this cycle. ;-) I think Matt is referring to: * https://blueprints.edge.launchpad.net/ubuntu/+spec/server-lucid-byobu * https://blueprints.edge.launchpad.net/ubuntu/+spec/server-maverick-byobu-and-you Since you're interested in seeing Bug #586546 fixed, Carlos, you may want to attend this UDS session: * https://blueprints.edge.launchpad.net/ubuntu/+spec/packageselection-server-n-install-flavors :-Dustin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Ubuntu Server Team Meeting Minutes from 2010-10-05
For more details, see: * https://wiki.ubuntu.com/MeetingLogs/Server/20101005 == Minutes == Meeting Actions * ACTION: mathiaz to send out a call for ideas on ubuntu to the puppet community * ACTION: smoser to get skaet info on how to publish EC2 images * ACTION: Everyone to celebrate the 10.10.10 release in their own unique ways Review ACTION points from previous meeting * jiboumans to send an email to ubuntu-server@ and/or blog post for call for ideas * DONE (during the course of the meeting) * mathiaz to send out a call for ideas on ubuntu to the puppet community * ACTION (held over to next week) Maverick development (jib) * jib: winding down, ttx in London for release sprint release status, the road to 10.10.10 release (ttx) * ttx: nothing critical, a few FTBFS, nothing queued against the release, ISO testing to begin soon * ACTION: smoser to get skaet info on how to publish EC2 images Natty preparation (jib) * jib: [[ServerTeam/NattyIdeaPool]] is open, spend some time next week brainstorming Weekly Updates & Questions for the QA Team (hggdh) * hggdh: we will be dropping regression-potential Weekly Updates & Questions for the Kernel Team (jjohansen) * jjohansen: ill, not at meeting Weekly Updates & Questions for the Documentation Team (sommer) * sommer: not around Weekly Updates & Questions for the Ubuntu Community Team (kim0) * kim0: not around Open Discussion * SRU 649591 (mountall spins eating cpu when 'nobootwait' option exists in fstab followed by a comma) * kirkland sponsored smoser's proposal * ACTION: Everyone to celebrate the 10.10.10 release in their own unique ways Announce next meeting date and time * Tuesday 2010-10-12 at 1800 UTC - #ubuntu-meeting -- :-Dustin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
