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 daemonsI 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 faultycan 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)
By Just Another OpenBSD User (87.126.197.32) on
Comments
By Anonymous Coward (69.178.113.4) on
You're not going o run their website's Javascript, but you _are_ going to run their operating system? :o
By Anonymous Coward (82.83.144.230) on
It's broken in lynx 2.8.9dev.1, anyway.
By Jasper (82.161.249.145) jasper@openbsd.org on
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 :)
By Billy Larlad (69.178.113.4) larladtech@gmail.com on
By Just Another OpenBSD User (87.126.197.32) on
By Kurt Miller (74.88.179.142) on