Enviromental Variables issue in Knoppix 3.7.1 installed to H

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...

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)

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....

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).

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.

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.

Quote:

---

Originally Posted by angor

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?

Code:

---

# 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?

> 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.

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.

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