Ubuntu Wiki

Agenda

Items we will be discussing:

• Review ACTION points from previous meeting.

• Review progress made on the specification listed on the Roadmap.

• ServerTeam/WebArchitecture - We (ubuntu-eu) have problems setting up a simple web server - problem exposed, solution proposed, discussion welcomed (Yann Hamon)

• EtcUnderRevisionControl status (Koon)

• /etc/screenrc default: leave alone? use screen-profiles/ubuntu? configurable with update-alternatives? (DustinKirkland)

• Server Team Bug Days (zul)

• encrypted private/home with filename encryption available, call for testing (DustinKirkland)

• Open Discussion.
• Agree on next meeting date and time.

Minutes

SRU for ebox

mathiaz reported that ebox 0.12 had been uploaded to Jaunty. The intrepid SRU process can be moved forward. Bug 273486, bug 255368 and bug 314606 are marked Fix Released for Jaunty. The next step is to prepare debdiffs for the intrepid packages.

ACTION: sommer to prepare new debdiffs for the ebox intrepid SRU.

ACL by default

ACTION: ivoks to create a wiki page to keep track of ACL support in packages.

DRBD in jaunty

ivoks announced that the drbd userspace tools had been merged in Jaunty. DRBD 8.3.0 is now working in Jaunty. mathiaz suggested to write up a wiki page to outline testing instructions.

ACTION: ivoks to write a wiki page for conducting DRBD testing under https://wiki.ubuntu.com/Testing/Cases/

Screen profiles

kirkland stated that screen-profiles was in main as a Recommend from the screen package. He also asked what should we do with the default /etc/screenrc. After some discussion it was decided to implement a screen-profile selector that would prompt the user to choose a screen profile the first time screen is run. The workflow would be similar to the sensible-editor choice.

nealmcb updated the ServerGUI wiki page with the latest information about screen and screen-profiles.

ACTION: kirkland to implement a screen-profiles selection tool

ACTION: nealmcb to update the screen factoids

EtcUnderRevisionControl status

Koon gave a quick update on the EtcUnderRevisionControl specification. The implementation is based on improving etckeeper and its bzr plugin to be a little more user-friendly. Koon created an LP project as well as a LP team to organize work done on this topic. He is waiting for the blueprint to be approved.

ACTION: dendrobates to review the etc-under-revision-control blueprint

Server Team Bug Days

zul asked if we should run Server Team bug days. mathiaz said that there had been one Server Team Bug day organized almost 2 years ago. The next step would be to get in touch with the Bug team to get a Server Team bug day setup.

Encrypted private/home with filename encryption available

kirkland announced that the new ecryptfs-utils-69 package enabled filename encryption if the kernel supported it. This feature is only available on new installs. kirkland is working on a script to handle live migration for existing systems.

kirland mentioned that he'd like to get encrypted swap working. He hopes to get a script in Jaunty to help setting up a system to use encrypted swap. Chances to get this feature integrated in the installer for Jaunty are slim.

ACTION: kirkland to make a call for testing filename encryption via a blog post.

Agree on next meeting date and time

Next meeting will be on Tuesday, February 3rd at 16:00 UTC in #ubuntu-meeting.

Log

