View Issue Details

IDProjectCategoryView StatusLast Update
0004361unrealinstallingpublic2015-06-20 15:22
Reportersyzop Assigned Tosyzop  
Status resolvedResolutionfixed 
Product Version3.4-alpha3 
Target Version3.4-alpha4Fixed in Version3.4-alpha4 
Summary0004361: better directory structure & 'make install' by default (also good for system packages)
Description* Assume a 'make install' type of environment by default (and tell users this, especially at the end of 'make').

* Create a good directory structure rather than having so many files in the root directory, see Additional Information.
Additional Information(More or less raw notes..)

We currently have the following:
* unrealircd.conf (user needs to create this)
* example.conf + many translations of this file
* help.conf + many translations of this file
* badwords.*.conf (3 files)
* spamfilter.conf
* dccallow.conf (optional example, normally not included)

I was thinking like:

conf/ - root conf directory
conf/unrealircd.conf - where we expect the unrealircd.conf :)
conf/example/ - for example.*conf
conf/help/ - for help.*conf

so far so good, but how about the rest...

badwords.*.conf is often unchanged, so do we put this in conf/ directory? or in conf/example/ ? (because it still could be customized). Or in conf/badwords/ which may be over-the-top. Similar situation for spamfilter.conf...
Actually, now I think about it: nowadays, when we extract to 3.4-alphaX/ and such, an no longer to the fixed 'Unreal3.2' which we did until a few years ago, you (normally) no longer have that danger of overwriting. So then it's safe to just put things like badwords.*.conf and spamfilter.conf directly in conf/ I think.

Or maybe not conf/ but etc/. I think conf/ is more descriptive though, but etc/ is more standard I guess.
TagsNo tags attached.
3rd party modules



2015-06-14 15:33

reporter   ~0018386

+1, but i'd like to also see the example.conf split into 2 files.

1> a bare minimum file that allows Unreal to start. think minimalist.
2> a references.conf file that is more robust and has more optional settings in it.

A perfect example is how Bahamut ships. I think we can all agree that a 700+ line config file is a bit much.

As far as the file tree goes I think it should follow the current FHS (File Hierarchy Standard) to make it easier for package maintainers to package the ircd.


2015-06-14 16:26

administrator   ~0018387

Last edited: 2015-06-14 16:32

I totally understand what you mean, so I already edited the doc/example.conf in 3.4.x a couple of weeks ago, it's 400 lines now and I think it looks fine :)

The other point you raise is something to consider indeed.

We may need a few more (config-time) configurable directories then. Right now we have just DPATH (which is like /home/irc/Unreal3.4) and assume things from there.

We may need to declare a:
* configuration file directory (etc/ or conf/ for user install, /etc/unrealircd for system install)
* modules directory (modules/ for user install, something totally different for system install) -- this will also mean loadmodule lines would no longer be loadmodule "modules/something"; but rather loadmodule "something"; -- no problem, still in alpha stage..
* tmp directory (tmp/ for user install, something different for system install, but not /tmp)

I think the ircd.motd, oper motd and such can be just in the same directory as configuration files.

server.cert.pem, server.key.pem, curl-ca-bundle.crt, etc.. could be in etc/ or in a etc/ssl/ I think. But probably without the magic (see next).

I don't think we should have too many paths for this and paths for that, it creates too much magic and end-user will wonder what (no.. WHERE) UnrealIRCd is going to read / load something. So just the minimum.

Did I miss one?

Haven't actually started on anything, usually during the process I see things I hadn't though about yet..


2015-06-15 11:53

administrator   ~0018388

Last edited: 2015-06-15 11:54

Just installed some ircd packages, didn't know debian ships with inspircd and ratbox nowadays...
both use /etc/inspircd and /etc/ratbox directories, like just proposed.
modules of ircd-ratbox go in /usr/lib/x86_64-linux-gnu/ircd-ratbox/ and of inspircd go in /usr/lib/inspircd/modules/

Both ratbox and inspircd have their binaries in /usr/sbin. Not immediately logical if you ask me, but since an init script is used to run it (see later) it's fine and it's probably correct since a regular user (say 'xyz') shouldn't run it directly when it is expected to run as 'irc'.

Inspircd has a /usr/sbin/inspircd binary but also an /usr/lib/inspircd/inspircd script (perl script), that latter is basically just like the 'unreal' script we have.

Hmmm.. what else.. Ah yeah, ircd-ratbox package creates a /var/log/ircd-ratbox directory owned by irc:irc. Inspircd doesn't and assumes /var/log/inspircd.log. I for sure prefer the former but that's not important.

Other than that, nothing too special, actually. Some lograte conf, an init script which uses start-stop-daemon and such to set the uid & gid... Prety much all what you'd expect.

