Backup and Restore MySQL Databases

To export a MySQL database into a dump file:

$ mysqldump -u username -ppassword db_name > db_name.sql

(No, that’s not a typo; there is no space between -p and password.)

Data, tables, structures and database of database_name will be backed up into a SQL text file named db_name.sql.

To import a MySQL database, upload the dump file to the MySQL server, and use the following command to import the databases back into the MySQL server:

$ mysql -u username -ppassword db_name < db_name.sql

Backup of Chyrp

With NB, off-line backup was rather easy - essentially I was dealing with textual content from two sources that could be easily synchronized with basic shell tools.

Chyrp, on the other hand, required that I duplicate both the MySQL database and the static content, and that I had a web browser handy to access the graphical markup tools provided.

I had to dump the contents of the remote MySQL database to a local file, which could then be used to recreate the on-line database if ever the need arose. I created the following script for that purpose:

1
2
3
4
5
6
7
8

#!/bin/sh
MYSQLBACKUP=/home/$USER/.mysql_backup
DB_NAME=dump.sql
[ -f $MYSQLBACKUP/$DB_NAME.1 ] && mv -f $MYSQLBACKUP/$DB_NAME.1 $MYSQLBACKUP/$DB_NAME.2
[ -f $MYSQLBACKUP/$DB_NAME.0 ] && mv -f $MYSQLBACKUP/$DB_NAME.0 $MYSQLBACKUP/$DB_NAME.1
[ -f $MYSQLBACKUP/$DB_NAME ] && mv -f $MYSQLBACKUP/$DB_NAME $MYSQLBACKUP/$DB_NAME.0
ssh USER@host mysqldump -h MYSQL.HOST -u USER -pPASSWORD DBNAME > $MYSQLBACKUP/$DB_NAME

With a rudimentary backup method in place, I could now completely migrate away from NanoBlogger.

Themes in Chyrp

This page provides the links to modules/themes/feathers.

Installation involves downloading the zip archive, and extracting its contents to a similarly-named directory under themes/. You’d then need to activate it via the admin panel.

By the by, I was rather disappointed that the archives were only available as .zip archives. I’d much rather these archives be available in .tar.gz, or some other commonly used *nix format. To add insult to injury, several of the themes - gull and grackle - had .zip archives that produced errors when uncompressed with 7zip in Windows. These exact same archives extracted fine under OpenBSD.

Thoughts on Chyrp

I recently found out about Chyrp from a co-worker, who had been alpha-testing it for a while now. She took some time out of her busy work day to advocate its usage.

From Chyrp’s Homepage

Chyrp is a blogging engine designed to be very lightweight while retaining functionality. It is powered by PHP and has very powerful theme and extension engines, so you can personalize it however you want. The code is well-documented, and it has a very strong structure that’s loosely based on the MVC design pattern.

Upon installing Chyrp onto the bur.st host, I found it to be scalable; quick to deploy; fast to navigate; functional; aesthetically appealing; and very quick - something that couldn’t be said about NB.

One oversight made by developers of Chyrp was that, by default, noone was able to access any pages (!). As it turned out, the default .htaccess file that shipped with Chyrp-2.0, or even the git-version, did not have global-read permissions. This basically prevented the www-data system group from accessing the file, and in turn, this prevented all WWW users from viewing anything on the site. The issue was easily resolved by a $ chmod +r .htacccess.

Binary Patches for OpenBSD 4.6

To track stable, you don’t necessarily need to work with cvs snapshots. Ideally, you’d fetch all relevant patches for your architecture and OpenBSD version from here and cobble together those patches with binpatch

This also requires that you fetch architecture-independant src.tar.gz and sys.tar.gz from here, and all installation-set tarballs from here.

From the project description file, the tree structure is then:

  • binpatch-1.1.0/

  • Makefile

  • bsd.binpatch.mk

  • distfiles/

    • i386/
    • src.tar.gz
    • sys.tar.gz
  • packages/

  • patches/

    • common/
    • i386/
  • pkg/

    • (e.g. PLIST-i386-001)
  • work-binpatch-4.6/

    • fake/
    • obj/
    • src/

