<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Feb 11, 2017 at 7:41 AM, Oliver Grawert <span dir="ltr"><<a href="mailto:ogra@ubuntu.com" target="_blank">ogra@ubuntu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">hi,<br>
<span class="m_3128973579117012799gmail-">On Fr, 2017-02-10 at 09:04 -0500, Peter Silva wrote:<br>
><br>
> Hi folks, wondering if people could direct me to a good place to ask<br>
> this question. It isn't really a user question, but ... anyways. I<br>
> work on a package that can run either under a dedicated user, as a<br>
> sort of daemon or server mode, or it can be used by ordinary users<br>
> directly in client mode (connecting to daemons elsewhere.)<br>
><br>
</span>there are plenty of ways to achieve that :)<br>
<span class="m_3128973579117012799gmail-"><br>
> When I install the package, on older releases, there is /etc/default<br>
> and I put a file there to ensure it is disabled by default. That's<br>
> fine.<br>
</span>you could use a wrapper script for starting your daemon that first<br>
checks /etc/default ...<br></blockquote><div><br></div><div><br></div><div><div>It is a practical suggestion and should work, but I wonder if the systemd gods somewhere will say *You're doing it wrong*.</div><div><br></div></div><div>Reading through systemd information, and through bitter experience, I know most systemd services completely ignore /etc/default, so it would be *surprising* for admins on a systemd system if one service was actually using them:</div><div><br></div><div>As far as I can tell /etc/default is only supposed to be used by upstart or init files, and can be referenced as a crutch by systemd, but it isn't correct to build a systemd service that uses it.</div><div><br></div><div>On the subject of a wrapper script... The obvious thing is to just point at the /etc/init script I already provide, but then it feels like I'm not doing it the *systemd* way. I end up with systemd stuff that explicitly invokes sysv stuff. </div><div><br></div><div>example of surprise:</div><div><br></div><div>systemctl enable foo<br></div><div><br></div><div>won't work, as people will need to modify /etc/default/foo as well as enable, and folks will complain that it isn't properly in systemd.</div><div><br></div><div>Some to think of it, I think I could just skip the systemd.service entirely then, and systemd's compatibility stuff could just pick up the init stuff. Still ugly.</div><div><br></div><div>So I'm looking for the systemd-ish way to do it right.</div><div><br></div><div>etc...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="m_3128973579117012799gmail-">><br>
> in systemd, I use the documented stuff in dh_ and it puts the service<br>
> file in the right place.<br>
<br>
</span>you could not use debhelper (which is responsible for enabling the<br>
service by default) but just install the service file to <br>
/lib/systemd/system/ from the debian/install file, not using the<br>
debhelper functions ...<br>
<br>
then it should not be started by default and you have to manually do<br>
"systemctl enable <service>"<br>
<span class="m_3128973579117012799gmail-"><br></span></blockquote><div><br></div><div>OK, but I'm using debuild, and the packages get built by launchpad, for me to stick a raw 'cp' in there, especially when installing on 14.04 (no systemd) seems likely to break somewhere. </div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_3128973579117012799gmail-">
><br>
> Two issues:<br>
> -- when I do systemctl status sarra ... it says: 'vendor preset:<br>
> enabled') I want it to be disabled by default. Couldn't find that.<br>
><br>
> -- I don't want to create the daemon user on systems where<br>
> it will only be used as a client, so in many cases the 'user'<br>
> specified in the service file will not exist. How to cleanly handle<br>
> that?<br>
><br>
</span>you would use a debconf question asking the admin if he wants the user<br>
created ...<br>
<br></blockquote><div><br></div><div>hmm... need to think about that... when installations are automated people are stuck specifying default answers... I would think If I'm going to ask a question it would be something like:</div><div><br></div><div>'client only mode (no server, no sarra user created)?'</div><div><br></div><div>so *no* would ensure the user exists... (the less common case) and *yes* would be the normal client mode... (the most common case) Does that sound correct?</div><div><br></div><div><br></div><div>thanks for the suggestions! not sure we're there yet...</div><div><br></div></div></div></div>