På måndagar så hålls hackerspace från c:a kl 18. Detta på Fallskärmsgatan 22 i Skarpnäck. Det brukar alltid vara trevliga ämnen! Nu på måndag så är det editorspecial. Kom och visa dina läckra Vim-plugins, bråka om att Emacs egentligen är bättre, osv. Välkommen!
Avoiding unauthorized TURN connections and scaling restund at Google ComputeEngine
I have been hacking around with WebRTC lately. It’s a really cool standard for P2P (peer to peer) in the web browser. However, a major problem with P2P is that clients are not always able to connect to each other, due to firewalls, NATs, etc. In the WebRTC standard, that is solved by using TURN servers to relay traffic.
In WebRTC, the TURN server authorization credentials are set by the JavaScript of the web site. So, they are available for anyone to copy and use, which is a major problem (since bandwidth is not free).
Further, I had to make my TURN infrastructure scale on demand, and have instances running in both Europe and America for keeping latency down.
So, my take on this was:
- The web site generates TURN credentials based on a username (which could be just a random string), the client’s IP address and a shared secret key.
- Modify a TURN server (restund, actually) to accept the credentials created above.
- Have a Google AppEngine application, which keeps track of the TURN server load in the two regions (Europe and America) and starts new server instances on demand (at Google ComputeEngine).
The TURN Server – restund
Restund is a open sourced (BSD license) STUN- and TURN-server, available from here. It is built using lightweight core and server modules that extend its functionality. What I did was simply modifying the existing auth module.
You can find my modified module on github together with instructions on how to compile restund with it.
This is what the module does:
- It generates one new shared secret key each hour, and it keeps them for 24 hours. So a credential will work for ~ 23-24 hours, if you are using the last shared secret key to create it.
- It checks so that the credential is a MD5(userName + “:” + clientIPaddress + “:” + sharedSecretKey). This means that a credential will only work as long as the client’s IP does not change. This effectively makes it pointless for other sites to copy the credential.
Starting/stoping TURN instances on demand
computeengineondemand (link to GitHub) is a Google AppEngine application which starts Google ComputeEngine instances on demand.
At the server instances running restund, there is a cronjob which sends information about the current server load to computeengineondemand. It also sends the last created shared secret key to computeengineondemand as “arbitrary instance data” (check the README.md at GitHub for more info).
Based on the load information, server instances are stopped/started.
One TURN server instance in each geographical area (Europe / America) is the currently “active” one, where there are capacity for new connections. Whenever the active server changes (or we get a new shared secret key), web sites running WebRTC are announced through a HTTP request.
An example: apprtc
As a demonstration, I modified apprtc to use my TURN server setup. Apprtc is a demonstration of WebRTC, available at https://apprtc.appspot.com/ and the source code for apprtc is available here.
The modifications I had to make was:
- If no TURN server was specified by the user, then it should use one of ours (Europe or America, based on AppEngine’s X-Appengine-Citylatlong header).
- Generate a TURN credential based on user’s username, IP-address and the shared secret key.
- Listen on /turnannounce for HTTP requests with TURN servers’ IP addresses and shared secrets.
This is a diff file (created from revision 81 of apprtc) with my modifications of apprtc: https://gist.github.com/anonymous/5153332
I deployed my modified apprtc example at http://apprtcturn.appspot.com/
IPv4 / IPv6
Google ComputeEngine (where I deployed the TURN servers) does not support IPv6 currently, but Google AppEninge does. Since the credentials are made from the IP address of the client, a client with both IPv4 and IPv6 support might not be able to connect (if the HTTP request is over IPv6, but TURN connection is over IPv4).
Solutions to this problem would be:
- To not resolve the IPv6 IP address on domain lookups.
- To add support of IPv6 at Google ComputeEngine.
- The JavaScript client could make an AJAX request to some IPv4-only service which returns the client’s IPv4 address, then sends it to server side which generates the TURN credentials from the IPv4 address.
Detta händer på hackerspacet i Skarpnäck
Just hemkommen ifrån vårat nystartade hackerspace i Skarpnäck. (Namnsituationen lite oklart just nu. “Laboratorium 17″ eller “Sputnik in Space” verkar vara på tapeten.)
Ikväll har vi kollat lite på hur man skapar SMS i inkorgen med hjälp av pythonscript på Nokia N900. Också har vi spånat på framtida workshops, såsom en grundkurs i Linux, en workshop om IPv6, osv.
Nästa vecka, alltså måndagen den 22 oktober, så kommer vi att ha workshop i BackTrack. Vi tar oss in i wifi:s, avlyssnar nätverkstrafik, osv. Vi sätter igång kl 18. Det som skiljer oss från andra hackerspace är att vi har någon slags “öppen förskola” samtidigt som vi har hackerspace, så barn är mycket välkomna. Det innebär att det kanske blir lite mer ofokuserat och stökigt än på andra hackerspace, men förhoppningsvis så ska det inte exkludera någon, utan bara inkludera fler än vanligt.
Att publicera wordpressplugin
Genom åren så har jag gjort oräkneligt många plugins för WordPress, men bara en bråkdel har jag sett till att få publicerade i WordPress Plugin Directory. Det är några moment som är lite störiga, och som har fått mig att inte orka ta steget varje gång. Det mest störiga är att pluginkatalogen använder Subversion, men jag vill oftast versionhantera med Git och använda tjänster typ github.com för issue tracking, osv. Det har inneburit att det finns två ställen där man kan rapportera buggar, osv., vilket skulle kunna bli rörigt i stora projekt.
Men här kommer hur-som-helst en guide för hur jag använder både Git och Subversion parallellt vid utveckling av wordpressplugins. I denna guide så förutsätter jag att det redan finns ett git-repository med själva pluginet, som alltså behöver slås ihop med ett subversion-repository för att kunna publiceras på WordPress Plugin Directory.
1. SKAPA ETT KONTO
Skaffa ett konto på wordpress.org.
2. GÖR EN ANSÖKAN
Logga in på wordpress.org och skicka en ansökan om att få lägga upp ett plugin. Handläggningen är manuell och kan ta flera dagar innan detta trillar in i mailboxen:
Your plugin hosting request has been approved.
I mailet så hittar du adress till det subversion-repository som du ska publicera ditt plugin genom.
3. GIT OCH SUBVERSION I SAMMA KATALOG
Använd subversion för att hämta det repository som wordpress.org har skapat åt dig. Ordna först en arbetskatalog som du kan jobba med, och ange sedan den katalogen som destination när du hämtar repositoryt:
computer:~$ mkdir repo computer:~$ svn co http://plugins.svn.wordpress.org/pluginnamn/ repo
Fyra underkataloger ska nu ha hämtats hem: assets, trunk, bransches och tags. Den första underkatalogen, assets, används för att exempelvis lägga upp en headerbild på ditt plugins presentationssida på wordpress.org. Detta ligger dock utanför fokus för denna guide.
De tre övriga underkatalogerna, trunk, bransches och tags, ingår i praxis för hur man brukar organisera ett subversionrepository. I trunk brukar den senaste utvecklingsversionen ligga, och det är där som själva utvecklingen sker. Därför vill jag att mitt git-repository ligger i trunk.
computer:~$ cd repo computer:~/repo$ git clone https://github.com/alfreddatakillen/pluginnamn.git
Så nu har vi en femte underkatalog som är själva git-repositoryt. Vi vill dock att den ska heta trunk. Den befintliga trunk är dock inte tom, så den går inte bara att byta ut. Subversion lägger nämligen en underkatalog som heter .svn i varje katalog i ett repository, som innehåller metadata om filerna i repositoryt. Den behöver vi flytta in i git-repositoryt innan vi byter namn på git-repositoryt och byter namn på den till trunk:
computer:~/repo$ mv trunk/.svn pluginnamn/.svn computer:~/repo$ rmdir trunk computer:~/repo$ mv pluginnamn trunk
4. FÅ GIT OCH SUBVERSION ATT SAMSAS!
Som sagt så skapar Subversion en underkatalog till varje katalog som heter .svn.
Git skapar också en underkatalog som heter .git, men den finns bara på ett ställe: I repository-rooten, alltså i det här exemplet i ~/repo/trunk/.git
Vi vill hur-som-helst inte att subversions metadata ska läggas till i git-repositoryt, och vi vill inte att git-metadatan ska hamna i subversion-repositoryt. Därför behöver vi säga till både subversion och git att ignorera varandras metadata:
computer:~/repo$ echo ".svn" >> trunk/.gitignore computer:~/repo$ svn propset svn:ignore ".git" . computer:~/repo$ svn propset svn:ignore ".gitignore" .
5. FIXA EN README-FIL
I ditt plugin så måste du ha en fil som heter readme.txt. Det är därifrån som wordpress.org läser in information och beskrivning av ditt plugin.
Det finns en standard för hur readme.txt bör se ut, och en validator som kan validera att din readme.txt är i rätt format. Använd den!
6. LÄGG TILL DINA FILER I SUBVERSION
Git-repositoryt är på plats. Nu behöver vi indexera projektets filer i Subversion också. Vi säger till subversion att indexera allt som finns i trunk (d.v.s. i katalogen som nu även är ett git-repository), men subversion kommer alltså att ignorera gits metadata:
computer:~/repo$ svn add trunk/*
Nu skulle du kunna ladda upp din trunk till wordpress.org’s subversionserver, med en liten förklaring om vad som har hänt:
computer:~/repo$ svn ci -m "Adding the first version of my plugin"
7. TAGGA DIN VERSION
Varje version av ditt plugin ska “taggas” av subversion. Det är det som katalogen tags finns för. Taggning av versioner innebär i praktiken att du har en kopia av varje version av pluginet i var sin underkatalog till tagskatalogen.
Så här gör du när det är dags att släppa en ny version av ditt plugin:
computer:~/repo$ svn cp trunk tags/1.0 computer:~/repo$ svn ci -m "Released version 1.0 of my plugin."
Observera att det ska finnas en “stable tag” i din trunk/readme.txt som anger för wordpress.org vilken version som är den senaste stabila.
8. VIOLA!
Efter att du har kört “svn ci -m”… osv så kommer wordpress.org att publicera ditt plugin. De har dock en del caching osv av sin sajt, så ibland kan det ta upp mot en dag innan det har slagit igenom överallt.
Labb 17 – Hackerspace på Sputnik i Skarpnäck
Vi är några vänner i Bagarmossen-Skarpnäck som håller på att startar ett nytt hackerspace. Vi kommer att vara på lokalen Sputnik i Skarpnäck.
Något som skiljer oss från andra hackerspace är att vi som har tagit detta initiativ är alla småbarnsföräldrar, och vi tänker kombinera föräldraskapet med hackandet, d.v.s. vi tänker träffas under sådana former att vi också kan ha våra barn med oss. Det innebär inte att man måste vara förälder/barn för att få vara med, utan bara att saker kan bli lite stökigare, ljudligare och mer ofokuserat än på andra hackerspace, och att det är meningen att det ska vara så. Förhoppningsvis ska inte detta exkludera någon, utan bara göra att fler känner sig inkluderade.
När vi inte träffas fysiskt på möten, så är vi på chattkanalen #labb17 på IRC-servern: irc.oftc.net. Välkommen in på chatten om du vill vara med, om du undrar när nästa möte är, om du har några frågor, osv.
Eller kom på nästa träff: måndag den 8 september från kl 18! Per Andersson, debianutvecklare, berättar om pakethanteringen i Debian. Vi kommer att se ett debianpaket bli till, och kanske hinner vi experimentera och bygga egna paket också?
Adressen är Fallskärmsgatan 22, Skarpnäck.
Termcasting – how to get social with your terminal!
From time to time, I want to share my terminal output with colleagues or other people. There are lots of CPU expensive ways of sharing screen output, such as VNC, Skype, Google Hangouts, etc., but they are all incredibly heavy for just sharing some terminal letters.
So I termcast. This is how, in 3 steps:
1.
I start screen, and let script save all my output to a file in /tmp:
me:~$ script -c "TERM=vt220 screen" -f /tmp/termcast
2.
My colleague(s) just starts listen to some port using netcat:
colleague:~$ nc -l 1234
3.
I use netcat to send the output from my screen to the colleague(s):
me:~$ tail -f /tmp/termcast | nc 192.168.0.153 1234
Viola!
Golang Sweden/Stockholm: Kom till KTH 5 november!
Den 5 november så kommer denna meetup att äga rum på Reaktorhallen R1 på KTH.
“On the fifth of November, GoStockholm and the Royal Institute of Technology present Andrew Gerrand, Google Developer Advocate from the Go development team in Sidney, and Stefan Nilsson, Assistant professor at the Institute.”
Det har varit ett brinnande intresse, så bara några få platser finns kvar till meetupen, så jag rekommenderar intresserade att skyndsamt OSA. Communityt kring Go växer konstant och det ska bli riktigt kul och intressant att träffa andra som pysslar med språket här i Sverige/Stockholm
Dags att skicka iväg de där visitkorten till tryckeriet, alltså.
Polyfiller for WebRTC DataChannels
Currently, I am working on a project for demonstrating WebRTC. WebRTC is a really cool standard for sending audio, video and other data peer-to-peer directly between web browsers (without passing a web server).
So far, only Google Chrome has (experimental) support for WebRTC, and currently they only support sending audio and video. The DataChannel class, which will be used for sending “messages”, does not exist yet. Rumors says that Chrome will support DataChannels (experimentally) within months. Until then, I built a polyfiller for the DataChannel class. It requires a websocket server, which I built in Go (golang, u know).
You can find the polyfiller here: https://code.google.com/p/webrtc-datachannel-polyfill/
The polyfiller is also experimental (just as everything else regarding WebRTC), but it does support the most basic features of the standard. And currently, the server lacks ways of removing info on old connections, so if you are running this on a sharp server, you might want to check your memory usage and maybe restart the server from time to time.
SwedBank E-Kort och Amazon
Sedan jag lyckades knäcka min Amazon Kindle på mitten i vintras så har jag upprepade gånger försökt köpa en ny. Vid varje beställning så har jag dock fått ett mail ifrån Amazon:
Hello,
We’re writing to let you know the payment for order #: xxx-xxxxxxx-xxxxxxx has been declined. You can check the current status of your order, and update your payment method through Your Account on our site…
Som betalningsmedel använder jag SwedBanks E-Kort. Jag har försökt allt: Ändra ordning på för- och efternamn, försökt med alla upptänkliga kombinationer av min “invoice address”, skapat nya konton på Amazon, ringt SwedBank och fått mitt Mastercard utbytt i hopp om att det skulle fungera bättre.
Jag har googlat och frågat på forum och kommit i kontakt med massor av folk som har samma problem.
Lösningen:
- Ange inte 1 månads expiry time på ditt SwedBank E-kort. Amazon tycker att det är ett kort som håller på och bli ogiltigt och accepterar det inte.
- Ange inte för många månaders expiry time heller. SwedBank tycker att Amazon är oseriösa och decline:ar om det är för lång giltighetstid på E-kortet.
Nu kör jag med 2 månaders gilitighetstid på SwedBank E-kort när jag ska pröjsa Amazon. Det funkar.
Tangentfuckup på MacBook Pro
Detta lär inte intressera några andra än oss svenskspråkiga, därför ett svenskt inlägg.
Jag har äntligen slängt ut Mac OS från min MacBook Pro, till förmån för Ubuntu 12.04. Eftersom att jag har suttit hela natten (trial-and-error!) med att försöka få tangentbordet att funka “normalt” (d.v.s. det ska kännas som på en “vanlig” PC med svensk layout), så ska jag här dokumentera hur det är gjort.
- Som keyboard layout använder jag “Swedish”. Det finns även en “Swedish (Macintosh)”, men den fuckar upp några enstaka tangenter – främst vänstra curly bracket (men inte högra). Som programmerare är det helt omöjligt att klara sig utan vänster curly bracket.
- Jag vill naturligtvis att tangenten direkt till vänster om space ska fungera som alt. I synnerhet för att alt-tab ska kännas rätt, men Apple har valt att kalla den tangenten cmd, vilket gör att det blir en krystad rörelse för att göra alt-tab på en nyinstallerad Ubuntu på MacBook Pro. För att rätta till detta så går jag in i “Options…” från “Keyboard Layout”-dialogen, och under “Alt/Win key behaviour” så klickar jag i “Left Alt is swapped with Left Win”.
- Sedan har vi vårat återkommande svenska problem med tecken som ligger på AltGr på ett icke-apple-tangentbord. Jag vill såklart att AltGr ska vara tangenten omedelbart till höger om space. Så i “Options…” från “Keyboard Layout”-dialogen, under “Key to choose 3rd level” kryssar jag i “Right Win”. Nu fungerar både höger cmd och höger alt som AltGr på ett icke-apple-tangentbord, vilket känns utmärkt!
Hoppas att jag härigenom att hjälp någon stackare som idag sitter och vrider sönder handlederna på MacBook Pro.