[opensuse] systemd: creation of tmpfiles, owned by net-wide user
Hi, I got a service, actually a Tomcat 5, that runs under a network-wide user/group id, i.e., one that's supplied by NIS (LDAP would be the same story). This service wants to store PID files somewhere. I want to use /run/tomcat5/ for that. This directory must be owned by the server's run user id. I can't create this directory via /etc/tmpfiles.d: systemd-tmpfiles-setup.service must not depend on ypbind.service, this would result in a dependency deadlock. Is there an "official" method to assert the existence of a directory in a systemd service unit definition, with appropriate create actions to be done when a service is started? I could use ExecStart and supply a script, to be executed with root rights; but I hope that the demands of using network-supplied resources is more widespread and thus predefined solutions exist. -- But, I haven't found them in man pages of systemd.unit and systemd.service. Cheers, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jschrod@acm.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Joachim Schrod said the following on 04/22/2013 07:57 PM:
Hi,
I got a service, actually a Tomcat 5, that runs under a network-wide user/group id, i.e., one that's supplied by NIS (LDAP would be the same story). This service wants to store PID files somewhere. I want to use /run/tomcat5/ for that. This directory must be owned by the server's run user id.
I can't create this directory via /etc/tmpfiles.d: systemd-tmpfiles-setup.service must not depend on ypbind.service, this would result in a dependency deadlock.
Is there an "official" method to assert the existence of a directory in a systemd service unit definition, with appropriate create actions to be done when a service is started? I could use ExecStart and supply a script, to be executed with root rights; but I hope that the demands of using network-supplied resources is more widespread and thus predefined solutions exist. -- But, I haven't found them in man pages of systemd.unit and systemd.service.
Maybe, just maybe ... Have that directory created anyway. Don't worry about making systemd-tmpfiles-setup.service must not depend on ypbind.service at this stage. By the time you get to start Tomcat the ypbind has started, right? At this point you have a number of options. There are a few ways you can use ExecStartPre The "Pre" means ... well that should be obvious. Run a grep on the directory with all the service files and find a few examples. Some, like dbus.service, have multiple "ExecStartPre" lines. I see quite a few "kill" and "rm"; I don't see why you can't do a 'chown'. Of course you could do the directory create there, but my personal inclination is that all the directories under /run should be managed from one and only point. There are also ways you can use dbus to do nifty things ... -- To avoid criticism do nothing, say nothing, be nothing. Elbert Hubbard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Joachim Schrod said the following on 04/22/2013 07:57 PM:
Hi,
I got a service, actually a Tomcat 5, that runs under a network-wide user/group id, i.e., one that's supplied by NIS (LDAP would be the same story). This service wants to store PID files somewhere. I want to use /run/tomcat5/ for that. This directory must be owned by the server's run user id.
I can't create this directory via /etc/tmpfiles.d: systemd-tmpfiles-setup.service must not depend on ypbind.service, this would result in a dependency deadlock.
Is there an "official" method to assert the existence of a directory in a systemd service unit definition, with appropriate create actions to be done when a service is started? I could use ExecStart and supply a script, to be executed with root rights; but I hope that the demands of using network-supplied resources is more widespread and thus predefined solutions exist. -- But, I haven't found them in man pages of systemd.unit and systemd.service.
Maybe, just maybe ...
Have that directory created anyway. Don't worry about making systemd-tmpfiles-setup.service must not depend on ypbind.service at this stage.
By the time you get to start Tomcat the ypbind has started, right? At this point you have a number of options. There are a few ways you can use ExecStartPre The "Pre" means ... well that should be obvious. Run a grep on the directory with all the service files and find a few examples. Some, like dbus.service, have multiple "ExecStartPre" lines.
I see quite a few "kill" and "rm"; I don't see why you can't do a 'chown'.
Of course you could do the directory create there, but my personal inclination is that all the directories under /run should be managed from one and only point.
That was my first reaction, too. But, OTH, if I have a distribution-specific systemd unit definition, what's the difference between an chown and a script that does both mkdir and chown? In maintenance terms, it's cheaper. There's one place where the action's on; not two -- like with an tmpfiles.d file and a ExecStartPre fcommand -- and that's better for new staff to comprehend the whole thing. That's just like over-engineered but never-used interfaces, a.k.a. pre-matural optimization. In my company, I try to establish a culture that establishs a balance between agile "don't do any design or interfaces" and traditional "use interfaces every where under all circumstances". (Tounge in cheek; most people don't have that reaction in a pure way.) Since these are site-specific unit definitions anyhow (customer doesn't want to pay for the upgrade to Servlet 2.5 architecture, even though it's urgent from a security point of view); I'll probably go for the mkdir+chown in ExecStartPre approach. Thanks a lot for your anser, it helped to clear my mind about the services at hand, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jschrod@acm.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Joachim Schrod said the following on 04/24/2013 08:03 PM:
But, OTH, if I have a distribution-specific systemd unit definition, what's the difference between an chown and a script that does both mkdir and chown?
A big difference. First you have to write the script. Second you have to set up the .service to create a shell to execute it. Using the tow "Pre" avoids both of those. Systemd execs the commands directly, not via a shell. That's why the address of the executables has to be fully specified as the man page says.
In maintenance terms, it's cheaper.
I disagree. Where is the script going to live? Where is the documentation for it going to be? -- If we believe absurdities, we shall commit atrocities. -- Voltaire -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Joachim Schrod said the following on 04/24/2013 08:03 PM:
But, OTH, if I have a distribution-specific systemd unit definition, what's the difference between an chown and a script that does both mkdir and chown?
A big difference. First you have to write the script. Second you have to set up the .service to create a shell to execute it.
I wouldn't consider both to be a hazzle. We're talking about a script with 2-3 lines here. And an additional call to a shell won't bother me at all -- you'll have to look at the stuff a Java application server is doing at startup to realize that this would be premature optimization.
Using the tow "Pre" avoids both of those.
Ooops, totally black hole of mine. Thanks; didn't get that you meant to propose putting both commands (mkdir and chown) in the service file. That's better from a maintenance point of view; I'll use that.
In maintenance terms, it's cheaper.
I disagree.
Where is the script going to live? Where is the documentation for it going to be?
Sorry, but I have to note that -- while I follow your recommendation, it's not due to these reasons. -- Where the script is going to live? Well that would be easy: -- Development phase: At the source repository that has the systemd service definition, too. We need to control and manage files that are external to the software distribution anyhow, one more wouldn't matter from a management perspective. -- Deployment phase: In /opt, where the Tomcat server lives. (Installation managed by Puppet, FWIW.) Thus, not a problem at all. -- Its documentation? Inline, as POD. As with all our scripts, man pages on the cheap. Thanks <insert your favorite deity> for ": <<'=cut'" :-) What convinced me to follow your recommendation was not these two (non-)issues -- but the ability to have one file less in general, a file that doesn't bring any abstraction to the table. That's a clear modularization and thus maintenance advantage. Cheers and thanks for the hint, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jschrod@acm.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (2)
-
Anton Aylward
-
Joachim Schrod