24 Apr 2014

feedPlanet Plone

JC Brand: Converse.js: XMPP instant messaging with Javascript

It is now possible to use converse.js, the Javascript from collective.xmpp.chat, in a standalone way, to communicate with any public Jabber account.

Lately I've been spending time refactoring converse.js the Javascript library used by collective.xmpp.chat the instant messaging add-on for the Plone CMS. My goal is to make it usable on it's own, requiring nothing else except an XMPP server to communicate with.

This would enable any website owner to add instant messaging functionality to their website, and due to the federated nature of XMPP, users could chat to any other public XMPP account (once they have been accepted as a contact).

One thing that previously prevented you from using converse.js on its own, was the fact that it made XHR calls to the Plone backend to fetch user data. To fix this, I added vCard support, to converse.js but also to Plone by adding it to collective.xmpp.core.

Last week I reached a significant milestone on the path to this goal, and I'd like to take a moment and share with you.

It is now possible to use converse.js (in a static HTML page) to communicate with Jabber accounts on any public server.

In the demo below, I illustrate this by chatting to a Google user and to a Jabber.org user. In the converse.js page, I'm authenticated with a Jappix.com account and I also use their connection manager to connect to their XMPP server. If you're doing XMPP via HTTP (i.e in the browser), you'll need a connection manager as a bridge to your intended XMPP server. Thanks a lot to the Jappix guys for making their connection manager public!

Note: For detailed fullscreen, make sure that video quality is set to HD, by clicking the gear icon on the video player.

Note

UPDATE: Since this blog post, a production ready version of converse.js has been released. So the following is no longer applicable.

I'm sorry to say that converse.js is not yet 100% ready for primetime as a standalone JS app. There are a few more hurdles (and nice-to-haves) to overcome before we'll achieve this goal:

  • Searching and adding new users still does XHR calls to Plone and should instead query the XMPP server.
  • Service discovery support (e.g so that multi-user chat is only available for servers that support it).
  • Some kind of "Keep me logged in" support when users log in manually.
  • I'm not proud of the CSS and it could probably be improved upon quite a bit.
  • The Jasmine tests are out of date and not passing, also more tests are required.

If you are interested in the project, please contribute by forking the code on github.

Thanks a lot to Alec Ghica and David Ichim from Eau de Web who've made various improvements to both collective.xmpp.chat and converse.js over the past months.

24 Apr 2014 10:11pm GMT

Reinout van Rees: Python/django programmeren in hartje Utrecht (NL)

English note: I'm writing this in Dutch as it is for a job opening at our company. Call us old-fashioned, but we're all talking Dutch at the office :-)

We (= Nelen & Schuurmans) hebben weer versterking nodig van ons team Python programmeurs. Je kans om met Reinout te werken want de zaken gaan goed en er is veel werk te verstouwen :-) Laatst is een van onze ervaren programmeurs voor zichzelf begonnen en daarom gooi ik hier op mijn blog weer een hengeltje uit: we zijn specifiek ook op zoek naar een ervaren Python programmeur.

Ervaren? Nou, gewoon, een stukje kwaliteit en kunde en kennis inbrengen. Het mooiste compliment dat ik ooit van een collega (hoi Roland!) kreeg was dat 'ie mijn code altijd zo lekker leesbaar vond. Duidelijke variabelenamen, netjes gestructureerd, netjes pep8. Zoiets. Gewoon dat als je code schrijft dat het dan z'n werk goed doet en dat het niet afgeraffeld is. Dat je geheel vrijwillig de README.rst en de CHANGES.rst up to date houdt. En dat je na een maandje de eerste collega's aan je bureau krijgt met "kun je me even helpen met...". En dat je op een gegeven moment met ik-weet-niet-wat iets heel handigs hebt geautomatiseerd ofzo. Vanuit jezelf.

Grote bonuspunten als je veel met open source bezig bent geweest. Github, mailinglijsten, stackoverflow, enz. Veel van wat we als bedrijf doen is open source (vaak GPL, dan is het wel lekker open source maar kan tegelijkertijd de eventuele concurrent er niet zonder licentieproblemen een closed source slaatje uit slaan).

Het karakter van het bedrijf? We zijn geen puur IT bedrijf, het is echt een mix van IT en vakinhoud. Qua personele verhouding 1:2. Vakinhoudelijk is het waterveiligheid, waterkwaliteit, waterbeheer en vooral dus water. IT is een echte force multiplier voor ons. Wat we qua IT doen en kunnen versterkt de vakinhoudelijke kant enorm.

