Contributed by pitrh on from the leading by example dept.
Finally a hackathon where I did not have to spend 90% of my time under ports/x11/gnome \o/ (but of course, I had to cd into it anyway...). Besides some regular tweaks and updates in there, I worked on the gnome.port.mk MODULE to make it more generic and allow non-GNOME ports to benefit from some of its goodies (like xdg triggers and such) without ending up with unneeded build dependencies or things being only relevant to GNOME.
I also started working on a small utility to manage rc(8) configuration. Having to work with different management tools for my day job, I got really fed up by the fact that OpenBSD did not have a standard way to list, enable, disable... services which means each tool (Ansible, Puppet, SaltStack) has to implement some kind of quirky support for editing rc.conf.local(8) (and in a different language) -- when it is actually implemented...This was the start of an interesting discussion between Theo, robert@ and myself, where we realized having a tool to edit a file that is actually sourced as a shell script may end up being very dangerous if the tool blows up.
So Theo insisted that rc.conf(5) (and rc.conf.local(5)) stopped being sourced by the rc.d(8) system and instead became parsed files. Beware, that means no crazy shell code in these files will work anymore.
This leaded to even more changes: rc.local, rc.shutdown and rc.securelevel stopped being sources as well and are now executed directly by sh(1).
It is worth noting that these 3 files are not even installed by default anymore.These changes de-polluted the rc(8) environment quite a lot!
The fate of my rc edit tool is still under consideration as we may end up developing something that does actually much more than just dealing with rc.conf(8) files ;-)
Speaking about rc.d(8) I implemented a new function: rc_wait(). By default, the rc.d(8) framework would forcibly kill a daemon after 30 seconds if it did not respond to the "stop" action (and would do the same with "start", i.e. stop trying to start it if it did not come alive fast enough). In large database environments, or when using the Squid proxy, this timeout can easily be reached and you probably do not want your application to unsafely end up being killed. Now by setting daemon_timeout, this timeout can be extended (or reduced).
Theo and I started removing configuration files from /etc. Well, not "removing" but actually moving them to /etc/examples/ where they now serve as a placeholder for much more extensive configuration examples. The purpose is not to really to copy the example file under /etc but instead create a file from scratch with the help of the numerous examples that the file under /etc/examples contains. On top of this, some files that were in the etc set got moved to the base one like /etc/services or /etc/protocols (which I updated in the process).
Amongst other benefits, all of this will ease sysmerge(8)'s job because it will not have to compare these files against the default ones since there are no default ones installed. When an example file changes from one release or snapshot to another and that you have a corresponding file under /etc, then sysmerge(8) will now warn you that the example has changed (which could indicate an important syntax change for instance).
This move is not over yet, more files will follow, but there are already around 35 files that got moved from the /etc root. This will make automated updates much easier! One of the end-goal being to run sysmerge(8) automatically after an upgrade.
Along with the initial /etc/examples support, I've worked on a very often requested feature for sysmerge(8): support for packages. I have an initial implementation which should be committed pretty soon. It will allow users to compare @sample files installed by packages against the default ones.
As far as I am concerned this was a very productive hackathon and I am very excited with all the recent changes happening in OpenBSD.
Ljubljana was as I remember it from a previous hackathon: awesome! And Mijta did again a more-than-perfect job in hosting the event.
(Comments are closed)
By Anonymous Coward (93.38.58.95) on
Comments
By journeysquid (Tor) on http://www.bsdnow.tv/
By Renaud Allard (renaud) renaud@allard.it on
But, now, what if someone does an upgrade and /etc/services had been modified before to add some more services? Would he be notified?
Comments
By Josh Grosse (129.9.75.247) on
Most of us who upgrade use sysmerge(8) to manage local changes in /etc.
Additionally, this change was documented in the Following -current FAQ, and I assume it will be documented in the Upgrade Guide: 5.5 to 5.6.
By Anonymous Coward (2601:6:51c0:e1:38a5:d2ec:cd3f:dac3) on
Let's hope the ports start doing similar things with their "extensive configuration examples."
Many thanks for your efforts!
By brynet (Brynet) on http://brynet.biz.tm/