c0d3 :: j0rg3

A collection of tips, tricks and snips. A proud Blosxom weblog. All code. No cruft.

Mon, 17 Feb 2014

Installing INN’s Project Largo in a Docker containter

Prereqruisites: Docker, Git, SSHFS.

Today we’re going to look at using Docker to create a WordPress installation with the Project Largo parent theme and a child theme stub for us to play with.

Hart Hoover has established an image for getting a WordPress installation up and running using Docker. For whatever reason, it didn’t work for me out-of-box but we’re going to use his work to get started.

Let’s make a place to work and move into that directory:
cd ~
mkdir project.largo.wordpress.docker
cd project.largo.wordpress.docker

We’ll clone the Docker/Wordpress project. For me, it couldn’t untar the latest WordPress. So we’ll download it outside the container, untar it and modify the Dockerfile to simply pull in a copy:
git clone https://github.com/hhoover/docker-wordpress.git
cd docker-wordpress/
ME=$(whoami)
wget http://wordpress.org/latest.tar.gz
tar xvf latest.tar.gz
sed -i 's/ADD http:\/\/wordpress.org\/latest.tar.gz \/wordpress.tar.gz/ADD \.\/wordpress \/wordpress/' Dockerfile
sed -i '/RUN tar xvzf \/wordpress\.tar\.gz/d' Dockerfile

Then, build the project which may take some time.
sudo docker build -t $ME/wordpress .

If you’ve not the images ready for Docker, the process should begin with something like:
Step 0 : FROM boxcar/raring
Pulling repository boxcar/raring
32737f8072d0: Downloading [> ] 2.228 MB/149.7 MB 12m29s

And end something like:
Step 20 : CMD ["/bin/bash", "/start.sh"]
---> Running in db53e215e2fc
---> 3f3f6489c700
Successfully built 3f3f6489c700

Once the project is built, we will start it and forward ports from the container to the host system, so that the Docker container’s site can be accessed through port 8000 of the host system. So, if you want to see it from the computer that you’ve installed it on, you could go to ‘HTTP://127.0.0.1:8000’. Alternatively, if your host system is already running a webserver, we could use SSHFS to mount the container’s files within the web-space of the host system.

In this example, however, we’ll just forward the ports and mount the project locally (using SSHFS) so we can easily edit the files perhaps using a graphical IDE such as NetBeans or Eclipse.

Okay, time to start our Docker image and find its IP address (so we can mount its files):
DID=$(docker run -p 8000:80 -d $ME/wordpress)
DIP=$(docker inspect $DID | grep IPAddress | cut -d '"' -f 4)
docker logs $DID| grep 'ssh user password:' --color

Copy the SSH password and we will make a local directory to access the WordPress installation of our containter.
cd ~
mkdir largo.mount.from.docker.container
sshfs user@$DIP:/var/www $HOME/largo.mount.from.docker.container
cd largo.mount.from.docker.container
PROJECT=$(pwd -P)

Now, we can visit the WordPress installation and finish setting up. From the host machine, it should be ‘HTTP://127.0.0.1:8000’. There you can configure Title, Username, Password, et cet. and finish installing WordPress.

Now, let’s get us some Largo! Since this is a test project, we’ll sacrifice security to make things easy. Our Docker WordPress site isn’t ready for us to easily install the Largo parent theme, so we’ll make the web directory writable by everybody. Generally, this is not a practice I would condone. It’s okay while we’re experimenting but permissions are very important on live systems!

Lastly, we’ll download and install Largo and the Largo child theme stub.
ssh user@$DIP 'sudo chmod -R 777 /var/www'
wget https://github.com/INN/Largo/archive/master.zip -O $PROJECT/wp-content/themes/largo.zip
unzip $PROJECT/wp-content/themes/largo.zip -d $PROJECT/wp-content/themes/
mv $PROJECT/wp-content/themes/Largo-master $PROJECT/wp-content/themes/largo
wget http://largoproject.wpengine.netdna-cdn.com/wp-content/uploads/2012/08/largo-child.zip -O $PROJECT/wp-content/themes/largo-child.zip
unzip $PROJECT/wp-content/themes/largo-child.zip -d $PROJECT/wp-content/themes
rm -rf $PROJECT/wp-content/themes/__MACOSX/

We are now ready to customize our Project Largo child theme!


Tags: , , , , , ,
Permalink: 20140217.project.largo.docker

Wed, 26 Jun 2013

Terminal suddenly Chinese

The other day, I was updating one of my systems and I noticed that it had decided to communicate with me in Chinese. Since I don’t know a lick of Chinese, it made for a clumsy exchange.

