Skip to content
Snippets Groups Projects
Commit 96ee05ab authored by Randy Sommerfeld's avatar Randy Sommerfeld
Browse files

Documentation updates for IRCd 2.0

parent 69e7dc7a
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
Showing
with 270 additions and 607 deletions
docs/ircd.txt
+ 270
− 607
View file @ 96ee05ab
$Id: ircd.txt,v 1.6 2006/08/14 14:23:48 cyan Exp $
** ircd.js : The Synchronet IRCd Service **
by: Randy Sommerfeld <cyan@rrx.ca>
1 .... Introduction
2 .... About this document
2.1 .... What this document hopes to accomplish
2.2 .... What this document won't accomplish
2.3 .... Assumptions we make about you
3 .... Installation
3.1 .... Getting the IRCd up and running
3.2 .... Linking to the Synchronet IRC Network (irc.synchro.net)
3.3 .... Using JSexec to run the IRCd
4 .... About the Synchronet IRC Network (irc.synchro.net)
5 .... Technical information
5.1 .... Limits of the Synchronet IRCd
5.2 .... Compliance with RFC's, and established protocols
5.3 .... Compatibility with other IRCd's
6 .... The Future
7 .... Frequently Asked Questions
7.1 .... Installation Questions
7.2 .... Technical Questions
=======- 1.0 -- Introduction -================================================
The Synchronet IRCd (IRC daemon) service is the newest Synchronet
service written in 100% Javascript. It's currently the largest (and perhaps
the most complex) service available for Synchronet. The IRCd service aims to
eventually be a 'communications bridge' of sorts which will allow multiple
BBS's to link their "multinode chat" areas together in a network so that users
may talk to one another from the comfort of their home BBS. While
accomplishing this goal, the Synchronet IRCd intends to also be a fully-
functional IRC daemon that rivals the bigger, legacy UNIX IRC daemons in terms
of features. This way, everyone who wishes to chat on a common network will
be able to use the local BBS, or a standard IRC client (if they wish.)
=======- 2.0 -- About this document -=========================================
[2.1] - What this document hopes to accomplish
First and foremost, this document is intended to be an absolute
reference regarding the Synchronet IRCd. This document should be the first
place to look if you're having a problem of some kind, regardless of what that
problem may be. It intends to be an installation guide which will aide you
through setting up your own IRCd. Or, if you're simply curious about the IRCd
from a theoretical standpoint (it's not every day that you get to see an IRC
daemon as functional as this implemented inside of a scripting language), this
document will do its best to explain certain implementation decisions to you.
[2.2] - What this document won't accomplish
This document is not a replacement for your brain. If you're having a
problem of some kind, and it's not covered by this document, PLEASE take a few
hours to think about the problem and solve it. Use a systematic approach to
the problem; "If I do X, does Y still happen?" Remember, installation and
maintenance of the Synchronet IRCd isn't life or death, it's a hobby, and like
all good hobbies, you're supposed to learn something from it. So, take a few
days before you even consider asking for support -- take a deep breath, go jog
around the block, turn off the computer -- and then come back later. On the
other hand, if you've found a unique or interesting solution to your problem,
and it hasn't been covered here, then by all means tell us about it!
We don't intend to teach you the basics of IRC here. While you can
certainly still get the Synchronet IRCd up and running with a minimal amount
of effort and IRC knowledge, your experience will be more enjoyable if you
have at the very least a working knowledge of IRC. To gauge your knowledge
of IRC, answer the following questions either with a 'true' or 'false':
* People chat in 'rooms' on IRC.
* 'IRCop' is short for 'IRC cop', the police officers of IRC.
* A 'ping' is something submarines use to gauge distance under water.
* CTCP and DCC stand for Client Tunneling Carrier Protocol and
Direct Channel Cutting, respectively.
If you answered 'true' to any of the above questions, or if you don't
understand some of the terminology used in the questions, then it's best that
you go to http://www.irchelp.org and read through their very helpful documents
about IRC. This way, you'll gain a better understanding about what IRC really
is, what it's here for, the terminology, and a little history, too. At the
very least, this is so that when someone asks you to edit your 'M:Line' to
solve or diagnose a problem, you'll at least know what they're talking about.
We don't cover any IRC basics in this document.
Don't be surprised if you're ignored or simply referred to a URL
without further explanation if you ask for help and refer to an IRC *channel*
as a room, call *IRC operators* 'cops', don't understand why a 10 second 'ping'
time is bad, or not know how to DCC SEND a file (such as your ircd.conf) to be
inspected. That includes not having your NAT or proxy set correctly to
properly masquerade your IP address on a DCC CTCP.
[2.3] - Assumptions we make about you
In short, this document assumes that you know:
* How to use your computer and operating system effectively.
* The basics of IRC and its terminology.
* How to use, configure, and make basic modifications to Synchronet.
* The basics of the Internet (or at least the ability to visualize
a routed, distributed network)
=======- 3.0 -- Installation -================================================
[3.1] - Getting the IRCd up and running
(1) Make sure you are running a modern version of the Synchronet BBS
software. The Synchronet IRCd is not intended to run on versions 3.10 or
earlier. While care has been taken to ensure backwards compatibility with
3.10, it should only be run on that version for testing purposes. Upgrading
may include retrieving the latest version of Synchronet from the Synchronet
CVS (if you're familiar with building from CVS), from the Synchronet web site
(http://www.synchro.net), or elsewhere. Synchronet 3.11 is the minimum
required version to run version 1.0 (or higher) of the Synchronet IRCd.
Older versions of Synchronet also come packaged with older Javascript
libraries. The Synchronet IRCd makes use of some of the newer Javascript
library features (such as the ability to treat strings as an array of
characters), therefore it's critical to have a modern JS library. If your
Javascript library is from 2002 or earlier (you can check this in the 'system
information' part of your BBS main menu), then it's too old. Time to upgrade.
(2) Check to make sure that all of the components of the Synchronet
IRCd are resting in their correct directories. While you're at it, check the
file sizes to make sure they're relatively normal (i.e. not 0 bytes long.)
Make sure that all of the files are readable by the user you're intending to
run the IRCd as. Here's a chart to help:
File Synchronet Dir. Description
irclib.js exec Javascript IRC library functions
ircd.js exec IRCd core
ircd_channel.js exec Channel functions/objects
ircd_server.js exec Functions/objects for servers
ircd_unreg.js exec Handling of unregistered connections
ircd_user.js exec Functions/objects for users
ircd.conf ctrl Primary configuration file
ircmotd.txt text Message users see upon connect
(3) Edit your relevant services configuration file (in the Synchronet
'ctrl' directory.) For Synchronet 3.11, this is most likely "services.ini",
however, backwards compatibility has been retained with the old style
"services.cfg" just in case you want to bring yours over from an older version
of Synchronet. You may run the Synchronet IRCd on any port you wish, however,
standard convention dictates that it be run on port 6667 (which is the
standard port that most IRC clients will try to connect to, first.) It's
important that the IRCd be defined as a STATIC service (i.e. one that runs in
the background continuously and does not require a connection to start the
service), and that it uses the LOOP option (so that if you wish to restart only
the IRCd, or if it crashes, it comes back up immediately.)
The combined options for 'services.cfg' represented in hex is '806',
so that a completed services.cfg line should look like this:
;protocol port max_clients options(hex) command-line
IRC 6667 0 806 ircd.js
An example IRC section from services.ini looks like this, and should
already be present in services.ini for Synchronet 3.11 and above. The IRCd is
enabled by default in Synchronet 3.11, so, it's likely that it's already
operating:
[IRC]
Port=6667
Options=STATIC | LOOP
Command=ircd.js
The 'maximum clients' value used inside of the services configuration
is *ignored* by Synchronet Services since that value is managed by the IRCd
itself. The maximum number of IRC clients can be changed on a Y:Line in
your ircd.conf, and is set to 100 by default (more on the ircd.conf later.)
(4) Take a look at your ircd.conf, and familiarize yourself with the
options and terminology. Although the ircd.conf has been specifically made so
that it works right out of the box, you may wish to tweak some options. The
configuration file is self-documenting, so you should carefully read about
each of the configuration options. At the very least, this will familiarize
you with what a 'Z:Line' is, and where a 'K:Line' is, or how to enable
passwords on sensitive IRC commands. If you intend to link to the Synchronet
IRC Network, pay careful attention to where the C:Line and N:Line pair is
configured. We'll be dealing with those later.
If you're already familiar with other IRC daemon configuration files,
the Synchronet ircd.conf has been carefully engineered to be compatible with
the Bahamut ircd.conf. Thus, if you've already got a working Bahamut
configuration, putting that ircd.conf in place of the stock ircd.conf should
give you an IRCd configured exactly the way it was on Bahamut. Configuration
files from other IRC daemons have *not* been tested, so your mileage may vary
with those (although the configuration should be very similar.) Certainly if
you find an ircd.conf from another daemon that works, let us know about it!
(5) Restart your BBS, or recycle your services so that your new IRC
service is brought online with your BBS. Watch your BBS console carefully,
as you should see something similar to the following messages:
srvc 0007 IRC SynchronetIRCd-1.1b(1.102) started.
srvc 0007 IRC Reading Config: /sbbs/ctrl/ircd.conf
You may have to scroll up to see the message. Any errors should be
self-explanatory (and usually involve not being able to read the configuration
file.) If you get an error about not being able to bind to a socket, or that
a socket is already in use, then you already have something running on the
port you defined in your services configuration. Could it be another IRC
server running? Try disabling any other IRC servers or proxies and restart
the BBS. If you recently restarted Synchronet with users connected to an
already operating IRCd, then it's likely that some of your sockets are in a
'TIME_WAIT' state. Wait a minute or two for the condition to clear up, then
try again. Repeat this process of elimination until your IRCd starts
successfully.
(6) Test your new IRCd by connecting to it with an IRC client.
At the very least, using 'telnet' to connect to the IRCd port should give you
something similar to the following line:
:rrx.synchro.net NOTICE * :*** SynchronetIRCd-1.1b(1.102) (RoadRunner X) Ready.
Which is the standard Synchronet IRCd banner, informing you that the
IRCd is accepting new connections correctly.
At this point, you should have a working, fully-functional IRC server
available for users to use. You may want to point Synchronet's internal IRC
client to your local IRC server (just 'localhost' or '127.0.0.1'), so that
your BBS users will be able to make use of your new IRCd. By default, an
O:Line has been added so that anyone connecting either from the BBS itself, or
your internal network will be able to make use of the /OPER command to become
an IRC Operator. To become an IRC Operator, first /WHOIS yourself to make
sure that your hostname is your local BBS's hostname (i.e. mybbs.synchro.net)
If so, execute '/OPER Sysop <pass>', where <pass> is your local BBS system
password. If your hostname isn't the local BBS's hostname, go ahead and edit
ircd.conf (in the Synchronet 'ctrl' directory) and add an O:Line for your
hostname as directed by the instructions inside of the configuration file.
[3.2] - Linking to the Synchronet IRC Network (irc.synchro.net)
Connecting your IRC server to the Synchronet IRC Network has certain
advantages. The best advantage is that you'll be allowing any users who use
your IRC server (i.e. your BBS users) to also talk to other users on the
network. Since the network is largely BBS-oriented, there are a wide variety
of channels available for users to join and discuss various topics.
Furthermore, you'll be offering your system to the pool of IRC servers
available for the public to use. Just like how DOVE-Net is a network of
Synchronet systems that pass message group messages to one another, the
Synchronet IRC Network is a network of Synchronet systems for the purposes of
chatting in realtime.
In later versions of the IRCd or the network, you'll be able to offer
your BBS's files over IRC, integrate your BBS chat area with IRC, or even
receive alerts about new messages or BBS email while on IRC.
Linking with the Synchronet IRC Network takes about as much time (if
not less) as it does to establish a DOVE-Net node. Therefore, the procedures
have been kept very similar. The Synchronet IRC Network is the only IRC
network in the world that allows you to link without going through a tiresome
application process, or other such bureaucracy. In fact, no network admin need
be present at all for you to link to the Synchronet IRC network.
Just as with establishing a DOVE-Net node, the following steps must be
taken to ensure a smooth link to the Synchronet IRC Network:
(1) Ensure that you have a DOVE-Net node established. Although you
aren't required to be a member of DOVE-Net to be a member of the Synchronet IRC
Network, you need to at least go through the same automatic registration
** ircd.js : The Synchronet IRCd **
by: Randy Sommerfeld <cyan@synchro.net>
1 ...... Introduction
2 ...... Configuration
3 ...... Linking to the Synchronet IRC Network (irc.synchro.net)
4 ...... A Word from the Author
5 ...... Known Issues & Ideas for the Future
=======- [1] -- Introduction -================================================
The Synchronet IRCd is a Synchronet service that is 100% compatible with
RFC1459, the Internet standard that defines the IRC protocol. Many BBS users
use it to chat on the Synchronet IRC Network, and many sysops connect their
own IRC servers to the network.
If you're not familiar with IRC, it will be helpful to learn the basics
first. This document will assume that you know IRC terminology. If you're
not familiar with the Synchronet IRC Network, you might want to point your
favourite IRC client at irc.synchro.net and take a look around. You might
also want to take a look at https://www.irchelp.org/
If you are familiar with IRC, then the Synchronet IRCd might be a
nostalgic trip to the past for you. Feature-wise it's about on par with a
late 90's IRC server (like the original irc2 server or DreamForge), and
it's full of anachronisms from that era.
=======- [2] -- Configuration -===============================================
[2.1] - Introduction
Versions of the IRCd prior to 2.0 used an irc2-style "line" configuration
file. Versions 2.0 and later use Synchronet-style .ini files. Both are still
equally supported, but the .ini file is preferred.
The easiest way to configure the Synchronet IRCd is to use ircdcfg.js
with jsexec. This is a configuration TUI based on Synchronet's UIFC. It has
online help hints, but still assumes a fair bit of IRC technical knowledge.
Most sysops won't need to configure anything at all, the IRCd is pre-
configured out of the box.
[2.2] - Conversion from old .conf format
Load the old .conf based configuration into ircdcfg.js like this:
jsexec ircdcfg.js -f /path/to/old.conf
Look around the various menus to make sure the data from the old config
was imported correctly. If all looks well, "save as" from the main menu, and
inspect the resulting .ini file.
[2.3] - Service or JSexec?
The IRCd can run either as a Synchronet Service (in which case it will
start and stop whenever Synchronet does), or standalone with jsexec. Many
sysops prefer to keep their IRCd running with jsexec since then it is not
affected by BBS restarts. The choice is yours.
=======- [3] -- Linking to the Synchronet IRC Network (irc.synchro.net) -=====
1) Ensure that you have a DOVE-Net node established. Although you
aren't required to be a member of DOVE-Net to be a member of the Synchronet
IRC Network, you need to at least go through the same automatic registration
process to obtain and configure your QWK-ID. Instructions about obtaining
your QWK-ID can be found here: http://www.synchro.net/docs/dove-net.txt
Only steps 1 and 2 need be followed, but heed the document's warning:
"Remember the password you used to create this account, you'll need it later."
You do not need to create a new QWK-ID for the IRCd if you already have an
existing one for DOVE-Net.
(2) Setup the "dyndns.js" module with your appropriate QWK-id
2) Setup the "dyndns.js" module with your appropriate QWK-id
information so that the hostname "mybbs.synchro.net" will point towards your
correct IP address. This is required so that users who try to reach your IRC
server will be able to resolve the hostname used on the IRC network. That
way, if anyone wishes to connect to your server/BBS specifically, they'll be
able to use "mybbs.synchro.net" (i.e. if your server happens to be faster,
closer, or offers interesting BBS features.) The dyndns.js module comes
with Synchronet 3.11.
To enable the dyndns module, add a timed event inside of SCFG under
"External Programs->Timed Events" to run the command "?dyndns <pass>" every
now and then. Replace <pass> with your exact QWK password. Running the
module once per day is usually acceptable, although you may want to run it
more often if your IP address is prone to changing rapidly.
After the timed event has been configured, force the event to be ran.
This can be done at the BBS itself (by using ";EXEC ?dyndns <pass>" from the
BBS main menu.) Then, after about 3 or 5 minutes, attempt to ping your new
hostname (qwk-id.synchro.net, where 'qwk-id' is your qwk-id.) It is very
important that the IP address you're connecting to the Synchronet IRC Network
from and the IP address that your new hostname (in the form of
qwk-id.synchro.net) resolves to are exactly the same, otherwise you won't be
able to link. This is to prevent anyone from arbitrarily linking their server
to the network by utilizing your qwk-id.
(3) Edit your ircd.conf and include a C/N line pair for connecting to
'vert.synchro.net'. These should be commented out in the stock ircd.conf, and
will look like this:
#C:vert.synchro.net:QWK_PASSWORD:*.synchro.net:6667:30
#N:vert.synchro.net:*:*.synchro.net::30
Remove the '#' from each line, and replace 'QWK_PASSWORD' with the
password you were assigned (or selected) when registering for a QWK-ID. The
ircd.conf contains a description of what each of the lines (and fields) mean.
It is very important that you leave the asterisks as they are, especially on
the N:Line. This is because the server you're connecting to may be randomly
assigned, and the server will never echo your QWK password back to you, so it
chooses to echo a '*' back instead. An asterisk in the N:Line also forbids any
servers from connecting *to* you, which is important, since you'll only be
doing outbound connects with this C/N pair.
(4) Restart your BBS (or, if you know how to become an IRC operator,
closer, or offers interesting BBS features.)
3) Launch ircdcfg.js with jsexec, and navigate to the "Servers" section.
There, add a new server and save the ircd.ini with these details:
TCP/IP Address: vert.synchro.net
TCP/IP Port: 6667
Outbound Password: <your actual DOVE-Net QWK password>
Inbound Password: *
ServerName: vert.synchro.net
IRC Class: 10
Flags:
Hub: true
Note that "IRC Class" may differ if you've changed the defaults. The
"Flags" are intentionally left blank. You might want to add another server
for "cvs.synchro.net", but it's not strictly necessary since both of these
servers are in the same location and offer little redundancy from each other.
4) Restart your BBS (or, if you know how to become an IRC operator,
simply use the /REHASH command), and you should see a message similar to the
following in your Synchronet console:
srvc 0008 IRC Routing: Auto-connecting to rrx.synchro.net
srvc 0008 IRC Routing: Auto-connecting to vert.synchro.net
srvc 0008 IRC Routing: Connected! Sending info...
srvc 0008 IRC 0018 Accepted new connection: 154.5.119.21 port 6667
srvc 0008 IRC Routing: Link with rrx.synchro.net established, states: TS
If you see any messages in regards to "Server not configured" or
"Connection reset by peer", it's highly likely that you've mistyped your QWK
password into the C:Line in your ircd.conf. Double-check to make sure that
the password is correct, and that you haven't otherwise malformed the C/N line
pair. In particular, make sure all the asterisks (as per the default) are
where they should be.
Otherwise, if you have received those messages, then you're connected!
You should be able to join the typical busy Synchronet IRC channels, #bbs and
#synchronet, and be able to chat with people across the network. You can find
network administrators in #opers if you have any questions or concerns.
[3.3] - Using JSexec to run the IRCd
There are times where you may wish to run the IRCd service separately
from Synchronet so that whenever your BBS goes up or down, the IRCd isn't
affected. A special program, included with Synchronet, is called "JSexec" and
is intended for use in this way. By using JSexec, your IRCd will remain
operational regardless of what your BBS is doing, while still integrating with
all of the regular Synchronet features. In fact, in most respects, running
the IRCd via JSexec is the preferred method.
To run your IRCd with JSexec, make sure that you've followed all the
installation instructions above. In particular, take a look at your M:Line on
your ircd.conf and ensure that the last argument is the port you wish to run
the IRCd on (typically 6667.) If you're currently running the IRCd through
Synchronet, shutdown your BBS and comment out (or remove) the sections in your
services configuration files (services.ini or services.cfg) so that the
service is not restarted when you bring the BBS back up.
Just like when you're running the IRCd from within Synchronet, you
need to tell JSexec that the service you're running is to be 'looped,' which
is done with the -l option. Thus, a typical JSexec execution will look like
this:
jsexec -l ircd
The above command is typed from within the Synchronet 'exec' directory.
All console commands and errors are logged to the terminal that JSexec was
started from. You should see the standard IRCd startup messages, which means
that the IRCd is now operational through JSexec. Connecting to the IRCd
should now work as per normal.
=======- 4.0 -- About the Synchronet IRC Network (irc.synchro.net) -==========
The Synchronet IRC Network is currently a small network with a BBS
focus. Like all new IRC networks, we hope that with the help of other BBS
sysops around the globe, the Synchronet IRC Network will grow to become a
thriving community sporting a wide variety of topics. Currently, the network
has a very relaxed authoritative structure -- perhaps one of the most relaxed
among all IRC networks. Even so, certain 'common sense' rules still apply.
Servers linked to the Synchronet IRC Network are automatically put
into the DNS round-robin for 'irc.synchro.net', which means that you can
expect to see connections from other clients who choose to use that address to
connect to IRC. You should expect to see your server listed in the round-
robin within about 30 minutes, although it typically takes less.
=======- 5.0 -- Technical Information -=======================================
[5.1] - Limits of the Synchronet IRCd
Although the Synchronet IRCd Service is written in Javascript, an
interpreted scripting language, it has been written to scale relatively well.
Thanks to the DALnet Bahamut testing team, the IRCd has successfully held
over 1,000 clients without any noticable slowdown. The old limit of 100 users
has been eliminated since version 1.1 of the IRCd.
If you notice any slowdown or scaling problems, please let us know.
[5.2] - Compliance with RFC's, and established protocols
The Synchronet IRCd has always aimed to be compliant with RFC1459, which
was the first published IRC specification. However, it has chosen to deviate
from the RFC where appropriate. This might be because of errors inside the
RFC itself (i.e. +p channels being listed as "*" instead of "Prv",) for the
purpose of added functionality (i.e. handling of the PASS message for dynamic
QWK connections,) or for security (not displaying some sensitive STATS output
to users who are not IRC operators.) Compliance with the newer IRC RFC papers
(inclusive of RFC's 2810 through 2813) is mostly correct, however deviates
wherever Bahamut-specific extensions conflict.
The DALnet-style Bahamut extensions to the server-to-server protocol
involve improving performance between server links by reducing the amount of
traffic that needs to go across any link. Furthermore, extra arguments are
added to common commands (NICK, MODE, TOPIC, etc) in order to better establish
the authenticity of the message. In particular, timestamps ("TS") have been
added to many commands in order to resolve conflicts between messages.
Although the Bahamut extensions are largely undocumented, the author chose to
use these extensions as a base for extending the IRC protocol (as described
in RFC1459) for the purpose of providing modern features.
The Synchronet IRCd diverges from common IRC practice and Bahamut IRC
protocol in the following fashion:
* The Synchronet IRCd does NOT make use of the "ident" protocol, which
is popular among larger IRC networks. This exclusion was decided on because
it provides very little in the way of authoritative information. Instead, a
user has been considered to be "identified" (by the lack of a tilde in the
username portion of the user "user@host" mask) when they have correctly
identified to a local BBS account. Identifying to the BBS account is done by
sending a PASS message in the registration stage. Checks against a local BBS
account are done against the username, and then the nickname respectively.
Thus, any IRC servers not running the Synchronet IRCd MUST NOT accept ident,
as it could seriously compromise a BBS-style authorization structure.
* The PASS message has been extended to allow for the passing and
checking of QWK passwords in the case of dynamic connections:
PASS <password> :<qwk-id> QWK
No destination is specified within the message, as the routing is
handled by static configuration directives (in the form of flags on the N:Line)
which show a single path for the message to take. This is to ensure that the
password cannot be sent over an arbitrary connection, improving the security
of the message. The reply to a query looks like this:
PASS <result> :<qwk-id> QWK <origin>
Where <result> is "OK" if the password check succeeded, and anything
else (typically "VOID") on failure. The origin is specified so that the
message may be routed back to the correct server. Thus, a PASS message without
an origin is a check, and a PASS message with an origin is a reply.
* Leaf servers are considered to be 'untrusted' servers by default, due
to the highly dynamic nature of a Synchronet-based IRC network. This is to
prevent bogus messages from being injected into the network, false
representation of authority, or otherwise harmful activity. Since untrusted
servers are allowed to connect to the network, leaf servers are restricted in
the following way beyond the standard behavior:
- All timestamps received from a leaf are ignored and are instead
replaced by the current time. Thus, nickname collisions cannot be
forced, and TS blasting is prevented.
- User mode +o (oper) is ignored. However, local operators still
retain authority over their local server.
- The KILL and SQUIT messages are ignored and reversed if the target
is connected to a server beyond the scope of the leaf.
- Services authorization modes (+z, +r, +q and friends) are ignored.
- Authenticity of mode change messages (channel ops, voice, bans, etc)
are strictly checked and reversed if there's a mismatch. Mode
hacking is thus prevented.
- All channel modes are bounced on behalf of the leaf by the hub upon
a resync.
- Private/Secret channels are not revealed to the leaf unless a user
on the leaf explicitly joins the channel.
[5.3] - Compatibility with other IRCd's
The Synchronet IRCd has only been tested to be link compatible with:
* Bahamut 1.4.35, 1.4.36 http://bahamut.dal.net
* Andy Church's IRC Services 5.0 http://www.ircservices.za.net
The IRCd should be compatible with any other daemon that supports the
DALnet-style Bahamut extensions. If you successfully link another IRCd
(including a services package, or other pseudo-server,) then please feel free
to let us know about it in #synchronet. Patches may be accepted to allow the
IRCd to be link compatible with other protocols at the sole discretion of the
author.
=======- 6.0 -- The Future -==================================================
Although the original intention of the IRCd was to allow users to
interact between one another from the BBS multi-node chat area, that has yet
to occur. Eventually, users will be able to talk to one another from various
BBS's and not even be aware that they're using IRC as the transport protocol
for their chat sessions. For the time being, one can use the Synchronet IRC
client (irc.js) to connect to their local IRC server.
Further compatibility with the later Bahamut daemons is planned,
including the server-to-server "RESYNCH" command, user-accessible "WATCH", and
"SILENCE." Also, more umodes will be supported, in addition to the possibility
of gaining some of the Bahamut channel modes (i.e. +c) Exception modes (+e,
etc) and exception lines (to circumvent K:Lines) may be implemented.
Some sort of mechanism will be implemented to allow individual BBS's
to share their message and file areas over IRC. This means that you'll be
able to DCC send/receive files from a BBS, QWK packets, messages, and that
sort of thing.
I'm sure DigitalMan has a ton of cool ideas, too ;)
=======- 7.0 -- Frequently Asked Questions -==================================
[7.1] - Installation Questions
Q: After setting up my IRCd, and trying to connect, it gives me an
error stating: "You're not authorized to use this server." or
"Your host isn't among the privileged." (Numeric 463)
A: Most likely your Javascript libraries are too old. Upgrade to
Synchronet 3.11, which contains sufficiently modern Javascript
libraries. If you're certain that you're running new libraries,
double-check your I:Lines and Y:Lines inside the ircd.conf.
Javascript libraries before the year 2003 are considered to be too
old; you can check your Javascript library version from the 'system
information' portion of your BBS main menu.
Q: I try to connect and it tells me "Password Incorrect" or "Denied."
(Numeric 464)
A: You've required a password to be passed to the IRC server via
the PASS command upon registration. Check your I:Lines.
Q: I keep on getting "Error setting up socket for listening" or
"Error binding socket to TCP port."
A: It's highly likely that you already have something running on the
port that you've defined the IRCd to use (typically 6667.) If you
have another IRCd running, shut it down or redefine the port that
the Synchronet IRCd uses to listen for connections. If you get
this error after having recently shut down Synchronet, one or more
sockets may be stuck in 'TIME_WAIT' or similar, in which case you
should wait until they expire (as viewable with "netstat".)
Q: My server keeps on trying to auto-connect to other servers, and I
don't want this! What do I do?
A: The IRCd will attempt to auto-connect if there's a port defined in
the C:Line for that server. Furthermore, a connect frequency must
be defined in a Y:Line for the applicable IRC class for an auto-
connect to be attempted. Remove the port from the C:Line, or turn
the auto-connect frequency down to 0 in the Y:Line.
Q: I installed the IRCd, but where are IRC Services? (ChanServ,
NickServ, etc.)
A: IRC Services are not a part of the Synchronet IRCd. Instead, we
recommend that you make use of an external services package such
as Andy Church's IRC Services (http://www.ircservices.za.net)
Furthermore, any services package which is compatible with the
Bahamut inter-server protocol should work. There *may* be an IRC
services package written in Javascript for Synchronet later.
Q: I've linked to the Synchronet IRC Network, and now I'm getting all
sorts of weird 'Routing' messages.
A: These messages are sent whenever an 'important' event occurs on the
IRC network. This includes whenever a server links or delinks from
the network, which occurs with quite a bit of regularity. These
messages are informational only, and simply indicate that your IRCd
(and the network at large) are operating correctly.
Q: I've successfully installed my IRCd, now how do I become an IRC
Operator?
A: Use the /OPER command, which has a syntax of '/OPER <nick> <pass>'.
By default, the Synchronet IRCd configuration file is already pre-
configured so that you may OPER to a nickname of 'Sysop' with the
BBS system password so long as you're connecting from the BBS
machine itself, or a system on your local network. This means you
would execute the command like this: '/OPER Sysop <syspass>'.
Also check out the O:Line section in ircd.conf.
Q: My question isn't answered in this document, where can I go?
A: First, make sure you've read this document *in its entirety*
Second, read section 2.2 again.
Third, if you're still having a problem, feel free to join
#synchronet on irc.synchro.net, the author typically uses the nick
of 'Cyan' Support is not given via email or otherwise.
[7.2] - Technical Questions
Q: Why were the Bahamut protocol extensions used instead of EFnet,
Undernet, Unreal, or otherwise?
A: The Bahamut extensions were simply the extensions that the author
was most familiar with. Bahamut is a widely-deployed IRC daemon in
use by many networks (DALnet in particular,) so it's had a strong
test cycle. Furthermore, all modern IRC extensions are relatively
similar to each other, but differ in name. For example, Bahamut's
SJOIN is similar to EFnet's NJOIN.
Q: Will you be adding support for <X> protocol, or for <X> IRCd?
A: Highly unlikely. However, feel free to add in your own support and
send me a diff. Depending on the scope of the changes, I may choose
to include them, or perhaps offer it externally as a patch. When
coding in support for different IRC protocol extensions, try to
make use of modularity so that it's possible to link together
servers of different protocols, with the IRCd as the bridge.
Patches that follow this 'modular' approach are more likely to be
accepted.
Q: Can I make modifications to the IRCd?
A: By all means, go for it! If you think that you've made a
particularly useful or clever hack, please feel free to send your
changes to ircd@rrx.ca (in unified diff format, preferably) along
with a description of what you've changed.
Q: I'm an IRC guru, and I'd like to talk to the author about the IRCd,
where do I go?
A: The author can typically be found in #synchronet as 'Cyan' on
irc.synchro.net, and welcomes all discussion about IRC protocol,
theory (especially as it relates to IRC3 proposals,) or general
banter among long-standing IRC users.
srvc 0008 IRC 0018 Accepted new connection: 71.95.196.34 port 6667
srvc 0008 IRC Routing: Link with vert.synchro.net established
5) If you have received those messages, then you're connected! You should
be able to join #synchronet and chat with people across the network.
=======- [4] -- A Word from the Author -======================================
When I first started writing this two decades ago, the intention was to
create an IRC server that would be integrated with the hosting Synchronet BBS
in some meaningful way. The most obvious way would be to have the BBS chat
the same as IRC, so a user could flip between the two and still chat with the
same people on either one. The idea would be to provide a seamless experience
to the user so that they wouldn't know they're using IRC on the backend. This
hasn't materialized, and considering it's been over two decades, I don't
expect it to.
With that being said, I'm still surprised two decades on that people are
still using this thing on a daily basis. When I first started writing the
IRCd, RFC1459 was only ten years old.
There have been some remarkable milestones. In 2021, ircstats.org
reported that Synchronet IRCd accounted for 2.2% of all IRC servers on the
IPv4 Internet. In 2022, that rose to 2.7%, a larger share than charybdis
(used by Libera), or even the IRCd's spiritual ancestor Bahamut (used by
DALnet). Of course, this only happened because the IRCd is riding
Synchronet's coat-tails. It's more a statement about Synchronet's install
base, but it's still noteworthy.
The unfortunate reality of the IRCd is that despite two decades of
development, it really doesn't have any BBS-centric features that make it
stand out from its peers. What's the difference between a sysop running the
Synchronet IRCd and a standalone IRCd written in C? Not much, really.
In many ways, MRC has achieved many of the goals that the IRCd originally
set out to accomplish. If you want a more "BBS-like" experience in your chat,
you should definitely give MRC a try.
As for me, after two decades of development, it's time to step aside. I'm
now in my forties and my priorities now are much different than they were
when I started this thing. I'd like to thank DigitalMan and Deuce in
particular. Without their help, the IRCd would never have been written, and
it only exists because they helped carry me across the line.
When I first started writing the IRCd, I figured there'd be an influx of
people interested in discussing the IRC protocol, design decisions, BBS
integration, operations, etc. Those are all passions of mine and my twenty-
something self was excited about contributing. Now that I'm two decades older
I can see that this is a niche hobby that very few have a passion for.
As of January 2024, the IRCd will become unmaintained software. I hope
that someone can take up the torch. Sysops should consider migrating
their chat to MRC, a maintained IRC network, or a maintained IRCd.
Finally, I wanted to express my appreciation for authors of open source
software as a whole. People like DigitalMan, Deuce, Linus Torvalds, and other
open source authors are able to keep writing despite an immense amount of
pressure and noise. They're made of much tougher stuff than I am.
-Cyan.
=======- [5] -- Known Issues & Ideas for the Future -=========================
[5.1] - Known Issues
[5.1.1] - IRC Services
The current version of IRC Services (that is, the software that runs
ChanServ, NickServ, et al) on the Synchronet IRC Network is ircservices-5.1.24
written by Andy Church in 2009. On Church's website,
http://achurch.org/services/ there is a disclaimer about the current state of
the software that reads:
No assistance or patches will be provided for this software, and the
author does not accept any liability for any damage caused by this software,
even in the case of security bugs.
Synchronet should move to its own IRC Services instead of relying on
unmaintained software. This is an opportunity to integrate things like
NickServ or MemoServ with the BBS.
[5.1.2] - RBL Lookups
Currently RBL lookups are a blocking operation. That is to say, when an
RBL lookup happens, the IRCd is unable to process anything else until the
lookup completes. The check_dnsbl() function that handles RBL lookups in
the IRCd should be migrated to dns.js instead of resolve_ip(), since dns.js
allows for asynchronous lookups that do not block.
[5.1.3] - IRC Network Hub-and-Spoke Model
The Synchronet IRC network follows a hub and spoke model, where vert and
cvs are major hubs. This creates a single point of failure and the whole
network is rendered useless (sometimes for days at a time) whenever
something happens at DigitalMan's house.
The network should consider migrating its IRC hub to a stable platform
(such as a server in a multi-homed datacenter). This server could still be
left in control of DigitalMan and forward its QWK passwords up to vert in a
cryptographically secure way.
[5.1.4] - 005 Numeric is Incomplete
The 005 numeric has evolved a lot over the decades, and it's no longer
complete on the Synchronet IRCd. In particular TARGMAX= needs to be fixed.
[5.2] - Ideas for the Future
[5.2.1] - IRC Services
Related to 5.1.1 above, there's an opportunity to make the IRC network
unique by creating IRC services that have BBS-specific features. One idea is
that every server should run its own set of services with special non-
colliding nicks. For example, if you have an account on vert, you could then
identify to it with something like this:
/MSG NickServ@vert.synchro.net IDENTIFY password
There would need to be a method to resolve conflicts (i.e., an account on
vert will override an account from a BBS that just joined the network).
[5.2.2] - File Serving via IRC
Related to the above, it could be possible to create a "FileServ"
service that offers BBS files over IRC and DCC.
[5.2.3] - MRC Compatibility
This is an easy one, but it will rely more on the future IRCd author
(whover that may be) collaborating with the MRC authors to make it happen.
But it seems like an easy win for both IRC and MRC.
[5.2.4] - Meaningful BBS Integration
This would require a lot of collaboration between the various stakeholders,
but it's still possible to achieve the IRCd's original design goal.
[5.2.5] - Host Cloaking
Host Cloaking is a method of obscuring a user's real hostname or IP
address through a cryprographic hash. For example, my /WHOIS output on
DALnet looks like this:
*** [Cyan] (~cyan@e21e-3e5a-1440-d392-7fe2.7001.80b.2602.ip)
The hash is constructed in a way where it reveals some portion of the IP,
but not all of it, so it's still useful for making hostmasks (like for bans).
When the Synchronet IRCd was written, host cloaking on IRC was a fairly rare
thing. These days, it's almost an expectation.
[5.2.6] - IRCv3 Compatibility
The IRCd already parses IRCv3 tags from the IRC protocol through the
IRC_parse() and IRC_parse_tags() functions in irclib.js
This would form the basis of any future work on making the IRCd
compatible with IRCv3.
[5.2.7] - Reducing Netsplit Noise
Since the Synchronet IRC Network allows anyone to link any kind of IRC
server to it, there is a lot of "noise" on the network. For example, it's
easy (and acceptable!) to run Synchronet and its IRCd on a Raspberry Pi, so
whenever the Pi is unplugged from the wall, it could cause a visible netsplit.
When this happens across dozens of connected machines, the noise starts to
become annoying, and it's a frequent complaint from users.
A solution to this would be to implement a channel mode that would squelch
netsplit noise. This could be accomplished in a few different ways:
1) "Hold" the netsplit users in their channels until the server comes
back. If a message is sent to the split users, the server could send a NOTICE
back informing the sender of the split. This would need a timeout (15 minutes
seems reasonable) before the client-facing QUIT messages were sent for the
split.
When the split server comes back, any messages queued up would be sent
over as part of the resync.
2) Don't display JOIN/PART/QUIT messages in a channel unless a user has
talked first. That is to say, when a user sends PRIVMSG to a channel, only
then will the JOIN take place.
=======- EOF -================================================================
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment