- 1 network.http.ssl_verify_peer.set=0
- 2 rtorrent with dtach as service?
- 3 why don't we just assume for simplicity that there is only one session?
- 4 Creating multiple rtorrent sessions this way is far from perfect
- 5 This page use deprecated commands
- 6 Improve Systemd services using tmux section
- 7 Improve dtach systemd unit
- 8 systemd unit file
It seems to me "set network.http.ssl_verify_peer.set=0 " would open the door for man-in-the-middle attacksRwd.
rtorrent with dtach as service?
There are 3 service files so far, with tmux and screen. But can it be done with dtach? /usr/bin/dtach -n /home/dustball/.dtach/rtorrent /usr/bin/rtorrent doesn't seem to cut it. Dustball
I could not figure oun a way to go even more minimalist - start rtorrent "bare", just with systemd's sockets like so:
ExecStart=-/home/sam/bin/rtr_new -n -o import=/home/sam/.config/rtorrent/new_.rc
and if I need the interactivity, take over the sockets later like this:
reptyr -T `pgrep -fn rtr_new_ `
(it's in one of the Arch repositories)
Reptyr's man page says it does not work with rtorrent but I find reptyr can successfully steal from dtach once. After that a 2nd reptyr won't steal rtorrent from the 1st reptyr. Sometimes it seems to work for a few seconds then rtorrent just goes away.
also I can do this repeatedly (separate terminals) - neercs steals from reptyr, reptyr from neercs and repeat as many times as you like;
neercs -P `pgrep -fn rtr_new_` & reptyr `pgrep -fn rtr_new_ `
and rtorrent keeps running fine https://aur.archlinux.org/packages/neercs-git/
so the problem's not with reptyr per se
why don't we just assume for simplicity that there is only one session?
Creating multiple rtorrent sessions this way is far from perfect
perhaps a separate section is needed?
last time I lurked on rtorrent discussions this question came up regularly.
This page use deprecated commands
And example config fromtoo.
- I replaced the commands with the new syntax equivalents.
Improve Systemd services using tmux section
It's not possible to start any command with tmux if the user is a daemon / service account (that has /usrb/bin/nologin or /sbin/nologin as a shell that can be changed for extra security for SFTP user for example), even if /sbin/nologin is added to /etc/shells.
The only post talking of that on internet I found is this reddit thread https://www.reddit.com/r/linuxadmin/comments/7am99j/systemd_service_unit_file_uses_the_users_login/.
Also for With tmux running as user rtorrent (restart rtorrent if crashed) should we add ReamainAfterExit=yes because tmux is detached? And also should we change sendkeys -t rtorrent into sendkeys -t rtorrent:rtorrent in order to target the right window if there is several windows inside the session?
Improve dtach systemd unit
For starters, I had to change "multi-user.target" to "default-target" or it wouldn't work on boot after having enabled it. After that it kept failing to start because rtorrent couldn't lock the session file. I'm currently running this:
[Unit] Description=rTorrent [Service] Type=forking Environment="TERM=xterm-256color" ExecStartPre=-/bin/rm /home/raphael/.config/rtorrent/.session/rtorrent.lock /home/raphael/.config/rtorrent/dtach ExecStart=-/usr/bin/dtach -n /home/raphael/.config/rtorrent/dtach /usr/bin/rtorrent ExecStop=-/usr/bin/killall -w -s INT /usr/bin/rtorrent [Install] WantedBy=default.target
The user will probably be surprised to see the arrow keys not working... according to the gentoo wiki the fix is to enter "keyboard transmit mode", attach and then leave keyboard transmit mode. Basically this page should suggest the user to create an alias with this
tput smkx; dtach -a ~/.config/rtorrent/dtach; tput rmkx
I wonder how I go around packaging this... unfortunately I'm not very well versed in systemd and I'd much rather be using OpenRC if Arch Linux hadn't been infected with this disease.
systemd unit file
What do you think of this unit file
[Unit] Description=rTorrent Daemon After=network.target [Service] Type=simple KillMode=process User=rtorrent ExecStart=/usr/bin/rtorrent -o system.daemon.set=true WorkingDirectory=%h Restart=on-failure [Install] WantedBy=multi-user.target
I had the idea thanks to this warning:
- I have added a fleshed out version of this to allow multiple users using a single service unit.
- There is probably a better way of achieving this than what I have added though. I couldn't get %h working when user/group is specified via %I, so all values for a user are using %I, as shown by the ExecPre line.