Puppy Linux Discussion Forum

Afternoon, all.

Some of you may remember the all-in-one chrooted Iron 69 package I produced early last year when Darry and I were messing around with his "Phoenix" build of Puppy 4.3.1. This had been updated with a newer glibc, libs, and much more.

Finding a decent browser to run in it was proving problematical, however, bearing in mind that the browser is the main attack vector for any OS.....even Puppy. Watchdog put together a chroot 'jail' (using Precise 571) running the then newest Palemoon, and although it ran perfectly, for me at least, it seemed a bit sluggish. Perhaps it was just my hardware; couldn't really say.

Anyway, I did some head-scratching, and a bit of pondering. I've always been a fan of the Chromium "clones", and since Chrome stopped supporting 32-bit Linux more than 4½ years ago, my favourite 32-bit replacement has always SRWare's 'Iron' browser. I figured out that Tahrpup was the oldest Puppy that would run the current crop of 'clones' - still is! - so I created a chroot jail by basically just using Tahr 6.0.6 as the base, "installed" Iron 69, borrowed watchdog's chroot run scripts, and gave it a try. Wonder of wonders, it worked.....and it seemed to run like greased lightning, too! Darren himself will confirm this; you can read the post I made about it at the time, here:-

http://oldforum.puppylinux.com/puppy/vi ... 49#1035264

I made the whole thing up into an SFS package, so it could be loaded/unloaded as & when required. It IS quite large, since you're basically running one Puppy inside another, so.....it's not really viable if you've only got 2GB of RAM or less. 4 GB will work better; the clones are, after all, heavyweight browsers....

Now rebuilt with the current Iron 88 'portable'.....and using Xenialpup 7.5 as the 'chroot'. If anybody wants to try this out, the new Iron-chroot SFS can be found here:-

https://drive.google.com/file/d/1_oVMZV ... sp=sharing

Enjoy!

Mike.

I made the whole thing up into an SFS package, so it could be loaded/unloaded as & when required. It IS quite large, since you're basically running one Puppy inside another, so.....it's not really viable if you've only got 2GB of RAM or less. 4 GB will work better; the clones are, after all, heavyweight browsers....

Anyways; I've just rebuilt this with the current Iron 84 'portable' (which I haven't yet published on its own). I'm posting from it now, running in Sailor's Slacko 571. If anybody wants to try this out, the new Iron-chroot SFS can be found here:-

https://drive.google.com/file/d/17tWCUq ... sp=sharing

Enjoy!

Mike.

Hello mikewalsh,

this worked for me in upupGG+D (32bit). I tried this chrooted version of iron because I wasn't able to get your portable version of iron working on upupGG+D (32bit). Also the chromium package which was available on the upupGG+D package manager didn't work for me.

So thank-you for this chrooted version of Iron84

Next, I might want to make a menu item to load the sfs, like taersh mentions:
viewtopic.php?p=11974#p11974
viewtopic.php?f=106&t=970

P.S. your menu item needs to be fixed. You have:

Exec=/usr/bin/Iron69 "$@"

but the actual startup script that you have in your sfs file is:

/usr/bin/Ironchroot

Also for some reason the sfs wasn't showing through properly so I ran the following command:

busybox mount -t aufs -o remount,udba=reval unionfs /

that I learned about reading the code of Scottman's package manager (i.e. pkg).

On another note I might try removing the "xhost +" in your startup script for better security.

@s243a :-

Sweet. Nice to hear it's of some use to somebody..!

Thanks for pointing out the Menu entry error. I'll investigate, and re-pack/re-upload.

Cheers.

Mike.

@s243a :-

Had a thought. Your issue with the Iron-portable is in all likelihood related to the same issue I've had with Google_Chrome-portable (and some others) running under Fossapup64.

It revolves around the fact that Fossapup has newer versions of all the libs in the self-contained 'libs' directory. Ordinarily, it wouldn't present a problem, but the browsers still want default dependencies that then call on the ones in the dedicated libs directory.....and one in particular that's wanted is a newer version than in here; libpangoft2.

That then throws the cat among the pigeons, and everything else conflicts. Davids45 first unearthed this issue when trying to run either Chrome-portable or Vivaldi-portable under peebee's SCPup64.

The answer seems obvious, I know; update everything in the dedicated libs directory, yes? Unfortunately, if you do that, then the portables won't work in anything older than Fossapup. Which kind of makes a mockery of the fact that I try to ensure my portables will run on as many Pups as possible; remember, not everybody is able to run the very newest Pups. Often, they're just too much for a lot of older machines.....and I've always been a big believer in running 'date-sympathetic' software to when your hardware was manufactured.

