previously on this list Zbigniew Jędrzejewski-Szmek contributed: > Hi Helmut, > "exec" vs. "ExecStart=" and "export" vs. "Environment=" is easy. > Anyone can whip up a sed script to convert between those. The question > is how to deal with more advanced options. Let's say that I have a > systemd unit with > > CapabilityBoundingSet=CAP_SYS_TIME # limit the capability bounding set to > CAP_SYS_TIME > PrivateTmp=yes # run with unshared /tmp > InaccessibleDirectories=/home # run without access to /home > WatchdogSec=60 # consider the service dead if it > hasn't pinged the > # manager for in the last minute > Restart=on-failure # restart service on watchdog failure > or unclean exit > > This isn't a question of syntax, it's a question of significant > functionality in the manager. I think that sharing service > descriptions between disparate init managers is infeasible, unless we > forbid the use of anything but the basic features. >
Couldn't they just be ignored not to mention already having existing or far more functional and robust *options* that work with any init system. Even SElinux has people wanting to use RSBAC or grsecurities RBAC because they have a better security record due to more secure architectures and rules. and on another matter I personally much prefer a setcap (again or other options like RBAC) shell line to CapabilityBoundingSet=CAP_SYS_TIME > Another thing that is turning into a significant gap is socket > activation. In systemd, socket activation allows the service to > receive multiple open sockets (e.g. ports 80 and 443 for an httpd > server). Socket activation of daemons is cool: No it isn't and has been argued over not long ago, so as I have been requested to and am now trying (even harder) it would be good if we could keep the S/N ratio down. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd _______________________________________________________________________ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527896.83523...@smtp118.mail.ir2.yahoo.com
