12-Step Program for Performance, with Wanelo.com

Few of my readers will be familiar with Wanelo, the social shopping site, because you just aren't in its target market.  But Wanelo.com is currently the darling of the dot-com world, or as Bloomberg puts it, "the next big thing in ecommerce".  And most importantly to you: they run PostgreSQL.

Last night Wanelo CTO Konstantin Gredeskoul described their "12-step Program for Application Performance" to a packed crowd at their HQ in San Francisco.  This is kind of a recipe book for scaling a social web site backed by Postgres.  Wanelo's stack includes Rails, PostgreSQL, Joyent, SOLR, Redis, Memcached, Manta, and mobile applications.

Video for the talk is here (sorry about quality, Google Hangouts has ... issues).  Konstantin's slides are here.

Postgres SMF Permissions on Joyent SmartOS

A few of our clients run on the Joyent cloud.  Uniquely, Joyent runs SmartOS, an Illumos (i.e. OpenSolaris) distribution, which is the default and supported OS on VMs.   Like Solaris 10 and 11, SmartOS controls server services using the Service Management Framework, or SMF, and XML-configuration-driven tool which supports version-specific start, stop, restart, reload and auto-vivification for PostgreSQL.

Now, for replication failover between SmartOS hosts on Joyent, one of the things we need to do is STONITH ("Shoot The Other Node In The Head") which includes shutting down Postgres on the old master if it's still running.  For various setup reasons, our scripts need to do this as the "postgres" user, not as root.  But, thanks to auto-vivification, if we just "pg_ctl stop", SMF will automatically restart PostgreSQL after a few minutes.  So we needed to grant permission for the postgres user to enable, disable and restart the PostgreSQL service.

Unfortunately, permissions on services are a wierd alchemy of SMF configuration and RBAC, the Solaris security framework.  After several hours of struggling with how to do this, Joyent support came to the rescue.  Ryan Puckett gave me this formula:

echo "postgres.applications:::Manage Postgres::" >> /etc/security/auth_attr
echo "postgres::::type=normal;auths=postgres.applications" >> /etc/user_attr
svccfg -s postgresql setprop general/action_authorization = astring: postgres.applications
svccfg -s postgresql setprop general/value_authorization = astring: postgres.applications 

And I'm delighted to report that, after running the above commands, the postgres user can run "/usr/sbin/svcadm disable postgresql".   Yay!