And that also goes for the OS itself.....

Go into the 'iron32' directory, then open the 'iron-pup' wrapper-script with Geany, and remove the 'LD_LIBRARY_PATH' line. Save, exit, then try launching the portable again from the 'LAUNCH' script. It should now run, all things being equal.

Let me know if that works, please. I need feedback on what's happening with this stuff in the newest Pups..!

Mike.

mikewalsh wrote: ↑Fri Dec 11, 2020 12:29 am

@s243a :-

Had a thought. Your issue with the Iron-portable is in all likelihood related to the same issue I've had with Google_Chrome-portable (and some others) running under Fossapup64.

It revolves around the fact that Fossapup has newer versions of all the libs in the self-contained 'libs' directory. Ordinarily, it wouldn't present a problem, but the browsers still want default dependencies that then call on the ones in the dedicated libs directory.....and one in particular that's wanted is a newer version than in here; libpangoft2.

That then throws the cat among the pigeons, and everything else conflicts. Davids45 first unearthed this issue when trying to run either Chrome-portable or Vivaldi-portable under peebee's SCPup64.

The answer seems obvious, I know; update everything in the dedicated libs directory, yes? Unfortunately, if you do that, then the portables won't work in anything older than Fossapup. Which kind of makes a mockery of the fact that I try to ensure my portables will run on as many Pups as possible; remember, not everybody is able to run the very newest Pups. Often, they're just too much for a lot of older machines.....and I've always been a big believer in running 'date-sympathetic' software to when your hardware was manufactured.

And that also goes for the OS itself.....

Go into the 'iron32' directory, then open the 'iron-pup' wrapper-script with Geany, and remove the 'LD_LIBRARY_PATH' line. Save, exit, then try launching the portable again from the 'LAUNCH' script. It should now run, all things being equal.

Let me know if that works, please. I need feedback on what's happening with this stuff in the newest Pups..!

Mike.

Deleting the LD_LIBRARY_PATH from your startup script didn't help. I think this is the error:

IntentionallyCrashBrowserForUnusableGpuProcess()

I provide more details in the following post:
viewtopic.php?p=12134#p12134

Not sure if this will help but here is where in the source this function is called:
https://chromium.googlesource.com/chro ... te.cc#413

s243a wrote: ↑Fri Dec 11, 2020 2:10 am

mikewalsh wrote: ↑Fri Dec 11, 2020 12:29 am

@s243a :-

Had a thought. Your issue with the Iron-portable is in all likelihood related to the same issue I've had with Google_Chrome-portable (and some others) running under Fossapup64.

It revolves around the fact that Fossapup has newer versions of all the libs in the self-contained 'libs' directory. Ordinarily, it wouldn't present a problem, but the browsers still want default dependencies that then call on the ones in the dedicated libs directory.....and one in particular that's wanted is a newer version than in here; libpangoft2.

That then throws the cat among the pigeons, and everything else conflicts. Davids45 first unearthed this issue when trying to run either Chrome-portable or Vivaldi-portable under peebee's SCPup64.

The answer seems obvious, I know; update everything in the dedicated libs directory, yes? Unfortunately, if you do that, then the portables won't work in anything older than Fossapup. Which kind of makes a mockery of the fact that I try to ensure my portables will run on as many Pups as possible; remember, not everybody is able to run the very newest Pups. Often, they're just too much for a lot of older machines.....and I've always been a big believer in running 'date-sympathetic' software to when your hardware was manufactured.

And that also goes for the OS itself.....

Go into the 'iron32' directory, then open the 'iron-pup' wrapper-script with Geany, and remove the 'LD_LIBRARY_PATH' line. Save, exit, then try launching the portable again from the 'LAUNCH' script. It should now run, all things being equal.

Let me know if that works, please. I need feedback on what's happening with this stuff in the newest Pups..!

Mike.

Deleting the LD_LIBRARY_PATH from your startup script didn't help. I think this is the error:

Code: Select all

IntentionallyCrashBrowserForUnusableGpuProcess()

I provide more details in the following post:
viewtopic.php?p=12134#p12134

Not sure if this will help but here is where in the source this function is called:
https://chromium.googlesource.com/chro ... te.cc#413

As I mentioned, with more detail, in the other thread, the solution was to add the following option:
Edit: Old option suggestion crossed out in place of "--use-angle"

--enable-oop-rasterization Turns on out of process raster for the renderer whenever gpu raster would have been used. Enables the chromium_raster_transport extension

