news aggregator

Benjamin Rubin: Blogging with Ghost

Planet Ubuntu - Fri, 2013-12-27 22:37

So, I thought I'd give this blog thing a try again.

I'm not using wordpress this time around though. Instead, I'm giving Ghost (via github) try.

Since this wasn't going to be used for critical things, I opted to follow their developer-centric instructions. This allows me to pull down updates on the fly, instead of waiting for them to publish a new release. Even so, setup was still a breeze.

I deviated from their instructions a little, so for the record (and as an excuse to write something) I will document the procedure here.

  1. Create a user that Ghost's node.js process would run as.
    • sudo adduser ghost
  2. Install nodejs
    • sudo apt-get install nodejs
      • My linode is running 13.04, so I needed to find a PPA that could provide node.js 0.10.x. Since vetting PPAs is not something I want to do here, I'll leave it as an exercise for the reader.
  3. Install grunt
    • sudo npm install -g grunt-cli
  4. Switch to the ghost user
    • sudo su ghost
  5. Use rvm to install Ruby 1.9.3
    • curl -sSL | bash -s stable --ruby=1.9.3
  6. Install the bundler gem
    • gem install bundler
  7. Clone the git repo
    • git clone
  8. Drop into the newly cloned repo and pull down their linked submodules (this includes things like their default theme, which they track in a separate github repo)
    • cd Ghost && git submodule update --init
  9. Use bundler to pull the project's ruby dependencies
    • bundler install
  10. Use npm to pull the project's node dependencies
    • npm install
  11. Compile Ghost's assets
    • grunt init
  12. Modify the default config as necessary
    • vim config.js
  13. Run it
    • npm start
  14. The node.js instance will begin listening on http://localhost:2368, you'll need configure your preferred webserver provide a reverse proxy to this.
  15. You'll also likely want to keep npm running by setting it up as a service. Since there are a few options on how to do that I'll just point to the official docs here.

Stéphane Graber: LXC 1.0: Container storage [5/10]

Planet Ubuntu - Fri, 2013-12-27 22:00

This is post 5 out of 10 in the LXC 1.0 blog post series.

Storage backingstores

LXC supports a variety of storage backends (also referred to as backingstore).
It defaults to “none” which simply stores the rootfs under
/var/lib/lxc/<container>/rootfs but you can specify something else to lxc-create or lxc-clone with the -B option.

Currently supported values are:

directory based storage (“none” and “dir)

This is the default backingstore, the container rootfs is stored under

The --dir option (when using “dir”) can be used to override the path.


With this backingstore LXC will setup a new subvolume for the container which makes snapshotting much easier.


This one will use a new logical volume for the container.
The LV can be set with --lvname (the default is the container name).
The VG can be set with --vgname (the default is “lxc”).
The filesystem can be set with --fstype (the default is “ext4″).
The size can be set with --fssize (the default is “1G”).
You can also use LVM thinpools with --thinpool


This one is mostly used when cloning containers to create a container based on another one and storing any changes in an overlay.

When used with lxc-create it’ll create a container where any change done after its initial creation will be stored in a “delta0″ directory next to the container’s rootfs.


Very similar to btrfs, as I’ve not used either of those myself I can’t say much about them besides that it should also create some kind of subvolume for the container and make snapshots and clones faster and more space efficient.

Standard paths

One quick word with the way LXC usually works and where it’s storing its files:

  • /var/lib/lxc (default location for containers)
  • /var/lib/lxcsnap (default location for snapshots)
  • /var/cache/lxc (default location for the template cache)
  • $HOME/.local/share/lxc (default location for unprivileged containers)
  • $HOME/.local/share/lxcsnap (default location for unprivileged snapshots)
  • $HOME/.cache/lxc (default location for unprivileged template cache)

The default path, also called lxcpath can be overridden on the command line with the -P option or once and for all by setting “lxcpath = /new/path” in /etc/lxc/lxc.conf (or $HOME/.config/lxc/lxc.conf for unprivileged containers).

The snapshot directory is always “snap” appended to lxcpath so it’ll magically follow lxcpath. The template cache is unfortunately hardcoded and can’t easily be moved short of relying on bind-mounts or symlinks.

The default configuration used for all containers at creation time is taken from
/etc/lxc/default.conf (no unprivileged equivalent yet).
The templates themselves are stored in /usr/share/lxc/templates.

Cloning containers

All those backingstores only really shine once you start cloning containers.
For example, let’s take our good old “p1″ Ubuntu container and let’s say you want to make a usable copy of it called “p4″, you can simply do:

sudo lxc-clone -o p1 -n p4

And there you go, you’ve got a working “p4″ container that’ll be a simple copy of “p1″ but with a new mac address and its hostname properly set.

Now let’s say you want to do a quick test against “p1″ but don’t want to alter that container itself, yet you don’t want to wait the time needed for a full copy, you can simply do:

sudo lxc-clone -o p1 -n p1-test -B overlayfs -s

And there you go, you’ve got a new “p1-test” container which is entirely based on the “p1″ rootfs and where any change will be stored in the “delta0″ directory of “p1-test”.
The same “-s” option also works with lvm and btrfs (possibly zfs too) containers and tells lxc-clone to use a snapshot rather than copy the whole rootfs across.


So cloning is nice and convenient, great for things like development environments where you want throw away containers. But in production, snapshots tend to be a whole lot more useful for things like backup or just before you do possibly risky changes.

In LXC we have a “lxc-snapshot” tool which will let you create, list, restore and destroy snapshots of your containers.
Before I show you how it works, please note that “lxc-snapshot” currently doesn’t appear to work with directory based containers. With those it produces an empty snapshot, this should be fixed by the time LXC 1.0 is actually released.

So, let’s say we want to backup our “p1-lvm” container before installing “apache2″ into it, simply run:

echo "before installing apache2" > snap-comment sudo lxc-snapshot -n p1-lvm -c snap-comment

At which point, you can confirm the snapshot was created with:

sudo lxc-snapshot -n p1-lvm -L -C

Now you can go ahead and install “apache2″ in the container.

If you want to revert the container at a later point, simply use:

sudo lxc-snapshot -n p1-lvm -r snap0

Or if you want to restore a snapshot as its own container, you can use:

sudo lxc-snapshot -n p1-lvm -r snap0 p1-lvm-snap0

And you’ll get a new “p1-lvm-snap0″ container which will contain a working copy of “p1-lvm” as it was at “snap0″.


Subscribe to Free Software Magazine aggregator