What IS happening with my launchers?

[mikewalsh]

@dimkr :-

Dima, Dima, Dima.....what on earth have you done with these DPups?

I'm experimenting with V-DPup32 at the moment. I've installed a few things from the repos (even had a wee play around with Synaptic, just for the hell of it.....and noticed it is a hell of a lot faster than PPM, for starters!)

I thought I'd try out some of my portable applications. They run great, albeit with some glaring exceptions.

Anything internet-facing, for instance. They'll fire up fine.....just once. After which, the LAUNCH scripts get re-written, the original is re-named LAUNCH.bin, and the app won't run any more. It will insist it's running, and must be re-started.....yet there's no sign of it, and it doesn't show in the task manager. Even after a re-start, the scenario simply repeats itself again. So I'm kinda f**ked.

I would guess this is all part of your high-security measures, but what's the solution?

Mike.

[jrb]

Hi Mike,

The problem seems to be with /usr/sbin/run-as-spot and /usr/sbin/setup-spot. I just grabbed them from an older pup (17mar2019) and have them in my save files. It was driving me nuts rewritting your launch scripts and some of my own. Seems to attack anything with a common internet name, firefox, chromium, palemoon, etc. You could include those older /usr/sbin files in your portables and have your launch scripts replace them before starting the executables. (Power to the people!) BTW, running as spot works fine with the older files.

Good Luck, J

P.S. Its not just vdpup. Its built into the latest WoofCE's.

[OscarTalks]

I think this may be the same issue as I mentioned in the VoidPup Discussion thread recently regarding VLC which if compiled from source can be built with --enable-run-as-root in which case I really don't want the installation process (make install or installing via .pet or .xbps) to hijack my files and modify them. The small vlc binary is renamed as vlc.bin and is replaced by a script named vlc which attempts to run VLC as spot.

This is done without asking and furthermore when I looked in Login and Security Manager there was an option in there to change VLC to run-as-root but if I try to untick that option the untick action does not persist.

I think I understand the concept of trying to assist users who mostly install "official builds" and published packages from the various distributions, but I think this process needs to have more user choice, perhaps with some dialogs along the way or something.

[dimkr]

Let's start from the beginning.

Which version?
Which applications?
How did you install them?
Do these applications work as root in other Puppy releases or must run as spot?
When you say that some portable applications misbehave - which ones and how do you run them?
What do you mean by "LAUNCH scripts"?

And please be nice and don't blame me for breaking anything. I'm only trying to help and free Puppy from the curse of 2+ years without an official release, for free.

[mikewalsh]

@dimkr :-

Hallo, Dima. Let's see if we can run through these in order, shall we?

Which version?

Vanilla DPup 9.2.21 (32-bit). I grabbed this from GitHub just last night.

Which applications?

I'm talking about my self-contained, portable applications, which can be run from anywhere.....though usually outside the 'save'.

How did you install them?

They don't "install" as such. They come packed as a tarball; you unpack it, move it anywhere you want, then enter the directory and click on the 'LAUNCH' script. Doing this keeps all config files within the portable directory. An option is provided to add a Menu entry from wherever it's located, if required.

Do these applications work as root in other Puppy releases or must run as spot?

The majority run as root. Some are set to run-as-spot where the application refuses to run any other way.

When you say that some portable applications misbehave - which ones and how do you run them?

It's only the internet-facing ones that misbehave.....at least, the two I've tried so far; Thunderbird & Slimjet.

I share these portables between multiple Puppies, as far as possible. When I try any portable in a new Puppy for the first time, I always do so from the terminal, to get an idea of what happens.....if it'll 'play nice' or not, and if it needs any more 'tweaking'.

What do you mean by "LAUNCH scripts"?

This is invariably the script which will launch the application.

With browsers, the LAUNCH script will set the "read-link" variable, create the profile directory, then the profile & everything else is created internally to the portable directory. With many of the others, I determine where in the file system the app in question would normally expect to either find - or if not already existing, where it would then look to create those files.

In the latter case, the LAUNCH script will set the "read-link" variable, then create config directories/files within a sub-directory. These are then sym-linked to where the app would expect to find them prior to launching the app. At close, the sym-links are removed.....and because they're sym-links, anything the app writes to what it THINKS is its standard config file location actually gets written back to the portable directory again.

Sometimes, a number of specific dependencies will be packaged with the app, and the LAUNCH script will reference these via LD_LIBRARY_PATH immediately prior to the exec line.

In the case of Thunderbird-portable32, this:-

Code: Select all

#!/bin/sh
#
# Launcher for 'portable' Thunderbird....
#
HERE="$(dirname "$(readlink -f "$0")")"
#
mkdir "$HERE/profile" 2> /dev/null
#
LD_LIBRARY_PATH=$HERE/:$HERE/extralibs${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} "$HERE/thunderbird32/thunderbird" "$@" -profile "$HERE/profile"

