utilities extensions not overwriting Busybox symlinks

[wdef]

Hi

Is there any reason that (for eg) the binutils extension does not overwrite the corresponding Busybox symlinks?

This causes  problems with Perl's CPAN which does not appear to search PATH (at least in order) to find some utilities.

Example: /usr/bin/ar is a symlink to Busybox.  The binutils extension puts ar in /usr/local/bin
CPAN does not seem to provide a standard o conf configuration to point it at an alternative location for ar and ignores /usr/local/bin/ar, then runs into problems using Busybox's ar unless that symlink is removed.

If possible it would be simpler if extensions like binutils overwrote the corresponding Busybox symlinks.

(There are in fact a few dependencies like binutils that need to be added to the Perl extension for CPAN to build modules properly but that is a topic for another day).

Thanks

EDIT: would this be to do with keeping the extension uninstallable with appsaudit? Perhaps the Busybox symlinks could be dealt with using a custom startup script for the extension to avoid having two binaries with the same name in PATH.

Some programs do not make use of environment variables for security reasons.

[Jason W]

Of course, /usr/local/bin was used for PPI compatibility and it is ahead of /usr in $PATH, but I guess there is no way around creating symlinks with the startup script that overwrite the busybox symlinks.  That way PPI compatibitily is preserved and RAM use minimized for those using PPI while overwriting the busybox symlinks.

[wdef]

Thanks Jason.   One possibility might be to write a generic startup script for all Busybox replacement extensions that goes like: 

If a symlink exists in PATH (but not in /usr/local/bin) with the same name as an executable in the extension, replace that symlink with one to the executable.

[Jason W]

Though some base scripts depend on busybox apps as opposed to their full versions, the command "busybox cp" will still use busybox cp even if the symlink is gone.

Overwriting the busybox simlinks would definitely prevent any live uninstalling of the extension that overwrites them. 

Since coreutils/binutils is Juanito's, I would like to hear his input on this. 

I have in the past altered scripts and such in extensions to adhere to TC's installation path in /usr/local/{bin,sbin}.  In other words make the extension compatible with TC.  I normally have an aversion to overwriting base, but tar overwrites the busybox symlink /bin/tar as that is where many apps expect it to be.  I admit it would be hard to browse each source to check for where it wants to find coreutils commands, though most seem to use a "which app" to find the app.

[wdef]

Thanks for looking into it.  Most of the time (I think I came across an exception once) Busybox utility cli switches are a subset of the full set of switches available to the GNU counterpart, so a script that works with Busybox usually will work with GNU utils I think.  An 'unrecognized option' error is usually fairly obvious. 

While it would be for the tc team and extension builders to say, I guess it could be argued that if there was ever a case for overwriting base symlinks and thus to have a live-uninstallable extension it would have(?) to be to replace Busybox versions with standard GNU utils.

[jpeters]

I know I've had to use "busybox command" on a number of occasions when gnu just didn't work right.

[Juanito]

There's been quite a few comments for and against replacing the busybox symlinks when installing binutils/coreutils.

I believe most apps will check $PATH and find the binutils/coreutils version, but I've noticed, for example, that many ./configure scripts do not find /usr/local/bin/ar although this has only resulted in an error once.

I'm leaning towards the opinion that apps should check $PATH and so they should be modified, if required, rather than the busybox symlinks, but I'll go with what the majority believes.

[Jason W]

Since I personally have not had problems with having the coreutils stuff in /usr/local/bin, I also would hold tight for now.  It does seem few and far between that apps use hard coded paths for things, and if it is not an issue that affects many apps then adjusting the app to conform to TC could be done.

The same principle has applied to scripts that do not find kernel modules in anything but /lib/modules, or that dont find files that exist as symlinks ( both the case with alsaconf).  For now adjustments to the apps can be made I think, especially if ar is about the only utility that is affected.

[maro]

I guess I take it from this discussion that diffutils.tcz needs to be considered as currently "broken".

That extension is packaged for /usr/bin (instead of /usr/local/bin) and I currently I have to create the /usr/local/bin symlink myself if I want to use GNU diff.

Cheers
Martin

[Jason W]

Things should always be installed to /usr/local/ unless there is no other way.  And for those files that need to go above /usr/local, using the startup script to copy or move them there from beneath /usr/local is the way to go.   I will repack the extension if the extension creator does not do so in the near future.

