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 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?
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).
xconsole watches root owned logfiles
-rw-r----- 1 root adm 7974 Mar 29 09:50 /var/log/messages
prw-r----- 1 root adm 0 2006-03-29 08:17 /dev/xconsole|
and my user is not a member of group adm
- Nowadays, it may not even be there, but it can be created and will stick across boots.
- Do "mknod -m 640 /dev/xconsole p"; add "p /dev/xconsole 640 root adm" to /etc/tmpfiles.d/rsyslog.conf (alternatively, "systemd-tmpfile --create --prefix /dev/xconsole" (note, this has not been tried by me so far)), then (see rsyslog stuff below) restart rsyslog
- add your user $LOGNAME to group adm then logout and back in.
- Overnight, *maybe* something changed /dev/xconsole to root:root ownership, or it was root:root when I created it (I thought I checked that)? So, "chown root:adm /dev/xconsole"
- You need to have added lines to your /etc/rsyslog.conf:
*.=debug;\ auth,authpriv.none;\ news.none;mail.none -/dev/xconsole *.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ mail,news.none -/dev/xconsole
then as root/via sudo systemctl restart rsyslog.
for me, that lets me "alias xc='xconsole -file /dev/xconsole -daemon -exitOnFail -geometry 704x114-2-16 &'" in my user acct., no root login required.
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 ...).
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.
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.
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.
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:
- once it's running, resize its window to your taste.
in an xterm window, run xwininfo, then click in the xconsole window.
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.