--use-angle	Select which ANGLE backend to use. Options are: default: Attempts several ANGLE renderers until one successfully initializes, varying ES support by platform. d3d9: Legacy D3D9 renderer, ES2 only. d3d11: D3D11 renderer, ES2 and ES3. warp: D3D11 renderer using software rasterization, ES2 and ES3. gl: Desktop GL renderer, ES2 and ES3. gles: GLES renderer, ES2 and ES3. ↪

https://peter.sh/experiments/chromium-c ... -switches/

I'm probably not the best one to be testing some of those GPU --switches.

Although my CPU has a perfectly good built-in Intel GPU, I use an Nvidia discrete card. When I first tried Fossapup, for example, the desktop was so laggy as to be virtually unusable. Phil suggested to try the supplied "official" driver, which I did, and.....everything behaved itself again.

But I'm not prepared to keep testing out different browsers in multiple various Puppies, along with constantly switching back & forth between iGPU and discrete GPU, just to see which might work better for everybody else..... There ARE limits. (And I don't have that kind of time to spare. On top of which, my tower is not that easily-accessible; swapping GPUs once would be bad enough, but doing it several times a day? Err....NO.)

Sorry!

Mike.

mikewalsh wrote: ↑Fri Dec 11, 2020 12:01 pm

I'm probably not the best one to be testing some of those GPU --switches.

Although my CPU has a perfectly good built-in Intel GPU, I use an Nvidia discrete card. When I first tried Fossapup, for example, the desktop was so laggy as to be virtually unusable. Phil suggested to try the supplied "official" driver, which I did, and.....everything behaved itself again.

But I'm not prepared to keep testing out different browsers in multiple various Puppies, along with constantly switching back & forth between iGPU and discrete GPU, just to see which might work better for everybody else..... There ARE limits. (And I don't have that kind of time to spare. On top of which, my tower is not that easily-accessible; swapping GPUs once would be bad enough, but doing it several times a day? Err....NO.)

Sorry!

Mike.

I'm not asking you to test out all these options but if users find for instance that the --angle option is good for hardware lacking a suitable gpu, then it might be good to provide a second startup-script/"menu option" that uses the --angle switch. Having two menu options doesn't hurt and if enough people have the same issue as me then it seems like a good approach. That said, I would really like to know why I didn't need this "--angle" option in the chrooted version.

@s243a :-

Reading through the Chromium command-line "--switch" list, I get the impression that the '--angle' option (along with several others?) is actually a 'forced' workaround for Windows.....unless I'm reading that little lot totally wrong! The mentioned Linux workarounds appear to be for forcing either the version of OpenGL the machine is running with, or the version of EGL....

It wouldn't be a problem at all to provide a second MenuEntry; I'm already providing a second portable 'LAUNCH' script for those who find that the 'LD_LIBRARY_PATH' is giving them problems in Fossapup. I think we would need to experiment a wee bit with some of the other available options, and take a squizz at possible impacts on CPU activity/temps, etc, while we're at it.

Make sense? (I can't spare the time for this until early next week, but I'd be happy to see what effect some of those Linux 'options' have, especially for those of us running an Nvidia card with the official driver.)

Mike.

mikewalsh wrote:

Make sense? (I can't spare the time for this until early next week, but I'd be happy to see what effect some of those Linux 'options' have, especially for those of us running an Nvidia card with the official driver.)

Mike.

Thank-you for looking into this. This isn't urgent for me because I got it working for me by using the --angle option. Maybe what we need is to propose some tests, and get some of the users with different hardware to try these tests. Maybe someone has already done these tests and we can find the results online.

Anyway, it's pretty easy to edit the startup script once someone knows this needs to be done and has an idea what options they should try.

Seems to work when sfs loaded within Fatdog (load sfs, in a terminal run ironchroot). Except no sound heard when playing youtubes, which for me was fixed by editing /usr/bin/ironchroot as per viewtopic.php?p=14005#p14005

so I created a chroot jail by basically just using Tahr 6.0.6 as the base, "installed" Iron 69, borrowed watchdog's chroot run scripts, and gave it a try. Wonder of wonders, it worked

Hmm! Not really a 'jailed' system Mike, just a straight chroot. Conceptually could still repartition disks (gparted), can see all, and even relatively easily escape the chroot (such as chrooting out of the chroot).

For more jail like it would at least have to drop capabilities. For instance instead of running

chroot /cont /bin/sh

for a shell within the chroot, instead using

capsh --drop=cap_sys_chroot --chroot=/cont -- /usr/bin/xterm

For the former within that shell you can still run
chroot /
... and that will succeed, but not with the latter - i.e. will block attempts to chroot out of the chroot.

Loads of other capabilities that might also be dropped (which involves just extending the --drop= ... to provide a comma separated list, and where current capabilities can be seen by running capsh --print).

