Getting more entropy for Subversion on FreeBSD
I was trying to create a new Subversion repository today and noticed
to my dismay that it would hang during create. Totally
high-centered. My only recourse was kill -9. It was bad.
“Why is this?” I thought. I googled a little and found this entry in the Subversion FAQ. In a nutshell I have too little entropy (sources of randomness) and that I should configure the system to get more entropy from interrupts.
It recommended checking into rndcontrol about this. The rndcontrol
manpage was easy enough:
SYNOPSIS
rndcontrol [-q] [-s irq_no] [-c irq_no]
DESCRIPTION
The rndcontrol command is used to set which interrupts are used to
help randomise the ``pool of entropy'' maintained by the kernel.
The /dev/random and /dev/urandom devices are the user interface
to this source of randomness. Any changes take effect
immediately.
The following command line options are supported:
-q Turn off all output except errors.
-s n Allow IRQ n to be used as a source of randomness. This
option may be repeated for more than one IRQ.
-c n Stop IRQ n from being used as a source of randomness.
This option may be repeated for more than one IRQ.
The default is to have no IRQ's being used.
Ok. So I need some IRQs I can get some entropy from:
# /sbin/dmesg | grep -i irq
IOAPIC #0 intpin 2 -> irq 0
IOAPIC #0 intpin 19 -> irq 2
IOAPIC #0 intpin 21 -> irq 5
IOAPIC #0 intpin 20 -> irq 9
asr0: <Adaptec Caching SCSI RAID> mem 0xfc000000-0xfdffffff irq 9
at device 4.1 on pci2
ahc0: <Adaptec aic7896/97 Ultra2 SCSI adapter> port 0x2000-0x20ff
mem 0xf4100000-0xf4100fff irq 2 at device 12.0 on pci0
ahc1: <Adaptec aic7896/97 Ultra2 SCSI adapter> port 0x2400-0x24ff
mem 0xf4101000-0xf4101fff irq 2 at device 12.1 on pci0
fxp0: <Intel Pro 10/100B/100+ Ethernet> port 0x2800-0x283f mem
0xf4000000-0xf40fffff,0xf4102000-0xf4102fff irq 5 at device 14.0
on pci0
pci0: <Intel 82371AB/EB (PIIX4) USB controller> at 18.2 irq 5
sio0 at port 0x3f8-0x3ff irq 4 flags 0x30 on isa0
sio1 at port 0x2f8-0x2ff irq 3 on isa0
Ah, IRQ 9, 2, and 5 look great: hard drives, RAID adapters, network interfaces are all great entropy sources. Let’s change our random device now:
# rndcontrol -s 9 -s 2 -s 5
rndcontrol: setting irq 9
rndcontrol: setting irq 2
rndcontrol: setting irq 5
rndcontrol: interrupts in use: 2 5 9
(Meanwhile, in another terminal):
$ svnadmin create SVN_REPO
Wow, that was fast… er, I guess that’s what it’s like under normal conditions. Oh well. Better put things back the way they were:
# rndcontrol -c 9 -c 2 -c 5
rndcontrol: clearing irq 9
rndcontrol: clearing irq 2
rndcontrol: clearing irq 5
rndcontrol: interrupts in use:
That’s it.
SOCKS5 Proxy Server on FreeBSD
For several years I ran the Dante proxy server and was generally happy with it. I chose it mainly because it was easy to install from FreeBSD ports, and had a few good tutorials on how to use it.
I rarely had to restart it, but I noticed that it forked a lot of processes for various tasks (probably tunable, but I never learned how to tune it), and was not always reliable (I’d have to sometimes retry my local connection to it several times).
For the past month or so I’ve been using nylon for my proxy and have been even more pleased with how it has worked.
Nylon is fast and small. It seems to keep its children under control, not spawning more than it needs to keep its connections up. It’s config file is also fairly minimal and easy to understand, though I’m not sure it is as flexible as Dante, it meets my simple needs perfectly well. Highly recommended as a first SOCKS5 proxy.
Upgrading milter-greylist from 1.6.1 to 2.0:
cd /usr/ports/mail/milter-greylist make (read the README and Changes files for items) (noticed a new line in the .mc file: confMILTERMACROSENVRCPT, so I add that) (noticed that the whitelist syntax is different than before: have to add ‘acl whitelist’ in front of ‘rcpt’ and ‘domain’ directives now) /usr/local/etc/rc.d/milter-greylist.sh stop make deinstall make reinstall
I touched and chown’d /var/milter-greylist/greylist.db to ‘smmsp’, the started milter-greylist:
sh /usr/local/etc/rc.d/milter-greylist.sh start
Seems ok so far.
Upgrading milter-greylist from 1.5.6 to 1.6.1:
cd /usr/ports/mail/milter-greylist make /usr/local/etc/rc.d/milter-greylist.sh stop make deinstall make reinstall
That seems to do it. However, I’m a paranoid type, full of all kinds
of mischief, FUD, and cargo-cult practices. So I check the greylist
README and make sure my /etc/mail/hostname.mc is up-to-date with the
recommended changes there (it was—greylist hasn’t changed for a
while).
I was getting a bogus IP from my ISP the other day and my FreeBSD firewall was having a tough time getting connectivity. I found this page:
http://www.moundalexis.com/archives/000054.php
which says this:
In this case the active interface is sis0, so here is the command to run.
# /sbin/dhclient -r sis0
Now occasionally that may not work as quickly as you might like. If you want to force it, you can restart the networking components by hand.
# /etc/netstart
Saved my bacon!
xset is one of those programs I keep learning how useful it is.
I just (re-)learned how to turn off/on DPMS support in X:
# xset -dpms
Querying the results:
# xset q
I should note that FreeBSD’s power settings (4.x) don’t honor xset, however (afaik). I’m fiddling with sysctl settings:
machdep.apmstandbydelay machdep.apmsuspenddelay
I’ve set these to 0, but the screen still goes blank after a while in X. The screen never blanks in a console (only X). That seems to say that it’s an X setting.
Got it:
# xset s reset s off
I’m seeing lines like this in my log:
May 11 15:29:51 foo sm-mta[24407]: j5HAduFf025412: Milter (milter-regex): local socket name /var/spool/milter-regex/sock unsafe
I looked and there was no sock file there. ‘ps’ revealed no milter-regex running at all :(
Starting milter-regex seems to have solved the problem.
I’ve had a wireless router behind my FreeBSD firewall for about 8 months now. It worked mostly fine except for the fact that I had to unplug and re-plug it in every other day. It’s a Netgear WGB (fixme)
I thought for the longest time it had something to do with my DHCP server settings. I fiddled with those a little, dropping the TTL to something like an hour instead of 12 hours. I fiddled with the NAT settings. I changed the named (DNS server) settings. Not until I changed my wireless encryption options did things fall into place. I setup WPA on the wireless router; now I can open and close the laptop all day long. I can go away for days or minutes, and when the laptop wants wireless, it gets it. I haven’t had to reset the router for a few weeks now, and (I’m told) I’m more secure than before. Nice.Missing Devices from FreeBSD 5.2.1 to 5.3
I just upgraded from FreeBSD 5.2.1 to 5.3 and encountered the following symtoms:
Mar 28 11:50:52 tub init: getty repeating too quickly on port /dev/ttyv8, sleeping 30 secs
After a little research (thank Google) I found an entry in freebsddiary.org where the following 2 lines were missing from the 5.2.1 GENERIC kernel config file:
device mem # Memory and kernel memory devices device io # I/O device
I’ve added these back into my custom kernel file, rebuilt the kernel, and the problem went away.
I learned to change a few lines in the cvsup config file to get the latest stuff for kernel upgrade:
*default release=cvs tag=RELENG52
can be changed to:
*default release=cvs tag=RELENG53
and then you can run cvsup to get the latest codebase.
Find the module /modules/procfs.ko. Now do this:
umount -f /proc kldunload procfs kldload procfs mount /proc
Doesn’t that feel better?