|Subject||tcpsvd listening on different IP addresses controlling security2.fdb location|
Sorry for the repost, but it's been a year....
We have tcpsvd binding fb_inet_server processes to different port/address/root combinations but sharing a tmpfs lock folder and security2.fdb on the same server. Reading and writing to security2.fdb seems to be about the only significant IO on the root partition so I'm thinking about moving it onto a tmpfs too and symlinking back into /var/lib/firebird/2.5/system/security2.fdb.
(The users in the security database are fairly static and new ones are only created when we start and stop customers - i.e. I don't really care if it survives a reboot as I manage users from bash scripts already. )
However I think it would be neater if I could just tell fb_inet_server to use a different security database in a similar way to the lock file and root, and even better if I can give each fb_inet listener it's own security database.
Am I being thick and not seeing either:
1. an easy way to tell fb_inet_server where the security database is?
2. a glaring big hole in this plan that is going to bring it all crashing down around me?
So far (for the last 4 years) the only thing I've seen is that I need to be certain that processes accessing shared databases use the same lock folder otherwise bad things start to happen quickly. But I think if they get their own security2.fdb then they can probably get their own lock folders too, and truly all customers will have separate resources for all IO.