vanguards network example does not work about docker-tor-hidden-service

[cmehay]

Sorry but I won't provide support for usage, your compose file doesn't look good.

[beuluis]

Sorry i am late to the party.

I will give it a try on the Weekend and let you guys know.

Thank you for looking into it!

[beuluis]

any news?

[anoduck]

@beuluis I received a similar error, and I am not all sure what the source of the problem was either, but I assumed that it had to do with a network error in docker. Something dealing with the multiple network setup for isolating vanguards and tor. If you change the network driver from bridge to local or whatever, it might work, but I would not recommend attempting this.

Just run tor and vanguards in the same container with the same image, and it should fix the issue. There is no need to make it more difficult than it has to be.

[cmehay]

should be fixed now

[anoduck]

@cmehay OK, used Docker Compose Vanguards Network File as an example, and still receiving the connection refused error in the vanguards container.

The big difference between the repository version docker-compose file and the one I am locally using is my configuration does not employ the use of docker secrets. Rather than use secrets to stor the tor service key, the key is written in the docker-compose file.

Is employment of docker secrets required in order for vanguards to connect with tor? I am not seeing why it should.

[cmehay]

No is not, double check the compose file, there was a typo in the previous one 2fc69d3

Run make run-vanguards-network from the latest master commit to check your docker environment.

[anoduck]

@cmehay I did not have those typos in my docker-compose file, but I did realize the tor control port was overlapping with a separate instance of tor on a different stack. So I modified my docker-compose file and changed tor port to 9150 and tor-control port to 9151, and still receiving the error Tor daemon connection failed: Connection refused. Trying again....

While testing this, I also discovered a rouge instance of the tor container was still running. Which, was quickly resolved.

Something I happened to notice by chance is there is a time difference between the host machine and the containers of four hours. The time set on the containers is four hours ahead of local time. I do know this can affect connectivity, but I doubt it would make a difference in a configuration such as this.

Still stumped as to what could be causing this error. Below is my docker-compose.yml file.

version: '3.5'

services:
# -------------------------------------------------------
# Apache
# -------------------------------------------------------
  apache:
    image: apache:0.0.2
    container_name: webox
    restart: always
    volumes:
      - type: bind
        source: $PWD/httpd.conf
        target: /etc/apache2/httpd.conf
      - type: bind
        source: $PWD/apache
        target: /var/www/apache
    ports:
      - "8888:8888"
    expose:
      - "8888"
    networks:
      - hidden_services
    entrypoint: ["/usr/sbin/httpd", "-D", "FOREGROUND"]

# -----------------------------------------------------
# Tor
# -----------------------------------------------------
  tor:
    image: goldy/tor-hidden-service:latest
    container_name: torbox
    restart: always
    environment:
      TOR_SOCKS_PORT: '9150'
      TOR_CONTROL_PORT: '9151'
      TOR_CONTROL_PASSWORD: 'some_control_password'
      # TOR_ENABLE_VANGUARDS: 'true'
      VANGUARDS_EXTRA_OPTIONS: |
       [GLOBAL]
       enable_cbtverify = True
       loglevel = DEBUG

      CHAN_TOR_SERVICE_HOSTS: '80:webox:8888'
      CHAN_TOR_SERVICE_PORTS: '80:8888'
      CHAN_TOR_SERVICE_VERSION: '3'
      CHAN_TOR_SERVICE_KEY: |
        'some_extremely_safe_yet_irritatingly_long_tor_service_key'

    volumes:
      - type: bind
        source: ./tor
        target: /var/lib/tor/hidden_service
      - type: bind
        source: ./tor-data
        target: /run/tor/data
    ports:
      - 9150:9150
      - 9151:9151
    networks:
      hidden_services:
        ipv4_address: 172.16.222.10
      tor_control:
        # Set an ip address for tor_control network to bind for the good network
        ipv4_address: 172.16.111.10

# -----------------------------------------------
# Vanguards
# -----------------------------------------------
  vanguards:
    image: goldy/tor-hidden-service:latest
    container_name: vanbox
    restart: always
    depends_on:
        - tor
    environment:
      TOR_CONTROL_PORT: tor:9151
      TOR_CONTROL_PASSWORD: 'some_control_password'
      CHAN_TOR_SERVICE_NAME: 'webox'
      CHAN_TOR_SERVICE_HOSTS: '80:webox:8888'
      CHAN_TOR_SERVICE_PORTS: '80:8888'
      CHAN_TOR_SERVICE_VERSION: '3'
      CHAN_TOR_SERVICE_KEY: |
        'some_extremely_safe_yet_irritatingly_long_tor_service_key'

    networks:
      - tor_control
    volumes:
      - type: bind
        source: ./tor-data
        target: /run/tor/data
    command: vanguards

# ----------------------------------------------
# Networks
# ----------------------------------------------
networks:
    # This network is used for hidden services
    hidden_services:
        driver: bridge
        ipam:
            driver: default
            config:
                - subnet: 172.16.222.0/24
    # This network is used for vagrands to get access to tor
    tor_control:
        driver: bridge
        ipam:
            driver: default
            config:
                - subnet: 172.16.111.0/24

[anoduck]

@cmehay Admittedly, the closing of the issue and response caught me at a bad time, but I do feel it was premature, and your response is ambiguous.

What doesn't "look good" about it? This response is ambiguous, it neither clarifies the faults of the particular applied "usage", whether the error is not reproducible, nor does it point out possible errors in the docker-compose.yml. It solely expresses an opinion of taste or preference.

How can a "docker-compose.yml" file be at fault when the code blocks were literally copied and pasted from the examples provided by the developer?

---

@beuluis Could you please give this another try? Now, that the docker-compose.yml has been modified. Thanks.

[cmehay]

@anoduck sorry if it looks rough, but this place is for tracking bugs, not for asking support, the issue originally reported has been fixed.

[beuluis]

For sure. I will take a look and reopen if necessary or create a new one if i find a different issue.

Thank you for fixing it!

[anoduck]

@cmehay Flexibility is the standard for courtesy.

Regardless, I discovered the error made on the docker-compose.yml, and it is working. I will close out the other issue I opened. Good-to-go now.

@beuluis Make sure to define the IP for the tor control port on both tor and vanguards in your configuration. Vanguards still might not connect immediately, I actually had to tunnel into vanguards and start the program manually. Which may or may not mean that it is running as configured, but the important part is knowing that it can run.