It was Linux Mint (an Ubuntu variant), so a snip of the output from an ‘apt-get upgrade’ looked like this: terminal screen with Chinese characters

I’m pretty sure I caused it — but there’s no telling what I was working on and how it slipped past me. Anyway, it’s not a difficult problem to fix but I imagine it could look like big trouble.

So, here’s what I did:
> locale

The important part of the output was this:
LANG=en_US.UTF-8
LANGUAGE=zh_CN.UTF-8

If you want to set your system to use a specific editor, you can set $EDITOR=vi and then you’re going to learn that some programs expect the configuration to be set in $VISUAL and you’ll need to change it there too.

In a similar way, many things were using the en_US.UTF-8 set in LANG, but other things were looking to LANGUAGE and determining that I wanted Chinese.

Having identified the problem, the fix was simple. Firstly, I just changed it in my local environment:
> LANGUAGE=en_US.UTF-8

That solved the immediate problem but, sooner or later, I’m going to reboot the machine and the Chinese setting would have come back. I needed to record the change somewhere for the system to know about it in the future.

> vim /etc/default/locale

Therein was the more permanent record, so I changed LANGUAGE there also, giving the result:

LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE=”en_US.UTF-8”
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=”en_US.UTF-8”
LC_PAPER=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=

And now, the computer is back to using characters that I (more-or-less) understand.


Tags: , , , , ,
Permalink: 20130626.terminal.suddenly.chinese

Wed, 15 May 2013

Git: an untracked mess?

There may be times when you find your Git repository burdened with scads of untracked files left aside while twiddling, testing bug patches, or what-have-youse.

For the especially scatter-brained among us, these things can go unchecked until a day when the useful bits of a git status scroll off the screen due to utterly unimportant stuff. Well, hopefully unimportant.

But we’d better not just cleave away everything that we haven’t checked in. You wonder:
What if there’s something important in one of those files?

You are so right!

Let’s fix this!

Firstly, we want a solution that’s reproducible. Only want to invent this wheel once, right?

Let’s begin with the play-by-play:

Git, we want a list of what isn’t tracked: git ls-files -o --exclude-standard -z

We’ll back these files up in our home directory (~), using CPIO but we don’t want a poorly-named directory or finding anything will become its own obstacle. So we’ll take use the current date (date +%Y-%m-%d), directory (pwd) and branch we’re using (git branch) and we’ll twist all of it into a meaningful, but appropriate, directory name using sed. git ls-files -o --exclude-standard -z | cpio -pmdu ~/untracked-git-backup-`date +%Y-%m-%d`.`pwd | sed 's,^\(.*/\)\?\([^/]*\),\2,'`.`git branch | grep "*" | sed "s/* //"`/

Then Tell Git to remove the untracked files and directories: git clean -d -f

Ahhhh… Much better. Is there anything left out? Perhaps. What if we decide that moving these files away was a mistake? The kind of mistake that breaks something. If we realize right away, it’s easily-enough undone. But what if we break something and don’t notice for a week or two? It’d probably be best if we had an automated script to put things back the way they were. Let’s do that.

Simple enough. We’ll just take the opposite commands and echo them into a script to be used in case of emergency.

Create the restore script (restore.sh), to excuse faulty memory: echo "(cd ~/untracked-git-backup-`date +%Y-%m-%d`.`pwd | sed 's,^\(.*/\)\?\([^/]*\),\2,'`.`git branch | grep "*" | sed "s/* //"`/; find . -type f \( ! -iname 'restore.sh' \) | cpio -pdm `pwd`)" > ~/untracked-git-backup-`date +%Y-%m-%d`.`pwd | sed 's,^\(.*/\)\?\([^/]*\),\2,'`.`git branch | grep "*" | sed "s/* //"`/restore.sh

Make the restore script executable: chmod u+x ~/untracked-git-backup-`date +%Y-%m-%d`.`pwd | sed 's,^\(.*/\)\?\([^/]*\),\2,'`.`git branch | grep "*" | sed "s/* //"`/restore.sh

Lastly, the magic, compressed into one line that will stop if any command does not report success: a='untracked-git-backup-'`date +%Y-%m-%d`.`pwd | sed 's,^\(.*/\)\?\([^/]*\),\2,'`.`git branch | grep "*" | sed "s/* //"`; git ls-files -o --exclude-standard -z | cpio -pmdu ~/$a/ && git clean -d -f && echo "(cd ~/$a/; find . -type f \( ! -iname 'restore.sh' \) | cpio -pdm `pwd`)" > ~/$a/restore.sh && chmod +x ~/$a/restore.sh; unset a


Tags: , , , ,
Permalink: 20130515.git.untracked.mess