En we doen inmiddels best veel gave dingen. 3di is een compleet overstromingssimulatiepakket. Inclusief webinterface om het live aan te sturen. (Iemand heeft ook een video van het ontwikkelteam gemaakt). En kijk bijvoorbeeld naar http://regenradar.lizard.net/ (moet het wel net geregend hebben, zie anders deze video), da's op zich geen concurrent voor buienradar.nl maar geeft wel aan dat we neerslagdata hebben. En ook historische neerslagdata. En we integreren het met de rest van de data. Bij twee waterschappen berekenen we bijvoorbeeld aan de hand van neerslagvoorspellingen, meetgegevens, windrichting en getijde-voorspellingen hoe hard gemalen aangezet moeten worden. En dat gedetailleerde hoogtebestand dat laatst in het nieuws was (AHN2)? https://raster.lizard.net/wms/demo is een demo, we integreren het inmiddels in veel sites en we gebruiken het ook als achtergronddata voor dat 3Di dat ik eerder noemde.

Essentieel voor het karakter van het bedrijf is dat we allemaal hoog opgeleid zijn. Bijna iedereen universitair. En ik ben niet de enige dr. die er rondloopt: 8 van de 50 ofzo. Dat is eigenlijk de kern van het bedrijf: zet allemaal slimme, ijverige lui bij elkaar met een focus op waterveiligheid en er komen mooie (en winstgevende) dingen uit. Je hebt veel vrijheid (vertaald: het is soms een zooitje). Ruimte voor eigen initiatief.

Qua werkomgeving? Hartje Utrecht. Regelmatig halen we een ijsje bij dat ijskraampje op de Oude Gracht: dat is 1 minuut lopen. Goed bereikbaar: 10 minuten lopen vanaf het centraal station. Lunch enzo? Gezamenlijk in de kelder aan tafel. Vers brood van de bakker. Goed geregeld, wat dat betreft. Verder zijn veel dingen relatief goedkoop geregeld. Geen apple beeldschermen op het bureau zullen we maar zeggen. Voordeel: elk jaar hebben we tot nu toe winst gedraaid. Da's in deze tijd ook een geruststellende gedachte.

Werkinhoudelijk? Veel Python. Veel ook aan de web kant: Django. Er moet ook geautomatiseerd worden, dus Fabric, Ansible, buildout, enz. Her en der zit nog een snufje Java of Fortran. Natuurlijk ook veel javascript (recent ook steeds meer angularjs). Nette Python packages, changelog, readme, buildout, grunt/bower enz. Onze code staat op github. Branches, pull requests, code review. Tests kunnen we meer van gebruiken, maar we hebben ook al een aardige stapel. Zelfs javascript wordt deels getest. (Dus... qua tests kunnen we nog een extra opvoeder gebruiken). We hebben in twee datacenters een rack volgepropt, dus we hebben en vette VMWare omgeving met veel virtual machines. Best gaaf geregeld.

Het leukste: we hebben een groot IT team. Ongeveer 10 Python programmeurs (met bakken css/javascript/whatever kennis erbij). Da's binnen Nederland best een grote club. Volgens mij horen we gewoon bij de grootste Python bedrijven binnen Nederland. Je kan bij ons veel leren en sparren en experimenteren en helpen en samenwerken. Gaaf.

Interesse? Meer info nodig? Je kan kijken naar alles wat ik met "nelenschuurmans" getagt heb op dit weblog. Je kan mij mailen op reinout@vanrees.org.

  • De officiele vacature staat hier: http://www.nelen-schuurmans.nl/NL/bedrijfsprofiel/carriere . Het emailadres voor de sollicitatie staat daar ook bij. Doe me een plezier en zet mij even in de cc als je het opstuurt.
  • Lees je dit artikel over 3 jaar als de vacature verlopen is? Maakt vast niet uit, mail me maar.
  • Oh help, ik ben een beginner? Oh help, ben ik wel ervaren genoeg? Gewoon mailen danwel solliciteren. Ervaren met java/ruby/perl/APL in plaats van Python? Dan lukt Python vast ook wel. Mailen.
  • Niet geheel relevante vooropleiding? Ha ha ha. Onze systeembeheerder is afgestudeerd theoloog, de beste vormgever die we hebben is verpleger en we hebben ook een cardioloog als (goede!) programmeur. En ik heb bijvoorbeeld civiele techniek gestudeerd en niet technische informatica ofzo.
  • Utrecht is mooi maar je blijft liever dichter bij jouw huidige woonplaats in buurt? Ik vind het prima als je me mailt of ik nog ideeen heb, want ik krijg nogal eens de vraag van iemand "of ik nog iemand weet die...". Wil je bijvoorbeeld liever in de buurt van Rotterdam werken, kijk dan eens bij Zest software. Leuk bedrijf om bij te werken, ik heb er zelf 4 jaar gewerkt. En mijn broer Maurits werkt er nog steeds.
  • Heb ik al gezegd dat het leuk werken bij ons is? Kom eens langs of mail me :-)

24 Apr 2014 9:18pm GMT

Reinout van Rees: Python/django programmeren in hartje Utrecht (NL)

English note: I'm writing this in Dutch as it is for a job opening at our company. Call us old-fashioned, but we're all talking Dutch at the office :-)

