janbar/ipfilter

Module flexibilitty

MiguelFGM opened this issue · 1 comments

I want to request a few changes to the module to make it more flexible in AnyCast networks or services running with multiple instances.

  1. Database reload
    -> Seems like the database itself only reloads when we are adding new IPs via the CLI in the server itself. If we run some sort of FileServer that syncs the database to multiple instances, the database will not reload since we are not doing changes via CLI, a command for a database reload (or automatic reloads) could fix this problem.

  2. Database flexibility
    -> Imagining that we are building multiple databases, where we will store different values like Low Threats, Medium Threats, and High Threats, we would require multiple commands like the "deny, allow" ones and more variables, a flexible database would let us doing more than "allow and deny" for these cases.

Any of these would be possible?

Best Regards!

janbar commented

I didn't anderstand what you try to acheive. The database is a file, and opened instances handle a file descriptor (fd) to the datafile file, like all others database system. If you remove or replace the file itself , all handles become invalid.
There is no need to reload if you update the content of the file, like the CLI do. But replacing the file is an other thing that cannot be managed. I let you imagine what happens, if you delete or replace the files of sqlite, mysql or postgresql database while running ...

The CLI allows all operations to manage changes (delete, insert, load etc). So you haven't need to "replace" the file. If you need to reload the full content you have to do the following:

Export the content from source database:

    export {dump_file_path}

Reload target database with the dump file:

    purge force
    load rule {dump_file_path}