Originally posted by uid313
View Post
GNU Shepherd 1.0 Service Manager Released As "Solid Tool" Alternative To systemd
Collapse
X
-
-
-
Originally posted by skeevy420 View PostCode: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
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))
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))
Code:SocketBindAllow=ipv4:22 SocketBindDeny=any
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
-
-
Originally posted by uid313 View PostI 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.
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
-
-
Originally posted by emblemparade View PostTechnically 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.
Comment
-
-
Originally posted by jacob View PostIf 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.
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
-
-
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.
(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
-
-
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
-
-
Originally posted by Sonadow View PostUpstart 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.
Comment
-
-
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.
Comment
-
-
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.Last edited by jacob; 09 December 2024, 11:24 PM.
Comment
-
Comment