.....is rewritten into this after the first run:-

Code: Select all

#!/bin/ash
# generic wrapper to run as ${XUSER} (when currently running as root)
# (C) James Budiono 2012, 2017
# License: GPL version 3 or later
#

#set -x

XUSER=spot

case $0 in *run-as|*run-as-user)
	if ! [ "$1" ] ; then
		echo "$0: Specify user"
		exit 1
	fi
	XUSER=$1
	shift
esac

CWD=$PWD
CMD=/mnt/sda3/SYSTEM/BROWSERS/32-bit/Thunderbird-portable32/LAUNCH.bin
while [ "$1" ]; do
	CMD="$CMD \"$1\""
	shift
done

[ "$CMD" ] || exit

USER_HOME=$(awk -F: '$1=="'"${XUSER}"'" {print $6}' /etc/passwd)
if ! [ "${USER_HOME}" ] ; then
	echo "$0 ERROR: could not HOME dir for user $XUSER"
	exit 1
fi
CURDIR=$PWD

if [ $(id -u) -eq 0 ]; then
	[ $XAUTHORITY ] && cp $XAUTHORITY ${USER_HOME}/.Xauthority 2>/dev/null
	touch ${USER_HOME}/.Xauthority
	export XAUTHORITY=${USER_HOME}/.Xauthority

	# replace all occurences of /root in XDG_* with /home/spot, because we don't
	# run a login shell and source /etc/profile.d/*
	OLD_HOME="$HOME"
	while IFS='=' read NAME VAL; do
		case "$NAME" in
		XDG_*) export $NAME="`echo "$VAL" | sed -e s~^$OLD_HOME~$USER_HOME~ -e s~:$OLD_HOME~:$USER_HOME~g`" ;;
		esac
	done << EOF # hack for old busybox, which doesn't understand <() and <<<
`env`
EOF

	export XDG_CONFIG_HOME=${USER_HOME}/.config
	export XDG_CACHE_HOME=${USER_HOME}/.cache
	export XDG_DATA_HOME=${USER_HOME}/.local/share

	for i in ${XDG_CONFIG_HOME} ${XDG_CACHE_HOME} ${XDG_DATA_HOME}
	do
		if ! [ -d $i ] ; then
			mkdir -p $i
			chown ${XUSER} $i
		fi
	done

	if [ "${XDG_RUNTIME_DIR}" ] ; then
		export XDG_RUNTIME_DIR=/tmp/runtime-${XUSER}
		if [ ! -d ${XDG_RUNTIME_DIR} ] ; then
			mkdir -p ${XDG_RUNTIME_DIR}
			chmod 0700 ${XDG_RUNTIME_DIR}
			chown ${XUSER} ${XDG_RUNTIME_DIR}
		fi
	fi

	if [ -s /tmp/.spot-session-bus ]; then
		. /tmp/.spot-session-bus
		export DBUS_SESSION_BUS_ADDRESS
		export DBUS_SESSION_BUS_PID
	fi

	# close all file descriptors except std{in,out,err}, in case one of
	# them points to a file under /root
	for FD in /proc/self/fd/*; do
		FD="${FD##*/}"
		[ $FD -gt 2 ] && eval "exec ${FD}<&-"
	done

	exec su ${XUSER} -s /bin/ash -c '
# try to switch to original directory, unless it is /root
if [ "'"$CURDIR"'" = /root ]; then
	cd "'"$USER_HOME"'"
else
	cd "'"$CURDIR"'"
fi
exec '"$CMD"'
'
else
	exec ash -c "exec $CMD"
fi

### END ###

Now it will refuse to run any more, insisting it's already running and must first be closed. But where is it? It can't be found, neither by searching manually through the workspaces OR via the LX task manager; according to the latter, the process doesn't exist!

So how can you close something which never started? Even a re-boot yields no joy; every subsequent attempt to start the app in question insists it's already running.......rinse & repeat.

It's the same with Slimjet-portable32. The original LAUNCH script:-

Code: Select all

#!/bin/sh
#
# Launcher for 'portable' Slimjet browser
#
HERE="$(dirname "$(readlink -f "$0")")"
#
mkdir "$HERE/PROFILE" 2> /dev/null
#
if [ -d "$HERE/slimjet/PROFILE" ]
then 
	rm -rf $HERE/slimjet/PROFILE
	ln -s $HERE/PROFILE $HERE/slimjet/PROFILE
else
	ln -s $HERE/PROFILE $HERE/slimjet/PROFILE
fi
#
"$HERE/slimjet/flashpeak-slimjet" "$@"
#
rm -rf $HERE/slimjet/PROFILE

