Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upDebian Templates: /etc/init.d/tinyproxy should be deactivated by default #1401
Comments
adrelanos
referenced this issue
in marmarek/old-qubes-core-agent-linux
Nov 10, 2015
Merged
preset disable tinyproxy by default #43
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Nov 10, 2015
Member
Created https://github.com/marmarek/qubes-core-agent-linux/pull/43 for it. But I am having difficulties to test it. vm-systemd/75-qubes-vm.preset is capable to disable /etc/init.d services also, right? If so, this should work.
|
Created https://github.com/marmarek/qubes-core-agent-linux/pull/43 for it. But I am having difficulties to test it. vm-systemd/75-qubes-vm.preset is capable to disable |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Nov 10, 2015
Member
https://github.com/marmarek/qubes-core-agent-linux/pull/43 doesn't fix it. But it is okay to be merged anyhow, I think, for later, if/when Debian starts shipping a tinyproxy systemd unit file at some point.
It does not fix it because qubes-core-agent-linux debian/qubes-core-agent.postinst function systemdPreload checks if [ -e "/lib/systemd/system/${unit_name}" ]; then, which does not apply here for the init script.
Do we already have a mechanism/common practice in qubes-core-agent to disable Debian default init scripts?
|
https://github.com/marmarek/qubes-core-agent-linux/pull/43 doesn't fix it. But it is okay to be merged anyhow, I think, for later, if/when Debian starts shipping a tinyproxy systemd unit file at some point. It does not fix it because qubes-core-agent-linux debian/qubes-core-agent.postinst function Do we already have a mechanism/common practice in qubes-core-agent to disable Debian default init scripts? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 10, 2015
Member
If /etc/init.d/tinyproxy starts, qubes-updates-proxy.service can no longer start.
Why exactly?
user@d8test:~$ systemctl status tinyproxy
● tinyproxy.service - LSB: Tinyproxy HTTP proxy
Loaded: loaded (/etc/init.d/tinyproxy)
Active: active (running) since Fri 2015-10-23 13:00:54 CEST; 2 weeks 4 days ago
CGroup: /system.slice/tinyproxy.service
├─494 /usr/sbin/tinyproxy
├─670 /usr/sbin/tinyproxy
├─690 /usr/sbin/tinyproxy
├─712 /usr/sbin/tinyproxy
├─735 /usr/sbin/tinyproxy
├─745 /usr/sbin/tinyproxy
├─750 /usr/sbin/tinyproxy
├─752 /usr/sbin/tinyproxy
├─755 /usr/sbin/tinyproxy
├─758 /usr/sbin/tinyproxy
└─764 /usr/sbin/tinyproxy
user@d8test:~$ systemctl status qubes-updates-proxy
● qubes-updates-proxy.service - Qubes updates proxy (tinyproxy)
Loaded: loaded (/lib/systemd/system/qubes-updates-proxy.service; enabled)
Active: active (running) since Tue 2015-11-10 22:12:14 CET; 1min 7s ago
Process: 30103 ExecStartPre=/usr/lib/qubes/iptables-updates-proxy start (code=exited, status=0/SUCCESS)
Process: 30099 ExecStartPre=/usr/bin/install -d --owner tinyproxy --group tinyproxy /var/run/tinyproxy (code=exited, status=0/SUCCESS)
Main PID: 30110 (tinyproxy)
CGroup: /system.slice/qubes-updates-proxy.service
├─30110 /usr/sbin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates.conf
├─30113 /usr/sbin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates.conf
└─30114 /usr/sbin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates.conf
Why exactly? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Nov 10, 2015
Member
They are using the same var run folder. They cannot both use the same pid folder.
ls -la /var/run/tinyproxy/
total 4
drwxr-xr-x 2 nobody nogroup 60 Nov 7 09:30 .
drwxr-xr-x 28 root root 840 Nov 8 19:16 ..
-rw------- 1 nobody nogroup 4 Nov 7 09:30 tinyproxy.pid
sudo /usr/sbin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates.conf
tinyproxy: Could not create file /var/run/tinyproxy/tinyproxy-updates.pid: Permission denied
/usr/sbin/tinyproxy: Could not create PID file.
|
They are using the same var run folder. They cannot both use the same pid folder. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Nov 10, 2015
Member
Independently, there is another argument for disabling /etc/init.d/tinyproxy. We don't install tinyproxy by default because we think it's useful to have running by default for users. It's just a dependency of qubes-core-agent's qubes-updates-proxy.service to implement some functionality. There is no need to have any instances of tinyproxy running by default, unless started by qubes-updates-proxy.service.
|
Independently, there is another argument for disabling |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 10, 2015
Member
Independently, there is another argument for disabling /etc/init.d/tinyproxy. We don't install tinyproxy by default because we think it's useful to have running by default for users. It's just a dependency of qubes-core-agent's qubes-updates-proxy.service to implement some functionality. There is no need to have any instances of tinyproxy running by default, unless started by qubes-updates-proxy.service.
Yes, right. But that's separate issue. Those services shouldn't conflict. This is why PID file has different name, but apparently it isn't enough - it should have different directory.
Yes, right. But that's separate issue. Those services shouldn't conflict. This is why PID file has different name, but apparently it isn't enough - it should have different directory. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Nov 10, 2015
Member
it should have different directory.
Yes. It's not clean to use the same directory.
Not sure this deserves a separate ticket... The ExecStartPre is also problematic.
ExecStartPre=/usr/bin/install -d --owner tinyproxy --group tinyproxy /var/run/tinyproxy
The canonical way is to use systemd-tmpfiles. For example (untested):
/usr/lib/tmpfiles.d/qubes-core-agent-linux.conf
d /var/run/tinyproxy 0775 tinyproxy tinyproxy
It's also problematic, because that makes overwriting/disabling the other ExecStartPre line, i.e. ExecStartPre=/usr/lib/qubes/iptables-updates-proxy start more difficult for others (such as derivative distributions, namely Whonix ;). [I would like to prevent run of /usr/lib/qubes/iptables-updates-proxy to avoid conflicts with Whonix firewall. It's still doable with a drop-in, but I think I am better off deactivating whole qubes-updates-proxy.service in Whonix and re-implement starting it. This is by the way also how this whole thing got my attention.]
Yes. It's not clean to use the same directory. Not sure this deserves a separate ticket... The The canonical way is to use systemd-tmpfiles. For example (untested):
It's also problematic, because that makes overwriting/disabling the other |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 10, 2015
Member
Is it guaranteed that systemd-tmpfiles will create the directory before starting the service, or some additional dependency is needed?
|
Is it guaranteed that |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Nov 10, 2015
Member
systemd-tmpfiles has always worked stable for me without extra dependency.
cat /lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup.service
[...]
Before=sysinit.target [...]
[...]
There is one caveat. If the package should work right after installation as opposed to after boot, then until Debian stretch, the following Debian postinst maintainer script snippet would be required.
## workaround for 'dh_installinit should run systemd-tmpfiles if a
## /usr/lib/tmpfiles.d/ snippet gets shipped for systemd-only packages
## also' - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795519
# In case this system is running systemd, we need to ensure that all
# necessary tmpfiles (if any) are created before starting.
if [ -d /run/systemd/system ] ; then
systemd-tmpfiles --create /usr/lib/tmpfiles.d/qubes-core-agent-linux.conf >/dev/null || true
fi
I don't think this applies to qubes-core-agent-linux at the moment, since installing the package and using it before reboot is not a supported use case yet.
I also do not foresee issues during the transition/updating. The already booted system will still have the var run folder created by the old /usr/bin/install method. And after reboot, the /usr/bin/install method will be gone, systemd-tmpfiles mechanism taking over.
|
There is one caveat. If the package should work right after installation as opposed to after boot, then until Debian I don't think this applies to qubes-core-agent-linux at the moment, since installing the package and using it before reboot is not a supported use case yet. I also do not foresee issues during the transition/updating. The already booted system will still have the var run folder created by the old |
marmarek
closed this
in
QubesOS/qubes-core-agent-linux@f32dccb
Nov 11, 2015
added a commit
to QubesOS/qubes-core-agent-linux
that referenced
this issue
Nov 11, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 11, 2015
Member
The original issue isn't fixed yet - tinyproxy service would still be started.
How should we distinguish between "tinyproxy installed as a dependency" and "tinyproxy installed by user"? In the later case we shouldn't disable the service (at each qubes-core-agent update...)
|
The original issue isn't fixed yet - tinyproxy service would still be started. |
marmarek
reopened this
Nov 11, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Nov 11, 2015
Member
It can be checked if a package has been manually installed. ("Manually installed" here means, that the user [or build script!] has run for example sudo apt-get install iceweasel, which I did, I think.)
apt-mark showmanual iceweasel
iceweasel
Vs another example of the python2.7 package, which I did not manually installed, which was automatically installed as a dependency.
apt-mark showmanual python-2.7
(no output)
However, I am skeptical it would be good to invent a mechanism using this as this is even more non-standard, getting more complex and difficult to grasp for new users.
This is the solution that I would recommend. (tested) (Somewhat great, that one can use [somewhat?] systemd drop-ins, to even modify a sysvinit script.)
/lib/systemd/system/tinyproxy.service.d/30_qubes.conf
## Unit that does not need not run by default in Qubes VMs.
##
## This file is part of the qubes-core-agent-linux package.
##
## To enable this unit, you must create your own higher-priority file.
## For example:
## /lib/systemd/system/tinyproxy.service.d/50_user.conf
#[Unit]
#ConditionPathExists=
[Unit]
ConditionPathExists=!/usr/lib/qubes
|
It can be checked if a package has been manually installed. ("Manually installed" here means, that the user [or build script!] has run for example Vs another example of the (no output) However, I am skeptical it would be good to invent a mechanism using this as this is even more non-standard, getting more complex and difficult to grasp for new users. This is the solution that I would recommend. (tested) (Somewhat great, that one can use [somewhat?] systemd drop-ins, to even modify a sysvinit script.)
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 11, 2015
Member
On Wed, Nov 11, 2015 at 03:28:00AM -0800, Patrick Schleizer wrote:
This is the solution that I would recommend. (tested) (Somewhat great, that one can use [somewhat?] systemd drop-ins, to even modify a sysvinit script.)
Is it really possible for user to find what is going on here when trying
to launch tinyproxy and nothing happens?
Anyway I don't think many would want to use it Qubes VM for anything
else, so I'm ok with such solution.
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
On Wed, Nov 11, 2015 at 03:28:00AM -0800, Patrick Schleizer wrote:
Is it really possible for user to find what is going on here when trying Anyway I don't think many would want to use it Qubes VM for anything Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Nov 11, 2015
Member
Is it really possible for user to find what is going on here when trying to launch
tinyproxyand nothing happens?
Good point. Maybe there is space for improvement. Was also wondering about that. Let's see.
First of all, they will still be able to run tinyproxy. Just the service won't automatically start anymore. But probably not what you meant.
When they run sudo service tinyproxy start, it won't work. Without error. Not great. But if they are running sudo service tinyproxy status, they will get the following.
● tinyproxy.service - LSB: Tinyproxy HTTP proxy
Loaded: loaded (/etc/init.d/tinyproxy)
Drop-In: /lib/systemd/system/tinyproxy.service.d
└─30_qubes.conf
Active: inactive (dead) since Wed 2015-11-11 11:21:17 UTC; 1h 18min ago
start condition failed at Wed 2015-11-11 11:21:17 UTC; 1h 18min ago
ConditionPathExists=!/usr/lib/qubes was not met
Process: 30840 ExecStop=/etc/init.d/tinyproxy stop (code=exited, status=0/SUCCESS)
Perhaps,
30_qubes.conf->30_not_needed_in_qubes_by_default.conf, and/orConditionPathExists=!/usr/lib/qubes was not met->ConditionPathExists=!/usr/share/qubes/systemd_read_me was not met/usr/shared/qubes/systemd_read_mewould contain an explanation.
would make it a bit easier? (@bnvk)
Anyway I don't think many would want to use it Qubes VM for anything else,
Yes. Only advanced users are the type of users that care about stuff like tinyproxy. Still, if we can make such stuff simpler for them, why not.
so I'm ok with such solution.
Okay.
Good point. Maybe there is space for improvement. Was also wondering about that. Let's see. First of all, they will still be able to run When they run Perhaps,
would make it a bit easier? (@bnvk)
Yes. Only advanced users are the type of users that care about stuff like tinyproxy. Still, if we can make such stuff simpler for them, why not.
Okay. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 11, 2015
Member
Or, even better: plug it into qvm-service framework:
ConditionPathExists=/var/run/qubes-service/tinyproxy
What do you think?
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
Or, even better: plug it into qvm-service framework: What do you think? Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 11, 2015
Member
It would be instead of preset entry.
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
It would be instead of preset entry. Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Nov 11, 2015
Member
Good idea. What do you think about my config file name change idea 30_qubes.conf -> 30_not_needed_in_qubes_by_default.conf?
|
Good idea. What do you think about my config file name change idea |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 11, 2015
Member
On Wed, Nov 11, 2015 at 05:43:07AM -0800, Patrick Schleizer wrote:
Good idea. What do you think about my config file name change idea
30_qubes.conf->30_not_needed_in_qubes_by_default.conf?
Good idea.
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
On Wed, Nov 11, 2015 at 05:43:07AM -0800, Patrick Schleizer wrote:
Good idea. Best Regards, |
adrelanos
referenced this issue
in marmarek/old-qubes-core-agent-linux
Nov 11, 2015
Merged
No longer start /etc/init.d/tinyproxy by default anymore. #46
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Nov 11, 2015
Member
- use separate pid directory: you sorted that out marmarek/qubes-core-agent-linux@2a589f2
- use systemd-tmpfiles mechanism rather than /usr/bin/install: you sorted that out marmarek/qubes-core-agent-linux@2a589f2
- No longer start /etc/init.d/tinyproxy by default anymore.: sorted out https://github.com/marmarek/qubes-core-agent-linux/pull/46
This ticket should be 100% done.
This ticket should be 100% done. |
marmarek
added this to the Release 3.1 milestone
Nov 11, 2015
marmarek
added
bug
C: core
C: templates
P: minor
labels
Nov 11, 2015
marmarek
modified the milestones:
Release 3.0 updates,
Release 3.1
Nov 11, 2015
marmarek
closed this
Nov 11, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 13, 2015
Member
@adrelanos What do you think about backporting this one to R3.0? Is enabled
tinyproxy service a big problem?
|
@adrelanos What do you think about backporting this one to R3.0? Is enabled |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Nov 13, 2015
Member
Nothing severely broken from a users point of view. No need for backport.
|
Nothing severely broken from a users point of view. No need for backport. |
added a commit
to QubesOS/qubes-core-agent-linux
that referenced
this issue
Nov 15, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 15, 2015
Member
Automated announcement from builder-github
The package qubes-core-agent_3.0.21-1+deb8u1 has been pushed to the r3.0 testing repository for the Debian jessie template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing jessie-testing, then use the standard update command:
sudo apt-get update && sudo apt-get dist-upgrade
|
Automated announcement from builder-github The package |
marmarek
added
the
r3.0-jessie-testing
label
Nov 15, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 15, 2015
Member
Automated announcement from builder-github
The package qubes-core-agent_3.0.21-1+deb7u1 has been pushed to the r3.0 testing repository for the Debian wheezy template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing wheezy-testing, then use the standard update command:
sudo apt-get update && sudo apt-get dist-upgrade
|
Automated announcement from builder-github The package |
marmarek
added
the
r3.0-wheezy-testing
label
Nov 15, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 15, 2015
Member
Automated announcement from builder-github
The package qubes-core-vm-3.0.21-1.fc20 has been pushed to the r3.0 testing repository for the Fedora fc20 template.
To test this update, please install it with the following command:
sudo yum update --enablerepo=qubes-vm-r3.0-current-testing
|
Automated announcement from builder-github The package |
marmarek
added
the
r3.0-fc20-testing
label
Nov 15, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 15, 2015
Member
Automated announcement from builder-github
The package qubes-core-vm-3.0.21-1.fc21 has been pushed to the r3.0 testing repository for the Fedora fc21 template.
To test this update, please install it with the following command:
sudo yum update --enablerepo=qubes-vm-r3.0-current-testing
|
Automated announcement from builder-github The package |
marmarek
added
the
r3.0-fc21-testing
label
Nov 15, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 15, 2015
Member
Automated announcement from builder-github
The package qubes-core-vm-3.0.21-1.fc22 has been pushed to the r3.0 testing repository for the Fedora fc22 template.
To test this update, please install it with the following command:
sudo yum update --enablerepo=qubes-vm-r3.0-current-testing
|
Automated announcement from builder-github The package |
marmarek
added
the
r3.0-fc22-testing
label
Nov 15, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 15, 2015
Member
Automated announcement from builder-github
The package qubes-core-vm-3.0.21-1.fc23 has been pushed to the r3.0 testing repository for the Fedora fc23 template.
To test this update, please install it with the following command:
sudo yum update --enablerepo=qubes-vm-r3.0-current-testing
|
Automated announcement from builder-github The package |
marmarek
added
the
r3.0-fc23-testing
label
Nov 15, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 29, 2015
Member
Automated announcement from builder-github
The package qubes-core-vm-3.0.21-1.fc20 has been pushed to the r3.0 stable repository for the Fedora fc20 template.
To install this update, please use the standard update command:
sudo yum update
|
Automated announcement from builder-github The package |
marmarek
added
r3.0-fc20-stable
and removed
r3.0-fc20-testing
labels
Nov 29, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 29, 2015
Member
Automated announcement from builder-github
The package qubes-core-vm-3.0.21-1.fc21 has been pushed to the r3.0 stable repository for the Fedora fc21 template.
To install this update, please use the standard update command:
sudo yum update
|
Automated announcement from builder-github The package |
marmarek
added
r3.0-fc21-stable
and removed
r3.0-fc21-testing
labels
Nov 29, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Dec 20, 2015
Member
Automated announcement from builder-github
The package qubes-core-agent_3.0.21-1+deb8u1 has been pushed to the r3.0 stable repository for the Debian jessie template.
To install this update, please use the standard update command:
sudo apt-get update && sudo apt-get dist-upgrade
|
Automated announcement from builder-github The package |
marmarek
added
r3.0-jessie-stable
and removed
r3.0-jessie-testing
labels
Dec 20, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Dec 20, 2015
Member
Automated announcement from builder-github
The package qubes-core-agent_3.0.21-1+deb7u1 has been pushed to the r3.0 stable repository for the Debian wheezy template.
To install this update, please use the standard update command:
sudo apt-get update && sudo apt-get dist-upgrade
|
Automated announcement from builder-github The package |
adrelanos commentedNov 10, 2015
/etc/init.d/tinyproxy(shipped by the tinyproxy package) conflicts with qubes-updates-proxy.service.If
/etc/init.d/tinyproxystarts, qubes-updates-proxy.service can no longer start.At the moment,
tinyproxyneedlessly starts in all Debian based VMs.