Hi Razvan, > The sql plugin's behaviour was exactly the one that I was trying to > replicate, but without using the actual databases, as this would > become quite troublesome when you are dealing with a rather large > number of hosts, as you have to keep a database for each of these.
Well, you could use SQLite, which has nearly no overhead (such as another process etc.), and then make the Java application, which you would have running on each host, I suppose, simply write the config to that database instead of storing it somewhere else, or sending it to a special plugin (no idea if that applies to your use case). > I got that from the code, but as the plugins don't actually have a > while(true) loop inside of them, and they are just basically a set > of methods, they are called by the daemon in the end(or at least > that's what I get from the code). The plugin interface is actually very simple, it basically is just a single function each plugin has to implement - <name>_plugin_create() - which gets called by the daemon once the dynamic library is loaded and which has to return a plugin_t object (the plugin loader in recent versions allows some dynamic loading and dependencies via get_features, but the basic interface has not changed). Have a look at the existing plugins to see what each of them does in this constructor (you'll find them in src/libcharon/plugins/<name>/<name>_plugin.c). > Of course you could do this with a signal, but, again I would like to > avoid this as much as possible, because for example in java you don't > have a library to send signals, and you will have to use something > like Runtime.exec(). Not sure what you mean by signal, whether actual POSIX signals or some other kind of IPC (because with POSIX signals you can't transmit any other information than the signal itself). But I just saw that there are several libraries which allow you to use Unix domain sockets from Java (JUDS or junixsocket for instance). And other kinds of sockets (TCP/UDP) are certainly also available in Java. If you want to use Runtime.exec() you could use stroke directly to add simple connections (with ipsec stroke add) and to initiate and control those connections (ipsec up etc.). Combined with the sql plugin, or even by creating ipsec.conf files (and then calling ipsec update), this would also work for complex configs. > The SMP plugin seems a pretty good starting point, though it is only > used after the connection configurations have been made. Yep, its functionality is pretty basic at the moment. You could, of course, extend it and submit the patches to us afterwards. > Also, would it be ok, if a plugin, when created, started a running in > a separate thread as far as the charon daemon is concerned? Yes, that's no problem but most plugins that need separate threads use callback_job_t instead, which simplifies this a lot as it relies on threads provided by the global thread pool in charon. The stroke plugin, for instance, is one that uses this to read from the aforementioned Unix domain socket. Another example is the maemo plugin which actually uses the assigned thread to execute the GLib main event loop. Just grep for callback_job_create to see other examples. Since the main functionality of the charon daemon is contained in libcharon you could also use JNI to actually include charon in your Java application (by loading libcharon and the other libraries from it). Configuration could then be transferred directly via JNI. But doing that is probably a lot more work than using or modifying some of the existing plugins. Regards, Tobias _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
