Hello, I have multi-server (cluster) installation of ISPConfig. I wonder if there is some way how to trigger datalogUpdate from non-master server? For example in my script I want to disable and enable again shell user. I have this script on non-master server (the actual server when shell user is created) but when I trigger updateDatalog the updated record is wrote in master database but not in datalog table and because of that no action is actually triggered (shell user is not disabled). Another example, I have created a DKIM for domain inserted in webserver. I want to from webserver (non-master) trigger using datalogInsert adding DNS server into DNS server. When I call datalogInsert there is just record into database inserted but not into datalog table so, again, no action is triggered. What am I miss? Thanks a lot
I can't readily help with your approach, as I'm not familiar enough with the ispconfig functions to know right offhand (I've only used the api), but I'm both curious as to the use case that would require that, and would point out that you might want to rethink your approach. That is of course exactly the type of thing the remote api was created for, I'm curious why you don't want to use it? And note that you will likely need to give your remote servers full access to the dbispconfig database on your master to do what you're wanting, which lowers your security posture in addition to "recreating the wheel."
In both cases, our scripts are parts and integrated into original ISPConfig source code (we have made many modifications on our installations). That is the reason why I do not want to use HTTP api and enter credentials into source codes, especially when I need to make an operation that is basically part of the ISPConfig and base "protocol".
Maybe is the solution to change Code: $app->db->query($sql, $db_table, $dbidx, $server_id, $action, time(), $username, $diffstr, session_id()); to Code: $app->dbmaster->query($sql, $db_table, $dbidx, $server_id, $action, time(), $username, $diffstr, session_id()); in datalogSave function but I am not sure about consenquences.
The ispcsrv* user, which is the one that connects from slave server to master, is not permitted to write to sys_datalog table on the master for security reasons. If it works on your system, then you probably used a different user or changed its permissions. The reason why it is disallowed is this: if a slave would get hacked and the ispcsrv* user has full permissions to sys_datalog on the master, then the attacker would be able to take over or heavily damage the master and all slaves by injecting commands in the datalog which would get processed by all other slaves.
Oh, ok, understand. So, I guess, there is no other way how to achieve described behavior than using HTTP API, right?
Yes, or at least not if you don't want to configure your ispcsrv* users manually and take the risk that a hacked slave is able to damage all other servers.
OK, Till, thank you. It's a pitty, but understand reasons. We have to figure out in another way, using HTTP API.
I'm aware of the limitations that happen due to these security restrictions but they are necessary in my opinion. I plan to replace the dbmaster connection in the long term with some kind of http(s) based API, this would avoid database connections to the master in general and it would give even more fine-grained control in a way that one would be able to allow access to sys_datalog from a slave but restrict the slave to inject only data for it's own server_id which means that he can't manipulate other servers like that but the data will show nonetheless on the master. But this is basically a large rewrite on how this whole master/slave thing works, so nothing that#äs done in a few weeks. Plus a migration procedure must be found for existing servers etc.
That's a really good idea though. I understand that rewriting is kind of complicated and not easy in such a way, but it will be great and more flexible then. I figured out how we solve it temporarily until a new way will be sometimes in the future implemented. We make some bridge script on a slave that will communicate with the master HTTP API. This bridge will be on every slave and our functions will use and call it in terms of providing operations on the master. This should work for a while.