[16:02] <mathiaz> #startmeeting
[16:02] <MootBot> Meeting started at 10:02. The chair is mathiaz.
[16:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:02] <mathiaz> Today's agenda: https://wiki.ubuntu.com/ServerTeam/Meeting
=== dendrobates- is now known as dendrobates
[16:02] <zul> hi ho neighborarinos
[16:02] <soren> o/
[16:02] <sommer> hey all
[16:02] <mathiaz> what a busy agenda! let's get moving
[16:03] <mathiaz> Last week minutes: https://wiki.ubuntu.com/MeetingLogs/Server/20090120
[16:03] <mathiaz> [TOPIC] SRU for ebox
[16:03] <MootBot> New Topic:  SRU for ebox
[16:03] <mathiaz> so I've uploaded ebox 0.12 to the new jaunty archive
[16:03] <mathiaz> sommer: that means the SRU process for intrepid can move on.
[16:04] <sommer> mathiaz: great, thanks
[16:04] <mathiaz> sommer: do you have the three bug numbers?
[16:04] <sommer> one sec
[16:05] <mathiaz> sommer: https://bugs.launchpad.net/ubuntu/+source/ebox/+bug/273486
[16:05] <ubottu> Launchpad bug 273486 in ebox "Current eBox packages in intrepid don't work at all" [Undecided,New]
[16:06] <mathiaz> sommer: ok - I don't find the others
[16:06] <sommer> bug 255368
[16:06] <ubottu> Launchpad bug 255368 in ebox "ebox: Depends: libapache-authcookie-perl but it is not installable " [Undecided,Fix released] https://launchpad.net/bugs/255368
[16:07] <sommer> and the dbug gconf one
[16:07] <mathiaz> sommer: is there a bug number for the latter?
[16:08] <sommer> mathiaz: bug 314606
[16:08] <ubottu> Launchpad bug 314606 in ebox "ebox and libebox don't support Intrepid gconf version" [Undecided,Fix released] https://launchpad.net/bugs/314606
[16:08] <sommer> that's them :)
[16:08] <mathiaz> sommer: ok - I've just mark bug 273484 fix released
[16:08] <ubottu> Launchpad bug 273484 in ubuntu "monitors wont go to sleep " [Medium,Incomplete] https://launchpad.net/bugs/273484
[16:08] <mathiaz> sommer: https://bugs.launchpad.net/ubuntu/+source/ebox/+bug/273486
[16:08] <ubottu> Launchpad bug 273486 in ebox "Current eBox packages in intrepid don't work at all" [Undecided,Fix released]
[16:09] <mathiaz> sommer: all the three bugs are fixed in jaunty and the intrepid SRU can move along.
[16:09] <sommer> mathiaz: I'll get with foolano and whip up some new debdiffs
[16:10] <mathiaz> sommer: the next step is to get the debdiff for the sru prepared, ACKed by the sru team and then sponsored to intrepid-proposed
[16:10] <mathiaz> [ACTION] sommer to prepare new debdiff for the ebox intrepid SRU
[16:10] <MootBot> ACTION received:  sommer to prepare new debdiff for the ebox intrepid SRU
[16:10] <mathiaz> [TOPIC] ACL by default
[16:10] <MootBot> New Topic:  ACL by default
[16:11] <mathiaz> ivoks: ^^ did you create a wiki page?
[16:11] <ivoks> mathiaz: nope :/
[16:11] <ivoks> mathiaz: probably tomorrow
[16:11] <mathiaz> ivoks: anything else to report on this topic?
[16:11] <ivoks> no
[16:11] <mathiaz> [ACTION] ivoks to create wiki page to keep track of ACL support in packages
[16:11] <MootBot> ACTION received:  ivoks to create wiki page to keep track of ACL support in packages
[16:11] <mathiaz> [TOPIC] DRBD in jaunty
[16:11] <MootBot> New Topic:  DRBD in jaunty
[16:11] <ivoks> drbd is uploaded
[16:11] <mathiaz> ivoks: ^^ ? is dbd working in jaunty?
[16:11] <ivoks> yes
[16:11] <mathiaz> *drbd*
[16:12] <mathiaz> ivoks: what kind of test did you conduct?
[16:12] <ivoks> mathiaz: two vritualized machines
[16:12] <ivoks> i'll do upgrade tests too during this week
[16:12] <mathiaz> ivoks: could you write down some test instructions?
[16:12] <ivoks> sure
[16:13] <mathiaz> ivoks: so that they can be put in a wiki page and other can also help out in testing
[16:13] <ivoks> of course... but in two-three days
[16:14] <mathiaz> ivoks: I'd suggest to create a subpage under https://wiki.ubuntu.com/Testing/Cases/
[16:14] <ivoks> ok
[16:14] <mathiaz> [ACTION] ivoks to write a wiki page for conducting DRBD testing under https://wiki.ubuntu.com/Testing/Cases/
[16:14] <MootBot> ACTION received:  ivoks to write a wiki page for conducting DRBD testing under https://wiki.ubuntu.com/Testing/Cases/
[16:15] <mathiaz> [TOPIC] Screen profiles
[16:15] <MootBot> New Topic:  Screen profiles
[16:15] <mathiaz> kirkland: what's the state of screen and screen-profiles now?
[16:15] <kirkland> mathiaz: screen-profiles is in main
[16:15] <kirkland> mathiaz: screen recommends screen-profiles
[16:16] <nijaba> and it kicks asses
[16:16] <kirkland> nijaba: yes, multiple asses :-)
[16:16] <sommer> heeeh
[16:16] <kirkland> mathiaz: so here's my question for the Ubuntu Server team .....
[16:16]  * mathiaz plays the drums
[16:16] <kirkland> mathiaz: what could/should we do with the default /etc/screenrc ?
[16:16] <cjwatson> conffiles and alternatives are unlikely to be friends; I recommend not using alternatives (as suggested in the agenda)
[16:16] <ivoks> i'm for vanilla /etc/screenrc
[16:17] <kirkland> cjwatson: okay, so not update-alternatives .....
[16:17] <ivoks> just because most of the people expect that
[16:17] <mathiaz> kirkland: how many different screen profiles are there now?
[16:18] <nijaba> ivoks: a lot of people expect linux desktop to be command line only, if we go that direction...
[16:18] <kirkland> ivoks: i agree that that's been the traditional screen profile, but i think we've created something cool, and very Ubuntu-unique ... could be a nice advantage of using the Ubuntu Server
[16:18] <kirkland> mathiaz: for Ubuntu, 3 basically....  the plain vanilla one, ubuntu-light, and ubuntu-dark
[16:18] <ivoks> nijaba: that's correct, but i was thinking more about people who do know how to use cli and screen
[16:18] <kirkland> mathiaz: we also have profiles for debian, etc, but those are not installed on ubuntu
[16:19] <kirkland> ivoks: they won't be using screen then
[16:19] <nijaba> ivoks: run a test, and ask how many admin DO know about screen, you'll be surprised
[16:19] <kirkland> cjwatson: do you have any other suggestion, if not alternatives?
[16:19] <cjwatson> I haven't looked into it at all; I was just raising a warning flag rather than purporting to have an alternative :)
[16:20] <kirkland> cjwatson: thanks
[16:20] <mathiaz> kirkland: what are you trying to accomplish actually?
[16:20] <cjwatson> although I would say, why is this a root-only thing?
[16:20] <mathiaz> kirkland: IIUC you're asking what we should put in /etc/screenrc
[16:20] <kirkland> cjwatson: its not at all a root-only thing
[16:20] <cjwatson> alternatives and other solutions that involve moving things around in /etc are root-only
[16:20] <mathiaz> kirkland: and we have 3 choices
[16:20] <kirkland> cjwatson: any user can have this profile, if they run 'select-screen-profile'
[16:20] <cjwatson> if you aren't focusing on root-only, you should be thinking about options that users can easily set
[16:20] <nijaba> kirkland: what about it being installed by default with ubuntu-standard?  it is quite easy to put back to default
[16:20] <cjwatson> ah, well, who cares about what's in /etc then
[16:21] <ivoks> here's an idea...
[16:21] <ivoks> default screen prompts text, that nobody reads
[16:21] <kirkland> cjwatson: b/c that's what you get if you don't (know to) run 'select-screen-profile'
[16:21] <ivoks> is it possible to put a list of profiles there?
[16:22] <ivoks> that would be selectable? :)
[16:22] <ivoks> just an idea...
[16:22] <nijaba> ivoks: in "select-screen-profiles" ?  that's alreay the case
[16:22] <kirkland> ivoks: ah that's an idea, perhaps .... on that screen we could say "run 'select-screen-profile' if you'd like some advanced features, etc."
[16:22] <nijaba> and once screen is launched, you can change it using the screen profile helper
[16:22] <ivoks> kirkland: no... you would run select-screen-profile
[16:22] <mathiaz> kirkland: how does the sensible-editor selection work?
[16:22] <ivoks> kirkland: and, on first run, let people choose
[16:23] <kirkland> ivoks: i like that, choose on first run
[16:23] <ivoks> kirkland: people that want plain screen, wouldn't notice anything
[16:23] <ivoks> kirkland: they would just hit enter
[16:23] <kirkland> mathiaz: that's sort of how select-editor works
[16:23] <ivoks> kirkland: people who run it for the first time, they would be 'wow, look at that...'
[16:23] <kirkland> mathiaz: ivoks: cool, i think that's a plan
[16:23] <Koon> melikes ivoks plan
[16:24] <mathiaz> kirkland: seems like we could try a similar workflow for screen profiles selection
[16:24] <cjwatson> sounds appropriate
[16:24] <mathiaz> kirkland: do you have an idea on how to do that?
[16:24] <ivoks> right, just as select-editor
[16:24] <kirkland> mathiaz: cheers.  thank you brilliant community
[16:24] <Koon> especially as usual screen users are trained to ignore that screen anyway
[16:24] <mathiaz> kirkland: are you planning to work on that?
[16:25] <kirkland> mathiaz: i think /usr/bin/screen becomes a wrapper script to see if you've selected a profile;  if so, just launch screen.  if not, run select-screen-profile, then launch screen
[16:25] <kirkland> mathiaz: i'll have it done by the end of today ;-)
[16:25] <nijaba> \o/
[16:25] <ivoks> nice
[16:25] <mathiaz> [ACTION] kirkland to implement screen-profiles selection tool
[16:25] <nealmcb> kirkland: the "home page" for this is listed as https://launchpad.net/screen-profiles on launchpad - is that right?  I want to know where to point people from https://help.ubuntu.com/community/ServerGUI
[16:25] <MootBot> ACTION received:  kirkland to implement screen-profiles selection tool
[16:25] <ivoks> good job kirkland
[16:26] <kirkland> nealmcb: correct
[16:26] <nealmcb> will do :)
[16:26] <mathiaz> let's move on
[16:26] <mathiaz> [TOPIC] EtcUnderRevisionControl status
[16:26] <MootBot> New Topic:  EtcUnderRevisionControl status
[16:26] <mathiaz> Koon: ^^ what's going on there?
[16:26] <Koon> Just a quick update on that project, which you may have heard (with the epic delay) at UDS
[16:27] <ivoks> i'm sorry, but i have to leave... bbl
[16:27] <Koon> The design is finalized, it's heavily relying on etckeeper
[16:27] <Koon> everything should be implemented directly into etckeeper
[16:28] <Koon> The idea is to improve etckeeper and its bzr plugin to be a little more user-friendly
[16:28] <mathiaz> Koon: is there anything to test?
[16:28] <Koon> mathiaz: not yet. I created a project and a team on launchpad
[16:29] <Koon> interested people are welcomed to join, I already have Jelmer Vernooij (author of current bzr etckeeper featured) in
[16:29] <mathiaz> Koon: is the spec up-to-date wrt to the implementation plan?
[16:29] <Koon> the spec is up to date, ready to be accepted
[16:29] <mathiaz> Koon: what are the names of the team and project in LP?
[16:29] <jdstrand> Koon: what's the project name in LP?
[16:29] <Koon> project: etckeeper
[16:30] <Koon> team: etckeeper
[16:30] <jdstrand> gee, I could have guessed that...
[16:30] <Koon> it's manually synced with the GIT tree
[16:30] <Koon> at upstream
[16:30] <Koon> and we have Ubuntu branches in there
[16:30] <mathiaz> Koon: so you're waiting for the Spec to approved?
[16:30] <Koon> mathiaz: yes.
[16:31] <Koon> Joey Hess (upstream) has been quite open to intergating more advanced features
[16:31] <Koon> so they should find their way back into core
[16:31] <mathiaz> Koon: great. You should ping dendrobates about aproving the spec
[16:32] <Koon> he is pinged already
[16:32] <jdstrand> Koon: I haven't followed the spec closely since UDS. will this require changes to bzr as well?
[16:32] <Koon> jdstrand: it /could/ use a few more hooks
[16:32] <dendrobates> Koon: he already did.
[16:32] <dendrobates> er mathiaz
=== dholbach_ is now known as dholbach
[16:33] <Koon> jdstrand: especially to catch all permissions-upsdating corner cases
[16:33] <jdstrand> Koon: not that it should be a factor in your devel work, but I was curious how easy it would be to backport to hardy
[16:34] <jdstrand> Koon: IIRC, the hooks cannot be done via bzr plugins-- is that accurate?
[16:34] <mathiaz> dendrobates: are you planning to review the blueprint soon?
[16:34] <dendrobates> mathiaz: yes.
[16:34] <Koon> jdstrand: hooks usually are in bzr core, and plugins use them
[16:34]  * jdstrand nods
[16:35] <Koon> but you could theorically add a hook by plugin, it just doesn't make much sense in the common scenario
[16:35] <mathiaz> [ACTION] dendrobates to review the etc-under-revision-control blueprint
[16:35] <MootBot> ACTION received:  dendrobates to review the etc-under-revision-control blueprint
[16:35] <mathiaz> ok - let's move on.
[16:35] <mathiaz> [TOPIC] Server Team Bug Days
[16:35] <MootBot> New Topic:  Server Team Bug Days
[16:35] <mathiaz> zul: what's your idea?
[16:36] <zul> yeah so I was thinking that other teams have similar things where they hang out on the bugs channel and get people to help fixing bugs, i believe its a good way to get people involved
[16:37] <mathiaz> right. We had one bug day organized by the bug team
[16:37] <mathiaz> that was about 1 3/4 years ago
[16:37] <zul> well we should have another one organized soonish
[16:37] <mathiaz> so I'd suggest to ask the Bug team about it
[16:38] <mathiaz> they'd be more than happy to help out and we'd reach much more people
[16:38] <mathiaz> than just organizing a Server Bug day in the server team.
[16:38] <mathiaz> bdmurray: what should we do to get a Server Team Bug day organized?
[16:38] <zul> well thats what I was thinking as well we need someone to approach them
[16:40] <dendrobates> mathiaz zul: I am arranging a discussion between all of us at the sprint.
[16:40] <zul> thats it from me :)
[16:40] <zul> dendrobates: nifty
[16:40] <mathiaz> dendrobates: ok. We'll talk about this topic next week then.
[16:40] <mathiaz> let's move on
[16:41] <mathiaz> [TOPIC] ncrypted private/home with filename encryption available
[16:41] <MootBot> New Topic:  ncrypted private/home with filename encryption available
[16:41] <kirkland> \o/
[16:41] <mathiaz> kirkland: what did you do?
[16:41] <kirkland> i uploaded a new ecryptfs-utils-69 package that enables filename encryption, if your kernel supports it
[16:41] <kirkland> rtg on the kernel team backported ecryptfs filename encryption from 2.6.29 to 2.6.28
[16:42] <kirkland> and i completed the userspace bits this weekend to make this work with encrypted home and encrypted private
[16:42] <mathiaz> kirkland: awesome.
[16:42] <kirkland> so, if you were to use ecryptfs-setup-private on an up-to-date jaunty system, you would see that your filenames are now encrypted as well, in your underlying .Private dir
[16:42] <kirkland> and transparently decrypted for your in Private
[16:42] <kirkland> same goes for encrypted home
[16:43] <mathiaz> kirkland: so upgrade are automatically handled?
[16:43] <kirkland> mathiaz: dammit with the hard questions!
[16:43] <kirkland> mathiaz: :-)
[16:43] <kirkland> i still have some work to do on "live migration"
[16:43] <kirkland> with some help from jdstrand, we came up with a theoretical design to solve this
[16:43] <mathiaz> kirkland: ok - so you get filename encryption on new installs only.
[16:44] <mathiaz> kirkland: for now
[16:44] <kirkland> i'm flying to Germany tomorrow;  i hope to hack that live migration script then
[16:44] <kirkland> mathiaz: right
[16:44] <kirkland> mathiaz: if you wanted to take advantage of this, you should backup your cleartext data elsewhere
[16:44] <mathiaz> kirkland: ok - do you have specific instructions for testing this?
[16:44] <kirkland> mathiaz: then do a new ecryptfs-setup-private (fresh, empty dir)
[16:44] <kirkland> mathiaz: and then rsync your data back in
[16:45] <kirkland> mathiaz: i will blog about it this week
[16:45] <cjwatson> note that the desktop CD's still busted, this is server/alternate install CD only still
[16:45] <mathiaz> kirkland: great.
[16:45] <kirkland> cjwatson <- is right
[16:45] <kirkland> but i think we  (evand, cjwatson) mostly know whats wrong there
[16:46] <mathiaz> [ACTION] kirkland to make a call for testing filename encryption
[16:46] <MootBot> ACTION received:  kirkland to make a call for testing filename encryption
[16:46] <kirkland> cjwatson: i have set ecryptfs-setup-private to automatically use filename encryption, if possible
[16:46] <kirkland> cjwatson: so no further changes in that respect should be required from you dudes
[16:47] <mathiaz> excellent news kirkland !
[16:47] <mathiaz> kirkland: is there anything else to add on this topic?
[16:48] <mathiaz> kirkland: once the installer has support for this is there anything else left to be done for jaunty?
[16:48] <kirkland> mathiaz: encrypted swap
[16:49] <kirkland> mathiaz: i *strongly* believe that any user using encrypted home or encrypted private should really be using encrypted swap
[16:49] <mathiaz> kirkland: ok - that's a different (but related) topic
[16:49] <mathiaz> kirkland: for encrypted directories I meant
[16:49] <kirkland> mathiaz: in such cases, all of the encrypted data lives as cleartext in memory
[16:49] <kirkland> mathiaz: should that memory get swapped to disk, it's swapped to disk in the clear, unless swap too is encrypted
[16:49] <mathiaz> kirkland: is this something targeted for jaunty?
[16:50] <kirkland> mathiaz: in the very worst case, i plan on adding a script to ecryptfs-utils that would attempt to setup your system for encrypted swap
[16:50] <kirkland> mathiaz: to be run at the user's discretion after installation
[16:50] <kirkland> i'm guessing that this item probably won't make the installer at this point
[16:50] <mathiaz> kirkland: ok. seems like a good first step.
[16:50] <kirkland> i hope to talk to the foundations team about this next week
[16:51] <mathiaz> kirkland: FYI FeatureFreeze is in 3 weeks
[16:51] <kirkland> mathiaz: and the live migration scripts
[16:51] <kirkland> mathiaz: right
[16:51]  * kirkland is looking forward to FF :-)
[16:51]  * kirkland <--- late nights
[16:51] <mathiaz> ok - let's move on.
[16:52] <mathiaz> [TOPIC] Open Discussion
[16:52] <MootBot> New Topic:  Open Discussion
[16:52] <nealmcb> I updated https://help.ubuntu.com/community/ServerGUI to note the latest info on screen and screen-profiles.  feel free to jump in
[16:52] <sommer> I have a quick question about the installer.  are we going to be using lvm by default, there was some talk about it at UDS?
[16:52] <soren> sommer: Noone's been working on it, AFAIK.
[16:53] <nealmcb> !screen
[16:53] <ubottu> screen is a terminal multiplexer. See http://www.kuro5hin.org/story/2004/3/9/16838/14935 and http://en.wikipedia.org/wiki/GNU_Screen
[16:53] <nealmcb> I'll update that factoid also - input welcome
[16:53] <sommer> soren: okay, I just was wondering for documentation reasons
[16:53] <mathiaz> nealmcb: great - thanks.
[16:53] <mathiaz> [ACTION] nealmcb to update the screen factoids
[16:53] <MootBot> ACTION received:  nealmcb to update the screen factoids
[16:55] <mathiaz> anything else?
[16:55] <jdstrand> I might mention that ufw now has debconf/preseeding support
[16:55] <cjwatson> kirkland: I think you'll be lucky to get encrypted swap by default
[16:56] <kirkland> cjwatson: not "by default"  ... i've abandoned that
[16:56] <cjwatson> sommer: I saw that there had been a requirement mentioned for it, but nobody wrote up the UDS session *at all*
[16:56] <kirkland> cjwatson: but "when encrypted home is selected", would be ideal
[16:56] <cjwatson> i.e. there's a server-installer-partitioning spec that doesn't even have a wiki link set
[16:56] <cjwatson> kirkland: I doubt that's feasible for jaunty. Sorry
[16:56] <kirkland> cjwatson: right
[16:56] <sommer> cjwatson: ah, well maybe for jaunty+1
[16:56] <cjwatson> does anyone care enough to watch the UDS videos corresponding to server-installer-partitioning and write it up so that I have some clue what the design is supposed to be?
[16:57] <cjwatson> I understood that it had got demoted in priority, which is why I haven't been making too much noise about it
[16:57] <kirkland> cjwatson: let's discuss contingency plans next week.  i'm thinking now about an ecryptfs-utils provided script that would do the magic for you, in some constrained cases.  and then document/warn that it needs to be run, for more security
[16:58] <cjwatson> kirkland: it's already on the foundations agenda for next week
[16:59] <nealmcb> I think the encrypted swap session was at noon on the 11th: http://videos.ubuntu.com/uds/jaunty/Server/2008-12-11/morning-post-break/
[16:59] <sommer> cjwatson: from my UDS notes and memory, it was only mentioned during the server raid discussion, as sort of a sidebar
[16:59] <kirkland> cjwatson: awesome, i'll be there with bells on :-)
[16:59] <sommer> cjwatson: err the lvm discussion
[16:59] <mathiaz> ok - let's move on
[16:59] <mathiaz> [TOPIC] Agree on next meeting date and time
=== smarter_ is now known as smarter
[16:59] <MootBot> New Topic:  Agree on next meeting date and time
[17:00] <mathiaz> same place, same time, next week?
[17:00] <kirkland> k
[17:00] <sommer> works for me :)
[17:00] <cjwatson> sommer: ok, that doesn't make it very easy to have a clue on what to implement, given that there are known problems with the post-installation tools
[17:00] <dendrobates> cjwatson: I think it was not actually help to allow for even more cloud discussions/
[17:00] <dendrobates> cjwatson: I'll review what I have, though.
[17:01] <mathiaz> ok - see you all next week
[17:01] <mathiaz> same time same place here.