What manages /etc/passwd?

[pjz]

Should /etc/passwd, /etc/shadow, /etc/group be in my filetool.lst or not?  I ask because the following is happening and I'm not sure how to fix it:

sce-import -b transmission-daemon
grep transmission /etc/passwd [ => '' ]
sce-load transmission-daemon
grep transmission /etc/passwd [ => debian-transmission:x:101:103::/var/lib/transmission-daemon:/bin/false ]
sudo reboot
...
... 30+s later, after login ...
...
grep transmission /etc/passwd [ => '' ]

so... is it my fault for not putting /etc/passwd into my .filetool.lst, or should the sce-load at boot-time (or whatever happens to the sces listed in sceboot.lst) be putting the debian-transmission entry into /etc/passwd?

[pjz]

...is this the right place to ask this? or is there a bugtracker somewhere?

[Rich]

Hi pjz
If you want changes made to those files to persist, they need to be added to  filetool.lst.

[pjz]

...usually, sure, but in this case *I'm* not the one making those changes - the `sce-load` of the package is.  So do *I* need to persist it, or should the `sce-load` that's happening at boot-time be doing it?  If I need to do so then IMO /etc/passwd and /etc/group should just be added to the `.filetool.lst` by default since the packages will refuse to work unless they're persisted.  Or maybe the boot-time `sce-load` (which is somehow different from manually doing `sce-load`) should be making those changes?  Hence my question.

[Jason W]

In this case, if transmission is not adding it's needed user every time the extension is loaded, then the issue is the startup script needs to be fixed so that it does, not that files in /etc need to be backed up.

[pjz]

It does seem to be boot-time specific; if I sce-import transmission-daemon then reboot and manually do sce-load transmission-daemon, /etc/passwd is correctly updated.

[Jason W]

I tried booting and noticed the same, the startup script itself seems to be ok.  There is an issue in processing startup scripts while booting, I will do some investigating and try to fix it today.

[Jason W]

It is not the path in tce-setup, nor missing deps, nor that startup script not being put in the queue to be run on boot.  I will keep looking for a solution.

[pjz]

Presuming that the startup stuff ends up doing some variant of:

for f in `cat $TCEDIR/sceboot.lst` ; do
    sce-load $f
done

then it seems likely to me that that's being done before something is set up/initialized during boot... or later?  I tried putting a loop like the above into my bootsync.sh and it still didn't modify /etc/passwd... are some permissions or something perhaps just not ready? or is /etc/passwd being trampled by something even later in the process?

[pjz]

Also, as a datapoint, the openssh-server sce *does* correctly add an sshd user to /etc/passwd.  Is it using a different mechanism to do so than transmission-daemon?

[Jason W]

Thanks for that observation, I will look and see what the difference is.

EDIT:  Turns out that I put in a custom adduser/addgroup command set in there to make it work.  So that is the angle I will approach transmission-daemon.  Sometimes we just have to create a custom startup script, like with things we compile ourselves.

[pjz]

Ugh; custom work isn't what you want, given the scope of the debian repositories; most daemons get their own user to run as (for security) instead of root.  Is there no way to hook into the debian package machinery?

[Jason W]

Custom meaning on our server, transparent to the user.

But I think I found the issue and it involves perl, I will post results soon.

[Jason W]

Using a dCore custom startup script simply achieves what the Debian one aims at, if a daemon is added as it's own user, then that is what our script will add it as.  It will not run as root, we are not a run as root distro.  I have made some progress into seeing why adduser works in a running session but not during boot.  At worst, the debian-transmission user will be added by us in the same way as by Debian or any other distro.

I have 1250 packages installed on my machine, and ony 5 have adduser in their Debian startup script.  So it is possible for us to tweak those scripts if necessary.

[pjz]

Oh, you mean supplying a custom 'adduser' ; I thought you meant a custom 'add a transmission-daemon user/group' script.  I misunderstood, and definitely agree with your approach