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