NeoXed's scripts nxAutoNuke, nxTools, etc. |
09-08-2007, 05:08 PM
|
#1
|
Too much time...
FlashFXP Beta Tester ioFTPD Scripter
Join Date: May 2003
Posts: 1,326
|
nxMyDB v0.1.0 - Alpha 1
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
Download
http://www.inicom.net/pages/en.ioftp...pts.php?id=227
Last edited by neoxed; 09-08-2007 at 05:19 PM.
|
|
|
09-09-2007, 04:25 AM
|
#3
|
Senior Member
FlashFXP Registered User ioFTPD Foundation User
Join Date: Jun 2004
Posts: 165
|
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...
Code:
09-09-2007 11:15:39 nxMyDB: v0.1.0 loaded, using MySQL Client Library v5.0.45.
|
|
|
09-09-2007, 08:02 AM
|
#4
|
Senior Member
Join Date: May 2007
Posts: 692
|
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.
|
|
|
09-09-2007, 12:43 PM
|
#5
|
Senior Member
FlashFXP Registered User ioFTPD Foundation User
Join Date: Jun 2004
Posts: 165
|
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...
|
|
|
09-09-2007, 01:37 PM
|
#6
|
Too much time...
FlashFXP Beta Tester ioFTPD Scripter
Join Date: May 2003
Posts: 1,326
|
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?
|
|
|
09-09-2007, 02:04 PM
|
#7
|
Senior Member
Join Date: May 2007
Posts: 692
|
don't think so, i've looked for it but found nothing
|
|
|
09-09-2007, 04:08 PM
|
#8
|
Too much time...
FlashFXP Beta Tester ioFTPD Administrator
Join Date: May 2005
Posts: 1,194
|
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.
|
|
|
09-09-2007, 04:54 PM
|
#9
|
Too much time...
FlashFXP Beta Tester ioFTPD Scripter
Join Date: May 2003
Posts: 1,326
|
Yes to all of the above. The functions I use from GetProc are:
Code:
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?
|
|
|
09-09-2007, 05:01 PM
|
#10
|
Too much time...
FlashFXP Beta Tester ioFTPD Scripter
Join Date: May 2003
Posts: 1,326
|
Looks like you've removed those three memory functions:
Code:
| 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.
Last edited by neoxed; 09-09-2007 at 05:13 PM.
|
|
|
09-09-2007, 06:24 PM
|
#11
|
Too much time...
FlashFXP Beta Tester ioFTPD Administrator
Join Date: May 2005
Posts: 1,194
|
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.
|
|
|
09-09-2007, 06:51 PM
|
#12
|
Too much time...
FlashFXP Beta Tester ioFTPD Administrator
Join Date: May 2005
Posts: 1,194
|
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...
|
|
|
09-09-2007, 08:18 PM
|
#13
|
Too much time...
FlashFXP Beta Tester ioFTPD Scripter
Join Date: May 2003
Posts: 1,326
|
I can wait until 6.3, I still have quite a bit of work left .
|
|
|
Thread Tools |
|
Display Modes |
Rate This Thread |
Linear Mode
|
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -5. The time now is 06:01 PM.
|