(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
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:
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.
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.
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:
# 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
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.
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.