The following changes to Makefile were made to suit patches for OpenBSD 4.6:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

### Last Updated: June 3rd 2010

# List of patches for all architectures
PATCH_COMMON=001_bind 003_getsockopt 004_openssl 005_ptrace 006_openssl 007_ftpd 008_kerberos 009_mpi 010_openssl 011_pfsync 012_trunklacp
# List of patches for i386 only
PATCH_I386=002_xmm
#...
002_xmm: _kernel
003_getsockopt: _kernel
005_ptrace: _kernel
009_mpi: _kernel
011_pfsync: _kernel
012_trunklacp: _kernel

001_bind:
cd ${WRKSRC}/usr.sbin/bind && \
(${_obj_wrp}; ${_depend_wrp}; ${_build_wrp})

004_openssl:
cd ${WRKSRC}/lib/libssl && \
(${_obj}; ${_depend}; ${_includes}; ${_build}) && \
cd ${WRKSRC}/sbin && \
(${_obj}; ${_depend}; ${_build})

006_openssl:
cd ${WRKSRC}/lib/libssl && \
(${_obj}; ${_depend}; ${_includes}; ${_build}) && \
cd ${WRKSRC}/sbin && \
(${_obj}; ${_depend}; ${_build})

007_ftpd:
cd ${WRKSRC}/libexec/ftpd && \
(${_depend}; ${_build})

008_kerberos:
cd ${WRKSRC}/lib/libkrb5 && \
(${_obj}; ${_depend}; ${_build}) && \
cd ${WRKSRC}/kerberosV/libexec/kdc && \
(${_obj}; ${_depend}; ${_build})

010_openssl:
cd ${WRKSRC}/lib/libssl && \
(${_obj}; ${_depend}; ${_includes}; ${_build}) && \
cd ${WRKSRC}/sbin && \
(${_obj}; ${_depend}; ${_build})

You’ll need to modify the above to include more recent patches i.e. patches dated later than June 3rd 2010.

To patch the relevant files on your OpenBSD install, and to prepare packages (in packages/) for installation, as root:

# make PATCH="001" build

# make PATCH="001" plist

# make PATCH="001" package

To install the packages, do:

# make PATCH="001" install

I prefer to use the following script (documented here) to install packages:

1
2
3
4

#!/bin/sh
tar xzpf "$1" -C /
mkdir -p /var/db/patches/$(basename "$1" .tgz)

.. or to query previously installed packages:

# ls /var/db/patches/

On Fedora 12

My girlfriend’s Sony VAIO laptop has been nothing short of a nightmare to maintain. It ran Windows Vista - the Windows M.E. for the Facebook generation - and was indubitably doomed to fail from the OEM.

After addressing one technical problem too many, I decided to do away with Vista on the laptop altogether, and to install a basic Linux distribution. Fedora’s DVD seemed to provide all the tools my partner would ever need in her lifetime of computer-interaction, and so it came to pass that F12 was introduced to the household.

![7180173935_d1b0be84a9](/images/ae9ccea53f5bf95b2d5f01457a4a8864530513e2.jpg)

PHP/MySQL-based Solution for Blog

While I’ve found NanoBlogger to be extremely intuitive and easy to deploy, I’ve come to the realization that bash and co. simply don’t scale well with lots of entries, and that they aren’t nearly as effective as other database-querying solutions.

On one of my sites in particular, $ nb update all took all of 10 minutes to complete - this was with a ‘quick’ 2-line hack of the display template. Pitiful performance for something I once thought was lean and mean - though I should have known that from the start.

I’m also entertaining the idea of using a perl-based CMS called BlazeBlogger. It’s reportedly very fast at serving static files, and as it is based on Perl, does not require a database. From BlazeBlogger’s About page:

BlazeBlogger is a simple to use but capable CMS for the command line. Being written in Perl as a cross-platform application, and producing static content without the need of database servers or server-side scripting, it is literally a CMS without boundaries suitable for a wide variety of web presentations, from a personal weblog to a project page, or even a company website.