solanum-ircd / solanum

An IRCd for unified networks

solanum

Solanum is an IRCv3 server designed to be highly scalable. It implements IRCv3.1 and some parts of IRCv3.2.

It is meant to be used with an IRCv3-capable services implementation such as Atheme or Anope.

necessary requirements

• A supported platform
• A working dynamic library system
• A working lex and yacc - flex and bison should work

platforms

Solanum is developed on Linux with glibc, but is currently portable to most POSIX-compatible operating systems. However, this portability is likely to be removed unless someone is willing to maintain it. If you'd like to be that person, please let us know on IRC.

platform specific errata

These are known issues and workarounds for various platforms.

• macOS: you must set the LIBTOOLIZE environment variable to point to glibtoolize before running autogen.sh:

  brew install libtool
  export LIBTOOLIZE="/usr/local/bin/glibtoolize"
  ./autogen.sh

• FreeBSD: if you are compiling with ipv6 you may experience problems with ipv4 due to the way the socket code is written. To fix this you must: sysctl net.inet6.ip6.v6only=0

• Solaris: you may have to set your PATH to include /usr/gnu/bin and /usr/gnu/sbin before /usr/bin and /usr/sbin. Solaris's default tools don't seem to play nicely with the configure script. When running as a 32-bit binary, it should be started as:

  ulimit -n 4095 ; LD_PRELOAD_32=/usr/lib/extendedFILE.so.1 ./solanum

building

sudo apt install build-essential pkg-config automake libtool libsqlite3-dev # or equivalent for your distribution
./autogen.sh
./configure --prefix=/path/to/installation
make
make check # run tests
make install

See ./configure --help for build options.

feature specific requirements

• For SSL/TLS client and server connections, one of:

  • OpenSSL 1.0.0 or newer (--enable-openssl)
  • LibreSSL (--enable-openssl)
  • mbedTLS (--enable-mbedtls)
  • GnuTLS (--enable-gnutls)

• For certificate-based oper CHALLENGE, OpenSSL 1.0.0 or newer. (Using CHALLENGE is not recommended for new deployments, so if you want to use a different TLS library, feel free.)

• For ECDHE under OpenSSL, on Solaris you will need to compile your own OpenSSL on these systems, as they have removed support for ECC/ECDHE. Alternatively, consider using another library (see above).

tips

• To report bugs in Solanum, visit us at #solanum on Libera Chat

• Please read doc/readme.txt to get an overview of the current documentation.

• Read the NEWS.md file for what's new in this release.

• The files, /etc/services, /etc/protocols, and /etc/resolv.conf, SHOULD be readable by the user running the server in order for ircd to start with the correct settings. If these files are wrong, Solanum will try to use 127.0.0.1 for a resolver as a last-ditch effort.

git access

• The Solanum git repository can be checked out using the following command: git clone https://github.com/solanum-ircd/solanum

• Solanum's git repository can be browsed over the Internet at the following address: https://github.com/solanum-ircd/solanum

solanum's Issues

general::stats_l_oper_only missing from INFO

make overriding users immune to channel throttles

give modules a way to see which privs changed when privs change

Support NickServ AJOIN

This is implemented in oftc-hybrid as a fake join command (literally just builds the parameters up and calls m_join). As such, anything that would prevent the user from joining still applies (and it outright doesn't work with +k channels because there's no way to provide the channel key).

Atheme's ns_ajoin contrib module uses s2s syntax that matches oftc-hybrid already, so the same could be used here as well; alternately, adjusting ns_ajoin to use the same syntax as used with elemental-ircd (ENCAP SVSJOIN) would work as well.

Get rid of OPER_HANDLER

We've got lots of things that have their own privs which don't work properly unless you have oper:general. I think this is silly. Merge m_foo and mo_foo wherever those exist, check for privileges (ideally more specific than oper:general) in the handlers.

If we think it's nicer we can add a privilege to test for to Message? MessageEntry? to handle the common case with less boilerplate.

Revisit operspy

Ticket is a work in progress

