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

Thu, 13 Jun 2013

Blogitechture continued… Simplify with Vim

Last we were discussing the structure and design of your own CLI-centric blog platform, we had some crude methods of starting and resuming posts before publishing.

Today, let’s explore a little more into setting up a bloging-friendly environment because we need to either make the experience of blogging easy or we’ll grow tired of the hassle and lose interest.

We can reasonably anticipate that we won’t want to beleaguered with repetitious typing of HTML bits. If we’re going to apply paragraph tags, hyperlinks, codeblocks, etc. with any frequency, that task is best to be simplified. Using Vim as our preferred editor, we will use Tim Pope’s brilliant plug-ins ‘surround’ and ‘repeat’, combined with abbreviations to take away the tedium.

The plug-ins just need dropped into your Vim plugin directory (~/.vim/plugin/). The directory may not exist if you don’t have any plug-ins yet. That’s no problem, though. Let’s grab the plugins:

cd ~/.vim/
wget "http://www.vim.org/scripts/download_script.php?src_id=19287" -O surround.zip
wget "http://www.vim.org/scripts/download_script.php?src_id=19285" -O repeat.zip

Expand the archives into the appropriate directories:

unzip surround.zip
unzip repeat.zip

Ta-da! Your Vim is now configured to quickly wrap (surround) in any variety of markup. When working on a blog, you might use <p> tags a lot by putting your cursor amid the paragraph and typing yss<p>. The plug-in will wrap it with opening and closing paragraph tags. Move to your next paragraph and then press . to repeat.

That out of the way, let’s take advantage of Vim’s abbreviations for some customization. In our .vimrc file, we can define a few characters that Vim will expand according to their definition. For example, you might use:
ab <gclb> <code class="prettyprint lang-bsh linenums:1">
Then, any time you type <gclb> and bress <enter>, you’ll get:
<code class="prettyprint lang-bsh linenums:1">

The next time that we take a look at blogitecture, we will focus on making the posts convenient to manage from our CLI.


Tags: , , , ,
Permalink: 20130613.blogitechture.continued

Thu, 23 May 2013

GNU Screen: Roll your own system monitor

Working on remote servers, some tools are practically ubiquitous — while others are harder to come by. Even if you’ve the authority to install your preferred tools on every server you visit, it’s not always something you want to do. If you’ve hopped on to a friend’s server just to troubleshoot a problem, there is little reason to install tools that your friend is not in the habit of using. Some servers, for security reasons, are very tightly locked down to include only a core set of tools, to complicate the job of any prying intruders. Or perhaps it is a machine that you normally use through a graphical interface but on this occasion you need to work from the CLI.

These are very compelling reasons to get comfortable, at the very least, with tools like Vim, mail, grep and sed. Eventually, you’re likely to encounter a situation where only the classic tools are available. If you aren’t competent with those tools, you’ll end up facing the obstacle of how to get files from the server to your local environment where you can work and, subsequently, how to get the files back when you’re done. In a secured environment, this may not be possible without violating protocols.

Let’s take a look at how we can build a makeshift system monitor using some common tools. This particular configuration is for a server running PHP, MySQL and has the tools Htop and mytop installed. These can easily be replaced with top and a small script to SHOW FULL PROCESSLIST, if needed. The point here is illustrative, to provide a template to be modified according to each specific environment.

(Note: I generally prefer tmux to Gnu Screen but screen is the tool more likely to be already installed, so we’ll use it for this example.)

We’re going to make a set of windows, by a configuration file, to help us keep tabs on what is happening in this system. In so doing, we’ll be using the well-known tools less and watch. More specifically, less +F which tells less to “scroll forward”. Other words, less will continue to read the file making sure any new lines are added to the display. You can exit this mode with CTRL+c, search the file (/), quit(q) or get back into scroll-forward mode with another uppercase F.

Using watch, we’ll include the “-d” flag which tells watch we want to highlight any changes (differences).

We will create a configuration file for screen by typing:

> vim monitor.screenrc

In the file, paste the following:

# Screen setup for system monitoring
# screen -c monitor.screenrc
hardstatus alwayslastline
hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{=kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B}%Y-%m-%d %{W}%c %{g}]'

screen -t htop 0 htop
screen -t mem 1 watch -d "free -t -m"
screen -t mpstat 2 watch -d "mpstat -A"
screen -t iostat 3 watch -d "iostat"
screen -t w 4 watch -d "w"
screen -t messages 5 less +F /var/log/messages
screen -t warn 6 less +F /var/log/warn
screen -t database 7 less +F /srv/www/log/db_error
screen -t mytop 8 mytop
screen -t php 9 less +F /srv/www/log/php_error

(Note: -t sets the title, then the window number, followed by the command running in that window)

Save the file (:wq) or, if you’d prefer, you can grab a copy by right-clicking and saving this file.

