Hi Matt!! I don't report a bug due to misconfiguration. Let's see if what you see applies, though.
Matt Zimmerman wrote: > First, "man su" to find out where su(1) is getting its environment from. > Searching for 'environment' on that man page, you can find this: > > The current environment is passed to the new shell. The > value of $PATH is reset to /bin:/usr/bin for normal users, > or /sbin:/bin:/usr/sbin:/usr/bin for the super user. This > may be changed with the ENV_PATH and ENV_SUPATH defini- > tions in /etc/login.defs. When using the -m or -p options, > the users environment is not changed. > > Then, read /etc/login.defs. Note the values of the ENV_PATH and ENV_SUPATH > options. These are used by login(1) and su(1). Test login(1) and su(1) and > make sure they are doing what you expect. If they aren't, find out why. If > they are behaving contrary to their documentation, file a bug. If they are, > continue. > [EMAIL PROTECTED]:~$ cat /etc/login.defs | grep ENV # Three items must be defined: MAIL_DIR, ENV_SUPATH, and ENV_PATH. #ENV_TZ TZ=CST6CDT #ENV_TZ /etc/tzname ENV_HZ HZ=100 #ENV_HZ HZ=1024 ENV_SUPATH PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games #ENVIRON_FILE See Matt? This isn't the source of the problem. I didn't even touch it. Let's go on, sure. I'll try to overlook your insults and get to solve the problem. I checked it and it seems that I can login on this box (woody) directly with the SU path when I login from the console as root. But on borg which I observed the bug, when I login as root I only get the ENV_PATH > "man telnetd". Find out where telnetd is supposed to be getting its > environment from. Traditionally, telnetd has called login(1) to complete the > login process, but it sounds like that may have changed, or different options > are being used. I don't run telnetd (and neither should you), so I can't walk > you through this step as I don't have the package installed. > I used telnet to demonstrate how it looks to a normal root login. We use telnet here because this is a diverse university network; we can't force people to run ssh and any moron could go root on this machine if he really wanted to. No tight physical security either. We trust each other here. > Those are the major components that you're dealing with. Investigate the > problem step by step, testing each component individually, and determine which > component is causing the problem. If the problem appears to be caused by a > software bug, isolate the smallest possible test case, and report a bug > against > the package which contains the buggy component. Optionally, you may > investigate further, fix the problem, and include a patch. > Really? Unfortunately Matt the components don't really include telnetd. > Thank you for attending UNIX System Administration 101, followed by a brief > introduction to deductive problem solving. Now please stop reporting bugs > against general, and subscribe to a UNIX help mailing list. Why are you pretending that this is an FAQ. This happened twice on systems that I used, and was caused by an upgrade. I marked it important not because it is difficult to solve, but because it would apparently disrupt operation in a bad way. If you have a valid reason, you may decrease the priority to normal but otherwise stop ranting and try to help solving it. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
