znc.service.in only works with ~/.znc #627
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/znc#627
Reference in new issue
Block a user
...which will fail on all systems where znc USER has its HOME set to /dev/null. of course one could override this with /etc/systemd/system/znc.service/override.conf but that's a just a workaround. that is "works out of box" for systemd is broken.
I believe
znc.service.inis intended to be used by people who compile ZNC and create accounts etc. by themselves.Debian-based distributions simply don't include the file and only Gentoo users seem to have issues (which result in ping-ponging users between #gentoo and #znc as happened a few weeks/months ago).
that's an argument for it being broken.
archlinux in fact uses znc.service.in and users have to do ridiculous things like:
usermod -s /bin/sh znc
before proceeding with configuration; fedora and debian have given up on it all together and provide their own service file and so on.
you on the other hand have installed znc under ~/.local/bin with znc having /home/znc as its HOME and probably think that's just genius but could please just leave this issue alone and enjoy your own phenomenal system?
based on this I suggest you to read the documentation.
$HOME/.local/is recommended as not-root install location and if I did global installation, I would have to give root access to not-entirely-closed-out-future-ZNC-admins just so they could upgrade ZNC without me being there.right, we are talking about global installation; your personal setting doesn't apply here.
When you install to
$HOME/.local, znc.service reflects that by changing@bindir@to/home/<user>/.local/bin/znc.In case you need more accurate link:
On Thu, Oct 22, 2015 at 08:35:41PM -0700, Mikaela Suomalainen wrote:
no, that's only you who installs under ~/.local. and in any events for that
case it works. in fact so says the title of this ticket; read it again; now give
it minute... how are we doing? not yet? well take a deep breath; repeat. and
please get off this topic; why does this bother you so much. apparently it works
just fine for you. that should be good news, no? this is for cases where
znc.service.in does cover (or is not general enough for). again this issue
doesn't apply to you... so, find something else to do and goodbye.
So... we should remove
znc.systemd.inagain, I guess, because there is no way for this file to be useful to the general public. Anyone who wants to use znc needs to configure it somehow and this systemd service doesn't provide any obvious/sane way to set up the config.@nbebout Does Fedora use this file? If so, how?
2015-10-23 8:29 GMT+01:00 Uli Schlachter notifications@github.com:
There is also clone of that service at http://wiki.znc.in/Running_ZNC_as_a_system_daemon#Create_the_systemd_script with a little more instructions. I will change it a little as it seems to be missing some essential information:
Edit: Issues fixed: http://wiki.znc.in/Running_ZNC_as_a_system_daemon#systemd
what is wrong with shipping a default setting under /etc ? passing that config file to znc in znc.service could be a start (just an idea).
however this is where things are headed as far as systemd is concerned:
http://0pointer.net/blog/projects/stateless.html
"In the long run we hope that packages can be fixed so that they always work correctly without configuration in /etc. Depending on the software this means that they should come with compiled-in defaults that just work should their configuration file be missing, or that they should fall back to static vendor-supplied configuration in /usr that is used whenever /etc doesn't have any configuration. Both the PAM and the D-Bus case are probably candidates for the latter. Given that there are probably many cases like this we are working with a number of folks to introduce a new directory called /usr/share/etc (name is not settled yet) to major distributions, that always contain the full, original, vendor-supplied configuration of all packages. This is very useful here, so that there's an obvious place to copy the original configuration from, but it is also useful completely independently as this provides administrators with an easy place to diff their own configuration in /etc against to see what local changes are in place."
Well, znc provides no services to the local system, but only to the network. So a static config would mean e.g. a login of "root" and "password". That's obviously a bad idea, because then everyone can log in (just as its bad for MySQL to have default logins...).
Edit: The only things that ZNC really needs is a port to listen on (we can easily provide a default here) and a valid login (nope, no default).
Also, having ZNC only reachable from localhost but then with a default login is likely a bad idea, too.
On Fri, Oct 23, 2015 at 06:22:19AM -0700, Uli Schlachter wrote:
no it doesn't. you do have a default USER; znc.
No, ZNC doesn't create any default user. That's up to the distro (and to
the human user)
2015-10-23 15:21 GMT+01:00 jrun notifications@github.com:
On Fri, Oct 23, 2015 at 07:33:07AM -0700, Alexey Sokolov wrote:
look into znc.service.in:
User = znc
On Fri, Oct 23, 2015 at 07:33:07AM -0700, Alexey Sokolov wrote:
not technically; true. it's what package managers do... but there is an implicit
assumption that znc user will be created on the system.
If and only if the znc.service file is installed. That 'znc.service.in' file doesn't get installed when you build/install ZNC from source, nor does it do that for a lot of the package managers (which don't ship ZNC as a service). You're grasping at straws which aren't issues at this point. The only implicit assumption is if you are reading this 'included service file' which may exist in the repository but it is not installed by the
makeormake installsteps. It's included as an 'example', yes, but the example on its own does not make any implicit assumption. (I read all.infiles typically as included examples, not actual for-use service files unless you know more about what you're doing, really.)On Fri, Oct 23, 2015 at 07:59:47AM -0700, Thomas Ward wrote:
sure, znc.service.in is just for illustration purposes; now how about shipping
one that's actually useful should distros downstream decide to use it. mind you
that some distros downstream do use znc.service.in. some, seems to me, have
given up and write their own.
@257 What would a useful example look like? Which distros have useful examples?
The only thing that comes to my mind is adding
--datadir /etc/zncto the command line, but that makes it IMO just harder to use this (users have to guess that they have to runsudo znc --datadir /etc/znc --makeconf). And something likeConditionPathIsDirectory=/etc/zncmay make it more obvious that a config has to be created first, but still doesn't provide any hint on how to do that. (OrAssertPathIsDirectory?)It should be /var/lib/znc instead of /etc/znc, according to
https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
2015-10-24 9:30 GMT+01:00 Uli Schlachter notifications@github.com:
--datadir /etc/znc/would next bring issues that:/etc/znc/modulesdoesn't belong to /etcI think systemd units allow comments starting with
#so that could be used as a solution to this issue.Random idea: Use
znc --datadir %iin the systemd unit.%iis the instance name and so the user is "forced" to provide the datadir. They would then have to do something likesystemctl enable znc@/etc/zncto use this. Of course, the problem of "how is this documented in a useful fashion"?@psychon did you see #1166? I am wondering if it's OK or if I should implement your idea.
@DarthGandalf didn't express opinion at IRC when asked (unless the opinion was that it also was offtopic for #znc-dev which didn't help).
I saw #1166 and don't have any opinion on it. Also, abusing %i like this might count as ugly....
It was just an idea. I don't even know if it works.
This is probably the point where I ask for any better ideas? 😄
On Tue, Nov 10, 2015 at 09:12:45AM -0800, Uli Schlachter wrote:
it does work but yes it's ugly.
Should I create a new issue "znc.service.in only works with /var/lib/znc"?
As it was previously, it worked just fine, including automatic creation of users.
Regardless of how the user is created, the home folder is "/var/lib/znc" (or anything else), then ZNC can just write to "/var/lib/znc/.znc" and that's totally fine.
As it is now, the behavior is indeed hardcoded and wrong and is going to break people's setups.
Urgh.
If no packager comments anything about this, I'll remove this file from the repo again, as in
0a049664fb@nbebout @Philantrop (anyone else uses it? @seblu @Barthalion @TingPing)
With 1.6.1 the service file was working great. It is used in official Arch Linux package without any modifications.
https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/znc
As @BlaXpirit says, we're using it as is (I think one of points for single init in many distributions is using the same service, isn't it?). Our package creates a znc user with /var/lib/znc home.
…and looking at current version of the service in git, it is incompatible with previous behavior. Usage of --datadir looks good to me though, so we will just handle it on package side.
@Barthalion ok, thanks...
If you guys (packagers) all agree on how this file should look like, I'm fine with it too.
I think there were two wrong move with the
znc.servicerecently.network-online.targetbutnetwork.target. znc does require network stack to be setup, not to be configured. It starts and connects to irc servers when each network paths become available, no need to depend on something else.~/.znc).I don't understand the rational behind this bug report. The
~/.zncis the default datadir, if it's not good, that's not the systemd unit which have to be changed. Moreover, the previous systemd service file worked out of the box when a properly znc user is setup. The point about thechmodin Arch Linux is completly irrevelent.Maybe there is one upstream systemd file missing to create the znc user which can be added.
@DarthGandalf So my reading is to revert commits
43f2253f2dand28f7f57666and close this bug report as wont fix.Nonetheless, there is no problem managing the unit downstream, I already added a systemd specific file to create the znc user, but as @Barthalion says, it would be better if systemd files go in znc tree.
On Sun, Nov 15, 2015 at 04:54:07PM -0800, Sébastien Luttringer wrote:
that's the implication behind this bug. the way config file location is
handled is just, well, different? that's where the real problem is. it
doesn't lend itself to generalisation if like.
@DarthGandalf: I completely agree with @seblu's comment here. Things were correct before and those two commits he referenced should be reverted.
This bug is invalid; the distro used by @257 needs to properly set up the ZNC user.
We're coming from the bad old times where every distro did things differently and admins had to memorise how things were done for each of them. Nowadays, we're standardising things - starting with service files, configuration file locations, etc.
Let's not make this more complicated because one person or distro gets it wrong.
Except if configuration of a listener limits it to some specific host. Listening on 127.0.0.1 and on 0.0.0.0 probably doesn't need network to be configured, but listening on something more explicitly external (e.g. 198.51.100.20 or 2001:db8:12::a2) needs it, I think... At least until #431 is fixed (see also #617)
I don't see how single
znc.servicefile can support both cases (listening on everything withnetwork.targetvs listening on some specific host withnetwork-online.target), as listeners are configured at runtime and stored inznc.conf. Does systemd (or any other init) support querying a program for its current dependencies based on its configuration?How does ZNC connect to networks with network stack up, but without it having external connectivity? I believe majority of ZNC users use it to connect to not-localhost networks.
On Tue, Nov 10, 2015 at 06:35:24AM -0800, Uli Schlachter wrote:
%f seems more suited for this; 'man systemd.unit'
so for:
znc --datadir %f
one does 'systemctl enable znc@etc/znc'
or even this might work if znc is specified as the user running the daemon:
znc --datadir %f/%u
'systemctl enable znc@etc'
or
'systemctl enable znc@var/lib'
@DarthGandalf If we look what is done elsewhere, almost all units are scheduled after
network.targetand don't usenetwork-online.target. In particular, nginx, apache, postgres are servers which listen on network like znc and don't pullnetwork-online.target.The best way to manage this, is from the developer point of view. He has to make his software support dynamic IP. Either using IP_FREEBIND socket option, either watching rtnetlink (more complex).
The other way is a system configuration, which doesn't require software to be dynamic. The network manager ensure network is fully setup before reaching
network.target. This is done by enabling wait online units from your network manager.Examples:
I think the rational behind that is the few number of configurations using IP in binding. Instead of slow down all servers startup, when the admin needs to do that, he has to force network to be fully online.
@257 Service instances are used to run multiple instance of the same service at the same time. Not to configure a path.
It's expected to be done either by
EnvironmentFile=-/etc/default/xxxdirective. (old way)On Mon, Nov 23, 2015 at 09:40:10AM -0800, Sébastien Luttringer wrote:
don't think so; have a look at these two units:
system/systemd-fsck@.service
system/systemd-hibernate-resume@.service
and like i mentioned, have a look at systemd.unit manual:
"%f"
Unescaped filename
This is either the unescaped instance name (if applicable) with / prepended
(if applicable), or the prefix name
As far as I am aware, these services don't usually connect to other hosts unless working as reverse proxy and on postgres I am not fully sure (I have faint idea of it being a database server).
I repeat https://github.com/znc/znc/issues/1165#issuecomment-156969539: How does ZNC connect to networks with network stack up, but without it having external connectivity? I believe majority of ZNC users use it to connect to not-localhost networks.
@Mikaela ZNC will try to connect until network is finally fully up. No need to delay startup though.
On Mon, Nov 23, 2015 at 01:06:39PM -0500, 257 wrote:
yep, works just fine here. in fact those ugly forward slashes get
translated to hyphen:
. znc@var-lib.service - ZNC, an advanced IRC bouncer
Loaded: loaded (/etc/systemd/system/znc@.service; disabled; vendor preset: enabled)
Active: active (running) since Tue 2015-11-24 13:12:57 EST; 2min 16s ago
Main PID: 710 (znc)
CGroup: /system.slice/system-znc.slice/znc@var-lib.service
└─710 /usr/bin/znc -D -d /var/lib/znc
znc@.service:
[Unit]
Description=ZNC, an advanced IRC bouncer
After=network.target
[Service]
User=znc
ExecStart=/usr/bin/znc -f -d %f/%u
[Install]
WantedBy=multi-user.target
ran this:
systemctl enable znc@var/lib.service
of course you could also do:
systemctl enable znc@etc.service
given /etc/znc exist etc. next, look into tmpfiles.d(5) and RTFA i posted
early on about 'where things are headed'.
@257: Yes, it works and it's still wrong and abuse.