[00:11] <CIA-4> installation-guide: cjwatson * r460 ubuntu/debian/ (archlist changelog control): Disable building for hppa, since it's EOL.
[00:17] <rgreening> evand: well, I keep trashing my usb stick :) progress I guess .. haha
[09:07] <purplefool> hi, was bedeutet 'writelines() argument must be a sequence of strings'?  wie kann ich das korregieren?
[09:08] <_ruben> this is an english channel, and where are you seeing that?
[09:09] <cjwatson> ("what does 'writelines() argument must be a sequence of strings' mean?  how can I correct this?")
[09:09] <purplefool> gads, sorry!!  my display is german and i didn't want that.  good, i am trying to install in winxp and this is what i get through the installer
[09:10] <cjwatson> purplefool: could we see the full log, e.g. on paste.ubuntu.com?
[09:10] <cjwatson> it's an error from the python standard library, but hard to say why you're getting it without context
[09:10] <purplefool> where should i past it...have the log just for this question^^
[09:10] <cjwatson> paste.ubuntu.com please?
[09:10] <purplefool> ok, now you will see what a noob i am...how do i paste it?
[09:12] <purplefool> ok, done...was easier then i thought
[09:12] <cjwatson> get it into the clipboard (Edit->Copy in an editor or whatever), right-click->Paste in text box on website?
[09:12] <cjwatson> alternatively paste.debian.net has a file upload widget
[09:12] <purplefool> am working with windows at the moment^^
[09:14]  * cjwatson files a request for a file upload widget to be added to paste.ubuntu.com
[09:14] <cjwatson> anyway, need you to give me the URL that paste.ubuntu.com gave you
[09:15] <purplefool> oh...sorry...here it is:  http://paste.ubuntu.com/199025/
[09:17] <purplefool> does this show anything that makes sence? or helps?
[09:17] <cjwatson> hmm, ok, a wubi bug, the main wubi guy isn't here at the moment
[09:17] <cjwatson> oh, he is :-)
[09:17] <cjwatson> xivulon: purplefool is reporting http://paste.ubuntu.com/199025/ with what looks like current wubi
[09:18] <cjwatson> wubi's tasklist.error exception handling doesn't preserve the traceback position unfortunately
[09:19] <purplefool> that was english...but i have no idea what it means.  it sounds like the problem wasn't recoreded.
[09:21] <purplefool> why is the cd checking all the other drives for information?  is that normal?
[09:22] <xivulon> cjwatson, that is an odd version, I believe we shipped r129, in any case that bug should have been fixed in r136
[09:22] <xivulon> purplefool: can you please try wubi r136
[09:22] <purplefool> if you tell me what wubi is and what r136 is i would be very happy to do that.
[09:26] <purplefool> ok, am downloading wubi right now...don't know if it is r136, but it should be the latest version.  this is the page:  http://www.ubuntu.com/getubuntu/downloadmirrors#wubi
[09:29] <purplefool> ok, still get r129 with my download...btw, r136 is revision, correct?
[09:29] <cjwatson> yeah
[09:30] <cjwatson> http://people.ubuntu.com/~evand/wubi/karmic/wubi-r136.exe is a current build, but probably not signed
[09:31] <evand> top of my list this morning is pushing that to releases.ubuntu.com
[09:31] <cjwatson> xivulon: would something like http://paste.ubuntu.com/199032/ (totally untested) make sense?
[09:31] <purplefool> http://paste.ubuntu.com/199031/  this is the cutandüaste for r129...will look for r136 and download it now.
[09:33] <cjwatson> evand: it also seems kind of unfortunate that tracebacks from wubi expose Z:\home\evan\bzr\wubi.trunk\build\... - I don't suppose that can be fixed?
[09:34] <purplefool> ok, now it is being installed...don't know what the prob was, but thx for your help in finding the right wubi (cute name...sounds like a childs stuffed animal!)
[09:36] <cjwatson> "Windows UBuntu Installer"
[09:36] <evand> I'm sure at the very least we could tidy that up in an excepthook, but I'll put trying to find a cleaner solution on my todo list.
[09:37] <xivulon> sorry I am on/off from machine as I have to rush out, cjwatson seems reasonable, but will have to spend more than 2secs on it to digest
[09:38] <xivulon> cjwatson the full path is due to the byte-compilation stage
[09:39] <xivulon> via pypack
[09:39] <xivulon> ehm pylauncher
[09:41] <xivulon> src/pylauncher/pack.py > compile
[09:44] <xivulon> I guess py_compile.compile -> dfile argument will do ? will have a second look later
[09:45] <xivulon> have to go now
[10:33] <mpt> "When installing, the keyboard layout suggestion should be based on the time zone chosen."
[10:33] <mpt> It already is, right?
[10:37] <evand> mpt: indeed it is
[10:37] <mpt> hm, wonder why this person thought it isn't
[10:37] <mpt> he/she is in Portugal
[10:37] <mpt> I'll ask
[10:44] <cjwatson> mpt: it depends. It's based on a combination of language and country.
[10:45] <cjwatson> Being in Portugal does get you a Portuguese keyboard by default though, as far as I can see.
[11:31] <evand> shtylman: if you're done editing, can you please mark your spec as "Review"?
[11:47] <evand> shtylman: also, were you keen on taking on the oem-config / ubiquity merge, or am I okay to punt that to another developer?
[11:47] <evand> xivulon: dreamhost lets you run IRC clients on their servers now?
[11:49] <xivulon> ah that is interesting
[11:50] <xivulon> by the way created 389424, will patch later on tonight, thanks cjwatson
[12:03] <cjwatson> cool, ta
[14:38] <shtylman> evand: marked, also...if there is a developer willing to take it on that would be good...ive had my hands full with other stuff...but if not, I will tackle it :)
[14:39] <evand> sure thing, I think mterry is willing to work on it as part of the oem-config specification
[14:40] <evand> shtylman: you might want to also poke Riddell about approving it.  I know we're past the deadline, but perhaps he can talk to Rick (or whoever that falls to) about an exception.
[14:41] <shtylman> evand: will do :) thanks
[14:46] <rgreening> evand: you have a chance to look over the recent changes to usb-creator?
[14:48] <evand> indeed, looked it over last night.  It looks okay, feel free to merge that in
[14:49] <evand> be sure to do so in a way that preserves history
[14:49] <evand> so bzr mv
[14:49] <rgreening> sure
[14:49] <evand> thanks
[14:49] <rgreening> I'll write the wrappers for the gtk_frontend.py as part fo the merge.
[14:51] <rgreening> oh, and persistance would try and create a casper file that was x MB * 1024^2... seems it wasn't down converted before being passed to the install.py.
[14:51] <rgreening> I've fixed in local and will push that up too
[14:52]  * rgreening wondered why my stick kept running out of space
[14:52] <rgreening> :P
[15:02] <evand> heh
[15:03] <evand> my fault, I must've screwed up the merge into trunk at UDS
[15:43] <rgreening> lol
[15:44] <rgreening> np, I'll up my changes later today. gotta go buy a fathers day gift...
[16:54] <kirkland> cjwatson: hiya, i'm still looking for some feedback on that /var/lib/ecryptfs issue
[16:55] <kirkland> cjwatson: i have a package i'm testing now, seems to be doing most of what i want
[16:55] <kirkland> cjwatson: but the design itself could use some more eyeballs
[17:28] <cjwatson> kirkland: the basic design seems reasonably plausible to me. I definitely prefer /home/.ecryptfs over /.home; it seems more appropriately contained to me, more expressive, and I dislike new directories off / anyway
[17:28] <kirkland> cjwatson: agreed.
[17:28] <cjwatson> kirkland: do be insanely careful about moving the files across from /var though; they might be on different filesystems so it won't just be a rename
[17:28] <cjwatson> kirkland: think about what happens if the move is interrupted half-way through
[17:29] <kirkland> cjwatson: okay, use cp -a, check the return, then delete?
[17:29] <kirkland> cjwatson: this data *should* be very, very small
[17:29] <cjwatson> I'd use rsync so that it can be more easily restarted
[17:29] <cjwatson> but I suppose that works too if it's just configuration
[17:29] <kirkland> cjwatson: at least, the data that ecryptfs puts there is a trivial amount, a few bytes, less than 1K
[17:29] <cjwatson> perhaps cp -a one user at a time
[17:29] <kirkland> cjwatson: rsync isn't on the desktop, i don't think
[17:30]  * kirkland hits that sometimes
[17:30] <cjwatson> hmm, I have neither /var/lib/ecryptfs/ nor /home/.ecryptfs/. Should I?
[17:30] <cjwatson> rsync Task: standard
[17:30] <cjwatson> you could depend on it, most people will have it already
[17:30] <cjwatson> but I think your cp -a approach is probably ok
[17:30] <kirkland> cjwatson: do you have an encrypted home?
[17:30] <kirkland> cjwatson: or just encrypted private?
[17:30] <cjwatson> oh, no, just private
[17:30] <cjwatson> ok
[17:31] <kirkland> cjwatson: encrypted private are unaffected
[17:31] <cjwatson> right, of course
[17:32] <kirkland> cjwatson: http://pastebin.ubuntu.com/199393/
[17:32] <kirkland> cjwatson: that's my work in progress diff
[17:32] <kirkland> cjwatson: you might start at the bottom, looking at the init script
[17:33] <cjwatson> mkdir -m 600 -p, just in case
[17:33] <cjwatson> will save an error if it already exists if nothing else
[17:33] <kirkland> cjwatson: ack
[17:33] <cjwatson> gar, why are these scripts not set -e? oh well
[17:34] <kirkland> cjwatson: which one?
[17:34] <kirkland> cjwatson: the init script is sh -e
[17:34] <kirkland> cjwatson: is that the same thing?
[17:34] <cjwatson> at least the init script is
[17:34] <cjwatson> ecryptfs-setup-private isn't
[17:34] <kirkland> cjwatson: right, i'd like to fix that, for sure
[17:34] <cjwatson> sh -e is near enough the same thing
[17:34] <kirkland> cjwatson: what's the difference?
[17:34] <kirkland> sh -e and set -e
[17:34] <cjwatson> I tend to write 'set -e' separately nowadays because that means you can use 'sh -x' on a script without changing its error-handling behaviour
[17:35] <cjwatson> otherwise they're identical
[17:35] <kirkland> oh
[17:35] <kirkland> cool
[17:35] <kirkland> i'll abide by that hence forth
[17:35] <cjwatson> would it be better to use mountpoint(1) rather than mount | grep?
[17:36] <kirkland> cjwatson: good call
[17:36] <kirkland> cjwatson: didn't know that was around
[17:36] <cjwatson> [ ... -a ... ] => [ ... ] && [ ... ] for portability
[17:37] <cjwatson> perhaps 'rm "/home/.$PKG/$i/.$PKG"' => 'rm -f "/home/.$PKG/$i/.$PKG"'? (at least I tend to do that out of habit)
[17:37] <cjwatson> probably makes no difference
[17:37] <kirkland> cjwatson: -a && ... ack
[17:38] <kirkland> cjwatson: okay
[17:38] <cjwatson> in ecryptfs-fix-link, I'd recommend just testing the output of readlink for equality rather than that grep. Usernames can contain "." which is a metacharacter to grep
[17:38] <cjwatson> ln -snf> good, a lot of people forget that -n
[17:38] <cjwatson> why "/home/.$PKG/$i/.$PKG" in the init script but "/home/.$PKG/$i/.ecryptfs" in fix-link?
[17:38] <kirkland> cjwatson: yeah, testing sent me to the manpage to find -snf :-)
[17:39] <kirkland> cjwatson: i'll fix that, i'm trying to $PKG as much as possible now
[17:39] <kirkland> cjwatson: the name shift from screen-profiles -> byobu make me realize the value in that :-)
[17:39] <cjwatson> I wonder if variables or shell functions or something would make it a bit more readable
[17:39] <kirkland> cjwatson: which one?
[17:40] <cjwatson> it's quite hard to glance at "/home/.$PKG/$i/.$PKG" and be sure no characters have been left out :)
[17:40] <kirkland> good point
[17:40] <cjwatson> home_config_dir () { echo "/home/.$1/$2/$1"; }   "$(home_config_dir "$PKG" "$i")" or something
[17:40] <cjwatson> maybe that doesn't help
[17:40] <cjwatson> ... and I left a dot out there :-)
[17:41] <cjwatson> I think that's my nitpicking budget exhausted
[17:41] <kirkland> cjwatson: question about your readlink comment
[17:41] <kirkland> cjwatson: how do you recommend I get around that grep?
[17:41] <kirkland> cjwatson: oh, test equality
[17:42] <cjwatson> oh, but it isn't equality
[17:42] <cjwatson> is it?
[17:42] <cjwatson> is that * at the end of the grep meant to be .* ?
[17:42] <kirkland> cjwatson: right, i used the grep to handle trailing slashes
[17:42] <cjwatson> or is it zero-or-more slashes?
[17:42] <kirkland> cjwatson: links can have 0 or more trailing slashes
[17:43] <cjwatson> readlink -f canonicalises those away
[17:43] <kirkland> sweet, thanks.
[17:44] <cjwatson> or you could do target="$(readlink "/home/.$PKG" | sed 's,/*$,,')" if you didn't want to rely on that
[17:44] <cjwatson> but readlink -f is probably sane anyway - oh, waitaminute, that doesn't work if somebody made /var/lib/ecryptfs a symlink to a directory on another partition
[17:44] <cjwatson> so I think you might need the sed approach
[17:44] <kirkland> cjwatson: http://pastebin.ubuntu.com/199405/
[17:45] <cjwatson> I've been known to make /var a symlink to /space/var on awkwardly-laid-out systems :)
[17:45] <kirkland> cjwatson: hrm
[17:45] <cjwatson> ("$readlink" => "$LINK" in your paste BTW)
[17:45] <kirkland> shite
[17:45] <kirkland> okay
[17:46] <cjwatson> LINK="$(readlink "/home/.$PKG" | sed 's,/*$,,')"; if [ "$LINK" = "/var/lib/$PKG/$USER" ]; then ... fi
[17:47] <kirkland> cjwatson: is it standard to quote LINK="$(...)" ?
[17:47] <kirkland> cjwatson: i've never done it that way
[17:47] <kirkland> LINK=$(...)   or LINK=`...`   <--- me uses
[17:48] <cjwatson> I believe that strictly speaking it isn't necessary, but I can never quite remember whether it is or not and my standard policy is to quote any $-expansion unless I'm sure I don't need to
[17:49] <kirkland> cjwatson: okay
[17:50] <cjwatson> "The text after the = in each variable assignment undergoes tilde expansion, parameter expansion, command substitution, arithmetic expansion, and quote removal before being assigned to the variable." says bash(1)
[17:50] <cjwatson> so no word splitting, and therefore you're right that the quotes aren't necessary
[17:51] <cjwatson> dash(1) is a lot less clear but I think that is standard behaviour
 mkdir -m 600 -p, just in case
