Archive for the 'Software' category

Creating a PostgreSQL user in Vagrant with Ansible

published on June 28, 2016.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

Lately I’ve been playing around with provisioning a PostgreSQL server with Ansible in a local Vagrant machine that runs a Fedora 23 image.

The first task after installing and starting the PostgreSQL server is to create a database user and a database. So far I have found an ugly way, a really ugly way and a nice way to do this.

How it should be done

The proper way to do this would be to use the postgresql_user Ansible module and the become, become_user and become_method directives, like so:

- name: Create a PostgreSQL database user
  postgresql_user: name=project password=project role_attr_flags=CREATEDB state=present
  become: yes
  become_user: postgres
  become_method: sudo

But this fails because sudo expects us to enter the password:

TASK [postgresql : Create user] ************************************************
fatal: [default]: FAILED! => {"changed": false, "failed": true, "module_stderr": "", "module_stdout": "sudo: a password is required\r\n", "msg": "MODULE FAILURE", "parsed": false}

You can read more about privilege escalation in Ansible in their documentation.

The really ugly way

This solution is so bad I’m not even sure I should write it down. It depends on changing the default identification method for local connections from peer to the trust method, so we can use the default vagrant user to create new users without any checks, based only on, well, trust.

- name: Change peer identification to trust
  shell: /bin/sed -i '/^local/s/peer/trust/' /var/lib/pgsql/data/pg_hba.conf
  notify: restart dbserver

- meta: flush_handlers

- name: Create a PostgreSQL database user
  postgresql_user: name=project password=project role_attr_flags=CREATEDB state=present

- name: Change trust identification back to peer
  shell: /bin/sed -i '/^local/s/trust/peer/' /var/lib/pgsql/data/pg_hba.conf
  notify: restart dbserver

- meta: flush_handlers

This is just bad, there must be a better way.

The less ugly way

But still ugly. This is based on running a psql command using the shell Ansible module.

- name: Create a PostgreSQL database user
  shell: sudo -u postgres bash -c "psql -c \"CREATE USER project WITH CREATEDB PASSWORD 'project';\""

