Closed stevengoossensB closed 3 years ago
For the SSL piece - I will add that for a container deployment, I'd rather have the option of using HTTP or HTTPS, rather than have this rewritten so the core application runs HTTPS out of its own container. For AWS, I prefer to have a load balancer host the HTTPS entrypoint/termination to the application, and then host HTTP-serving nodes in a group configuration from my docker containers. Enabling this approach allows certificate management to be more flexible in both Azure and AWS cloud environments.
Makes sense. How about running the container both on 443, with SSL and 80, without default redirect to SSL? That way everyone can do whatever they want but still use the same container :)
I'm sure that both listeners at the same time will be great. Anyone can always use docker to expose only one of them if they desire.
This is implemented now. The container runs the service both on port 443 and port 80 without redirect.
If this is fine for you, I can merge it.
For me it's fine and works as designed.
Thank you!
Hi, I have found a problem in the dockerfile line 25 and 32. Due to the COPY operation on line 25 not specifying ownership the execution of INSTALL_NODB.sh on line 32 fails due to user "misp" not having enough permissions.
This can easily be solved by adding --chown=misp:misp to the COPY operation.
I hope this is the right way for me to make you aware of the issue/solution, if not please say so and I will do my best to improve in the future.
Hi, I have found a problem in the dockerfile line 25 and 32. Due to the COPY operation on line 25 not specifying ownership the execution of INSTALL_NODB.sh on line 32 fails due to user "misp" not having enough permissions.
This can easily be solved by adding --chown=misp:misp to the COPY operation.
I hope this is the right way for me to make you aware of the issue/solution, if not please say so and I will do my best to improve in the future.
Since this has already been merged, it might be best to submit the fix as a new Pull Request, and reference this PR as the changeset that introduced the problem, or open a new Issue explaining the fix and reference this PR - that way the defect gets tracked as an open issue in GitHub.
I've rewritten the Dockerfile so it uses the Installerscript and installs all but the Database in the container. This includes GPG key generation, SSL setup,... which makes part of what was done in the run.sh file obsolete.
Since the container itself now runs SSL, the Docker compose file with NGINX in front of MISP is obsolete so I removed that as well. Maybe the PR should move to a different branch because of the big change compared to the old container.