View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004361 | unreal | installing | public | 2015-06-14 12:50 | 2015-06-20 15:22 |
| Reporter | syzop | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.4-alpha3 | ||||
| Target Version | 3.4-alpha4 | Fixed in Version | 3.4-alpha4 | ||
| Summary | 0004361: 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. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
+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. |
|
|
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.. |
|
|
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. |
|
|
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. |
|
|
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). |
|
|
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: https://en.opensuse.org/openSUSE:Packaging_guidelines 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 (https://build.opensuse.org). 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 ircd.pid 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. |
|
|
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. |
|
|
https://github.com/unrealircd/unrealircd/commit/5e94fc9c72495435fed3fbd2df7e00376f7afe5d New items: --with-bindir=path Specify the directory for the unrealircd binary --with-scriptdir=path Specify the directory for the unrealircd start-stop script --with-confdir=path Specify the directory where configuration files are stored --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: badwords.channel.conf -> doc/conf/badwords.channel.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: unreal.in -> unrealircd.in again, more to follow later. |
|
|
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...) |
| 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 |