This one has an additional problem of that it only works when we run it for the first time, because we can’t create the same user twice. A possible solution would be to wrap the CREATE USER ... in an additional IF NOT EXISTS (SELECT * FROM pg_catalog.pg_user ... query, but that’s just… Ugh. No.

Back to square one

Let’s go back to the way how it should be done, by using the become and become_user directives. But how do we handle the sudo password? We tell sudo to not ask for a password by editing the /etc/sudoers files. The line to add is:

vagrant ALL=(postgres) NOPASSWD:/bin/sh

This tells sudo that the user vagrant on ALL hosts can run the /bin/sh program with NOPASSWD as the user postgres. I’m explicitly limiting the possible commands to /bin/sh as that is the only command we need to be able to run to make things work. I don’t want to add more if I don’t need to.

The Ansible tasks are now:

- name: Enable passwordless sudo
  lineinfile: dest=/etc/sudoers regexp=^vagrant line="vagrant ALL=(postgres) NOPASSWD:/bin/sh"

- name: Create a PostgreSQL database user
  postgresql_user: name=project password=project role_attr_flags=CREATEDB state=present
  become: yes
  become_user: postgres
  become_method: sudo

For added bonus we can cleanup the sudoers file after we are done by removing the line we added.

Happy hackin’!

P.S.: If you want to use a good quality Ansible role for PostgreSQL take a look at this one. Thanks to Gilles Cornu for pointing it out!

GitHub flavoured code fences in Hugo

published on March 28, 2016.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

This was an undocumented feature until today, so I missed it when I was converting my site to Hugo last week. It is also possible to highlight code examples with GitHub flavoured code fences, or, in other words, with triple backticks ```.

I like this a lot because it makes highlighting code in posts easier. Typing the {{< highlight >}} shortcode is just awkward and I always end up forgetting either the angle brackets or add too much or too little currly brackets. Backticks are much nicer.

The code fences are not enabled by default, though. We need to set PygmentsCodeFences to true in Hugo’s configuration file and that’s about it. Everything else about syntax highlighting stays the same.

Change to backticks in old posts

I used these two simple sed one-liners to change all the highlighting shortcodes to the code fences:

find -name "*.md" -print0 | xargs -0 sed -i 's/&#123;&#123;< highlight \([a-z]*\) >&#125;&#125;/``` \1/g'
find -name "*.md" -print0 | xargs -0 sed -i 's/&#123;&#123;< \/highlight >&#125;&#125;/```/g'

Now I don’t even need a custom Vim function to insert the highlighting shortcode. Sweet.

Tags for PHP in Vim

published on March 09, 2016.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

One thing I was missing for a long time in Vim is to be able to “jump to definition” in an easy and painless way.

The other thing I wanted to improve is to be able to tell easily where am I actually in the code base; to see the current class and method name of wherever the cursor was.

With a bit of googling and poking around, I finally came up with a perfect combo of 5 plugins (yep, five!) that enables me to do both, and a little bit of extra.

Tags made easy

Gutentags  is a brilliant Vim plugin that makes it so easy to have tags. Just install the plugin and boom! Tags! It will figure out things on it’s own and just generate the tags in the background. I use it daily for a fairly large code base and I never had any problems with the tags, or with Vim being unresponsive while the tags are being generated.

The only two settings I have set for it is what to exclude and where to store the tag files to not pollute the current project with them.

let g:gutentags_exclude = ['*.css', '*.html', '*.js']
let g:gutentags_cache_dir = '~/.vim/gutentags'

That’s it.

Jump to definition

Pair gutentags with CtrlP and it’s CtrlPTag method and we get jump to definition.

map <silent> <leader>jd :CtrlPTag<cr><c-\>w

Move to the method name we’re interested in, hit <leader>jd and it will jump to it’s definition. Tip: <C->w means “insert word under cursor”.

Where the hell am I?

My second requirement for displaying the current class and method name was a bit more difficult to fulfill. It takes the tagbar, tagbar-phpctags and lightline plugins as well as the phpctags tag generator to accomplish that.

Let the tagbar plugin know where the phpctags bin is:

let g:tagbar_phpctags_bin='~/.vim/phpctags'

This will make the tagbar plugin use phpctags to generate tags for the current file. To finally display the current tag in lightline, I wrote a simple tagbar component for it:

'tagbar': '%{tagbar#currenttag("[%s]", "", "f")}'

My complete lightline settings at the time of writing this can be found here.

pugdebug 1.0.0.

published on July 01, 2015.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

After 3 months since announcing that I’m working on pugdebug, and some 5 months since I actually started working on it, it is finally time to let version 1.0.0 out in the wild.

It’s been a busy 3 months: 82 pull requests got merged, 67 issues resolved, more than 350 commits pushed. A lot of changes, fixes and improvements found their way into this first version.

First of all, a big thanks goes out to Ivan Habunek and Srdjan Vranac for helping. They asked for and added new features, tested on Windows and OSX systems, helped fleshing out ideas.

One of the biggest news is that there are binaries built for Linux and Windows operating systems, using pyinstaller. These binaries include everything pugdebug needs to work so there is no need to install anything. Just download the binary for your system and run it. That’s it. It makes me incredibly happy that it’s possible to have it this simple to run and use pugdebug.

pugdebug

The user interface has improved a great deal. It is using dockable widgets for different pieces of the UI, making the layout of the application configurable by just dragging the widgets around. It’s not all great though, there’s still room for improvement, but it will be better over time.

pugdebug allows to debug multiple requests one after the other which helps debugging in a more “complicated” scenario where there are, for example, multiple AJAX calls triggered in succession. By starting to listen to incomming connections, pugdebug will listen to all incoming connections and, based on the IDE key setting, decide should the connection be queued for debugging, or ignored.

It is also now possible to create projects inside pugdebug, as a way to help switching between different PHP projects where debugging is needed. Simply name the project, set it’s settings and that’s it. pugdebug stores all the configuration files in it’s own directory, so nothing will be added to your PHP projects.

I’m especially happy and proud that pugdebug got included on Xdebug’s website on the list of remote debugging clients. Thanks to Derick Rethans!

For more information on how to use pugdebug, take a look at the read me file or the wiki and let me know if you have any issues with it!

Introducing pugdebug

published on April 01, 2015.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

In my spare time in the past few months I was working on a tool that would help me in my every day job as a PHP programmer. As you may, or may not, know, I’m using vim as my editor/almost IDE, but one thing that is missing from it is the ability to debug PHP files remotely. Yes, there are a bunch of plugins out there that add debugging to vim, but none of them felt usable for me.

And based on my google searches, there are no standalone remote debuggers for PHP, that work on Linux.

In February this year I started to work on a desktop application that would help me address this issue.

pugdebug

pugdebug  is a PyQt desktop application meant to be used as a remote debugger for PHP, that communicates with xdebug.

It is meant to be a debugger and only a debugger. There are a plenty of (good) IDEs that include remote debugging and I’m not going to start writing another one (although I did start one, once).

The application is still pretty simple, ugly as hell, but it works. Sort of. There are still a few kinks left to sort out and I’m doing my best to write them all down.

It’s dependencies are Python 3.4, Qt 5.4, SIP 4.6 and PyQt 5.4. The read me file should have a bit more details on how to start using it. I know it’s a bit messy to set everything up, but I am working on building executables for different Linux distros. That stuff is hard!

It is lincesed under the GNU GPL v3 license, because PyQt.

Using pugdebug

Start the application, click the start button and then it waits for incomming connections. Load a PHP page to start a HTTP debug session, and pugdebug should break on the first line of your code.

Stepping around the code is possible with the step into, step out and step over commands. At each step, pugdebug will get the current variables state from xdebug and display them.

Double clicking on lines in the code viewer will set breakpoints on those lines. Do note though that there needs to be a debugging session active to be able to set a breakpoint. This will change in the (near) future.

And that’s about it. While I know it doesn’t look like much, this was, and still is, a nice learning experience for me and the best part of it is that I was using pugdebug earlier this week to debug a PHP application I’m working on.

Robert Basic

Robert Basic

Software engineer, consultant, open source contributor.

Let's work together!

If you require outsourcing or consulting help on your projects, I'm available!

Robert Basic © 2008 — 2019
Get the feed