So no surprises there.

Note that this bugid is not about creating a package itself. Rather this is about which configure items that are needed to make it easier to package unreal (and the impact on the rest of the conf).

In that respect you can see some consequences of the inspircd vs ratbox choice with regards to the modules stuff. With inspircd they have /usr/lib/inspircd with 'inspircd' and '.gdbargs' files and then a 'modules/' directory under it... so it's some kind of base for things. With ratbox they directly place the modules in /usr/lib/ircd-ratbox. I'd say the latter is more logical unless we can think of other non-modules files that should belong there. Though the latter makes it easier as it would make loadmodule modules/... still work like it is today (since the root for modules is then one directory up).
I'm leaning to directly so like ratbox, like my initial idea in previous post, actually. The 'module' part in 'loadmodule "modules/..."' is rather redundant after all, and since we may break conf's in 3.4.x why not do it now.


2015-06-15 11:56

administrator   ~0018389

And I'd be happy to see some feedback from package maintainers, Heero, etc.. so *set to feedback* :]

Would want this in 3.4-alpha4.


2015-06-15 12:01

administrator   ~0018390

Last edited: 2015-06-15 12:03

Perhaps we could rename the 'unreal' script to 'unrealctl'? like apachectl has? :)
Or 'unrealircdctl' ? (For consistency, but long to type)

For system-installs maybe not terribly important as they will likely have to use /etc/init.d/... or rather 'service unrealircd' to start/stop/reload.
Though it should be mentioned that our tool also does things like mkpasswd, upgrade-conf, etc.. (similarly how apachectl does different stuff too like configtest, fullstatus, etc).


2015-06-17 05:41

reporter   ~0018404

Packaging depends on the platform. /etc/init.d is replaced on the major desktop distributions (Feroda, Ubuntu, openSUSE at least) with systemd.

I can give the example of my packages for SUSE Linux. SUSE provides a set of guidelines with links to other distributions' ideals:

When packaging for openSUSE 13.2 or SLE 12 I have to write unit files to start and stop the application with systemd.

The unreal script is not usable directly or as a init.d script. If used for the Exec in the unit file it will not do what is expected. The service may always report failed if systemd cannot find a path in proc from the launched process to systemd's PID 1 process with the expected name. PID files help with this but see bellow for more issues with that.

