Synchronet v3.19b-Win32 (install) has been released (Jan-2022).

You can donate to the Synchronet project using PayPal.

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
service:ircd [2010/02/26 09:31] – Work in progress... cyanservice:ircd [2023/09/09 10:40] (current) – [Using JSexec with systemd] Refer to the ircd.service file from the Git repo instead of copy/pasting stale example here digital man
Line 4: Line 4:
  
 The Synchronet IRCd (IRC daemon) service is a static service written in 100% Javascript.  It's currently the largest (and perhaps The Synchronet IRCd (IRC daemon) service is a static service written in 100% Javascript.  It's currently the largest (and perhaps
-the most complex) service available for Synchronet.  The IRCd service aims tobe a 'communications bridge' of sorts which will allows multiple BBS's to link together in a network so that users may talk to one another from the comfort of their home BBS or IRC client.  The Synchronet IRCd is 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.)+the most complex) service available for Synchronet.  The IRCd service aims to be a 'communications bridge' of sorts which will allows multiple BBS's to link together in a network so that users may talk to one another from the comfort of their home BBS or IRC client.  The Synchronet IRCd is 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.)
  
 ====== About this document ====== ====== About this document ======
Line 18: Line 18:
 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. 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:
  
- 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 your computer and operating system effectively. +  * How to use, configure, and make basic modifications to Synchronet. 
- * The basics of IRC and its terminology. +  * The basics of the Internet (or at least the ability to visualize a routed, distributed network)
- * 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)+
  
 ====== Installation ====== ====== Installation ======
Line 34: Line 31:
 By default, the Synchronet IRCd is installed as a service.  It should already be present in your "services.ini" file inside the BBS 'ctrl' directory.  The IRCd will automatically start when you start your BBS.  The default entry for the IRCd inside of services.ini looks like this: By default, the Synchronet IRCd is installed as a service.  It should already be present in your "services.ini" file inside the BBS 'ctrl' directory.  The IRCd will automatically start when you start your BBS.  The default entry for the IRCd inside of services.ini looks like this:
  
 +<code>
 [IRC] [IRC]
 Port=6667 Port=6667
 Options=STATIC | LOOP Options=STATIC | LOOP
 Command=ircd.js Command=ircd.js
 +</code>
  
 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.) 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.)
Line 47: Line 46:
 You will know if the IRCd has started successfully if you see entries like this in your BBS log: You will know if the IRCd has started successfully if you see entries like this in your BBS log:
  
 +<code>
 srvc 0007 IRC SynchronetIRCd-1.1b(1.102) started. srvc 0007 IRC SynchronetIRCd-1.1b(1.102) started.
 srvc 0007 IRC Reading Config: /sbbs/ctrl/ircd.conf srvc 0007 IRC Reading Config: /sbbs/ctrl/ircd.conf
 +</code>
  
 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. 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.
Line 54: Line 55:
 Test your new IRCd by connecting to it with an IRC client. At the very least, using 'telnet' to connect to the IRCd port (port 6667 by default) should give you something similar to the following line: Test your new IRCd by connecting to it with an IRC client. At the very least, using 'telnet' to connect to the IRCd port (port 6667 by default) should give you something similar to the following line:
  
 +<code>
 :rrx.synchro.net NOTICE * :*** SynchronetIRCd-1.1b(1.102) (RoadRunner X) Ready. :rrx.synchro.net NOTICE * :*** SynchronetIRCd-1.1b(1.102) (RoadRunner X) Ready.
 +</code>
  
 This is the standard Synchronet IRCd banner, informing you that the IRCd is accepting new connections correctly. This is the standard Synchronet IRCd banner, informing you that the IRCd is accepting new connections correctly.
Line 78: Line 81:
 (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: (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:
  
 +<code>
 #C:vert.synchro.net:QWK_PASSWORD:*.synchro.net:6667:30 #C:vert.synchro.net:QWK_PASSWORD:*.synchro.net:6667:30
 #N:vert.synchro.net:*:*.synchro.net::30 #N:vert.synchro.net:*:*.synchro.net::30
 +</code>
  
 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 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. 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, simply use the /REHASH command)and you should see a message similar to the following in your Synchronet console:+(4) If you know how to become an IRC operator, simply use the /REHASH command. If not, you can try **touch /sbbs/ctrl/ircd.rehash** otherwise restart your BBS. You should see a message similar to the following in your Synchronet console:
  
 +<code>
 srvc 0008 IRC Routing: Auto-connecting to rrx.synchro.net srvc 0008 IRC Routing: Auto-connecting to rrx.synchro.net
 srvc 0008 IRC Routing: Connected!  Sending info... srvc 0008 IRC Routing: Connected!  Sending info...
 srvc 0008 IRC 0018 Accepted new connection: 154.5.119.21 port 6667 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 srvc 0008 IRC Routing: Link with rrx.synchro.net established, states: TS
 +</code>
  
 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. 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.
Line 95: Line 102:
 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. 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.
  
-====== Using JSexec to run the IRCd+====== Using JSexec to run the IRCd ======
  
-There are times where you may wish to run the IRCd service separately +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.
-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 +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.
-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 +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:
-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+jsexec -l ircd
  
- The above command is typed from within the Synchronet 'exec' directory. +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.
-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) -==========+====== Using JSexec with systemd ======
  