Let's update spy and override to reflect the nature of our unified network approach. User connectivity is already advertised via client-connection snotices and we don't have a notion of server-local operator.

Things that stop being operspy:

• SCAN
• WHO - used to list users by nick or mask - keep the ! flag but don't announce it when used
• MASKTRACE - always do a global search, ignore ! if provided for compatibility

Things that stay spy:

• Channel information without joining: member list, mode parameters, topic
• Viewing user's hidden channel list
• Listing secret channels with LIST

Move off of Travis

Travis is no longer providing unlimited build credits for OSS; you now have to apply for build credit, and currently none are being given out. This has already been implemented for our org, and now we have a one-time 10,000 credit (10 credits is 1 minute on Linux, 50 credits is 1 minute on macOS) allowance, which we've already used 2,500 of. Our builds average about 11.5 minutes, with 2 minutes of that being macOS, so each build uses about 195 credits. Which means we have about 38 builds left before those credits are gone and Travis will no longer work at all.

Github Actions are completely free for public repos, and it certainly seems likely to stay that way for the foreseeable future, so we should probably switch to them.

consider allowing anyone to send STATUSMSGs even if they do not have said prefix mode

this could be useful to privately poke ops without pmming them etc

for what it's worth, InspIRCD already allows this.

Extend oper:override to cover cmode +f

The user shouldn't need to be a member nor operator in either channel.

allow opers to always grant themselves downwards

I figure it's probably not difficult to work back down privset inheritance and, especially for testing purposes, downgrading your privset might be useful

mode lists in config should be late-bound

the config handling resolves both mode strings and named mode lists to flags as it parses, which doesn't seem great as modes implemented by modules might not have been loaded.

I think they should all be mode strings, and they should remain stringy until the moment they're applied.

Multiple lines in the output of /findforwards

It would be neat to have m_findforwards generate multiple lines of replies in case the reply is too long to fit into one message.

It seems like it would make sense to do this after #51 has landed.

fold RPL_WHOISSPECIAL for oper/privset in to RPL_WHOISOPERATOR