.....becomes:-

Code: Select all

#!/bin/ash
# generic wrapper to run as ${XUSER} (when currently running as root)
# (C) James Budiono 2012, 2017
# License: GPL version 3 or later
#

#set -x

XUSER=spot

case $0 in *run-as|*run-as-user)
	if ! [ "$1" ] ; then
		echo "$0: Specify user"
		exit 1
	fi
	XUSER=$1
	shift
esac

CWD=$PWD
CMD=/mnt/sda3/SYSTEM/BROWSERS/32-bit/Slimjet-portable32/LAUNCH.bin
while [ "$1" ]; do
	CMD="$CMD \"$1\""
	shift
done

[ "$CMD" ] || exit

USER_HOME=$(awk -F: '$1=="'"${XUSER}"'" {print $6}' /etc/passwd)
if ! [ "${USER_HOME}" ] ; then
	echo "$0 ERROR: could not HOME dir for user $XUSER"
	exit 1
fi
CURDIR=$PWD

if [ $(id -u) -eq 0 ]; then
	[ $XAUTHORITY ] && cp $XAUTHORITY ${USER_HOME}/.Xauthority 2>/dev/null
	touch ${USER_HOME}/.Xauthority
	export XAUTHORITY=${USER_HOME}/.Xauthority

	# replace all occurences of /root in XDG_* with /home/spot, because we don't
	# run a login shell and source /etc/profile.d/*
	OLD_HOME="$HOME"
	while IFS='=' read NAME VAL; do
		case "$NAME" in
		XDG_*) export $NAME="`echo "$VAL" | sed -e s~^$OLD_HOME~$USER_HOME~ -e s~:$OLD_HOME~:$USER_HOME~g`" ;;
		esac
	done << EOF # hack for old busybox, which doesn't understand <() and <<<
`env`
EOF

	export XDG_CONFIG_HOME=${USER_HOME}/.config
	export XDG_CACHE_HOME=${USER_HOME}/.cache
	export XDG_DATA_HOME=${USER_HOME}/.local/share

	for i in ${XDG_CONFIG_HOME} ${XDG_CACHE_HOME} ${XDG_DATA_HOME}
	do
		if ! [ -d $i ] ; then
			mkdir -p $i
			chown ${XUSER} $i
		fi
	done

	if [ "${XDG_RUNTIME_DIR}" ] ; then
		export XDG_RUNTIME_DIR=/tmp/runtime-${XUSER}
		if [ ! -d ${XDG_RUNTIME_DIR} ] ; then
			mkdir -p ${XDG_RUNTIME_DIR}
			chmod 0700 ${XDG_RUNTIME_DIR}
			chown ${XUSER} ${XDG_RUNTIME_DIR}
		fi
	fi

	if [ -s /tmp/.spot-session-bus ]; then
		. /tmp/.spot-session-bus
		export DBUS_SESSION_BUS_ADDRESS
		export DBUS_SESSION_BUS_PID
	fi

	# close all file descriptors except std{in,out,err}, in case one of
	# them points to a file under /root
	for FD in /proc/self/fd/*; do
		FD="${FD##*/}"
		[ $FD -gt 2 ] && eval "exec ${FD}<&-"
	done

	exec su ${XUSER} -s /bin/ash -c '
# try to switch to original directory, unless it is /root
if [ "'"$CURDIR"'" = /root ]; then
	cd "'"$USER_HOME"'"
else
	cd "'"$CURDIR"'"
fi
exec '"$CMD"'
'
else
	exec ash -c "exec $CMD"
fi

### END ###

.......and henceforh refuses to run again.

While it's appreciated that you're attempting to make Puppy as friendly and easy-to-use as possible, especially for Windows refugees, I DO feel it's a bit cheeky to automatically assume that you "know what's best" for the user. Windows users neither know nor expect any different; they're used to having important decisions/choices made for them by Microsoft. My point is that experienced Linux users may well get snotty over not even being given the chance to decide differently, y'know?

I realise that the /home/user model is standard throughout the ecosphere, and that Puppy has up till now been very definitely out on a limb with regards to the way it runs.......and needs to change somewhat in this respect (or at least provide a usable alternative that allows proper operation as merely "a user", which is expected by a lot of software). I also appreciate that the original reason for Puppy's existence has changed somewhat over the years.....and that very few people still run the kind of resource-starved hardware that existed when Puppy first came onto the scene. Most of it's already died!

For myself, I do a ton of things that horrify 'traditional' users. Running as root is just one of them. I also share these portable applications between as many Puppies as I can. I couldn't care less whether or not everything is "just so" or not, much less whether things like themes/icons have a uniform look. Life is for living, not for "nitpicking"! And in several years of accessing the internet as the root user, I have never, EVER had any issues.