We (= Nelen & Schuurmans) hebben weer versterking nodig van ons team Python programmeurs. Je kans om met Reinout te werken want de zaken gaan goed en er is veel werk te verstouwen. Laatst is een van onze ervaren programmeurs voor zichzelf begonnen en daarom gooi ik hier op mijn blog weer een hengeltje uit: we zijn specifiek ook op zoek naar een ervaren Python programmeur.

Ervaren? Nou, gewoon, een stukje kwaliteit en kunde en kennis inbrengen. Het mooiste compliment dat ik ooit van een collega (hoi Roland!) kreeg was dat 'ie mijn code altijd zo lekker leesbaar vond. Duidelijke variabelenamen, netjes gestructureerd, netjes pep8. Zoiets. Gewoon dat als je code schrijft dat het dan z'n werk goed doet en dat het niet afgeraffeld is. Dat je geheel vrijwillig de README.rst en de CHANGES.rst up to date houdt. En dat je na een maandje de eerste collega's aan je bureau krijgt met "kun je me even helpen met...". En dat je op een gegeven moment met ik-weet-niet-wat iets heel handigs hebt geautomatiseerd ofzo. Vanuit jezelf.

Grote bonuspunten als je veel met open source bezig bent geweest. Github, mailinglijsten, stackoverflow, enz. Veel van wat we als bedrijf doen is ook open source (vaak GPL, dan is het wel lekker open source maar kan tegelijkertijd de eventuele concurrent er niet zonder licentieproblemen een closed source slaatje uit slaan).

Het karakter van het bedrijf? We zijn geen puur IT bedrijf, het is echt een mix van IT en vakinhoud. Qua personele verhouding 1:2. Vakinhoudelijk is het waterveiligheid, waterkwaliteit, waterbeheer en vooral dus water. IT is een echte force multiplier voor ons. Wat we qua IT doen en kunnen versterkt de vakinhoudelijke kant enorm.

En we doen inmiddels best veel gave dingen. 3di is een compleet overstromingssimulatiepakket. Inclusief webinterface om het live aan te sturen. (Iemand heeft ook een video van het ontwikkelteam gemaakt) En kijk bijvoorbeeld naar http://regenradar.lizard.net/ (moet het wel net geregend hebben, zie anders deze video), da's op zich geen concurrent voor buienradar.nl maar geeft wel aan dat we neerslagdata hebben. En ook historische neerslagdata. En we integreren het met de rest van de data. Bij twee waterschappen berekenen we bijvoorbeeld aan de hand van neerslagvoorspellingen, meetgegevens, windrichting en getijde-voorspellingen hoe hard gemalen aangezet moeten worden. En dat gedetailleerde hoogtebestand dat laatst in het nieuws was (AHN2)? https://raster.lizard.net/wms/demo is een demo, we integreren het inmiddels in veel sites en we gebruiken het ook als achtergronddata voo dat 3Di dat ik eerder noemde.

Essentieel voor het karakter van het bedrijf is dat we allemaal hoog opgeleid zijn. Bijna iedereen universitair. En ik ben niet de enige dr.ir. die er rondloopt: 8 van de 50 ofzo. Dat is eigenlijk de kern van het bedrijf: zet allemaal slimme, ijverige lui bij elkaar met een focus op waterveiligheid en er komen mooie (en winstgevende) dingen uit. Je hebt veel vrijheid (vertaald: het is soms een zooitje). Ruimte voor eigen initiatief.

Qua werkomgeving? Hartje Utrecht. Regelmatig halen we een ijsje bij dat ijskraampje op de Oude Gracht: dat is 1 minuut lopen. Goed bereikbaar: 10 minuten lopen vanaf het centraal station. Lunch enzo? Gezamenlijk in de kelder aan tafels. Vers brood van de bakker. Goed geregeld, wat dat betreft. Verder zijn veel dingen relatief goedkoop geregeld. Geen apple beeldschermen op het bureau zullen we maar zeggen. Voordeel: elk jaar hebben we tot nu toe winst gedraaid. Da's in deze tijd ook een geruststellende gedachte.

Werkinhoudelijk? Veel Python. Veel ook aan de web kant: Django. Er moet ook geautomatiseerd worden, dus Fabric, Ansible, buildout, enz. Her en der zit nog een snufje Java of Fortran. Natuurlijk ook vrij veel javascript; we gebruiken ook aardig wat angularjs. Nette Python packages, changelog, readme, buildout, grunt/bower enz. Onze code staat op github. Branches, pull requests, code review. Tests kunnen we meer van gebruiken, maar we hebben ook al een aardige stapel. Zelfs javascript wordt deels getest. (Dus... qua tests kunnen we nog een extra opvoeder gebruiken).

Het leukste: we hebben een groot IT team. Ongeveer 10 Python programmeurs (met bakken css/javascript/whatever kennis erbij). Da's binnen Nederland best een grote club. Volgens mij horen we gewoon bij de grootste Python bedrijven binnen Nederland. Je kan bij ons veel leren en sparren en experimenteren en helpen en samenwerken. Gaaf.

