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.

Why can't my user use ''dmesg'' anymore?

Upstream kernel devs (aka Linus) decreed it be locked down (for system security reasons, likely). Add "kernel.dmesg_restrict = 0" to /etc/sysctl.conf to change back.

How do I do PPP over a null modem cable?


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

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?

In my case, this is current as of stretch/stable, Sep., 2017. Update, works for me on testing/Buster, Apr. 2018.

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

        news.none;mail.none     -/dev/xconsole
        mail,news.none          -/dev/xconsole

then as root/via sudo systemctl restart rsyslog.

To this point, all we've been doing is getting the thing to run at all. Now it does for me as I've added myself to group adm, and sussed out configs and edited seldom encountered root-ish stuff. However, that may be non-trivial or impossible for you on an employer's or client's server. On the other hand, the following assumes you've root's pword! Er. Rock vs. hard place?

I have a dream: The debian-boot people implement ask at install time whether install is for user desktop/portable or server box. It'd solve a lot of problems, such as this.

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

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