Access to MailPit (was MailHog) redirects to novarnish.[hostname]

[rob-baker-ar]

MailHog MailPit should be available on the web service on port 8025 but attempting to visit: http://[hostname]:8025 from the host system redirects to http://novarnish.[hostname]/.

This seems to be something to do with these lines in docker-compose.varnish.yaml which appear to be using the same port as MailHog MailPit should be on:

    environment:
    ...
      - HTTPS_EXPOSE=443:80,8026:8025
      - HTTP_EXPOSE=80:80,8025:8025

Or even here:

    entrypoint:
      /usr/local/bin/docker-varnish-entrypoint -a 0.0.0.0:8025

I'm guessing a workaround might be to have MailHog MailPit on a different port?

[rfay]

No, it should be working correctly without changing port. The HTTP*EXPOSE there is exposing mailhog; it's not being "used" by varnish. I'm not saying that you haven't found a bug.

[rob-baker-ar]

I'm fairly new to docker / ddev - have been working with Varnish on production / dev servers with NGINX as a proxy up until now and trying to make our dev environment portable. I have not seen this set-up before, so not too certain exactly what is used by what, apologies.

I do have a custom varnish VCL but it's not doing any redirecting.

[rfay]

I confirm that it redirects (and succeeds) with novarnish.<fqdn>.

@skeemer could you please take a look at this? I imagine it has to do with

• Add redirects for mailhog ports, fixes #10 #14

[skeemer]

http://[hostname]:8025 is supposed to redirect to http://novarnish.[hostname]:8025 and does when I just tested it. It has to do that because configuring varnish to also route MailHog got really complicated. From what I remember, varnish isn't really built to handle routing multiple ports in parallel.

[rob-baker-ar]

OK, so can be worked around by binding MailHog to a different port? Or, as MailHog is bound to port 8025 in a default install perhaps Varnish should be using a different port in this particular context?

In my particular case (and I realise I may be in the minority here) I always need Varnish on as it does Edge Side Includes - I have stuff built into my VCL that allows me to bypass Varnish for various things. So if there is a way to sacrifice the http://novarnish.[hostname]:8025 functionality for access to MailHog, that would be a fine fix for me.

[skeemer]

You can edit any file added by the ddev get command by removing the #ddev-generated line at the top of the file and making the changes you want.

That being said, unless you configure varnish to pass 8025 from the varnish service to the web service, you won't be able to reach MailHog because the web instance is made available on the novarnish subdomain. You can see this in the file docker-compose.varnish-extras.yaml.

[rob-baker-ar]

In docker-compose.varnish-extras.yaml I have just:

services:
  web:
    environment:
    - VIRTUAL_HOST=novarnish.[hostname],novarnish.[second hostname]

I have 2 hostnames with 2 separate NGINX server blocks for this site.

So essentially, if I delete the web key and sub keys above - then novarnish.[hostname] goes away? I'm guessing something like:

services:
  varnish:
    ports:
      - "8025:8025"
    expose:
      - "8025"

Would solve:

unless you configure varnish to pass 8025 from the varnish service to the web service

Does that look right?

[skeemer]

That would do that, but then I'm not sure that anything would actually pass through varnish because web might remain primary for 80.

[rob-baker-ar]

You are right - this doesn't work.

I have found a work-around though: In .ddev/config.yaml I set all of: mailhog_port, mailhog_https_port and host_mailhog_port to ports not in use anywhere else and then accessed MailHog at http://[hostname]:[host_mailhog_port]. It looks like everything else is unaffected.

Many thanks for your help.

[rfay]

Note that you can just add the hostname novarnish. to your /etc/hosts and this works fine. Not sure that was clear.

[hoebekewim]

There is another way to solve this. You can remove the ".ddev/docker-compose.varnish-extras.yaml" file and then change the virtual host in .ddev/docker-compose.varnish.yaml to :

• VIRTUAL_HOST=varnish.$DDEV_HOSTNAME

Now everything will work, and if you need varnish, just put varnish. in front of your local domain.

[skeemer]

I was going to reply with the following, but that I realized you can just consider the varnish.* as the primary. Sometimes hard to think past the ideal.

I don't use varnish for anything at the moment, but to me that seems backwards. If you're trying to somewhat simulate production, then using an alt-domain as primary doesn't seem the most useful to me.

[FlorentTorregrosa]

Hi,

I have a the PR #25 that should help fix it.

No change needed for me in .ddev/docker-compose.varnish.yaml but when I looked at .ddev/docker-compose.varnish-extras.yaml and saw an hardcoded domain, it gaves me clue of a potential fix.

[rfay]

As I'm sure you know it's not mailhog any more, but mailpit, please update references to that as well? Nothing functional should be affected.

[FlorentTorregrosa]

In the MR, there is no reference to Mailhog, either in the description, or in the commit message, or in the change. Which references do you think about? This issue title?

[rfay]

Well at least issue title 😅

[FlorentTorregrosa]

Ok, I can't edit it. I think only maintainers of the repository and the issue author can edit the title :)

[rob-baker-ar]

I opened the issue - title updated and the issue text.

[rfay]

Oh sorry, I thought it was your new issue! Using my phone on a bike tour in Chile.

[FlorentTorregrosa]

No problem, enjoy your travel :)