woof-CE: sandbox.sh official and modified versions

[s243a]

Call for testers
sandbox.sh has been broken in puppy for a while but should be fixed now. It is useful tool for building packages and testing applications.

The commit that likely fixed sandbox.sh was:
fix sandbox.sh & sandbox-rw.sh #1739

You can read about sandbox.sh at:
http://distro.ibiblio.org/fatdog/web/faqs/sandbox.html

and as I note, it now should work on puppy but requires further testing before we can close "Issue #1737"

We need testers to test how well sandbox.sh works with different pup modes. To test it replace the sandbox.sh on your system with the one from the latest woof-CE testing branch.

rootfs-skeleton/usr/bin/sandbox.sh
rootfs-skeleton/usr/bin/sandbox-rw.sh


Non Official Modifications (not ready yet, so I strongly recommend not testing these mods yet)

For me further testing of standbox.sh is on the back burner because I'm working on some non-official modifications of sandbox.sh which add considerably more features to it. The reason, is that I want to be able to mount a puppy in a sandbox that is different than the one I'm currently running.

I'be been struggling with the code a bit the last few days but I finally have code that appears to create a sandbox from multiple layers of an external puppy:
sandbox_s243a-debug4.sh
sandbox.awk

This was my test command:

Code: Select all

bash -x /usr/bin/sandbox_s243a_debug4.sh -f ~/sandbox.out -o ~/sandbox.out --maybe-psubdir "Tiny_Puduan/PreAlpha11.4" --no-exit

Note that the original sandbox.sh does not nave any of these command line options / switches but I'll explain them.

Code: Select all

-f 
  input file
-o 
  output file
--maybe-psubdir
  get the layers from a given sub directory if no layers were found via the previous options.  
--no-exit
  when an output file is specified the layers are just written to the output file and the script will exit before mounting the sandbox unless the --no-exit option is specified. 

Both the --psubdir and --maybe-psubdir options get the puppy layers from a directory like puppy would do with the psubdir boot parmater (see: puppy boot parmaters) albeit implemented differently. The purpose of the maybe part of the option is to only do so if the layers weren't first found via a previous option (e.g. an input file as specified by the -f option). Options are evaluated from left to right, so order does matter.

More info on available options are documented in the comments of:
sandbox_s243a-debug4.sh

As noted above these mods aren't ready yet for general use. When the code gets a bit further along I'll put it on something like github or gitlab, Perhaps as part of my woof-next project or it could be it's own project if people think that is worth while. In the case that it is it's own project, I want to look at ways of expanding functionality. For instance perhaps I could adopt some of the functionality from easy containers but first I need to learn about easy containers.

P.S. What should this thread should be about (suggestions welcome )

I'm not sure if this thread should be about the official sandbox.sh or the non-official modifications of it that I'm working on. Alternatively, I could start a new thread for each of these topics.

[s243a]

If anyone ignores much strong recommendations to not test my "non-official" mods yet here are some notes:

1 - Mounting the sandbox will fail if the same mount point/path is specified more than once. So when the dialog pops up, unselect any duplicates. The spacebar can be used to unselect a layer.
2 - My code appears to mount the save directory, this isn't actually necessary.
3 - The code doesn't handle errors well in the input file, so if your first run fails, then delete the input file and generate a new one via the --psubdir or --maybe-psubdir option.
4 - Don't expect the code to work other then via the options that I specified in my test example:

Code: Select all

bash -x /usr/bin/sandbox_s243a_debug4.sh -f ~/sandbox.out -o ~/sandbox.out --maybe-psubdir "Tiny_Puduan/PreAlpha11.4" --no-exit

5 - I will probably troubleshoot other option combinations in the next few days.

[s243a]

I created a gitlab project both for my unofficial modifications (now called psandbox.sh), and the official woof-CE scripts (sandbox.sh and sandbox-rw.sh)

The official ones are in this repo, in case I want to test some changes before trying to push them to the official woof-CE.

The unofficial psandbox.sh, likely will never be part of puppies rootfs-skeleton because of increased complexity while at the same time not serving a core puppy function. I already broke it up into some separate file:

sandbox_mnt_fn.sh - Handles the mounting of files. This creates a much shorter filename than rox for the mount path.

