Recommended Irc Server (Ircd) for a Small Site

Recommended IRC server (ircd) for a small site?

During the past couple days I have been coding a bot with Python and IRCLib. Since I am coding the communication interface I needed to see the raw data transfered between the server and the client. So, I needed an IRC server which would support that. At first I was using IRCD, and it was totally fine. But after a while I realized that I was missing some features that IRCD did not have since it's outdated. So, after further research I found ngIRCd.

I compiled it from source with those options "--enable-sniffer --enable-debug". Now when I want to see the information sent between my bot and my client I only need to start the server with the -n and -s option. Like that : ngircd -n -s

Here is the website of the server : http://ngircd.barton.de/

Confusion about the 005 IRC numeric and general RFC

RFC2812 and its companions only reflected usage on IRCNet at the time. They were actually more of a political statement following the "great split" between EFNet and IRCNet. Rather than reflect any sort of community consensus, they
sought to codify IRCNet's practices as the "standard", even as numerous other networks had adopted competing implementations around the "TS" (timestamp) protocol.

The only known implementation of RPL_BOUNCE was in IRCNet's IRCD - and following the widespread adoption of 005 to mean RPL_ISUPPORT, and it's growing necessity to be able to convey differences in implementation to clients, RPL_BOUNCE was moved to the 010 numeric, and IRCNet itself has adopted 005 as RPL_ISUPPORT.

RPL_BOUNCE was itself a reflection or IRCNet philosophy. Servers on IRCNet have historically been tightly restricted along geographic and nationalistic lines - for example, a sever based in France might only accept connections from France and neighboring countries. In the past, this was very strictly enforced, with servers expected to only serve the limited user bases with which they had applied to serve, and only a small number of "open" servers permitted at any given time for the benefit of users without a server in their area. The overall effect of this was that any given user would have only a few servers to which they were authorized to connect, based on their
internet provider and geographic location, and therefore the "bounce" numeric provided a way for the geographically restricted servers to advertise another server for the user to connect to.

RPL_ISUPPORT was submitted as an Internet Draft, but for reasons unknown, there was no follow through on moving it towards the RFC stage.

In many cases, the source code of the server (ircd) software itself, and occasionally, some text files included with it, are the only meaningful documentation of modern usage - especially for server-to-server protocols, which are now completely nonstandard and tied to specific implementations.

There are some groups attempting to harmonize the various client-server extensions, such as the IRCv3 working group, but really, RFC1459 is still the least common denominator.

Postel's admonition to be conservative in what you do, be liberal in what you accept from others is especially true with respect to IRC, as clients must contend with an ever growing and ever diverging array of implementations. Good luck.

UnrealIRCd or InspIRCd

There are many ways you can compare the two IRC servers, a good comparison could be found at Comparison of Internet Relay Chat daemons

Few additions as well are:

• Both ircd projects are up to date.
• Both have a rich modules libraries.
• Both have a good recent commit history & issue tracker.
• They have almost the same feature support, although InspIRCD is in favor.

For me personally, i prefer InspIRCD, i feel they have the edge, with accepting new ideas and implementing features.

At the end, base on those comparison, it doesn't really matter, both of them are doing a great job all around, and are well distinguished between others.

How to get operator rights in ircd-hybrid?

The operator tag is commented out. Replace the "#operator {" with "operator {" and then try again after rehashing the ircd with a SIGHUP.

Implementing IRC RFC: How to respond to MODE?

RFC 1459 is famously sparse. It does not tell you everything you need to know to write a server.

In this case, what's missing is the distinction between a MODE command that queries an existing mode, and a MODE command that sets a new mode. In the case of a mode query, a client will receive a numeric reply that indicates the existing mode; in the case of altering a mode, a client will not receive a direct numeric reply unless there was an error. However, if the mode was successfully altered, then a client will recieve a MODE from the server informing it of the change.

So for example, if the client's nick is foo and it sends:

MODE foo

then this is querying its current usermode - it will expect a RPL_UMODEIS reply like:

:irc.example.org 221 foo :+i

If the client then sends:

MODE foo :+w

then this is altering its usermode - it will either get a numeric error like ERR_USERSDONTMATCH or an acknowledgement of the mode change:

:foo!foo@bar.com MODE foo :+w

Note that this acknowledgement is technically not a direct reply to the MODE - it's the server informing the client of a relevant change in its state, which happens to have been triggered by a client command.

