OpenBSD Journal

g2k14: Landry Breuil on Taming Mozilla

Contributed by tbert on from the firefox-fur-coat dept.

As is now an habit, i had made zero plans for this hackathon, i had some unfinished stuff lying around, and no real big task ahead. Firefox 31 betas were already working for me, and only needed actual testing.

In the end, i spent quite a bunch of time doing some sysadmin stuff with ansible, with which i've really felt in love. Thanks to rpe@, we have a really up-to-date port, and it was the perfect occasion for me to reconfigure some of my infrastructure servers, starting by our test bulk cluster OPI - which can be now fully upgraded/reconfigured in a single ansible playbook task, taking care of all the steps to be able to run a bulk build. This will soon be featured in an article in a french newspaper issue about BSD systems. I'll really stress that ansible can be the perfect tool to remotely administer OpenBSD systems, only needing ssh and python on the remote machine, and the learning curve of the tool is really smooth.

I also spent some time digging in various pkg_tools/pkg_locatedb/pkg_check/sqlports/pkg_sign usecases, more material for another article in the same newspaper - along this, i had lots of questions for espie@, who still thinks his code is easy to understand to outsiders.. unfortunately, not everyone is as smart as him.

A hackathon wouldnt be one without some activity in mozilla's bugzilla, so i resumed pushing some patches that were still local and pending to reduce our count of local modifications - unfortunately, some last minute changes to our headers (read: endian.h) brought more patches to all our mozilla ports, and ruined my efforts :)

I tried porting the new mozilla sync server, since the one we have in-tree will stop working with gecko 31. Unfortunately, after 15 new ports of some python libs, and realizing i'd also need to port around a bazillions of node js modules, i totally gave up on this. I doubt this'll improve in the future, the new sync server is not really designed to be properly packaged, rather ran directly from a one-shot checkout of its sources.

I also did some minor wip update to the www/nginx port, adding the ldap auth patch, polished ports for a pair of GIS caching servers i plan to use at work (mapcache, and mapproxy) but that work is still awaiting feedback and review.

As Vadim said, i spent quite a bunch of time proofreading lots of new ports needed for kde4 updates, fixing nits around and commenting on style issues - but since he's now an experienced porter, i didnt have much to add... and finally, i reviewed the work of our GSOC student about systemd-like daemons, to allow us to have equivalent features provided via D-BUS (those are more and more needed by gnome), and the architecture is shaping up quite nicely - we had quite some interesting exchange with him and ajacoutot@. I think that's material for a standalone undeadly issue, i'll let ian talk about it :)

Thanks again to mitja and his crew, again a perfect event in a really nice city!

(Comments are closed)


Comments
  1. By Anonymous Coward (2601:8:9c80:305:64:e372:96c1:b234) on

    American newspapers: Who in Hollywood slept with who... French newspapers: interviews on making bulk builds easier with Ansible...

    'MURICA

  2. By Russell (74.111.215.221) on

    I too fell in love with Ansible, mainly for the second reason Landry mentioned, the gentle learning curve.

    Most configuration management systems throw you straight into the guts of the system. As one very new to the whole concept I quickly got overwhelmed trying to figure out where to even start.

    Ansible starts you off with "Here is how you run a single command", this is equivalent to the repl found in many programming languages, never seriously used for future work, however it lets you poke at the system at a time when you are still trying to get an understanding of the domain you found yourself in.

    So anyhow, many thanks Landry for keeping Ansible current.

    Now if I could figure out how to keep vi from turning spaces into tabs on autoindent.

    Comments
    1. By Russell (74.111.215.221) on

      > I too fell in love with Ansible, mainly for the second reason Landry mentioned, the gentle learning curve.
      >
      > Most configuration management systems throw you straight into the guts of the system. As one very new to the whole concept I quickly got overwhelmed trying to figure out where to even start.
      >
      > Ansible starts you off with "Here is how you run a single command", this is equivalent to the repl found in many programming languages, never seriously used for future work, however it lets you poke at the system at a time when you are still trying to get an understanding of the domain you found yourself in.
      >
      > So anyhow, many thanks Landry for keeping Ansible current.
      >
      > Now if I could figure out how to keep vi from turning spaces into tabs on autoindent.
      Whoops, just reread the article, apparently it is rpe@ that maintains the ansible port, well salutes to you sir.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]