Environment variables in wsgi-applicaties

Soms heb je een environment variable nodig in een wsgi-applicatie, zoals bijvoorbeeld LD_LIBRARY_PATH omdat een bepaalde C-bibliotheek niet beschikbaar is.

De normale manier om dat te doen is via mod_env en SetEnv in de VirtualHost-definitie, maar voor wsgi-applicaties werkt dat niet, omdat die gestart worden voor de eerste request. SetEnv wordt enkel uitgevoerd bij de eerste request naar een site.

Je moet die variables meegeven aan het apache (httpd)-proces zelf, met dien verstande dat ze dan voor alle websites en webapplicaties beschikbaar zijn (wat misschien niet de bedoeling is). Op Ubuntu-gebaseerde systemen moet dat in /etc/apache2/envvars, op RedHat-gebaseerde systemen gebruiken /etc/sysconfig/httpd:

LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/opt/apa/lib"

Een procesherstart later zou de variable moeten beschikbaar zijn.

ObjectId & PyMongo

Het is een beetje weggestopt in de documentatie, maar het staat er gelukkig wel in. Wanneer je een document uit een mongodatabase wil halen op basis van zijn _id, dan moet je dat id eerst omzetten naar een ObjectId, anders krijg je onbegrijpelijke “Document not found“-foutmeldingen.

Alweer een uur gespaard!

Puppetmodules in RubyMine

In RubyMine, een uitstekende IDE uit de Jetbrainsstal, kan je Puppetmodules ontwikkelen (de taal is ondersteund), maar je moet enkele dingen in het achterhoofd houden.

Zo eentje heb ik vandaag ontdekt. Opdat RubyMine automatisch de naam van variabelen, functies en klassen uit jouw module zou aanvullen, moet je ervoor zorgen dat ze op één of andere manier door heeft dat je een module aan het ontwikkelen bent.

De oplossing is eenvoudig en elegant: voeg een metadata.json-bestand toe en zorg ervoor dat de structuur van de module overeen komt met de documentatie.

Een kleine moeite, een wereld van verschil.

mysql op Ubuntu 16.04

Groot was de (mijn) consternatie toen ik probeerde om op een blauwe maandag (het zal eerder een zaterdag geweest zijn, maar goed) een database aan te maken voor één of ander project. Normaal is dat niet zo moeilijk: inloggen als root, database aanmaken et voilà, Bob’s your uncle!

Maar niet dus. Hoewel ik het mij niet kon herinneren, bleek de mysql server al geïnstalleerd te zijn en, nog vreemder, er was een rootwachtwoord ingesteld. Nu ben ik, als goede systeembeheerder, nogal paranoïde, en was het dus niet onmogelijk dat ik in het verleden het wachtwoord toch had ingesteld.

Maar een goede systeembeheerder documenteert, en het ingestelde wachtwoord kwam niet overeen met het door mij gedocumenteerde mysqlwachtwoord (ik gebruik Keepassxc als wachtwoordbeheerder). Allemaal wreed vreemd.

Een mysqlwachtwoord opnieuw instellen is niet zo moeilijk, in principe, maar in dit geval wou het maar niet werken. Na een lange avond zoeken (u wil het echt niet weten), bleek deze lijn in /var/log/syslog (en niet in /var/log/mysql/error.log trouwens) het antwoord te bevatten:

[Warning] 'user' entry 'root@localhost' has both a password and an authentication plugin specified. The password will be ignored.

Tussen Ubuntu 14.04 (mijn vorige versie) en Ubuntu 16.04 (de huidige) is de standaardauthenticatieplugin van MariaDB op Ubuntu veranderd naar unix_socket. En daarom lukte het niet om het wachtwoord te wijzigen, of in te loggen met het nieuwe wachtwoord.

Om alsnog toegang te krijgen tot de server, moet u simpelweg als root (de Linuxgebruiker, niet de mysqlgebruiker) mysql -u root uitvoeren:

sudo mysql -u root

Je kan, en ik citeer, niet meer inloggen als een andere gebruiker wanneer die plugin geactiveerd is voor een bepaalde gebruiker; dus enkel root kan inloggen als root.

U moet het maar weten. Of de release notes lezen natuurlijk …

WSGIPassAuthorization

Een RESTful API die niet helemaal publiek mag zijn is meestal beveiligd met een variant van HTTP Basic Authentication. Daar is natuurlijk niets mis mee, want het is veruit de eenvoudigste manier voor een API-consument om zich te identificeren.

Maar onlangs stootte ik toch op een caveat emptor: wanneer je een API in Python (bv. Flask) via mod_wsgi beschikbaar stelt, dan werkt het plots niet meer om met Basic Authentication aan te melden. Mysterie, mysterie, zeker omdat het in de ontwikkelomgeving wel werkte.

Na lang (~ 1/2e dag) zoeken bleek mod_wsgi de schuldige (en mijn gebrekkige lectuur van de handleiding, want het is gedocumenteerd). In een standaardopstelling worden de authorization headers immers onderschept door Apache, die zelf de authenticatie wil uitvoeren. Uiteraard wist ik dat niet, en had Apache ook niet zo geconfigureerd. En dus stond ik voor het mysterie van de missende header.

Maar via wat google-fu en een blogpost kwam ik dan toch op de oplossing. In de vhost (of elders, al naargelang) waar je de wsgi-applicatie hebt geconfigureerd moet je de instelling WSGIPassAuthorization op On zetten (en dan de webserver herstarten, dat spreekt).

WSGIPassAuthorization On

En hoera! De authenticatie werkt! Op naar het volgende probleem!

Wetteren – Gent-Sint-Pieters: in het zadel!

Ik ben vandaag met de fiets van Wetteren naar het Sint-Pietersstation gereden. Op zich geen wereldschokkend nieuws (al is het een beetje vreemd voor iemand die altijd de trein neemt), maar ik ga het er toch even over hebben. We moeten immers allemaal groen zijn (fiets! openbaar vervoer!), maar wanneer iemand het dan ook echt eens wil doen blijkt dit toch ook weer niet zo eenvoudig …

Er is geen “fietsostrade” van Wetteren naar Gent (wel een autostrade, de E40, een steenweg, de N9, en diverse spoorwegen), dus er is geen mooi recht fietspad. Ik heb dus zelf een beetje een route gefabriceerd, met hopelijk een mooie balans tussen snelheid (de droom om per fiets naar Gent en dan per trein naar Brussel is nog niet dood) en veiligheid (één accident is meer dan genoeg).

“Wetteren – Gent-Sint-Pieters: in het zadel!” verder lezen