Hey everyone,
in this thead I will write down my experiences when setting up ioFTPD and an irc-bot. I tried this setup on two completly diffrent maschined: WIN7 and WIN10.
DOWNLOADING THE IOFTPD EXECUTABLE
It was not quite easy to get to the exec file, or even to understand what is the latest version of the ftpd and the scripts. So the current version of YIL of ioftpd I could not find in the forum so I had to get it from the "internet archive". The current version is 7.7.3. Prodigy compiled a new version 7.7.7 which even support TLS1.3 which you can find here:
https://www.flashfxp.com/forum/ioftp...7-7-first.html
DOWNLOADING CURRENT VERSION OF THE SCRIPTS: ioA, ioBanana, ioNINJA
I was not able to get ioA in the latest version 2.0.8. The only version I was able to find was 2.0.5. A download link for ioNINJA was not available anywhere on the forum so I asked on EFnet in the #ioftpd chan. Some nice dude sent me ioNiNJA.1.0.Beta5.rar (although the version tag in the TCL script says its Beta 4). ioNiNJA has a bot (windrop version 1.6.x) included. The current version is 1.8.4.
Henkie2 has re-uploaded the sources and the executables in this thread:
https://www.flashfxp.com/forum/16950/p86407-post1.html
CONFIGURING ioFTPD YIL VERSION 7.3.3
I had no problem setting up ioFTPD.YIL 7.7.3 version. Just follow the instructions in the ioftpd.ini setup VFS files, create a SSL certificate with "site makecert" and you are fine. This version of ioftpd is pretty stable. Only once or twice it crashed with Unhandled exception: Access Violation (0xC0000005).
There seems to be a problem though with SSL and TLS in this version. When I try to FXP with SSL/TSL from glFTPD sites. I get errors like this. Using prodigies version 7.7.7 solves this problem completly.
Code:
[glsite] RETR linux-iso-20181210.r07 ·
[glsite] 150 Opening BINARY mode data connection for linux-iso-20181210.r07 (50000000 bytes) using SSL/TLS.
[glsite] 435 Failed TLS negotiation on data channel (SSL_accept(): (1) error:1417D102:SSL routines:tls_process_client_hello:unsupported protocol), disconnected
[ioftpd] 426 Connection closed: SSL library failure (error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version).
This looks like an outdated SSL ioftpd library to me. I leave it as it is for now.
Installing ioFTPD as a service worked just fine for me, though it led to errors with the eggdrop. See next section for more info on that. By the way, yes, I have setup the ioftpd service to run from the same user who has administrator rights as the eggdrop.
CONFIGURING THE IRC-Bot: Version 1.6.17 vs 1.8.3 eggdrop
I decided to use ioNINJA for my irc-bot. The ioNiNJA.1.0.Beta5.rar had an /eggdrop directory included and ioNINJA readme explicitly tells you to use that included version of the eggdrop (windrop) for ioNINJA to work correctly. I tried to setup the included egddrop version 1.6.something.SSL but I could not manage to make it connect to a SSL irc-network. It just would not connect. It seems like some SSL problem. The only solution to make the bot connect was to update it to the current eggdrop version 1.8.3.SSL. From now on it connected just fine. From here on I used version 1.8.3.
Configuring ioNINJA / DZBOT is more or less strait forward. Interstingly it had some problem finding paths of c:\ioftpd\logs\ files. For some reason the variable holding it was ending up like this "eggdrop\c:\ioftpd\logs\ioftpd.log". I suppose this has something to do with the fact that I updated the eggdrop version to 1.8.3. I fixed that problem in the ioNINJA.TCL file by hand. Then the bot started to give notice.
Starting the eggdrop manually from commandline into the background with "eggdrop.exe" works. But strangly only some anounces work. NEWDIR and DELDIR do not work. Then there was some error that had a problem with "ioFTPD::Window" in one of the TCL procedures (the one that is figuring out the tagline). I just changed the TCL proc by hand to just return an empty string instead of a tagline and the script worked. This would make NEWDIR and DELDIR announces work.
Starting the eggdrop manually from commandline into the background with "eggdrop.exe" works. But strangly only some anounces work. (Or announced would not work at all, I dont remember anymore).
Starting eggdrop from inside of ioftpd (which was started manually) with a batch skript (site startbot) starts the bot into the background but NEWDIR and DELDIR do not get annonuced.
Starting eggdrop from inside of ioftpd (which was started as a service) with a batch skript (site startbot) that starts the bot, but it crashes immediatly.
Working solution so far: Patch the TCL script to return empty tagline. Start ioftpd manually (not as a serivce) and start eggdrop manually with "eggdrop -nt". This works, the NEWDIR gets announced but it is very unsatisfactory.
What about triggering commands from irc-channel?
It is possible to trigger commands from the channel, but those that interact with windows and get information from Windows crash the bot. Good example is the trigger: uptime. This procedure geathers a ton of information from the windows system. It gets them through the TWAPI (TCL-Windows API). I tried to figue out which call exactly makes the bot crash with a really stunning result.
If you run the bot manually as "eggdrop.exe -nt" most calls inside the TCL proc of !uptime do well. Some crash the bot. So I commented out those that make the bot crash. And it kind of works.
If you run the bot manually as "eggdrop.exe" all calls crash the bot on !uptime.
If you run ioftpd as a service run the bot manually as "eggdrop.exe" all calls crash the bot on !uptime AND ioftpd becomes unfuntional. You cannot login anymore. It stops at USER command of ftp with some error message. Restarting ioftpd makes it go away.
The version of TWAPI that is part of ioNINJA is 2.0. The current version is 4.3. I tried to update the TWAPI to 4.3. For some reason TCL does not manage to find newer versions of it. It needed more hacking and I left it as it is for now.
SUMMARY: If you port ioNInja to eggdrop 1.8.x
Start ioftpd.exe manually (not as a service). Update eggdrop to currect version and run it as "eggdrop -nt". Do not use !uptime or other commands that process data based on TWAPI.