Closed Simbiat closed 2 months ago
@Simbiat: Thanks for opening an issue, it is currently awaiting triage.
In the meantime, you can:
Adding DISABLE_PARSERS: crowdsecurity/geoip-enrich
to compose does not help: the links are still created on every start.
Maybe
ln -s "/staging/var/lib/crowdsec/data/$geodb" /var/lib/crowdsec/data/
can be replaced with something like this?
if istrue "$GEODB_COPY"; then
cp -f "/staging/var/lib/crowdsec/data/$geodb" /var/lib/crowdsec/data/
else
ln -s "/staging/var/lib/crowdsec/data/$geodb" /var/lib/crowdsec/data/
fi
I can make a PR for this (and adding the variable to docker documentation), if this is acceptable
Honestly, we don't want to add another option just for this edge case. We symlink them because they already exist within the container image and copying the file just uses extra storage. As you stated after the container is running you can just CP manually and then the file are the correct ones and if the volume is persisted then there should be no issues after the fact.
There no need to onedrive these files, the only thing I would say is the database to which I would expect onedrive to be able to turn on or off depending if they are valid.
On my test environment my whole project, including data folders are on OneDrive. I know it's an edge case, but what about another more probable scenario: sharing of geo files between containers? From what I understand, if we still make links, it will not allow that, because links in other containers will be failing.
On my test environment my whole project, including data folders are on OneDrive. I know it's an edge case, but what about another more probable scenario: sharing of geo files between containers? From what I understand, if we still make links, it will not allow that, because links in other containers will be failing.
If you share the same mount point between all crowdsec containers it follows the symlinks which will result in the same location no matter. If its another application then sorry its out of scope for this project to support having geo databases read by another application.
What happened?
I have a Windows host machine running Docker Desktop with WSL2. When running Crowdsec container and mounting a path that's a OneDrive path in Windows, OneDrive starts complaining about
GeoLite2-ASN.mmdb
andGeoLite2-City.mmdb
saying name or type not allowed. It complains because the files are symlinks, and from what I understand OneDrive can be picky about those. In this case it would be doubly picky, since the links are to WSL areas, which OneDrive clearly can't access.What did you expect to happen?
Files should be accepted by OneDrive normally
How can we reproduce it (as minimally and precisely as possible)?
Have a Docker Compose service like
with
${CROWDSEC_DATA_DIR}
being a OneDrive folder. Start the service and wait for the files to be created and OneDrive to try syncing them.Anything else we need to know?
This is obviously not a bug, but it would be nice to find a way to work around t his, because as is I have to remove the links every time. To be honest, I am unsure what's the point of using symlinks here, since the files are still within the same container in non-persistent storage, thus it seems reasonable to just use files from
/staging/var/lib/crowdsec/data
Crowdsec version
OS version
Enabled collections and parsers
Acquisition config
Config show
Prometheus metrics
Related custom configs versions (if applicable) : notification plugins, custom scenarios, parsers etc.
No response