GeekTank

AutoMySQLBackup is a shell script that allows daily, weekly and monthly backups of your local and remote MySQL Databases. It’s meant to run on Linux/Unix through a cron job. Its highly configurable, and easy to setup as I will show you today!

First you will need to acquire the shell script and drop it on your server. You can download AutoMySQLBackup on their SourceForge Project Page

Typically I will just do a “wget” into a downloads folder within my root directory just to keep it organized:

[root@jager:/root]# mkdir download
[root@jager:/root]# cd download/
[root@jager:/root/download]# wget “http://internap.dl.sourceforge.net/sourceforge/automysqlbackup/automysqlbackup.sh.2.5″
–12:01:24– http://internap.dl.sourceforge.net/sourceforge/automysqlbackup/automysqlbackup.sh.2.5
=> `automysqlbackup.sh.2.5′
Resolving internap.dl.sourceforge.net… 66.79.151.7, 66.79.148.7
Connecting to internap.dl.sourceforge.net|66.79.151.7|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 25,316 (25K) [application/x-sh]

100%[=======================================================================================================================================>] 25,316 –.–K/s

12:01:25 (180.28 KB/s) – `automysqlbackup.sh.2.5′ saved [25316/25316]

[root@jager:/root/download]#

Now that we have the script, we need to give it a home. Since this is a custom script thats not apart of the distribution, we can place it in “/usr/local/sbin”.

[root@jager:/root/download]# cp automysqlbackup.sh.2.5 /usr/local/sbin/automysqlbackup.sh
`automysqlbackup.sh.2.5′ -> `/usr/local/sbin/automysqlbackup.sh’
[root@jager:/root/download]# cd /usr/local/sbin
[root@jager:/usr/local/sbin]# ls -la
total 44K
drwxrwsr-x 2 root staff 4096 2008-01-17 12:03 ./
drwxrwsr-x 10 root staff 4096 2007-05-29 10:01 ../
-rw-r–r– 1 root staff 25316 2008-01-17 12:03 automysqlbackup.sh

So now the script has a home we must allow it to run. A simple “chmod u+x” will do, you will also want to confirm that only the user has execute permission and not the group or other since we don’t want users on the server running the script or even seeing whats inside the file as it will have a database login.

[root@jager:/usr/local/sbin]# chmod u+x automysqlbackup.sh
[root@jager:/usr/local/sbin]# ls -al
total 44K
drwxrwsr-x 2 root staff 4096 2008-01-17 12:03 ./
drwxrwsr-x 10 root staff 4096 2007-05-29 10:01 ../
-rwxr–r– 1 root staff 25316 2008-01-17 12:03 automysqlbackup.sh*

As you can see above, User/Group/Other have read access, which we will have to change.

[root@jager:/usr/local/sbin]# chmod 700 automysqlbackup.sh
[root@jager:/usr/local/sbin]# ls -al
total 44K
drwxrwsr-x 2 root staff 4096 2008-01-17 12:03 ./
drwxrwsr-x 10 root staff 4096 2007-05-29 10:01 ../
-rwxr-xr-x 1 root staff 4184 2008-01-01 05:27 addwww*
-rwx—— 1 root staff 25316 2008-01-17 12:03 automysqlbackup.sh*

There, now only the user will be able to execute and read the files contents. Lets move on to configuration.

The configuration is rather simple, you’ll be asked for a username, password and hostname as well as a directory that you would like to have the backups stored. Now this will pose a security concern as you will be providing your login information for your databases, you can choose to use the root login or create a login that will only allow SELECT for all databases. This is mostly up to you, just remember that its possible if you system is compromised or if permissions change on this file that 3rd parties might have access to the login information contained within this file.

Lets go over the basics.

# Username to access the MySQL server e.g. dbuser
USERNAME=root

# Username to access the MySQL server e.g. password
PASSWORD=password

# Host name (or IP address) of MySQL server e.g localhost
DBHOST=localhost

# List of DBNAMES for Daily/Weekly Backup e.g. “DB1 DB2 DB3″
DBNAMES=”DB1 DB2 DB3″

# Backup directory location e.g /backups
BACKUPDIR=”/backups”

# Mail setup
# What would you like to be mailed to you?
# – log : send only log file
# – files : send log file and sql files as attachments (see docs)
# – stdout : will simply output the log to the screen if run manually.
# – quiet : Only send logs if an error occurs to the MAILADDR.
MAILCONTENT=”stdout”

# Set the maximum allowed email size in k. (4000 = approx 5MB email [see docs])
MAXATTSIZE=”4000″

# Email Address to send mail to? (user@domain.com)
MAILADDR=”user@domain.com”

