nxMyDB v0.1.0 - Alpha 1

[neoxed]

The first alpha release will not synchronize the local user and group cache (the refresh feature of ioShareDb). This will take a bit of work to implement properly.

Please use the latest version of MySQL Server v5.0!

Notes
Only use for testing purposes, not stable enough yet.
It was built in debug mode, so performance is a little slower.
I have only tested this on v5.8.5, not with v6.x - feedback welcome.

Changes
CHG: Initial release.

Download

http://www.inicom.net/pages/en.ioftpd-scripts.php?id=227

[neoxed]

See http://www.inicom.net/forum/showthread.php?t=12726 for the release schedule and missing features.

[hukker]

I wanted to test around a bit, using ioftpd 6.2.1... it doesnt seem to be doing anything at all atm, still keeps adding the users on the local computer users/groups way... doesnt load the module? Is the configuration maybe supposed to be added somewhere specific in ioftpd.ini, I added the modules settings and right after that the [nxMyDB] settings.

Tested ioFTPD-beta5-8-5r aswell... and sure enough its doing what its supposed to be doing here... it loads the module from what I could see in error.log? The message below popped up when I tried to connect to the fresh install of this ioftpd version... and I had no root dir setup... once I fixed that connection worked fine with the standard ioftpd account.
Added a user and tried connecting, that worked aswell...

09-09-2007 11:15:39 nxMyDB: v0.1.0 loaded, using MySQL Client Library v5.0.45.

[o_dog]

Tested With: 5.8.5

dunno if thats true or not, but following the install instructions in 6.2.1.0 doesn't do anything at all when adding users.

[hukker]

thats what I said aswell... 6.2.1 doesnt work.

ioftpd 5 8 5 works, I just mentioned that it was funny the msg I copied from error.log was infact in error.log and not in ioftpd.log, cause its not an error if you think about it...

[neoxed]

Interesting, thank you o_dog and hukker for your reports on v6.2.1. I will have to look into that.

Has Yil posted the source for 6.2 anywhere that anyone knows of?

[o_dog]

don't think so, i've looked for it but found nothing

[Yil]

Hmm... The USERFILE structure hasn't changed at all between 5.x and 6.x. So that shouldn't be an issue.

Do you just implement the 8 or so required user module functions and use the provided register/update functions? Or do you lookup other named functions via the GetProc module function? If so which registered functions do you access? I know a few of them definitely have changed and the memory allocation stuff isn't even in the very latest builds.

[neoxed]

Yes to all of the above. The functions I use from GetProc are:

RESOLVE("Config_Get", procTable.ConfigGet)
RESOLVE("Config_GetBool", procTable.ConfigGetBool)
RESOLVE("Config_GetInt", procTable.ConfigGetInt)
RESOLVE("Config_GetPath", procTable.ConfigGetPath)

RESOLVE("GetGroups", procTable.GetGroups)
RESOLVE("Gid2Group", procTable.Gid2Group)
RESOLVE("Group2Gid", procTable.Group2Gid)
RESOLVE("Ascii2GroupFile", procTable.Ascii2GroupFile)
RESOLVE("GroupFile2Ascii", procTable.GroupFile2Ascii)

RESOLVE("GetUsers", procTable.GetUsers)
RESOLVE("Uid2User", procTable.Uid2User)
RESOLVE("User2Uid", procTable.User2Uid)
RESOLVE("Ascii2UserFile", procTable.Ascii2UserFile)
RESOLVE("UserFile2Ascii", procTable.UserFile2Ascii)

RESOLVE("Allocate", procTable.Allocate)
RESOLVE("ReAllocate", procTable.ReAllocate)
RESOLVE("Free", procTable.Free)

RESOLVE("StartIoTimer", procTable.StartIoTimer)
RESOLVE("StopIoTimer", procTable.StopIoTimer)
RESOLVE("Putlog", procTable.Putlog)

I'll do some debugging to see where it gives up.

Where is the source published for 6.2?

[neoxed]

Looks like you've removed those three memory functions:

| 2968 | ProcTableInit | Unable to resolve procedure "Allocate".
| 2968 | ProcTableInit | Unable to resolve procedure "ReAllocate".
| 2968 | ProcTableInit | Unable to resolve procedure "Free".

I need access to ioFTPD's memory allocation system in order to use the Ascii2UserFile, UserFile2Ascii, and many functions in which ioFTPD allocates memory the caller has to free and vice versa.

[Yil]

Yup, that's almost definitely the problem. That was literally one of the very first changes I ever made to the source so I could use purify to try to find the 4k .ioftpd corruption issue. At the time I thought the name to address mappings were just for debugging purposes. I didn't realize the resolving procedure address was exported to modules who could use it and then make calls... I do remember searching the sources though :)

I'll get that fixed for 6.3 as well as a source update then. You have two short term solutions. In the very latest releases (6.2.2+?) I really am using malloc/free/realloc so just ignore the getproc result and use the actual addresses... In fact using 6.2.3 which doesn't trap exceptions and generate the c:\ioftpd.crash.log file might be a nice help during development.

The other option is to just use the released 6.1 sources and remove the #ifdef around the registering of the memory routines. I ended up changing the IoMemory.h file very shortly after commenting those out way back when and there is no need now for those functions to not be exported.

[Yil]

Crap. It just occurred to me that 6.2.3 might be a real debug build and as such the malloc/free calls are the actual memory routines BUT the code sticks a char * pointer for a descriptive comment on the front. This of course screws everything up...

6.2.1 I think is a release build that uses malloc/free so that might be OK.

Worst case use the 6.1 sources or wait for 6.3...

[neoxed]

I can wait until 6.3, I still have quite a bit of work left :p.