Interesse? Meer info nodig? Je kan kijken naar alles wat ik met nelenschuurmans getagt heb op dit weblog. Je kan mij ook mailen op reinout@vanrees.org.

  • De officiele vacature staat hier: http://www.nelen-schuurmans.nl/NL/bedrijfsprofiel/carriere . Het emailadres voor de sollicitatie staat daar ook bij. Doe me een plezier en zet mij even in de CC :-)
  • Lees je dit artikel over 3 jaar als de vacature verlopen is? Maakt vast niet uit, mail me maar.
  • Oh help, ik ben een beginner? Oh help, ben ik wel ervaren genoeg? Gewoon mailen danwel solliciteren. Ervaren met java/ruby/perl/APL? Dan lukt Python vast ook wel. Mailen.
  • Utrecht is mooi maar je blijft liever dichter in jouw buurt? Ik vind het prima als je me mailt of ik nog ideeen heb, want ik krijg nogal eens de vraag van iemand "of ik nog iemand weet die...". Wil je bijvoorbeeld liever in de buurt van Rotterdam werken, kijk dan eens bij Zest software bijvoorbeeld. Leuk bedrijf om bij te werken, ik heb er zelf 4 jaar gewerkt.
  • Heb ik al gezegd dat het leuk werken bij ons is? Kom eens langs of mail me :-)

24 Apr 2014 8:54pm GMT

Martijn Faassen: Morepath 0.2

I've just released Morepath 0.2! Morepath is your friendly neighborhood Python web microframework with super powers.

Major changes include:

And various smaller tweaks. You can also read the changelog.

What makes Morepath special? You can read about its superpowers and read how it compares to other web frameworks, but here are some highlights:

It's lots of power contained in a small codebase.

(If you followed the Morepath link above, ignore the 0.1 in the title bar there: those are the 0.2 docs, not 0.1. I've now fixed the doc building configuration to include the version number from the package itself.)

24 Apr 2014 1:22pm GMT

eGenix: Python Meeting Düsseldorf - 2014-04-29

The following text is in German, since we're announcing a regional user group meeting in Düsseldorf, Germany.

Ankündigung

Das nächste Python Meeting Düsseldorf findet an folgendem Termin statt:

Dienstag, 24.09.2014, 19:00 Uhr
Raum 1, 2.OG im Bürgerhaus Stadtteilzentrum Bilk
Düsseldorfer Arcaden, Bachstr. 145, 40217 Düsseldorf


Neuigkeiten

Bereits angemeldete Vorträge

Charlie Clark
"Status openpyxl, bzw. Lösung neuer Probleme"
"IndexedList - eine Liste optimiert für "in" Abfragen"
"Bericht von der PyCon 2014 in Montreal"


Marc-Andre Lemburg
"Python Code mit lib2to3 modernisieren"
"DDOS Attacken mit Python bekämpfen"
"Bericht von der FOSDEM 2014"

Wir suchen noch weitere Vorträge. Bei Interesse, bitte unter info@pyddf.de melden.

Geänderte Startzeit

Dieses Mal treffen wir uns erst um 19:00 Uhr im Bürgerhaus in den Düsseldorfer Arcaden, da wir keinen Termin für 18 Uhr bekommen haben. Hier eine kurze Beschreibung:

Das Bürgerhaus teilt sich den Eingang mit dem Schwimmbad und befindet sich an der Seite der Tiefgarageneinfahrt der Düsseldorfer Arcaden.

Über dem Eingang steht ein großes "Schwimm'in Bilk" Logo. Hinter der Tür direkt links zu den zwei Aufzügen, dann in den 2. Stock hochfahren. Der Eingang zum Raum 1 liegt direkt links, wenn man aus dem Aufzug kommt.

>>> Eingang in Google Street View

Einleitung

Das Python Meeting Düsseldorf ist eine regelmäßige Veranstaltung in Düsseldorf, die sich an Python Begeisterte aus der Region wendet.

Einen guten Überblick über die Vorträge bietet unser PyDDF YouTube-Kanal, auf dem wir Videos der Vorträge nach den Meetings veröffentlichen.

Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld, in Zusammenarbeit mit Clark Consulting & Research, Düsseldorf:

Programm

Das Python Meeting Düsseldorf nutzt eine Mischung aus Open Space und Lightning Talks, wobei die Gewitter bei uns auch schon mal 20 Minuten dauern können :-)

Lightning Talks können vorher angemeldet werden, oder auch spontan während des Treffens eingebracht werden. Ein Beamer mit XGA Auflösung steht zur Verfügung. Folien bitte als PDF auf USB Stick mitbringen.

Lightning Talk Anmeldung bitte formlos per EMail an info@pyddf.de

Kostenbeteiligung

Das Python Meeting Düsseldorf wird von Python Nutzern für Python Nutzer veranstaltet.

Da Tagungsraum, Beamer, Internet und Getränke Kosten produzieren, bitten wir die Teilnehmer um einen Beitrag in Höhe von EUR 10,00 inkl. 19% Mwst. Schüler und Studenten zahlen EUR 5,00 inkl. 19% Mwst.