Most of the above is pretty straight forward, you mostly have to just change the username and password and chagne “DBNAMES” to “ALL”. You will also want to keep track of the backups via email incase they break. Here’s and example configuration:

# Username to access the MySQL server e.g. dbuser
USERNAME=root

# Username to access the MySQL server e.g. password
PASSWORD=mymysqlpassword

# Host name (or IP address) of MySQL server e.g localhost
DBHOST=localhost

# List of DBNAMES for Daily/Weekly Backup e.g. “DB1 DB2 DB3″
DBNAMES=”all”

# Backup directory location e.g /backups
BACKUPDIR=”/home/backup”

# Mail setup
# What would you like to be mailed to you?
# – log : send only log file
# – files : send log file and sql files as attachments (see docs)
# – stdout : will simply output the log to the screen if run manually.
# – quiet : Only send logs if an error occurs to the MAILADDR.
MAILCONTENT=”stdout”

# Set the maximum allowed email size in k. (4000 = approx 5MB email [see docs])
MAXATTSIZE=”4000″

# Email Address to send mail to? (user@domain.com)
MAILADDR=”root”

There is detailed information within the configuration file that outlines each option and its purposes and values. The following are a couple that you should keep in mind or that might be relevant.

# Put in the list of DBNAMES(Databases)to be backed up. If you would like
# to backup ALL DBs on the server set DBNAMES=”all”.(if set to “all” then
# any new DBs will automatically be backed up without needing to modify
# this backup script when a new DB is created).

The following has a good point about cron.d on Debian:

# Finally copy automysqlbackup.sh to anywhere on your server and make sure
# to set executable permission. You can also copy the script to
# /etc/cron.daily to have it execute automatically every night or simply
# place a symlink in /etc/cron.daily to the file if you wish to keep it
# somwhere else.
# NOTE:On Debian copy the file with no extention for it to be run
# by cron e.g just name the file “automysqlbackup”

# The list of MDBNAMES is the DB’s to be backed up only monthly. You should
# always include “mysql” in this list to backup your user/password
# information along with any other DBs that you only feel need to
# be backed up monthly. (if using a hosted server then you should
# probably remove “mysql” as your provider will be backing this up)
# NOTE: If DBNAMES=”all” then MDBNAMES has no effect as all DBs will be backed
# up anyway.

The following is the exact rotation schedule.

#=====================================================================
# Backup Rotation..
#=====================================================================
#
# Daily Backups are rotated weekly..
# Weekly Backups are run by default on Saturday Morning when
# cron.daily scripts are run…Can be changed with DOWEEKLY setting..
# Weekly Backups are rotated on a 5 week cycle..
# Monthly Backups are run on the 1st of the month..
# Monthly Backups are NOT rotated automatically…
# It may be a good idea to copy Monthly backups offline or to another
# server..

So now you just need to install a cron for this to run daily! Just enter the following into your /etc/crontab.

59 11 * * * root /usr/local/sbin/automysqlbackup.sh

The about line will run the backup at midnight based on the servers timezone. You can also copy the script to /etc/cron.daily if you’re on Debian or if your distribution supports this method.

[root@jager:/usr/local/sbin]# mv automysqlbackup.sh /etc/cron.daily/automysqlbackup

You must make sure that you leave the .sh off the end of the filename in order for it to be processed by the cron daemon. Last but not least run the script and see if it works!

I woke up to a very big announcement today. I was browsing digg and found that MySQL was acquired by Sun Microsystems. You can read more about the acquisition on the MySQL blog of Kaj Arno about the acquisition of MySQL by Sun Microsystems. My take, with Sun releasing Solaris into the Open Source realm, this is just another piece of software that they can put under their belt and package with Solaris. I have included some blurbs from Kaj Arno’s blog below.

After all the industry speculation about MySQL being a “hot 2008 IPO”, this probably takes most of us by surprise — users, community members, customers, partners, and employees. And for all of these stakeholders, it may take some time to digest what this means. Depending on one’s relationship to MySQL, the immediate reaction upon hearing the news may be a mixture of various feelings, including excitement, pride, disbelief and satisfaction, but also anxiety.

Facts on Sun Microsystems

