Secure your MySQL setup

This was going to go into a Lazy Reading post, but then I realized it shouldn’t.  Here’s the source: “A Tragically Comedic Security Flaw in MySQL” (via)

The short version: MySQL, compiled a certain way, will allow 1 out of 256 root login attempts to work no matter what.  I was going to link to this for the startlingly large number of MySQL installations found allowing connections from the public Internet, which means breaking into any affected servers would be easy.  Then I thought about it…  I don’t see a my.cnf installed by pkgsrc for at least MySQL 5.1 by default.

To fix this for your own installation, put

[mysqld]
bind-address=127.0.0.1

in /usr/pkg/etc/my.cnf to disallow remote connections.  I don’t know if MySQL on DragonFly from pkgsrc is vulnerable to the issue, but it’s a good idea to not allow remote connections to the database, and ought to be on by default.

Or just use Postgres, if possible.

 

libpthreadbroken, fixed

If you are running bleeding-edge DragonFly, libpthread was broken for a short period.  If you built anything in the last … 12 hours?  You may want to rebuild it.  If that doesn’t describe you, it’s a nonevent.

It’s funny that I’m reporting a short-term break in bleeding-edge operating system code as any sort of surprise.  It shows something about how stable DragonFly-master is most of the time.

HEADS UP: package recompilation needed

The presence of /usr/include/crypt.h in DragonFly (starting in December 2010) meant that some programs compiled during that time will expect that file to always be there.  It was recently removed, so any programs compiled in that timeframe will also need to be recompiled.  Right now, this affects you only if you are running DragonFly 2.13 , since that’s the only place crypt.h was removed.  This may be an issue for the release, but we’ll worry about that when we get there…  I’m kicking off new 2.13 bulk builds now.

The next release and what’s needed

There’s a rare crash in DragonFly 2.10, where applications would segfault.  The system would run find.  This is apparently more likely to happen in 2.12, though reports on this vary.  It’s real, though.

Matthew Dillon went looking for this bug, and happened to roll back vm_token, the last lock in DragonFly that presented a serious impediment to multiprocessing.  It’s a big patch.  It fixes the problem, which is great!  It also happens to make DragonFly buildworlds almost twice as fast depending on the number of cores in the system.

Holy crap we want to get that out…  but it makes some significant changes to the system and needs to be tested.  So, the next release probably won’t be for a few weeks.

If you want to help, build master and do something with it – move data, run server programs, whatever.  Report crashes.  This performance improvement is worth working for.

Old ISA drivers and what to do about them

Some ISA devices have been removed from DragonFly.  That probably affects approximately 0% of everyone, cause they’re old devices, but a few of them are were in the GENERIC kernel configs, so you’ll get an error for an unrecognized option when you next rebuild your kernel using a GENERIC-based config, based on an older version of GENERIC.  The description of which drivers went is quite sensibly placed in UPDATING.

x86_64: Rebuild!

If you’re running 64-bit DragonFly, and you’re on version 2.11, you will want to rebuild with the latest sources.  Peter Avalos found a bug with file descriptor passing, and Venkatesh Srinivas fixed it.  It will require a quickworld/kernel build – maybe a full buildworld and kernel?  I’m not sure.   Some pkgsrc packages might need recompilation, too if they also passed file descriptors around.

binutils, Hammer updates

Sascha Wildner has updated the default version of binutils in DragonFly from 2.17 to 2.21.  You’ll want to do a full buildworld on your next upgrade, if you’re running DragonFly 2.9.

Also, Matthew Dillon has made version 6 the default version of Hammer in DragonFly 2.9.   Version 6 has improved handling of directory names in some circumstances.  Just don’t ask me which, cause I lost track.  It’s been a hard day!

Summer of Code: mentoring wait

The mentor signup page for Google Summer of Code 2011 as of this writing still says “We have temporarily disabled the creation of new requests and invites in preparation of the launch of the new UI for Melange later this week.”, as it has said since the 20th.

So, if you’re wanting to mentor, keep an eye on it.  I’ll send mentor requests to any of the names on my list of people that have already expressed interest, if I get to a working version of the page before you do…