Thank you to everyone, all of the responses contained ideas that
guided me towards a successful outcome.
First, it was clear that nobody advocated trying to control the order
that the packages were installed in.
The suggestion by James Richardson to create users/groups before
installing the packages was a better solution that hadn't occurred
to me.
The various pointers to the docs got me reading them again, more
carefully.
The suggestion by Max Hyre to clone passwd, shadow, group, & gshadow
seemed like the easiest method to achieve it. Thanks for the reminder
about *shadow, I would have forgotten it and made a mess! Joe also
supported this approach.
The observation by Andrei Popescu, that packages don't remove system
users on purge, boosted my feeling that this could work.
I worried that package install scripts might have some subtle breakage.
Also then, I was incorrectly reading 'man useradd' which documented
exitstatus=9 if the user already exists and it wasn't clear if this was
disabled by --system. I should have been reading 'man adduser' instead
which is less alarming.
So the first thing I tried was a test to check this. I chose the
already installed 'approx' package as an example:
# grep approx /etc/passwd
approx:x:102:104::/var/cache/approx:/bin/false
It has this in its postinst script:
adduser --quiet --system --group --no-create-home --home
/var/cache/approx approx
So in a terminal I tested:
# adduser --quiet --system approx
# echo $?
0
which confirmed no need to worry about adduser exitstatus.
The ideas from 'paul e condon' and Gilles Mocellin on how to use
aptitude to generate a list of packages and then feed that list back
to aptitude were brilliant. I ended up doing it like this:
# aptitude --disable-columns -F "%p=%V" search '~i!~M' >package_list
# edit package_list for different xorg drivers
# aptitude -R install $(cat package_list)
That last line was run on a bare minimum wheezy netinstall. It seems
to have worked perfectly on the test system. The additional system
users created by my package selections were
sshd,approx,messagebus,dnsmasq,festival,pulse,usbmux,lightdm,saned.
The only thing I have noticed that needed a fix afterward is that
lightdm would not start:
# cat /var/log/lightdm/x-0-greeter.log
Error writing X authority: Error opening file
'/var/lib/lightdm/.Xauthority': No such file or directory
The reason is the homedir /var/lib/lightdm was never created, due to
the postinst script being written like this:
$ cat /var/lib/dpkg/info/lightdm.postinst
#!/bin/sh
set -e
[...]
# creating lightdm user if he isn't already there
if ! getent passwd lightdm >/dev/null; then
adduser --system --ingroup lightdm --home /var/lib/lightdm lightdm
usermod -c "Light Display Manager" lightdm
usermod -d "/var/lib/lightdm" lightdm
usermod -g "lightdm" lightdm
usermod -s "/bin/false" lightdm
fi
if [ -d /var/lib/lightdm ]; then
chown -R lightdm:lightdm /var/lib/lightdm
chmod 0750 /var/lib/lightdm
fi
[...]
It was obviously easy to fix this:
# mkdir -p /var/lib/lightdm
# chown -R lightdm:lightdm /var/lib/lightdm
# chmod 0750 /var/lib/lightdm
None of the other packages mentioned above had this issue. Either
they have 'adduser --no-create-home', or they do not adduser or
create homedir in their postinst.
Thanks again for the help. Now I know how to get my all the numeric
uid/gid the same on all my personal machines, which I find useful.
Also, doing things out of the ordinary is a great way to learn - even
if sometimes the only thing you learn is why no-one else does it that
way :)
On 9 June 2013 15:23, Chris Bannister <cbannis...@slingshot.co.nz> wrote:
> On Thu, Jun 06, 2013 at 10:52:25PM +1000, David wrote:
>> On 06/06/2013, Andrei POPESCU <andreimpope...@gmail.com> wrote:
>> > On Jo, 06 iun 13, 14:39:22, David wrote:
>> > For my curiosity, could you please provide an example where *system*
>> > users need to be synchronized between different machines?
>>
>> Hi Andrei
>>
>> Each machine has multiple OS root partitions managed by grub1,
>> each with /usr and /var. There is a different home dir for each OS with
>> its own dotfiles (lets say that to keep this story simpler), but most of
>> my work data files are bindmounted under it from a common data
>> partition.
>> For example, I might want to play with a http server, that I could run on
>> any machine, but it would have data available from the synced data
>> partition. Another possible candidate would be dnsmasq.
>
> Sounds like a job for ssh! ??
>
> Each machine could then be "headless" then use your most portable
> machine as display and keyboard?
>
> virtual machines to test out another OS
>
> There must be a particular reason why you have decided to do things that
> way. I would be interested to know what that reason is.
>
> --
> "If you're not careful, the newspapers will have you hating the people
> who are being oppressed, and loving the people who are doing the
> oppressing." --- Malcolm X
>
>
> --
> To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/20130609052302.GD6677@tal
>
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAMPXz=p8f6zseqf2jwynqch7yg1qmluov1pe_706wohcgru...@mail.gmail.com