[17:51] <cjwatson> err, that was somewhere up above, ecryptfs-setup-private I think
[17:52] <cjwatson> I think it was just code you were moving around
[17:52] <kirkland> 600 vs 700?
[17:52] <kirkland> ah
[17:52] <cjwatson> I meant 'mkdir -m 600' vs. 'mkdir -m 600 -p'
[17:53] <kirkland> right, that makes more sence
[17:53] <kirkland> sense, even
[17:53] <kirkland> cjwatson: okay, so here are the things I've tested, and verified to fix ...
[17:54] <kirkland> cjwatson: encrypted private users are not affected, as their .Private and .ecryptfs dirs are real directories in $HOME, and not symlinks
[17:54] <kirkland> cjwatson: encrypted home users are affected, by design of course
[17:54] <kirkland> cjwatson: for that bind mount (init script) to work, NO encrypted home user can be logged in with a mounted home
[17:55] <kirkland> cjwatson: otherwise, the bind mount would latch onto the mounted cleartext data, and not the underlying dir
[17:55] <kirkland> cjwatson: the check exists in the init script
[17:55] <kirkland> cjwatson: on upgrade, restarting that init script will "warn", but still exit 0 such that the package upgrade succeeds
[17:56] <kirkland> cjwatson: for all practical purposes, this won't really take effect until the next reboot, hence the touch reboot-required in the postinst
[17:56] <cjwatson> yes
[17:56] <cjwatson> hmm, two concerns about fix-link
[17:56] <kirkland> cjwatson: hit me
[17:57] <cjwatson> oh, well, one was a misreading on my part, I read $HOME as /home
[17:57] <cjwatson> (sigh)
[17:58] <kirkland> cjwatson: i can variablize that to BIND_DIR="/home/.$PKG"
[17:58] <cjwatson> the second, though, is that it runs every single time a user logs in for the rest of time
[17:58] <cjwatson> this seems perhaps a little heavyweight. can we think of a better way?
[17:58] <kirkland> cjwatson: heh, this is the lightweight version :-)
[17:58] <kirkland> cjwatson: i had some C code that did this in pam_ecryptfs.c
[17:59] <cjwatson> I was about to suggest that that might be lighter weight
[17:59] <cjwatson> shell scripts tend to fork quite a bit
[17:59] <cjwatson> one syscall for readlink() is surely better than fork() execve() load bunch of libraries readlink() exit() in terms of weight
[18:00] <kirkland> cjwatson: building the strings and the stat() calls weren't as trivial (in code writing) as shell
[18:00] <kirkland> cjwatson: but it could certainly be done
[18:00] <cjwatson> right, the code is more work, but the ultimate system impact should be less
[18:01] <cjwatson> I think I'd be happier with that if it's feasible, given that pam_ecryptfs is running anyway
[18:01] <kirkland> cjwatson: oh, there's the chowning too
[18:01] <kirkland> cjwatson: the pam stuff runs as root
[18:01] <kirkland> cjwatson: so permissions need to be fixed on the symlink
[18:02] <cjwatson> I agree you have to be a bit careful
[18:02] <cjwatson> but the syscall sequence shouldn't be all that long
[18:02] <kirkland> cjwatson: i can do it that way
[18:02] <kirkland> cjwatson: one other idea, though
[18:02] <kirkland> cjwatson: what if this script were "removed" at some point, once it was guaranteed unnecessary ?
[18:04] <cjwatson> I think I'd still be happier with it being done in C
[18:04] <kirkland> cjwatson: okay, no problem
[18:04] <kirkland> cjwatson: back to the reboot-required issue ...
[18:04] <cjwatson> it just seems a lot simpler from a system integration / packaging POV
[18:05] <kirkland> cjwatson: if the admin tries to adduser --encrypt-home <newuser>, before that bind mount is established (before reboot, for practical purposes), that will fail
[18:05] <cjwatson> if you wanted to remove it at some point, you wouldn't be able to ship it as a straightforward file in the package, since it isn't unnecessary until all users have logged in and had their directories moved over
[18:05] <cjwatson> meh, have adduser fail then :)
[18:05] <kirkland> cjwatson: i've handled it somewhat gracefully with informative error messages
[18:05] <kirkland> cjwatson: it does
[18:06] <cjwatson> I think that's ok?
[18:06] <cjwatson> oh, one more point on pam_ecryptfs
[18:06] <cjwatson> is there any possibility that /home might be on NFS?
[18:06] <kirkland> cjwatson: right, except that the user *is* created, but the home encrypting fails, so that user is sorta busted
[18:06] <cjwatson> if so, you need to make sure to do the home directory editing with dropped privileges, due to root_squash
[18:06] <kirkland> cjwatson: was wondering if there was a clean-up-user-if-add-fails option or handler in adduser
[18:06] <cjwatson> I think so
[18:07] <kirkland> cjwatson: known bug, ecryptfs kernel support broken for NFS and Samba
[18:07] <kirkland> cjwatson: so there aren't any working encrypted-home-on-nfs that i know of
[18:07] <kirkland> cjwatson: it's not possible at this point
[18:07] <kirkland> cjwatson: however, i did start the initscript at 47 (just after nfs) in case that starts working one day
[18:08] <cjwatson> well, nevertheless, it seems perhaps a prudent approach to do the home directory changes with dropped privileges
[18:08] <cjwatson> on the minimal-privilege principle if nothing else
[18:08] <cjwatson> if it's possible with PAM's ordering, that is
[18:08] <kirkland> cjwatson: so in the pam_* bits, drop privs
[18:08] <cjwatson> or do it in a hook that already runs with dropped privileges, if there's an appropriate one
[18:08] <kirkland> cjwatson: which i'd need to do anyway to handle the symlink ownership properly
[18:08] <cjwatson> but yes. ask slangasek if in doubt :-)
[18:08] <cjwatson> nah, in principle you could use lchown
[18:08] <cjwatson> but anyway
[18:09] <cjwatson> for adduser: I don't think there is actually any rollback support. Maybe just check for the doomed situation up-front before starting? You're already hacking adduser directly rather than using any particular hooks so that seems no great hardship
[18:09] <kirkland> cjwatson: i was actually thinking about creating this as a standalone program.c and fork/exec'ing it
[18:09] <kirkland> cjwatson: would make my testing thereof atomically easier
[18:09] <kirkland> cjwatson: could be a function in pam_ecryptfs.c though
[18:10] <cjwatson> perhaps for prototyping, but I'd like to have a very good reason for any extra processes in a standard login session
[18:10] <kirkland> cjwatson: understood
[18:10] <cjwatson> they tend to add up rather
[18:10] <kirkland> cjwatson: i'll integrate it directly
[18:10] <cjwatson> you could give it a main() function, compiled conditionally
[18:11] <kirkland> cjwatson: bah, i'll just put it in pam_ecryptfs.c
[18:11] <kirkland> cjwatson: i have a mostly working prototype already
[18:11] <kirkland> cjwatson: okay, so back to the testing situation, everything is definitely hunky dorey after the reboot, adduser being the only known breakage (though gracefully handled)  prior to reboot
[18:12] <kirkland> cjwatson: so the init script throws an error message if you try to stop it (should not unmount this dir)
[18:12] <kirkland> cjwatson: but the admin can obviously umount /home/.ecryptfs
[18:12] <kirkland> cjwatson: which might yank away access of other users to their .ecryptfs data
[18:13] <kirkland> cjwatson: they can continue to login, no problem.
[18:13] <kirkland> cjwatson: but they can't logout, or change their pwd
[18:13] <cjwatson> interesting symptoms :)
[18:14] <kirkland> cjwatson: heh, yeah
[18:14] <cjwatson> same would go if /home were mounted separately and the admin unmounted that, though
[18:14] <kirkland> cjwatson: it would be a "dumb" thing for an admin to do
[18:14] <cjwatson> actually, wouldn't the admin get EBUSY?
[18:14] <cjwatson> *shouldn't* the admin get EBUSY?
[18:14] <kirkland> cjwatson: not in my testing, unless someone is doing something in .ecryptfs
[18:14] <cjwatson> oh, 'cos it's just configuration not files
[18:14] <kirkland> cjwatson: right
[18:15] <cjwatson> or not data anyway
[18:15] <cjwatson> you could have something hold an fd open there, but I don't know that it's worth it - just a DDTT
[18:15] <kirkland> cjwatson: the only way i see around this is having the real data somewhere permanently accessible, and not bind mounted
[18:15] <kirkland> cjwatson: which was previously /var/lib/ecryptfs <---- what we're trying to get rid of
[18:16] <kirkland> cjwatson: RH solved this for polyinstantiation with /home/.$USER directories
[18:16] <cjwatson> remind me why it can't be a *real* directory /home/.ecryptfs?
[18:16] <cjwatson> and have pam_ecryptfs look for configuration under that?
[18:16] <cjwatson> ISTM that you only have this problem because you want to have ecryptfs keep looking in /home/$USER/.ecryptfs
[18:17] <cjwatson> perhaps breaking that constraint would be easier overall
[18:17] <kirkland> cjwatson: yeah, that could be done;  create a list of places where .ecryptfs might be found
[18:17] <kirkland> cjwatson: so the other thing this is trying to solve is to give users's access to their encrypted .Private data for backups
[18:17] <kirkland> cjwatson: the bind mount solves that too
[18:18] <cjwatson> right, it does, but you could deal with that by a similar migration path for .Private
[18:18] <cjwatson> data migration rather than config migration
[18:18] <cjwatson> I dunno, just seems like a potential option with some upsides
[18:18] <kirkland> cjwatson: hmm, well, let me toss this one out ...
[18:19] <kirkland> cjwatson: which i did pitch for jaunty, but i don't remember why it got nack'd
[18:19] <kirkland> cjwatson: /home/.$USER, real dir with actual .ecryptfs and .Private
[18:19] <kirkland> cjwatson: /home/.$USER/.Private mounted on top of /home/$USER
[18:19] <kirkland> cjwatson: /home/.$USER always available
[18:20] <kirkland> cjwatson: hence, .ecryptfs and .Private encrypted data (for backups) always available
[18:20] <kirkland> cjwatson: users wanted to back up their cleartext data backup $HOME
[18:20] <kirkland> cjwatson: users wanting to backup their encrypted data backup /home/.$USER
[18:22] <cjwatson> I didn't like doubling the number of directory entries in /home
[18:22] <cjwatson> there may be significant performance considerations there on some filesystems
[18:23] <cjwatson> /home/.ecryptfs/$USER avoids those performance considerations hitting every path lookup under /home
[18:23] <cjwatson> I don't honestly see why /home/.ecryptfs/$USER is any more difficult to implement than /home/.$USER
[18:23] <cjwatson> and it seems more appropriately contained
[18:24] <kirkland> cjwatson: that's fair, i think
[18:24] <kirkland> cjwatson: i'd like to avoid the bind mount for sure!
[18:24] <cjwatson> either way, you need to worry about moving .Private
[18:24] <cjwatson> (for migration)
[18:24] <kirkland> cjwatson: that's a simple inode mv, though, right?
[18:25] <kirkland> cjwatson: would doublecheck the mountpoints
[18:25] <kirkland> cjwatson: but /home/$USER and /home/.ecryptfs should be on the same $fs
[18:25] <kirkland> cjwatson: i guess the check is $HOME ?= /home/$USER  :-)
[18:27] <cjwatson> rename() should be atomic even on directories if they're on the same fs, yes
[18:27] <kirkland> cjwatson: okay, i'm on board with you then
[18:27] <kirkland> cjwatson: ditch the bind mount mess
[18:28] <kirkland> cjwatson: make /home/.ecryptfs a real dir
[18:28] <cjwatson> and the only nasty cases are when some idiot did mount --bind /space/my-home-directory /home/idiot
[18:28] <kirkland> cjwatson: with /home/.ecryptfs/[$USERS]
[18:28] <cjwatson> (ok, idiot is harsh ...)
[18:28] <cjwatson> but you could always have a fallback case for that
[18:28] <kirkland> cjwatson: heh
[18:29] <kirkland> cjwatson: okay, i still need a little bit of symlink fixing handled in the init script (no mounting, though)
[18:29] <kirkland> cjwatson: as well as the mv of the real dir
[18:29] <cjwatson> symlinks in the user's home directory might still be nice for discoverability
[18:29] <kirkland> cjwatson: and we'll still need one minor bit of C code in the pam module to handle the fixup too
[18:29] <cjwatson> /home/.ecryptfs/ is a bit non-obvious to find if you don't know it's there
[18:29] <kirkland> cjwatson: right, absolutely
[19:32] <cr3> hi folks, I'm getting a TimezoneApply error raised in ./scripts/install.py for a time/zone value of America/New_York
[19:50] <cr3> actually, specifying US/Eastern seems to work
[19:57] <evand> American/New_York should work.  Are you certain you entered it correctly?
[19:58] <evand> the timezone_apply code is really simple
[19:58] <evand> err America/New_York ;)
[22:45] <cjwatson> cr3: need the full logs for that kind of error, the traceback alone tends to be uninformative
[22:58] <cr3> cjwatson: ok, I'll try to reproduce again this weekend. I'm really looking forward to having live cd images tested automatically before Monday