ioFTPD v7.0.3 Released - Page 11

paja1 · 11-10-2009, 06:00 PM

Quote:

Originally Posted by Yil

paja1: I don't think you are doing anything wrong. I'm just trying to determine what separates people who are seeing this problem from those who aren't. Earlier indications showed that multi-core/multi-cpu machines were far more likely to have this issue (which means a race condition) and that w2k3 seemed like to make it more likely as well. I'm trying to finish up a bunch of changes for the folks playing with virtual directories and then implement the few changes I mentioned which hopefully will fix/reduce the problem further.

Yes, i'm running on windows 2003 server.
Yes, i do have dual core P4 CPU.

Quote:

Originally Posted by Yil

I'm also going to have to go back and double check, but it's possible that the TCL socket code changed internally when the TCL libraries were updated. If that is so then it's possible this is just highlighting the flaw more... I'll have to check on that since you said v6 didn't seem to have this issue in your configuration. Any chance you could try disabling the HTTP and/or EXEC routines for a bit to see if that improves stability?

OK, i can remove HTTP call for a while, will see if it helps. I'll keep you posted.

Thanks man!

SysOp · 11-14-2009, 08:24 AM

A quite strange thing.
ioFTPD crashs right after the time when a line like this "11-14-2009 20:00:00 Rejected auto-banned IP 111.222.33.44 ()." written into "Error.log". 111.222.33.44 is not any of my IPs. Maybe this IP keeps hammering the server, but how can this make the server crashed?
Tried to set Connections_To_Ban to a very large number OR set Temporary_Ban_Duration to a very small number. It works, however, this is not the way to solve problems, isn't it?

