pegasus/anope
1
0
Fork 0
mirror of https://github.com/anope/anope.git synced 2026-07-04 19:13:12 +02:00
Code Activity

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.

Browse Source 
git-svn-id: svn://svn.anope.org/anope/trunk@578 31f1291d-b8d6-0310-a050-a5561fc1590b


git-svn-id: http://anope.svn.sourceforge.net/svnroot/anope/trunk@428 5417fbe8-f217-4b02-8779-1006273d7864
This commit is contained in:
geniusdex geniusdex@31f1291d-b8d6-0310-a050-a5561fc1590b
2005-02-21 17:12:47 +00:00
parent 1ee7364fb3
commit 984677b5a4
9 changed files with 830 additions and 713 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Changes
+1
View File
@@ -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]
docs/BUGS
+2 -2
View File
@@ -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.
docs/DEFCON
+13 -6
View File
@@ -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.
docs/EVENTS
+131 -124
View File
@@ -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
A) All functions most be formatted as:
int functioname(char *source, int ac, char **av);
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;
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;
}
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.
Note that AUTHOR and VERSION should be defined above the AnopeInit
function, just like you should do with any module.
msg = createEventHandler("NICK", my_nick);
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.
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"
msg = createEventHandler("NICK", my_nick);
status = moduleAddEventHandler(msg);
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".
it will return the module error code so you can confirm that it was added
correctly.
status = moduleAddEventHandler(msg);
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.
It will return the same module error codes as adding a regular message,
which you can use to confirm it was added correctly.
int my_nick(char *source, int ac, char **av)
{
alog("Internal Event - nick is %s",av[0]);
return MOD_CONT;
}
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.
==============================================================================================
3. Triggered Events
==============================================================================================
int my_nick(char *source, int ac, char **av)
{
alog("Internal Event - nick is %s",av[0]);
return MOD_CONT;
}
These events also known as "event hooks" are internal events such as expiring of nicks to
the saving of databases.
3) Triggered Events
A. All functions most be formatted as
These events also known as "event hooks" are internal events such as
expiring of nicks to the saving of databases.
int functioname(char *message);
A) All functions most be formatted as:
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;
int functioname(char *message);
moduleAddAuthor(AUTHOR);
moduleAddVersion(VERSION);
return MOD_CONT;
}
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;
C. Pass "createEventHook" the name of the event, in this case we are going to hook to the
saving of databases, "EVENT_DB_SAVING"
moduleAddAuthor(AUTHOR);
moduleAddVersion(VERSION);
return MOD_CONT;
}
hook = createEventHook(EVENT_DB_SAVING, my_save);
C) Pass "createEventHook" the name of the event. In this case we are
going to hook to the saving of databases, "EVENT_DB_SAVING".
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"
hook = createEventHook(EVENT_DB_SAVING, my_save);
status = moduleAddEventHook(hook);
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"
it will return the module error code so you can confirm that it was added
correctly.
status = moduleAddEventHook(hook);
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
It will return the same module error codes as adding a regular message,
which you can use to confirm it was added correctly.
int my_save(char *source)
{
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.
if (!stricmp(source, EVENT_START)) {
alog("Saving the databases! has started");
} else {
alog("Saving the databases is complete");
}
return MOD_CONT;
}
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 |
==============================================================================================
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 |
|------------------------|-------------------------------------------|
docs/INSTALL
+139 -137
View File
@@ -1,182 +1,184 @@
ANOPE INSTALLATION INSTRUCTIONS
===============================
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
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/
NOTE: although you may specify different binary and data paths,
it is RECOMMENDED that you use the same value for both.
Next, unpack the package in your home directory, and go into the created
directory.
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/.
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.
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.
NOTE: although you may specify different binary and data paths, it is
RECOMMENDED that you use the same value for both.
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.
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/.
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!
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.
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 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 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!
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
To upgrade Anope, just follow the installation instructions described in
section 1. There are however a few specific guidelines:
If you got a .diff file and want to patch the old Anope sources with it,
do the following:
* IMPORTANT: Back up your old databases!
* If you are upgrading to a new major release, ALWAYS restart a
fresh configuration file from example.conf.
* Copy the .diff file into the root Anope sources directory.
* Type patch -p1 <file.diff
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.
3. Setting up the IRCd
----------------------
To upgrade Anope, just follow the installation instructions described in
section 1. There are however a few specific guidelines:
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).
* IMPORTANT: Back up your old databases!
* If you are upgrading to a new major release, ALWAYS restart a
fresh configuration file from example.conf.
For samples below we'll take Services.LocalHost.Net as the name of
the Services (as stated in the ServerName configuration directive).
3) Setting up the IRCd
First, the C/N lines, that allow Services to link. They also need a
Y:line to work correctly.
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).
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
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.
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).
First, the C/N lines, that allow Services to link. They also need a
Y:line to work correctly.
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.
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
U:Services.LocalHost.Net:*:*
"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).
NOTE: if you have more than one server in your network, this line
MUST be added on ALL servers, or things won't work.
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.
Finally, you'll need to add an H:line, to make the OperServ JUPE
command work correctly.
U:services.localhost.net:*:*
H:*::Services.LocalHost.Net
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.
Don't forget to /rehash to apply changes.
Finally, you'll need to add an H:line, to make the OperServ JUPE command
work correctly.
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:
H:*::Services.LocalHost.Net
link Services.LocalHost.Net
{
username *;
hostname localhost;
bind-ip *;
port 6667;
hub *;
password-connect "mypass";
password-receive "mypass";
class servers;
};
Don't forget to /rehash your IRCd to apply changes.
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:
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:
http://heinz.anope.org/ilm.php
link services.localhost.net
{
username *;
hostname localhost;
bind-ip *;
port 6667;
hub *;
password-connect "mypass";
password-receive "mypass";
class servers;
};
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.
4. Starting Anope
-----------------
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:
Go into the directory where binaries were installed (by default,
~/services). Type ./services to launch Anope.
http://heinz.anope.org/ilm.php
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.
4) Starting Anope
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.
Go into the directory where binaries were installed (by default, this is
~/services). Type ./services to launch Anope.
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.
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.
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.
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.
5) Setting up a crontab
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 ;).
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.
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.
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 ;))
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). 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).
Save and exit, and it's installed.
docs/IRCD
+472 -381
View File
@@ -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.
docs/MODULES
+28 -22
View File
@@ -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/
docs/MYSQL
+39 -40
View File
@@ -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 "" or MysqlSecure ""
#MysqlSecure ""
Disables security. All passwords will be saved on the MySQL database
as clear text, with no encryption or encoding. FASTEST
or
MysqlSecure "des"
MysqlSecure ""
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
Disables security. All passwords will be saved on the MySQL database
as clear text, with no encryption or encoding. FASTEST
MysqlSecure "md5"
MysqlSecure "des"
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
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 "sha"
MysqlSecure "md5"
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
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 "mykey"
MysqlSecure "sha"
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
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
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.
MysqlSecure "mykey"
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.
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: 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.
version.log
+5 -1
View File
@@ -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.