Wir möchten alle Teilnehmer bitten, den Betrag in bar mitzubringen.

Anmeldung

Da wir nur für ca. 20 Personen Sitzplätze haben, möchten wir bitten, sich per EMail anzumelden. Damit wird keine Verpflichtung eingegangen. Es erleichtert uns allerdings die Planung.

Meeting Anmeldung bitte formlos per EMail an info@pyddf.de

Weitere Informationen

Weitere Informationen finden Sie auf der Webseite des Meetings:

http://pyddf.de/

Viel Spaß !

Marc-Andre Lemburg, eGenix.com

Published: 2013-03-20
<noscript> <div style="border-top: 1px solid; text-align: center;">Please enable JavaScript to make full use of our web-site. Thank you.</div> </noscript>
Contact : Impressum : Terms & Conditions : Privacy Policy : Trademarks 2013-03-20
(c) Copyright 2000-2013 eGenix.com Software, Skills and Services GmbH, Langenfeld, Germany. All Rights Reserved.

24 Apr 2014 9:00am GMT

23 Apr 2014

feedPlanet Plone

Connexions Developers Blog: OpenStax CNX Featured On Floss Weekly Podcast


Two OpenStax team members were featured guests on the Floss Weekly podcast this morning. Floss Weekly covers open source software for the TWIT podcast network. Kathi Fletcher and Ross Reedstrom told the history of the project along with a discussion of the work we are currently doing on OpenStax CNX. The podcast is available to view or download from TWIT.

23 Apr 2014 9:10pm GMT

Quintagroup: Collective.easyform

Collective.easyform-logo.pngPlone developers constantly search for more efficient ways of Plone performance. Dexterity is a new platform for content types in Plone and will be used instead of Archetypes in Plone 5. As a result there is necessity to create custom forms using Dexterity.
Quintagroup offers new Plone product - collective.easyform that generates web forms that save or mail form input. Easyform provides a Plone form builder through-the-web using fields, widgets, actions and validators.

How to use:

Created-Easyform-Fields.png

Check out our video tutorial on collective.easyform

Try it yourself!

Collective.easyform is compatible with Plone 4.3.2. It is distributed as a Python egg and can easily be installed into your buildout similarly to other Plone packages. Visit the following pages to find more information about collective.easyform:

23 Apr 2014 2:51pm GMT

Josh Johnson: Centralized Ansible Management With Knocd + Auto-provisioning with AWS

Ansible is a great tool. We've been using it at my job with a fair amount of success. When it was chosen, we didn't have a requirement for supporting Auto scaling groups in AWS. This offers a unique problem - we need machines to be able to essentially provision themselves when AWS brings them up. This has interesting implications outside of AWS as well. This article covers using the Ansible API to build just enough of a custom playbook runner to target a single machine at a time, and discusses how to wire it up to knockd, a "port knocking" server and client, and finally how to use user data in AWS to execute this at boot - or any reboot.

Ansible - A "Push" Model

Ansible is a configuration management tool used in orchestration of large pieces of infrastructure. It's structured as a simple layer above SSH - but it's a very sophisticated piece of software. Bottom line, it uses SSH to "push" configuration out to remote servers - this differs from some other popular approaches (like Chef, Puppet and CFEngine) where an agent is run on each machine, and a centralized server manages communication with the agents. Check out How Ansible Works for a bit more detail.

Every approach has it's advantages and disadvantages - discussing the nuances is beyond the scope of this article, but the primary disadvantage that Ansible has is one of it's strongest advantages: it's decentralized and doesn't require agent installation. The problem arises when you don't know your inventory (Ansible-speak for "list of all your machines") beforehand. This can be mitigated with inventory plugins. However, when you have to configure machines that are being spun up dynamically, that need to be configured quickly, the push model starts to break down.

Luckily, Ansible is highly compatible with automation, and provides a very useful python API for specialized cases.

Port Knocking For Fun And Profit

Port knocking is a novel way of invoking code. It involves listening to the network at a very low level, and listening for attempted connections to a specific sequence of ports. No ports are opened. It has its roots in network security, where it's used to temporarily open up firewalls. You knock, then you connect, then you knock again to close the door behind you. It's very cool tech.

The standard implementation of port knocking is knockd, included with most major linux distributions. It's extremely light weight, and uses a simple configuration file. It supports some interesting features, such as limiting the number of times a client can invoke the knock sequence, by commenting out lines in a flat file.

User Data In EC2

EC2 has a really cool feature called user data, that allows you to add some information to an instance upon boot. It works with cloud-init (installed on most AMIs) to perform tasks and run scripts when the machine is first booted, or rebooted.

Auto Scalling

EC2 provides a mechanism for spinning up instances based on need (or really any arbitrary event). The AWS documentation gives a detailed overview of how it works. It's useful for responding to sudden spikes in demand, or contracting your running instances during low-demand periods.

