Ubuntu Server 11.10 Features Defined
Hello all, With FeatureDefinitionFreeze[1] now behind us, I'd like to formally present the prioritized feature list for Ubuntu Server 11.10: http://blueprints.launchpad.net/~ubuntu-server/+specs?role=assignee Please have patience with us, as we are still working out milestone delivery targets and work items assignments, but you can get a good idea of what Oneiric Server will be from this list. Please post all questions/comments about this plan to the ubuntu-server mailing list. If you scroll down to the bottom, you'll notice 5 blueprints with "Undefined" priorities and starting with "topic-". These blueprints correspond with 5 key topics we want to focus on this cycle (in no particular order): * The Ubuntu Orchestra project * The Ubuntu Ensemble project * Ubuntu Server for ARM * Making Ubuntu Server the Best Cloud Infrastructure OS * Making Ubuntu Server the Best Cloud Guest OS Each feature will fall into one or more of these categories, and is marked as such in the "Dependencies" section. The plan is that in the upcoming days, we'll soon have a fast, easy, and useful way to track our progress in these topics, as well as at the individual feature/work item level. Trust me, I've seen the prototype...it's **very** nice. ;) So buckle up folks...it's going to be a roller coaster of a ride this cycle, but I'm confident Ubuntu Server 11.10 will be our best release yet! -Robbie [1] https://wiki.ubuntu.com/FeatureDefinitionFreeze -- Robbie Williamson Ubuntu Server Engineering Manager, Canonical robbiew[irc.freenode.net] "You can't be lucky all the time, but you can be smart everyday" -Mos Def "Arrogance is thinking you are better than everyone else, while Confidence is knowing no one else is better than you." -Me ;) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Server Team 20110524 meeting minutes
== Agenda == * Review ACTION points from previous meeting * Oneiric Development * Ubuntu Server Team Events * Weekly Updates & Questions for the QA Team (hggdh) * Weekly Updates & Questions for the Kernel Team (smb) * Weekly Updates & Questions from the Ubuntu Community * Open Discussion == Minutes == Meeting Actions * All: spec peer reviews Oneiric Development * Review blueprints! - Thursday is feature definition freeze - We need peer reviews - See: * https://blueprints.launchpad.net/sprints/uds-o?searchtext=server-o * http://blueprints.launchpad.net/~ubuntu-server/+specs?role=assignee - Question the implementation and direction. - Give feedback in whiteboard. - Daviey will send a post to ubuntu-server ml today with further details. Weekly Updates & Questions for the Kernel Team (smb) smb reminded the team about his email asking about iscsitarget. Weekly Updates & Questions from the Ubuntu Community cp1 asked what we might do to better keep up with security updates. He feels we were slow with the last exim update, particularly compared to debian. jdstrand, kees, and dholbach came back with suggestions: * kees pointed us to http://people.canonical.com/~ubuntu-security/cve/main.html * jdstrand informed us that as part of the security-o-community blueprint, 10-15 packages per month will be put up for community contributions. * dholbach pointed out that if you are aware of an embargoed issue and have a patch, you can file a private security bug. Agree on next meeting date and time Next meeting will be on Tuesday, May 31st at 16:00 UTC in #ubuntu-meeting. -- 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 Fri, May 27, 2011 at 7:44 AM, Kees Cook wrote:
> The problem is that dmesg is just a log. The contents can't be adjusted
> based on who is viewing it like (like has been done for the %pK sprintf
> uses in /proc, /sys, etc). Things like Oops reports will go to dmesg, which
> are utterly useless without all their addresses intact, etc.
One could also provide an suid utility that stripped out everything
that looks like an address.
For fun, I attach such a utility, though I am not convinced this is
the best approach. It
1) opens /var/log/dmesg
2) drops root privileges
3) filters out everything starting with '0x'
It strips out lots of things that aren't addresses, but It looks like
what it leaves could still be useful for many purposes. It may well
still leave some sensitive information unprotected, so I wouldn't use
it when it is not needed, particularly as it may cause confusion if
users mistake it for the real dmesg.
--
John C. McCabe-Dansted
#include
#include
int main ( int argc, char** argv )
{
int last_char = 0;
int this_char;
int in_address = 0;
FILE *f = fopen ( "/var/log/dmesg", "r" );
if (setuid(getuid())) { /* drop root privileges */
puts("Cannot drop root privileges\n");
return 1;
}
while ( (this_char = fgetc(f)) != EOF) {
if (this_char < 33 || this_char == ']' || this_char == '-') {
// A space, newline or special char
in_address = 0;
}
if (in_address) {
putchar('?');
} else {
putchar((char)this_char);
}
if (last_char=='0' && this_char=='x') {
in_address=1;
}
last_char = this_char;
}
return (0);
}
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Using -v when merging from Debian
On May 27, 2011, at 12:01 PM, Micah Gersten wrote: >This is a friendly reminder that when merging a package from Debian, >to use -v when building the source package. You pass it the last >version that was in Ubuntu and it'll include everything after that in >the _source.changes file. This allows all the recorded changes to >show up on the -changes mailing list and any LP bugs closed in Debian >to be auto-closed. Also, as I just learned, if you're using UDD, when you build the source package use the --package-merge option, e.g.: $ bzr bd -S --package-merge From the help: --package-merge Build using the appropriate -v and -sa options for merging in the changes from another source. This bug tracks my inquiry as to why this can't just be the default: https://bugs.launchpad.net/udd/+bug/788349 Cheers, -Barry signature.asc Description: PGP signature -- 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 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. -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Using -v when merging from Debian
This is a friendly reminder that when merging a package from Debian, to use -v when building the source package. You pass it the last version that was in Ubuntu and it'll include everything after that in the _source.changes file. This allows all the recorded changes to show up on the -changes mailing list and any LP bugs closed in Debian to be auto-closed. Thanks, Micah -- 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, 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? -- - mdz -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
