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



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 daemons are up to, regardless of what I'm doing at the time. 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).

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. By the way, you can tweak the geometry setting by:

Xwininfo will report a raft of stuff about the Xconsole process's window, including its geometry values.

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