Upgrade support

[narly-david]

Did some initial code compares between the INSTALL_NODB.sh script in this project vs in the INSTALL.sh from the main MISP project

Looks like the INSTALL_NODB.sh script was a modified snapshot of an INSTALL script from a few months ago: https://github.com/MISP/MISP/blob/dee302640a31f3f3b41b60b7c77d1ce4ea2d164e/INSTALL/INSTALL.sh

If this is correct, what is the upgrade path for this repo?

With the recent new updates to MISP, we were interested in pulling in the updates)

I understand that it will be challenging to sustain what is essentially doing a massive diff and mod every time there is a new commit to MISP.

Any ideas on how to proceed?

As an aside, we are interested in using PaaS such as AWS RDS to replace the need for a local database in addition to throwing this into our Kubernetes cluster.

Thanks!

[TheOfficalNick]

We are also interested in using a PaaS database in Azure. I believe Mariadb is available for PaaS. I would be interested to know if you have found a solution to decoupling MISP and getting around this update stuff.

[narly-david]

@TheOfficalNick Using the docker-misp repo (from harvarditsecurity), we were able to successfully use AWS RDS. However, that repo hasnt had activity since August of last year and led us to this repo.

We have not yet tried connecting this to AWS RDS. To date, we've used Kustomize to convert this Docker Compose to Kubernetes yaml. We haven't yet solved ingress/egress for the cluster to reach out to an external PaaS (we hope to). We've temporarily used the local DB on a K8s PVC.

We're attempting to determine if the INSTALL_NODB.sh script will be maintained as the INSTALL.sh script is updated in MISP. I imagine that if the INSTALL_NODB.sh falls behind too many commits, it may not have all of the correct environment vars and settings that future versions of MISP will require. Also unsure if we'd be able to specify a specific commit/version of MISP to use in case a breaking commit is introduced in the main MISP codebase to hold us off until an updated INSTALL_NODB.sh can be introduced.

Depending on your requirements (using containerization or not), MISP can definitely talk to an external DB. Using Docker, we could bring up the CLI and test whether the container had access to login to the PaaS DB and then we had to run the following command manually to initialize the database:

Initialize Database

docker run -it --rm -v /docker/misp-db:/var/lib/mysql harvarditsecurity/misp /init-db

I'm currently reading up on the main MISP repo on how the INSTALL.sh is generated from the INSTALL.tpl.sh to hopefully provide insights into how the INSTALL_NODB.sh is created unless I hear from the maintainers first

[stevengoossensB]

Hi,

I initially went this path, for the sake of NOT having to maintain the Dockerfile whenever there's new libraries etc that need to be installed and leverage the installer. Turns out the installer had quite some issues running inside a container, which is why I adapted it. I would need to retest it and check whether these issues still exist.

Ideally, the standard INSTALL.SH should be adapted to also work in a container environment, so the INSTALL.SH of the main MISP repo can be used inside the container. That way, a new build of the container will use the newest codebase and the newest install script.

In the meanwhile, building the container from scratch results in a working MISP instance, which is on the latest codebase from git. The issues might arise whenever there's a need for new libraries, different python versions etc, which are installed through the INSTALL script.