Re: Simple little basic config questions
I think you got Colin wrong there (Colin please correct me if *I* got you=20 wrong:) . Colin just gave an example how easy it is to exploit the=20 sudo-privilege for using dpkg. Ah, shoot, you're right. I totally glossed over the sudo example he suggested. I blame work; it totally gets in the way of concentrating on important stuff, like debian-user. Sowwy! Btw, does Colin = Pigeon? I'm confused on that count as well =P Sorry, somehow I managed to think the mail had been from Colin, not from Pigeon (probably I shouldn't write mail after 1:00am:) s/Colin/Pigeon/g Johannes -- More than machinery we need humanity -- Charlie Chaplin, The Great Dictator pgp0.pgp Description: signature
Re: Simple little basic config questions
On Thu, 30 Oct 2003, Haines Brown wrote: each user has a session and a session key. this key is used to authenticate yourself to the Xserver. Root as a key and each user does. Yes, that makes sense. so when you login as user and then switch to root, it tried to use your root key to access the user session-- no go. ? When I login as user, and then su - root, does not root then use its own session key? Are you saying that when I su - root, root tries to use user's session key? no. root uses its key but since you logged in as user, it tries roots keys in yser 'lock'(session). one solution is: user% xhost + user% su root! xcalc but this is an insecure hack since in says anyone can snoop on your xserver. but if you are not on the net or have a firewall it may be used, the better solution is to 'merge' your X authenticaion key database but I forgot the command. Thanks, Kev. My understanding of Linux is that normally you want to log in as user because being root carries with it certain risks. But regularly, we, running as user, find that we need to do something that requires root's privileges, and so we su - root. That's what I read in Running Linux and elsewhere. It's what I've been doing for years. So I assumed that by moving from RedHats to debian, things would continue as before. But they have not. So, the important question that still remains unansered: was my installation of debian flawed, or does debian simply work differently than what I assume? Haines This is correct. root will be able to delete any file, etc. -Kev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Thu, 30 Oct 2003, Monique Y. Herman wrote:
On Thu, 30 Oct 2003 at 15:52 GMT, Kent West penned:
I echo Colin's thought. Forget about su and use sudo. It takes an
extra 5 keystrokes per command, but it just works, and in my opinion
is better than forgetting you're root and doing something you don't
want to do.
apt-get install sudo visudo, add yourself a line similar to what's
already there sudo command_to_be_run_as_root
People keep talking about sudo like it's the cat's meow, and maybe for a
single-user system it is. But sudo documentation very explicitly warns
that, if you're not careful about what you allow, you could accidentally
allow access to far more than you expected.
Hi Monique,
like you said, you need to read the docs for muli-user systems. Sudo can
be setup to allow not just specific commands but a specific command with
specific parameters. ('ls' vs 'ls -l')
-Kev
Anyway, go ahead and use sudo, but be aware of the possible security
issues.
(Of course, it's by definition safer than just giving someone the root
password. I'm just saying, don't think it solves 100% of security
issues.)
--
monique
PLEASE don't CC me. Please. Pretty please with sugar on top.
Whatever it takes, just don't CC me! I'm already subscribed!!
(if anyone knows how to tell pine to do this, let me know, I hate having
to delete the 'to')
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
Application can't initialize because it lacks display name and no $DISPLAY environment variable. Look what I just found as a new package on unstable: Sux is a wrapper around the standard su command which will transfer your X credentials to the target user. http://sourceforge.net/projects/sux/ ( from http://fgouget.free.fr/sux/ ) Thanks, but that seems a workaround more than a fix. For example, if I logged in as root, I'd be in trouble, without access to a display. I need a statement that would put the default display into root's environment. Further, when I run su root without the -, I carry over user's environment, and so root acquires a display. I wonder what might have gone wrong to cause display to be missing for root in the first place. That is, was it the effect of a faulty new installation of debian 3.0r1 from cdrom disks, or is this a known bug? Haines Brown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
Please don't CC me. (If somehow my sig isn't clear enough, please let me know how I can make it so.) My apologies. The current auto CC: is something I did not have before, and so I'm not used to removing that line. I was aware I had forgotten to do that as soon as I had sent the message to you. Oh wait a minute. I just looked at my .bashrc, etc and think I've noticed the problem. Try simply doing this: DISPLAY=:0.0 export DISPLAY Seems to have brought some progress. Now, when I su - root and run: echo $DISPLAY :0.0 But apparently, all that does is to say that I've successfully assigned the value :0.0 to DISPLAY, but it does not seem to have been exported. That is I run an application that calls for display :0.0 and it still fails: Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to server Haines -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
Why not just use 'su' (with no parameters) or 'su - -p'? -m, -p, --preserve-environment do not reset environment variables, and keep the same shell That will preserve things like X display dettings. Just an idea. Perhaps it is a philosophical issue, but my instinct tells me that my root account should be self-contained. I should be able to log in as root and startx. To have to log in as a user, and then su to root, assumes there's a user account, and assumes that it is working. Both of these conditions do not always exist. Further, when I am logged in as user, when I su to root, I want to acquire root's environment. Haines -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Thu, 30 Oct 2003, Haines Brown wrote: Please don't CC me. (If somehow my sig isn't clear enough, please let me know how I can make it so.) My apologies. The current auto CC: is something I did not have before, and so I'm not used to removing that line. I was aware I had forgotten to do that as soon as I had sent the message to you. Oh wait a minute. I just looked at my .bashrc, etc and think I've noticed the problem. Try simply doing this: DISPLAY=:0.0 export DISPLAY Seems to have brought some progress. Now, when I su - root and run: echo $DISPLAY :0.0 But apparently, all that does is to say that I've successfully assigned the value :0.0 to DISPLAY, but it does not seem to have been exported. That is I run an application that calls for display :0.0 and it still fails: Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to server Haines each user has a session and a session key. this key is used to authenticate yourself to the Xserver. Root as a key and each user does. so when you login as user and then switch to root, it tried to use your root key to access the user session-- no go. one solution is: user% xhost + user% su root! xcalc but this is an insecure hack since in says anyone can snoop on your xserver. but if you are not on the net or have a firewall it may be used, the better solution is to 'merge' your X authenticaion key database but I forgot the command. -Kev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Thu, Oct 30, 2003 at 04:45:17AM -0500, Haines Brown wrote: Look what I just found as a new package on unstable: Sux is a wrapper around the standard su command which will transfer your X credentials to the target user. http://sourceforge.net/projects/sux/ ( from http://fgouget.free.fr/sux/ ) Thanks, but that seems a workaround more than a fix. For example, if I logged in as root, I'd be in trouble, without access to a display. No, I think if you had actually started X as root then you certainly would have an appropriate $DISPLAY. The issue is not really rootness, it's that $DISPLAY is set in the environment of the X session which is run as the user who started X, and .Xauthority is in the home directory of the user who started X, and it's quite easy to lose all that when changing users. 'sux' is not a workaround, it's a valid solution. Stepping back a bit: why would you ever want to start X as root? It's not generally considered a good idea. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
each user has a session and a session key. this key is used to authenticate yourself to the Xserver. Root as a key and each user does. Yes, that makes sense. so when you login as user and then switch to root, it tried to use your root key to access the user session-- no go. ? When I login as user, and then su - root, does not root then use its own session key? Are you saying that when I su - root, root tries to use user's session key? one solution is: user% xhost + user% su root! xcalc but this is an insecure hack since in says anyone can snoop on your xserver. but if you are not on the net or have a firewall it may be used, the better solution is to 'merge' your X authenticaion key database but I forgot the command. Thanks, Kev. My understanding of Linux is that normally you want to log in as user because being root carries with it certain risks. But regularly, we, running as user, find that we need to do something that requires root's privileges, and so we su - root. That's what I read in Running Linux and elsewhere. It's what I've been doing for years. So I assumed that by moving from RedHats to debian, things would continue as before. But they have not. So, the important question that still remains unansered: was my installation of debian flawed, or does debian simply work differently than what I assume? Haines -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
user% xhost + user% su root! xcalc but this is an insecure hack since in says anyone can snoop on your xserver. You could also use ``xhost +local:'' so that you don't open your xserver to the net. ``xhost +'' is something I would only advise for debugging-purpose only.. Johannes -- More than machinery we need humanity -- Charlie Chaplin, The Great Dictator pgp0.pgp Description: signature
Re: Simple little basic config questions
No, I think if you had actually started X as root then you certainly would have an appropriate $DISPLAY. The issue is not really rootness, it's that $DISPLAY is set in the environment of the X session which is run as the user who started X, and .Xauthority is in the home directory of the user who started X, and it's quite easy to lose all that when changing users. 'sux' is not a workaround, it's a valid solution. I notice that .Xauthority in /root has zero size. If it is going to authenticate root for the x server, I should think there would be something in it. When you say changing users, do you refer to logging in as user and then running su - root? I assume virtually everyone does this regularly and successfully, and so I assume my inability to do it is a sign that I need to do a fix. For years I didn't loose all that, but could su - root as I needed. I still don't know whether my system's busted or if it is me ;-) That is, is loosing all that a natural occurance or a flaw in my setup? I presume every debian user who is both user and administrator of his machine (probably the majority) will occasionally want to su to become root (I assume everyone does that regularly). Certainly they all don't have Sux installed. I appreciate that one does not want to run as root, but I do it when installing a new system or retreat to it when user's account ceases to function. Haines -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Thursday 30 October 2003 12:30, Haines Brown wrote: [...] For years I didn't loose all that, but could su - root as I needed. I still don't know whether my system's busted or if it is me ;-) That is, is loosing all that a natural occurance or a flaw in my setup? [...] The point is, ou need to omit the - if you want to inherit the ordinary user's environment - which includes his X-session (approximately, I'm no expert). BTW, you don't need to specify root - that is the default for su. So it is either su - when you will be in /root and with root's usual environment, or su when you will be able to use Xwindows and also will still have the same pwd (present working directory) and environment as immediately before the command. I don't think anything is broken in your setup. I do seem to recollect that, when I used RH, su- was able to use Xwindows, so it may be that some distros execute this differently. HTH -- richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Thu, Oct 30, 2003 at 05:40:37AM -0500, Haines Brown wrote:
each user has a session and a session key. this key is used to
authenticate yourself to the Xserver. Root as a key and each user
does.
Yes, that makes sense.
so when you login as user and then switch to root, it tried to use your
root key to access the user session-- no go.
? When I login as user, and then su - root, does not root then use
its own session key? Are you saying that when I su - root, root
tries to use user's session key?
The explanation above about each user having a session key is strange
and confusing to my eyes.
When you start X, an X session is created, associated with the X server
you've started. There is one of these per server, not one per user.
Similarly, there is only one key (called a cookie) for each X session,
not one per user. This lives in the .Xauthority file in the home
directory of whoever started X, but any other user who wants access to
the X server, including root, must get access to that .Xauthority file
somehow. ('xauth merge' etc. is the standard way to do this, but is a
bit fiddly; 'sux' wraps this all up in a convenient form.)
They must also find out the correct value of $DISPLAY, which again is
associated with the X server, and doesn't have one correct value that
you could just set globally for root or what-have-you.
My understanding of Linux is that normally you want to log in as user
because being root carries with it certain risks. But regularly, we,
running as user, find that we need to do something that requires root's
privileges, and so we su - root. That's what I read in Running
Linux and elsewhere. It's what I've been doing for years.
So I assumed that by moving from RedHats to debian, things would
continue as before. But they have not. So, the important question that
still remains unansered: was my installation of debian flawed, or does
debian simply work differently than what I assume?
'su - root' sets up your environment from scratch, and therefore deletes
the $DISPLAY variable. It's possible that Red Hat has a magic PAM module
for su that figures out what $DISPLAY is supposed to be and plugs it
back in, but that doesn't exist in Debian, and you shouldn't expect it
to exist in general on Unix systems. Your installation of Debian is not
flawed, just not the same as Red Hat.
'su root', without the dash, or just 'su' for short, would be better,
but still requires you to get the X cookie from somewhere. 'sux' does
all that for you.
'sudo' also appears to sort this out, although I think that's just
because it doesn't change $HOME, so it won't work if your home directory
is a root-squashed NFS mount. (If you don't know, it probably isn't.)
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Thu, Oct 30, 2003 at 06:30:14AM -0500, Haines Brown wrote: Colin Watson wrote: No, I think if you had actually started X as root then you certainly would have an appropriate $DISPLAY. The issue is not really rootness, it's that $DISPLAY is set in the environment of the X session which is run as the user who started X, and .Xauthority is in the home directory of the user who started X, and it's quite easy to lose all that when changing users. 'sux' is not a workaround, it's a valid solution. I notice that .Xauthority in /root has zero size. If it is going to authenticate root for the x server, I should think there would be something in it. root did not start X, and so it isn't authenticated. I'm not actually sure what creates the zero-length .Xauthority file: I've got an empty /root/.Xauthority too. I'd imagine, though, that 'sux' will fill it in using 'xauth merge'. When you say changing users, do you refer to logging in as user and then running su - root? Yes. I assume virtually everyone does this regularly and successfully, and so I assume my inability to do it is a sign that I need to do a fix. See my other message just a moment ago, please. 'su - root' is just wrong if you expect to run X programs; it deliberately loses $DISPLAY, and doesn't properly handle X cookies. Perhaps other systems have special hacks to make it work (it wouldn't surprise me if they did), but in general it doesn't work on Unix systems, and doesn't work on Debian. However, 'su - root' is fine if you're just doing regular command-line administration. (I'd use 'sudo' because I prefer to run commands only one at a time as root rather than starting an interactive root shell, but to each their own.) For years I didn't loose all that, but could su - root as I needed. I still don't know whether my system's busted or if it is me ;-) That is, is loosing all that a natural occurance or a flaw in my setup? It is a natural occurrence. I presume every debian user who is both user and administrator of his machine (probably the majority) will occasionally want to su to become root (I assume everyone does that regularly). Certainly they all don't have Sux installed. I become root occasionally, but I almost never run X programs as root, so no, this isn't an issue for me. I assume (and sincerely hope) that this is the common case. I appreciate that one does not want to run as root, but I do it when installing a new system or retreat to it when user's account ceases to function. Using the root account for administration is fine, but I only ever use command-line tools for administration. The X libraries are huge and have had at least their fair share of security holes; I think privileged use of them is unwise. (It's still possible to write graphical administration tools that run the graphical parts as an ordinary user and spawn small helper programs to make changes that require root privileges, and if I were writing such tools that's definitely the way I'd do it.) Anyway, this is all normal. Your Debian installation is fine. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
Johannes, Took your advice, and that seems to have worked. $ xhost +local non-network local connection being added to access control list $ su Password: # So I gave root access to the X server. Still don't understand why I had to do this rather than it being the default setup with an installation. Thanks! Haines Brown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
I don't think anything is broken in your setup. I do seem to recollect that, when I used RH, su- was able to use Xwindows, so it may be that some distros execute this differently. Yes, Richard, apparently I had work habits based on the RedHat setup, and didn't realize that under debian I'd have to add root to the access control list. My next question has to do with disabling screen blanking and power saving under X. This also may be the result of moving into a somewhat different setup when I moved from RedHat to debian. I had added to ~/.Xclients: xset s off xset -dpms But now that is having no effect. Haines -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
Haines Brown([EMAIL PROTECTED]) is reported to have said: I don't think anything is broken in your setup. I do seem to recollect that, when I used RH, su- was able to use Xwindows, so it may be that some distros execute this differently. Yes, Richard, apparently I had work habits based on the RedHat setup, and didn't realize that under debian I'd have to add root to the access control list. My next question has to do with disabling screen blanking and power saving under X. This also may be the result of moving into a somewhat different setup when I moved from RedHat to debian. I had added to ~/.Xclients: xset s off xset -dpms But now that is having no effect. see the man page at /usr/X11R6/man/man5/XF86Config-4.5x.gz -- Melted fruit snacks found on Keyboard. Delete nephew [Y/N]? ___ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
My next question has to do with disabling screen blanking and power saving under X. This also may be the result of moving into a somewhat different setup when I moved from RedHat to debian. I had added to ~/.Xclients: xset s off xset -dpms But now that is having no effect. see the man page at /usr/X11R6/man/man5/XF86Config-4.5x.gz I hadn't remembered that BlankTime, StandbyTimes, SuspendTime and OffTime could be set in this config file. But as the man page points out, the xset commands can be set at run time. Does that mean run time for x server? If so, where would the xset command be put? Do you think I could put them into /usr/X11R6/lib/X11/xinit/xserverrc ? Doing it this way seems a lot cleaner than plugging in enormous numbers of minutes for each of the ServerFlags options in XF86Config. Haines Brown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Thu, Oct 30, 2003 at 10:06:35AM -0500, Haines Brown wrote: But as the man page points out, the xset commands can be set at run time. Does that mean run time for x server? If so, where would the xset command be put? Do you think I could put them into /usr/X11R6/lib/X11/xinit/xserverrc ? You should put them in your .xsession (or .xinitrc if you're using startx). Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
Haines Brown([EMAIL PROTECTED]) is reported to have said: My next question has to do with disabling screen blanking and power saving under X. This also may be the result of moving into a somewhat different setup when I moved from RedHat to debian. I had added to ~/.Xclients: xset s off xset -dpms But now that is having no effect. see the man page at /usr/X11R6/man/man5/XF86Config-4.5x.gz I hadn't remembered that BlankTime, StandbyTimes, SuspendTime and OffTime could be set in this config file. I didn't know that either as I don't use them myself. But as the man page points out, the xset commands can be set at run time. Does that mean run time for x server? If so, where would the xset command be put? Do you think I could put them into /usr/X11R6/lib/X11/xinit/xserverrc ? Doing it this way seems a lot cleaner than plugging in enormous numbers of minutes for each of the ServerFlags options in XF86Config. To answer your questions I have been looking at the man pages, readme's and XFree86 Howto's. May you should look into them for your answers? -- You can tell how far we have to go, when FORTRAN is the language of supercomputers. -- Steven Feiner ___ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
Haines Brown wrote: But regularly, we, running as user, find that we need to do something that requires root's privileges, and so we su - root. . . . I presume every debian user who is both user and administrator of his machine (probably the majority) will occasionally want to su to become root (I assume everyone does that regularly). Colin Watson wrote: However, 'su - root' is fine if you're just doing regular command-line administration. (I'd use 'sudo' because I prefer to run commands only one at a time as root rather than starting an interactive root shell, but to each their own.) I echo Colin's thought. Forget about su and use sudo. It takes an extra 5 keystrokes per command, but it just works, and in my opinion is better than forgetting you're root and doing something you don't want to do. apt-get install sudo visudo, add yourself a line similar to what's already there sudo command_to_be_run_as_root -- Kent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
%% [EMAIL PROTECTED] (Haines Brown) writes: hb Johannes, hb Took your advice, and that seems to have worked. hb $ xhost +local hb non-network local connection being added to access control list hb $ su hb Password: hb # Well this doesn't prove anything: you have to run an X application as root before you can know whether it worked or not. This is still a bad idea, though, because anyone who can log into your box (via telnet or whatever) can access your X server. And anyone who can access your X server can see every key you type, everything that appears on your screen, etc. etc. hb So I gave root access to the X server. Still don't understand why hb I had to do this rather than it being the default setup with an hb installation. I'll try this... It's not the default because, as above, it's a very insecure and silly thing to do. If you were able to start X applications from the command line after running su on a Red Hat box, like this: $ su Password: # xclock then Red Hat must have opened up access to the X server, which is very, very bad. I'm _SURE_ they've fixed this by now, if they ever did it at all. You should be reading Colin's posts: he's got the right answers. Here are some notes which might help you: * Whomever starts the X server (that is, runs startx from the console or logs in via XDM or GDM or whatever), has access to use the X server. If you log in as root through XDM or running startx, then root has access to the X server. If you log in as yourself, then you have access to the X server. * Any other user, even root, even if you get to be that user by running su, does _NOT_ have access to use the X server (by default). * Access is (typically) controlled by means of a special cookie, called the XAUTH cookie. By default the user who starts the X server has that cookie, and no one else has it. Whomever has that cookie, has access to the X server. * So, if you want root to have access to the X server via su after you started it yourself, you have to give root that cookie. That can be done a number of ways, as previously described, but if you don't do this in some way then root can't access the X server. * Disabling access control via xhost + or xhost +local is a VERY BAD idea! People with access to the X server are really very serious security risks. If you must do it occasionally, be sure to undo it again quickly. Much better is installing tools so you have a reliable, secure method to invoke X apps which doesn't require disabling your security. In addition to the already-mentioned sux there is gksu which pops up a graphical box to enter the password then starts an X app: this is good for adding to menus and stuff. And, I have an xsudo script I wrote a few months ago which wraps sudo the same way sux wraps su (mine is lots shorter though so I'll have to look at sux and see what he's doing that I'm not :)). You may feel that it's annoying to have to go to this extra trouble to use X apps after running su, especially if for some reason you didn't have to before. But, it's a very serious security issue, so you should think of it as annoying in the same way having to type your password to log in is annoying. I hope this helps clarify things... -- --- Paul D. Smith [EMAIL PROTECTED] HASMAT--HA Software Mthds Tools Please remain calm...I may be mad, but I am a professional. --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
I echo Colin's thought. Forget about su and use sudo. It takes an
extra 5 keystrokes per command, but it just works, and in my opinion
is better than forgetting you're root and doing something you don't want
to do.
apt-get install sudo
visudo, add yourself a line similar to what's already there
sudo command_to_be_run_as_root
Thanks, Kent, I'll follow your advice. But that brings up my next
elementary question: getting packages.
I ran # netselect-apt woody in the /etc/apt directory, and as a result
built a /etc/apt/sources list that had a US and a non-US site
uncommented. OK, so next I run (ignore line breaks):
# apt-get install sudo
Reading Package Lists... Done
Building Dependency Tree... Done
W: Couldn't stat source package list http://ftp.br.debian.org
woody/main Packages
(/var/lib/apt/lists/ftp.br.debian.org_debian_dists_woody_main_binary-i386_Packages)
- stat (2 No such file or directory)
... [same for three directories in each of the two source sites
listed in sources list]
W: You may want to run apt-get update to correct these problems
E: Couldn't find package sudo
Well, running apt-get update just gives me exactly the same thing as
above. I added the following http subsection to /etc/apt.conf to enable
internet sources:
Acquire
{
Retries 0;
// I added this next subsection:
http
{
Proxy http://127.0.0.1:3128;;
Proxy::http.us.debian.org DIRECT; // Specific per-host setting
Timeout 120;
Pipeline-Depth 5;
// Cache Control. Note these do not work with Squid 2.0.2
No-Cache false;
Max-Age 86400; // 1 Day age on index files
No-Store false;// Prevent the cache from storing archives
};
};
// Things that effect the APT dselect method
DSelect
{
Clean auto; // always|auto|prompt|never
};
Haines
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
hb $ xhost +local hb non-network local connection being added to access control list hb $ su hb Password: hb # Well this doesn't prove anything: you have to run an X application as root before you can know whether it worked or not. This is still a bad idea, though, because anyone who can log into your box (via telnet or whatever) can access your X server. And anyone who can access your X server can see every key you type, everything that appears on your screen, etc. etc. Paul, you and Colin and Kent have persuaded me a) to use command line when I'm doing maintenance as root, b) run sudo. So now I need to undo the above. The man seems to suggest # xhost -local. Should that be done again as user? It's not the default because, as above, it's a very insecure and silly thing to do. If you were able to start X applications from the command line after running su on a Red Hat box, like this: $ su Password: # xclock then Red Hat must have opened up access to the X server, which is very, very bad. I'm _SURE_ they've fixed this by now, if they ever did it at all. I am persuaded. You should be reading Colin's posts: he's got the right answers. Here are some notes which might help you: I read your notes with interest, and indeed you helped clarify things. Only now, I've got somehow to undo the xhost command I issued before. Haines -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Thu, 30 Oct 2003 at 15:52 GMT, Kent West penned: I echo Colin's thought. Forget about su and use sudo. It takes an extra 5 keystrokes per command, but it just works, and in my opinion is better than forgetting you're root and doing something you don't want to do. apt-get install sudo visudo, add yourself a line similar to what's already there sudo command_to_be_run_as_root People keep talking about sudo like it's the cat's meow, and maybe for a single-user system it is. But sudo documentation very explicitly warns that, if you're not careful about what you allow, you could accidentally allow access to far more than you expected. Anyway, go ahead and use sudo, but be aware of the possible security issues. (Of course, it's by definition safer than just giving someone the root password. I'm just saying, don't think it solves 100% of security issues.) -- monique PLEASE don't CC me. Please. Pretty please with sugar on top. Whatever it takes, just don't CC me! I'm already subscribed!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Thu, Oct 30, 2003 at 11:03:23AM -0700, Monique Y. Herman wrote: On Thu, 30 Oct 2003 at 15:52 GMT, Kent West penned: I echo Colin's thought. Forget about su and use sudo. It takes an extra 5 keystrokes per command, but it just works, and in my opinion is better than forgetting you're root and doing something you don't want to do. apt-get install sudo visudo, add yourself a line similar to what's already there sudo command_to_be_run_as_root People keep talking about sudo like it's the cat's meow, and maybe for a single-user system it is. But sudo documentation very explicitly warns that, if you're not careful about what you allow, you could accidentally allow access to far more than you expected. ...it seems like a good idea on a single-user machine to allow sudo dpkg -i... sudo dpkg -i make_bash_setuid_root.deb -- Pigeon Be kind to pigeons Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x21C61F7F pgp0.pgp Description: PGP signature
Re: Simple little basic config questions
On Thu, 30 Oct 2003 at 20:43 GMT, Pigeon penned: --PLVMksexArUZ/iL3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 30, 2003 at 11:03:23AM -0700, Monique Y. Herman wrote: On Thu, 30 Oct 2003 at 15:52 GMT, Kent West penned: I echo Colin's thought. Forget about su and use sudo. It takes an extra 5 keystrokes per command, but it just works, and in my opinion is better than forgetting you're root and doing something you don't want to do. =20 apt-get install sudo visudo, add yourself a line similar to what's already there sudo command_to_be_run_as_root =20 =20 People keep talking about sudo like it's the cat's meow, and maybe for a single-user system it is. But sudo documentation very explicitly warns that, if you're not careful about what you allow, you could accidentally allow access to far more than you expected. =2E..it seems like a good idea on a single-user machine to allow sudo dpkg -i... sudo dpkg -i make_bash_setuid_root.deb I'm a bit confused ... you snipped out the part where I said that it's probably fine for a single-user machine, then added your own comment to that effect, and instructions for installing it ... For the record, I have it installed. But I still think that espousing sudo as a panacea, without encouraging people to read the documentation and understand the potential pitfalls, is not the right thing to do. -- monique PLEASE don't CC me. Please. Pretty please with sugar on top. Whatever it takes, just don't CC me! I'm already subscribed!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Thu, Oct 30, 2003 at 02:45:32PM -0700, Monique Y. Herman wrote: On Thu, 30 Oct 2003 at 20:43 GMT, Pigeon penned: --PLVMksexArUZ/iL3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 30, 2003 at 11:03:23AM -0700, Monique Y. Herman wrote: On Thu, 30 Oct 2003 at 15:52 GMT, Kent West penned: I echo Colin's thought. Forget about su and use sudo. It takes an extra 5 keystrokes per command, but it just works, and in my opinion is better than forgetting you're root and doing something you don't want to do. =20 apt-get install sudo visudo, add yourself a line similar to what's already there sudo command_to_be_run_as_root =20 =20 People keep talking about sudo like it's the cat's meow, and maybe for a single-user system it is. But sudo documentation very explicitly warns that, if you're not careful about what you allow, you could accidentally allow access to far more than you expected. =2E..it seems like a good idea on a single-user machine to allow sudo dpkg -i... sudo dpkg -i make_bash_setuid_root.deb I'm a bit confused ... you snipped out the part where I said that it's probably fine for a single-user machine, then added your own comment to that effect, and instructions for installing it ... Er, I left that bit in, then added an example to show how it may be little different from leaving root wide open if someone does get into your account... always a possibility if you're on the net. For the record, I have it installed. But I still think that espousing sudo as a panacea, without encouraging people to read the documentation and understand the potential pitfalls, is not the right thing to do. Agreed. -- Pigeon Be kind to pigeons Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x21C61F7F pgp0.pgp Description: PGP signature
Re: Simple little basic config questions
=20 People keep talking about sudo like it's the cat's meow, and maybe for a single-user system it is. But sudo documentation very explicitly warns that, if you're not careful about what you allow, you could accidentally allow access to far more than you expected. =2E..it seems like a good idea on a single-user machine to allow sudo dpkg -i... sudo dpkg -i make_bash_setuid_root.deb I'm a bit confused ... you snipped out the part where I said that it's probably fine for a single-user machine, then added your own comment to that effect, and instructions for installing it ... For the record, I have it installed. But I still think that espousing sudo as a panacea, without encouraging people to read the documentation and understand the potential pitfalls, is not the right thing to do. I think you got Colin wrong there (Colin please correct me if *I* got you wrong:) . Colin just gave an example how easy it is to exploit the sudo-privilege for using dpkg. Btw. allowing apt-get limits the packages you can install to a well defined pool, but I wouldn't bet anything on it being any more secure than allowing dpkg -i. (Can anyone bring light on this?) Johannes -- More than machinery we need humanity -- Charlie Chaplin, The Great Dictator pgp0.pgp Description: signature
Re: Simple little basic config questions
On Fri, 31 Oct 2003 at 00:14 GMT, Johannes Zarl penned: --Boundary-02=_nlao/nYI2HXprUI Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline =3D20 People keep talking about sudo like it's the cat's meow, and maybe for a single-user system it is. But sudo documentation very explicitly warns that, if you're not careful about what you allow, you could accidentally allow access to far more than you expected. =3D2E..it seems like a good idea on a single-user machine to allow sudo dpkg -i... sudo dpkg -i make_bash_setuid_root.deb I'm a bit confused ... you snipped out the part where I said that it's probably fine for a single-user machine, then added your own comment to that effect, and instructions for installing it ... For the record, I have it installed. But I still think that espousing sudo as a panacea, without encouraging people to read the documentation and understand the potential pitfalls, is not the right thing to do. I think you got Colin wrong there (Colin please correct me if *I* got you=20 wrong:) . Colin just gave an example how easy it is to exploit the=20 sudo-privilege for using dpkg. Ah, shoot, you're right. I totally glossed over the sudo example he suggested. I blame work; it totally gets in the way of concentrating on important stuff, like debian-user. Sowwy! Btw, does Colin = Pigeon? I'm confused on that count as well =P -- monique PLEASE don't CC me. Please. Pretty please with sugar on top. Whatever it takes, just don't CC me! I'm already subscribed!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Fri, 31 Oct 2003 at 00:04 GMT, Pigeon penned: =20 =3D2E..it seems like a good idea on a single-user machine to allow sudo dpkg -i... sudo dpkg -i make_bash_setuid_root.deb =20 =20 I'm a bit confused ... you snipped out the part where I said that it's probably fine for a single-user machine, then added your own comment to that effect, and instructions for installing it ...=20 Er, I left that bit in, then added an example to show how it may be little different from leaving root wide open if someone does get into your account... always a possibility if you're on the net. Apologies. I somehow totally missed the point of your sudo example. Please forgive me. -- monique PLEASE don't CC me. Please. Pretty please with sugar on top. Whatever it takes, just don't CC me! I'm already subscribed!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
I have more elementary configuration questions arising from my transition from RedHat to debian. Sorry to be a pest. I think this may be is a debian question because user can start the FileRunner file manager, but not root. When root tries, it gets the error: Application can't initialize because it lacks display name and no $DISPLAY environment variable. Error stgartup script: can't read tk_patchLevel: No such variable while executing. How do I interpret these? In fact, if I try # echo $DISPLAY, nothing is returned, which means the root account is not configured properly, I'd guess. It would make sense to define the value of DISPLAY globally, I should think. If so, how does one do that? The second part of the error statement would seem to be a script error, where the value of tk_patchLevel is never defined, but since user can run the application OK, I assume the problem is deeper than that. Could it be the missing DISPLAY? Haines Brown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Wed, 29 Oct 2003 at 18:34 GMT, Haines Brown penned: I have more elementary configuration questions arising from my transition from RedHat to debian. Sorry to be a pest. I think this may be is a debian question because user can start the FileRunner file manager, but not root. When root tries, it gets the error: Application can't initialize because it lacks display name and no $DISPLAY environment variable. Error stgartup script: can't read tk_patchLevel: No such variable while executing. How do I interpret these? In fact, if I try # echo $DISPLAY, nothing is returned, which means the root account is not configured properly, I'd guess. It would make sense to define the value of DISPLAY globally, I should think. If so, how does one do that? The second part of the error statement would seem to be a script error, where the value of tk_patchLevel is never defined, but since user can run the application OK, I assume the problem is deeper than that. Could it be the missing DISPLAY? Haines Brown You're probably using 'su -' to get to root, right? Two quick fixes: one, just use 'su' so that it keeps the original user's environment. Two, explicitly set your display to whatever it's normally set to for your users in root's .bashrc or .profile. Not having the display set can cause an amazing variety of errors, depending on the application. Don't worry about debugging the tk_patchLevel thing until you know that your display is set properly. -- monique PLEASE don't CC me. Please. Pretty please with sugar on top. Whatever it takes, just don't CC me! I'm already subscribed!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
I think this may be is a debian question because user can start the FileRunner file manager, but not root. When root tries, it gets the error: Application can't initialize because it lacks display name and no $DISPLAY environment variable. You're probably using 'su -' to get to root, right? Yes, you are quite right. explicitly set your display to whatever it's normally set to for your users in root's .bashrc or .profile. I tried: set DISPLAY teufel:0.0; export DISPLAY /root/.profile, but it. My sytax probably wrong. Can I substitute localhost here for teufel? Haines -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
Haines Brown wrote: I think this may be is a debian question because user can start the FileRunner file manager, but not root. When root tries, it gets the error: Application can't initialize because it lacks display name and no $DISPLAY environment variable. Error stgartup script: can't read tk_patchLevel: No such variable while executing. Are you logged into X as root, or as a normal user, and then opening a terminal, su'ing to root, and then running fr? If the first, it should work. If the latter, you'll probably find it easier (and arguably safer) to use sudo instead of su. -- Kent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Wed, 29 Oct 2003 at 21:53 GMT, Haines Brown penned: I think this may be is a debian question because user can start the FileRunner file manager, but not root. When root tries, it gets the error: Application can't initialize because it lacks display name and no $DISPLAY environment variable. You're probably using 'su -' to get to root, right? Yes, you are quite right. explicitly set your display to whatever it's normally set to for your users in root's .bashrc or .profile. I tried: set DISPLAY teufel:0.0; export DISPLAY /root/.profile, but it. My sytax probably wrong. Can I substitute localhost here for teufel? Haines If you're logged in as a normal user, what does env | grep DISPLAY show you? -- monique PLEASE don't CC me. Please. Pretty please with sugar on top. Whatever it takes, just don't CC me! I'm already subscribed!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
I tried: set DISPLAY teufel:0.0; export DISPLAY /root/.profile, but it. My sytax probably wrong. Can I substitute localhost here for teufel? If you're logged in as a normal user, what does env | grep DISPLAY show you? Monique, it displays as it should: :0.0. My problem only with root. Haines -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Wed, 29 Oct 2003 at 18:34 GMT, Haines Brown penned: I have more elementary configuration questions arising from my transition from RedHat to debian. Sorry to be a pest. I think this may be is a debian question because user can start the FileRunner file manager, but not root. When root tries, it gets the error: Application can't initialize because it lacks display name and no $DISPLAY environment variable. Error stgartup script: can't read tk_patchLevel: No such variable while executing. How do I interpret these? In fact, if I try # echo $DISPLAY, nothing is returned, which means the root account is not configured properly, I'd guess. It would make sense to define the value of DISPLAY globally, I should think. If so, how does one do that? The second part of the error statement would seem to be a script error, where the value of tk_patchLevel is never defined, but since user can run the application OK, I assume the problem is deeper than that. Could it be the missing DISPLAY? Haines Brown Look what I just found as a new package on unstable: Sux is a wrapper around the standard su command which will transfer your X credentials to the target user. http://sourceforge.net/projects/sux/ ( from http://fgouget.free.fr/sux/ ) -- monique PLEASE don't CC me. Please. Pretty please with sugar on top. Whatever it takes, just don't CC me! I'm already subscribed!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Thu, 30 Oct 2003 at 01:16 GMT, Haines Brown penned: I tried: set DISPLAY teufel:0.0; export DISPLAY /root/.profile, but it. My sytax probably wrong. Can I substitute localhost here for teufel? If you're logged in as a normal user, what does env | grep DISPLAY show you? Monique, it displays as it should: :0.0. My problem only with root. Haines Please don't CC me. (If somehow my sig isn't clear enough, please let me know how I can make it so.) Anyway, the point of my question and your answer: since your normal user successfully uses the setting of DISPLAY=:0.0 , I suggest trying ... Oh wait a minute. I just looked at my .bashrc, etc and think I've noticed the problem. Try simply doing this: DISPLAY=:0.0 export DISPLAY (note that I don't use set at all) Since :0.0 works, I don't see any real reason to use teufel explicitly, but if your hostname is properly set up, it shouldn't be a problem. And finally, please don't cc me =) -- monique PLEASE don't CC me. Please. Pretty please with sugar on top. Whatever it takes, just don't CC me! I'm already subscribed!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
Monique Y. Herman wrote: Monique, it displays as it should: :0.0. My problem only with root. Haines Please don't CC me. (If somehow my sig isn't clear enough, please let me know how I can make it so.) Anyway, the point of my question and your answer: since your normal user successfully uses the setting of DISPLAY=:0.0 , I suggest trying ... Oh wait a minute. I just looked at my .bashrc, etc and think I've noticed the problem. Try simply doing this: DISPLAY=:0.0 export DISPLAY (note that I don't use set at all) Since :0.0 works, I don't see any real reason to use teufel explicitly, but if your hostname is properly set up, it shouldn't be a problem. Why not just use 'su' (with no parameters) or 'su - -p'? -m, -p, --preserve-environment do not reset environment variables, and keep the same shell That will preserve things like X display dettings. Just an idea. -Roberto pgp0.pgp Description: PGP signature
Re: Simple little basic config questions
On Sun, Oct 26, 2003 at 07:57:20AM -0500, Haines Brown wrote: As for setting up basic bash configuration, a little experimentation shows that this is what I've got (debian 3.0r1). Root has both .bashrc and .profile, and the configuations (custom bash prompt and setterm) can go in either place. User has a .bashrc and .bash_profile (there's no .profile), and the configuration must go into the latter. It does not work for me if put into .bashrc. I once gathered this information (is this right ?): # ~/.profile, at login autoread by all Bourne-compatible shells \ (after /etc/profile) # ~/.profile is *NOT* executed by bash shell if ~/.bash_profile exists # All 2nd level bash shells will read ~/.bashrc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Sat, 25 Oct 2003, Haines Brown wrote: In moving from RedHat to debian, I'm left with some simple little basic configuration questions. They all relate to a situation in which I operate at this point from console. 1. Where do I set the global bash prompt format? I changed PS1= in /etc/profile, but that only affects user, not root. 2. I had placed the command setterm -blank 0 in RedHat's /etc/rc.d/rc.local to block screen blanking while running in console. Debian does not use that file. What is its equivalent? 3. My usual practice is to avoid xdm and boot to a text login prompt. To do this, in rc2.d I belive I edited the symlink to the xdm program, renaming S99xdm -... to K99xdm - But in debian I get a beep when I try. Am I imagining I once edited the name of a symlink? Can't one do it in debian? snip Hi H, one of the 'freedoms' of debian is that runlevel 2 to 5 are the same. 2 is the default runlevel. RH and others have seperate runlevels. Its something that confused me and there are some people out there like me who like the RH runlevel scheme but havent changed prevailing minds. Oh well! -Kev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Sat, Oct 25, 2003 at 09:08:48PM -0500, Ron Johnson wrote: On Sat, 2003-10-25 at 19:57, Haines Brown wrote: 3. My usual practice is to avoid xdm and boot to a text login prompt. To do this, in rc2.d I belive I edited the symlink to the xdm program, renaming S99xdm -... to K99xdm - But in debian I get a beep when I try. Am I imagining I once edited the name of a symlink? Can't one do it in debian? That's almost exactly what I did: # cd /etc/rc2.d # mv S99xdm __S99xdm You get a beep when you try to rename the file? If so, are you sure the file /etc/rc2.d/S99xdm exists? Of course, you could always deinstall xdm : # apt-get --purge remove xdm If one installs (x/g/k)dm and does use intend to use it, removing it is the best option. But, if your server is not properly configured and you intend to try something else, booting into (x/g/k)dm should be temporarily disabled. I generally do not manually create/remove symlinks in rd?.d. I just do a update-rc.d -f xdm remove will do all the work for you. HTH, -- Sridhar M.A. It is easier to get forgiveness than permission. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Sat, Oct 25, 2003 at 09:08:48PM -0500, Ron Johnson wrote: Of course, you could always deinstall xdm : # apt-get --purge remove xdm apt-get remove --purge xdm -- David Jardine Running Debian GNU/Linux and loving every minute of it. -Sacher M. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Sat, Oct 25, 2003 at 10:26:29PM -0500, Kent West wrote: Haines Brown wrote: In moving from RedHat to debian, I'm left with some simple little basic configuration questions. They all relate to a situation in which I operate at this point from console. 1. Where do I set the global bash prompt format? I changed PS1= in /etc/profile, but that only affects user, not root. This is the place; however, users can over-ride this by creating their own ~/.profile file. I believe a typical Debian setup does not have personal .profiles in users' home directories by default, but there is one in root's home directory by default. My system (woody) sets up .bash_profile when a new user is added. 2. I had placed the command setterm -blank 0 in RedHat's /etc/rc.d/rc.local to block screen blanking while running in console. Debian does not use that file. What is its equivalent? Sorry; can't address this one. 3. My usual practice is to avoid xdm and boot to a text login prompt. To do this, in rc2.d I belive I edited the symlink to the xdm program, renaming S99xdm -... to K99xdm - But in debian I get a beep when I try. Am I imagining I once edited the name of a symlink? Can't one do it in debian? Yes, you can do it in Debian. I'm not sure when you're getting the beep; is it when you're trying to rename the file, or when the script runs, or what? However, if you don't ever want xdm to run, I'd suggest you just remove it: apt-get --purge remove xdm You can always reinstall it later if you want it: apt-get install xdm There are other ways to defeat xdm also, such as renaming the actual script (not just the symlink) in /etc/init.d, or by placing an exit 0 as the first executable line in the script. -- Kent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- David Jardine Running Debian GNU/Linux and loving every minute of it. -Sacher M. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Sun, 2003-10-26 at 04:26, David Jardine wrote: On Sat, Oct 25, 2003 at 09:08:48PM -0500, Ron Johnson wrote: Of course, you could always deinstall xdm : # apt-get --purge remove xdm apt-get remove --purge xdm Doesn't matter which way it's ordered. # apt-get -s remove --purge mc Reading Package Lists... Done Building Dependency Tree... Done The following packages will be REMOVED: mc* 0 upgraded, 0 newly installed, 1 to remove and 457 not upgraded. Purg mc (1:4.6.0-5 Debian:testing) # apt-get -s --purge remove mc Reading Package Lists... Done Building Dependency Tree... Done The following packages will be REMOVED: mc* 0 upgraded, 0 newly installed, 1 to remove and 457 not upgraded. Purg mc (1:4.6.0-5 Debian:testing) -- David Jardine Running Debian GNU/Linux and loving every minute of it. -Sacher M. -- - Ron Johnson, Jr. [EMAIL PROTECTED] Jefferson, LA USA You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time. Bertrand Meyer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Sat, 2003-10-25 at 19:57, Haines Brown wrote: 1. Where do I set the global bash prompt format? I changed PS1= in /etc/profile, but that only affects user, not root. 2. I had placed the command setterm -blank 0 in RedHat's /etc/rc.d/rc.local to block screen blanking while running in console. Debian does not use that file. What is its equivalent? 3. My usual practice is to avoid xdm and boot to a text login prompt. To do this, in rc2.d I belive I edited the symlink to the xdm program, renaming S99xdm -... to K99xdm - But in debian I get a beep when I try. Am I imagining I once edited the name of a symlink? Can't one do it in debian? That's almost exactly what I did: # cd /etc/rc2.d # mv S99xdm __S99xdm Yes, I was trying to edit the word in emacs in a console, and emacs was playing tricks on me. But renmaing with mv worked fine. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
Thanks, Wayne. I had previously done the basic configurations globally rather than in ~/.bashrc, but your suggestion to do it for each user has a backup advantage. Haines -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
As for setting up basic bash configuration, a little experimentation shows that this is what I've got (debian 3.0r1). Root has both .bashrc and .profile, and the configuations (custom bash prompt and setterm) can go in either place. User has a .bashrc and .bash_profile (there's no .profile), and the configuration must go into the latter. It does not work for me if put into .bashrc. Thanks for alerting me to this difference. Haines -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
Kev writes: one of the 'freedoms' of debian is that runlevel 2 to 5 are the same. 2 is the default runlevel. RH and others have seperate runlevels. Its something that confused me and there are some people out there like me who like the RH runlevel scheme but havent changed prevailing minds. No need to change minds. Just change your runlevels to whatever you want them to be. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
one of the 'freedoms' of debian is that runlevel 2 to 5 are the same. 2 is the default runlevel. RH and others have seperate runlevels. Its something that confused me and there are some people out there like me who like the RH runlevel scheme but havent changed prevailing minds. Oh well! Kev, Yes, my sense has been that in principle one designs a set of alternative run levels 3-5, leaving runlevel 2 in its default state, and than for whatever reason, you switch runlevels to get a different setup. I suspect that this involves a command such as # init 5, but I've never tried it. Does that init command simply change the default runlevel? It seems that default is set in /etc/inittab, where it has: id:5:initdefault: . I assume you can also simply edit this line to change the default runlevel when you boot up. Haines -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Sat, Oct 25, 2003 at 09:08:48PM -0500, Ron Johnson wrote: Of course, you could always deinstall xdm : # apt-get --purge remove xdm apt-get remove --purge xdm Yes, on second thought, removal might be best, since I'll never use xdm, and with a new install, this is a good time to clean house before I fill it with new furniture. For example, I'm now running postfix, but exim seems to be around as a result of basic installation. The apt-get remove --purge command I understand will remove exim's configuration files as well. I hope it would not abuse any files that postfix needs. I guess the aptitude equivalent would simply be # aptitude purge packagename. Haines -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Sat, Oct 25, 2003 at 08:57:41PM -0400, Haines Brown wrote: In moving from RedHat to debian, I'm left with some simple little basic configuration questions. They all relate to a situation in which I operate at this point from console. 1. Where do I set the global bash prompt format? I changed PS1= in /etc/profile, but that only affects user, not root. ~/.bash_profile for users /root/.profile for root 2. I had placed the command setterm -blank 0 in RedHat's /etc/rc.d/rc.local to block screen blanking while running in console. Debian does not use that file. What is its equivalent? Debian uses a directory-full of separate scripts - /etc/init.d - which are called through symlinks in /etc/rc*. You set one up yourself: # cat /etc/init.d/noblank #!/bin/sh /usr/bin/setterm -blank 0 echo 'Console blanking disabled' ^D # chmod a+x /etc/init.d/noblank # ln -s /etc/init.d/noblank /etc/rcS.d/S99noblank 3. My usual practice is to avoid xdm and boot to a text login prompt. To do this, in rc2.d I belive I edited the symlink to the xdm program, renaming S99xdm -... to K99xdm - But in debian I get a beep when I try. Am I imagining I once edited the name of a symlink? Can't one do it in debian? Sure... dunno about this beep, because I use the command line for stuff like this... # cd /etc/rc2.d # mv S99xdm K99xdm ...if that doesn't work, it'll still give you more informative error messages than a beep. -- Pigeon Be kind to pigeons Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x21C61F7F pgp0.pgp Description: PGP signature
Re: Simple little basic config questions
Haines Brown wrote: Haines Brown([EMAIL PROTECTED]) is reported to have said: prompt and setterm) can go in either place. User has a .bashrc and .bash_profile (there's no .profile), and the configuration must go into the latter. It does not work for me if put into .bashrc. Do you have source .bashrc As the last line of your .bash_profile? That might help. No, the default (debian3.0r.1) is to comment that in .bash_profile: # if [ -f ~/.bashrc]; then # source ~./bashrc # fi I don't see why this is commented, for it seems to disable ~/.bashrc. Is that so? If so, why it it disabled by default? Sometimes ~/.bashrc is read on login; sometimes ~/.bash_profile is read. I never can remember when one is and the other isn't. Leaving these lines doesn't "disable ~/.bashrc"; it just prevents the reading of that file when ~/.bash_profile is read. I just uncomment the three lines above and let Debian sort it out. Note, just in case you didn't know this. After making changes to these files it is not necessary to exit and relogin. Just enter . .bash_profile I don't understand. "Enter" what into ~/.bash_profile? What does your elipsis here refer to? It's not an ellipsis. The first dot is short-hand for "source", roughly meaning "run the .bash_profile 'script'". You could alternatively enter this same command as "source .bash_profile". -- Kent
Re: Simple little basic config questions
Which is generated by the adduser routine by copying the skeleton files from /etc/skel. You can add other files in this directory if you want them to be added to new users' home directories. Interesting--the plot thickens! So, if one wants to set a global configuration for bash, such as a custom prompt or setterm= then the way to do it is to edit the files in /etc/skel. For example, I could uncomment in /etc/skel/bash_profile the section that has source ~./bashrc and then in the /etc/skel/bashrc file enter my custom value for PS1= or commands such as setterm = ... All this is entirely new to me ;-). Haines -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
Haines Brown wrote: Which is generated by the adduser routine by copying the skeleton files from /etc/skel. You can add other files in this directory if you want them to be added to new users' home directories. Interesting--the plot thickens! So, if one wants to set a global configuration for bash, such as a custom prompt or setterm= then the way to do it is to edit the files in /etc/skel. For example, I could uncomment in /etc/skel/bash_profile the section that has source ~./bashrc and then in the /etc/skel/bashrc file enter my custom value for PS1= or commands such as setterm = ... All this is entirely new to me ;-). Haines But only for new users. This won't affect existing users, as these files are copied into the users' home directories when the user is created using adduser. -- Kent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Sat, Oct 25, 2003 at 08:57:41PM -0400, Haines Brown wrote:
...
3. My usual practice is to avoid xdm and boot to a text login
prompt. To do this, in rc2.d I belive I edited the symlink to the
xdm program, renaming S99xdm -... to K99xdm - But in
debian I get a beep when I try. Am I imagining I once edited the
name of a symlink? Can't one do it in debian?
Haines Brown
Same with me,
if you'd like some additional first aid to temporarily remove / restore
any command in '/etc/init.d/' (including all related softlinks), you
might try my bash script, I named '/usr/local/bash/init.d':
###
#!/bin/sh
# \wwf 9.3.02
USE () {
echo
echo
echo Save+Remove // Restore Start_Stop Files in /etc/init.d/
echo
setterm -bold on
echo 'including related Links in /etc/rc?.d/'
setterm -bold off
echo
echo
echo usage:
echo
echo $0 [{-s|-r}] fname ...(-s = default)
echo
echo '( put Filename Wildcards in Double-Quotes: *, ? )'
echo
echo
echo 'Options:'
echo ''
echo '-s = (S)avefiles to /etc/init.d/SAVE/file.tar.gz'
echo '-r = (R)estore files from /etc/init.d/SAVE/file.tar.gz'
echo
echo '(-s: Files are MOVED from Directories to Archive)'
echo '(-r: Files are MOVED from Archive to Directories)'
echo
echo
}
Save () {
test -d /etc/init.d/SAVE || mkdir /etc/init.d/SAVE
echo Save+Deinstall init.d Files to /etc/init.d/SAVE/file.tar.gz
echo =
cd /etc/init.d
for FILE in [EMAIL PROTECTED]; do
echo
# Skip bad Params
if [ ! -f ${FILE} ]; then
echo /etc/init.d/${FILE}: NO FILE -- skipping Param
echo --
echo
continue ## comment this line: save links only
# ## when /etc/init.d/file is missing
fi
if [ -f SAVE/${FILE}.tar.gz ]; then
echo Dest_Archive already exists:
echo NO REwriting to /etc/SAVE/${FILE}.tar.gz -- skipping Param
echo --
echo
continue
fi
# Begin of Job
echo -n Save+Deinstall /etc/init.d/${FILE} ? ; read answ
case $answ in
y*|Y*|j*|J*) echo Answer = ${answ};; # Save Files
* ) echo Answer = ${answ}:NO Action -- skipping Param
echo
continue
esac
echo
echo Saving spec''d Files to /etc/init.d/SAVE/${FILE}.tar.gz
echo -
find /etc/rc* /etc/init.d -name *${FILE} | \
tar -cvzf /etc/init.d/SAVE/${FILE}.tar.gz -PT -
echo
echo Comparing Tar Archive to orig. Source Files
echo ---
tar -dvzf /etc/init.d/SAVE/${FILE}.tar.gz
if [ `echo $?` = 0 ]; then
echo
echo ==
echo All Files saved OK
echo ==
echo
echo -n Remove saved Source Files now ? ; read answ
case $answ in
y*|Y*|j*|J*) echo Answer = ${answ};; # Remove Files
* ) echo Answer = ${answ}: Files NOT removed
iecho
continue
esac
echo
echo Removing saved Files from /etc/rc*/ /etc/init.a/
find /etc/rc* /etc/init.d -name *${FILE} -exec rm {} \;
else
echo
echo ERROR, BAD Match!!
echo ==
echo /etc/init.d/SAVE/${FILE}.tar.gz differs to
echo Source Files in /etc/rc*/, /etc/init.d/
echo NO File removed
echo
fi
done
}
Restore () {
echo Reinstall Files from /etc/init.d/SAVE/file.tar.gz
echo ---
cd /etc/init.d/SAVE/
for FILE in [EMAIL PROTECTED]; do
echo
ARCHIV=
[ -f ${FILE} ] ARCHIV=${FILE}
[ -f ${FILE}.tar.gz ] ARCHIV=${FILE}.tar.gz
## echo File = ${FILE} Archive = ${ARCHIV}; read answ
if [ -z ${ARCHIV} ]; then
echo NO matching Archive: ${FILE} -- skipping Param
echo
continue
fi
echo -n Reinstall ${ARCHIV} ? ; read answ
case $answ in
y*|Y*|j*|J*) ;; # Answer = 'yes', start Job
* ) echo Answer = ${answ}: NO Action taken!!;
echo
continue;;
esac
echo Reinstalling Archive to /etc/rc*, /etc/init.d/
tar -xvkzf ${ARCHIV} -P
echo -n Remove ${ARCHIV} now ? ; read answ
case $answ in
y*|Y*|j*|J*) echo Answer = ${answ};; # Remove Archive
* ) echo Answer = ${answ}: Archive NOT removed
Re: Simple little basic config questions
Haines Brown([EMAIL PROTECTED]) is reported to have said: As for setting up basic bash configuration, a little experimentation shows that this is what I've got (debian 3.0r1). Root has both .bashrc and .profile, and the configuations (custom bash prompt and setterm) can go in either place. User has a .bashrc and .bash_profile (there's no .profile), and the configuration must go into the latter. It does not work for me if put into .bashrc. Do you have source .bashrc As the last line of your .bash_profile? That might help. Note, just in case you didn't know this. After making changes to these files it is not necessary to exit and relogin. Just enter . .bash_profile As long as you have the above in .bash_profile, any changes to either file will take effect. Oh, welcome to Debian. You won't be sorry you switched from RH!! Wayne -- Unix IS user friendly. It's just selective about who its friends are. ___ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
Haines Brown([EMAIL PROTECTED]) is reported to have said: Do you have source .bashrc As the last line of your .bash_profile? That might help. No, the default (debian3.0r.1) is to comment that in .bash_profile: # if [ -f ~/.bashrc]; then # source ~./bashrc # fi I don't see why this is commented, for it seems to disable ~/.bashrc. Is that so? If so, why it it disabled by default? I haven't done a fresh Debian install in many years so don't remember if I ever saw that in my original install. It does disable sourceing .bashrc and I don't know why it is disabled by default. :-( Maybe 'man bash' and a search on .bashrc would help. Note, just in case you didn't know this. After making changes to these files it is not necessary to exit and relogin. Just enter . .bash_profile I don't understand. Enter what into ~/.bash_profile? What does your elipsis here refer to? enter it at the prompt, ie VT5 wtopa-Buddy:~$. .bash_profile or VT5 wtopa-Buddy:~$source .bash_profile will re-read .bash_profile and, if you added source .bashrc to .bash_profile, the .bashrc as well. Same as if you had exited and logged in again. Oh, welcome to Debian. You won't be sorry you switched from RH!! I don't know if this comment is accurate, but RedHat seemed to be moving toward a more integrated desktop, which a) caused unexpected problems b) that are harder to resolve. As I have not run RH for a looong time, I am not 'up' on what is does currently. I do remember that upgrading was a real pain, a pain I have not felt since moving to Debian. :-) :-) HTH, YMMV, HAND :-) -- Press any key to continue or any other key to quit... ___ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
David Jardine wrote: On Sat, Oct 25, 2003 at 10:26:29PM -0500, Kent West wrote: Haines Brown wrote: In moving from RedHat to debian, I'm left with some simple little basic configuration questions. They all relate to a situation in which I operate at this point from console. 1. Where do I set the global bash prompt format? I changed PS1= in /etc/profile, but that only affects user, not root. This is the place; however, users can over-ride this by creating their own ~/.profile file. I believe a typical Debian setup does not have personal .profiles in users' home directories by default, but there is one in root's home directory by default. My system (woody) sets up .bash_profile when a new user is added. Which is generated by the adduser routine by copying the skeleton files from /etc/skel. You can add other files in this directory if you want them to be added to new users' home directories. -- Kent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
Haines Brown([EMAIL PROTECTED]) is reported to have said: prompt and setterm) can go in either place. User has a .bashrc and .bash_profile (there's no .profile), and the configuration must go into the latter. It does not work for me if put into .bashrc. Do you have source .bashrc As the last line of your .bash_profile? That might help. No, the default (debian3.0r.1) is to comment that in .bash_profile: # if [ -f ~/.bashrc]; then # source ~./bashrc # fi I don't see why this is commented, for it seems to disable ~/.bashrc. Is that so? If so, why it it disabled by default? Note, just in case you didn't know this. After making changes to these files it is not necessary to exit and relogin. Just enter . .bash_profile I don't understand. Enter what into ~/.bash_profile? What does your elipsis here refer to? As long as you have the above in .bash_profile, any changes to either file will take effect. Interesting. Oh, welcome to Debian. You won't be sorry you switched from RH!! I don't know if this comment is accurate, but RedHat seemed to be moving toward a more integrated desktop, which a) caused unexpected problems b) that are harder to resolve. Haines -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Simple little basic config questions
In moving from RedHat to debian, I'm left with some simple little basic configuration questions. They all relate to a situation in which I operate at this point from console. 1. Where do I set the global bash prompt format? I changed PS1= in /etc/profile, but that only affects user, not root. 2. I had placed the command setterm -blank 0 in RedHat's /etc/rc.d/rc.local to block screen blanking while running in console. Debian does not use that file. What is its equivalent? 3. My usual practice is to avoid xdm and boot to a text login prompt. To do this, in rc2.d I belive I edited the symlink to the xdm program, renaming S99xdm -... to K99xdm - But in debian I get a beep when I try. Am I imagining I once edited the name of a symlink? Can't one do it in debian? Haines Brown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
Haines Brown([EMAIL PROTECTED]) is reported to have said:
In moving from RedHat to debian, I'm left with some simple little
basic configuration questions. They all relate to a situation in which
I operate at this point from console.
1. Where do I set the global bash prompt format? I changed PS1= in
/etc/profile, but that only affects user, not root.
.bash_profile or .bashrc in users home dir.
(Below on 1 line)
.bash_profile:export PS1=\[`setterm -foreground
cyan`\]VT${V_TERM##/dev/tty} \u-Buddy:\w\\$\[`setterm -default`\]
2. I had placed the command setterm -blank 0 in RedHat's
/etc/rc.d/rc.local to block screen blanking while running in
console. Debian does not use that file. What is its equivalent?
Same place as #1
3. My usual practice is to avoid xdm and boot to a text login
prompt. To do this, in rc2.d I belive I edited the symlink to the
xdm program, renaming S99xdm -... to K99xdm - But in
debian I get a beep when I try. Am I imagining I once edited the
name of a symlink? Can't one do it in debian?
I also boot to text login. I never installed xdm or any other display
manager so it boots into text.
:-) HTH, YMMV, HAND :-)
Wayne
--
Linux - for those that deserve the Very Best!
___
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
On Sat, 2003-10-25 at 19:57, Haines Brown wrote: In moving from RedHat to debian, I'm left with some simple little basic configuration questions. They all relate to a situation in which I operate at this point from console. 1. Where do I set the global bash prompt format? I changed PS1= in /etc/profile, but that only affects user, not root. 2. I had placed the command setterm -blank 0 in RedHat's /etc/rc.d/rc.local to block screen blanking while running in console. Debian does not use that file. What is its equivalent? 3. My usual practice is to avoid xdm and boot to a text login prompt. To do this, in rc2.d I belive I edited the symlink to the xdm program, renaming S99xdm -... to K99xdm - But in debian I get a beep when I try. Am I imagining I once edited the name of a symlink? Can't one do it in debian? That's almost exactly what I did: # cd /etc/rc2.d # mv S99xdm __S99xdm You get a beep when you try to rename the file? If so, are you sure the file /etc/rc2.d/S99xdm exists? Of course, you could always deinstall xdm : # apt-get --purge remove xdm -- - Ron Johnson, Jr. [EMAIL PROTECTED] Jefferson, LA USA Basically, I got on the plane with a bomb. Basically, I tried to ignite it. Basically, yeah, I intended to damage the plane. RICHARD REID, tried to blow up American Airlines Flight 63 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple little basic config questions
Haines Brown wrote: In moving from RedHat to debian, I'm left with some simple little basic configuration questions. They all relate to a situation in which I operate at this point from console. 1. Where do I set the global bash prompt format? I changed PS1= in /etc/profile, but that only affects user, not root. This is the place; however, users can over-ride this by creating their own ~/.profile file. I believe a typical Debian setup does not have personal .profiles in users' home directories by default, but there is one in root's home directory by default. 2. I had placed the command setterm -blank 0 in RedHat's /etc/rc.d/rc.local to block screen blanking while running in console. Debian does not use that file. What is its equivalent? Sorry; can't address this one. 3. My usual practice is to avoid xdm and boot to a text login prompt. To do this, in rc2.d I belive I edited the symlink to the xdm program, renaming S99xdm -... to K99xdm - But in debian I get a beep when I try. Am I imagining I once edited the name of a symlink? Can't one do it in debian? Yes, you can do it in Debian. I'm not sure when you're getting the beep; is it when you're trying to rename the file, or when the script runs, or what? However, if you don't ever want xdm to run, I'd suggest you just remove it: apt-get --purge remove xdm You can always reinstall it later if you want it: apt-get install xdm There are other ways to defeat xdm also, such as renaming the actual script (not just the symlink) in /etc/init.d, or by placing an exit 0 as the first executable line in the script. -- Kent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
