| CIA-4 | installation-guide: cjwatson * r460 ubuntu/debian/ (archlist changelog control): Disable building for hppa, since it's EOL. | 00:11 |
|---|---|---|
| rgreening | evand: well, I keep trashing my usb stick :) progress I guess .. haha | 00:17 |
| === rgreening_ is now known as rgreening | ||
| purplefool | hi, was bedeutet 'writelines() argument must be a sequence of strings'? wie kann ich das korregieren? | 09:07 |
| _ruben | this is an english channel, and where are you seeing that? | 09:08 |
| 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:09 |
| 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:10 |
| 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:12 |
| * 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:14 |
| purplefool | oh...sorry...here it is: http://paste.ubuntu.com/199025/ | 09:15 |
| 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:17 |
| cjwatson | wubi's tasklist.error exception handling doesn't preserve the traceback position unfortunately | 09:18 |
| purplefool | that was english...but i have no idea what it means. it sounds like the problem wasn't recoreded. | 09:19 |
| purplefool | why is the cd checking all the other drives for information? is that normal? | 09:21 |
| 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:22 |
| 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:26 |
| purplefool | ok, still get r129 with my download...btw, r136 is revision, correct? | 09:29 |
| cjwatson | yeah | 09:29 |
| cjwatson | http://people.ubuntu.com/~evand/wubi/karmic/wubi-r136.exe is a current build, but probably not signed | 09:30 |
| 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:31 |
| 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:33 |
| 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:34 |
| 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:36 |
| 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:37 |
| xivulon | cjwatson the full path is due to the byte-compilation stage | 09:38 |
| xivulon | via pypack | 09:39 |
| xivulon | ehm pylauncher | 09:39 |
| xivulon | src/pylauncher/pack.py > compile | 09:41 |
| xivulon | I guess py_compile.compile -> dfile argument will do ? will have a second look later | 09:44 |
| xivulon | have to go now | 09:45 |
| mpt | "When installing, the keyboard layout suggestion should be based on the time zone chosen." | 10:33 |
| mpt | It already is, right? | 10:33 |
| 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:37 |
| cjwatson | mpt: it depends. It's based on a combination of language and country. | 10:44 |
| cjwatson | Being in Portugal does get you a Portuguese keyboard by default though, as far as I can see. | 10:45 |
| evand | shtylman: if you're done editing, can you please mark your spec as "Review"? | 11:31 |
| 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:47 |
| xivulon | ah that is interesting | 11:49 |
| xivulon | by the way created 389424, will patch later on tonight, thanks cjwatson | 11:50 |
| cjwatson | cool, ta | 12:03 |
| 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:38 |
| evand | sure thing, I think mterry is willing to work on it as part of the oem-config specification | 14:39 |
| 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:40 |
| shtylman | evand: will do :) thanks | 14:41 |
| rgreening | evand: you have a chance to look over the recent changes to usb-creator? | 14:46 |
| evand | indeed, looked it over last night. It looks okay, feel free to merge that in | 14:48 |
| 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:49 |
| 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:51 |
| * rgreening wondered why my stick kept running out of space | 14:52 | |
| rgreening | :P | 14:52 |
| evand | heh | 15:02 |
| evand | my fault, I must've screwed up the merge into trunk at UDS | 15:03 |
| rgreening | lol | 15:43 |
| rgreening | np, I'll up my changes later today. gotta go buy a fathers day gift... | 15:44 |
| kirkland | cjwatson: hiya, i'm still looking for some feedback on that /var/lib/ecryptfs issue | 16:54 |
| 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 | 16:55 |
| 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:28 |
| 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:29 |
| * 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:30 |
| kirkland | cjwatson: encrypted private are unaffected | 17:31 |
| cjwatson | right, of course | 17:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| kirkland | cjwatson: good call | 17:36 |
| kirkland | cjwatson: didn't know that was around | 17:36 |
| cjwatson | [ ... -a ... ] => [ ... ] && [ ... ] for portability | 17:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| cjwatson | readlink -f canonicalises those away | 17:43 |
| kirkland | sweet, thanks. | 17:43 |
| 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:44 |
| 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:45 |
| cjwatson | LINK="$(readlink "/home/.$PKG" | sed 's,/*$,,')"; if [ "$LINK" = "/var/lib/$PKG/$USER" ]; then ... fi | 17:46 |
| 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:47 |
| 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:48 |
| kirkland | cjwatson: okay | 17:49 |
| 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:50 |
| cjwatson | dash(1) is a lot less clear but I think that is standard behaviour | 17:51 |
| kirkland | <cjwatson> mkdir -m 600 -p, just in case | 17:51 |
| cjwatson | err, that was somewhere up above, ecryptfs-setup-private I think | 17:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| cjwatson | oh, well, one was a misreading on my part, I read $HOME as /home | 17:57 |
| cjwatson | (sigh) | 17:57 |
| 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:58 |
| 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 | 17:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:27 |
| 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:28 |
| 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 | 18:29 |
| cr3 | hi folks, I'm getting a TimezoneApply error raised in ./scripts/install.py for a time/zone value of America/New_York | 19:32 |
| cr3 | actually, specifying US/Eastern seems to work | 19:50 |
| evand | American/New_York should work. Are you certain you entered it correctly? | 19:57 |
| evand | the timezone_apply code is really simple | 19:58 |
| evand | err America/New_York ;) | 19:58 |
| === kirkland` is now known as kirkland | ||
| cjwatson | cr3: need the full logs for that kind of error, the traceback alone tends to be uninformative | 22:45 |
| 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 | 22:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!