With systemd, having both and init.d file and the unit file causes package lint errors on the SUSE Open Build Service ( The lint errors can prevent the package from being published even if it does build.

The unreal script ends up sidelined in a harmless path instead of /etc/init.d. To get access to commands like rehash, upgrade-conf and gencloak one has to wrap the unrealircd script using the legacy-actions feature of systemd.

You are correct that the .conf files can be problematic. They are hard coded in the binary. To handle the location of the unrealircd.conf file one can pass a fixed path inside the unit file. Unfortunately that .conf file does not contain the configuration location of many important locations. Things like the tmp directory, cache for cURL, modules directory or other parts are actually compiled in. Unless you patch the sources it is not possible to relocate them at install time or build time to distribution preferred locations. It is certainly a challenge to build a relocatable package with how UnrealIRCd treats directories like cache and modules and the generated files.

For example on SUSE the file used to go into /var/run/, then to /var/run/$name/ and now goes in /run/$name/ which must be created on boot by the tmpfiles.d process.

On RedHat and Fedora it still goes into /var/run/$name/. If SELinux is use the package must ship a $name-policy.te file granting ircd rights to create files in it. Since the choice to use SELinux is up to the user not the maintainer, a proper RedHat package must include that policy file.


2015-06-17 14:43

reporter   ~0018405

Since different distros put things in different places, despite the fact that we have file hierarchy standards for Linux, perhaps we should let would-be package maintainers worry about correct paths on system builds.


2015-06-19 14:03

administrator   ~0018407

Last edited: 2015-06-19 14:06

New items:
  --with-bindir=path Specify the directory for the unrealircd binary
  --with-scriptdir=path Specify the directory for the unrealircd start-stop
  --with-confdir=path Specify the directory where configuration files are
  --with-modulesdir=path Specify the directory for loadable modules
  --with-logdir=path Specify the directory where log files are stored
  --with-cachedir=path Specify the directory where cached files are stored
  --with-tmpdir=path Specify the directory where private temporary files
                          are stored. Should not be readable or writable by
                          others, so not /tmp!!
  --with-datadir=path Specify the directory where permanent data is stored
  --with-docdir=path Specify the directory where documentation is stored
  --with-pidfile=path Specify the path of the pid file

I tried the defaults (so without --with-) but that was just a mess, some --with and some without --with... so I settle with this for now. Who cares anyway.

Result looks nice!

Regular user-install (default):
syzop@vulnscan:~/unrealircd$ tree -d
|-- bin
|-- cache
|-- conf
|   |-- aliases
|   |-- ssl
|-- data
|-- doc
|-- logs
|-- modules
|   |-- chanmodes
|   |-- extbans
|   |-- usermodes
|-- tmp

Still work in progress. Certainly not finished yet.

Things like modules.conf have been updated to use loadmodule "m_something" rather than loadmodule "modules/m_something".

In the build tree also a lot changed:
# renamed: Donation -> doc/Donation
# renamed: aliases/aliases.conf -> doc/conf/aliases/aliases.conf
# renamed: aliases/anope.conf -> doc/conf/aliases/anope.conf
# renamed: aliases/atheme.conf -> doc/conf/aliases/atheme.conf
# renamed: aliases/auspice.conf -> doc/conf/aliases/auspice.conf
# renamed: aliases/cygnus.conf -> doc/conf/aliases/cygnus.conf
# renamed: aliases/epona.conf -> doc/conf/aliases/epona.conf
# renamed: aliases/generic.conf -> doc/conf/aliases/generic.conf
# renamed: aliases/genericstats.conf -> doc/conf/aliases/genericstats.conf
# renamed: aliases/ircservices.conf -> doc/conf/aliases/ircservices.conf
# renamed: aliases/operstats.conf -> doc/conf/aliases/operstats.conf
# renamed: -> doc/conf/
# renamed: badwords.message.conf -> doc/conf/badwords.message.conf
# renamed: badwords.quit.conf -> doc/conf/badwords.quit.conf
# renamed: dccallow.conf -> doc/conf/dccallow.conf
# renamed: help.conf -> doc/conf/help.conf
# renamed: modules.conf -> doc/conf/modules.conf
# renamed: spamfilter.conf -> doc/conf/spamfilter.conf
# renamed: curl-ca-bundle.crt -> doc/conf/ssl/curl-ca-bundle.crt
# renamed: ->

again, more to follow later.


2015-06-20 15:21

administrator   ~0018409

About 10 more commits were made related to this (& other file renames / moves).
eg: badwords.*.conf is now badwords.conf, help.conf is now in (conf/)help/, example configuration is in (conf/)examples/ etc..

Some small things may still change later, but I'm marking this as done.

If a package maintainer still sees some missing functionality then please do let me know!

(Or anyone else, of course...)

Issue History

Date Modified Username Field Change
2015-06-14 12:50 syzop New Issue
2015-06-14 12:54 syzop Product Version 3.4-alpha4 => 3.4-alpha3
2015-06-14 12:54 syzop Target Version => 3.4-alpha4
2015-06-14 12:54 syzop Description Updated
2015-06-14 12:54 syzop Additional Information Updated
2015-06-14 12:55 syzop Status new => acknowledged
2015-06-14 12:55 syzop View Status private => public
2015-06-14 12:55 syzop Additional Information Updated
2015-06-14 15:33 katsklaw Note Added: 0018386
2015-06-14 16:26 syzop Note Added: 0018387
2015-06-14 16:27 syzop Note Edited: 0018387
2015-06-14 16:29 syzop Note Edited: 0018387
2015-06-14 16:29 syzop Note Edited: 0018387
2015-06-14 16:30 syzop Note Edited: 0018387
2015-06-14 16:32 syzop Note Edited: 0018387
2015-06-15 11:53 syzop Note Added: 0018388
2015-06-15 11:53 syzop Note Edited: 0018388
2015-06-15 11:53 syzop Note Edited: 0018388
2015-06-15 11:54 syzop Note Edited: 0018388
2015-06-15 11:56 syzop Note Added: 0018389
2015-06-15 11:56 syzop Assigned To => syzop
2015-06-15 11:56 syzop Status acknowledged => feedback
2015-06-15 12:01 syzop Note Added: 0018390
2015-06-15 12:03 syzop Note Edited: 0018390
2015-06-15 12:04 syzop Summary better directory structure & 'make install' by default => better directory structure & 'make install' by default (also for system packages)
2015-06-15 12:04 syzop Summary better directory structure & 'make install' by default (also for system packages) => better directory structure & 'make install' by default (also good for system packages)
2015-06-17 05:41 waveclaw Note Added: 0018404
2015-06-17 14:43 katsklaw Note Added: 0018405
2015-06-19 14:03 syzop Note Added: 0018407
2015-06-19 14:04 syzop Status feedback => assigned
2015-06-19 14:06 syzop Note Edited: 0018407
2015-06-20 15:21 syzop Note Added: 0018409
2015-06-20 15:21 syzop Status assigned => resolved
2015-06-20 15:21 syzop Fixed in Version => 3.4-alpha4
2015-06-20 15:21 syzop Resolution open => fixed