5 ms·

daemontools doesn't run as pid 1 and achieves all of this. http://cr.yp.to/daemontools.html http://cr.yp.to/daemontools.html

by d0 13y ago

FooBarWidget 13y ago
It does not. Not even close. https://news.ycombinator.com/item?id=7210308 https://news.ycombinator.com/item?id=7210308
- Fasebook 13y ago
  That comment is insane. Why would log files need journaling? They should be serialized. How is adding a line to a run script "duplicating logic badly"? Coupling is clearly bad, as evidenced by ... 30+ years of software design, but is a necessary evil. I don't see any reason why it's necessary in such a low level system component. "this is not rocket science" you don't impose dependencies on something you want to be reliable. Daemontools is clearly the most mature solution, from a perspective of stability. It's probably why nobody wants to use it, there's nothing to play with or exploit for profit because it already works.
  - bitwize 13y ago
    That comment is insane. Why would log files need journaling? They should be serialized. systemd-journald provides tampering-attestation features that plain-text logs do not, and cannot, provide. It's fundamentally more secure.
    - peterwwillis 13y ago
      Fallacy: having owned the user that writes logs, I cannot fuck with your logs if journaled. Reality: if I owned the user writing logs, I can do anything I want with the logs, no matter how they're stored.
      - hdevalence 13y ago
        No, you cannot do anything you want with the logs. Here is something you cannot do: you cannot alter the logs without anyone noticing, since log entries have a rolling hash. This prevents an attacker from being able to modify logs without detection, and was implemented in systemd after the postmortem on the kernel.org breakin, i.e., it was developed to counter an actual threat. I would suggest you read up on what log attestation actually does.
        peterwwillis 13y ago
        Logs can be modified in real time by being intercepted during writes to the buffer before the new hash is applied. Because of this, only the logs up to the intrusion can be preserved, and even then if the old message/hash/key/etc is still in memory, the old messages can be modified. The only truly secure way to record messages up to the point of break-in is a one-way remote log. Any new messages after break-in is subject to falsification.
        bct 13y ago
        > The only truly secure way to record messages up to the point of break-in is a one-way remote log. And if you have this then you don't need a fancy cryptographic syslogd to detect tampering.
        peterwwillis 13y ago
        The fancy cryptologic syslogd is fallible as I mentioned previously, so why depend on it? And really if you really want to cover your tracks you can just cause random disk corruption over the whole disk (and just happen to damage the journal in the process). Things will start failing rapidly, fsck will later show itself fixing the disk corruption, and it will be assumed to be a hardware error and the incident ignored. Security half-measures do not mean you are secure. If it can be hacked, it will be hacked, and then what was the point of sacrificing your whole system's init system? (Also you could just replace syslogd with a journaled syslogd, rather than replacing your entire init system... but I guess that's off-topic?)
    - edwintorok 13y ago
      rsyslog allows you to sign your logs if you want to: http://www.rsyslog.com/how-to-sign-log-messages-through-signature-provider-guardtime/ http://www.rsyslog.com/how-to-sign-log-messages-through-sign...
gnoway 13y ago
How does svscan handle service dependencies?
- d0 13y ago
  It doesn't. That's the point. Nothing in daemontools does. Dependencies are bad.
  - deong 13y ago
    I'm not sure if you're making a point more subtle than I'm reading, but when most people in the systemd debate say "dependencies are bad", they mean that having loads of things depend on the init system is bad. The comment you're responding to is talking about dependencies in boot services, e.g., sshd depends on having the network interface up. Systemd does a great job of handling this sort of thing, allowing services to start in parallel, but ensuring that things only start after all the pieces they rely on have started. That sort of dependency isn't "bad" -- it just is. You can't remove a dependency like this, it reflects reality. That said, I really don't care for systemd. I think the complexity it adds more than counteracts the benefits it provides, but I'm old and didn't mind SysV or BSD init.
    - d0 13y ago
      I'm saying that the dependency on the network being up is bad for services. An example of a bad case: if the network interface is hotplugged or down and you're running Redis, do you want it to restart and have to drag the entire AOF file off disk just because you yanked the interface card because it was failed or failing? Your 20 second hotplug problem becomes a 15 minute block of IO coming off disk because you had to restart the process. So many problems come from such a simple dependency. Designing all services to handle and expect failures and just let init restart regardless of the state is the RIGHT solution.
aidenn0 13y ago
daemontools can't reliably monitor daemons that reparent themselves to init or kill their pgroup. I have written hacks to work around this (I have a gentoo VM that uses supervise as an openRC replacement, and have several hacks to work around this issue). It's a pain in the ass, and one reason why systemd runs in pid 1. I prefer daemontools, but it's not perfect; it made a different set of tradeoffs.

