ondemand logic

[Roberto A. Foglietta]

Hi all,

I am developing a suite to customize a TC USB/ISO disk [1], At the moment I put every tcz in a folder named tcz and I load it at startup.

However I wish to use the standard tce folder but I have one problem in using optionals / onboot.list.

I put all tcz in tce/optional then I put in ondemand.lst the package with its dependecies. Then I do:

tc@box:~$ sudo unlock.sh
/mnt/sda1 (RW)
/mnt/sda2 (RW)

tc@box:~$ sudo ondemand wget.tcz

tc@box:~$ wget
BusyBox v1.33.0 (2021-01-17 14:57:11 UTC) multi-call binary.

tc@box:~$ /usr/local/bin/wget
-ash: /usr/local/bin/wget: not found

tc@box:~$ ondemand -e wget.tcz
tc@box:~$ wget: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

tc@box:~$ sudo ondemand libssl.so.1.1.tcz

tc@box:~$ ondemand -e wget.tcz
tc@box:~$ wget: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

The library is still missing. How I can manage the load of executable and its dependencies? Thank you, R.


[1] https://github.com/robang74/tinycore-editor

[Juanito]

Why not use tce-load?

[curaga]

That looks like your dir is missing the .dep files.

[nick65go]

... How I can manage the load of executable and its dependencies? Thank you, R.

The logic of recursively build the dependencies of dependencies, is in the script /usr/bin/tce-load, at subroutine/function recursive_scan_dep(), called with parameter "$TARGETSFETCH", etc. It is written in awk language.

[Roberto A. Foglietta]

Thank you Juanito, nick65go and curaga.

Just another question: why tce-load does not fall-back to tc.staff when executed by root?

[nick65go]

Just another question: why tce-load does not fall-back to tc.staff when executed by root?

IMHO: it can be easy done; but why are you so sure that $USER = tc ?
 On booting you can choose to create a user (default is tc), but if you choose user = roberto (lets say!) then the user "tc" does not exist in this tinycore system.

[Roberto A. Foglietta]

Just another question: why tce-load does not fall-back to tc.staff when executed by root?

IMHO: it can be easy done; but why are you so sure that $USER = tc ?

It is irrelevant the name of the user. $SUDO_USER might help or not but the uid=1001 remains the same

In attachment the code, I cannot post here because a forum bug about config error.

[Roberto A. Foglietta]

In attachment an example of tce-load working as root falling back to uid=1001 user.

You can test making an ISO with the last version of TinyCore Editor (suite)

https://github.com/robang74/tinycore-editor

[nick65go]

nice catch, so you run (as root) your new function getuser ( ) , from file / etc / init.d / tc-functions, to change on the fly the tc user string from / etc / passwd    
So basically the same "user ID", not another user, aha!

PS: i get many internal server errors when I try to post, so i must use space between  "/" and "(" <-- maybe a server bug

[Rich]

Hi Roberto A. Foglietta

... Just another question: why tce-load does not fall-back to tc.staff when executed by root?

Because it doesn't need to. It aborts if you try to run it as root:

Code: [Select]

tc@box:~$ sudo tce-load
Don't run this as root.

It is irrelevant the name of the user. $SUDO_USER might help or not but the uid=1001 remains the same ...

Really? I'm pretty sure user  tc  with  uid=1001  is built into the base system. If you select another user, that user
gets assigned their own  uid.

Since the  tce  directory is a shared resource amongst all users, I would say  read/write  permission for  staff  is
what's important since all users should belong to that group.

[nick65go]

why not short-hand it as:

Code: [Select]

[ uuid == 0 ] && USER=`sed...`

[Roberto A. Foglietta]

It is irrelevant the name of the user. $SUDO_USER might help or not but the uid=1001 remains the same ...

Really? I'm pretty sure user  tc  with  uid=1001  is built into the base system. If you select another user, that user
gets assigned their own  uid.

Since the  tce  directory is a shared resource amongst all users, I would say  read/write  permission for  staff  is
what's important since all users should belong to that group.

So, the most important thing is to use an user that belong to the staff group, is it right?
It does not matter that it matches with the current user as long as belong to staff.
Because all users should belong to staff group, is it right?

[Rich]

Hi Roberto A. Foglietta

... It does not matter that it matches with the current user as long as belong to staff.
Because all users should belong to staff group, is it right?

That would be my understanding of it. If you look at the  addUser  function in  /etc/init.d/tc-config  it sets the group
to  staff  for every user added. So if I add user  Rich  to my system, I'll still be able to load extensions installed
by user  tc.

[nick65go]

I wonder if a solution will be like this: start tce-load (as root user, by mistake), and the first instruction inside it will check for $user=root, and in this case just "re-lunch it" aka

Code: [Select]

sudo -u tc -exec ($@). So basically all remaining instructions are ignored and it starts again as user tc.

PS: I do not know the implication for cache /memory.

[Roberto A. Foglietta]

Hi Roberto A. Foglietta

... It does not matter that it matches with the current user as long as belong to staff.
Because all users should belong to staff group, is it right?

That would be my understanding of it. If you look at the  addUser  function in  /etc/init.d/tc-config  it sets the group
to  staff  for every user added. So if I add user  Rich  to my system, I'll still be able to load extensions installed
by user  tc.

So, my patch seems working, as far as we know.
Who we need to involve to evaluate to integrate my changes?
Thank, -R