Then we will execute screen using this configuration, as noted in the comment:

> screen -c monitor.screenrc

Then you can switch between windows using CTRL+a, n (next) or CTRL+a, p (previous).

I use this technique on my own computers, running in a TTY different from the one used by X. If the graphical interface should get flaky, I can simply switch to that TTY (e.g., CTRL+ALT+F5) to see what things are going on — and take corrective actions, if needed.


Tags: , , , , , , , , , ,
Permalink: 20130523.gnu.screen.system.monitor

Mon, 13 May 2013

Zsh and hash

Documentation for this one seems a bit hard to come by but it is one of the things I love about Zsh.

I’ve seen many .bashrc files that have things like:
alias www='cd /var/www'
alias music='cd /home/j0rg3/music'

And that’s a perfectly sensible way to make life a little easier, especially if the paths are very long.

In Zsh, however, we can use the hash command and the shortcut we get from it works fully as the path. Other words, using the version above, if we want to edit ‘index.html’ in the ‘www’ directory, we would have to issue the shortcut to get there and then edit the file, in two steps:
> www
> vim index.html

The improved version in .zshrc would look like:
hash www=/var/www
hash -d www=/var/www

Then, at any time, you can use tilde (~) and your shortcut in place of path.
> vim ~www/index.html

Even better, it integrates with Zsh’s robust completions so you can, for example, type cd ~www/ and then use the tab key to cycle through subdirectories and files.

On this system, I’m using something like this:
(.zshrc)
hash posts=/home/j0rg3/weblog/posts
hash -d posts=/home/j0rg3/weblog/posts

Then we can make a function to create a new post, to paste into .zshrc. Since we want to be able to edit and save, without partial posts becoming visible, while we are working, we’ll use an extra .tmp extension at the end:
post() { vim ~posts/`date +%Y-%m`/`date +%Y%m%d`.$1.txt.tmp }

[ In-line date command unfamiliar? See earlier explanation ]

But, surely there is going to be a point when we need to save a post and finish it later. For now, let’s assume that only a single post will be in limbo at any time. We definitely don’t want to have to remember the exact name of the post — and we don’t want to have hunt it down every time.

We can make those things easier like this:
alias resume="vim `find ~posts/ -name '*.txt.tmp'`"

Now, we can just enter resume and the system will go find the post we were working on and open it up for us to finish. The file will need the extension renamed from .txt.tmp to only .txt to publish the post but, for the sake of brevity, we’ll think about that (and having multiple posts in editing) on another day.


Tags: , , , ,
Permalink: 20130513.zsh.and.hash

Tue, 07 May 2013

Welcome, traveler.

Thanks for visiting my little spot on the web. This is a Blosxom ‘blog which, for those who don’t know, is a CGI written in Perl using the file-system (rather than a database).

To the CLI-addicted, this is an awesome little product. Accepting, of course, that you’re going to get under the hood if you’re going to make it the product you want. After some modules and hacking, I’m pleased with the result.

My posts are just text files, meaning I start a new one like: vim ~posts/`date +%Y%m%d`.brief.subject.txt

Note: the back-ticks (`) tell the system that you want to execute the command between ticks, and dynamically insert its output into the command. In this case, the command date with these parameters:
  1. (+) we’re going to specify a format
  2. (%Y) four-digit year
  3. (%m) two-digit month
  4. (%d) two-digit day
That means the command above will use Vim to edit a text file named ‘20130507.brief.subject.txt’ in the directory I have assigned to the hash of ‘posts’. (using hash this way is a function of Zsh that I’ll cover in another post)

In my CLI-oriented ‘blog, I can sprinkle in my own HTML or use common notation like wrapping a word in underscores to have it underlined, forward-slashes for italics and asterisks for bold.

Toss in a line that identifies tags and, since Perl is the beast of Regex, we pick up the tags and make them links, meta-tags, etc.

Things here are likely to change a lot at first, while I twiddle with CSS and hack away at making a Blosxom that perfectly fits my tastes — so don’t be too alarmed if you visit and things look a tad wonky. It just means that I’m tinkering.

Once the saw-horses have been tucked away, I’m going to take the various notes I’ve made during my years in IT and write them out, in a very simple breakdown, aimed at sharing these with people who know little about how to negotiate the command line. The assumption here is that you have an interest in *nix/BSD. If you’ve that and the CLI is not a major part of your computing experience, it probably will be at some point. If you’re working on systems remotely, graphical interfaces often just impede you.

Once you’ve started working on remote machines, the rest is inevitable. You can either remember how to do everything two ways, through a graphical interface and CLI — or just start using the CLI for everything.

So let’s take a little journey through the kinds of things that make me love the CLI.


Tags: , , , , , , , , ,
Permalink: 20130507.greetings