OpenBSD Journal

c2k15: ajacoutot@ on rc.d refinements, ports churn and sysmerge's future

Contributed by pitrh on from the we will rcctl you dept.

Next up in our series of c2k15 hackathon reports is from Antoine Jacoutot (ajacoutot@), who writes:

A few days before the hackathon, I worked on a few rc.d(8) related things that I wanted to (and did) commit at the start of the week to give me a chance to fix any fallout.

The first change was in rcctl(8). I implemented a new rcctl command that proved very useful for configuration management tools: "ls". That command outputs a list of services according to the given subcommand:

all      list all services and daemons
faulty   list enabled but stopped daemons
off      list disabled services and daemons
on       list enabled services and daemons
started  list running daemons
stopped  list stopped daemons

I already fixed SaltStack so that it uses this new command, which speeds up the service state by a factor of three. This change has been pushed upstream and should be part of an upcoming salt release.

# rcctl ls faulty

can come in handy as a poor-man service monitoring tool to detect daemons that should be running but are not. It was requested by landry@ a few weeks ago and sthen@ was already using a small script to achieve the same goal.

The second modification I did was a bit more intrusive. Until now, the rc.d(8) framework was doing a "best match" against the process list. This worked fine unless you wanted to run the same daemon twice, in which case it would match both running processes. We are now matching against the _exact_ process name and arguments. This was inspired by a post from "nusenu" on misc@ who wanted to be able to run several tor processes by just linking /etc/rc.d/tor to /etc/rc.d/tor{1,2} ... This ended up breaking a few base and ports daemons which I fixed within the next few days.

The third and last rc.d(8) change was to unbreak stop/restart/reload when using the `-f' switch (which is used to start a daemon that is not enabled in /etc/rc.conf.local).

I also spent quite a lot of time updating ports (as usual), fixing our packages documentation to cope with the sudo(8) removal from base, changed some perl substitution to use the new 'sed -i' (thank you jasper@!) etc

I also released a new version of toad(8), the M:Tier hotplugd(8) script, to cope with non-mountable devices after pirofti@ gave me a broken USB key.

I finished by updating suitesparse to the latest available release. This was requested by pirofti@, and ended up being quite a challenge, since I never played with the fortran module before and the suitesparse build framework did not provide a way to create shared libraries. It's been committed, but broke octave. An update is in the works that should fix that.

At last, I had a few quick chats with deraadt@ regarding the future of sysmerge(8). What I'd like it to do is:

- make the installer run sysmerge(8) non-interactively during upgrades

- make sysmerge(8) handle the removal of "old" files (you know the list you have to copy/paste from the FAQ when moving from one release to the other)

I am still investigating the best (tm) way to do this, and hopefully will be able to provide a diff after 5.8 is cut.

To finish with, I would like to remind people who are looking to contribute to OpenBSD that we have a "portroach" page at http://portroach.openbsd.org/ that lists outdated ports. Some are very easy to bring up-to-date and are a good entry point to learn how ports(7) work. My secret goal is to have less than 10% outdated ports at any time.

Like always, it's been a very fun and productive week. The SAIT polytechnic of Calgary has fantastic facilities. A great thank you to everyone involved in organizing yet again a great hackathon.

Thank you, Antoine, for all the work and a great report! And to our readers, we can say that there will be more c215k reports coming after this one.

(Comments are closed)


  1. By Just Another OpenBSD User () on

    Sorry to make it not look perfect but does the portroach site work in a plain browser without the JS infestation, or is it only my end having issues?

    1. By Anonymous Coward () on

      > Sorry to make it not look perfect but does the portroach site work in a plain browser without the JS infestation, or is it only my end having issues?

      You're not going o run their website's Javascript, but you _are_ going to run their operating system? :o

    2. By Anonymous Coward () on

      > Sorry to make it not look perfect but does the portroach site work in a plain browser without the JS infestation, or is it only my end having issues?

      It's broken in lynx 2.8.9dev.1, anyway.

    3. By Jasper () jasper@openbsd.org on

      > Sorry to make it not look perfect but does the portroach site work in a plain browser without the JS infestation, or is it only my end having issues?

      Correct, portroach requires Javascript. The reason for this is actually pretty simple.
      The HTML pages are just a frontend which fetch and render JSON on the fly. These JSON files are not only used to generate the webpages, but they also allow others to re-use the data generated by portroach (such as afresh1@'s get_outdated script).
      So you're free to use the data and generate your own static-HTML pages from it :)

  2. By Billy Larlad () larladtech@gmail.com on

    Really good work, aja@! Thanks for it.

  3. By Just Another OpenBSD User () on

    Thank you once again for the good write up, and the added details regarding portroach page. Looking forward the the sysmerge polishing as well, OpenBSD has always been the easiest to install, upgrade and keep current by far compared to other systems: saves time and effort, and deserves more than praise.

  4. By Kurt Miller () on

    Sounds like a productive hackathon. Wish I could have been there too!

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.]