I imagine we can forego configured oper/admin strings in RPL_WHOISOPERATOR when the person doing it has the permission to see the oper/privset info of the target, and as such we can stop using a vaguely contested numeric (RPL_WHOISSPECIAL, https://bugs.kde.org/show_bug.cgi?id=130588) and also forego needless information in whois

:server 313 jess jess :is an IRC Operator
:server 320 jess jess :is opered as jess, privset sandcat

can just become

:server 313 jess jess :is opered as jess, privset sandcat

Improved SCAN

This ticket is a work-in-progress

Proposal

We need a good way to search the userlist with a flexible set of search criteria. Currently SCAN and WHO are closest to this functionality. The proposal is to enhance SCAN.

Some filters will be required to run on remote servers. In the case that such a filter is used will want to distribute the scan to run across all servers instead of locally.

When NO-LIST is specified the number of local and global matches will be returned. If a global scan is needed then each server will report the local matches.

• When no output options are specified the default will be: nickname, username, hostname, IP address, servername, user mode, realname
• As is the case with existing SCAN, OPERSPY will be required to perform a GLOBAL, LIST scan.
• We risk having too many parameters with a verbose model.
• Instead of a LOCAL predicate we could have a special SERVER sentinel that indicates local
• All predicates should be negatable.

New API:

/SCAN [LIST] [%OUTPUTS] [PREDICATES...]
/SCAN NO-LIST [PREDICATES...]

Predicates:
MASK <nick!user@host>
UMODE +<modes>-<modes>
GLOBAL|LOCAL
SERVER <servermask>
ACCOUNT <accountname>
CONNECT [<timestamp] [>timestamp]
IDLE  [<seconds] [>seconds]
CHANNEL <#channel>
AWAY|NO-AWAY
REALNAME <realname> -- last field to allow whitespace

Outputs:

Existing work

We'll want to at least do as much as the existing work provides.

Current SCAN

SCAN UMODES +<modes>-<modes> [NO-LIST] [LIST] [GLOBAL]
                        [LIST-MAX <number>] [MASK <nick!user@host>]

Current WHO on OFTC

/WHO [+|-][acghimnsuCMI] [args]
Flags are specified like channel modes,
The flags cghmnsu all have arguments
Flags are set to a positive check by +, a negative check by -
The flags work as follows:
Flag a: user is away
Flag c <channel>: user is on <channel>,
                  no wildcards accepted          
Flag g <gcos/realname>: user has string <gcos> in their GCOS, 
                        wildcards accepted, oper only         
Flag h <host>: user has string <host> in their hostname,
               wildcards accepted
Flag i <ip>: user is from <ip> wildcards accepted, 
Flag m <usermodes>: user has <usermodes> set on them,
                    only o/A/a for nonopers               
Flag n <nick>: user has string <nick> in their nickname,
               wildcards accepted
Flag s <server>: user is on server <server>, 
                 wildcards not accepted     
Flag u <user>: user has string <user> in their username,
               wildcards accepted
Behavior flags:
Flag C: show first visible channel user is in 
Flag M: check for user in channels I am a member of 
Flag I: show IP addresses instead of hostnames
Flag S: Show server name of user

Predicates to support

• Channel
• Maximum results to return (LIST-MAX)
• Hostmask (MASK)
• Local/Global
• Servername
• Connection time range
• Idle time range
• Usermodes
• Services account name
• Realname
• Away status

Make every ban-ish thing propagatable, allow permanent propagated bans

I think it's possible to solve the unkline problem with a slight shift in perspective. If each server stamps its bans with an incrementing number, netjoining servers A and B can, for each server S that has originated extant bans, compare their lists of bans originated by S that still exist, and server A can remove any bans by S it has that server B is missing within the range for which server B has information. We can probably deal with originator name proliferation, if we think it's going to be a problem, with a command to instruct a server to steal all of another server's bans.

Config option to skip loading certain autoloaded modules

Improve the module API

Things I think we should have:

• Module flags: NO_HOT_LOAD, NO_RELOAD, NO_UNLOAD (NO_UNLOAD without NO_RELOAD would mean it can unload only if it's going to reload again, and ircd has to abort if loading fails)
• Tell modules when they're being loaded/unloaded (with another flag field, presumably) whether it's a cold start, reload, etc
• Unify all the lists of things modules have into something that can be extended without a new module API
• A big such thing worth listing individually: memory areas on various IRC objects (client, local client, channel, membership) that modules can allocate parts of
• Inter-module dependencies?

snote when an oper sets/unsets a chm_hidden mode

setting/unsetting a chm_hidden mode feels like a bit of an event given the only one we've got is chm_operpeace, so I think it makes sense to let everyone know

implement REGISTER

reword ERR_ALREADYREGISTRED as people confuse it for nickserv

solanum/include/messages.h

Line 175 in 99b8e2f

#define NUMERIC_STR_462 ":%s 462 %s :You may not reregister"

lots of people see this message (I think it's mostly hexchat trying to do something strange) and mistake it for a nickserv thing. maybe we can s/reregister/redo handshake/ or so?

Config option for minimum TLS version

/accept list should track nick changes when you share channels

add formatting reset after gecos in cliconn snotes

Centralise multiline reply generation

BMASK doesn't burst set by/at metadata

chan TS change notices are useless and confusing

we get a non-negligible amount of users asking what this is and trying to explain how S2S handles netjoin collisions to explain what a timestamp is so we can explain why chanserv is resetting it drives me nuts. no end user needs to know this information

solanum/modules/core/m_join.c

Lines 440 to 441 in f679aa4

	sendto_channel_local(&me, ALL_MEMBERS, chptr,
	":%s NOTICE %s :*** Notice -- TS for %s changed from %ld to 0",

change +g override to be opt-in

opers walking over +g isn't always intentional and checking someone's umodes first is cumbersome, invasive and not possible for umode O users.

adding a separate umode to enable +g override might work. might need two forms of the override: one that is meant for time-limited usage (staff talking to people) and one that is for bots (think freenode-connect)

Add secure{} blocks to STATS

put account name in cliconn if user did SASL auth

Duplicate the ban reason in the ERROR message for banned clients

Because some clients only show the ERROR and not the ban reason from the numeric error

Add config to prevent non-+Z clients from becoming opers by any means

netjoin reverses order of banlist

not sure why this happens but along with metadata (setby, setat) loss, netjoined servers display banlists in reversed order - perhaps an issue with BMASK

H

extb_extgecos doesn't support CIDRs

Remove notion of server clusters

We use a unified network architecture, this functionality adds complexity that we don't benefit from.

oper_up should be able to fail

Config options to disable and hide arbitrary caps

Support remote SET

Currently SET only works on the local server; it should work remotely.

make linking faster

Support shedding users

Shedding actively disconnects users from the ircd, so that they can reconnect to the round-robin. It does this one user at a time, at an oper-specified interval (with random variation added). It's usually configured to exclude opers, but not always. The syntax from OFTC help:

SHEDDING <server> <approx_seconds_per_userdrop> <opers_too?[0|1]> :<reason>
SHEDDING <server> OFF

Reason is only logged in the snote reporting that shedding has been enabled; it is not otherwise available. The module is here: https://github.com/oftc/oftc-hybrid/blob/develop/modules/m_shedding.c

m_who.c doesn't support whox %H

in the interest of being able to get the same information out of WHOX as we can from #13, it would be good if we can support WHOX flag %H, as well as %h, which is defined as

- h - show host names.
- H - show real host names. Only available to privileged users, otherwise falls back to "h".

which, I assume, would involve copying this but replacing it with orighost:

solanum/modules/m_who.c

Lines 519 to 520 in 6b3ae7e

	if (fmt->fields & FIELD_HOST)
	append_format(str, sizeof str, &pos, " %s", target_p->host);

and adding one of these for e.g. FIELD_REALHOST

solanum/modules/m_who.c

Line 130 in 6b3ae7e

case 'h': fmt.fields |= FIELD_HOST; break;

split WALLOPS out of oper:massnotice

would be nice to not have to give someone the permission to do global notices when we're just interested in the ability to wallop

chm_hidden modes are not seen if you oper up after joining

if you don't oper up before joining a channel with a chm_hidden mode on it, you won't get told about it until you run /mode manually, and on irssi you actually have to /cycle.

offer SASL when agent missing but instantly ERR_SASLFAIL

I don't like the idea of new clients not knowing that we support SASL just because services is currently missing, and I think it's easier to understand as a failure to an end user than SASL just suddenly being gone.

improve ircv3 support

Solanum is a little behind as far as IRCv3 features are concerned. It would be nice to see things like message-tags and history playback added in the future. Most of the popular modern IRCds have this and I think many users (myself included) would like to see this.

VERSION response doesn't need to include server id

`MODE otheruser` only shows snomask for local user

we should either always show another user's snomask or never show it

Add a style guide

account-notify messages should go to the subject's client too

per https://ircv3.net/specs/extensions/account-notify-3.1#errata

A previous version of this specification didn’t make it clear that account-notify messages are sent for a client’s own account name changes.

I think we just need to chop off _butone?

solanum/modules/m_services.c

Lines 139 to 141 in f679aa4

	sendto_common_channels_local_butone(target_p, CLICAP_ACCOUNT_NOTIFY, NOCAPS, ":%s!%s@%s ACCOUNT %s",
	target_p->name, target_p->username, target_p->host,
	EmptyString(target_p->user->suser) ? "*" : target_p->user->suser);

support more human friendly k/d/x-line duration format

example:
KLINE 11520 *@1.2.3.4 :go away
could instead be:
KLINE 1w1d *@1.2.3.4 :go away

I think we'd want to support week, day, hour, minute

I think this is where would want changing....

solanum/ircd/s_newconf.c

Lines 684 to 685 in 6485005

	time_t
	valid_temp_time(const char *p)