Resetting MySQL debian-sys-maint Password in Ubuntu

Occasionally, for various reasons, the MySQL debian-sys-maint password may be reset. Here's how to recover it. Instructions swiped from the following forum.

Find your debian-sys-maint password in /etc/mysql/debian.cnf.

Then use
GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY '' WITH GRANT OPTION;
Replace with your debian-sys-maint password.

Then, of course:

FLUSH privileges;

That's it!

Listing Apache's Compiled In Modules

On Ubuntu, if you'd like to get a list of modules compiled directly into your Apache binary, use the following command:

apache2 -l

You may see something like this:

$ apache2 -l

Compiled in modules:

core.c

mod_log_config.c

mod_logio.c

prefork.c

http_core.c

mod_so.c

Recovering From Corrupted MySQL Binlog Files

The WunderCounter.com has a replicated MySQL setup. Today I had a slave MySQL database server crash and the slave would not restart after reboot. The error was the following:

Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave

By using the mysqlbinlog utility, I was able to confirm that the one of the binlogs downloaded from the master was indeed corrupt and this is where the slave had gotten stuck.

In the past, I was under the impression that there was nothing that could be done. AFAIK, the log files can not be repaired, so what I did the last time this happened was simply to wipe out the slave databases and to restart replication fresh. This isn't problematic in a lot of cases, but the WunderCounter databases are around 40 GB in total. That's a lot of data to copy and transfer to a different machine. The copying isn't even the real issue. You need to issue a "READ Lock" on the master machine while you create a snapshot. In the case of the WunderCounter, it's not really a viable option to shut things down for this length of time.

After doing some looking around today, I came across the following helpful info in the first comment on this blog:

In the case of a corrupt binlog on the slave server, there is no need to delete all logs and start over. Run a “show slave status;” and record two entries: Relay_Master_Log_File and Exec_Master_Log_Pos. Then execute:

stop slave; CHANGE MASTER TO master_log_file='(binlog name in Relay_Master_Log_File', master_log_pos=(exec_master_log_pos number); start slave;

This will re-read the binlog from the master and you should be all set. This especially helps when you’ve purged older binlogs from the master server.

This is confirmed at mysql.com, even though it's buried in the following article.

In my case, I stopped the slave server and issued a "show slave status" to get the master_log_file and master_log_pos info. I used the listed info in the CHANGE MASTER TO statement and then started the slave. My slave immediately came back online and then began catching up on 3 hours of data remaining to be synced.

This saved me a massive amount of unnecessary work. I hope someone else will find it helpful as well.

Starting Process on Reboot

I set up a script to help me fire up MojoMojo and I need this to run on reboot. Here's the command I used:

# update-rc.d mojomojo-live defaults
update-rc.d: warning: /etc/init.d/mojomojo-live missing LSB information
update-rc.d: see 
Adding system startup for /etc/init.d/mojomojo-live ...
  /etc/rc0.d/K20mojomojo-live -> ../init.d/mojomojo-live
  /etc/rc1.d/K20mojomojo-live -> ../init.d/mojomojo-live
  /etc/rc6.d/K20mojomojo-live -> ../init.d/mojomojo-live
  /etc/rc2.d/S20mojomojo-live -> ../init.d/mojomojo-live
  /etc/rc3.d/S20mojomojo-live -> ../init.d/mojomojo-live
  /etc/rc4.d/S20mojomojo-live -> ../init.d/mojomojo-live
  /etc/rc5.d/S20mojomojo-live -> ../init.d/mojomojo-live

http://www.debuntu.org/how-to-manage-services-with-update-rc.d

There's a handy utility for checking to see init scripts and run levels:

sudo sysv-rc-conf

Ubuntu: Upgrading from Fiesty to Gutsy

