OpenBSD Journal

GSoC 2014: Systemd replacement utilities (systembsd)

Contributed by jj on from the all your system is belong to us dept.

Ian Kremlin wrote in with this report on the GSoC he was involved in:
This summer I, along with my mentors Landry Breuil and Antoine Jacoutot, worked on systemd shim-like replacements for four D-Bus daemons systemd provides, namely hostnamed, localed, timedated, and logind.
Now let's clear some things up:

The purpose of this GSoC was (is) not to port systemd to *BSD in way, shape or form. Nor is it to replace the existing init(8), boot(8) or rc(8) programs. Systemd and *BSD differ fundamentally in terms of philosophy and development practices and special care was taken to only wrap the functionality of the aforementioned daemons and not create any new systemd-like functionality.

You can find the repository here
.
Upon completion and review, my code will most likely end up as a port to be installed along with the GNOME suite, or any other ports that depend on systemd (upstream) and need a compatibility layer to work properly on non-systemd operating systems. It goes without saying that none of my code will end up (or belongs) in the base system.

Hostnamed (formally systemd-hostnamed) is a D-Bus daemon that handles setting system hostnames (in our case, that's through the sethostname(3) call and the /etc/myname file) as well as provides system information mostly found through uname(1). Hostnamed also handles determining the system's chassis type, whether it be a server, desktop, laptop, handheld, VM, etc. and providing a proper icon from that information.

Localed and timedated are more straightforward daemons that allow setting system/xorg locales/keymaps and times/dates/timezones/NTP settings respectively.

Logind (currently unfinished) is a rather large daemon that encompasses many aspects of a user's login session. This includes everything from getting current users and any PIDs under them, as well as system suspension and shutdown/reboot preparation. We are still researching a proper way to implement this as native systemd uses PAM for authentication, something we do not want to do on OpenBSD.

Overall, it was an excellent summer. I took this project because I was fed up with what systemd was doing to my then-main computer running Arch Linux. I figured this would be a great way to make the move to OpenBSD and I couldn't be happier. I dearly hope you'll be seeing more of me in the future ;)

As a fun aside, me and some friends all turned 21 around the beginning of August (the tail end of GSoC) and decided to pool our pennies together to take a road trip together to Colorado. This led to some interesting circumstances. All I can say is that there is stable LTE service between Texas and Colorado that work at speed in excess of eighty-eight miles per hour and that one can do a lot with a macbook charger, a working alternator, a bit of cabling and entry-level electrical engineering knowledge.

Thanks for the report, and hope you didn't get too tainted with systemd.

(Comments are closed)