daemontools doesn't run as pid 1 and achieves all of this. http://cr.yp.to/daemontools.html http://cr.yp.to/daemontools.html

by d0 13y ago

daemontools doesn't run as pid 1 and achieves all of this. http://cr.yp.to/daemontools.html http://cr.yp.to/daemontools.html

FooBarWidget 13y ago

It does not. Not even close. https://news.ycombinator.com/item?id=7210308 https://news.ycombinator.com/item?id=7210308

Fasebook 13y ago
That comment is insane. Why would log files need journaling? They should be serialized. How is adding a line to a run script "duplicating logic badly"? Coupling is clearly bad, as evidenced by ... 30+ years of software design, but is a necessary evil. I don't see any reason why it's necessary in such a low level system component. "this is not rocket science" you don't impose dependencies on something you want to be reliable. Daemontools is clearly the most mature solution, from a perspective of stability. It's probably why nobody wants to use it, there's nothing to play with or exploit for profit because it already works.
- bitwize 13y ago
  That comment is insane. Why would log files need journaling? They should be serialized. systemd-journald provides tampering-attestation features that plain-text logs do not, and cannot, provide. It's fundamentally more secure.
  - peterwwillis 13y ago
    Fallacy: having owned the user that writes logs, I cannot fuck with your logs if journaled. Reality: if I owned the user writing logs, I can do anything I want with the logs, no matter how they're stored.
    - hdevalence 13y ago
      No, you cannot do anything you want with the logs. Here is something you cannot do: you cannot alter the logs without anyone noticing, since log entries have a rolling hash. This prevents an attacker from being able to modify logs without detection, and was implemented in systemd after the postmortem on the kernel.org breakin, i.e., it was developed to counter an actual threat. I would suggest you read up on what log attestation actually does.
      - peterwwillis 13y ago
        Logs can be modified in real time by being intercepted during writes to the buffer before the new hash is applied. Because of this, only the logs up to the intrusion can be preserved, and even then if the old message/hash/key/etc is still in memory, the old messages can be modified. The only truly secure way to record messages up to the point of break-in is a one-way remote log. Any new messages after break-in is subject to falsification.
        bct 13y ago
        > The only truly secure way to record messages up to the point of break-in is a one-way remote log. And if you have this then you don't need a fancy cryptographic syslogd to detect tampering.
        peterwwillis 13y ago
        The fancy cryptologic syslogd is fallible as I mentioned previously, so why depend on it? And really if you really want to cover your tracks you can just cause random disk corruption over the whole disk (and just happen to damage the journal in the process). Things will start failing rapidly, fsck will later show itself fixing the disk corruption, and it will be assumed to be a hardware error and the incident ignored. Security half-measures do not mean you are secure. If it can be hacked, it will be hacked, and then what was the point of sacrificing your whole system's init system? (Also you could just replace syslogd with a journaled syslogd, rather than replacing your entire init system... but I guess that's off-topic?)
  - edwintorok 13y ago
    rsyslog allows you to sign your logs if you want to: http://www.rsyslog.com/how-to-sign-log-messages-through-signature-provider-guardtime/ http://www.rsyslog.com/how-to-sign-log-messages-through-sign...

gnoway 13y ago

How does svscan handle service dependencies?

d0 13y ago
It doesn't. That's the point. Nothing in daemontools does. Dependencies are bad.
- deong 13y ago
  I'm not sure if you're making a point more subtle than I'm reading, but when most people in the systemd debate say "dependencies are bad", they mean that having loads of things depend on the init system is bad. The comment you're responding to is talking about dependencies in boot services, e.g., sshd depends on having the network interface up. Systemd does a great job of handling this sort of thing, allowing services to start in parallel, but ensuring that things only start after all the pieces they rely on have started. That sort of dependency isn't "bad" -- it just is. You can't remove a dependency like this, it reflects reality. That said, I really don't care for systemd. I think the complexity it adds more than counteracts the benefits it provides, but I'm old and didn't mind SysV or BSD init.
  - d0 13y ago
    I'm saying that the dependency on the network being up is bad for services. An example of a bad case: if the network interface is hotplugged or down and you're running Redis, do you want it to restart and have to drag the entire AOF file off disk just because you yanked the interface card because it was failed or failing? Your 20 second hotplug problem becomes a 15 minute block of IO coming off disk because you had to restart the process. So many problems come from such a simple dependency. Designing all services to handle and expect failures and just let init restart regardless of the state is the RIGHT solution.

aidenn0 13y ago

daemontools can't reliably monitor daemons that reparent themselves to init or kill their pgroup. I have written hacks to work around this (I have a gentoo VM that uses supervise as an openRC replacement, and have several hacks to work around this issue). It's a pain in the ass, and one reason why systemd runs in pid 1. I prefer daemontools, but it's not perfect; it made a different set of tradeoffs.