Tiny Core Linux
dCore Import Debian Packages to Mountable SCE extensions => dCore X86 => Topic started by: pjz on October 03, 2015, 12:13:40 AM
-
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?
-
...is this the right place to ask this? or is there a bugtracker somewhere?
-
Hi pjz
If you want changes made to those files to persist, they need to be added to filetool.lst.
-
...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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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?
-
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.
-
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?
-
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.
-
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.
-
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 :)
-
I am still looking into this. It seems that busybox adduser also does not add the user on boot just as the full version of adduser does not. Where the same command once booted works.
-
Is there a way to pull log files out of sce-load? Maybe turn on -x to at least see the error?
-
I am still at a loss as to why this one package does not add a user like others are able to with the same routine.
I am working on sce-load (tce-setup during boot) to recognize the "debug" boot command line option. There is the -d option in sce-load, but that is not good for boot as a backed up /etc/sysconfig/sceconfig is not restored until after the exntensions are loaded.
-
If you want to verify it's a general problem and not particular to transmission-daemon, some other packages fail for me similarly: minidlna (though it can be worked around by changing the 'run as user' setting in /etc/defaults/minidlna) and (I think) rygel.
You said you put in custom adduser/addgroup for openssh - if you get a generic solution working, that would be removable, so something else to potentially test with.
-
Ok, sceconfig in tcedir makes sense.
Uploaded new release candidate with debug option at the boot command line. It does not specifically point out what is happening with transmisison-daemon and adduser. All other packages that have busybox adduser works right during boot, just transmission does not.
I will look into minidina.
-
On further thougnt of sceconfig being in tcedir, that makes it difficult to ship a default file, without using scripting or similar to copy it over. So I would rather leave it in /etc/sysconfig. However, I will add it by default in /opt/.filetool.lst.
-
Hi
I'm trying the "debug" boot code and the system hangs on "pulseaudio" while processing all the packages in alphabetic order.
Removing pulseaudio-module-x11 makes dCore continue without hanging.
Made a lonely pulseaudio-module-x11 sce without deps and booting, having only it in sceboot makes the system hang with the "debug" boot code.
Made a basenopulse sce the system boots with debug and I can now see the sce.log which is attached to this post.
Another thing:
I wanted to see if connmand was started, so I typed ps but:
with "norestore" boot option ps doesn't show me all the running processes, I have to type ps -fe, while without "norestore" I can see all the processes just typing ps.
Even sce.log reports that connman is started I don't see it as a running process.
Thanks
-
I forgot to mention to use "sce-update -a" before testing the debug option as I fixed pulseaudio before making the release candidate cut.
What we are seeing with ps seems to be Busybox ps - full output with just the ps command - and the standard version of ps. I have noticed this on my box for a while and will try the norestore option and see if I can find what is happening.
-
Using norestore did not make a difference here, but just using the "ps" command does not show all running processes in a Ubuntu hard drive install, it is just the standard ps behavior.
-
Any progress on the user-creation-at-startup issue?
-
Please explain, we are dealing with startup scripts that are built in to the packages.
-
You'd said:
>I am still at a loss as to why this one package does not add a user like others are able to with the same routine.
And I was wondering if you'd made progress on that issue yet, is all.
-
Ok, I see. No, no progress, now focusing on recovering from the server outage.