- The Synchronet IRC Network is currently a small network with a BBS +A sample ''ircd.service'' file for starting/managing JSexec-invoked ircd.js instance is provided [[https://gitlab.synchro.net/main/sbbs/-/blob/master/install/systemd/ircd.service|in the Synchronet Git repository]].
-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 +Then run: 
-into the DNS round-robin for 'irc.synchro.net', which means that you can +systemctl enable ircd 
-expect to see connections from other clients who choose to use that address to +systemctl daemon-reload 
-connect to IRC.  You should expect to see your server listed in the round+systemctl start ircd
-robin within about 30 minutes, although it typically takes less.+
  
-=======- 5.0 -- Technical Information -=======================================+===== Setting up TLS/Secure Connections ===== 
 + 
 +If you are running with JSExec, you can add this line to your ircd.conf in order to accept secure requests: 
 + 
 +<code> 
 +P:*:*:*:6697 
 +</code> 
 +====== 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. 
 + 
 +====== Technical Information ======
  
 [5.1] - Limits of the Synchronet IRCd [5.1] - Limits of the Synchronet IRCd
  
- Although the Synchronet IRCd Service is written in Javascript, an +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.  
-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.+If you notice any slowdown or scaling problems, please let us know.
  
 [5.2] - Compliance with RFC's, and established protocols [5.2] - Compliance with RFC's, and established protocols
  
- The Synchronet IRCd has always aimed to be compliant with RFC1459, which +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.
-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 +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.
-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 +The Synchronet IRCd diverges from common IRC practice and Bahamut IRC protocol in the following fashion:
-protocol in the following fashion:+
  
- * The Synchronet IRCd does NOT make use of the "ident" protocol, which +* 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.
-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 +* The PASS message has been extended to allow for the passing and checking of QWK passwords in the case of dynamic connections:
-checking of QWK passwords in the case of dynamic connections:+
  
- PASS <password> :<qwk-id> QWK+PASS <password> :<qwk-id> QWK
  
- No destination is specified within the message, as the routing is +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:
-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>+PASS <result> :<qwk-id> QWK <origin>
  
- Where <result> is "OK" if the password check succeeded, and anything +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.
-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 +* 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:
-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 +- 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. 
-   replaced by the current time.  Thus, nickname collisions cannot be +- User mode +o (oper) is ignored.  However, local operators still retain authority over their local server. 
-   forced, and TS blasting is prevented. +- The KILL and SQUIT messages are ignored and reversed if the target is connected to a server beyond the scope of the leaf. 
- - User mode +o (oper) is ignored.  However, local operators still +- Services authorization modes (+z, +r, +q and friends) are ignored. 
-   retain authority over their local server. +- 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. 
- - The KILL and SQUIT messages are ignored and reversed if the target +- All channel modes are bounced on behalf of the leaf by the hub upon a resync. 
-   is connected to a server beyond the scope of the leaf. +- Private/Secret channels are not revealed to the leaf unless a user on the leaf explicitly joins the channel.
- - 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+====== Compatibility with other IRCd'======
  
- The Synchronet IRCd has only been tested to be link compatible with:+The Synchronet IRCd has been tested to be link compatible with:
  
  * Bahamut 1.4.35, 1.4.36 http://bahamut.dal.net  * Bahamut 1.4.35, 1.4.36 http://bahamut.dal.net
  * Andy Church's IRC Services 5.0 http://www.ircservices.za.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 +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.
-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 -==================================================+====== The Future ======
  
- Although the original intention of the IRCd was to allow users to +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.
-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, +Further compatibility with the later Bahamut daemons is planned, including the server-to-server "RESYNCH" command.  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.
-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 +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.
-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 ;) +====== Frequently Asked Questions ======
- +
-=======- 7.0 -- Frequently Asked Questions -================================== +
- +
-[7.1] - Installation Questions+
  
  Q: After setting up my IRCd, and trying to connect, it gives me an  Q: After setting up my IRCd, and trying to connect, it gives me an
Line 337: Line 260:
     would execute the command like this: '/OPER Sysop <syspass>'.     would execute the command like this: '/OPER Sysop <syspass>'.
     Also check out the O:Line section in ircd.conf.     Also check out the O:Line section in ircd.conf.
 +
 + Q: My ipv6 O:Line isn't working even if I surround the address with
 +    square brackets.
 +        
 + A: You need to enclose the whole netmask within the square brackets. Do
 +    include leading zeros in the netmask. It should match your /whois netmask.
 +    For example:
 +    [~jsmith@2001:440:1fff:b0:99d2:3cde:43e7:c96]
 +
 + Q: I've been forced off of the server with a "Terminated." message.
 +    What does this message mean?
 +
 + A: This message is an indication that the Sysop of your BBS/IRCd has
 +    shut down the BBS, and the IRCd is terminated as a result of that.
 +    It is an indication of explicit termination (i.e., the IRCd was
 +    instructed to shut down by a human being).
  
  Q: My question isn't answered in this document, where can I go?  Q: My question isn't answered in this document, where can I go?
Line 384: Line 323:
     banter among long-standing IRC users.     banter among long-standing IRC users.
  
-=======- EOF -================================================================