[wdef]

It will not always be trivial to modify apps that expect Gnu utilities to be in /usr/bin to look elsewhere since this may involve eg hacking the source code and recompiling.

Binaries from C programs with security concerns can avoid using environment variables like PATH at all since environment variables can provide an attack route. It would be reasonable to think these might look in different locations for a utility rather than just one. CPAN doesn't seem to for some reason.  I might ask about this on the appropriate list.

From another angle though,  Busybox is a mere approximation of Gnu utils, not the other way round.  The GNU standard is the full utility so it's not surprising when Busybox breaks something, and it's no surprise when apps from out there are written for compatibility primarily with Gnu utils not with Busybox. 

So just my $0.02:  I still think Busybox symlinks should be overwritten by the gnu utils counterparts when these get installed.   Maybe some testing of scripts in the base against gnu utils is needed and scripts modified to work with both Busybox and GNU versions.

It's rare that something that works with Busybox gets broken by GNU utils (please give me some examples and if these are scripts I will undertake to fix them to work with both).  But the other way round is quite frequent. 

[Juanito]

Maybe we could have two coreutils extensions - one that installs to /usr/local and one that installs to /usr/local, but runs a start-up script to replace the links in /usr to busybox with links to the gnu utility in /usr/local?

[Jason W]

md5sum and wget are 2 busybox commands that have busybox options that are not supported by full versions.  But "busybox wget" will work even if the symlink is gone. 

In the end, I wouldn't have a problem with coreutils/binutils overwriting the BB stuff.

If we had a seperate coreutils extension to test, it would be good to add to the startup script

touch /usr/local/tce.installed/coreutils

so it would account for coreutils being installed.

[Jason W]

Actually, upon looking at some of the CPAN scripts, they use /usr/bin/mpg123 for the mpg123 path, same with lynx and sendmail and etc.  And expect /usr/share to be the share directory.  So it goes far beyond coreutils/binutils as to the paths of apps.  CPAN expects all apps to be installed in /usr.  To change TC to prevent changes to CPAN apps would  basically abandoning the /usr/local install path we have used since day one.  Much easier to use sed on those particular scripts to change the app and share path to make them TC compatible.

I do understand the issue of having duplicate binaries, BB in the system and GNU/other in /usr/local.  Perhaps a script to force symlink any base executables to ones in /usr/local if they exist could be put up in programming and scripting, which could be run by bootlocal.sh for those that want only the extensions' version in /usr/local to be used.  I still have the tendency to favor not overwriting base by default unless necessary, but I understand the desire to only have one installed version used of each app.

The way CPAN is using hard coded paths makes their stuff need the same tweaking for UNIXs like Solaris where /usr/local is the default GNU install path, if GNU stuff was to be used.  Actually, /usr/local is the default GNU install path (using ./configure with no flags) on any Linux/Unix and was one reason we went with /usr/local as our default extension path.

For those that don't already know the scripting but would like to remove duplicate, here is an example script to remove duplicate apps in PATH for a quick and easy workaround:

Code: [Select]

#!/bin/sh

for I in `ls /usr/local/bin`; do
[ -x /usr/bin/"$I" ] && sudo ln -sf /usr/local/bin/"$I" /usr/bin/"$I";
[ -x /bin/"$I" ] && sudo ln -sf /usr/local/bin/"$I" /bin/"$I";
[ -x /sbin/"$I" ] && sudo ln -sf /usr/local/bin/"$I" /sbin/"$I";
[ -x /usr/sbin/"$I" ] && sudo ln -sf /usr/local/bin/"$I" /usr/sbin/"$I";
done

for I in `ls /usr/local/sbin`; do
[ -x /usr/bin/"$I" ] && sudo ln -sf /usr/local/sbin/"$I" /usr/bin/"$I";
[ -x /bin/"$I" ] && sudo ln -sf /usr/local/sbin/"$I" /bin/"$I";
[ -x /sbin/"$I" ] && sudo ln -sf /usr/local/sbin/"$I" /sbin/"$I";
[ -x /usr/sbin/"$I" ] && sudo ln -sf /usr/local/sbin/"$I" /usr/sbin/"$I";
done