On Wed, Jan 01, 2014 at 08:53:51PM -0800, Russ Allbery wrote: > I've been taking a look at this bug because I care a lot about #581899 > getting fixed. I've reviewed the bug logs of both this bug and #143437.
Thanks for looking at this! Note, in case it helps and I haven't already mentioned it, that base-passwd is now revision-controlled using git (http://anonscm.debian.org/gitweb/?p=users/cjwatson/base-passwd.git); I mention that since I only uploaded the change of Vcs-* fields yesterday. > Unfortunately libdebconfclient doesn't appear to be particularly > well-documented (at least, I didn't find anything except header files, > which mostly don't even have comments). Is there anything needed here > other than calling debconfclient_new() and then calling > debconf_register(), debconf_subst(), debconf_input() and client->ret() as > needed, and then debconfclient_delete() when update-passwd is done? It's a pretty thin layer over the debconf protocol. That sounds right. > I think this would require finding all the places in the code that make > updates and have them call to a prompting routine, which would need to > instantiate questions from a template using REGISTER. And to do this > properly, all of those questions are going to need to encode the actual > change that would be made so that a previous answer doesn't inadvertantly > answer an unrelated question. Indeed. (It would also be possible to reuse a smaller number of questions and forcibly reset them, but I think that's much less good than dynamically registering questions for each thing that might have a different answer.) > The thought that I had on how to handle the question naming problem was to > name the questions after the substance of the change, so proposed changes > like: > > Changing gid of sync from 100 to 65534 > Changing gid of games from 100 to 60 > Changing gid of man from 100 to 12 > Changing GECOS of list from "SmartList" to "Mailing List Manager". > Changing home-directory of nobody from /home to /nonexistent > Adding group "man" (12) > > would become questions: > > base-passwd/system/user/sync/gid/100/65534 > base-passwd/system/user/games/gid/100/60 > base-passwd/system/user/man/gid/100/12 > base-passwd/system/user/list/gecos > base-passwd/system/user/nobody/home/home/nonexistent > base-passwd/system/group/man/add This seems reasonable. > In other words, the question naming scheme would start with base-passwd > (of course), and then the following fields in order: > > target "system" for regular files, "other" if -P or -G given > type "user" or "group" > name The identifier of the user or group affected > action One of the following: > - "add" to add this user or group > - "remove" to delete this user or group > - "uid" to change the UID of a user > - "gid" to change the GID of a user or group > - "gecos" to change the GECOS > - "home" to change the home directory > - "shell" to change the shell > > Then, for any action other than "add" or "remove", the next two fields are > the old and new values. For home directory and shell, this is basename() > of the values. That will probably be sufficiently unique in practice to > not pose major issues. (Alternately, we could map "/" to "_" if you'd > prefer.) I'd probably go with mapping to "_". Just be careful to sanitise input, as some of the data comes from the current system state and not necessarily from {passwd,group}.master; I think it's fairly crazy to set a system user's home directory to something containing a space, say, but it's possible and it shouldn't cause update-passwd to break the debconf protocol if the sysadmin has done that. > As an exception, I would omit the old and new values for GECOS and use the > same question and the same preseeded answer for all GECOS changes. I > think the user is likely to either approve of GECOS changes for that user > in general or not want it changed at all. I doubt there is any real > benefit to prompting for each different change. Agreed. That probably also implies that there's no need to reset that question's seen flag. > Note that this produces the same question identifiers for any non-system > files, which isn't ideal, but since you mentioned that this would probably > only be used for testing, I'm inclined to avoid any unnecessary complexity > there. Right. I wouldn't actually expect people to use the debconf protocol in that case. > I think question coalescing is going to be quite difficult without > basically rewriting the whole control flow of update-passwd, so I'm > inclined to bail on that. Similarly, while it would be nice to support > backing up in the questions, it looks like quite a lot of work. Agreed. We can always do this later if need be. > Over time, in theory, this could result in a fair number of debconf > database entries. But given how few changes there have been to > base-passwd in practice, I'm inclined to not worry about it. Yes. Some of that is because I've been holding off changes due to this bug, of course, but even accounting for that it's not going to be a particularly excessive list. > Obviously, debconf prompting would be controlled by a new --debconf > command-line flag. Consider, perhaps, checking for the DEBIAN_HAS_FRONTEND environment variable instead. > Does this sound like a reasonable implementation approach? Absolutely. Thanks again for taking this on. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
