5 ms·
Can you post your 10 lines for us to see?
by hoodoof 11y ago
Can you post your 10 lines for us to see?
- rsync 11y agoYes, please - genuinely interested.
- nailer 11y agoSure. [Unit] Description=Blah app [Service] ExecStart=/var/www/blah/bin/www Restart=always User=nobody Group=nobody Environment=PATH=/usr/bin:/usr/local/bin Environment=NODE_ENV=production WorkingDirectory=/var/www/blah [Install] WantedBy=multi-user.target
- heinrich5991 11y agoStarting as nobody is probably not a good idea if you have more than one service which does that. They'll be able to interact.
- hoodoof 11y agoCould you please explain in more details the issues here and the right way to do it?
- vacri 11y agoWith two applications running under the same user, if one is compromised, it has ready access to the other. Generally it's fairly easy to make a system user for an application if no special accesses are required - just make a custom system user for the application, and ensure it can access the various things it needs to touch (eg: logging).
- JdeBP 11y ago... and if you want to learn more than has been already said, start with the famous design of qmail as a collection of mutually untrusting daemons that run under individual unprivileged user accounts, precisely to insulate each from the others using the normal operating system mechanisms that insulate one user's processes, files, directories, and so forth from another's. A good question to ask yourself: "Presume that my daemon is compromised by an attacker ... * ... what processes can it trace, debug, read/write the memory spaces and environments of, or send signals to?" * ... what files, devices, and directories can it read and write?" * ... what files, devices, and directories does it own, and can thus grant access to?" Then ask: "How does the answer change if instead of all of my daemons running as the same (even if unprivileged) user they each run as different users, some (where appropriate) having no write access to anything and owning no files nor directories at all?"
- schmichael 11y agoBeautiful! It's not even the number of lines that matters -- because start-stop-daemon could probably accomplish all of that in "1" gigantic line. It's the fact that it's incredibly readable. Someone with only a passing knowledge of UNIX and no knowledge of systemd could understand almost everything in this file at a glance.
- semi-extrinsic 11y agoI can't say I agree. Does Restart=always mean the service is restarted if it is killed? Or something else? Why is there a block named [Install]? Why would my service file need to be installed? What is multi-user.wants? How do I know that this sorta-kinda-but-not-really corresponds to Runlevel 5?
- JdeBP 11y agoHowever, the reverse view raises similar questions. How do you know what runlevel 5 is? (Hint: Someone with "a passing knowledge of Unix" knows that there's no coherent definition of run level 5. It's "power the system off" on some Unices, for example. Someone without a passing knowledge of Unix is probably at a complete loss as to what "level 5" could be.) In actual fact, the multi-user boot versus single-user boot notion goes back to pretty much the beginning (https://news.ycombinator.com/item?id=10207674 https://news.ycombinator.com/item?id=10207674), and the name "multi-user" is not exactly difficult to cope with if one has a Unix background. It's not novel or a systemd-ism. It's been a Solaris SMF milestone name for over a decade. It was a concept used in the 4.1 Berkeley Distribution manual for init(8) in 1981.
- simoncion 11y ago> ...the name "multi-user" is not exactly difficult to cope with if one has a Unix background. It's not novel or a systemd-ism. Sure, but I had to do a bit of reading to understand that [Install] WantedBy=multi-user.target meant: "This service should start in the runlevel called 'multi-user'". It also seems... backwards to put runlevel membership in a service definition file. Runlevels are an administratively controlled thing. Does systemd have two or more places a given service's runlevel membership can be specified, or is the only way to change a service's runlevel in its service definition file? Yes, I know that the notion of "runlevels" is probably "legacy". However, assume that -on my OpenRC system- I have two particular runlevels, one for regular multi-user operation, and one for operation when I connect to hostile networks. Transitioning to this second runlevel shuts down all services that listen on anything other than localhost. Transitioning back brings those services back up. Although this situation is a little contrived, this sort of flexibility is valuable.
- hoodoof 11y agoLooks very similar to supervisor.conf
- Spidler 11y agoI'm not the same author, but I run several Webapps in systemd units, with the below service for all of them: Note the @ in the name, that means I reuse it as webapp@api.domain.name webapp@frontend.domain.name and so on. ----8<---- webapp@.service ---->8---- [Unit] Description=%i webapp [Service] User=%i Group=%i # Note that the first argument of the command line (i.e. the program to execute) # may not include % specifiers. ExecStart=/srv/webapp %i WorkingDirectory=/srv/%i/ PrivateTmp=true Type=simple Restart=always RestartSec=2s [Install] WantedBy=multi-user.target ---- 8< ---- /srv/webapp is a simple script that will do "exec $1/webapp" which is the actual executable.
- simoncion 11y ago> /srv/webapp is a simple script that will do "exec $1/webapp" I'm not trying to start a fight. Why do you call out to a script, rather than having systemd make the call on its own?
- JdeBP 11y agoIt's for the same reason that java has to be invoked as /usr/bin/env $JAVA_HOME/bin/java thus raising questions such as http://unix.stackexchange.com/questions/229523/ http://unix.stackexchange.com/questions/229523/ . systemd does not permit variable expansions or unit parameters in the first word of ExecStart.