libnotify over ssh enhanced
Monday, June 16th, 2008Bene shares some modifications he made to my libnotify over ssh post.
Bene shares some modifications he made to my libnotify over ssh post.
Here is an X.org configuration file for a Dell Latitude C610 Laptop using an ATI Radeon Mobility M6 LY video card. This configuration uses the stock standard X.org ATI driver, however an upgrade to the ATI closed-source driver shortly is anticipated. It’s running on kate’s laptop.
Download atiradeon_mobility_m6.txt
Update: The configuration file has been updated and can be found here.
Both my partner (Kate) and I enjoy a fairly minimalistic environment when it comes to our X setup/configurations. She got me hooked on Gentoo, while I got her rather attached to IceWM as a Window Manager.
IceWM has loads style for little cost, it all fits in minimal memory, it’s quick and very useable. We don’t need, nor particularly like the featureset of “desktop environments” and the Windows-wanna-be approach that Gnome and KDE tend to take. Taking this a step further, we both use xdm as a Display Manager, and yes - it is ugly. This is how I’ve made it a little more asthetically pleasing.
You should be able to find all of the configuration files for xdm in /etc/X11/xdm or somewhere similiar depending upon the distribution you’re using.
Firstly, make sure you’re actually using xdm (as opposed to gdm or kdm or one of the others), under Gentoo you can do this in /etc/rc.conf, look for the environment variable DISPLAYMANAGER, it should be set to “xdm”.
Starting with the /etc/X11/xdm/Xresources file, we first want to make the login box look a little prettier:
xlogin*greeting: Identify Yourself xlogin*namePrompt: User ID:\ \ \ xlogin*passwdPrompt: Password:\ \ \ xlogin*fail: ACCESS DENIED! xlogin*greetFont: -*-clean-bold-*-*-*-15-*-*-*-*-*-*-* xlogin*font: -*-clean-bold-*-*-*-15-*-*-*-*-*-*-* xlogin*promptFont: -*-clean-bold-*-*-*-15-*-*-*-*-*-*-* xlogin*failFont: -*-clean-bold-*-*-*-15-*-*-*-*-*-*-* xlogin*width: 300 xlogin*height: 120 xlogin*x: 10 xlogin*y: 10 xlogin*borderWidth: 2 xlogin*frameWidth: 0 xlogin*innerFramesWidth: 0 xlogin*shdColor: black xlogin*hiColor: black xlogin*background: #333333 xlogin*greetColor: yellow xlogin*failColor: red xlogin*promptColor: #ffffff xlogin*Foreground: red xlogin*Background: black xlogin*useShape: false xlogin*logoPadding: 0
You can leave the xlogin.translations bit as is, unless you particularly want to play with it), you can leave the Chooser section as is as well, unless you particularly want it customised.
Now to add a touch of interest to the root window while we’re waiting for someone to login. I decided to use the glslideshow component
to add some movement and interest. xdm generally runs as root, so you may want to copy your .xscreensaver file from your home directory to root’s to keep some configuration options (like the directory for glslideshow to pull it’s images from with xscreensaver-getimage).
Next setup your Xsetup_0 file, I tend to remove the xconsole entry, I find it annoying and if I want to check the console log, I’m more then capable of doing it myself. So I first black the screen, then start a glslideshow of images:
#!/bin/sh # $Xorg: Xsetup_0,v 1.3 2000/08/17 19:54:17 cpqbld Exp $ xsetroot -solid black /usr/lib/misc/xscreensaver/glslideshow -root -duration 26 \ -letterbox -zoom 50 -pan 4 -fade 5 -delay 0 &
You could of course replace glslideshow with anything, even tuxracer if you wanted to!
Enjoy your slightly prettier xdm configuration.
When I was visiting recently, I needed to have my MAC address added to your firewall configuration to be allowed to access your network, how did you do this?
The simple answer to this question is that I actually use Shorewall running on my Debian-based router. It has a maclist configuration file with a layout that looks like:
eth0 00:50:22:E7:3A:B2 192.168.1.2 # usajii eth0 00:0F:EA:B3:A9:64 192.168.1.101 # tachan eth0 00:06:5B:E5:6F:BD 192.168.1.102 # binky
Of course, I also only give DHCP addresses to registered mac’s as well, and ensure that the address corresponds to the host it is assigned. I haven’t automated the update of both Shorewall and DHCP configuration files, yet. That’s something thats on that extremely long to-do list of mine!
So, DHCP configuration for these hosts (just for interest) looks like:
host usajii { hardware ethernet 00:50:22:E7:3A:B2;
fixed-address usajii.home;
server-name "usajii.home"; }
host binky { hardware ethernet 00:06:5B:E5:6F:BD;
fixed-address binky.home;
server-name "binky.home"; }
You don’t want to run Shorewall? That’s fine. It’s still possible of course. I am just particularly fond of the way that Shorewall works. I like it’s flexibility and general approach to doing things, so I use it. If you prefer raw iptables or something else, good, go for it. Here’s how to do it with pure iptables:
# iptables -A INPUT -i eth0 -m state --state NEW -j macfilter
# iptables -A macfilter -s 192.168.1.101 \
-m mac --mac-source 00:0F:EA:B3:A9:64 -j RETURN
# iptables -A macfilter -s 192.168.1.102 \
-m mac --mac-source 00:06:5B:E5:6F:BD -j RETURN
# iptables -A macfilter -j REJECT
You would have to change the INPUT rule to insert the rule in a relevant spot in your INPUT chain, you probably don’t want it below a rule that rejects everything first! (check the manpage for iptables for how to do that one). You can leave out the –state and -m options if you want to check every packet, but I feel safe enough only checking the first packet of every connection the host makes, you don’t really need to check every packet sent for a 800Mb samba transfer for instance!
The following rules instruct iptables to ‘return’ to the calling chain (the chain which used -j to jump to the macfilter chain), so these packets get processed by the upcoming rules.
If the packet manages to fall through all the rules granting a ‘return’ it hits a ‘REJECT’ rule, which will reject all packets that get to that point. You could be mean and ‘DROP’ them instead, or you may wish to insert some logging prior to it:
iptables -A maclist -j LOG --log-prefix "MAC Filter:" --log-level 7
You will want that before the ‘REJECT’ rule, otherwise the packet will get rejected before it gets logged, and therefore not get logged.
If you don’t want to restrict particular mac addresses to particular IPs you don’t have to. You can leave the IP section out of both styles - the shorewall config is happy without them and so is the raw iptables way, e.g.:
# iptables -A macfilter -m mac --mac-source 00:06:5B:E5:6F:BD -j RETURN
Hope this helps you secure your network a little further.
The reason I originally setup mac filtering on my network was for my wireless subnet, which isn’t up and running at the moment, but I expanded the idea to be the whole network when I started sharehousing and not being sure I could trust just anyone plugging into the network.
I promised in a recent article to publish my “struggle” getting NVidia GeForce2 MX400+ TV Output working on my X setup, however there was no struggle, it ended up being a rather simple exersize.
First, before doing any of this, you must be running the closed-source “nvidia” GLX driver (not the open-source “nv” driver), details on this can be found here.
To add TV-Out support, a couple of lines of configuration change are needed to define two completely seperate Layout’s, one for TV-Out the other for CRT Out (this was when I implemented it a few days ago going to be a transient configuration, however I got so attached to having a loungeroom PC again, and missed my work PC so much that I had to dedicate a lounge room PC, more on that project soon!)
I’m in Australia, so the first thing to make sure that I have set is my TV Standard:
Section "Device" Identifier "geforce2tv" Driver "nvidia" VendorName "nVidia Corporation" BoardName "NV11 [GeForce2 MX/MX 400]” BusID “PCI:2:0:0″ Option “TVStandard” “PAL-B” Option “ConnectedMonitor” “TV” Option “TVOutFormat” “SVIDEO” EndSection
The section for my Television was defined as:
Section "Monitor" Identifier "TV" VendorName "TV" ModelName "TV" HorizSync 30-50 VertRefresh 60 EndSection
Second last, we have the “Screen” definition:
Section "Screen"
Identifier "tv"
Device "geforce2tv"
Monitor "TV"
DefaultColorDepth 24
SubSection "Display"
Depth 24
Modes "800x600" "640x480"
EndSubSection
EndSection
And one last one being the appropriate Server Layout:
Section "ServerLayout" Identifier "tvout" Screen 0 "tv" 0 0 InputDevice "Mouse" "CorePointer" InputDevice "Keyboard" "CoreKeyboard" EndSection
It worked remarkably well, and I had no issues using it for watching movies, surfing the net (and even emailling occasionally over the weekend).
Getting the NVidia GeForce2 MX440 video card to work successfully with GLX on Gentoo Linux wasn’t as difficult as first seemed, however there were a few hurdles I ran into.
You will need the kernel and X packages emerged (you can grab the settings package as well if you like). The glx package in Gentoo requires the kernel package, so all you need to do is emerge the nvidia-glx package.
# emerge nvidia-glx
This resulted in the following packages being emerged from portage:
I then edited my /etc/X11/xorg.conf file and simply changed the driver to nvidia (from nv), however this caused major issues when X next restarted.
I continued playing with various settings for a while and eventually found running startx would work but xdm would fail miserably when starting (causing screen flashing and putting the machine in a state that only a hard reset would fix!!)
My full XOrg.conf file.
The important points with configuration are: