Enviromental Variables issue in Knoppix 3.7.1 installed to H

[Quazar]

I installed Knoppix 3.7.1 to my HD (multi-user mode) and whenever I issue a "set" command in a Konsole, I get the following behavior:

<truncated>
......
XDM_MANAGED=/var/run/xdmctl/xdmctl-:0,maysd,mayfn,sched,method=classic
XMODIFIERS=none
_=/etc/profile
bash205='3.00.16(1)-release'
bash205b='3.00.16(1)-release'
bash3='3.00.16(1)-release'
_ImageMagick ()
{
local prev;
prev=${COMP_WORDS[COMP_CWORD-1]};
case "$prev" in
-channel)
COMPREPLY=($( compgen -W 'Red Green Blue Opacity \
Matte Cyan Magenta Yellow Black' -- $cur ));
return 0
;;
-colormap)
COMPREPLY=($( compgen -W 'shared private' -- $cur ));
return 0
;;
-colorspace)
COMPREPLY=($( compgen -W 'GRAY OHTA RGB Transparent \

<truncated>

How do I fix this? It is causing problems with packages correctly reading the values of enviromental variables.....

Thanks for any assistance...

[angor]

This looks perfectly normal to me... Could you elaborate on how this causes problems?
(And please be patient - I won't be reading this forum again until Apr-25)

[Quazar]

I will post more details next week, but I am not used to seeing all of that programming-like output from issuing a simple "set" command to see what variables are set and what their values are. ...

The problem I am running into is two fold..

1.) Despite what looks like a correct PATH statement, programs in the /usr/local/sbin directory will not run unless I am cd'd into that directory.

2.) When I try to install the newest version of Nessus (after deleting the current version), it reports that GTK is not installed and that I won't get some of the GUI features. GTK is installed and there are several variables that attest to that fact.

Thanks....

[Keilaron]

I've been having a similar problem, but I think I know (partially) what the problem is. I don't have a solution though :(

Quazar, are you running a script, and it's not finding, say, start-stop-daemon (/sbin/)? I've been having this problem, and it's really annoying me. With some scripts it only happens if I'm not running it as root... so I'm rather annoyed by this. I think I know how to solve it for those that work as root, but for those that don't... I'm a little lost how to fix it without editing the scripts themselves (the scripts that come with Knoppix, in /etc/init.d, are those that I am referring to).

[angor]

Quazar:

>1.) Despite what looks like a correct PATH statement

Please check that your PATH environment contains /usr/local/bin. PATH contains colon-delimited entries, and I bet that
yours does not have /usr/local/bin *but* does have "." (a dot, without the quotes). The dot denotes the current directory
and is a not-so-wise element in PATH (for security reasons).

<code>
export PATH=$PATH:/usr/local/bin
</code>
should fix your problem temporarily; if it does, make it permanent in $HOME/.bashrc or /etc/profile or sth like that.

Nessus problem:

I guess you are not trying to install with "apt-get install"? There are *very* good reasons to use apt-get; if you don't,
the management of installed packages becomes your own responsibility and I think that you really don't want that.
In this case the Debian maintainers probably decided to put GTK in /some/path, while the Nessus authors try to find it
in /another/pass.

Keilaron:

programs under /sbin (= Static BINaries) are used to initialize the system, mostly at a time when dynamic libraries
cannot yet be accessed (hence statically linked). This is strictly root territory, and the reason why /sbin is not in the
user's PATH. If you want, you can modify your PATH to include /sbin (and /usr/sbin:/usr/local/sbin); however many
of the executeables there need you to be root, anyway.

[Keilaron]

Problem: We're talking about /etc/init.d/ scripts, and I like to have my daemons running under the appropriate username. (e.g. apache runs as www-data or something similar, mysqld runs as mysql, etc.)
Here's why this is a problem: start-stop-daemon only shows up in certain circumstances; this is because of the PATH.


programs under /sbin (= Static BINaries) are used to initialize the system, mostly at a time when dynamic libraries cannot yet be accessed (hence statically linked). This is strictly root territory, and the reason why /sbin is not in the
user's PATH. If you want, you can modify your PATH to include /sbin (and /usr/sbin:/usr/local/sbin); however many
of the executeables there need you to be root, anyway.
Oh?


# whereis start-stop-daemon
start-stop-daemon: /sbin/start-stop-daemon /usr/share/man/man8/start-stop-daemon
.8.gz
# which start-stop-daemon # (Note that this is the command scripts use to figure out where it is.)
/sbin/start-stop-daemon
# file /sbin
/sbin: symbolic link to `/UNIONFS/sbin'
# file /UNIONFS/sbin/
/UNIONFS/sbin/: directory
# ll -d /UNIONFS/sbin/
drwxr-xr-x 2 root root 30720 Apr 8 08:47 /UNIONFS/sbin/
# ll /UNIONFS/sbin/start-stop-daemon
-rwxr-xr-x 1 root root 18424 Feb 10 10:30 /UNIONFS/sbin/start-stop-daemon
Anyone can read/run it. /sbin just doesn't get put into the PATH by default.
=/
It gets added to the path in /etc/bashrc, but this seems to be ignored sometimes (even if the used shell is bash), possibly because of the way the scripts are configured (#!/bin/sh). Any way to add it to the "default" path?

[angor]

> I like to have my daemons running under the appropriate username.

I agree, but running ist not the same as starting. Apache, e.g., needs to bind to port 80 (443 for https) unless you
specify a non-standard port. You need root privileges to bind to ports < 1024. After that has been done, it is wise
to have Apache (or other daemon) switch to a non-privileged user, but you do this by configuring the daemon, not
by starting it as such.

[Keilaron]

Erroneous thought there... Apache is still running as root. It's children, yes, are running as another user - this is the default.
However, it is still running as root! It is, although unlikely, still possible to gain root access because of this.
Besides, I can bind any port and route port 80 to it. Not a problem.
And last I recall, this was the only issue I had: apache would run fine entirely under it's own username.

[Quazar]

Angor - Thanks for all the help..

I actually did a "apt-get update" to update the availiable packages, then used Kpackage to mark the 4 Nessus packages and only upgrade them (and their direct dependencies). Didn't want to break too much by upgrading the whole system...The only thing that was a little bit of a disappointment was that it only upgraded to 2.2.3 of Nessus, not 2.2.4 which is availiable @ http://www.nessus.org...

Everything seems to be working ok now...Thanks again for the assistance

FYI: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin:/usr/games