GNU Shepherd 1.0 Service Manager Released As "Solid Tool" Alternative To systemd

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • jacob
    Senior Member
    • Jul 2010
    • 2973

    #31
    Originally posted by uid313 View Post
    I am using Ubuntu which uses systemd and I am very happy with systemd because my system works fine, and I don't use systemd, I just know its installed on Ubuntu and works.

    People complain about systemd but it works fine on my system.

    I wouldn't want to replace systemd with anything. Also this Guile language looks really weird and confusing and I think it is much easier with something like YAML or Python.
    IMHO this is a great point. Unless you are developing some OS service, you should never have to "use" the system manager. It should really be like the kernel or ACPI: do its job and not bother the user. Neither systemd nor launchd nor svchost are perfect but they are the closest thing we have to that ideal case.

    Comment

    • oiaohm
      Senior Member
      • Mar 2017
      • 8519

      #32
      Originally posted by skeevy420 View Post
      Code:
      Description=OpenSSH Daemon
      Wants=sshdgenkeys.service
      After=sshdgenkeys.service
      After=network.target
      
      [Service]
      Type=notify-reload
      ExecStart=/usr/bin/sshd -D
      KillMode=process
      Restart=always
      
      [Install]
      WantedBy=multi-user.target
      ​
      Versus

      Code:
      (define sshd
      (service
      '(sshd ssh-daemon) ;the secure shell daemon
      #:start (make-inetd-constructor ;start on demand
      '("/usr/sbin/sshd" "-D" "-i")
      (list (endpoint
      (make-socket-address AF_INET INADDR_ANY 22))
      (endpoint
      (make-socket-address AF_INET6 IN6ADDR_ANY 22)))
      #:max-connections 10)
      #:stop (make-inetd-destructor)
      #:respawn? #t))
      
      (register-services (list sshd))
      (start-in-the-background '(sshd))​​
      Not gonna lie, the # not being used to comment out code throws me off.
      I am sorry that not a correct one to one.

      Network Accounting and Control from here is required to replace those make-socket-address bits.

      This following in shepherd
      Code:
      (endpoint
      (make-socket-address AF_INET INADDR_ANY 22))​
      comes
      Code:
      SocketBindAllow=ipv4:22
      SocketBindDeny=any​
      in systemd.

      There is a difference here systemd socket control does not have the INADDR_ANY. Yes with shepherd it support having a process like on socket 10 on ipadress 127.0.0.1 and on socket 20 on ipaddress 127.0.0.2 because those INADDR_ANY/in6addr_any can be replaced by IP addresses. this more complex stuff with systemd has to be done by bpf ingress programs.

      Yes Systemd general case of
      Code:
      SocketBindAllow=22
      SocketBindDeny=any​

      for hardening ssh is a lot more compact and systemd does still have ipaddress filtering with IPAddressAllow=ADDRESS[/PREFIXLENGTH]…, IPAddressDeny=ADDRESS[/PREFIXLENGTH] but this is not per socket ipaddress filtering as shepherd has.

      Lot of distribution provided systemd service files are not has hardened as systemd allows. That is the one thing about gnu shepherd if you had not declared the make socket address bit shepherd auto defaults to Deny any as in blocked so not setting up the hardening stuff at least somewhat is not a option..

      Comment

      • Sonadow
        Senior Member
        • Jun 2009
        • 2282

        #33
        Originally posted by uid313 View Post
        I am using Ubuntu which uses systemd and I am very happy with systemd because my system works fine, and I don't use systemd, I just know its installed on Ubuntu and works.

        People complain about systemd but it works fine on my system.

        I wouldn't want to replace systemd with anything. Also this Guile language looks really weird and confusing and I think it is much easier with something like YAML or Python.
        That is what makes systemd great.

        Everybody knows its there yet it's also not there. It's just there, doing what it needs to do, out of sight and out of mind.

        Not like the fragile mess of spaghetti sysvinit startup and service scripts. And definitely not like this one. Upstart was somewhat decent back then and I am very certain would have eventually become the de facto init mechianism with many of systemd's features eventually tacked on (especially service dependency resolution) had systemd not come along.

        Distributions are going to have to pry systemd off my cold dead hands if the alternatives are like this.
        Last edited by Sonadow; 09 December 2024, 08:39 PM.

        Comment

        • jacob
          Senior Member
          • Jul 2010
          • 2973

          #34
          Originally posted by emblemparade View Post
          Technically speaking, systemd's ini-style files are not the only way to create units. They can be created programatically via API, and indeed much of the internal stuff is created that way.

          For what it's worth, I have often been unhappy with the limitations of ini files and their tepid text templating. Doing anything sophisticated is hard if not impossible. It could be nice to be able to use a domain-specific language instead, like Shepherd does (and unfortunately requires).

          I personally would not pick Guile (a dialect of Scheme, which is a dialect of LISP). But imagine using Lua or JavaScript to write your own generator for systemd units.

          There is a good idea here.
          If the old script-based init system taught us anything, it's that managing configuration through imperative programs is a horrible idea. The notion that everything should be infinitely open, infinitely flexible and that one should be able to make it do absolutely anything is probably the single worst antipattern in the history of software engineering.

          Comment

          • emblemparade
            Senior Member
            • Jan 2014
            • 410

            #35
            Originally posted by jacob View Post
            If the old script-based init system taught us anything, it's that managing configuration through imperative programs is a horrible idea. The notion that everything should be infinitely open, infinitely flexible and that one should be able to make it do absolutely anything is probably the single worst antipattern in the history of software engineering.
            Nice speech. But how do you handle the need to, say, create (or delete) multiple systemd units based on an indirect configuration, possibly external to the machine? You can't do this with .ini files. The only automatic thing systemd does, that I know of, is handle the specific case of defining one service, as a template, per user.

            Or, you know, you can write an actual program to do it (a controller), which probably will need to be compiled. It's beyond the abilities of most users.

            For my time, I would rather have a simple DSL interpreted file that I can edit and see its changes immediately. People would be able to easily publish and consume such snippets online to solve various everyday use cases. That's much less manageable than writing a full-blown program.

            Comment

            • toves
              Senior Member
              • Sep 2021
              • 133

              #36
              Originally posted by jacob View Post

              If the old script-based init system taught us anything, it's that managing configuration through imperative programs is a horrible idea. The notion that everything should be infinitely open, infinitely flexible and that one should be able to make it do absolutely anything is probably the single worst antipattern in the history of software engineering.
              I wouldn't have though Scheme code would be classified as imperative. More functional and therefore declarative.
              (Based on my reading many years ago of Abelson and Sussman.)

              Just very difficult for non-LISPers to read it that way (or at all.) Although mother's milk to the emacs fraternity I should think.

              I imagine translating systemd unit files into this scheme framework could be entirely mechanical even at run-time.

              I mostly just tolerate systemd. It's integral to the distros I use and mostly works. Creating new service unit files doesn't strain the gray cell too much. AutoFS support is to me weird and fundamentally inelegant. Inelegance probably summarises my objection to systemd but not to the extent of replacing it with a system that vast majority can't read. Contemporary sysadmins very commonly have little or no exposure to programming in any form and struggle with simple shell (Bourne, Bash) scripts let alone scheme. It's cruel to see them trying to deal with tcl based stuff like environment module configuration files.

              Comment

              • mobadboy
                Senior Member
                • Jul 2024
                • 182

                #37
                there is no reason to define unit files as a lisp

                you keep things as simple as possible when work is multiplied

                you have dozens of such files

                keep these dozens of files as simple as possible to avoid everybody making the same mistakes

                hate systemd the service, who cares, but the unit files vastly reduce the surface area for mistakes. and humans are really good at making mistakes.

                --

                if your job is dependent upon knowing how to create The Best startup scripts and one service comes and ruins your job, then maybe it is a castle made of sand

                Comment

                • fibre
                  Junior Member
                  • Nov 2024
                  • 3

                  #38
                  Originally posted by Sonadow View Post
                  Upstart was somewhat decent back then and I am very certain would have eventually become the de facto init mechianism with many of systemd's features eventually tacked on (especially service dependency resolution) had systemd not come along.
                  Suppose you had a configurable supervisor to run your household. You configure a rule that going to the grocery store requires starting your car. Then every time you start your car it goes to the grocery store. That's Upstart. When I read the Upstart docs I thought no, that can't be. The documentation must be wrong. No one would design a supervisor to work that way. But alas, the horror was that Upstart really did work that way. I dumped Ubuntu like a load of bad chili.

                  Comment

                  • jacob
                    Senior Member
                    • Jul 2010
                    • 2973

                    #39
                    Originally posted by emblemparade View Post

                    Nice speech. But how do you handle the need to, say, create (or delete) multiple systemd units based on an indirect configuration, possibly external to the machine? You can't do this with .ini files. The only automatic thing systemd does, that I know of, is handle the specific case of defining one service, as a template, per user.

                    Or, you know, you can write an actual program to do it (a controller), which probably will need to be compiled. It's beyond the abilities of most users.

                    For my time, I would rather have a simple DSL interpreted file that I can edit and see its changes immediately. People would be able to easily publish and consume such snippets online to solve various everyday use cases. That's much less manageable than writing a full-blown program.
                    It's hard to answer without a concrete example of why you "need to, say, create (or delete) multiple systemd units based on an indirect configuration, possibly external to the machine". So from a purely general point of view, I would say this is exactly an anti-feature. More information pending, I would even go as far as to say that a well designed service manager would make sure that it is NOT possible to do that. The whole point of modern service management, and that's by no means only related to systemd, is to be as stateless as possible. Service units should be independent of any machine and of each other, except for expressly defined dependencies within the units themselves. So unless you have some extra compelling reason (and, hypothetically, the fact that it has been like that for the past 30 years but it can't easily be migrated to systemd is not a compelling reason), it seems that the use case needs revisiting and possibly redesigning.

                    Comment

                    • jacob
                      Senior Member
                      • Jul 2010
                      • 2973

                      #40
                      Originally posted by toves View Post

                      I wouldn't have though Scheme code would be classified as imperative. More functional and therefore declarative.
                      (Based on my reading many years ago of Abelson and Sussman.)

                      Just very difficult for non-LISPers to read it that way (or at all.) Although mother's milk to the emacs fraternity I should think.

                      I imagine translating systemd unit files into this scheme framework could be entirely mechanical even at run-time.

                      I mostly just tolerate systemd. It's integral to the distros I use and mostly works. Creating new service unit files doesn't strain the gray cell too much. AutoFS support is to me weird and fundamentally inelegant. Inelegance probably summarises my objection to systemd but not to the extent of replacing it with a system that vast majority can't read. Contemporary sysadmins very commonly have little or no exposure to programming in any form and struggle with simple shell (Bourne, Bash) scripts let alone scheme. It's cruel to see them trying to deal with tcl based stuff like environment module configuration files.
                      Scheme is imperative. It has set!, loop, begin etc., which are quintessential imperative features. It is also eagerly evaluated except for built-in constructs like if, meaning that the order in which sub-expressions are evaluated matters. That's another trait of imperative programming. Yes, it's not a purely imperative language like C and allows functional programming (which is not the same thing as declarative), but that doesn't make it good for configuration management. A configuration file should not be a program, regardless of the language.
                      Last edited by jacob; 09 December 2024, 11:24 PM.

                      Comment

                      Working...
                      X