------------------------------------------------

Please don't feel that my post is just a litany of complaints. It's not. I AM 'being nice'.....but at the same time trying to raise what I see as valid points..?

In our community, you're one of the very few individuals for whom I have always had a real & genuine respect. If it weren't for you - and but a handful of others - the rest of us wouldn't even have the opportunity to play around with Puppy the way we do, much less enjoy it as much. Most of the time, you toil in relative obscurity, yet your work makes so much difference to the rest of us. In my book, that makes you a community hero.

You're definitely one of the "good guys", mate. I just regret not being able to contribute back more than I do, but when it comes to the nitty-gritty of what makes things work, I just don't have the interest......nor - increasingly these days - the time.

We all have our strengths.....and weaknesses. It's perhaps a good thing that we're not all interested in exactly the same stuff, or the community wouldn't have lasted for as long as it has.

Mike.

[dimkr]

Applications in this list are automatically configured to run as spot if placed in /usr/bin.

Rationale: it is assumed that packages that touch /usr/bin, rather than /usr/local/bin or /opt, are Debian packages, without magic Puppy patches for applications that normally refuse to run as root, or a wrapper script that runs them as spot.

Are you copying these "portable applications" or putting the "LAUNCH scripts" in /usr/bin/vlc, /usr/bin/google-chrome-stable, /usr/bin/seamonkey, etc'? If so, try to place them in /usr/local/bin instead.

[mikewalsh]

@dimkr :-

Applications in this list are automatically configured to run as spot if placed in /usr/bin.

Rationale: it is assumed that packages that touch /usr/bin, rather than /usr/local/bin or /opt, are Debian packages, without magic Puppy patches for applications that normally refuse to run as root, or a wrapper script that runs them as spot.

Ah. That explains a LOT.

Are you copying these "portable applications" or putting the "LAUNCH scripts" in /usr/bin/vlc, /usr/bin/google-chrome-stable, /usr/bin/seamonkey, etc'? If so, try to place them in /usr/local/bin instead.

Um.....well; yes AND no. What I've set the 'MenuAdd' script to do is to sym-link the 'LAUNCH' script into /usr/bin, renaming it at the same time. This is what the .desktop entry's 'Exec' line then looks for.

I shall have to experiment a bit. As it stands, without 're-setting' the current LAUNCH/LAUNCH.bin mess, these apps now won't run in any other 32-bit Puppy, either.

Let me have a think about this...

Mike.

[jrb]

Are you copying these "portable applications" or putting the "LAUNCH scripts" in /usr/bin/vlc, /usr/bin/google-chrome-stable, /usr/bin/seamonkey, etc'? If so, try to place them in /usr/local/bin instead.

I confess, I have been linking all my portables, both Mikes creations and my own, into /usr/bin. I just eliminated my crude hack as mentioned above and rewrote my linking script to link into /usr/local/bin. Seems to be working just fine.

Thanks for explaining this @dimkr, and also clearing up the mystery of which process has been doing the rewriting.

[OscarTalks]

Applications in this list are automatically configured to run as spot if placed in /usr/bin.

Rationale: it is assumed that packages that touch /usr/bin, rather than /usr/local/bin or /opt, are Debian packages, without magic Puppy patches for applications that normally refuse to run as root, or a wrapper script that runs them as spot.

Are you copying these "portable applications" or putting the "LAUNCH scripts" in /usr/bin/vlc, /usr/bin/google-chrome-stable, /usr/bin/seamonkey, etc'? If so, try to place them in /usr/local/bin instead.

Thanks for the explanation. ( I thought it was something along those lines but that clarifies fully ).
I still think it would be nice if a dialog question could be inserted:-
"The program you appear to be installing will be reconfigured to run as user spot, to proceed with this click 'Yes' or to continue to allow the installed program to run as root click 'No'. You can always run this program as spot later by using Login and Security Manager"
Wording could be improved but you get the idea.

Regarding my VLC builds in VoidPup I was always told that the normal practice when compiling in Puppy is to configure with --prefix=/usr so compiling and installing from source with new2dir make install does of course trigger this reconfiguration for run-as-spot (because the vlc executable will go into /usr/bin). I am aware of the possibilities of configuring differently at build time, maybe --prefix=/usr --bindir=/usr/local/bin or alternatively I presume the executables can be moved manually from /usr/bin to /usr/local/bin before packaging, but there are some script executables (in vlc) which then need editing as well I think. Anyway, it is possible to work around it now we understand what is happening.

[fredx181]

Perhaps off-topic, I noticed that in (some ?) modern Puppies /usr/local/bin is not first in PATH.
I always like that to be first, to have priority, so just put some binary or script in /usr/local/bin/ and it will replace the other (standard) in PATH.