* Founded 1982 by Andreas von Bechtolsheim, Vinod Khosla, Bill Joy and Scott McNealy
* 34.200 employees worldwide, 13.9 billion dollars (9.4 billion euros) in revenues FY 2007, market cap (total value of all Sun shares) about the same as yearly revenues
* Grew astronomically with the Web, suffered from the Web bubble, now profitable over the last four quarters
* Lead by Scott McNealy until 2006, now by Jonathan Schwartz (a prolific blogger)
* The world’s biggest contributor to Open Source: Open Office, Java (now under GPL), GlassFish, NetBeans — and soon MySQL
* Environmentally friendly; large numbers of distributed employees working at least partially from home
* Headquartered in Santa Clara, California, just south of Cupertino (MySQL’s North American headquarters)
* Counts some of the worlds most brilliant innovators amongst its current and past employees

Sun’s track record is embodied by individuals with a solid set of FOSS values, such as Simon Phipps (Sun’s Chief Open Source Officer), Ian Murdock (Debian founder, now Sun’s Chief OS Strategist), and Josh Berkus (PostgreSQL lead). I’ve met all three in various FOSS arenas, I respect their work, and I am looking forward to be working closely with them.

Absolutely not. MySQL is still being managed by the same people, and the charter is still the same. There is no need for reducing the set of platforms or languages. It only makes sense for us to continue to support defacto Web development standards like LAMP, as well as emerging ones like Ruby and Eclipse. This deal is about addition, not subtraction.

