diff options
-rw-r--r-- | Changes | 1 | ||||
-rw-r--r-- | docs/BUGS | 4 | ||||
-rw-r--r-- | docs/DEFCON | 19 | ||||
-rw-r--r-- | docs/EVENTS | 305 | ||||
-rw-r--r-- | docs/INSTALL | 278 | ||||
-rw-r--r-- | docs/IRCD | 853 | ||||
-rw-r--r-- | docs/MODULES | 50 | ||||
-rw-r--r-- | docs/MYSQL | 79 | ||||
-rw-r--r-- | version.log | 6 |
9 files changed, 856 insertions, 739 deletions
@@ -4,6 +4,7 @@ Provided by Anope Dev. <dev@anope.org> - 2005 02/13 A Internal Event support, see EVENTS in the doc folder for help [ #00] 02/05 A Support for Unreal 3.2 +I channel mode. [ #00] 02/03 A Merged anope-win32 branch into the main, now Win32 ready. [ #00] +02/21 F Updated documentation for one style and small fixes. [ #00] 02/13 F nickIsServices() works if format is nick@services [ #00] 02/12 F Win32 builds can now build with encryption [ #00] 02/10 F mod_current_buffer was not set in all possible cases [#296] @@ -1,5 +1,5 @@ -Reported Bugs from Bugzilla: http://bugs.anope.org -=================================================== +Reported Bugs from Bugzilla: http://bugs.anope.org/ +--------------------------------------------------- .- Strange Segfault on expiring nicknames. Almost arbitrary, very hard to reproduce. diff --git a/docs/DEFCON b/docs/DEFCON index 1b7b169de..ba46744e8 100644 --- a/docs/DEFCON +++ b/docs/DEFCON @@ -1,7 +1,14 @@ Anope DefCon ------------ -Introduction: +1) Introduction +2) Installation +3) Configuration +4) Usage +5) Usage Example +6) Support + +1) Introduction Anope 1.6 onwards supports a unique protection mechanism based on the military "Defense Readiness Condition" (DefCon) system. It is based on @@ -20,7 +27,7 @@ Introduction: are running. Also to protect the users, primarily in the event of Clones and/or FloodBOT attacks. -Installation: +2) Installation The DefCon system is part of Anope's core, @@ -32,7 +39,7 @@ Installation: Make sure you restart Anope after changing the DefCon configuration directives. -Configuration: +3) Configuration Pre-defined DefCon actions: @@ -71,14 +78,14 @@ Configuration: The recommended default values are safe to use on any network. -Usage: +4) Usage Anope starts up in DEFCON5 (normal readiness). To change the Defcon level in action use: /msg OperServ DEFCON 1|2|3|4|5 -Example: +5) Usage Example Place the network on DEFCON4: @@ -104,7 +111,7 @@ Example: -Global- Services are now back to normal, sorry for any inconvenience -Support: +6) Support You might get DefCon support by posting on our online forum, or maybe on our #anope channel at /server irc.anope.org. diff --git a/docs/EVENTS b/docs/EVENTS index 594df325b..869257d31 100644 --- a/docs/EVENTS +++ b/docs/EVENTS @@ -1,156 +1,163 @@ -Internal Events +Anope Internal Events +--------------------- -1. Intro -2. Complex Events -3. Triggered Events -4. Triggered Events List +1) Intro +2) Complex Events +3) Triggered Events +4) Triggered Events List -============================================================================================== -1. Introduction to Internal Events -============================================================================================== +1) Introduction to Internal Events - Internal Events are setup to give module developers more information about what the core -is doing at different times. This information can be as complex as data we are feeding to the -uplink, to simple triggered events such as the databases being saved. A list of triggered -events can be found below. Additional there is a module included with the core which can -provide some clue as to how to use the code in your modules. The rest of this document assumes -that you are used to writting modules. + Internal Events are setup to give module developers more information + about what the core is doing at different times. This information can + be as complex as data we are feeding to the uplink, to simple triggered + events such as the databases being saved. A list of triggered events + can be found below. Additional there is a module included with the core + which can provide some clue as to how to use the code in your modules. + The rest of this document assumes that you are used to writting modules. -============================================================================================== -2. Complex Events -============================================================================================== +2) Complex Events - This type of events are based around what happens when we talk to the IRCD, much like -MESSAGE events that the IRCD sends to us. The events are triggered when Anope writes to the -ircd. To watch for these events you must have some knowledge of how the IRCD command system -works. In our example we will trap for NICK events. + This type of events are based around what happens when we talk to the + IRCd, much like MESSAGE events that the IRCD sends to us. The events + are triggered when Anope writes to the ircd. To watch for these events + you must have some knowledge of how the IRCd command system works. In + our example we will trap for NICK events. -A. All functions most be formatted as - - int functioname(char *source, int ac, char **av); - -B. In AnopeInit you must declare EvtMessage in some fashion, it is into this variable that - we will create the event handler. Here is what the base AnopeInit should look like at - this point. - - int AnopeInit(int argc, char **argv) - { - EvtMessage *msg = NULL; - int status; - - moduleAddAuthor(AUTHOR); - moduleAddVersion(VERSION); - return MOD_CONT; - } - -C. Pass "createEventHandler" the name of the message in this case NICK, and the function - that was created in Step A. At this point you should assign the return of - "createEventHandler" to the EvtMessage variable. - - msg = createEventHandler("NICK", my_nick); - -D. The Handler is not ready for use, now you must add it to the hash, with - "moduleAddEventHandler", you will want to pass to this function the return - of "createEventHandler" - - status = moduleAddEventHandler(msg); - - it will return the module error code so you can confirm that it was added - correctly. - -E. With that setup in your function you will be passed 3 items. The source most of the time - this will be set to ServerName or NULL, consult our ircd documentation about how messages - are formatted. AC is the count of variables you will find in AV. - - int my_nick(char *source, int ac, char **av) - { - alog("Internal Event - nick is %s",av[0]); - return MOD_CONT; - } - -============================================================================================== -3. Triggered Events -============================================================================================== - - These events also known as "event hooks" are internal events such as expiring of nicks to -the saving of databases. - -A. All functions most be formatted as - - int functioname(char *message); - -B. In AnopeInit you must declare EvtHook in some fashion, it is into this variable that - we will create the event handler. Here is what the base AnopeInit should look like at - this point. - - int AnopeInit(int argc, char **argv) - { - EvtHook *hook = NULL; - int status; - - moduleAddAuthor(AUTHOR); - moduleAddVersion(VERSION); - return MOD_CONT; - } - -C. Pass "createEventHook" the name of the event, in this case we are going to hook to the - saving of databases, "EVENT_DB_SAVING" - - hook = createEventHook(EVENT_DB_SAVING, my_save); - -D. The Handler is not ready for use, now you must add it to the hash, with - "moduleAddEventHook", you will want to pass to this function the return - of "createEventHook" - - status = moduleAddEventHook(hook); - - it will return the module error code so you can confirm that it was added - correctly. - -E. With that setup in your function you will be passed 1 items, the message is very simple - it could be as simple as a start, stop or message. In the case of saving it has a start - and stop - - int my_save(char *source) - { - - if (!stricmp(source, EVENT_START)) { - alog("Saving the databases! has started"); - } else { - alog("Saving the databases is complete"); - } - return MOD_CONT; - } - -============================================================================================== -4. Triggered Events List -============================================================================================== -| Event Hook | Event Argument | -============================================================================================== -| EVENT_DB_SAVING | EVENT_START, EVENT_STOP | -| EVENT_NEWNICK | Nick as it connected | -| EVENT_BOT_UNASSIGN | Channel name | -| EVENT_BOT_JOIN | Channel name | -| EVENT_BOT_CREATE | Bot Nick | -| EVENT_BOT_CHANGE | Bot Nick | -| EVENT_BOT_DEL | Bot Nick | -| EVENT_BOT_ASSIGN | Bot Nick | -| EVENT_TOPIC_UPDATED | Channel Name | -| EVENT_CHAN_EXPIRE | Channel Name | -| EVENT_CHAN_REGISTERED | Channel Name | -| EVENT_CHAN_DROP | Channel Name | -| EVENT_CHAN_FORBIDDEN | Channel Name | -| EVENT_CHAN_SUSPENDED | Channel Name | -| EVENT_CONNECT | EVENT_START, EVENT_STOP | -| EVENT_DB_EXPIRE | EVENT_START, EVENT_STOP | -| EVENT_RESTART | EVENT_START | -| EVENT_SHUTDOWN | EVENT_START, EVENT_STOP | -| EVENT_SIGNAL | Quit Message | -| EVENT_NICK_REGISTERED | Nick | -| EVENT_NICK_DROPPED | Nick | -| EVENT_NICK_FORBIDDEN | Nick | -| EVENT_NICK_EXPIRE | Nick | -| EVENT_CHANGE_NICK | Nick | -| EVENT_USER_LOGOFF | Nick | -============================================================================================== + A) All functions most be formatted as: + int functioname(char *source, int ac, char **av); + + B) In AnopeInit you must declare EvtMessage in some fashion, it is into + this variable that we will create the event handler. Here is what the + base AnopeInit should look like at this point: + + int AnopeInit(int argc, char **argv) + { + EvtMessage *msg = NULL; + int status; + + moduleAddAuthor(AUTHOR); + moduleAddVersion(VERSION); + return MOD_CONT; + } + + Note that AUTHOR and VERSION should be defined above the AnopeInit + function, just like you should do with any module. + + C) Pass "createEventHandler" the name of the message in this case NICK, + and the function that was created in Step A. At this point you should + assign the return of "createEventHandler" to the EvtMessage variable. + + msg = createEventHandler("NICK", my_nick); + + D) The Handler is not ready for use yet; now you must add it to the hash + with "moduleAddEventHandler". You will want to pass to this function + the return of "createEventHandler". + + status = moduleAddEventHandler(msg); + + It will return the same module error codes as adding a regular message, + which you can use to confirm it was added correctly. + + E) With that setup in your function you will be passed 3 items. The source + most of the time this will be set to ServerName or NULL; consult our + IRCd documentation about how messages are formatted. AC is the count of + variables you will find in AV. + + int my_nick(char *source, int ac, char **av) + { + alog("Internal Event - nick is %s",av[0]); + return MOD_CONT; + } + +3) Triggered Events + + These events also known as "event hooks" are internal events such as + expiring of nicks to the saving of databases. + + A) All functions most be formatted as: + + int functioname(char *message); + + B) In AnopeInit you must declare EvtHook in some fashion; it is into + this variable that we will create the event handler. Here is what + the base AnopeInit should look like at this point: + + int AnopeInit(int argc, char **argv) + { + EvtHook *hook = NULL; + int status; + + moduleAddAuthor(AUTHOR); + moduleAddVersion(VERSION); + return MOD_CONT; + } + + C) Pass "createEventHook" the name of the event. In this case we are + going to hook to the saving of databases, "EVENT_DB_SAVING". + + hook = createEventHook(EVENT_DB_SAVING, my_save); + + D) The Handler is not ready for use yet; now you must add it to the hash + with "moduleAddEventHook". You will want to pass to this function the + return of "createEventHook" + + status = moduleAddEventHook(hook); + + It will return the same module error codes as adding a regular message, + which you can use to confirm it was added correctly. + + E) With that setup in your function you will be passed 1 item. The message + is very simple; it could be as simple as a start, stop or message. In + the case of saving it has a start and stop. + + int my_save(char *source) + { + if (!stricmp(source, EVENT_START)) { + alog("Saving the databases! has started"); + } else { + alog("Saving the databases is complete"); + } + return MOD_CONT; + } + +4) Triggered Events List + + Here's a list of all event hooks we currently offer, with a description + of what argument is being passed to the event functions for this type of + event. + + Note that all events are emitted AFTER the action has taken place, so + any deleted nick/channel/etc won't exist anymore when your function is + being run. + + |------------------------|-------------------------------------------| + | Event Hook | Event Argument | + |------------------------|-------------------------------------------| + | EVENT_DB_SAVING | EVENT_START, EVENT_STOP | + | EVENT_NEWNICK | Nick that just connected to the network | + | EVENT_BOT_UNASSIGN | Channel name the bot is on | + | EVENT_BOT_JOIN | Channel name the bot is on | + | EVENT_BOT_CREATE | Nick of the bot involved | + | EVENT_BOT_CHANGE | Nick of the bot involved | + | EVENT_BOT_DEL | Nick of the bot involved | + | EVENT_BOT_ASSIGN | Nick of the bot involved | + | EVENT_TOPIC_UPDATED | Channel name of the channel involved | + | EVENT_CHAN_EXPIRE | Channel name of the channel involved | + | EVENT_CHAN_REGISTERED | Channel name of the channel involved | + | EVENT_CHAN_DROP | Channel name of the channel involved | + | EVENT_CHAN_FORBIDDEN | Channel name of the channel involved | + | EVENT_CHAN_SUSPENDED | Channel name of the channel involved | + | EVENT_CONNECT | EVENT_START, EVENT_STOP | + | EVENT_DB_EXPIRE | EVENT_START, EVENT_STOP | + | EVENT_RESTART | EVENT_START | + | EVENT_SHUTDOWN | EVENT_START, EVENT_STOP | + | EVENT_SIGNAL | Quit message sent | + | EVENT_NICK_REGISTERED | Nick of the account involved | + | EVENT_NICK_DROPPED | Nick of the account involved | + | EVENT_NICK_FORBIDDEN | Nick of the account involved | + | EVENT_NICK_EXPIRE | Nick of the account involved | + | EVENT_CHANGE_NICK | Nick of the user involved | + | EVENT_USER_LOGOFF | Nick of the user involved | + |------------------------|-------------------------------------------| diff --git a/docs/INSTALL b/docs/INSTALL index 2c1cd3883..634560f61 100644 --- a/docs/INSTALL +++ b/docs/INSTALL @@ -1,182 +1,184 @@ -ANOPE INSTALLATION INSTRUCTIONS -=============================== - -Table of contents ------------------ - 1. Installing Anope - 2. Upgrading Anope - 3. Setting up the IRCd - 4. Starting Anope - 5. Setting up a crontab +Anope Installation Instructions +------------------------------- + +1) Installing Anope +2) Upgrading Anope +3) Setting up the IRCd +4) Starting Anope +5) Setting up a crontab -You should also read the README and FAQ files! +Note: You should also read the README and FAQ files! -1. Installing Anope -------------------- +1) Installing Anope -IMPORTANT NOTE: it is not recommended to use (and therefore install) -Anope as root. Use an unprivileged user instead -- the one you're -using for the ircd or a dedicated one will be good enough. + IMPORTANT NOTE: it is not recommended to use (and therefore install) + Anope as root. Use an unprivileged user instead -- the + one you're using for the ircd or a dedicated one will + be good enough. -The very first thing you need to do is to get the Anope package -(if not already done). You can find it at the following place: + The very first thing you need to do is to get the Anope package (if not + already done). You can find it at: - http://www.anope.org/ - -Next, unpack the package in your home directory, and go into the -created directory. - -Now type ./Config to start the configuration script. It will -ask you a few questions, and figure out how to compile Anope on -your system. If you are unsure about the answer to a question, -use the default value. + http://www.anope.org/ + + Next, unpack the package in your home directory, and go into the created + directory. + + Now type ./Config to start the configuration script. It will ask you a + few questions, and figure out how to compile Anope on your system. If + you are unsure about the answer to a question, use the default value. + + NOTE: although you may specify different binary and data paths, it is + RECOMMENDED that you use the same value for both. + + You can now type make to compile Anope. If there are errors in the + Makefile, *try to use gmake* instead. If it still doesn't work, you (or + the system administrator if it's a shell) must install GNU make. You may + find it at ftp://prep.ai.mit.edu/pub/gnu/. -NOTE: although you may specify different binary and data paths, - it is RECOMMENDED that you use the same value for both. + Now type make install (or gmake install; see above). This will install + all the needed files in the paths you specified with the configure + script, and setup file permissions. You should ensure that the data + directory is not accessible by other users, as malicious users may + cause troubles on your network if passwords are not encrypted, or read + the memos of any user. -You can now type make to compile Anope. If there are errors in the -Makefile, *try to use gmake* instead. If it still doesn't work, you -(or the system administrator if it's a shell) must install GNU -make. You may find it at ftp://prep.ai.mit.edu/pub/gnu/. + If you see errors during this process, please mail us with the *complete* + error output, and don't forget to mention your OS, compiler and C library + versions. -Now type make install (or gmake install; see above). This will -install all the needed files in the paths you specified with the -configure script, and setup file permissions. You should ensure -that the data directory is not accessible by other users, as malicious -users may cause troubles on your network if passwords are not -encrypted, or read the memos of any user. + Now go into the data directory (by default, ~/services). Copy the example + configuration file (example.conf) to services.conf, and open the latter + with your favorite text editor. It contains all the configuration + directives Anope will use at startup. Read the instructions contained in + the file carefully. Using the default values is NOT a good idea, and will + most likely not work! -If you see errors during this process, please mail us with the -*complete* error output, and don't forget to mention your OS, -compiler and C library versions. + If you need help, you should subscribe to the Anope mailing list and mail + there to get help from other users. See the README file for more + information. -Now go into the data directory (by default, ~/services). Copy the -example.conf file to services.conf, and open the latter with your -favorite text editor. It contains all the configuration -directives Anope will use at startup. Read the instructions contained -in the file carefully. Using the default values is NOT a good idea, -and will most likely not work! +2) Upgrading Anope -If you need help, you should subscribe to the Anope mailing list and -mail there to get help from other users. See the README file for more -information. + If you got a .diff file and want to patch the old Anope sources with it, + do the following: + * Copy the .diff file into the root Anope sources directory. + * Type patch -p1 <file.diff -2. Upgrading Anope ------------------- + Note that upgrading anope with a patchfile isn't recommended. You should + download a new, clean source package, as this will give the best results. -If you got a .diff file and want to patch the old Anope sources with it, do -the following: - * Copy the .diff file into the root Anope sources directory. - * Type patch -p1 <file.diff + To upgrade Anope, just follow the installation instructions described in + section 1. There are however a few specific guidelines: -To upgrade Anope, just follow the installation instructions described in -section 1. There are however a few specific guidelines: + * IMPORTANT: Back up your old databases! + * If you are upgrading to a new major release, ALWAYS restart a + fresh configuration file from example.conf. - * IMPORTANT: Back up your old databases! - * If you are upgrading to a new major release, ALWAYS restart a - fresh configuration file from example.conf. +3) Setting up the IRCd + Services acts as an IRC server with pseudo-clients on it. To link them to + your network, you'll need to add some lines in the ircd.conf of their hub + server (as stated in the RemoteServer configuration directive). -3. Setting up the IRCd ----------------------- + For samples below we'll take services.localhost.net as the name of the + Services (as stated in the ServerName configuration directive). Note that + this samples are made to be as generic as possible, but there might be + small variations, depending on your IRCd. For IRCd-specific help with + configuration, read near the end of this section. -Services acts as an IRC server with pseudo-clients on it. To link -them to your network, you'll need to add some lines in the ircd.conf -of their hub server (as stated in the RemoteServer configuration -directive). + First, the C/N lines, that allow Services to link. They also need a + Y:line to work correctly. -For samples below we'll take Services.LocalHost.Net as the name of -the Services (as stated in the ServerName configuration directive). + Y:27:180:0:0:4000000 + C:127.0.0.1:mypass:services.localhost.net::30 + N:127.0.0.1:mypass:services.localhost.net::30 -First, the C/N lines, that allow Services to link. They also need a -Y:line to work correctly. + "mypass" is the same password you mentioned in the RemoteServer + configuration directive. 127.0.0.1 is the IP from which Services connect + from (linking in localhost is the most efficient way to run Services). -Y:27:180:0:0:4000000 -C:127.0.0.1:mypass:Services.LocalHost.Net::30 -N:127.0.0.1:mypass:Services.LocalHost.Net::30 + Then, you have to set-up an U:line, that will allow Services to change + channel modes, topics, and much more without being opped in the channel. -mypass is the same password you mentioned in the RemoteServer -configuration directive. 127.0.0.1 is the IP from which Services -connect from (linking in localhost is the most efficient way -to run Services). + U:services.localhost.net:*:* -Then, you have to set-up an U:line, that will allow Services to -change channel modes, topics, and much more without being opped -in the channel. + NOTE: if you have more than one server in your network, this line MUST + be added on ALL servers, or things won't work correctly. -U:Services.LocalHost.Net:*:* + Finally, you'll need to add an H:line, to make the OperServ JUPE command + work correctly. -NOTE: if you have more than one server in your network, this line -MUST be added on ALL servers, or things won't work. + H:*::Services.LocalHost.Net -Finally, you'll need to add an H:line, to make the OperServ JUPE -command work correctly. + Don't forget to /rehash your IRCd to apply changes. -H:*::Services.LocalHost.Net + A new trend in ircd configuration is popping all over the place, good + examples are the latest Hybrid, Unreal and Bahamut, which use a more + "readable" form of configuration. For those, use something like: -Don't forget to /rehash to apply changes. + link services.localhost.net + { + username *; + hostname localhost; + bind-ip *; + port 6667; + hub *; + password-connect "mypass"; + password-receive "mypass"; + class servers; + }; -A new trend in ircd configuration is popping all over the place, -good examples are the latest Hybrid and Unreal, which use a more -"readable" for of configuration. For those, use something like: + Note that this block-style configuration files differ heavily, depending + on the IRCd. Consult the interactive link maker (link is below) for more + details on the exact configuration used by your IRCd. -link Services.LocalHost.Net -{ - username *; - hostname localhost; - bind-ip *; - port 6667; - hub *; - password-connect "mypass"; - password-receive "mypass"; - class servers; -}; + If you're unable to get a link with your IRCd after reading this section, + you might try the interactive link maker, which is located at: -If you're unable to get a link with your IRCd after reading this section, -you might try the interactive link maker, which is located at: + http://heinz.anope.org/ilm.php - http://heinz.anope.org/ilm.php +4) Starting Anope + Go into the directory where binaries were installed (by default, this is + ~/services). Type ./services to launch Anope. -4. Starting Anope ------------------ + If there are syntax errors in the configuration file they will be + displayed on the screen. Correct them until there are no errors anymore. + A successful startup won't generate any message. -Go into the directory where binaries were installed (by default, -~/services). Type ./services to launch Anope. + Give Services at least one minute to link to your network, as certain + IRCds on some OSes may be really slow for the link process. If nothing + happens after about a minute, it is probably a configuration problem. Try + to launch Anope with ./services -debug -nofork to see any errors that it + encounters, and try to correct them. -If there are syntax errors in the configuration file they will be -displayed on the screen. Correct them until there are no errors -anymore. A successful startup won't generate any message. + If you need help to solve errors, feel free to subscribe to the Anope + mailing list and ask there. See the README file for details. -Give to Services at least one minute to link to your network, as -certain IRCds on some OSes may be really slow for the link process. -If nothing happens then, it is probably a configuration problem. -Try to launch Anope with ./services -debug -nofork to see any errors -that it encounters, and try to correct them. +5) Setting up a crontab -If you need help to solve errors, feel free to subscribe to the -Anope mailing list and ask there. See the README file for details. + A crontab entry will allow you to check periodically whether Anope is + still running, and restart it if not. You'll need to have Anope binaries + and data installed in the same directory for this to work without + modification. + First rename the example.chk script that is in Anope path (by default, + this is ~/services) to services.chk and edit it. You'll need to modify + the CONFIGURATION part of the file. Then ensure that the file is marked + as executable by typing chmod +x services.chk, and try to launch the + script to see if it works (Anope must not be running when you do this ;)) -5. Setting up a crontab ------------------------ + When this is done, you'll have to add the crontab entry. Type crontab -e. + This will open the default text editor with the crontab file. Enter the + following (with correct path): -A crontab entry will allow you to check periodically whether Anope -is still running, and restart it if not. You'll need to have -Anope binaries and data installed in the same directory for this to -work without modification. + */5 * * * * /home/ircd/services/services.chk >/dev/null 2>&1 -First rename the example.chk script that is in Anope path (by default, -~/services) to services.chk and edit it. You'll need to modify the -CONFIGURATION part of the file. Then ensure that the file is marked as -executable by typing chmod +x services.chk, and try to launch the script -to see if it works (Anope must not be running when you do this ;). + The */5 at the beginning means "check every 5 minutes". You may replace + the 5 with other another number if you want (but less than 60). Consult + your system's manual pages for more details on the syntax of the crontab + file. Interesting manpages are crontab(5), crontab(1) and cron(8). -When this is done, you'll have to add the crontab entry. Type crontab -e. -This will open the default text editor with the crontab file. Enter the -following (with correct path): -*/5 * * * * /home/ircd/services/services.chk >/dev/null 2>&1 -The */5 at the beginning means "check every 5 minutes". You may replace -the 5 with other another number if you want (but less than 60). -Save and exit, and it's installed. + Save and exit, and it's installed. @@ -1,466 +1,557 @@ -HOW TO ADD IRCD SUPPORT - -1. Files to edit -2. Modifing the header file -3. The code -4. Modes -5. Functions / Events -6. CAPAB/PROTOCTL - -============================================================================================= +How To Add IRCd Support +----------------------- + +1) Files to Edit +2) Modifing the Header File +3) The Code +4) Modes +5) Functions / Events +6) CAPAB/PROTOCTL + +1) Files to Edit + + When preparing to add support to Anope for your ircd, you need to edit + the following files. + + A) Make a copy of the .c and .h file of the IRCd that matches the ircd + that you are attempting to add support for best. + B) Make a backup copy of include/services.h, include/sysconf.h.in + C) Make a backup copy of Config and configure.in + + First step in this process is to rename the .c and .h file after the IRCd + that you are going to be adding support for. Its recommened that you come + up with a name that is clear and easy to understand. + + Now that you have the files that you will need to create your own ircd + support, starting with Config. This file is a shell script file; scroll + down untill you find the list of ircs for the user to select. Indicate + the based ircd version which is supported such as a series 1.x or 2.2.x, + placing in the comment side an exact version that the support is for or + "experimental" if you are not the ircd developer. The next step is to + decide how the IRCd will be defined, following the existing examples edit + 'IRCTYPE_DEF="IRC_RATBOX"' to be the descriptive define for your ircd. + + With the Config file ready to go, edit configure.in and find in there the + reference to --with-ircd. You should see see the various other ircds, and + you will want to add yours in there using the same IRC_ name you came up + with above. Important in this step is to make sure that you set the + IRCDFILE to the name of the .c file you set in step 1. Once you have the + configure.in created you can remove the old configure and at the command + prompt type "autconf"; this will generate the new configure file. + + Getting close to actually modify code. Open sysconf.h.in and add two + lines for your given ircd, which is similar to this: + + /* "First IRCD type" */ + #undef IRC_RATBOX + + Open services.h and add a line with the rest of the ircd include files to + match the name of the .h file you set in step 1. + + #include "ratbox.h" + + Taking the .c and .h file open them and replace the #ifdef IRC_* with the + IRC_ name you set in step two. Ensure that the code comments at the top + of the file match the ircd that the code will be for. + + You are now ready to start getting into the code. + +2) Modifing the Header File + + Now that you have gotten past the first part of the creation process, you + are into the code. This part is the harder and more complex part. You + will need a general understanding of C code to continue. Here are the + step by step instructions required to make this work. + + Open the .h file and find the section of code with + + #define PROTECT_SET_MODE "+" + #define PROTECT_UNSET_MODE "-" + #define CS_CMD_PROTECT "PROTECT" + #define CS_CMD_DEPROTECT "DEPROTECT" + #define FANT_PROTECT_ADD "!protect" + #define FANT_PROTECT_DEL "!deprotect" + #define LEVEL_PROTECT_WORD "AUTOPROTECT" + #define LEVELINFO_PROTECT_WORD "PROTECT" + #define LEVELINFO_PROTECTME_WORD "PROTECTME" + + If the ircd supports a protective/admin (not owner) mode, set the + PROTECT_SET_MODE and PROTECT_UNSET_MODE to be that mode. On most ircds + it's usermode "a" so you will be setting it to "+a" and "-a". The next + two are based more on what this mode is called. When you message ChanServ + to get this mode, this is the command you will be using. After this are + the fantasy commands which can be used in channel to get these modes. The + next three relate to the ACCESS LEVEL list system. Again these are the + words to gain these levels in the ACCESS LEVEL system. If your ircd does + not have these functions, leave them at what ever value is currently set; + the core code will ignore the request of the user. + + Now that this is set, you can define the MODES. All user modes are stored + with UMODE_ followed by a letter matching the modes case; be careful to + use the correct case as this will make it clear when you setup MODES in + the .c in a few. Use hex values for the modes so starting at 0x00000001 + to 0x8000000. In most cases you want to list all modes. If you run out of + values look at removing any modes that do not impact services. + + Channel modes are done much like user modes, with the exception that + bans, exceptions, invites, and modes that are applied to a user such as + op and voice are not defined here. All other modes are defined in here. + Again be clear and use the correct case and use hex values as done with + user modes. + + Finally we come to DEFAULT_MLOCK; this is the mode that services will set + by default on channels when they are registered. In general you want this + to be whats acceptable by the ircd; in most cases this is "+nt" + +3) The Code + + Here is where the code of the .c file comes in. Be prepared to spend at + least an hour, if not longer, going over the code and getting it right; + Especially if you are setting up an ircd that is completely different + than the one you used as a base. This section covers the majority of the + code that is in use. + + The first bit of code you will face is: + + const char version_protocol[] = "Ratbox IRCD"; + + This the protocol name which will appear in various places; especially + when you do -version at the command prompt, this is where you state the + server name. The version is not always needed unless you are showing that + the support is for one branch of a ircd family, such as Unreal 3.1 and + Unreal 3.2. + + Once you have decided on this little piece of code, you will come to + flood mode characters being used for setting and removing. If your IRCd + does not support flood modes, you can just use ""; we will be setting if + your IRCD supports flooding or not in a little bit. + + const char flood_mode_char_set[] = "+f"; + const char flood_mode_char_remove[] = "-f"; + + The next task that you will face is setting whether the IRCD sends time + stamps on modes but does not tell us that it will do so. If it does, set + UseTSMODE to 1; if it does not set it to be 0. If you're not sure refer + to your IRCd's documentation on how MODE is sent. + + int UseTSMODE = 0; + + Now you've come to the part where you setup your ircd. There are two + structs which hold this information; This allows you to quickly setup + your specific ircd. + + IRCDVar ircd[] = { } + + This struct contains your basic IRCd functions. Your base source file has + the list of all available variables; note that you should not swap any + around, or you will break stuff. Here is a brief description of the usage + of each. + + 1) Name: This member tells Anope about the IRCD's name. It may contain + text about it's name and version. This is used to identify the + build on startup. + + 2) NickServ Mode: This is the user mode set by Anope on NickServ. + Normally you want this to be some form of oper flag, + or a services flag. + + 3) ChanServ Mode: This is the user mode set by Anope on ChanServ. + Normally you want this to be some form of oper flag, + or a services flag. + + 4) MemoServ Mode: This is the user mode set by Anope on MemoServ. + Normally you want this to be some form of oper flag, + or a services flag. + + 5) HostServ Mode: This is the user mode set by Anope on HostServ. + Normally you want this to be some form of oper flag, + or a services flag. Note that if your ircd does not + support HostServ, you can safely make this NULL or +, + as there is a check before bringing HostServ online. + + 6) OperServ Mode: This is the user mode set by Anope on OperServ. + Normally you want this to be some form of oper flag, + or a services flag. + + 7) BotServ Mode: This is the user mode set by Anope on BotServ. + Normally you want this to be some form of oper flag, + or a services flag. + + 8) HelpServ Mode: This is the user mode set by Anope on HelpServ. + Normally you want this to be some form of oper flag, + or a services flag. + + 9) DevNull Mode: This is the user mode set by Anope on DevNull. + Normally you want this to be some form of oper flag, + or a services flag. -1. FILES TO EDIT + 10) Global Mode: This is the user mode set by Anope on Global. + Normally you want this to be some form of oper flag, + or a services flag. -When preparing to add support to Anope for your ircd, you need to edit the -following files. + 11) NickServ Alias Mode: This is the user mode set by Anope on the alias + of NickServ. Normally you want this to be some + form of oper flag, or a services flag. -A. Make a copy of the .c and .h file of the IRCD that closely matches the ircd - that you are attempting to add support for. -B. Make a backup copy of include/services.h, include/sysconf.h.in -C. Make a backup copy of Config and configure.in + 12) ChanServ Alias Mode: This is the user mode set by Anope on the alias + of ChanServ. Normally you want this to be some + form of oper flag, or a services flag. -First step in this process is to rename the .c and .h file after the IRCD that you are going -to be adding support for. Its recommened that you come up with a name that is clear and easy -to understand. + 13) MemoServ Alias Mode: This is the user mode set by Anope on the alias + of MemoServ. Normally you want this to be some + form of oper flag, or a services flag. -Now that you have the files that you will need to create your own ircd support. Starting with -Config, this file is a shell script file, scroll down till you find the list of ircds for the -user to select. Indicate the based ircd version which is supported such as a series 1.x or 2.2.x, -placing in the comment side an exact version that the support is for or "experimental" if you -are not the ircd developer. The next step is to decide how the IRCD will be defined, following -the existing examples edit " IRCTYPE_DEF="IRC_RATBOX" " to be the descriptive define for your -ircd. + 14) HostServ Alias Mode: This is the user mode set by Anope on the alias + of MemoServ. Normally you want this to be some + form of oper flag, or a services flag. Note that + if your ircd does not support HostServ, you can + safely make this NULL or +, as there is a check + before bringing HostServ online. -With the Config file ready to go, edit configure.in and find in there the reference to ---with-ircd, you should see see the various other ircd, and you will want to add yours in there -using the same IRC_ name you came up with above. Important in this step is to make sure that you -set the IRCDFILE to the name of the .c file you set in step 1. Once you have the configure.in -created you can remove the old configure and at the command prompt type "autconf", this will -generate the configure file. + 15) OperServ Alias Mode: This is the user mode set by Anope on the alias + of OperServ. Normally you want this to be some + form of oper flag, or a services flag. -Getting close to actually modify code. Open sysconf.h.in and add two lines for your given ircd -which is similar to this + 16) BotServ Alias Mode: This is the user mode set by Anope on the alias + of BotServ. Normally you want this to be some + form of oper flag, or a services flag. -/* "First IRCD type" */ -#undef IRC_RATBOX + 17) HelpServ Alias Mode: This is the user mode set by Anope on the alias + of HelpServ. Normally you want this to be some + form of oper flag, or a services flag. -Open services.h and add a line with the rest of the ircd include files to match the name of the -.h file you set in step 1. + 18) DevNull Alias Mode: This is the user mode set by Anope on the alias + of DevNull. Normally you want this to be some + form of oper flag, or a services flag. -#include "ratbox.h" + 19) Global Alias Mode: This is the user mode set by Anope on the alias + of Global. Normally you want this to be some form + of oper flag, or a services flag. -Taking the .c and .h file open them and replace the #ifdef IRC_* with the IRC_ name you set in -step two. Ensure that the code comments at the top of the file match the ircd that the code -will be for. + 20) BotServ Bots Mode: This is the user mode set by Anope on all BotServ + bots. Normally you want this to be a some form of + service or bot flag; you can use + for no mode at + all. -You are now ready to start getting into the code. + 21) Max Channelmode Symbols: This is the total number of possible channel + modes that can appear before a nick. Do + remember to count each possible mode, so +ov + is 2. -============================================================================================= + 22) Modes to Remove: This is every mode that Anope should remove when + stripping channel modes. -2. Modifing the header file + 23) Channelmode for bots: When a BotServ bot joins a channel, this is the + mode set on them. Normally you will want them + opped (+o), and protected (+a) on IRCd's that + support it. -Now that you have gotten past the first part of the creation process. You are into the code -this part is the harder and more complex part. You will need a general understanding of C -code to continue. Here are the step by step instructions required to make this work. + 24) SVSNICK: Can the ircd use SVSNICK to change someones nick? Otherwise, + KILL is used. Use 1 for yes, 0 for no. -Open the .h file and find the section of code with + 25) VHOST: Can a user's host be changd on the fly? Enabling this allow + HostServ online. Use 1 for yes, 0 for no. -#define PROTECT_SET_MODE "+" -#define PROTECT_UNSET_MODE "-" -#define CS_CMD_PROTECT "PROTECT" -#define CS_CMD_DEPROTECT "DEPROTECT" -#define FANT_PROTECT_ADD "!protect" -#define FANT_PROTECT_DEL "!deprotect" -#define LEVEL_PROTECT_WORD "AUTOPROTECT" -#define LEVELINFO_PROTECT_WORD "PROTECT" -#define LEVELINFO_PROTECTME_WORD "PROTECTME" + 26) OWNER: Has a channel umode for being the channel owner. For example, + UnrealIRCd has mode +q. Use 1 for yes, 0 for no. -If the ircd supports a protective/admin (not owner) mode, set the PROTECT_SET_MODE and -PROTECT_UNSET_MODE to be that mode. On most ircd its the mode of "a" so you setting it -to "+a" and "-a". The next to are based more on what this mode is called, when you -message ChanServ to get this mode, this is the command you will be using. Following -that comes the fantasy commands which can be used in channel to get these modes. The next -three relate to the ACCESS LEVEL list system, again these are the words to gain these -levels in the ACCESS LEVEL system. If your ircd does not have these functions, leave -them at what ever value is currently set, the core code will handle ignore the request -of the user. + 27) OWNER MODE SET: What mode to set to make someone the owner. If the + IRCd doesn't support owners, set this to NULL. -Now that this is set, you can define the MODES, all user modes are stored with UMODE_ -followed by a letter matching the modes case, be careful to use the correct case as this -will make it clear when you setup MODES in the .c in a few. Use hex values for the modes -so starting at 0x00000001 to 0x8000000, in most cases you want to list all modes. If you -run out of values look at removing any modes that do not impact services. + 28) OWNER MODE UNSET: What mode to unset to take away someone's channel + owner status. If the IRCd doesn't support owners, + set this to NULL. -Channel modes are done much like user modes, with the exception that, bans, exceptions, -invites, and modes that are applied to a user such as op, voice are not defined here. All -other modes are defined in here. Again be clear and use the correct case and use hex values -as done with user modes. + 29) Mode on Nick Register: What mode to give users when they register + with NickServ. If your ircd doesn't set expect + a mode to be set on registration, you should + set this to NULL. -Finally we come to DEFAULT_MLOCK, this is the mode that services will set by default on channels -when they are registered. In general you want this to be whats acceptable by the ircd, in most -cause this is "+nt" + 30) Mode on Nick Unregister: What mode to set give users when they cancel + their registration with NickServ. If your + IRCd doesn't set a mode for registered users + you should set this to NULL. -============================================================================================= + 31) Mode on Nick Change: What mode to give users when they change their + nick. If your ircd doesn't set a mode, you + should set this to NULL. -3. The Code + 32) SGLINE: Does the IRCd support realname (geocs) bans? Use 1 for yes, + 0 for no. - Here is where the code of the .c file comes in. be prepared to spend at least an hour if -not longer going over the code and getting it right especially if you are setting up an ircd -that is completely different then that which your adding support for. This section goes over -the majority of the code that is in use. + 33) SQLINE: Does the IRCd support nick bans? Use 1 for yes, 0 for no. - First bit of code you will face is + 34) SZLINE: Does the IRCd support SZLINES? Use 1 for yes, 0 for no. -const char version_protocol[] = "Ratbox IRCD"; + 35) HALFOP: Is channelmode +h for halfop supported by the IRCd? Use 1 for + yes, 0 for no. - This the protocol name which will appear in various places especially when you do -version -at the command prompt, this where you state the server name, the version is not always needed -unless you are showing that the support is for one branch of a ircd family, such as Unreal 3.1 -and Unreal 3.2 + 36) Number of Server Args: When an IRCd connects, this is the number of + parameters that are passed. - Once you have decided on this little piece of code, you will come to flood mode characters -being used for setting and removing. If your IRCD does not support flood modes, you can just -use "", we will be setting if your IRCD supports flooding in a little bit. + 37) Join to Set: Services must join a channel to set any modes on that + channel. Use 1 for yes, 0 for no. -const char flood_mode_char_set[] = "+f"; -const char flood_mode_char_remove[] = "-f"; + 38) Join to Message: Services must join a channel to send any message to + that channel (cannot override +n). Use 1 for yes, + 0 for no. - The next task that you will face is setting whether the IRCD sends time stamps on modes but -does not tell us that it will do so. If it does set UseTSMODE to 1, if it does not set it to be 0, -if your not sure refer to your IRCD's documentation on how MODE is sent + 39) Exceptions: Support for channel exceptions (mode +e). Use 1 for yes, + 0 for no. -int UseTSMODE = 0; + 40) TS Topic Forward: Some IRCd's (like UnrealIRCd) like their topic TS + set forward by +1. Use 1 for yes, 0 for no. - Now you come to the part where you setup your ircd, there are two struct which hold this -information. This allows you to quickly setup your specific ircd. + 41) TS Topic Backward: Some IRCd's (mainly older DreamForge-like ones) + like their topic TS set back by -1. Use 1 for yes, + 0 for no. -IRCDVar ircd[] = { } + 42) Protected Umode: UMODE_ define that defines the protected usermod. + Use 0 for no support, or enter the UMODE_ define. -This contains your basic ircd functions, here is a brief description of the -usage of each. + 43) Admin: Support for channel admins (Mainly used by UltimateIRCd). Use + 1 for yes, 0 for no. -1. Name : this member tells Anope about the ircds name, it may contain text about its - name and version. This is used to identify the build on startup. + 44) SQline Channels: The IRCd's supports banning channel names via + SQLINES. Use 1 for yes, 0 for no. -2. NickServ Mode : this is the user mode set by Anope, normally you want this to be a - some form of oper flag, or service flag. + 45) Quit On Kill: When we (SVS)KILL a user, does the IRCd send back a + QUIT message for that user? Use 1 for yes, 0 for no. -3. ChanServ Mode : this is the user mode set by Anope, normally you want this to be a - some form of oper flag, or service flag. + 46) SVSMODE -b: We can use SVSMODE to unban hosts from a channel. Use + 1 for yes, 0 for no. -4. MemoServ Mode : this is the user mode set by Anope, normally you want this to be a - some form of oper flag, or service flag. + 47) Protect: Support for channel protect (mode +a, mainly being used by + UnrealIRCd and ViagraIRCd). Use 1 for yes, 0 for no. -5. HostServ Mode : this is the user mode set by Anope, normally you want this to be a - some form of oper flag, or service flag. - note if your ircd does not support hostserv, - you can make this NULL or +, as there is a check used before bringing hostserv online + 48) Reverse: We can do a reverse check when unbanning. For use with + DreamForge based IRCd's. Use 1 for yes, 0 for no. -6. OperServ Mode : this is the user mode set by Anope, normally you want this to be a - some form of oper flag, or service flag. + 49) Register Channels: Supports sending a channelmode for registered + channels. Use 1 for yes, 0 for no. -7. BotServ Mode : this is the user mode set by Anope, normally you want this to be a - some form of oper flag, or service flag. + 50) Registered Mode: Channelmode to set on registered channels, see the + option above. Use 1 for yes, 0 for no. -8. HelpServ Mode : this is the user mode set by Anope, normally you want this to be a - some form of helper flag, or service flag. + 51) vIdent: Support for including a user's ident in their vHost. Use + 1 for yes, 0 for no. -9. Dev/Null Mode : this is the user mode set by Anope, normally you want this to be a - some form of user flag, or service flag. + 52) SVSHOLD: Support for temporarely 'holding' a nick, instead of using + a nick enforcer client. Use 1 for yes, 0 for no. -10. Global Mode : this is the user mode set by Anope, normally you want this to be a - some form of oper flag, or service flag. + 53) TS on MODE: We need to send a timestamp when modes are being changed. + Use 1 for yes, 0 for no. -11. NickServ Alias Mode : this is the user mode set by Anope, normally you want this to be a - some form of oper flag, or service flag. + 54) NICKIP: The IP address of new users is being sent along with their + hostname when new users are being introduced on the network. + Use 1 for yes, 0 for no. -12. ChanServ Alias Mode : this is the user mode set by Anope, normally you want this to be a - some form of oper flag, or service flag. + 55) Umode: We can use OperServ to change a user's mode. Use 1 for yes, + 0 for no. -13. MemoServ Alias Mode : this is the user mode set by Anope, normally you want this to be a - some form of oper flag, or service flag. + 56) O:LINE: We can use OperServ to give some user a temporary O:LINE. + Use 1 for yes, 0 for no. -14. HostServ Alias Mode : this is the user mode set by Anope, normally you want this to be a - some form of oper flag, or service flag. - note if your ircd does not support hostserv, - you can make this NULL or +, as there is a check used before bringing hostserv online + 57) Vhost On Nick: On NICK the IRCd sends the VHOST. Use 1 for yes, + 0 for no. -15. OperServ Alias Mode : this is the user mode set by Anope, normally you want this to be a - some form of oper flag, or service flag. + 58) Change Realname: Change real name. Use 1 for yes, 0 for no. -16. BotServ Alias Mode : this is the user mode set by Anope, normally you want this to be a - some form of oper flag, or service flag. + 59) Extra Help: If the IRCd has more help for functions in ChanServ than + the default help, you should put the language string + identifier here. Use 0 for no extra help. -17. HelpServ Alias Mode : this is the user mode set by Anope, normally you want this to be a - some form of helper flag, or service flag. + 60) No Knock: CMODE_ that defines NO KNOCK. Use 0 for no support. -18. Dev/Null Alias Mode : this is the user mode set by Anope, normally you want this to be a - some form of user flag, or service flag. + 61) Admin Only: CMODE_ that defines Admin Only. Use 0 for no support. -19. Global Alias Mode : this is the user mode set by Anope, normally you want this to be a - some form of oper flag, or service flag. + 62) Default MLock: Default channelmodes for MLOCK. Use 0 for no modes. -20. BotServ's Bots Mode : this is the user mode set by Anope, normally you want this to be a - some form of service flag, you can use + for no mode at all + 63) Vhost Umode: UMODE_ that indicates if the user currently has a vHost. + Use 0 for no support. -20. Max Channel Mode Symbols : this is the total number of possible, channel modes that can - appears before a nick. Remember to count each possible mode, so +ov is 2 + 64) Flood Mode: The IRCd has a channelmode for blocking floods. Use 1 for + yes, 0 for no. -21. Modes to Remove : this is every mode that Anope should remove when stripping channel modes + 65) Link Mode: The IRCd has a channelmode for linking a channel to some + other channel. Use 1 for yes, 0 for no. -22. Mode used by BotServ bots : When a BotServ bot joins a channel, this is the mode set on them - normally you want them to protected and oped (+o) + 66) CMode F: CMODE_ that defines flood mode. Use 0 for no support. -23. SVSNICK : can the ircd use svsnick to change someones nick, otherwise kill is used, 1 = yes - 0 = no + 67) CMode L: CMODE_ that defines link mode. Use 0 for no support. -24. VHOST : can change a users host on the fly - enabling this will allow hostserv online, 1 = yes - 0 = no + 68) Check Nick ID: "on check change check if they should remain + identified" (needs a better description) + Use 1 for yes, 0 for no. -25. OWNER : has a channel umode for owning the channel, example Unreal has +q, 1 = yes - 0 = no + 69) No Knock Requires +i: Does the No Knock channel mode require invite + only channels? Use 1 for yes, 0 for no. -26. OWNER MODE SET : what mode to set to make someone the owner, if the ircd doesn't support owners, set - this to NULL + 70) Chan Modes: If sent in CAPAB/PROTOCOL, we store it in here. This is + NULL by default. -27. OWNER MODE UNSET : what mode to unset to take away someone as owner, if the ircd doesn't support - owners, set this to NULL + 71) Tokens: Can we use tokens to talk to the IRCd? Use 1 for yes, + 0 for no. -28. Mode on Nick Register : what mode to set on NickServ registration if your ircd doesn't set a mode, set - this to NULL + 72) Token Case Senstive: Are the IRCd's TOKENS/COMMANDS case senstive? + Use 1 for yes, 0 for no. -29. Mode on Nick Unregister : what mode to set on NickServ unregistration if your ircd doesn't set a mode, set - this to NULL + 73) base64 SJOIN TS: Are the timestamps sent with a SJOIN in base64? Use + 1 for yes, 0 for no. -30. Mode on Nick Change : what mode to set on nick change if your ircd doesn't set a mode, set - this to NULL + 74) Supports +I: Does the IRCd support channelmode +I? Use 1 for yes, + 0 for no. -31. SGLINE : realname (geocs) bans, 1 = yes 0 = no + 75) SJOIN Ban Char: Character used to identify bans. Use ''. -32. SQLINE : nick bans, 1 = yes 0 = no + 76) SJOIN Except Char: Character used to identify exceptions. use ''. -33. SZLINE : szline bans, 1 = yes 0 = no + 77) SVSMODE UCMODE: Can we clear user channel modes with SVSMODE? Use + 1 for yes, 0 for no. -34. HALFOP : channel mode +h, 1 = yes 0 = no + 78) SGline Enforce: Does the IRCd enfore SGLINES for us or do we need to + do so? Use 1 for yes, 0 for no. -35. Number of Server Args : when an ircd connects this is the number of parameters that are passed + 79) Vhost Character: The character used to represent the vHost mode, if + this is supported by the IRCd. -36. Join to Set : services must join the channel to set modes, 1 = yes 0 = no + 80) TS6: Does the IRCd support TS6? Use 1 for yes, 0 for no. -37. Join to Message : services must join the channel to send messages (can not override +n), 1 = yes 0 = no + 81) UMode +h: Does the IRCd support usermode +h for helpers? + Use 1 for yes, 0 for no. -38. Exceptions : channel mode +e, 1 = yes 0 = no + 82) P10: Is this IRCd a P10-style IRCd? Use 1 for yes, 0 for no. -39. Time Stamp on topics Forward : Unreal ircds like their topic ts set forward by +1, 1 = yes 0 = no + So we've had this long list. Now there's a second struct to fill. This + struct isn't as long as the previous one though, so we'll handle it quite + quick compared to the previous one. -40. Time Stamp on topics backwards : old dreamforge likes their topics with a ts that is set back by -1, 1 = yes 0 = no + IRCDCAPAB ircdcap[] = { } -41. Protected Umode : UMODE_ that defines the protected Umode, 0 = no, or the UMODE_ + This struct is based oN the CAPAB defines. You should review the CAPAB + table below to see how this should be done. -42. Admin : channel admin (Ultimate ircds), 1 = yes 0 = no + Define Table + -------------------------------------------------------------------------- + Define | Value | Token | Description + ----------------|------------|-----------|-------------------------------- + CAPAB_NOQUIT | 0x00000001 | NOQUIT | NOQUIT protocol support + CAPAB_TSMODE | 0x00000002 | TS | Chanmodes are timestamped + CAPAB_UNCONNECT | 0x00000004 | UNCONNECT | UNCONNECT protocol support + CAPAB_NICKIP | 0x00000008 | NICKIP | IP sent in the NICK line + CAPAB_NSJOIN | 0x00000010 | SSJOIN | Smart SJOIN support + CAPAB_ZIP | 0x00000020 | ZIP | Support for gzipped links + CAPAB_BURST | 0x00000040 | BURST | Supports BURST command + CAPAB_TS3 | 0x00000080 | TS3 | Support for TS3 protocol + CAPAB_TS5 | 0x00000100 | TS5 | Support for TS5 protocol + CAPAB_DKEY | 0x00000200 | DKEY | DH-Key exchange using DKEY + CAPAB_DOZIP | 0x00000400 | ZIP | Link traffic will be gzipped + CAPAB_DODKEY | 0x00000800 | DKEY | Do DKEY with this link + CAPAB_QS | 0x00001000 | QS | Supports quit storm removal + CAPAB_SCS | 0x00002000 | SCS | String Cache System support + CAPAB_PT4 | 0x00004000 | PT4 | Support for PT4 protocol + CAPAB_UID | 0x00008000 | UID | Support for UIDs + CAPAB_KNOCK | 0x00010000 | KNOCK | Supports KNOCK + CAPAB_CLIENT | 0x00020000 | CLIENT | Supports CLIENT + CAPAB_IPV6 | 0x00040000 | IPV6 | Support for IPv6 addresses + CAPAB_SSJ5 | 0x00080000 | SSJ5 | Smart Join protocol 5 support + CAPAB_SN2 | 0x00100000 | SN2 | Support for SN2 protocol + CAPAB_VHOST | 0x00200000 | VHOST | Supports VHOST protocol + CAPAB_TOKEN | 0x00400000 | TOKEN | Supports s2s tokens + CAPAB_SSJ3 | 0x00800000 | SSJ3 | Smart Join protocol 3 support + CAPAB_NICK2 | 0x01000000 | NICK2 | Support for extended NICK (v2) + CAPAB_UMODE2 | 0x02000000 | UMODE2 | Supports UMODE2 command + CAPAB_VL | 0x04000000 | VL | VLine information in info field + CAPAB_TLKEXT | 0x08000000 | TLKEXT | Not 8, but 10 params in TKL's -43. SQline Channels : sqline to ban channel names, 1 = yes 0 = no +4) Modes -44. Quit On Kill : when a user is killed a quit message is sent, 1 = yes 0 = no + The next thing you should do is defining the user modes. You will want to + have your .h file handy for this part. -45. SVSMODE -b : can use svsmode to unban addresses, 1 = yes 0 = no + unsigned long umodes[128] = { } -46. Protect : channel protect +a (Unreal/Viagra ircds), 1 = yes 0 = no - -47. Reverse : can do a reverse check when unbanning, dreamforge based ircds, 1 = yes 0 = no - -48. Register Channels : supports setting a channel as registered, 1 = yes 0 = no - -49. Registered Mode : mode to set set when registered CMODE_ , 0 = No - -50. vident : vhost a users ident, 1 = yes 0 = no - -51. svshold : instead of svsnick or kill, we can hold the nick, 1 = yes 0 = no - -52. timestamp on mode : needs to send time stamp when modes are changed, 1 = yes 0 = no - -53. NICKIP : on NICK the users IP address is sent, 1 = yes 0 = no - -54. Umode : can use OperServ to change a users mode, 1 = yes 0 = no - -55. O:line : can use OperServ to give a temp oline, 1 = yes 0 = no - -56. Vhost On Nick : on NICK it sends the VHOST, 1 = yes 0 = no - -57. Change Realname : change real name, 1 = yes 0 = no - -58. Extra Help : if the ircd has more help use the language file value here, 0 = no - -59. No Knock : CMODE_ that defines NO KNOCK, 0 = no - -60. Admin Only : CMODE_ that defines Admin Only, 0 = no - -61. Default Mlock : modes to default the mlock to, 0 = no - -62. Vhost Umode : UMODE_ that defines vhost is enabled, 0 = no - -63. Flood Mode : has flood mode, 1 = yes 0 = no - -64. Link Mode : has linked mode, 1 = yes 0 = no - -65. Cmode F : CMODE_ that defines flood mode, 0 = no - -66. Cmode L : CMODE_ that defines Linked Mode, 0 = no - -67. Check Nick ID : on check change check if they should remain identified, 1 = yes 0 = no - -68. No Knock Requires +i : if No Knock mode requires invite only, 1 = yes 0 = no - -69. Chan Modes : if sent in capab/protoctl we store it in here (NULL by default) - -70. Tokens : if Anope can support the ircd with Tokens, 1 = yes 0 = no - -71. Token Case Senstive : some ircds the TOKENS/COMMANDS are case senstive, 1 = yes 0 = no - -72. SJOIN time stamps are base64 : if they are base64 encoded, 1 = yes 0 = no - -73. Supports +I : Whether the ircd supports +I, 1 = yes 0 = no - -74. SJOIN Ban Char : char used to identify bans, use '' - -75. SJOIN Except Char : char used to identify exceptions, use '' - -76. SVSMODE UCMODE : clear user channel modes with SVSMODE, 1 = yes 0 = no - -77. SGline Enforce : the ircd enforces sglines for us we don't need to, 1 = yes 0 = no - -78. Vhost Character : the character used to represent the vhost mode - -79. TS6 : ircd supports TS6, 1 = yes 0 = no - -80. +h mode support, Helper Op mode supported by the ircd, 1 = yes 0 = no - -81. P10 : ircd is a P10 style of IRCD, 1 = yes 0 = no - -IRCDCAPAB ircdcap[] = { } - -This struct is based of the CAPAB defines, you should review the the CAPAB table -below for how this to be done. - -Define Table -====================================================================================================== -DEFINE WORD | VALUE | TOKEN | IRCD Meaning -====================================================================================================== -CAPAB_NOQUIT | 0x00000001 | NOQUIT | Supports NOQUIT -CAPAB_TSMODE | 0x00000002 | TS | Channel modes are TimeStamped (normal sent during PASS) -CAPAB_UNCONNECT | 0x00000004 | UNCONNECT | Supports UNCONNECT -CAPAB_NICKIP | 0x00000008 | NICKIP | IP in the NICK line -CAPAB_NSJOIN | 0x00000010 | SSJOIN | smart sjoin SSJOIN -CAPAB_ZIP | 0x00000020 | ZIP | server supports gz'd links -CAPAB_BURST | 0x00000040 | BURST | server supports BURST command -CAPAB_TS3 | 0x00000080 | TS3 | Supports the TS3 Protocol -CAPAB_TS5 | 0x00000100 | TS5 | Supports the TS5 Protocol -CAPAB_DKEY | 0x00000200 | DKEY | server supports dh-key exchange using "DKEY" -CAPAB_DOZIP | 0x00000400 | ZIP | output to this link shall be gzipped -CAPAB_DODKEY | 0x00000800 | DKEY | do I do dkey with this link? -CAPAB_QS | 0x00001000 | QS | Can handle quit storm removal -CAPAB_SCS | 0x00002000 | SCS | Supports String Cache System -CAPAB_PT4 | 0x00004000 | PT4 | PT4 Protocol Support -CAPAB_UID | 0x00008000 | UID | Can do UIDs -CAPAB_KNOCK | 0x00010000 | KNOCK | supports KNOCK -CAPAB_CLIENT | 0x00020000 | CLIENT | Supports CLIENT -CAPAB_IPV6 | 0x00040000 | IPV6 | Server is able to handle ipv6 address masks -CAPAB_SSJ5 | 0x00080000 | SSJ5 | Server supports smart join protocol 5 -CAPAB_SN2 | 0x00100000 | SN2 | Supports SN2 protocol (SNICK 2) -CAPAB_VHOST | 0x00200000 | VHOST | Supports VHOST protocol -CAPAB_TOKEN | 0x00400000 | TOKEN | Supports tokenized server<->server commands -CAPAB_SSJ3 | 0x00800000 | SSJ3 | Server supports smart join protocol 3 -CAPAB_NICK2 | 0x01000000 | NICK2 | supports the extended NICK command (version 2) -CAPAB_UMODE2 | 0x02000000 | UMODE2 | support for the UMODE2 command -CAPAB_VL | 0x04000000 | VL | Vline information is included in the info field -CAPAB_TLKEXT | 0x08000000 | TLKEXT | This allows 10 instead of 8 parameters in TKL's - -=================================================================================================== - -4. Modes - - The next part that you come to is the user modes. You will want to have your .h file handy -for this part as you being. - -unsigned long umodes[128] = { } - - This starts from 0 to 127 in the ASCII character set. Insert the user modes at the slot -where the mode fits. If you are adding a the user mode of +i find the 105 character slot in -the array, and place the UMODE_i into this slot. - -=================================================================================================== - -5. FUNCTIONS AND EVENTS - -A brief word about functions and events. All events are captured via the - -void moduleAddIRCDMsgs(void) { - m = createMessage("NICK", anope_event_nick); - addCoreMessage(IRCD,m); -} - -Each event should have a event handler if its important enough to process by services. -All event functions should be formed like so - -int anope_event_capab(char *source, int ac, char **av) -{ - return MOD_CONT; -} - -they will receive the source, this can be NULL at times depending on the event. AC is the -number of arguments that are in the event. and AV holds the values for each, so av[0] is -the first variable. Events are likely to pass to various upper level event handlers, see -the previous ircd source for how they handle these events. - -All commands are formed like so - -void anope_cmd_svsnoop(char *server, int set) -{ - send_cmd(NULL, "SVSNOOP %s %s", server, (set ? "+" : "-")); -} - -they may take any number of arguments, and come to a send_cmd() this root function is how -commands are sent to the ircd. - - -6. CAPAB/PROTOCTL - -Most IRCD send a CAPAB or PROTOCTL line so that they can work out what each is -capable of doing. Anope has a function to read these lines and set itself up -to to hand these events better. When adding support for your ircd. Take the -following steps - -1. in the ircd.c find the function anope_cmd_capab() this function will send - the CAPAB/PROTOCTL line (consult your ircd documentation for which to send) - then in a single line type in the tokens that anope must send. Here is an - example of Hybrid's capab line - - /* CAPAB */ - void anope_cmd_capab() - { - send_cmd(NULL, "CAPAB TS5 EX IE HOPS HUB AOPS"); - } - -2. in the ircd.h file make sure to place the defines (see below) that match your - ircds tokens, only use the ones that matter to your ircd. Should your ircd add - new features not covered in the defined, please contact the Anope Dev team - before doing so. - -3. Ensure that the CAPAB/PROTOCTL event his handled correctly. - - a. in the function "moduleAddIRCDMsgs" making sure that you have the following - two lines + This array goes from 0 to 127 in the ASCII character set. Insert the user + modes at the slot where the mode fits. If you are adding a the user mode + of +i find the 105th (ASCII code of 'i') character slot in the array, and + place the UMODE_i into this slot. Your base .c file should contain a good + start for this, as well as a little help locating the characters. + +5) Functions and Events + + A brief word about functions and events. All events are captured using: + + void moduleAddIRCDMsgs(void) + { + m = createMessage("NICK", anope_event_nick); + addCoreMessage(IRCD,m); + } + + Each event should have a event handler if its important enough to be + processed by services. All event functions should be formed like this: + + int anope_event_capab(char *source, int ac, char **av) + { + return MOD_CONT; + } + + They will receive the source; this can be NULL at times depending on the + event. Next, ac is the number of arguments that are in the event, and av + holds the values for each; so av[0] is the first variable, av[1] will be + the second one, and so on. Events are likely to pass to various upper + level event handlers; see the previous ircd source for how they handle + these events. + + All commands are formed like this: + + void anope_cmd_svsnoop(char *server, int set) + { + send_cmd(NULL, "SVSNOOP %s %s", server, (set ? "+" : "-")); + } + + They may take any number of arguments, depending on the command. They + should eventually come to a send_cmd(); this root function is how + commands are sent to the IRCd. + +6) CAPAB/PROTOCTL + + Most IRCD send a CAPAB or PROTOCTL line so that they can work out what + the other end of the connection is capable of doing. Anope has a function + to read these lines and set itself up to to handle these events better. + When adding support for your ircd, take the following steps. + + 1) In the ircd.c find the function anope_cmd_capab(); this function will + send the CAPAB/PROTOCTL line (consult your ircd documentation for + which to send). In a single line type in the tokens that anope must + send. Here is an example of Hybrid's capab line: + + /* CAPAB */ + void anope_cmd_capab() + { + send_cmd(NULL, "CAPAB TS5 EX IE HOPS HUB AOPS"); + } + + 2) In the ircd.h file make sure to place the defines (see below) that + match your IRCd's tokens; only use the ones that matter to your ircd. + Should your IRCd add new features not covered in the defined, please + contact the Anope Dev team before doing so. See README for information + on how to contact the Anope team. + + 3) Ensure that the CAPAB/PROTOCTL event his handled correctly. + + A) In the function "moduleAddIRCDMsgs" making sure that you have the + following two lines: - m = createMessage("CAPAB", anope_event_capab); - addCoreMessage(IRCD,m); - - b. Add the function to handle the event - - int anope_event_capab(char *source, int ac, char **av) - { - capab_parse(ac, av); - return MOD_CONT; - } - - this function + m = createMessage("CAPAB", anope_event_capab); + addCoreMessage(IRCD,m); + B) Add the function to handle the event + int anope_event_capab(char *source, int ac, char **av) + { + capab_parse(ac, av); + return MOD_CONT; + } + This function should call the capab_parse function which parses + the received CAPAB/PROTOCTL line. diff --git a/docs/MODULES b/docs/MODULES index af2cd376d..85fb283d5 100644 --- a/docs/MODULES +++ b/docs/MODULES @@ -1,35 +1,42 @@ Anope Modules ------------- -Introduction: +1) Introduction +2) Installation +3) Usage +4) Usage Example +5) More Modules +6) Support +7) Information for Developers - Anope 1.6 onwards supports external modules. External modules are pieces - of code that can be attached to a running Anope process dynamically. These - modules can serve several purposes, and perform all kind of operations to - enhance your network. +1) Introduction -Installation: + Anope 1.6 onwards supports external modules. External modules are pieces + of code that can be attached to a running Anope process dynamically. These + modules can serve several purposes, and perform all kind of operations to + enhance your network. + +2) Installation 1. If modules are supported by your system, they will be configured automatically when you run ./Config. The modules will be installed to the modules directory in your data path (by default this will be ~/services/modules). - Notes: - - * Modules are not supported on the following platforms: OpenBSD, Windows. - * You might need to run "make distclean" prior to running ./Config + Note: you might need to run "make distclean" prior to running ./Config 2. Compile Anope as usual. The (g)make process will now compile module support into Anope, and compile the default sample modules, and/or - any other module located on the "modules" folder. + any other module located on the modules folder ("src/modules/"). 3. Install Anope as usual. The install process will place the compiled modules in their runtime location, making them available for loading. 4. Start or restart services to make use of the new Anope executable. + Note that you do not need to restart to load new or changed modules, + only to make use of a new Anope executable. -Usage: +3) Usage All module manipulation commands are done through OperServ. These are: @@ -45,7 +52,7 @@ Usage: of "ModuleAutoload" and "ModuleDelayedAutoload" to include the modules you want to load every time Anope starts. -Example: +4) Usage Example /msg OperServ modload hs_moo *** Global -- from OperServ: dengel loaded module hs_moo @@ -70,28 +77,27 @@ Example: modules have an abbreviated service name they attach to (hs_ for HostServ, cs_ for ChanServ, etc) followed by a descriptive keyword. -More Modules: +5) More Modules Anope ships with two sample modules that only illustrates some of the implemented module capabilities. They don't really do much or anything useful. - You can download more useful modules from http://www.anope.org/ or from - our interim modules development website http://modules.anope.org/. Just + You can download more useful modules from http://modules.anope.org/. Just grab the module file (usually with a .c extension). Place the module - file on your compile "src/modules" folder. The same folder that contain both - hs_moo.c and catserv.c module files. + file in your modules (src/modules) folder; the same folder that contains + both hs_moo.c and catserv.c module files. The new modules need to be compiled and installed before you can make use of them: - 1. Make sure you're in the main source directory. + 1. Make sure you're in the main source directory. (usually anope-1.X.XX/) 2. Run `make modules` to compile any new or changed modules. 3. Run `make install` to install the modules. You can now use /msg OperServ MODLOAD to load the new modules. -Support: +6) Support The Anope team is not responsible or liable for any unofficial module (i.e. anything other than what was released with the Anope package). @@ -101,9 +107,9 @@ Support: author, posting on our online forum, or maybe on our #anope channel at /server irc.anope.org. -Developers: +7) Information for Developers Please take a look at: - * http://geniusdex.dezeserver.nl/anope + * http://geniusdex.dezeserver.nl/anope-wiki/ diff --git a/docs/MYSQL b/docs/MYSQL index 19a11113c..9bb8ce9d5 100644 --- a/docs/MYSQL +++ b/docs/MYSQL @@ -1,7 +1,7 @@ Anope MySQL Support ------------------- -Introduction: +1) Introduction Anope 1.6 onwards supports MySQL databases. On Anope 1.6.0 only PHASE 1 has been implemented. Since the next phases require major changes in the @@ -29,30 +29,27 @@ Introduction: in realtime. That way the MySQL db could be modified externally (web?). Again, the FFF will be kept intact. -Requirements: +2) Requirements 1. MySQL server version 3.23.32 or greater 2. MySQL libs and development files (usually called mysql-dev). 3. A MySQL user account 4. A MySQL database -Installation: +3) Installation 1. The ./Config script automatically detects if your system is capable of running Anope with MySQL support. There is no need anymore to answer yes when asked. - Notes: - - * MySQL is not supported on the following platforms: Windows. - * You might need to run "make distclean" prior to running ./Config + Note: You might need to run "make distclean" prior to running ./Config 2. Compile Anope as usual. The (g)make process will now compile MySQL support into Anope. 3. Install Anope as usual. -Configuration: +4) Configuration 1. Run bin/mydbgen to help on the schema creation and adjustments. @@ -61,49 +58,51 @@ Configuration: 3. Start or restart services to make use of the new Anope executable. -Security: +5) Security + + To add a layer of security you have the option of encrypting or encoding + all passwords for nicks and chans. Use the "MysqlSecure" directive on your + services.conf file to enable it. The available storage methods are: - To add a layer of security you have the option of encrypting or encoding - all passwords for nicks and chans. Use the "MysqlSecure" directive on your - services.conf file to enable it. The available storage methods are: + #MysqlSecure "" - #MysqlSecure "" or MysqlSecure "" + or - Disables security. All passwords will be saved on the MySQL database - as clear text, with no encryption or encoding. FASTEST + MysqlSecure "" - MysqlSecure "des" + Disables security. All passwords will be saved on the MySQL database + as clear text, with no encryption or encoding. FASTEST - Encrypts all passwords using a UNIX DES encryption. This is a one way - encryption algorithm. You can only validate it against another DES - encrypted string, using the same "salt" (the first two characters of - the encrypted string). FAST + MysqlSecure "des" - MysqlSecure "md5" + Encrypts all passwords using a UNIX DES encryption. This is a one way + encryption algorithm. You can only validate it against another DES + encrypted string, using the same "salt" (the first two characters of + the encrypted string). FAST - Calculates an MD5 128-bit checksum for the password. The value is - returned as a 32-digit hex number that may be used as a hash key. - This is a one way encryption algorithm. - SLOW + MysqlSecure "md5" - MysqlSecure "sha" + Calculates an MD5 128-bit checksum for the password. The value is + returned as a 32-digit hex number that may be used as a hash key. + This is a one way encryption algorithm. SLOW - Calculates an SHA 160-bit checksum for the password. The value is - returned as a 40-digit hex number. This is a one way encryption - algorithm.SLOWEST + MysqlSecure "sha" - MysqlSecure "mykey" + Calculates an SHA 160-bit checksum for the password. The value is + returned as a 40-digit hex number. This is a one way encryption + algorithm. SLOWEST - Encodes the passwords using "mykey" as the encryption password. It - produces a binary string and can be decoded using the MySQL built in - function DECODE(crypt_str,mykey). VARIABLE + MysqlSecure "mykey" - Caveat: Keep in mind that this if you use any method other than clear - text, services will need to encrypt/encode every single password on - every database save. On large networks, it may impact responsiveness - during the saves. + Encodes the passwords using "mykey" as the encryption password. It + produces a binary string and can be decoded using the MySQL built in + function DECODE(crypt_str,mykey). VARIABLE - Caveat: If you enable MysqlSecure you can not longer use the UseRDB directive - as all the password types are encrypted with a one way encryption method for - older MySQL servers. + Caveat: Keep in mind that this if you use any method other than clear + text, services will need to encrypt/encode every single password on + every database save. On large networks, it may impact responsiveness + during the saves. + Caveat: If you enable MysqlSecure you can not longer use the UseRDB directive + as all the password types are encrypted with a one way encryption method for + older MySQL servers. diff --git a/version.log b/version.log index ad3710da2..a36311727 100644 --- a/version.log +++ b/version.log @@ -8,10 +8,14 @@ VERSION_MAJOR="1" VERSION_MINOR="7" VERSION_PATCH="8" -VERSION_BUILD="577" +VERSION_BUILD="578" # $Log$ # +# BUILD : 1.7.8 (578) +# BUGS : +# NOTES : Updates of documentation (BUGS, IRCD, EVENTS, MYSQL, INSTALL, MODULES, DEFCON) for one style and some smaller fixes and updates. +# # BUILD : 1.7.8 (577) # BUGS : # NOTES : Applied a patch in behalf of heinz. |