Bug#924422: update to 1.9.1
Package: unbound Version: 1.9.0-2 Update to upstream release 1.9.1 to address some issues in OOOR, QNAME minimization and more. upstream announcement and changelog: https://nlnetlabs.nl/pipermail/unbound-users/2019-March/011415.html
Bug#791393: closed by Peter Palfrader <wea...@debian.org> (Bug#791393: fixed in tor 0.2.7.4-rc-1)
Thanks for implementing this! There are two typos in tor-instance-create.8.txt: 18,19c18,19 < daemon. This can be useful if you want to run multiple relays or brdige < relays on a single system, of if you want to provide a hidden service in --- > daemon. This can be useful if you want to run multiple relays or bridge > relays on a single system, or if you want to provide a hidden service in
Bug#791393: add multi-instance systemd unit file
Package: tor
Severity: wishlist
For users or relay operators that run multiple tor instances on a
single host a multi-instance systemd service file is handy.
I'm using a similar systemd unit file in my ansible-relayor configuration:
https://github.com/nusenu/ansible-relayor/blob/master/templates/debian_tor%40.service
Fedora also ships a similar systemd unit file since tor 0.2.6.8:
https://bugzilla.redhat.com/show_bug.cgi?id=1210837
When updating the tor package, all tor instances should be restarted.
here it is (I removed some of systemd's hardening feature from this
version due to #787758)
[Unit]
Description = Anonymizing overlay network for TCP
After = syslog.target network.target nss-lookup.target
[Service]
Type = simple
ExecStartPre = /usr/bin/tor -f /etc/tor/enabled/%i.torrc --verify-config
ExecStart = /usr/bin/tor -f /etc/tor/enabled/%i.torrc --runasdaemon 0
ExecReload = /bin/kill -HUP ${MAINPID}
KillSignal = SIGINT
TimeoutSec = 30
Restart = on-failure
LimitNOFILE = 32768
## Hardening
PrivateTmp = yes
PrivateDevices = yes
ProtectHome = yes
ProtectSystem = full
NoNewPrivileges = yes
CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE
PermissionsStartOnly=yes
[Install]
WantedBy = multi-user.target
signature.asc
Description: OpenPGP digital signature
Bug#787758: 'Failed at step NAMESPACE spawning' when using ReadOnlyDirectories in multi-instance service file
Do you maybe have anything installed on your upgraded system which might interfere with systemd, like cgmanager, lxc, cgroup-bin etc. upgraded-system# dpkg -l cgmanager lxc cgroup-bin dpkg-query: no packages found matching cgmanager dpkg-query: no packages found matching lxc dpkg-query: no packages found matching cgroup-bin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787758: 'Failed at step NAMESPACE spawning' when using ReadOnlyDirectories in multi-instance service file
Can you find out what is different between the upgraded and fresh Debian
installation?
systemd version is on both (fresh and upgraded) systems 215-17, what
else should I check?
Can you post the complete service file you are using, please?
working service file
(to make it fail on upgraded systems, enable the 4 commented-out Read*
lines):
[Unit]
Description = Anonymizing overlay network for TCP
After = syslog.target network.target nss-lookup.target
[Service]
Type = simple
ExecStartPre = /usr/bin/tor -f /etc/tor/enabled/%i.torrc --verify-config
ExecStart = /usr/bin/tor -f /etc/tor/enabled/%i.torrc --runasdaemon 0
ExecReload = /bin/kill -HUP ${MAINPID}
KillSignal = SIGINT
TimeoutSec = 30
Restart = on-failure
#WatchdogSec = 1m
LimitNOFILE = 32768
## Hardening
PrivateTmp = yes
PrivateDevices = yes
ProtectHome = yes
ProtectSystem = full
#ReadOnlyDirectories = /
#ReadWriteDirectories = /var/lib/tor
#ReadWriteDirectories = /var/log/tor
#ReadWriteDirectories = /var/run/tor
NoNewPrivileges = yes
CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE
PermissionsStartOnly=yes
AppArmorProfile=-system_tor
[Install]
WantedBy = multi-user.target
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787758: 'Failed at step NAMESPACE spawning' when using ReadOnlyDirectories in multi-instance service file
systemd version is on both (fresh and upgraded) systems 215-17, what else should I check? Eg. diff the list if installed packages you get via dpkg --get-selections and look for suspicouos diffs. The upgraded system has sysvinit installed, the fresh one doesn't. Both have systemd-sysv. kernel matches; 3.16.0-4-amd64: 3.16.7-ckt9-3~deb8u1 Local modifications, like custom fstab entries which override cgroupfs settings, stuff like that. fstab looks common (no special changes) Can you provide steps how to reproduce the problem Ok, I'll try to install a VM with an old debian - upgrade - test -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787758: 'Failed at step NAMESPACE spawning' when using ReadOnlyDirectories in multi-instance service file
Package: systemd Version: 215-17 when using a multi-instance systemd service file with ReadOnlyDirectories the service fails if it is attempted to start on a Debian 8 system that has been upgraded from a previous release. Error message is: Failed at step NAMESPACE spawning /usr/bin/tor: No such file or directory service: main process exited, code=exited, status=226/NAMESPACE The same config works on a fresh Debian 8 installation. This problem has been discussed on systemd-devel [2], but since this appears to be debian (upgrade) specific I'm filing this here. [1] https://github.com/nusenu/ansible-relayor/commit/4f6283e6d993e6f81a632007c823797253feee38 Note in upstream bugtracker: https://bugs.freedesktop.org/show_bug.cgi?id=89875#c2 [2] http://lists.freedesktop.org/archives/systemd-devel/2015-April/031377.html http://lists.freedesktop.org/archives/systemd-devel/2015-May/031993.html http://lists.freedesktop.org/archives/systemd-devel/2015-May/031995.html http://lists.freedesktop.org/archives/systemd-devel/2015-June/032779.html [3] https://github.com/nusenu/ansible-relayor/issues/16 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761403: CAP_KILL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Arto Jantunen: Actually also CAP_KILL is needed, otherwise reload will not work. CAP_KILL is not needed, see: https://lists.torproject.org/pipermail/tor-dev/2015-April/008759.html Feels a bit as if you are re-making my steps ;) It might make sense to take what is there already. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVSOwhAAoJEFv7XvVCELh02AcP/33lT84tYoVoiB9tHtbU/ffZ RO9yADsLukYRfoUA00ybaeKeC7mcU1LEIYnYPEeh+A0br/VJzopjSPBlkuWLGcTu D3CB4bCV0dowke6D4i2QqmdHKNSD/w1jq/iz5lvAbePo9UzySFMRgV3ev541kxL8 PUwDQ7s7gzh0kG4uvFpqW+PMbjeUQ2fO2MstqcuD5tBNILfb/Hme9pCe1Pn0VMVL G9y6iY8iAPpk8qssvAuo1GNLofrmulU5ne+rZfWkhPGPD+gsCJAAv5+j/Gw+TQtg Ygx+IOsb5jI2r2zTVNHAWiDoQ8sqYQJmI8B+XL1CF40ownAv+BvmAnYiNrqRtgaj rCWk73UdI77D4OvODvqKsFGlzQ0s0/8aHtcTJGm72ZeruzYoIohOduVKO4W5noFR 2b1M4iV2qe9y8vqXhMM9faqf/nEbTUM1Gv5jgDYQ1XZgRwyIW9yKQ7QYqUZxSvyn 67edYhMCZck2vCP/+aiud/5ex3SPSlmI5ut0w1M77tEo976Ab9gmVTkQlvHBMLhy x24MMCs2VjF0flaNkBOXcnAezEQr30QCCHhR7KzrdF9ia2yIachP7VqNfs8eeIpj xzyZw/xm3datX5G7NFVN5tkupMzKDlY+TgibtAto/t1h6zZjzxPmLiTFwMS/oQRY sNSyw3Og2UMKacommhDP =C64Q -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761403: CAP_KILL
Actually also CAP_KILL is needed, otherwise reload will not work. CAP_KILL is not needed, see: https://lists.torproject.org/pipermail/tor-dev/2015-April/008759.html Well. You can either do that, or add CAP_KILL. Either will work you chose one and I chose the other. With the difference that your tor daemons run with more capabilities than actually needed. Feels a bit as if you are re-making my steps ;) It might make sense to take what is there already. That may be the case. Is your version available for me to look at somewhere? See the URL in my first comment on this bug entry. and maybe also the closed issues in the tracker: https://github.com/nusenu/ansible-relayor/issues?utf8=%E2%9C%93q=is%3Aissue+is%3Aclosed+systemd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761403: CAP_FOWNER
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 CapabilityBoundingSet: Since you add CAP_FOWNER (compared to upstream): What use cases require it? CAP_FOWNER is required by ControlSocket /var/run/tor/control. Tor chowns the control socket on startup (and fails to start if this does not succeed). I was able to use ControlSocket without CAP_FOWNER. Adding CAP_DAC_OVERRIDE and CAP_CHOWN was enough in my case. See also: https://lists.torproject.org/pipermail/tor-dev/2015-April/008638.html What tor version did you test with? thanks, nusenu -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVRyECAAoJEFv7XvVCELh0h2UP/jMTEknl49OOgKKobZ0eqaZ/ 0ZJzwrrbY7GHjehl2Tf9V2EvekIkZMEvg1J1I293Kxlq4rYLCA1IBOCA/LxL0auD nugF5U6xYRQdLKjBlb3/DdSFF/ms87aqt4iBd/mxSlX5oOwW6RwuRSeh4GW0r3/k 13zQKYhzoFjb+H2l614yoeaaoMxrL7m3+qVzquKsSAa/ew4mvGi7y3sWzzUwQvJx GrzQgqOK4+mbNA+uanLLhC5QSRuwtYfSlgcsRRA+vSqdukJbFYifZs3HjLtEjA6Z VRe1aurJ2d6XDiBSkPbNc8okCgsXTsi3PxKLDrD75rzlU/hD+UU9mrJacoLU4y4b utcCr15z8ovCOZXNbR9nf7mrtwE6H5ZH7iRPwwIpuV7XRYKgylu0biJRmAcZBthr 6vPpgOENoPIQxVXmGWmpB0Fd8xp1AexT6DxEIrrQmlG2DhCq1i88HHIpTtrwFzY0 Kkr1zR5cEIxIjrZgGECBOtNsLzLY4YHgwgRYZjP2AwccKwTM88jGeQLKtuRYrCeX C+90alTLQVl14mY6wu+c9iTxejG06Db2dXKZ6KX+zGW5ippibFcy/WTRNTpmyIWf oYuySYJwEEE0JgnSuhuRgvxRs/zr8LJtrEC+bjpqIeRYIcwAPtvhpg9UI0gY5n4u QwZVefbznZNYbOzN7AuQ =Jo+x -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761403: CAP_FOWNER
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Arto Jantunen: With 0.2.6.7. Did you test both cases where /var/run/tor exists and doesn't exist? If /var/run/tor doesn't exist + ControlSocket /var/run/tor/control in torrc tor does not start with and without CAP_FOWNER: [warn] Before Tor can create a control socket in /var/run/tor/control, the directory /var/run/tor needs to exist, and to be accessible only by the user account that is running Tor. (On some Unix systems, anybody who can list a socket can connect to it, so Tor is being careful.) (I'm testing with 0.2.5.12) -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVR4ZxAAoJEFv7XvVCELh0WLYP/1aJqXbYI1hgFIKSt8Ujc4yo SeTZyxdShSXMhqP1oIQq+1GDCg8WUfn+NX4Wqrc0ugUCr+GUeUWJFlJCDpvTJn7/ zLvn5WHipALQm2Z2SZIkHnLqR0ZId5B4VpL2tNrQTjsBDxSHN+yWnFcRRladK7Ru f4Oa5tNqhja0of2E4nJcnmwBsRL/XeF86ZlRjcoL9PIXW6+k3MyyLkprRG5xWGRS 4CALF3EXCI3Pv+xOexU/TbBzcDZBW/ggemN5jza6EhzgELjLdFGadX8ZqW3Ya6fS pHdefHV0iY1clZYZO00XyQfnwKJjv+gIpg3NkgW9WlfNwrW+6npyxxlyaBv0M5/a 7UgpwBZi3GgPhCqWX2kIy7d+HM8qCr3nHowPbFVFQj5endcJOMv0cEGdi72/xpiy Uj0EVX+cjUaKihxOmdIhsF95uhIAqIb5q9vGLs99oKHJHiVVDUprLbrKmCzjT/M7 rnysLwVko2grVzKE6bKapUpuhpxjbF46kGxr0Ly9BAIQObmfLuwS3NkUbvUE478/ lGe2GnxvjkYsSXDodIPrWG789nbm6p2L1bhisrL0hpXBiSxrN9LHy2cKlMQTmu0G ab6QUYQ/rzn1T0xm3HNx8lfBpx/M0Xvp3hksXaqQDtWm/fqMUOvXyz9yE6NaxOSk 39BSdQIKfhNAAxOpZR7Y =CjQm -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761403: tor: Please install Tor's systemd unit file
Hi, please consider multi-instance support when adding a systemd service file for tor. For an example see: https://github.com/nusenu/ansible-relayor/blob/master/templates/debian_tor%40.service (this is a template file - simply remove lines 31,36-38) CapabilityBoundingSet: Since you add CAP_FOWNER (compared to upstream): What use cases require it? thanks, nusenu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782496: is-enabled fails for legacy sysv services
Package: systemd Version: 215-14 Hi, 'systemctl is-enabled service' returns 0 even if the service is enabled, when service is a legacy sysv init script. systemctl is-enabled tor Failed to get unit file state for tor.service: No such file or directory echo $? 1 chkconfig package (11.4.54.60.1debian1) is installed. Should it become a dependency for systemd in the future if 'is-enabled' depends on the presence of chkconfig? systemd 208 on RHEL7 does not show this behavior: systemctl is-enabled tor tor.service is not a native service, redirecting to /sbin/chkconfig. Executing /sbin/chkconfig tor --level=5 enabled echo $? 0 references: http://lists.freedesktop.org/archives/systemd-devel/2015-April/030652.html http://lists.freedesktop.org/archives/systemd-devel/2015-April/030671.html https://github.com/nusenu/ansible-relayor/issues/20 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782496: Acknowledgement (is-enabled fails for legacy sysv services)
duplicate Sorry I just saw: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751638 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751638: systemctl is-enabled fails for SysV init scripts
Control: affects -1 ansible I am also annoyed by this bug because this makes Puppet thinks that the service is not enabled as it should. same with ansible -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782479: systemd fails to merge CapabilityBoundingSet config lines
Package: systemd Version: 215-14 Hi, from systemd 215-14's man page about CapabilityBoundingSet: This option may appear more than once in which case the bounding sets are merged. So CapabilityBoundingSet = cap1 cap2 should be semantically identical to CapabilityBoundingSet = cap1 CapabilityBoundingSet = cap2 but that is not the case. Merging multiple lines manually fixed the issue for me: https://github.com/nusenu/ansible-relayor/commit/48df0a4738654ff6b0897493cf2811961550a7d6 https://github.com/nusenu/ansible-relayor/issues/19 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782479: systemd fails to merge CapabilityBoundingSet config lines
Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=89997 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