Ansilbe + Knockd = Centralized, On-Demand Configuration

As mentioned earlier, Ansible provides a fairly robust API for use in your own scripts. Knockd can be used to invoke any shell command. Here's how I tied the two together.

Prerequisites

All of my experimentation was done in EC2, using the Ubuntu 12.04 LTS AMI.

To get the machine running ansible configured, I ran the following commands:

$ sudo apt-get update
$ sudo apt-get install python-dev python-pip knockd
$ sudo pip install ansible

Note: its important that you install the python-dev package before you install ansible. This will provide the proper headers so that the c-based SSH library will be compiled, which is faster than the pure-python version installed when the headers are not available.

You'll notice some information from the knockd package regarding how to enable it. Take note of this for final deployment, but we'll be running knockd manually during this proof-of-concept exercise.

On the "client" machine, the one who is asking to be configured, you need only install knockd. Again, the service isn't enabled by default, but the package provides the knock command.

EC2 Setup

We require a few things to be done in the EC2 console for this all to work.

First, I created a keypair for use by the tool. I called "bootstrap". I downloaded it onto a freshly set up instance I designated for this purpose.

NOTE: It's important to set the permissions of the private key correctly. They must be set to 0600.

I then needed to create a special security group. The point of the group is to allow all ports from within the current subnet. This gives us maximum flexibility when assigning port knock sequences.

Here's what it looks like:

Depending on our circumstances, we would need to also open up UDP traffic as well (port knocks can be TCP or UDP based, or a combination within a sequence).

For the sake of security, a limited range of a specific type of connection is advised, but since we're only communicating over our internal subnet, the risk here is minimal.

Note that I've also opened SSH traffic to the world. This is not advisable as standard practice, but it's necessary for me since I do not have a fixed IP address on my connection.

Making It Work

I wrote a simple python script that runs a given playbook against a given IP address:

"""
Script to run a given playbook against a specific host
"""

import ansible.playbook
from ansible import callbacks
from ansible import utils

import argparse
import os, sys

parser = argparse.ArgumentParser(
    description="Run an ansible playbook against a specific host."
)

parser.add_argument(
    'host',
    help="The IP address or hostname of the machine to run the playbook against."
)

parser.add_argument(
    "-p",
    "--playbook",
    default="default.yml",
    metavar="PLAY_BOOK",
    help="Specify path to a specific playbook to run."
)

parser.add_argument(
    "-c",
    "--config_file",
    metavar="CONFIG_FILE",
    default="./config.ini",
    help="Specify path to a config file. Defaults to %(default)s."
)

def run_playbook(host, playbook, user, key_file):
    """
    Run a given playbook against a specific host, with the given username
    and private key file.
    """
    stats = callbacks.AggregateStats()
    playbook_cb = callbacks.PlaybookCallbacks(verbose=utils.VERBOSITY)
    runner_cb = callbacks.PlaybookRunnerCallbacks(stats, verbose=utils.VERBOSITY)

    pb = ansible.playbook.PlayBook(
        host_list=[host,],
        playbook=playbook,
        forks=1,
        remote_user=user,
        private_key_file=key_file,
        runner_callbacks=runner_cb,
        callbacks=playbook_cb,
        stats=stats
    )

    pb.run()

options = parser.parse_args()

playbook = os.path.abspath("./playbooks/%s" % options.playbook)

run_playbook(options.host, playbook, 'ubuntu', "./bootstrap.pem")

Most of the script is user-interface code, using argparse to bring in configuration options. One unimplemented feature is using an INI file to specify things like the default playbook, pem key, user, etc. These things are just hard coded in the call to run_playbook for this proof-of-concept implementation.

The real heart of the script is the run_playbook function. Given a host (IP or hostname), a path to a playbook file (assumed to be relative to a "plabooks" directory), a user and a private key, it uses the Ansible API to run the playbook.

This function represents the bare-minimum code required to apply a playbook to one or more hosts. It's surprisingly simple - and I've only scratched the surface here of what can be done. With custom callbacks, instead of the ones used by the ansible-playbook runner, we can fine tune how we collect information about each run.

The playbook I used for testing this implementation is very simplistic (see the Ansible playbook documentation for an explaination of the playbook syntax):

---
- hosts: all
  sudo: yes
  tasks:
  - name: ensure apache is at the latest version
    apt: update_cache=yes pkg=apache2 state=latest
  - name: drop an arbitrary file just so we know something happened
    copy: src=it_ran.txt dest=/tmp/ mode=0777

It just installs and starts apache, does an apt-get update, and drops a file into /tmp to give me a clue that it ran.

Note that the hosts: setting is set to "all" - this means that this playbook will run regardless of the role or class of the machine. This is essential, since, again, the machines are unknown when they invoke this script.

For the sake of simplicity, and to set a necessary environment variable, I wrapped the call to my script in a shell script:

#!/bin/bash
export ANSIBLE_HOST_KEY_CHECKING=False
cd /home/ubuntu
/usr/bin/python /home/ubuntu/run_playbook.py $1 >> $1.log 2>&1

