random musings
Are you running Debian Squeeze?
Did you upgrade to mysql-server-5.1 ?
Are you getting a message like this?
Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!
Did you read /usr/share/doc/mysql-server-5.1/README.Debian.gz ?
Go read it again and this time *comment out* skip-bdb in /etc/mysql/my.cnf:
perl -i.bak -pe 's/^(skip-bdb)/#$1/' /etc/mysql/my.cnf
So you’re tired of watching the grass grow while your Linux RAID2 array rebuilds itself. Let’s take care of it:
$ echo 10000 > /proc/sys/dev/raid/speed_limit_min
This should give you a 10x speedup over the 1000kB/sec default — subject to the limitations of your actual bus bandwidth, of course.
After getting in closer-than-usual acquaintance with my mail server logs I thought I’d share a brief note I found in the Spamhaus PBL FAQ:
The first thing to know is: THE PBL IS NOT A BLACKLIST.
Oh, and since you’re already there you may want to linger a bit in this warning:
WARNING! Some post-delivery filters use “full Received line traversal” or “deep parsing”, where the filter reads all the IPs in the Received lines. Legitimate users, correctly sending good mail out through their ISP’s smarthost, will have PBL-listed IPs show up in the first (lowest) Received header where their ISP picks it up. Such mail should not be blocked! So, you should tell your filters to stop comparing IPs against PBL at the IP which hands off to your mail server! That last hand-off IP is the one which PBL is designed to check. If you cannot configure your filters that way, then do not use PBL to filter your mail. Instead, you may wish to use sbl-xbl.spamhaus.org, but even that may have unacceptable “false positive” filtering, for example when a an exploited end-user machine sends legitimate mail out through the ISP smarthost, or when the dynamic assignment changes the IP to an uninfected machine. Do not use PBL or XBL if you do not understand the issues of “deep parsing”.
(Emphasis mine)
So if your top-of-the-line multi-thousand-dollar antispam appliance starts blocking all my email just because there’s a dynamic IP address somewhere in the header and there’s no freaking way to turn it off please go ask for a refund. And stop bouncing my messages.
Oh and by the way the default SpamAssassin configuration in Debian assigns a 0.905 score if the last hop is in PBL.
score RCVD_IN_PBL 0 0.509 0 0.905
...
header RCVD_IN_PBL eval:check_rbl('zen-lastexternal', 'zen.spamhaus.org.', '127.0.0.1[01]')
And yes, SpamAssassin does the right thing and checks only the *last* external address — I’ve seen the code:
package Mail::SpamAssassin::PerMsgStatus;
...
# If name is foo-lastexternal, check only the Received header just before
# it enters our internal networks; we can trust it and it's the one that
# passed mail between networks
So once again kudos to Open Source — and Common Sense.
For completeness, here’s a followup to my post about using a Nokia N95 as a bluetooth modem under Linux. This is a working wvdial configuration for use with Telcel in Mexico.
Remember to enter your SIM’s PIN in pin-telcel, and refer to my previous post for complete instructions.
[Dialer pin-telcel]
Modem = /dev/rfcomm0
Baud = 460800
Init1 =AT+Cpin=XXXX
[Dialer telcel]
Phone = *99***1#
Username = telcel
Password = telcel
Stupid Mode = 1
Dial Command = ATDT
Check Def Route = on
Dial Attempts = 3
Modem = /dev/rfcomm0
Baud = 460800
Init2 = ATZ
Init3 = ATQ0 V1 E0 S0=0 &C1 &D2 +FCLASS=0
Init4 = AT+CGDCONT=1,"IP","internet.itelcel.com"
ISDN = 0
Modem Type = Analog Modem
To use it, enter
# wvdial vodafone-pin
# wvdial vodafone
Enjoy!
Did you know that you can use your data-enabled N95 to get a thethered Internet connection from Linux? The access mode and speed will depend on your actual coberture, and as usual YMMV, but I’ve been using this setup for a few months and it works fine.
$ sudo -s
# apt-get install bluetooth bluez-pin bluez-utils kdebluetooth wvdial
Now in user mode use KBlueMon to find out the Bluetooth address of your device and write it down.
Then go ahead and initiate an OBEX file transfer to make sure that you can actually link to your phone and to establish a trust relationship. In your phone add the Laptop to your trusted device list, so it won’t nag you whenever you establish a link.
Now edit /etc/bluetooth/rfcomm.conf :
rfcomm0 {
bind yes;
device 00:21:09:XX:XX:XX;
channel 2;
}
Replace your own device address after “device”.
Now edit /etc/wvdial to add these two entries:
[Dialer pin-vodafone]
Modem = /dev/rfcomm0
Baud = 460800
Init1 =AT+Cpin=XXXX
[Dialer vodafone]
Phone = *99***1#
Username = vodafone
Password = vodafone
Stupid Mode = 1
Dial Command = ATDT
Check Def Route = on
Dial Attempts = 3
Modem = /dev/rfcomm0
Baud = 460800
Init2 = ATZ
Init3 = ATQ0 V1 E0 S0=0 &C1 &D2 +FCLASS=0
Init4 = AT+CGDCONT=1,"IP","ac.vodafone.es"
ISDN = 0
Modem Type = Analog Modem
You can give them any name you want. I have defined several providers, to avoid confusions and to use the provider at hand. Replace the “XXXX” in Init1 with your SIM’s PIN.
Now to use them restart the Bluetooth subsystem:
# /etc/init.d/bluetooth restart
And use wvdial to dial out:
# wvdial vodafone-pin
# wvdial vodafone
You should get an Internet link, complete with an IP, a default route and a couple of DNS servers. If it doesn’t, reboot your phone liberally.
Please note that this might get expensive quite quickly unless you get a data plan from your provider. Go ahead and make their day.
Enjoy!
Rafael Garcia-Suarez shares a helpful tip to correctly enable APM in his D420 running Ubuntu, but I can confirm that my D620 behaves the same -ignoring APM level 255 and disabling APM completely instead- and that his fix runs equally well, just by adding
/dev/sda {
apm = 254
}
to /etc/hdparm.conf and making sure that /etc/init.d/hdparm runs at startup (the default after apt-get installing hdparm in my case).
I just got a new ASUS M2V motherboard to replace a braindead server that would lock up on POST about 75% of the time. The new motherboard has a built-in Attansic L1 Gigabit Ethernet Adapter that is supported in Linux >= 2.6.21, but its driver is still missing from the daily Debian netinst CDs.
04:00.0 Ethernet controller [0200]: Attansic Technology Corp. L1 Gigabit Ethernet Adapter [1969:1048] (rev b0)
Subsystem: ASUSTeK Computer Inc. Unknown device [1043:8226]
Flags: bus master, fast devsel, latency 0, IRQ 25
Memory at fbcc0000 (64-bit, non-prefetchable) [size=256K]
Expansion ROM at fbca0000 [disabled] [size=128K]
Capabilities: [40] Power Management version 2
Capabilities: [48] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Capabilities: [58] Express Endpoint IRQ 0
Capabilities: [6c] Vital Product Data
I tried David Johnson’s pre-compiled driver for AMD64 but it didn’t work right away, so I compiled AtL1Linux_v1.0.41.0 for the stock 2.6.18-4-486 kernel in the official Debian 4.0 netinst CD and tested it. Although it was supposed to work right out of the box I kept getting “invalid module format” messages. So I stripped out the version information with
$ objcopy -R .modinfo atl1.ko
and it worked immediately. I completed the installation and I will upgrade the server to 2.6.21-2-amd64 over the weekend. So here is a atl1.ko for 2.6.18-4-486 that should work just fine.
By the way, I stripped the version information off David’s atl1.ko but I didn’t get a chance to test it because I was in a hurry. Here it is anyway in case someone finds it useful: atl1.ko for 2.6.18-4-amd64.
Oh, by the way, the M2V has four PCI slots but no built-in VGA adapter, and most PCI-e video cards are so thick that the first slot becomes unusable. Since I bought this motherboard precisely to maximize the number of available PCI slots in the server… well, it just sucks.
[tags]asus,m2v,attansic,debian,linux,driver,atl1,amd64[/tags]