[12:18] <allmanj> hey - i've been asked to modify the ubuntu installer to create a second user (without sudo privileges) and prompt for a password
[12:19] <allmanj> i'm thinking i can somehow get this into the main menu, hopefully by dropping a script of some type in somewhere and not by creating a udeb (but if this is the preferred method i guess i can do this)
[12:19] <allmanj> unfortunately i can't really find how to do this. any hints appreciated...
[12:28] <cjwatson> allmanj: do you need UI for it?
[12:29] <cjwatson> oh, you said prompt
[12:29] <cjwatson> allmanj: prompting without a udeb is difficult because there's no other easy way to get templates in; the only way you can prompt without a udeb is if you can somehow arrange to reuse an existing template
[12:30] <cjwatson> allmanj: is the username fixed?
[12:31] <allmanj> the username is fixed, yes
[12:31] <allmanj> can i not use something like debconf-loadtemplate?
[12:33] <cjwatson> no, doesn't work properly
[12:33] <cjwatson> trust me on this, it's complex :-)
[12:33] <allmanj> :( dang!
[12:33] <cjwatson> you're not sunk, though
[12:34] <allmanj> oh?
[12:34] <cjwatson> if the username is fixed, then the existing user-setup text should work reasonably well?
[12:34] <cjwatson> unless you need extra text?
[12:34] <cjwatson> _Description: Choose a password for the new user:
[12:34] <cjwatson>  A good password will contain a mixture of letters, numbers and punctuation
[12:34] <allmanj> no - i just need to make sure it's clear that the first time it prompts for a password it's for the first user, and the second time, for the second user
[12:34] <cjwatson>  and should be changed at regular intervals.
[12:34] <cjwatson> hmm, ok, you might need extra text then
[12:35] <cjwatson> I think you will have to create a ueb
[12:35] <cjwatson> udeb
[12:35] <cjwatson> you can't get stuff onto the main menu without a udeb anyway, so ...
[12:36] <allmanj> :( i assume i can store it on the cd and load it during startup. So, not modify the initrd?
[12:36] <cjwatson> yeah, any udeb that's Priority: standard or higher is automatically loaded at anna time; you definitely shouldn't modify the initrd for this
[12:36] <cjwatson> it just needs to be in the proper Packages files
[12:37] <allmanj> yep - i've already modified the packages on the cd and regenerated the Packages file so i'm happy with that
[12:37] <cjwatson> are you comfortable with creating a udeb, or do you need help?
[12:37] <allmanj> i'll have a go at creating a simple udeb. I may need a little help though as i suspect i'll get stuck...
[12:38] <cjwatson> whereabouts do you want it to go in the menu? immediately after user-setup?
[12:38] <allmanj> cjwatson - that would seem sensible i think?
[12:39] <allmanj> this seems to have some basic info on creating a udeb: http://people.debian.org/%7Efjp/talks/debconf6/paper/
[12:39] <cjwatson> I'd suggest cloning-and-hacking user-setup, radically simplifying it (you can chuck out loads of stuff), and making your udeb Depends: user-setup-udeb
[12:39] <cjwatson> yes, that's a good paper to read
[12:39] <allmanj> good call - i'll try that
[12:39] <cjwatson> you can then just use the same installer-menu-item number as user-setup and let the Depends break the tie for menu ordering
[12:39] <allmanj> any easy way for me to test my udeb without putting it on the cd and doing an install?
[12:42] <stgraber> Here I use an emulator like vmware or qemu, but maybe there is an easier way when testing only debian-installer (I'm testing a complete custom CD)
[12:42] <cjwatson> if you speak the debconf protocol to some basic extent, you can at least test the debconf interaction
[12:42] <cjwatson> DEBIAN_HAS_FRONTEND=1 ./script
[12:42] <cjwatson> and then you can type answers at it in the debconf protocol
[12:44] <cjwatson> it's also possible to set up a slightly more elaborate test environment by installing the cdebconf package and pointing /etc/cdebconf.conf at your own database, which you can then /usr/lib/cdebconf/debconf-loadtemplate into
[12:45] <cjwatson> I usually don't bother with that, but I have a bit more experience with what tends to break udebs so I can get away with shortcutting some things
[12:46] <allmanj> i'll see how i get on with putting it on the cd and testing it with vmware, but if i have to keep doing it i'll try the cdebconf thingy
[12:47] <allmanj> i quite possibly will be back in the not-too-distant future sobbing uncontrolably
[12:47] <cjwatson> if you have the CD creation automated, vmware testing will probably be reasonably efficient at least for testing the early phase of your udeb that runs before base-installer
[12:47] <allmanj> and if there's an error with my udeb it'll freak out
[12:47] <cjwatson> but package installation takes a while even in vmware so if you're relying on that make sure that the user creation script (that you've borrowed from user-setup-apply) is pretty solid
[12:49] <cjwatson> note that you'll need to rename the debian-installer/user-setup-udeb/title template according to the name of your udeb, and the finish-install/progress/user-setup template according to the name of your finish-install script
[12:50] <cjwatson> one day we should probably embark upon a project of making d-i a bit more customiser-friendly ...
[12:52] <allmanj> i second the motion!
[01:19] <allmanj> i assume i only need the udeb. The user-setup source package appears to create a deb and a udeb
[01:26] <cjwatson> yes
[01:27] <cjwatson> the .deb's mostly for ubiquity
[01:28] <allmanj> thanks. i've just created a clone of user-passwd (renamed package name and all scripts and template variables) so perhaps i'll get lucky and it'll just work...
[01:51] <allmanj> i've forgotten how i force it to load an additional udeb.  anna-choose_modules or something?
[01:55] <cjwatson> you shouldn't need to force it if you use Priority: standard
[01:55] <cjwatson> but it's anna/choose_modules=blah
[01:56] <cjwatson> (modules=blah in feisty)
[01:56] <allmanj> and that'll add it to the default list - it won't replace it?
[02:04] <cjwatson> there's no default value for anna/choose_modules - it's only for extras
[02:24] <allmanj> it's looking good. booting into system now - we'll see if it set both passwords appropriately
[02:26] <allmanj> only seems to have created the second user in my modified user-setup:(
[02:27] <allmanj> it prompted twice for passwords (4 including verify) but only appears to have created one user
[02:28] <cjwatson> you need to not use the same templates
[02:28] <cjwatson> or rather you need to rename them
[02:29] <cjwatson> otherwise you'll clobber state saved by user-setup-ask for user-setup-apply
[04:02] <allmanj> i did rename them?
[04:06] <cjwatson> perhaps you clobbered user-setup's finish-install script by mistake?
[04:06] <cjwatson> it definitely sounds like something clashed
[04:16] <allmanj> hmm. that's possible. though i thought i renamed files. will double check - cheers
[04:18] <allmanj> no file name clashes that i can see
[04:19] <allmanj> actually... let me double check taht
[04:21] <allmanj> dpkg -c certainly reveals no clashes
[04:30] <cjwatson> try booting with DEBCONF_DEBUG=5 to get a full debconf trace - will be somewhat tedious to read but will almost certainly tell you (in syslog) what's going on
[04:30] <allmanj> i'm going to need it not to reboot so i can grab the logs. any simple way to do that?
[04:38] <cjwatson> either don't preseed finish-install/reboot_in_progress, or just grab /var/log/installer/syslog after reboot (it's copied across)
[04:40] <allmanj> ah - i didn't realise it was copied. thanks
[05:16] <allmanj> looking at relevant section of syslog now. can see it reading in passwd/user-password...
[05:17] <cjwatson> that's what user-setup uses
[05:18] <allmanj> yep - going on now to see where it read in the other values...
[05:20] <allmanj> i can see it reading in the other values dta-passwd/user-password
[05:20] <allmanj> both then say ON STATE from 1 to 8
[05:21] <allmanj> so i think it's populating the debconf database correctly at least...
[05:22] <allmanj> see it running the prebaseconfig from the modified package...
[05:24] <allmanj> and now i see it (at least starting) to run the prebaseconfig from user-setup
[05:25] <allmanj> hmm - so it ran the modified one first...
[05:26] <allmanj> it runs the script but doesn't create the user...
[05:27] <allmanj> so i see dta-passwd/make-user, returns true then it GETs dta-passwd/user-password-crypted
[05:28] <allmanj> but after passwd/make-user (which returns true) it goes to PROGRESS STEP 1 and then moves on to another prebaseconfig script...
[05:32] <cjwatson> it runs them in lexicographical order
[05:33] <cjwatson> bump the number or prepend a z to the name or something if you want it run afterwards (you probably do)
[05:34] <allmanj> well, it shouldn't make a difference which user is created first (in theory). However for some reason the user-setup one seems to skip user creation. The script gets run but it just goes to the next script after reading passwd/make-user (which is true)
[05:36] <allmanj> looking at the apply script...
[05:36] <allmanj> is_system_user
[05:36] <allmanj> could that be my problem?
[05:37] <allmanj> ah - that is indeed it. # Assume NIS, or any uid from 1000 to 29999,  means there is a user.
[05:37] <allmanj> so if i make my one run after and skip the is_system_user check i should be ok
[05:37] <allmanj> i think
[05:39] <cjwatson> oh, right, sure, that's a piece you should remove from your script
[05:39] <cjwatson> you basically just want to use adduser
[05:49] <allmanj> i've been as lazy as possible and barely touched user-setup. removed bits i think will interfere now and trying again...
[06:25] <allmanj> looks like i got it! thanks for the help!
[06:29] <cjwatson> np, glad it worked