inspircd-docker
inspircd-docker copied to clipboard
conf/*.sh files are (unnecessarily?) tricky to override
I'm super happy with inspircd-docker. It's allowed me to get an IRC server running locally really quickly. I'm not super familiar with Docker, but I was able to trivially update some conf/*.conf
files so that I could have a lot more local connections while I develop my software.
However, when I wanted an oper to be able to use the sajoin
command I edited conf/opers.sh
and that didn't work. I wasn't too surprise, because there was a warning in that file about not editing it after a build. After (way too much?) futzing around, I think I understand what is happening, but I can't tell if it's a deliberate design decision or just the fallout of incremental development.
AFAICT (and I may be wrong), because conf/inspircd.conf
has lines like:
<include executable="conf/opers.sh">
that pulls opers.sh
in from a directory that is not overwritten when people use the -v
option of docker to create a bind mount. However, the *.conf
files are overwritten.
Locally I've created a consistent_configuration
branch that uses inspircd/conf
instead of conf
, e.g.,
<include executable="inspircd/conf/opers.sh">
and it works for me. However, I do not know why the code is the way it is and it's quite possible that my branch is worse for other use cases. However, if my upcoming PR is inappropriate, then it may be worth adding a little to README.md
to explain the dichotomy between the .conf
and the .sh
files.
@ctm, the design is definitely deliberate. The .sh
files are not meant to be edited.
Without getting into too much detail, for your specific use case: if you are you are mounting a configuration directory anyway, you might as well manually edit the configuration settings in each file to your liking. One solution would be to:
- add a line to your
inspircd.conf
:<include file="conf/my_opers.conf">
- declare the
oper
block in amy_opers.conf
in the directory (I assume) you are mounting at/inspricd/conf
with-v
(also, I assume you are manually adding/modifying theoper
block in theopers.sh
file?? just copy-pasta the block with your modifications into themy_opers.conf
file.)
The .sh
files are meant to help bootstrap a container with minimal external input, yet allowing for any necessary customization by mounting a conf.d
dir (as .d
dirs are commonly used for exactly this reason.
Honestly, with a full conf dir mount, I would suggest making a my_conf.conf
and include
ing it in inspircd.conf
as I described above (if you really don't comfortable changing the main conf files themselves, that is)
Note: I said "Without getting into too much detail, for your specific use case" because it seems that you are already mounting to /inspircd/conf
and the steps I mentioned are the recommended solution (probably..? disclaimer: I'm not a dev here :upside_down_face: just speaking as a longtime, avid, docker-izer), instead of your PR that would possibly (probably?) throw a wrench into many users' normally functioning setups :grimacing:
@ctm how to you start your container? What volumes do you mount?
@SISheogorath I use
docker run -v /Users/ctm/inspircd-docker/conf:/inspircd/conf --rm --name inspircd -p 6667:6667 -e "INSP_ENABLE_DNSBL=no" -e "INSP_OPER_NAME=mb2" -e "INSP_OPER_SSLONLY=no" -e 'INSP_OPER_PASSWORD_HASH=redacted' inspircd/inspircd-docker
and have also verified that the same invocation, but without the -v
command, i.e.,
docker run --rm --name inspircd -p 6667:6667 -e "INSP_ENABLE_DNSBL=no" -e "INSP_OPER_NAME=mb2" -e "INSP_OPER_SSLONLY=no" -e 'INSP_OPER_PASSWORD_HASH=redacted' inspircd/inspircd-docker
still works (and gives the default configuration). Beyond the mods in my PR, I locally have changed two .conf
and one .sh
file:
diff --git a/conf/inspircd.conf b/conf/inspircd.conf
index d38aeb4..96e3c8e 100644
--- a/conf/inspircd.conf
+++ b/conf/inspircd.conf
@@ -121,10 +121,10 @@
fakelag="on"
# localmax: Maximum local connections per IP.
- localmax="3"
+ localmax="30000"
# globalmax: Maximum global (network-wide) connections per IP.
- globalmax="3"
+ globalmax="30000"
# useident: Defines if users in this class must respond to a ident query or not.
useident="no"
diff --git a/conf/modules.conf b/conf/modules.conf
index 721ecd8..75dc1e9 100644
--- a/conf/modules.conf
+++ b/conf/modules.conf
@@ -588,7 +588,7 @@
# Connectban: Provides IP connection throttling. Any IP range that
# connects too many times (configurable) in an hour is Z-Lined for a
# (configurable) duration, and their count resets to 0.
-<module name="m_connectban.so">
+#<module name="m_connectban.so">
#
# ipv4cidr and ipv6cidr allow you to turn the comparison from
# individual IP addresses (32 and 128 bits) into CIDR masks, to allow
@@ -601,7 +601,7 @@
#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#
# Connection throttle module.
-<module name="m_connflood.so">
+#<module name="m_connflood.so">
#
#-#-#-#-#-#-#-#-#-#-#- CONNTHROTTLE CONFIGURATION -#-#-#-#-#-#-#-#-#-#
# seconds, maxconns - Amount of connections per <seconds>.
diff --git a/conf/opers.sh b/conf/opers.sh
index dbb5b58..e6d1117 100755
--- a/conf/opers.sh
+++ b/conf/opers.sh
@@ -59,7 +59,7 @@ cat <<EOF
# chanmodes: Oper-only channel modes that opers with this class can use.
chanmodes="*">
-<class name="SACommands" commands="SAJOIN SAPART SANICK SAQUIT SATOPIC SAKICK SAMODE OJOIN">
+<class name="SACommands" commands="SAJOIN SAPART SANICK SAQUIT SATOPIC SAKICK SAMODE OJOIN" privs="users/sajoin-others">
<class name="ServerLink" commands="CONNECT SQUIT RCONNECT RSQUIT MKPASSWD ALLTIME SWHOIS JUMPSERVER LOCKSERV UNLOCKSERV" usermodes="*" chanmodes="*" privs="servers/auspex">
<class name="BanControl" commands="KILL GLINE KLINE ZLINE QLINE ELINE TLINE RLINE CHECK NICKLOCK NICKUNLOCK SHUN CLONES CBAN CLOSE" usermodes="*" chanmodes="*">
<class name="OperChat" commands="WALLOPS GLOBOPS" usermodes="*" chanmodes="*" privs="users/mass-message">
I found that without adding the privs="users/sajoin-others"
, having SAJOIN
was useless. Initially it was a mystery why my change to opers.sh
didn't work, while my change to the other two .conf
files did.
If my changes are inappropriate, a little extra documentation (explaining, at minimum, the expected different behavior between the .conf
and .sh
files) might help someone else in my situation, although perhaps nobody else would be as easily confused. FWIW, now that I understand what's going on, I certainly don't need the change.