The $ANSIBLE_HOST_KEY_CHECKING environment variable here is necessary, short of futzing with the ssh configuration for the ubuntu user, to tell Ansible to not bother verifying host keys. This is required in this situation because the machines it talks to are unknown to it, since the script will be used to configure newly launched machines. We're also running the playbook unattended, so there's no one to say "yes" to accepting a new key.

The script also does some very rudimentary logging of all output from the playbook run - it creates logs for each host that it services, for easy debugging.

Finally, the following configuration in knockd.conf makes it all work:

[options]
        UseSyslog

[ansible]
        sequence    = 9000, 9999
        seq_timeout = 5
        Command     = /home/ubuntu/run.sh %IP%

The first configuration section [options], is special to knockd - its used to configure the server. Here we're just asking knockd to log message to the system log (e.g. /var/log/messages).

The [ansible] section sets up the knock sequence for an machine that wants Ansible to configure it. The sequence set here (it can be anything - any port number and any number of ports >= 2) is 9000, 9999. There's a 5 second timeout - in the event that the client doing the knocking takes longer than 5 seconds to complete the sequence, nothing happens.

Finally, the command to run is specified. The special %IP% variable is replaced when the command is executed by the IP address of the machine that knocked.

At this point, we can test the setup by running knockd. We can use the -vD options to output lots of useful information.

We just need to then do the knocking from a machine that's been provisioned with the bootstrap keypair.

Here's what it looks like (these are all Ubuntu 12.04 LTS instances):

On the "server" machine, the one with the ansible script:

$  sudo knockd -vD
config: new section: 'options'
config: usesyslog
config: new section: 'ansible'
config: ansible: sequence: 9000:tcp,9999:tcp
config: ansible: seq_timeout: 5
config: ansible: start_command: /home/ubuntu/run.sh %IP%
ethernet interface detected
Local IP: 172.31.31.48
listening on eth0...

On the "client" machine, the one that wants to be provisioned:

$ knock 172.31.31.48 9000 9999

Back on the server machine, we'll see some output upon successful knock:

2014-03-23 10:32:02: tcp: 172.31.24.211:44362 -> 172.31.31.48:9000 74 bytes
172.31.24.211: ansible: Stage 1
2014-03-23 10:32:02: tcp: 172.31.24.211:55882 -> 172.31.31.48:9999 74 bytes
172.31.24.211: ansible: Stage 2
172.31.24.211: ansible: OPEN SESAME
ansible: running command: /home/ubuntu/run.sh 172.31.24.211

Making It Automatic With User Data

Now that we have a way to configure machines on demand - the knock could happen at any time, from a cron job, executed via a distributed SSH client (like fabric), etc - we can use the user data feature of EC2 with cloud-init to do the knock at boot, and every reboot.

Here is the user data that I used, which is technically cloud config code (more examples here):

#cloud-config
packages:
 - knockd

runcmd:
 - knock 172.31.31.48 9000 9999

User data can be edited at any time as long as an EC2 instance is in the "stopped" state. When launching a new instance, the field is hidden in Step 3, under "Advanced Details":

User Data FieldOnce this is established, you can use the "launch more like this" feature of the AWS console to replicate the user data.

This is also a prime use case for writing your own provisioning scripts (using something like boto) or using something a bit higher level, like CloudFormation.

Auto Scaling And User Data

Auto Scaling is controlled via "auto scaling groups" and "launch configuration". If you're not familiar these can sound like foreign concepts, but they're quite simple.

Auto Scaling Groups define how many instances will be maintained, and set up the events to scale up or down the number of instances in the group.

Launch Configurations are nearly identical to the basic settings used when launching an EC2 instance, including user data. In fact, user data is entered in on Step 3 of the process, in the "Advanced Details" section, just like when spinning up a new EC2 instance.

In this way, we can automatically configure machines that come up via auto scaling.

Conclusions And Next Steps

This proof of concept presents an exciting opportunity for people who use Ansible and have use cases that benefit from a "pull" model - without really changing anything about their setup.

Here are a few miscellaneous notes, and some things to consider:


23 Apr 2014 11:47am GMT

22 Apr 2014

feedPlanet Plone

Plone.org: Plone Docs Get Monumental Overhaul

A summary of DocSprint Munich.

22 Apr 2014 8:10pm GMT

21 Apr 2014

feedPlanet Plone

JC Brand: Plone 4 compatible release of Quills

/img/quills.png

Since I've started this site, I've been using Quills for blogging functionality in Plone. So far, it's been perfectly fine for my relatively simple needs and I haven't found a reason to change. Unfortunately, except for some work to port Quills to Plone 4, development and bugfixes on Quills has completely dried up. No new releases were made for more than a year and the mailing list was almost dead. I only realised this when I fixed some bugs while porting my site to Plone 4 and couldn't find anybody to help making a new Plone 4 compatible release.

