Since MySQL v.5.5.29 the mysqldump command can generate the following error:

-- Warning: Skipping the data of table mysql.event. Specify the --events option explicitly.

An example of mysqldump for full dumps is this:

mysqldump --opt -u <USERNAME> -p<PASSWORD> --all-databases | gzip > full_dump.sql.gz  

In a case of a server which executes it during periodical backups, this means a warning email from Cron Daemon, very annoying.

If you add, as suggested, the --events option you can receive this error:

mysqldump: Couldn't execute 'show events':  
  Access denied for user '<USERNAME>'@'localhost' to database '<DATABASE>' (1044)

The solution is to grant the EVENT permission to the user:

GRANT EVENT ON <DATABASE>.* to '<USERNAME>'@'localhost' with grant option;  

Apparently if you don't care about events there's no way to suppress the error message with some --no-events option, as far as I know.
There's an interesting discussion about this (maybe-not-a-)bug here

Waiting for a sitemap generator inside the core of Ghost (planned as "future implementation") I decided to implement a way to generate an up-to-date sitemap.xml during deployment.
As you can read in the previous post I'm deploying this blog with Capistrano and capistrano-node-deploy.
So I added a deploy:generate_sitemap task which is executed at the end of the deployment process.

This is the Capfile extract:

namespace :deploy do  
  task :generate_sitemap do
    run "cd #{latest_release} && ./ #{latest_release}"
after "node:restart", "deploy:generate_sitemap"  

So at the end of the deployment the script is executed. The script is placed in the blog root and is a personalized version of the code you can find here:

It essentially does 3 things:

  • Puts the sitemap.xml link in the robots.txt file
  • Scans (using wget) the website and generates the sitemap.xml file in the content folder
  • Notifies Google Webmaster Tools

What I changed of the original script is:


user and group will be used to chmod the sitemap.xml file, so check that the web user (probably www-data) can read that file.

This process has a big problem: the sitemap is generated only during deploy, not when I publish a new post. A workaround is to run cap deploy:generate_sitemap after a new post is published.

It works but I need an automatic way. Any idea?

I just moved this blog from Jekyll to Ghost (v.0.4.2 while writing this post) and I had to find a fast way to deploy new changes to the server.
I'm pretty confident with Capistrano so, although Ghost doesn't use Ruby, I decided to use it to manage deployments.
A cool gem allow node apps to be deployed with Capistrano: capistrano-node-deploy

This is the Gemfile:

source ''  
gem 'capistrano', '~> 2.15.5'  
gem 'capistrano-node-deploy', '~> 1.2.14'  
gem 'capistrano-shared_file', '~> 0.1.3'  
gem 'capistrano-rbenv', '~> 1.0.5'  

If you don't use rbenv just remove the related line in the Gemfile and change the Capfile accordingly.

This configuration works well, but it has some problem if you use nvm instead of a system-wide installation of node and npm.

To fix them I had to add some variables (nvm_path, node_binary and npm_binary) and totally override the node:install_packages task. Whithout this changes the deploy task ends with messages like:

/usr/bin/env: node
No such file or directory  


node: not found  

This isn't really a good way, because you must change the nvm_path every time you upgrade nvm, but it's the only way I actually found :)

I also changed the app_command variable to launch node ~/apps/ instead of node ~/apps/ in the upstart script. The second command doesn't actually works although is the gem's default.

This is the full content of the Capfile (remember to change to your own):

require "capistrano/node-deploy"  
require "capistrano/shared_file"  
require "capistrano-rbenv"  
set :rbenv_ruby_version, "2.1.1"

set :application, ""  
set :user, "<USERNAME>"  
set :deploy_to, "/home/#{user}/apps/#{application}"

set :app_command, "index"

set :node_user, "<USERNAME>"  
set :node_env, "production"  
set :nvm_path, "/home/<USERNAME>/.nvm/v0.10.26/bin"  
set :node_binary, "#{nvm_path}/node"  
set :npm_binary, "#{nvm_path}/npm"

set :use_sudo, false  
set :scm, :git  
set :repository,  "<GIT REPO URL>"

default_run_options[:pty] = true  
set :ssh_options, { forward_agent: true }

server "<SERVER HOSTNAME OR IP>", :web, :app, :db, primary: true

set :shared_files,    ["config.js"]  
set :shared_children, ["content/data", "content/images"]

set :keep_releases, 3

namespace :deploy do  
  task :mkdir_shared do
    run "cd #{shared_path} && mkdir -p data images files"

  task :generate_sitemap do
    run "cd #{latest_release} && ./ #{latest_release}"

namespace :node do  
  desc "Check required packages and install if packages are not installed"
  task :install_packages do
    run "mkdir -p #{previous_release}/node_modules ; cp -r #{previous_release}/node_modules #{release_path}" if previous_release
    run "cd #{release_path} && PATH=#{nvm_path}:$PATH #{npm_binary} install --loglevel warn"

after "deploy:create_symlink", "deploy:mkdir_shared"  
after "node:restart", "deploy:generate_sitemap"  
after "deploy:generate_sitemap", "deploy:cleanup"  

Recentemente non sono riuscito ad aggiornare molto questo blog. Spesso la causa non è stata la mancanza di contenuti, ma la non immediatezza della piattaforma. È vero, con Jekyll mi sono divertito e l'idea di servire un sito statico secondo me è grandiosa, ma l'implementazione è effettivamente molto scarna e questo mi ha spesso fermato quando avrei voluto iniziare a scrivere un articolo e basta.

Da un po' di tempo mi sto quindi guardando intorno alla ricerca di una nuova piattaforma, nella convinzione che comunque non voglio usare Wordpress.

Per l'appunto nelle ultime settimane ho iniziato a riscrivere l'interfaccia di Rubyfatt utilizzando Ember e, quasi contemporaneamente, ho iniziato a sentir parlare di Ghost che ha appunto deciso di riscrivere l'interfaccia di amministrazione con Ember. Mi è subito sembrata un'occasione da cogliere al volo.

Sto lavorando sulla migrazione da Jekyll a Ghost, molto presto le pagine del blog potrebbero quindi cambiare aspetto per l'ennesima volta