sandbox.awk -- This is based on the awk code in the orginal sandbox.sh but with more features.

sb_db_rec_field.awk -- this is just some draft code to process the layer settings of a previous mount. This file might be abandoned.

** This project is not yet ready for developers or testers even though it does create a sandbox. Think of it as a preliminary sketch/prototype of what I'm thinking.

[jamesbond]

If anyone ignores much strong recommendations to not test my "non-official" mods

LOL you are too optimistic

The way you're going with this seems that you're going to re-implement EasyContainer; that is, the ability to run other Linuxes in a restrictive sandbox environment. For Puppies this is not difficult to do since all the layering are exposed, for others the difficulties varies.

That is the easy part, the difficult part is ensuring that whatever running inside the "container" cannot escape the container. And if you unshare the pid namespace, you'd better have a process reaper working, otherwise, sooner or later your container will be filled with zombie processes.

[s243a]

If anyone ignores much strong recommendations to not test my "non-official" mods

LOL you are too optimistic

Would the more optimistic case be they try it or don't try it?

The way you're going with this seems that you're going to re-implement EasyContainer; that is, the ability to run other Linuxes in a restrictive sandbox environment.

I plan to look into easy containers. That said, doesn't fatdog64 have it's own container tools (i.e. sandbox-lxc)?

For Puppies this is not difficult to do since all the layering are exposed, for others the difficulties varies.

At some point, I would be interested in learning more about this. At this point, I'm happy if it only works with puppy.

That is the easy part, the difficult part is ensuring that whatever running inside the "container" cannot escape the container. And if you unshare the pid namespace, you'd better have a process reaper working, otherwise, sooner or later your container will be filled with zombie processes.

Thankyou for the heads-up. At this point, that type of segregation isn't a priority yet. Later-on, I'll want to look into it.

[s243a]

I'm interested, in the files created when the sandbox starts because, if we want to remaster our sandbox, then we'll need special treatment of these files.

One of these files is shinit, this file was used in the original sandbox.sh (docs) to show the sandbox prompt and psandbox currently does the same thing:

Code: Select all

echo -e '\nexport PS1="sandbox'${SANDBOX_ID}'# "' >> $FAKEROOT/etc/shinit #fatdog 600

https://gitlab.com/s243a/psandbox/-/blo ... ox.sh#L619

another is /etc/profile

Code: Select all

sed -i -e '/^PS1/ s/^.*$/PS1="sandbox'${SANDBOX_ID}'# "/' $FAKEROOT/etc/profile # earlier fatdog

https://gitlab.com/s243a/psandbox/-/blo ... ox.sh#L620

what this code does is looks in /etc/profile for a line like PS1=something and rewrites that line of the file to say ${SANDBOX_ID}'# "

PS1 is an environmental variable for the name of the prompt. To make this line more general we might also want to look for lines starting with:

Code: Select all

export PS1=....

If we remaster the sandbox, we might want some way of reversing this change. Perhaps we could store the old value for this line in the /tmp folder.

Another file that is created is /etc/BOOTSTATE

Code: Select all

    SANDBOX_AUFS_ID=$(grep $FAKEROOT /proc/mounts | sed 's/.*si=/si_/; s/ .*//') #'
    sed -i -e '/AUFS_ROOT_ID/ d' $FAKEROOT/etc/BOOTSTATE 2> /dev/null
    echo AUFS_ROOT_ID=$SANDBOX_AUFS_ID >> $FAKEROOT/etc/BOOTSTATE

https://gitlab.com/s243a/psandbox/-/blo ... ox.sh#L580

puppy doesn't seem to have this file, so perhaps it is harmless in puppy. What it tells you is the location of the folder which defines the aufs layers. The full path to this folder is:

Code: Select all

/sys/fs/aufs/$SANDBOX_AUFS_ID 

this file should be deleted when remastering because it is probably only applicable to a particular boot and/or sandbox. Other files that I create are in /intird and /tmp These are not included for a remaster so aren't applicable. The intent of the /initrd is to make the sandbox look like other pupmodes. Currently the sandbox is made to look like a full install, but some of the code is in place to simulate other pupmodes.