Differences between revisions 2 and 3
Revision 2 as of 2006-03-26 14:59:47
Size: 912
Comment:
Revision 3 as of 2006-03-29 16:26:13
Size: 3807
Comment: Solution to running Xconsole in regular user's X Window session.
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
How do I do PPP over a null modem cable? == How do I do PPP over a null modem cable? ==
Line 14: Line 14:
How do you set up the nVidia graphics driver on Debian? ----
==
How do you set up the nVidia graphics driver on Debian? ==
Line 19: Line 20:
----
== How the fsck do you make Xconsole work in a user owned X Window session? ==

I fought with this for years. I grew to love Xconsole. I like to see what the system's doing, regardless of what I'm doing at the time. It's important for security to see what the daemons are doing, and it's educational; it teaches you more about the system when you see it doing its thing, as it's doing its thing.

Then, one day, Xconsole just stopped working (or on some distributions I tried, it just never worked at all).
 * xconsole watches root owned logfiles.
 * /dev/xconsole is{{{
prw-r----- 1 root adm 0 2006-03-29 08:17 /dev/xconsole|
}}} and my user is not a member of group {{{adm}}}
 * you want to run it when you're running as a regular user (real men/women '''don't''' run X as root).
 * some distributions ''don't think you deserve'' to run Xconsole in a user owned X Window session (What, they want me to run X as root?!? Idiots! Grrr ...).

=== Solution 1 ===
{{{xhost +}}}

'''Bad idea'''! You've just thrown away all security, opening your X Server up to the Universe. These days, {{{xhost}}} is almost always the wrong solution to anything. Besides, this seldom works anyway.

=== Solution 2 ===
{{{
xauth list # if you already have keys, skip next.
xauth generate . # perform if you have no auth file.
xauth nextract username.xa $DISPLAY # should be the only step needed.
#
# now login to other account/machine and:
export DISPLAY=$HOSTIP:0.0
xauth nmerge ~username/username.xa # now you can use username's auth.
}}}

This broke in Sarge. :-( Sigh.

=== Solution 3 ===
In your ''regular user's'' ~/.xinitrc (~/.xsession?):{{{
# This makes X work for root "su" (no "-") logins.
#
if [ -z "$XAUTHORITY" ]; then
  XAUTHORITY=$HOME/.Xauthority
  export XAUTHORITY
fi
}}}

Now, while running X Window as a regular user:{{{
$ su # no "-" (dash)
Password: ........ # root's password
# xconsole -file /dev/xconsole -daemon -notify -exitOnFail -geometry 596x114-3-4 &
# exit
$ _
}}}

XConsole should have popped up on your user X Window session. It's a root owned process accessing {{{root:adm}}} owned resources, and you've not otherwise compromised the security of your box doing it.

'''Why It Works'''

Bare "su" doesn't clobber your user's environment variables. Anything defined in the user's environment is inherited in the root login session. So {{{$XAUTHORITY}}} continues to point to user's {{{$HOME/.Xauthority}}}

It would be a good idea now to ensure Xscreensaver is set to lock your screen when you're not there. You don't want just anyone wandering by looking into your system log files.

It'll be interesting to see what the gods come up with next to disable this yet again but for now, I'm happy again. :-)
----
----

This is an area for Not So Frequently Asked Questions. Questions not asked enough to make it into the ["FAQs"], but ones that can really tick people off if they can't find an answer to them.


How do I do PPP over a null modem cable?

Using

 /usr/sbin/pppd ttyS0 115200 noauth debug local nocrtscts   \
  lcp-restart 1 ipcp-restart 1 persist 192.168.10.1:192.168.10.2

to make the link and doing other stuff to work out the routing for example.

MichaelIvey: I've been doing the ?NullModem trick to make my ?TiVo use an old 486 laptop to connect to the internet. Works like a champ. Found the instructions in the ?TiVo Serial-PPP ?HowTo.



How do you set up the nVidia graphics driver on Debian?

You go to [http://wiki.debian.org/NvidiaGraphicsDrivers NvidiaGraphicsDrivers] and [http://wiki.debian.org/NvidiaHowTo ?NvidiaHowTo].



How the fsck do you make Xconsole work in a user owned X Window session?

I fought with this for years. I grew to love Xconsole. I like to see what the system's doing, regardless of what I'm doing at the time. It's important for security to see what the daemons are doing, and it's educational; it teaches you more about the system when you see it doing its thing, as it's doing its thing.

Then, one day, Xconsole just stopped working (or on some distributions I tried, it just never worked at all).

  • xconsole watches root owned logfiles.
  • /dev/xconsole is

    prw-r-----  1 root adm 0 2006-03-29 08:17 /dev/xconsole|

    and my user is not a member of group adm

  • you want to run it when you're running as a regular user (real men/women don't run X as root).

  • some distributions don't think you deserve to run Xconsole in a user owned X Window session (What, they want me to run X as root?!? Idiots! Grrr ...).

Solution 1

xhost +

Bad idea! You've just thrown away all security, opening your X Server up to the Universe. These days, xhost is almost always the wrong solution to anything. Besides, this seldom works anyway.

Solution 2

xauth list                           # if you already have keys, skip next.
xauth generate .                     # perform if you have no auth file.
xauth nextract username.xa $DISPLAY  # should be the only step needed.
#
# now login to other account/machine and:
export DISPLAY=$HOSTIP:0.0
xauth nmerge ~username/username.xa   # now you can use username's auth.

This broke in Sarge. :-( Sigh.

Solution 3

In your regular user's ~/.xinitrc (~/.xsession?):

# This makes X work for root "su" (no "-") logins.
# 
if [ -z "$XAUTHORITY" ]; then
  XAUTHORITY=$HOME/.Xauthority
  export XAUTHORITY
fi

Now, while running X Window as a regular user:

$ su                    # no "-" (dash)
Password: ........      # root's password
# xconsole -file /dev/xconsole -daemon -notify -exitOnFail -geometry 596x114-3-4 &
# exit
$ _

XConsole should have popped up on your user X Window session. It's a root owned process accessing root:adm owned resources, and you've not otherwise compromised the security of your box doing it.

Why It Works

Bare "su" doesn't clobber your user's environment variables. Anything defined in the user's environment is inherited in the root login session. So $XAUTHORITY continues to point to user's $HOME/.Xauthority

It would be a good idea now to ensure Xscreensaver is set to lock your screen when you're not there. You don't want just anyone wandering by looking into your system log files.

It'll be interesting to see what the gods come up with next to disable this yet again but for now, I'm happy again. :-)