Eventually I got hold of Tim Hicks, one of the original maintainers of Quills, and I offered to help out with maintaining Quills and to make the new releases.

So, I'm happy to announce that new Plone 4 compatible releases of the Quills packages have been made. Notably Products.Quills, Products.QuillsEnabled and quills.app (all now at version 1.8a1). This new release is labeled alpha, as I'm still very new to the Quills codebase, but I'm already using it on this blog without any major problems.

If there is anyone who is still using Quills on a legacy Plone site and would like to migrate to Plone 4, just pin your Products.Quills (and Products.QuillsEnabled) version to 1.8a1 in your versions.cfg or bulidout.cfg.

Hopefully everything goes well (did I mention it's alpha ;) but if not, feel free to let me know and I'll try to help out.

21 Apr 2014 9:41am GMT

18 Apr 2014

feedPlanet Plone

Quintagroup: collective.contact.core

collective.contact.core is a Plone add-on that helps to manage organizations and staff in Plone (main developers are Vincent Fretin and Cedric Messiant). This product provides directory that can contain contact information for different content types: organizations/sub-organizations, persons,and positions. Contact info option depends on for which content types you set the IContactDetails behavior so it can cover many different uses.

Easy in use:

  1. Add directory to your website and insert all the additional information required. You'll need to specify types of positions and organizations that will be used (e.g. Faculty/Staff/Students for universities). Don't worry about filling out the form, since it can be edited at any time later.

    collective.contact.core edit.png

  2. Create organization(s) in the directory. Depending on the hierarchy, add other organizations (they may correspond to units, divisions, departments, etc.). An organization can contain position (e.g Dean, secretary, SEO) that will be connected with person (a physical person). Choose Organization/Position from the Add new drop-down menu or click on Create contact to divaricate your directory.

    collective.contact.core navigation.png

A person content type can hold one or more positions or be member of one or more organizations. All contact types have optional fields with variety of contact information, including phone, cell phone, fax, email, address, zip code, etc. Such data management is very suitable for universities.

collective.contact.core.png

collective.contact.core can be useful for all kinds of organizations, despite their size, number of employees or subdivisions. Created directory is easy to manipulate and can be branched or edited at any time.

collective.contact.core adds new content types, but preserves Plone functionality, especially concerning users' rights. Every 'organization' content type is similar to folder, thus you can specify in the Sharing tab what rights users have . Moreover, default Plone search is very efficient when you want to search for a specific person or position on all the website.

Use collective.contact.core to arrange your organization and contact information.

Contributors:

More information:

18 Apr 2014 1:07pm GMT

17 Apr 2014

feedPlanet Plone

Agendaless: Pyramid for Plone Developers: Training at Plone Symposium MW 2014

We are pleased to be offering a two day training session at the 2014 Plone Symposium Midwest this year. The two-day course will cover Pyramid development topics, aimed at Plone developers.

For details, please see the training page.

17 Apr 2014 7:44pm GMT

Martijn Faassen: Morepath Python 3 support

Thanks to an awesome contribution by Alec Munro, Morepath, your friendly neighborhood Python micro framework with super powers, has just gained Python 3 support!

Developing something new while juggling the complexities of Python 2 and Python 3 in my head at the same time was not something I wanted to do -- I wanted to focus on my actual goals, which was to create a great web framework.

So then I had to pick one version of Python or the other. Since my direct customer use cases involves integrating it with Python 2 code, picking Python 2 was the obvious choice.

But now that Morepath has taken shape, taking on the extra complexity of supporting Python 3 is doable. The Morepath test coverage is quite comprehensive, and I had already configured tox (so I could test it with PyPy). Adding Python 3.4 meant patiently going through all the code and adjusting it, which is what Alec did. Thank you Alec, this is great!

Morepath's dependencies (such as WebOb) already had Python 3 support, so credit goes to their maintainers too (thanks Chris McDonough in particular!). This includes the Reg library, which I polyglotted to support Python 3 myself a few months ago.

All this doesn't take away from my opinion that we need to do more to support the large Python 2 application codebases. They are much harder to transition to Python 3 than well-tested libraries and frameworks, for which the path was cleared in the last 5 years or so.

[update: this is still in git; the Morepath 0.1 release is Python 2 only. But it will be included in the upcoming Morepath 0.2 release]

17 Apr 2014 2:25pm GMT

David "Pigeonflight" Bain: Install Plone in under 5 minutes on Codio.com

I was introduced to Codio.com by +Rok Garbas. It turns out to be a very nice platform for developing Plone projects. So far what I like is that every Codio box pretty much ships with all the Plone dependencies while at the same time having a full suite of Node based tools (important for modern Javascript development), this is a great time saver on new projects. These are still early days so I

17 Apr 2014 3:21am GMT

14 Apr 2014

feedPlanet Plone

Plone.org: Plone Website Accounts Safe from Heartbleed

The plone.org website is safe from the Heartbleed bug and, as such, plone.org passwords have not been disclosed.

14 Apr 2014 9:01pm GMT