|In data giovedì 02 aprile 2009 08:35:14, Sébastien Masset ha scritto:|
> First of all, I would like to apologise to the mailing list subscribers
> if they've already received this (and some others) message but this is
> the third time I've tried to send it and I'm yet to see it posted on the
> message board. I hope this one will make it.
I just received 1 copy of it.
>> I took a quicj look at the patch and it seems harmless to me,
>> although for this level of details on the target live system I would
>> prefere to preconfigure the live system at build time adding my users
> I'm also pretty sure live-initramfs would fail to *add* a live-user at
> boot time if you have already created any user with 1000 as uid at build
> time. It would take that user and use it as *the* Live User
Yes, but only if "nouser" is not passed at bootime or $USERNAME user is not already present. Both things can be already handled.
> >My question is: which is the use case for this patch?
> As I explained in my first mail, I've encountered issues with a package
> that creates a user in the user range instead of the system range. When
> booting live-initramfs fails to add the Live User because the 1000 uid
> is already used.
This was a badly wrote package as Daniel stated before, but...
> As it seemed easier to change the uid live-initramfs
> than repackaging that other package, I tried (and failed) to change the
> hard coded 1000 uid value in the adduser script. I thought I'd try the
> boot parameter route to see if it would work.
You could manage to fix the package installation via a live helper hook (./config/chroot_local-hooks) which could fix user uid to a system one by deleting, recreating the user and chowning some files probably. This could be even easier that repackeging your broken software or trying to have an untested patch which probably do not work (as in "I tried (and failed) to change the hard coded 1000 uid value in the adduser script" before) that resolve a use case caused by a broken package.
> I'm currently reading some documentation on debian packaging to package
> and test my patched version of live-initramfs. Any help with that would
> be appreciated.
I suggest again to leave this path (or to provide some saner use cases after testing the patch yourself) and get the job done by a hook.
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.