Closed pufferffish closed 2 years ago
Related to #16
On further consideration, I think this is out of scope for the project. Such features are better left to other programs that manage wireproxy (e.g. systemd / runit or other init systems).
If someone thinks this would be an essential feature, feel free to comment or reopen the issue.
On further consideration, I think this is out of scope for the project. Such features are better left to other programs that manage wireproxy (e.g. systemd / runit or other init systems).
If someone thinks this would be an essential feature, feel free to comment or reopen the issue.
Agree. Now my systemd file is
[Unit]
Description=WireProxy for WARP
After=network.target
Documentation=https://github.com/fscarmen/warp
Documentation=https://github.com/octeep/wireproxy
[Service]
ExecStart=/usr/bin/wireproxy /etc/wireguard/proxy.conf
RemainAfterExit=yes
Restart=always
[Install]
WantedBy=multi-user.target
Turn of: systemctl statrt wireproxy
Turn off: systemctl stop wireproxy
Daemon:systemctl enable --now wireproxy
Disable:systemctl disable --now wireproxy
On further consideration, I think wireguard-tools have open and close options. wg-quick up and down. So WireProxy can pass parameter to switch on off should be better. Finish himself.
On further consideration, I think wireguard-tools have open and close options. wg-quick up and down. So WireProxy can pass parameter to switch on off should be better. Finish himself.
True, but I don't think we can easily implement this feature like wg-quick. wg-quick assumes you have root access and only one instance of wireguard running on your computer. Wireproxy can have multiple different instances running, each belonging to a different user. We can implement this feature by making pidfiles and keeping track of running wireproxy instances in a directory, but then we are reinventing init systems.
For this reason I don't think it is suitable to implement this feature. Multiple wireproxy instances can be achieved by having different systemd services. This responsibility shouldn't be handled by wireproxy.
Glad to hear this exciting news. Many WARP users have reported such a need. I also hope the parameter to close wireproxy. Now I need to use
kill -9 $(pgrep -f wireproxy)
, which seems rude and unprofessional.Originally posted by @fscarmen in https://github.com/octeep/wireproxy/issues/19#issuecomment-1082125051