4712
Comment: /etc/rsyslog.conf entry
|
4656
formatting
|
Deletions are marked like this. | Additions are marked like this. |
Line 34: | Line 34: |
* you need to have added lines to your /etc/rsyslog.conf; don't know how to say that here yet and not look ugly ... {{{*.=debug;\ |
* you need to have added lines to your /etc/rsyslog.conf: {{{ *.=debug;\ |
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).
xconsole watches root owned logfiles
-rw-r----- 1 root adm 7974 Mar 29 09:50 /var/log/messages
/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
- nowadays, it may not even be there. do "mknod -m 640 /dev/xconsole p"; add "p /dev/xconsole 640 root adm" to /etc/tmpfiles.d/rsyslog.conf, then restart rsyslog, logout and in again assuming you've added yourself to group adm.
- overnight, something changed /dev/xconsole to root.root ownership. 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
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. 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.