But I don’t expect that in any way to be at the cost of other popular operating systems (Linux, Windows, Mac OS/X, other Unixes etc.) or development environments (PHP, Ruby on Rails, Perl, Python, ODBC, C++, C#, VB etc.). MySQL grew with LAMP and MySQL without LAMP at its core is simply unimaginable. It was MySQLs part of LAMP that interested Sun in the first place. Hence I don’t see Sun having a platform migration strategy, but to continue to be an integral part of the dot in .com.

What does the acquisition of MySQL by Sun mean for the core MySQL community?

I’d like to think that the acquisition of MySQL by Sun will be seen as good news also by the core group of users who form the active MySQL community. This is because Sun is a safe haven for MySQL. Sun knows Open Source, and to the extent things change, I expect Sun to add value to our community. I don’t expect huge change, though. We continue to work with our quality contributors, we continue to provide our MySQL Forums, the Planet MySQL blog aggregator, we remain on the #mysql-dev and #mysql channels on Freenode, we provide MySQL University lessons, we meet at the MySQL Users Conference. We’ll put effort into connecting the many FOSS enthusiasts and experts at Sun — whom we will now learn to know better — with our active user community.

XCache is an opcode cacher for PHP developed by the Lighttpd team. The full description directly from http://xcache.lighttpd.net/

XCache is a fast, stable PHP opcode cacher that has been tested and is now running on production servers under high load. It is tested (on linux) and supported on all of the latest PHP cvs branches such as PHP_4_3 PHP_4_4 PHP_5_0 PHP_5_1 PHP_5_2 HEAD(6.x). ThreadSafe/Windows is also supported. It overcomes a lot of problems that has been with other competing opcachers such as being able to be used with new PHP versions. See Introduction for more information.

There is no XCache package within the apt repositories for Debian Etch, however it is available within Debian SID/Testing. You will need to then download the source, compile it and install it. You can download the 1.2 stable source from the following here:

http://xcache.lighttpd.net/wiki/Release-1.2.2

http://xcache.lighttpd.net/pub/Releases/1.2.2/xcache-1.2.2.tar.gz

The second link is the full XCache source, you can use “wget”, “curl” or lynx to retrieve the archive onto your machine.

Once downloaded, extract the archive and a directory called xcache-1.2.2 should have been created and you will want to change directory into it:


[root@jager:/root/source/xcache]# tar -zxvf xcache-1.2.2.tar.gz
[root@jager:/root/source/xcache]# ls -al
total 280K
drwxr-xr-x 3 root root 4096 2008-01-14 18:58 ./
drwxr-xr-x 4 root root 4096 2008-01-14 18:58 ../
drwxr-xr-x 5 513 513 4096 2007-12-28 10:00 xcache-1.2.2/
-rw-r--r-- 1 root root 269238 2007-12-28 23:45 xcache-1.2.2.tar.gz
[root@jager:/root/source/xcache]# cd xcache-1.2.2


You will need to make sure that you have “php5-devel” installed so you can use “phpize” to create the module, a simply “apt-get install php5-dev” as root should do the trick. You may need to type “rehash” if using tcsh to be able to run “phpize”.

Now we need to prepare the module for configuration by typing the following:


[root@jager:/root/source/xcache/xcache-1.2.2]# phpize --clean && phpize
Cleaning..
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20060613
Zend Extension Api No: 220060519


Then you will need to configure XCache before compiling, at this point you may want to run “./configure –help”. Which will provide information on the configuration options available for XCache that you can change when it compiles. If you don’t need to change anything, just run “./configure”.

If any errors were returned then you’re most likely missing some supporting packages and you will need to install them. If no errors were returned then you can simply run “make”.

Once the module has been compiled it should now reside within the “modules” directory. You can now copy to the proper PHP5 module directory:


[root@jager:/root/source/xcache/xcache-1.2.2]# cp modules/xcache.so /usr/lib/php5/20060613+lfs
`modules/xcache.so' -> `/usr/lib/php5/20060613+lfs/xcache.so'


Now that the module exists, we need to make a configuration file for it so that PHP5 will load the module and configuration. You should see a “xcache.ini” within the root folder of the extract archive. Just copy it to the correct configuration folder within /etc:


/etc/php5/apache/conf.d <- Configuration file for PHP5 as a Module in apache1.3x
/etc/php5/apache2/conf.d <- Configuration file for PHP5 as a Module in apache2.x
/etc/php5/cgi/conf.d <- Configuration file for PHP5 compiled as a CGI Binary
/etc/php5/cli/conf.d <- Configuration file for PHP5 compiled as a Command Line Binary


For our example, I'm using the PHP5 CGI Binary:


[root@jager:/root/source/xcache/xcache-1.2.2]# cp xcache.ini /etc/php5/cgi/conf.d/.
`xcache.ini' -> `/etc/php5/cgi/conf.d/./xcache.ini'


Now make sure to edit the following configuration values within the xcache.ini file:


[xcache-common]
;; install as zend extension (recommended), normally "$extension_dir/xcache.so"
zend_extension = /usr/local/lib/php/extensions/non-debug-non-zts-xxx/xcache.so
; zend_extension_ts = /usr/local/lib/php/extensions/non-debug-zts-xxx/xcache.so
;; For windows users, replace xcache.so with php_xcache.dll
zend_extension_ts = c:/php/extensions/php_xcache.dll
;; or install as extension, make sure your extension_dir setting is correct
; extension = xcache.so
;; or win32:
; extension = php_xcache.dll


Change the "zend_extension" to just "xcache.so" and comment out "zend_extension_ts " like so:


[xcache-common]
;; install as zend extension (recommended), normally "$extension_dir/xcache.so"
extension = xcache.so
; zend_extension_ts = /usr/local/lib/php/extensions/non-debug-zts-xxx/xcache.so
;; For windows users, replace xcache.so with php_xcache.dll
;zend_extension_ts = c:/php/extensions/php_xcache.dll
;; or install as extension, make sure your extension_dir setting is correct
; extension = xcache.so
;; or win32:
; extension = php_xcache.dll


You will also need to change the following from:


; to enable : xcache.size=64M etc (any size > 0) and your system mmap allows
xcache.size = 64M
; set to cpu count (cat /proc/cpuinfo |grep -c processor)
xcache.count = 1


To something like the following:


; to enable : xcache.size=64M etc (any size > 0) and your system mmap allows
xcache.size = 64M
; set to cpu count (cat /proc/cpuinfo |grep -c processor)
xcache.count = 4


If you have a Dual Pentium4 with Hyper Threading.

Just restart apache by issuing "invoke-rc.d apache2 restart", and all should be working!

To test whether or not the extension/module was loaded and working, you can put the following code within an PHP file and pull it up in your browser and search for XCache:

And you should see the following:


This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies
with XCache v1.2.2, Copyright (c) 2005-2007, by mOo


Enjoy!

I always thought there was something really strange about the WHOIS searches done at Registrars. Specifically the searches would have to be done on their website, a normal “whois” lookup through Linux wouldn’t show up registered the next day.

A story is developing regarding domain name registrar Network Solutions front running domains. According to multiple sources on DomainState.com, it appears that domains searched via NSI are being purchased by the registrar thereby preventing a registrant from purchasing it at any other registrar other than NSI. As an example, a random domain which DNN searches such as HowDoesThisDomainTasteTaste.com can be seen in this whois search to now be unavailable to register at other registrars but at NSI it can be purchased

Full article at domainnamenews.com

I always thought there was something really strange about the WHOIS searches done at Registrars. Specifically the searches would have to be done on their website, a normal “whois” lookup through Linux wouldn’t show up registered the next day.

A story is developing regarding domain name registrar Network Solutions front running domains. According to multiple sources on DomainState.com, it appears that domains searched via NSI are being purchased by the registrar thereby preventing a registrant from purchasing it at any other registrar other than NSI. As an example, a random domain which DNN searches such as HowDoesThisDomainTasteTaste.com can be seen in this whois search to now be unavailable to register at other registrars but at NSI it can be purchased

Full article at domainnamenews.com