Coming Soon: nxMyDB and nxDistDB

[neoxed]

nxMyDB:
Shares users and groups amongst several ioFTPD sites.
Central MySQL Server database.
Adjustable connection pool (maintains multiple connections to the database server).
Optional compression and encryption (SSL) for network communication.
Periodically synchronizes the database with ioFTPD.

nxDistDB:
Shares users and groups amongst several ioFTPD sites.
No central server (which means no single point of failure if the DB server goes down).
Each ioFTPD server maintains a list of updates (transactions).
Transaction records are saved in a local SQLite v3 database.
These transaction records are shared with other ioFTPD sites.
If a server goes down, pending transactions are saved until it comes back online.
All network communication is encrypted with MatrixSSL (an SSL library).

Both of these modules are under rapid development. nxMyDB will be finished soon. nxDistDB on the other hand, will take much longer due to its complexity. :)

[zOrP]

neoxed... <3

Thnx for all ur amazing scripts...
this is just what we have been waiting for.

Nice to see someone still keeping ioftpd alive.

so nxMydb will be kinda like iosharedb without all the errors?

[neoxed]

I guess nxMyDB and ioShareDb are similar in concept, but their designs are quite different.

nxMyDB uses MySQL's GET_LOCK/RELEASE_LOCK for locking. ioShareDb uses site ID+locked column (which worked poorly, especially when the locked flag wasn't cleared).

nxMyDB uses the MySQL client library directly. ioShareDb uses ODBC.

The list could go on, but you get the idea. :)

[zOrP]

yeye.. very nice.

looking forward to it.

so will there be a workaround of the annyoing 1024 max users bug.
Sometimes when i add new servers to iosharedb, it gives the rather large id's, and it wont add new users.

i know its a ioftpd bug. But iosharedb makes it even worse.. hehe

[neoxed]

Nope, there's nothing I can do about that. ioFTPD tells the module which ID to use, so the module doesn't have a choice.

[zOrP]

I thought so..

well, only takes a couple of mins to fix manuel anyway..
:)

Keep up the good work..

[neoxed]

I will not be able to finish nxMyDB until I have a chance to correct a trivial design flaw in ioFTPD's module system.

These are the forward declarations for callbacks used by ioFTPD's module system:
INT32 UserCreate(char *userName);
INT UserRename(char *userName, INT32 userId, char *newName);
INT UserDelete(char *userName, INT32 userId);
INT UserLock(USERFILE *userFile);
INT UserUnlock(USERFILE *userFile);
INT UserOpen(char *userName, USERFILE *userFile);
INT UserWrite(USERFILE *userFile);
INT UserClose(USERFILE *userFile);

The problem is that ioFTPD does not pass a pointer to the USERFILE structure on "Rename" and "Delete" operations. This is a problem because I must be able access the lpInternal member of the USERFILE structure.

It is possible to work around this issue, but I don't want to write an unpleasant hack to cope with this oversight.

Note: This doesn't mean nxMyDB is dead; it's just on hold until I can make the appropriate changes to ioFTPD. :)

[pion]

"It is possible to work around this issue, but I don't want to write an unpleasant hack to cope with this oversight."

So we won't see a working module anytime soon? With a little deluser workaround, and renuser disabled? Pretty please, with sugar on top! :p