Loads more of attack vectors that would need to be closed down before it was anywhere near like a jailed environment, anti-stuffing into other X windows, or keyboard stuffing/recording ... etc. etc.

Let alone being older versions of main system and browser would be riddled with potential known exploits (bugs).

.. but I guess much of that is irrelevant when you run Puppy's, as you're already accepting to little/no security by default. More a case of the suggestion of a 'jail' chroot ... is misleading.

@mikewalsh Small thing that I noticed that needs to be tweaked.

When you create the chroot you:

cp /var/lib/dbus/machine-id /${#CONT_NAME_DEST}/var/lib/dbus/machine-id 

when you close it you do this:

umount /cont/var/lib/machine-id

but this should be a delete not a umount. However, you might just want to delete the whole /cont folder after the you finish unmounting.

@s243a / @rufwoof :-

Guys; do bear in mind, both of you, that although I've made use of watchdog's 'chroot' scripting, I do not even begin to pretend to understand how it works, yeah? All I've done is to adapt it to enable use of a relatively modern browser on older Puppies; it worked for me, so.....I left it at that!

(It's quite clear to me that both of you appear to understand far more about the nuts & bolts of this whole chroot business, and, er, if I've wrongly appropriated the term "jailed" in this case, then I hold my hands up. I'm really only a sort of 'pretend' geek.....honest Injun!)

Mike.

mikewalsh wrote: ↑Sun Jan 17, 2021 9:06 pm

@s243a / @rufwoof :-

Guys; do bear in mind, both of you, that although I've made use of watchdog's 'chroot' scripting, I do not even begin to pretend to understand how it works, yeah? All I've done is to adapt it to enable use of a relatively modern browser on older Puppies; it worked for me, so.....I left it at that!

(It's quite clear to me that both of you appear to understand far more about the nuts & bolts of this whole chroot business, and, er, if I've wrongly appropriated the term "jailed" in this case, then I hold my hands up. I'm really only a sort of 'pretend' geek.....honest Injun!)

Mike.

Sometimes we learn first by doing. You were the first one to release such a browser here so you deserve some credit

Evening, all.

The Iron 'chroot' SFS package has now been upgraded to Iron 88. Link below:-

Iron 88 'chroot'

Enjoy.

Mike.

Hiya, gang.

The Iron-chroot package has now been updated to the newest Iron v89. Link as follows:-

Iron 89 'chroot'

Have fun!

Mike.

Your version 89 Chrooted Iron is working well on a Xenial Dog - Not what you'd be expecting it to run on but with a little bit of work I got it running with menu entry. Thanks again Mike for doing these keeping older Puppies and Dogs alive.

The script closechroot fails if you do not add:

exit

at the end of the ironchroot script.

watchdog wrote: ↑Sun May 02, 2021 4:02 am

The script closechroot fails if you do not add:

Code: Select all

exit

at the end of the ironchroot script.

Wouldn't the "exit" command also be needed in /usr/bin/mscwchoot which currently reads:
#!/bin/sh
export LC_ALL=C
mount --bind /dev /cont/dev
mount --bind /proc /cont/proc
mount --bind /sys /cont/sys
mount -t devpts devpts /cont/dev/pts
cp /etc/resolv.conf /cont/etc/resolv.conf
cp /var/lib/dbus/machine-id /cont/var/lib/dbus/machine-id
xhost +
mkdir -p /cont/tmp/.X11-unix
mount --bind /tmp/.X11-unix /cont/tmp/.X11-unix
chroot /cont Multiple-Sound-Card-Wizard

or for any other application to be run in the chroot via a similar call?

Yes, any app launched in a chroot script must be terminated with "exit" command for closechroot to work. Example: I have a chroot jail from StretchPup32 by @radky to run vlc in ScPup64 21.04+2. Here is my script:

#!/bin/sh
export LC_ALL=C
mount --bind /dev /cont/dev
mount --bind /proc /cont/proc
mount --bind /sys /cont/sys
mount -t devpts devpts /cont/dev/pts
cp /etc/resolv.conf /cont/etc/resolv.conf
cp /var/lib/dbus/machine-id /cont/var/lib/dbus/machine-id 
xhost +
mkdir -p /cont/tmp/.X11-unix
mount --bind /tmp/.X11-unix /cont/tmp/.X11-unix
chroot /cont vlc "$@"
exit

closechroot:

#!/bin/sh
umount /cont/tmp/.X11-unix
umount /cont/sys
umount /cont/proc
umount /cont/dev/pts
umount /cont/dev
xhost -

@watchdog :-

Thanks for the info, mate. I'll re-pack the chrooted Iron to include this from now on. Appreciated.

Cheers!

Mike.