Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
This simply means that root is not allowed to launch a new window into the regular user's space from the commandline. There are security reasons for this. Synaptic is usually installed in the apps->system menu (or equivalent) in most of the Debian window managers, did you look there? The menu entry will prompt you for the root password, then launch synaptic. If you can't find a menu entry, just run 'gksu synaptic' without logging into root and it will launch the same way.
Originally posted by misterflibble This simply means that root is not allowed to launch a new window into the regular user's space from the commandline. There are security reasons for this. Synaptic is usually installed in the apps->system menu (or equivalent) in most of the Debian window managers, did you look there? The menu entry will prompt you for the root password, then launch synaptic. If you can't find a menu entry, just run 'gksu synaptic' without logging into root and it will launch the same way.
Thanks for the quick reply.
No, synaptic doesn't show up in apps>system. I was under the understanding that it was necessary to log in as root, then type synaptic in the terminal.
And when I type gksu synaptic (as user, not root) I get "bash: gksu: command not found"
I can install gksu that way too, but before I do, would you mind telling me what I'm about to install? I don't mean to sound ungrateful, but I just want to know what it is.
Thanks for all your help so far, I really appreciate it.
You're right, I should've explained what it does before you install random things. Gksu is a frontend to su. Just as typing in su prompts you for the password and then lets you do things as root at the console, gksu does the same thing for graphical programs, so 'gksu programname' will let you run any X-Window program with full root privileges. It's useful for doing things ike running a file manager as root so you can mess around with protected files (carefully!). Gksu is the version associated with gnome programs (using GTK) and kdesu is for kde programs (using QT libraries) although they will both work with any program and do the exact same thing.
First, thanks for your patience. I really really really appreciate it. Now for the bad news...
From root, did an apt-get install synaptic...
Got the following....
"Reading Package Lists... Done
Building Dependency Tree... Done
Sorry, synaptic is already the newest version.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded."
Which, I'm assuming means what is says - I have the newest version of synaptic.
Looking at the firefox thread in this software forum, it looks like a similar problem. He pointed to this article (I think)...
Quote:
Hi,
>
> sometimes I need to run some X apps as root (i.e. ethereal, lprngtool) but
> Xlib complains that the server refuses the connection.
> how can I make the Xserver accept programs as root when I'm working as
> normal user?
>
Script started on Tue Jul 3 16:54:48 2001
[16:54:49 tmp]$ zgrep -A71 'How do I run an X client as root when the X session is run by a user?' /usr/share/doc/xfree86-common/FAQ.gz | tail -73
--
*) How do I run an X client as root when the X session is run by a user?
If a normal user is running an X session (from startx or xdm), and that
user, for instance, uses the su command from within an xterm to become root
and then runs a program that tries to do something with the X server, the
following error messages (or something similar) are usually seen:
Xlib: connection to ":0.0" refused by server
Xlib: Client is not authorized to connect to Server
This happens because of an X security mechanism, which uses "magic cookies"
stored in a file in the user's home directory (readable only by the user)
called .Xauthority. If the environment variable XAUTHORITY is not set (see
below), X clients attempt to authenticate themselves by using the
.Xauthority file found in the directory specified by the HOME environment
variable. Of course, if user "branden" is running the X session, and he
then uses su to become root, $HOME will be "/root" instead of
"/home/branden", and the correct .Xauthority file will not be found (even
if there is an .Xauthority file in /root, it will not contain the correct
magic cookies unless the root user has deliberately made it that way).
There are therefore a number of ways to solve this problem.
If only one user ever becomes root, and if root never starts an X session,
there is a one-step, permanent solution (provided you don't rearrange your
filesystem).
Become root, then:
cd
ln -s /home/branden/.Xauthority .Xauthority
Of course, you will want to replace "branden" in the above example with the
name of whatever user has access to the root account.
Alternatively, and more appropriate for more complex situations than the
one described above, you may simply issue commands while root that will tell
the X clients where to look for the .Xauthority file. If you set the
XAUTHORITY environment variable to the path to the appropriate user
.Xauthority file. If the su command is used, all of the environment of the
invoking user is inherited except for $PATH; therefore, each user who has
access to the root account could set the XAUTHORITY variable in their shell
startup files, and this variable will be passed to the root shell.
Other alternatives include modifying the root shell startup files to sense
the invoking user and setting XAUTHORITY, making command aliases that set
that variable for the invocation of specific commands, or configuring the
super or sudo programs with appropriate rules.
The most straightforward method (but not the one that requires the least
typing), is simply to set XAUTHORITY with each command you issue as root
that needs to access the X server.
For Bourne-type shells (sh, bash, ksh, zsh):
XAUTHORITY=/home/branden/.Xauthority xeyes
Users of ssh's X11 forwarding feature should note that ssh sets the DISPLAY
and XAUTHORITY variables itself, and does not use $HOME/.Xauthority for the
latter. If you frequently employ this feature of ssh you should not
unconditionally set XAUTHORITY in your shell's startup files. (You
shouldn't do that with DISPLAY, either, but most people know better than to
try. )
Finally, you should NEVER, EVER use the xhost command to manage X server
access control unless you know exactly what you are doing (even then,
there's hardly ever a good reason short of seeing just how many ways the
security of your system can be compromised). Use the xauth command
instead; the EXAMPLES section of its manual page is instructive for the
most common tasks.
[16:55:02 tmp]$ exit
exit
Script done on Tue Jul 3 16:55:04 2001
--
Shaul Karl <shaulka@bezeqint.net>
Hillel used to say: If I am not for myself who will be for me?
Yet, if I am for myself only, what am I? And if not now, when?
(Ethics Of The Fathers 1:14)
It seems like that is probably my problem. Unfortunately, I don't, for the life of me, understand how to follow the instructions to fix it.
This is a needlessly complicated solution to your problem since gksu and kdesu take care of it just fine. Seriously, try gksu to run a file manager or something and you'll see that you can run it as root. The problem now seems to be we can't find synaptic.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Problem With Snyaptic - A Newbie Needs Your Help!
)
