Project Logs

Collapse

• Torrents in a VPN

  lion mclionhead • 10/26/2023 at 23:18 • 0 comments

  Lions contend that most containers are only used for downloading torrents in a VPN.  Most ISP's these days disable your account for nefarious downloading.

  The mane VPN program is openvpn.  The mane command line torrent program these days is transmission-cli. 
  

  apt install transmission-daemon transmission-cli
  

  Getting it going in a VPN container is a long & hard process.

  The daemon is a systemd service.  It immediately gives "unauthorized" for all commands.  You have to systemctl stop transmission-daemon, edit /etc/transmission-daemon/settings.json, set rpc-authentication-required to false, & systemctl start transmission-daemon to get around this.
  

  Generally, there's an openvpn command which configures the VPN.  It runs a command after the VPN starts & another command before the VPN dies, to ensure no data intended for the VPN goes to the insecure network.
  

  openvpn --config [.ovpn file] --auth-user-pass [userpass file] --comp-lzo --up-delay --up [startup script] --down-pre --down [shutdown script]

  At minimum, the startup & shutdown scripts manage the torrent daemon.

  systemctl start transmission-daemon

  
  

  systemctl stop transmission-daemon

  
  
  

  -------------------------------------------------------------------------------

  Key commands:
  

  Start downloading a torrent:
  

  transmission-remote -a "magnet link"
  

  List status & ID's of all torrents:

  transmission-remote -l
  

  Stop a torrent by ID:
  

  transmission-remote -t [ID] -S
  

  Resume a torrent by ID:

  transmission-remote -t [ID] -s
  

  Remove a torrent by ID:
  

  transmission-remote -t [ID] -r
  

  There is no easy way to select individual files for downloading.  The general idea is to poll the torrent contents by torrent ID.

  transmission-remote -t [ID] -f
  

  Once it downloads the file list, stop all the files from downloading
  

  transmission-remote -t [ID] -G all
  

  Then resume 1 file at a time by passing its ID
  

  transmission-remote -t [ID] -g [file ID]
  

• Dangling virtual eth devices

  lion mclionhead • 05/24/2023 at 23:36 • 0 comments

  Noted every time you lxc-stop & lxc-start a certain container, it creates a new virtual eth device.  Eventually ifconfig & brctl show fill with dead virtual eth devices.  These dead devices cause networking in the container to fail with TLS errors, dropped connections, while DNS & ping continue to work. 
  

  The leading theory is these containers start processes which aren't killed by lxc-stop.  kill -9 instead of lxc-stop doesn't release the devices. 
  

  meld shows an interesting evolution of the process table during the lifecycle of the container.
  

  The container creates a bunch of nfsd & kworker which aren't visible inside the container.  These are left behind after lxc-stop or kill -9
  

  killall -9 nfsd gets rid of all the dangling eth devices & processes.
  

  The nfsds are all created outside of the container by lxc-start & bound to the virtual eth.

  For some reason, the offending container has a bunch of rpc programs running inside the container & these cause nfsd to run outside the container.  There's no reason to use nfsd in a container since the filesystem is a subdirectory on the host.  A quick disabling of RPC solves the dangling network interfaces.
  

  
  

  mv /usr/sbin/rpc.idmapd /usr/sbin/rpc.idmapd.bak
  

  mv /usr/sbin/rpc.mountd /usr/sbin/rpc.mountd.bak

  mv /usr/sbin/rpcbind /usr/sbin/rpcbind.bak
  

  
  

  That fixed the connection errors.  As in all things, containers introduce many new problems in exchange for solving old problems with virtual machines.  The hope is the new problems are less debilitating than the old problems but there can never be a perfect solution.
  

• X clients in a container

  lion mclionhead • 05/23/2023 at 21:14 • 0 comments

  The goog spits out many hits for running an X11 program in a container by creating a new container from scratch.  Buried in this list was 1 hit for reconfiguring an existing container.
  

  https://blog.simos.info/running-x11-software-in-lxd-containers/
  

  The general idea is to add 1 line to your /var/lib/lxc/*/config file
  

  lxc.mount.entry = /tmp/.X11-unix tmp/.X11-unix none bind,optional,create=dir,ro

  Then restart the container.

  This creates a path which redirects the X server sockets of display :0 to the X server sockets of the host display.
  

View all 3 project logs