A similar situation exists with channel modes. If a client queries the current channel modes with:

MODE #channel

then it will expect a RPL_CHANNELMODEIS response containing the current "simple" channel modes, and perhaps a RPL_CREATIONTIMEresponse giving the channel creation time. If it queries for the current ban list with:

MODE #channel b

then should get zero or more RPL_BANLIST responses, followed by a RPL_ENDOFBANLIST.

If instead a client tries to change a channel mode:

MODE #channel :+k zounds

then the direct reply will either be an error reply or nothing; and if the channel mode was actually changed, it will see the MODE command echoed back. In the latter case the successful MODE command will also be sent to the other members of the channel - this helps to illustrate that it's not really a direct reply to the initial MODE command, but an indirect response to it.

Responde to no Ident response on IRC

as @Miserable_Variable already linked to, you need an ident service running on tcp:113

on that port you will receive a connection from the IRCd that will give you something like

"xxxxx, 6667" where xxxxx is the portnumber of the IRC connection on your side and obviously 6667 is the portnumber on the side of the IRCd ...

if you reply with "xxxxx, 6667 : USERID : UNIX : yyyyy" where yyyyy stands for your username and xxxxx for the requested port number, the IRCd should accept your connection (unless you caught yourself a ban ...)

How to check if $4 is registered in IRC?

Since you have not specified any particular network I wrote an outline for some common networks around (that actually have user authentication systems). You should be able to add many other networks following the pattern.

Basically you execute /checkNickReg <target> <nick> [optional extra data] and when the server replays with the registration info (if applicable) use the on isReged signal event to handle the reply. Everything else is pretty much transparent.

EDIT: Looks like the specified network you are using (Torn) uses the standard anope services. So I updated the code to support that network.

; triggers when you get nick registration info back
; $1 = Target
; $2 = Nick
; $3 = Status, can be: LOGGEDIN, RECOGNIZED, NOTLOGGED
; $4- = Everything else passed
on *:signal:isReged:{
  echo -a Target: $1
  echo -a Nick: $2
  echo -a Status: $3
  echo -a Else: $4-
}

; reg lookup routines
alias checkNickReg {
  set %reg. $+ $network 1
  set %reg.target. $+ $network $1
  set %reg.nick. $+ $network $2
  set %reg.other. $+ $network $3-

  ; Freenode uses: NickServ ACC <nick>
  if ($network == Freenode) msg NickServ ACC $2
  ; Rizon/SwiftIRC/OFTC/Torn use: NickServ STATUS <nick>
  elseif ($istok(Rizon SwiftIRC OFTC Torn, $network, 32)) msg NickServ STATUS $2
}

; listen for replays
on *:notice:*:*:{
  if ($($+(%, reg., $network),2)) {
    ;
    var %target = $($+(%, reg.target., $network),2)
    var %nick = $($+(%, reg.nick., $network),2)
    var %other = $($+(%, reg.other., $network),2)
    ;
    unset %reg*. $+ $network

    if (($network == FreeNode) && ($2 == ACC)) $&
      || (($istok(Rizon SwiftIRC OFTC Torn, $network, 32)) && ($1 == STATUS)) {

      ; FreeNode:

      ; 0 = does not exist
      ; 1 = exists, not logged in
      ; 2 = recognized, not logged in
      ; 3 = logged in

      ; Rizon/SwiftIRC/OFTC/Torn:

      ; 0 = does not exists / not online
      ; 1 = not logged in
      ; 2 = recognized, not logged in
      ; 3 = logged in

      if ($3 < 2) var %status = NOTLOGGED
      elseif ($3 == 2) var %status = RECOGNIZED
      else var %status = LOGGEDIN
    }

    ;send status signal
    .signal isReged %target %nick %status %other 
  }
}

(Extra Note: It might be useful to add an extra check to make sure $nick is AuthServ/NickServ for security reasons.)

A simple usage example is:

; Just a basic example of how to call it.
on *:text:!isReged &:#:{
  checkNickReg $chan $2 $nick
}

on *:signal:isReged:{
  msg $1 $4: $2 status is: $3
}

Type !isReged <nick>

Edit: The data gets passed to the on isReged event via global variables. I set them in the checkNickReg alias and I clean them up in the on notice event. So you never see them because they get cleaned up. They are passed to the isReged signal event in $1-.

---

Related Topics