This problem applies to every ioFTPD v7.0.* versions (at least I've tested v7.0.0 & v7.0.3). Server's using various TCL scripts including ioNiNJA, nxTools, and several home-made scripts.

Yil · 11-20-2009, 08:02 AM

SysOp: Did you happen to turn on the no ident request feature in v7+? I forget who it was, but that does have a bug and the person reporting it actually sent in the one line fix too. As a workaround let it request the ident but you can use a 0 or 1 second timeout and all will work fine. If that isn't the cause I'll look for the issue locally as it should be easy to reproduce.

SysOp · 11-20-2009, 09:22 PM

Yes, I've turned on the no ident request feature in v7 by setting Ident_Timeout to zero.

And about the person who found the bug, is that me: https://oss.azurewebsites.net/forum/showpo...&postcount=108

But I also tried my own compiled version which has been added "pConnection->szIdent = NULL;" in Identity.c, it'll still crash if somebody hammer the server.

If I am not that person, please tell me how to fix this and I can compile by myself to test. Thank you very much.

SysOp · 11-21-2009, 10:14 AM

is this a typo?
Line 220 of File "./src/FtpBaseCommands.c": "AUTH SLL"
should it be "AUTH SSL"?

paja1 · 11-23-2009, 12:43 PM

Quote:

Originally Posted by Yil

paja1: I don't think you are doing anything wrong. I'm just trying to determine what separates people who are seeing this problem from those who aren't. Earlier indications showed that multi-core/multi-cpu machines were far more likely to have this issue (which means a race condition) and that w2k3 seemed like to make it more likely as well. I'm trying to finish up a bunch of changes for the folks playing with virtual directories and then implement the few changes I mentioned which hopefully will fix/reduce the problem further.

I'm also going to have to go back and double check, but it's possible that the TCL socket code changed internally when the TCL libraries were updated. If that is so then it's possible this is just highlighting the flaw more... I'll have to check on that since you said v6 didn't seem to have this issue in your configuration. Any chance you could try disabling the HTTP and/or EXEC routines for a bit to see if that improves stability?

Hi Yil,

so i've disabled HTTP calls, and kept just EXEC ... still the same, so looks like problem in "long" running exes is a problem.

Pavel

Yil · 12-01-2009, 04:36 PM

I think I taught ioFTPD about NTFS junctions/symlinks. You can now keep the current functionality which is to just ignore them entirely which might be needed for compatibility and in case the new features don't work right (IGNORE option). Or you can let the server keep file information just once for the target directory and create a placeholder link for the junction/symlink (SHARE option). For servers with tons of links this should reduce memory usage and it helps the server keep directory timestamps up to date and to track changes better. There is also another mode which I find particularly interesting. Not only does the server know about the links but it attempts to show them as links in listings by dynamically reverse resolving the target directory to a VFS path (SYMLINK option). This has two advantages to my mind. You can delete links in FTP clients like Flash without it trying to delete the contents of the directory itself, and it's obvious that you are dealing with a link and not a directory. The fake link itself has the same owner/timestamps/etc as the target directory automatically.

No matter what option you use, broken symlinks are now no longer hidden in listings and if you are a VM flagged user it will show you the real path that is missing as the target of the link. Permissions are set to 000 to make broken links stand out as well.

If you are using the SHARE/SYMLINK options you can also enable a safety feature which prevents accessing files/directories that are not explicitly exported via the VFS file. Thus a NTFS junction/symlink to c:\windows wouldn't work since it's unlikely you actually put that into a VFS file. Sort of a safety feature for badly formed links. This was never a worry with ioFTPD symlinks because they have to be valid VFS paths already.

I've got a ton of other changes, and a lot of testing still to do. I'll likely try to finish things up sometime next week and hopefully get a few of you to try out the new features as I'll need help testing so many low level internal changes.

Mave · 12-05-2009, 06:37 AM

Hey i still getting mass of error converting strings in my logs.
What kind of error is it anyway? What use to put them in the logs?
Would be nice to have a disable funktion cause it expands the log file tremendious.
Btw so after a year of waiting for ioYIL the project is canceled?? Darn

Greet

Yil · 12-05-2009, 04:51 PM

Mave: the converting string error is actually tied to me using a too small temp buffer when converting the name of the waitobject (I think it was) which was a feature ioNinja v0.8+ uses. It's fixed in the next release and you shouldn't see any more of those. I couldn't find it when it first showed up because I was using 0.7x and didn't realize that wasn't the latest ioNinja release so the problem never showed up for me.

Not really sure where ioYil is going. I actually put a fair amount of effort into it. The problem was it took a bunch of time to write useful features for me and future script writers. At that point though I decided some of it just made sense to put into the server itself for speed and easier use by other scripts. Several insanely useful things like ioArgs will be loved by any script writer and were definitely worth doing in the server. I haven't abandoned the project, but not sure where it's going right now...

Mave · 12-06-2009, 02:48 PM

A ok nice to hear the error convering string is soon history

Ok great to hear the ioYIL project didnt die. Well its even cooler since you can make ioYIL use those ones

Yil · 12-21-2009, 02:44 PM

Wrote a help command for the next release that takes simple .ini style files and looks up information and shows it to the user while running it through the cookie parser. Script writers can now create their own .ini files for their new commands and all users have to do is add the path to the file to the ioFTPD.ini file under [help].

I also wrote a separate TCL script that parses some simple section identifiers, colorizes the text by highlighting <args>, etc and then boxes the result by putting a border around everything. This parser can be used by script writers as well to get fancier output; all built-in commands will use this. This may also allow the help file to be translated into web pages and/or menu commands for FTP clients in the future.

I've started documenting the commands and am about 1/5 of the way through now. Hopefully this will make things easier for people in the future.

dink-puller · 12-21-2009, 04:29 PM

Man, I am so psyched about how you have rescued IO from the obsolescence. It's always been a badass, and it's just getting badder. Thanks so much.

mr.babek · 12-21-2009, 04:49 PM

Hey Yil,

Fantastic work! Good to see you diod not forget about IOyil! YEEHAW... would love to see it appear ....

keep up the good work

ArtX · 12-21-2009, 07:29 PM

if we leave out milk and cookies will santaYil give us a special present

Yil · 01-13-2010, 03:38 AM

Needless to say writing help files isn't the most interesting thing to do and thus I'm making slow progress as I get distracted easily... I did my first pass at all the site commands (minus site change) and most of the regular FTP commands but I put references to a few general topics like permissions and user flags that I never wrote up. I also found it necessary to try to strike a balance between what goes in the help file and what doesn't. Regular FTP commands are geared more towards regular users but even they require some documentation about why they can't delete or resume a file that it appears they could based on just directory permissions for instance. On the other hand site commands for SiteOps I felt could contain reference to settings in the .ini file that affected the command even if only the owner could modify it.

Based on that documentation work and looking at the code to try to make sure I got all the options I noticed a few holes or things that command didn't really do well so I've also modified/added a few new features as well.

I'm working on writing the ChangeLog up now as several people have sent me lockup/crash reports and while I learned nothing new, I'm hoping the next release can reduce or fix that so I'm just going to put what I got out there now. Not sure if it will have the help stuff included or not, or if another release will shortly follow this one with help and fixes to whatever I managed to break in this release. Remember, this has a some serious low level changes in directory caching to support NTFS reparse points, paths don't have to be fully resolved but can preserve symbolic links so the resolver got another overhaul, and the listing code had to change as well...

There are I'm guessing 50+ changelog entries so it will still take me a bit to make one line reminders into real entries and write some useful stuff about the new options in the .ini file but we should be talking days not weeks.