Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Static configuration of webserver and dbserver localhost ports, bind only to localhost, fixes #1491, fixes #941, #642 too #1502
OP #1491: For security reasons, host binding of the dbserver should only be localhost (127.0.0.1) not 0.0.0.0 (the default, all interfaces), because this allows other people on the network to possibly probe for the database connection, depending on firewall configuration.
OP #941: Keep a stable port number for the localhost ephemeral ports so that people can use standard techniques to access them.
#642: We've long talked about keeping a catalog of metadata even for projects that aren't running. This PR introduces that.
How this PR Solves The Problem:
This is actually an amazing step forward for us. For the first time it provides a global database of projects, as requested in #642 . It's now trivial to add additional project information in the global_config.yaml.
Manual Testing Instructions:
Automated Testing Overview:
We'll probably want to tell people to do a
This was referenced
Mar 20, 2019
changed the title
Static configuration of webserver and dbserver localhost ports, bind only to localhost, fixes #1491, fixes #941
Mar 24, 2019
@andrewfrench this one requires a significant effort both with the code review and manual testing and your review of the basic approach. I think it's good, but sure look forward to your opinion.
I guess the biggest basic design question is whether the host database should be kept in global_config.yaml (as currently) or split into a different file. We'll see what you think.
I also took a few minutes to think about docs and decided it didn't need extra, but interested in your opinion. The new items for the host db and web ports are documented in the text at the bottom of config.yaml.
Hey @rfay, I'm working through review of this now and it adds a huge amount of both immediate utility and future potential for expanding on the local database of projects idea.
Managing port claims in global_config.ddev works for me, but I was able to spot some issues regarding the way project ports are claimed in global_config.ddev: after a project is configured and its ports are claimed under the project's name, the normal methods of changing the project name cause failed starts, like editing the "name" field in .ddev/config.yaml or
I can imagine a few solutions to this:
Wow @andrewfrench I think you just saved a lot of people a lot of pain. Thanks for checking that carefully.
I think the fundamental error I've introduced is reserving the port for every single project, when only a few people have actually requested it. I'll experiment with only reserving globally when explicitly specified in project config.yaml. It was just wrong to have a second global reservation at this point (besides project name)
My initial response to the general issue is that we've always used project name as the unique systemwide identifier, but we haven't ever enforced it. As a result of this undocumented assumption, we have occasional failures like
I suspect we can solve both of those pretty easily as this functionality gets fleshed out. In the next sprint we can add the project directory and it will solve an enormous amount of this kind of trouble, and also allow
@andrewfrench I changed the logic so that the port is dynamic unless specified in the config.yaml, and not reserved in the global_config.yaml unless it's set as static in config.yaml. I think this is far more in keeping with the request, and should solve the problem you described.
andrewfrench left a comment
Approving after confirming that this works quite well, especially after only reserving ports when requested. I've left a couple notes about non-blocking preferences, but this does a great job of: