Tag Archives: known

Posted on
by

So, I’ve been doing a lot of work with Vagrant recently. Vagrant has been very handy when working in teams in order to have a common point of reference for development, especially when the application we were collaborating on requires helper services (such as Node servers and ElasticSearch) to be started.

Here are a couple of gotchas that caused me a whole bunch of headaches, hopefully this’ll make things easier for you.

Don’t mount to /home/vagrant

In hindsight, this is a stupidly obvious, but at the time I had tunnel vision with a couple of other things didn’t get this until I had an “oh” moment.

The problem was that after provisioning, vagrant ssh would not connect via public key. However, booting the VM by hand using VirtualBox, this would work.

When I finally picked through my VagrantFile, commenting things out until things worked again, I realised my mistake in a facepalming moment. Obvious when you think about it, when you mount your working directory at /home/vagrant you clobber the ~/.ssh/authorized_keys file that had been inserted by vagrant up.

Man, I felt so dumb.

Careful what box you use

If you start getting some weird problems booting your box, you might want to try switching the base box.

I was using the Official Ubuntu 16.04 build as my base, but I was having no end of problems provisioning. More often than not, randomly through the provisioning process, the file system would become read only. I’d have to reboot and restart with the --provision flag, often several times, before I was able to get a box built.

I switched to an unofficial 16.04 box, and these problems went away.

I’m sure there’s a root cause for this issue, I’ll investigate later, but for now, switching VMs resolved it.

Avoid vagrant-vbguest unless you have to

The plugin vagrant-vbguest will update the VirtualBox guest additions on the guest machine, during provisioning, if they are missing or out of date.

This sounds like a great idea, but in my experience, it seems to cause more harm than good. Often, the older guest additions will work just fine, and installing the new additions over them often breaks something.

My view now is very much “if it ain’t broke, don’t fix it!”.

Be careful calling scripts within your startup scripts

If your provisioning or startup script itself calls another shell script, for example to start up custom services, you’re likely going to run into problems on Windows host machines.

Problems I’ve seen:

default: nohup:
default: failed to run command '/path/to/script.sh'

or:

default: -bash: /path/to/script.sh: /bin/bash^M: bad interpreter: No such file or directory

Both of these stem from the same cause, namely your script has been imported from the Windows host and it still has Windows line endings.

There are a number of solutions you could adopt, and the preference would be to avoid using shell scripts within scripts – vagrant should automatically convert line endings in scripts in your Vagrantfile, so try and only call scripts from there. If you must call scripts within scripts, as I had to do on a couple of occasions, you’ll need to convert line endings.

If this is a new project, you could configure git to make sure shell scripts are always binary. Or, convert line endings of your script before execution, e.g:

sed -i -e 's/\r$//' /path/to/script.sh

Hope all this helps!

Posted on
by

In the latest builds of Known, I’ve added support for Gettext translations. This can operate in tandem with the string array mechanism used previously, but it is my hope that using gettext will make translations easier, as there is a more complete tool chain available.

Creating .POT file

The first step, after you’ve used \Idno\Core\Idno::site()->language()->_() to write your strings, is to generate a POT template translation file. To do this, in /languages/ there’s a helpful script, go into this directory and run the script

./makepot.sh /path/to/your/plugin > /path/to/your/plugin/languages/

This will parse all your plugin’s PHP files and extract translatable strings.

Creating your translation

Open up your .POT file with a suitable tool, e.g. poedit, and save your .mo and .po files as /path/to/your/plugin/languages/LOCALE/LC_MESSAGES/DOMAIN.mo|po, where:

  • LOCALE is the locale you’re writing for, e.g. pt_BR
  • DOMAIN is the domain, e.g. your plugin name ‘myplugin’

Registering your translation

In your plugin, register your language by registering a new GetTextTranslation class, passing the path of your languages directory, and the domain you used.

So, for the above example this might look like:

function registerTranslations()
{
    \Idno\Core\Idno::site()->language()->register(
        new \Idno\Core\GetTextTranslation(
            'myplugin',
            dirname(__FILE__) . '/languages/'
        )
    );
}

Posted on
by

I’ve been doing a bit of spring cleaning to the Known repo, removing unnecessary files, tidying up various bits and bobs. One thing I did, because it actually made some client work testing easier, was to move the Known vagrant wrapper into its own repo.

This makes the wrapper much easier to maintain and deploy (for me at least). I also took the liberty of tidying up a number of issues with the ansible configuration which was preventing the provisioning script from working properly.

Usage

You need to download and install a number of tools first, namely: VirtualBox, Vagrant, and Ansible.

Next, you need to check out a copy of the Known repo (or your Known based product environment) into a sub directory called Known. Symlinks should also work.

Run vagrant, and your new Known install will be provisioned as withknown on 192.168.33.33, I recommend modifying your /etc/hosts file to alias this.

Hope you find this useful!

» Visit the project on Github...



Vagrant logo by Fco.plj – Own work, CC BY-SA 3.0, Link