A few weeks ago, I decided to upgrade a couple of Ubuntu machines to the latest version. Now, this needs to be done incrementally. You can't just upgrade to the latest version. Step one is to upgrade from Feisty to Gutsy. It turns out that at this point (Feb 2009), it's a bit tricky to do this because it's hard to find the source files online. However, they have been archived. You just need to know where to find them.

The first step is to update /etc/apt/sources.list to the following:

deb http://old-releases.ubuntu.com/ubuntu/ feisty main universe
deb http://old-releases.ubuntu.com/ubuntu/ feisty-backports universe main
deb http://old-releases.ubuntu.com/ubuntu/ feisty-security universe main
deb http://old-releases.ubuntu.com/ubuntu/ feisty-updates universe main
deb http://old-releases.ubuntu.com/ubuntu/ feisty-proposed universe main

After I did this, I could run the following commands:

sudo aptitude update
sudo aptitude upgrade
sudo aptitude dist-upgrade
sudo aptitude install update-manager-core
sudo do-release-upgrade

However, the process had some errors. Some packages failed to download because, for some reason, the update-manager would insert an invalid URL into the sources list. Turns out this is a known issue.

I got around this by using the tip posted here. The site which I couldn't prevent from being checked for downloads (us.archive.ubuntu.com) did not have the files that I needed. I Googled the URL (minus domain name) find the URL elsewhere. After a few tries, I found that the following site had the files:

http://mirror.csociety.org/ubuntu/dists/feisty-backports/main/debian-installer/binary-i386/

I checked to see if this address could be fetched with an IP number:

Macintosh-7:~ olaf$ host mirror.csociety.org
mirror.csociety.org is an alias for csociety-ftp.csociety.org.
csociety-ftp.csociety.org has address 128.46.156.117

Now, armed with the IP, I tried the link:

http://128.46.156.117/ubuntu/dists/feisty-backports/main/debian-installer/binary-i386/

It worked! Almost there. Now, I needed to send all requests for us.archive.ubuntu.com to this address. So, I edited my /etc/hosts file and added the following line:

128.46.156.117  us.archive.ubuntu.com

Now, when I tried to run the release steps the correct packages were fetched, but I got a new error:

"While scanning your repository information no mirror entry for the upgrade was found"

I found the fix to this error here: http://andreasjacobsen.com/2008/12/

After fixing my /etc/apt/sources.list as described in this article, do-release-upgrade ran without complaints and I'm upgrading as we speak. :)

ERROR 2013 (HY000): Lost connection to MySQL server during query

I've got a brand new Ubuntu 7.04 install. I installed MySQL, edited /etc/mysql/my.cnf to allow connections from my local network, but no matter what I did, I always got the following error on trying to connect to the MySQL server from a different machine:

ERROR 2013 (HY000): Lost connection to MySQL server during query

The relevant area of /etc/mysql/my.cnf:

[mysqld]
bind-address = 192.168.0.23

After hours and hours of searching, I found the following solution:


1) /etc/hosts.allow was missing in this version of Ubuntu. You can add them in this way:

sudo apt-get install tcpd

2) I added the following to my new /etc/hosts.allow file:

mysqld: 192.168.0.*


That's it! This now allows me to connect to this MySQL server from any machine on my local network. From what I understand, MySQL on Ubuntu is built with libwrap and that's why you need to edit the /etc/hosts.allow file in this case. I'm no expert, but it worked for me.


The relevant documents are here:

Mysql Docs (see the comments from March 2, 2004)

hosts.allow (useful tips for getting started)

Related:
iptables rule to allow mysql (if you're not an iptables expert)

Fixing Line Breaks in Perl

Here is a handy Perl one-liner that I use a lot:

perl -pi -e 's/\r/\n/g' FILENAME

This one is useful for Excel Spreadsheets in OS X. When you export data into a delimited file and then open it in VI, the line breaks don't show up. At least, that's what happens with my very old version of Excel. Using the above one-liner on the file converts the carriage returns into line breaks that VI can interpret properly.

There's a much more thorough explanation here, which is where I got the idea from initially.