• Home
  • Peru

omega.palle.net

  • SaltStack adventures!

    26 Jun 2015

    I like to dabble in new technology, to try to learn new things, to see what might be useful for me (or companies I work for). Lately operations at my current job (ABC Startsiden in Oslo, Norway) have opted to change to SaltStack for configuration management. I have been meaning to deploy some of my hobby projects on some new servers, so I figured I would try to use SaltStack to manage the configuration of these new servers.

    SaltStack software orchestrates and automates the visualization, build and management of any legacy or modern infrastructure. SaltStack is known as the fastest, most scalable systems and configuration management software for CloudOps, ITOps and DevOps.

    This is from their front page. Sounds very promising, doesn’t it? I have some “CloudPRO” resources at a provider in Canada called cloud at cost. It isn’t a great provider, but they let you buy server resources for a one time fee, which suits me right now :)

    First impression

    I followed the Walk through, and got a salt-master running. I tried to use the gitfs provider, but couldn’t get pygit2 working with my ssh key and github at all. It gave me a “callback failed” error that wasn’t really helpful :( I traced the problem for a while, but I am not a very fluent C/C++ speaker, so I couldn’t figure out where the problem was, beyond that I managed to get libssh to work, but not libgit2. In the end, I just cloned the repo manually, and just pull from it manually for now. I only need to pull on the salt-master, so this isn’t too bad, since I don’t expect to be making too many changes on a day to day basis :)

    Once I got the repo cloned and the salt-master and one minion going, I used it to install some of the basic stuff, like vim, on the minion automatically. Next up was getting my personal account set up, with my public key added automatically. This introduced me to pillars, which was also working great.

    Setting up nginx vhosts with sslmate

    My next attempt was to get nginx running, and to add a vhost with ssl, and keys from sslmate. I once again turned to pillars, to store my sites there, and then just have the nginx states iterate over the pillar data to add sites to nginx.

    sslmate

    I decided to not automate buying keys, and just issue the buy command on my mac, and add the .key file to the salt repo. I added a cronjob via salt though, that would download the certificates for me:

    sslmate-apt-repo:
      pkgrepo.managed:
        - humanname: SSLMate apt repos
        - name: deb http://packages.sslmate.com/debian jessie main
        - dist: jessie
        - file: /etc/apt/sources.list.d/sslmate.list
        - key_url: https://sslmate.com/apt/jessie/sslmate.gpg
        - require_in:
          - sslmate
    
    sslmate:
      pkg.installed:
        - require:
          - pkgrepo: sslmate-apt-repo
    /root/.sslmate:
      file.managed:
        - contents_pillar: sslmate:api_key
        - contents_newline: True
    /etc/sslmate/:
      file.recurse:
        - source: salt://sslmate/keys/
    sslmate download --all --temp:
      cron.present:
        - identifier: sslmate-download-cron
        - minute: random
        - hour: 0
    

    This way I just add all the <domain>.key files to base/sslmate/keys/ in my repo, and then the cronjob will pick it up and download the certificates when they are ready. The --temp ensures that there will be some self-signed certs available immediately, so nginx can be configured and “work” until the proper certificates are in place.

    I did have some struggle with my DNS setup for DNS domain verification, but it worked itself out in the end (my syncing of DNS settings wasn’t working properly to the slaves).

    nginx

    Next up was nginx. I already had it running, so I just needed to add vhosts. I added pillars like these:

    web:
      sites:
        ‘mydomain.com':
          ssl: True
          location: http://localhost:3000 # Should this be specified somewhere else..?
          websockets: True
    

    And then I added a state something like this:

    {% for hostname, data in pillar.get(‘web:sites’, {}).items() %}
    

    This doesn’t work, which surprises me, since salt-call pillar.get web:sites works perfectly fine. Turns out the get in jinja isn’t the same get. Reading the docs explained this, but I didn’t read it carefully enough the first few times :) I ended up with this, which works.

    {% for hostname, data in pillar.get(‘web’).get('sites’, {}).items() %}
    

    With that added, and then some nginx config file templates using jinja, I had a working setup, where it adds the vhost, and restarts nginx, all with ssl enabled automatically. That’s a victory in my book :)

    Next steps

    I also setup mongodb (since my first app uses that, via the meteor framework), and the next step now is to figure out how to deploy the app itself. My first attempt will be dokku, a heroku-on-docker-thing, with the heroku-meteor build pack.

  • Ruter chaos

    13 Mar 2012

    Here in Oslo, all busses, trams etc are operated by # Ruter. They have converted all tickets to something called Flexus. As a part of that, I now have to charge a card with money, instead of buying N tickets. And for some bizarre reason, I cannot simply charge it with 50 tickets, I have to charge it with even sums of money (in 50NOK increments from my experience). Thus I made a small calculator to calculate how much I would have to recharge, given my current balance, to achieve an even number of tickets.

  • JIRA5 and the Github-jira plugin

    13 Mar 2012

    So JIRA5 happened. I still used the old User class, so I had to update the plugin. Since I only touch Java when I have to, I decided to fix up a few things while in there, which resulted in quite a few fixes:

    • Split the list into several Actions.

      First of all this is the correct thing to do. Secondly, it allowed the commits and comments to be included propperly in the All tab of an issue.

    • Adjust the design and markup to be in line with the rest of actions

      JIRA has some weird markup going on there, but at least now our stuff fits with the feel of the All tab.

    Going forward there are a couple of things that I want to fix:

    • Make a connection between github user and jira user.

      Most likely this will be resolved in git-indexer, by having it ask a different service for the correct jira (or in our case, crowd) username.

    • Group commit comments under the commits

      Most of our users (or at least the ones bothering with feedback), want commit comments to show nested beneath the commit it self, not in the timeline like it is now. I get bonus points for making this a front end toggle on the github tab :p

  • css animation experiments

    15 Sep 2011
  • GitHub Jira

    08 Aug 2011

    It didn’t take long for me to notice small stupid things that needed fixing. Now I have deployed 1.4 of the jira plugin and version N of git-indexer to production internally.

    git-indexer changes

    Yesterday I merged the new comment part, which uses the v3 api github provides to fetch comments. For now it is pretty stupid, supports a max of 100 comments pr repo etc, but it is better than the feed, which was bound to miss stuff. This also gave me the propper HTML of the comments, and it gave me the opertunity to format things a bit better on the JIRA-side.

    jira-plugin changes

    I added gravatars, and format changes. Also I finally bothered googeling the jackson error I kept getting whenever I changed the JSON feed, so now it does not die if I decide to add more fields to the JSON. This results in me being able to more easily update the two pieces independently, which is always great. I love decoupling!

Copyright © 2017 Andreas Marienborg, iMac image from wordrom.com