Comments
  1. By Noryungi (noryungi) noryungi@yahoo.com on

    First of all, many many thanks for your work and for this short introduction!

    One obvious question, but which is very important for me, is to know whether or not a portable version of these utilities is planned?

    There are still some (sane) Linux distributions that do not plan on shipping with systemd -- porting systembsd under these distros would be a great way to maintain their independence.

    How BSD-specific are these utilities? Do you think porting them to Linux would mean significant rewrites?

    Second question: apart from logind, how would you rate the difficulty of writing these utilities?

    Again, thanks for all the hard work!

    Comments
    1. By ian (128.230.184.88) ian@kremlin.cc on https://kremlin.cc

      > First of all, many many thanks for your work and for this short introduction!
      >
      > One obvious question, but which is very important for me, is to know whether or not a portable version of these utilities is planned?

      yes, the original outline for the project included a bit about OS-agnosticism. my approach to this was to use GLib overall, so porting it will not be an enormous headache. there are some more fundamental differences (such as how hostnames are handled) that will require a bit more proactive porting effort, however.

      i've recently been talking to someone who is interested in working with me + my code to port it to a minimal, busybox-like system which would require stripping out GLib, so that is just another thing on the horizon

      > There are still some (sane) Linux distributions that do not plan on shipping with systemd -- porting systembsd under these distros would be a great way to maintain their independence.
      >
      > How BSD-specific are these utilities? Do you think porting them to Linux would mean significant rewrites?

      hostnamed is probably the most bsd-specific right now, localed much less so and timedated even less. logind will probably be more bsd-specific due to the sheer complexity and responsibilities it covers.

      > Second question: apart from logind, how would you rate the difficulty of writing these utilities?

      i would say about 70% of this project was dealing with all the framework and scaffolding that is D-Bus + friends, which was particularly excruciating at first. even using GDBus (wrapper lib for D-Bus whose first page of documentation has "If you use this low-level API directly, you're signing up for some pain." in bold letters) it was quite a pain to learn, but once you get the hang of it, it is somewhat less of a nightmare.

      the other 30% was the actual implementation of the methods on openbsd, which was much less complicated and straightforward. it was the fun part!

      > Again, thanks for all the hard work!

      you are welcome! :)

      Comments
      1. By Noryungi (noryungi) on

        > > Again, thanks for all the hard work!
        >
        > you are welcome! :)

        And thanks again for taking the time to answer my questions!

  2. By Ypnose (134.157.2.73) on

    Good work. I look forward to see it in base. I'm excited!

    Comments
    1. By Anonymous Coward (178.162.209.232) on

      > Good work. I look forward to see it in base. I'm excited!

      From the article: "It goes without saying that none of my code will end up (or belongs) in the base system."

    2. Comments
      1. By Ypnose (134.157.2.73) on

        > > Good work. I look forward to see it in base. I'm excited!
        >
        > This will end up in ports, as protection for systemd-tainted packages.

        Yes, true. I did a mistake because I didn't read the entire article. I will read it more carefully next time.

  3. By Marc Paul Rubin (71.94.168.250) on

    Thanks for your work, and for clarifying its limited role in OpenBSD. Any idea how portable this would be to other BSD OSs?

    Comments
    1. By ian (74.106.201.50) ian@kremlin.cc on https://kremlin.cc

      > Thanks for your work, and for clarifying its limited role in OpenBSD. Any idea how portable this would be to other BSD OSs?

      porting to other BSDs will certainly be less of a hassle than porting to linux, and from what i have researched it should be very little trouble overall.

      in fact, a freebsd committer (bapt@) has recently begun creating a patch set you can find here: https://people.freebsd.org/~bapt/systembsd/

  4. By Lars Schotte (80.152.30.211) gustik@gustik.eu on http://gustik.eu/

    This replacement utilities to get some software running again may be a good idea. However, I would go further and make the first step towards launchd on BSDs. I already discussed this on a FreeBSD IRC channel and they told me that Apple launchd would be the only choice, because it is Apache licensed and thus license compatible to BSD, unlike other alternatives.

    Comments
    1. By Anonymous Coward (184.71.29.106) on

      > This replacement utilities to get some software running again may be a good idea. However, I would go further and make the first step towards launchd on BSDs. I already discussed this on a FreeBSD IRC channel and they told me that Apple launchd would be the only choice, because it is Apache licensed and thus license compatible to BSD, unlike other alternatives.

      i don't think its really going places: https://wiki.freebsd.org/launchd
      it was a GSoC 2005 project. its 2014.

      this is still outside of the scope of the replacement tools talked about here however, they are not and will never replace init.

      Comments
      1. By loreb (79.7.204.200) on

        > > This replacement utilities to get some software running again may be a good idea. However, I would go further and make the first step towards launchd on BSDs. I already discussed this on a FreeBSD IRC channel and they told me that Apple launchd would be the only choice, because it is Apache licensed and thus license compatible to BSD, unlike other alternatives.
        >
        > i don't think its really going places: https://wiki.freebsd.org/launchd
        > it was a GSoC 2005 project. its 2014.
        >
        > this is still outside of the scope of the replacement tools talked about here however, they are not and will never replace init.

        Does anyone know if http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html was considered/rejected/whatever? While it is meant to replace init it looks modular enough that one could just use a few pieces of it.

  5. By Ilyas Bakirov (79.142.53.90) on

    systemd is not warm welcomed by many Linux distors, why almost *UNIX derived OpenBSD switch to systemd? just for Gnome desktop? huh :(

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