UnrealIRCd Forums

Hi,

I know there is a module just for that purpose (m_soper), but is there a way to get that working with the built-in arsenal of UnrealIRCd (in order to minimize the risk of crashes, etc)?

I tried something like
but that one doesn't seem to work: It indeed lets me oper when I'm on an SSL connection, but does the same when I'm not so it's basically useless.

And generally, how do those three settings work together? Does the ircd allow the oper block iff the user already in that class before opering, or does it put the user into that class after (or if) the oper is successful? If the latter is true, then the above configuration is logically wrong.

Thanks for any suggestions,

Mike


P.S. OffTopic: What are all those m_* modules in the modules/ directory good for (except cloak and commands, of course)? They are never loadmodule'd anywhere, they're not documented anywere (or have I overseen sth?) and they are not on the Modules section of the website, so they don't seem to be just 3rd party modules that happen to be included in the Unreal distribution. But there's still quite a bunch of them to be just there for nothing...

oper::class is the name of the class the oper will become once opering up. If you want to require opers to use SSL to oper, there is a module that provides that function. I think the module is on the Unreal website.

EDIT: The module is m_soper, and the link is: http://www.unrealircd.com/index.php?pag ... dule&id=47

First of all, thanks for that lightning fast answer in the early morning

Stealth wrote: oper::class is the name of the class the oper will become once opering up.

That's what I was afraid of...

Stealth wrote: If you want to require opers to use SSL to oper, there is a module that provides that function. I think the module is on the Unreal website.

EDIT: The module is m_soper, and the link is: http://www.unrealircd.com/index.php?pag ... dule&id=47

I know that (see the *first* sentence of my post) but I wanted to make sure there is no way to do that with the built-in options of Unreal before messing aroung with recompile etc (the modules have to be compiled together with the whole whole ircd again and then copied to modules/ in the installation dir of unreal, I suppose?)


Mike

Modules are simple to install, and a recompile is not needed. Here are some simple instructions (for *nix):

Put the .c file in src/modules

From the main Unreal directory, type "make custommodule MODULEFILE=m_soper"

Add "loadmodule src/modules/m_soper.so" to your conf, rehash and enjoy!

Stealth wrote:Modules are simple to install, and a recompile is not needed.

Well, since I have installed to a different directory (with 'make install') I can safely recomile everything and then only copy the <module>.so to <install dir>/modules. Or does it have to be with 'make custommodule' ? Does 'make custommodule' require the *.o object files from the other sources, or just the headers (e.g. will it work after a 'make clean') ?

And by the way, sorry but what's that sh*t with the default installation being in the sources directory? I find that a total mess, especially paths like 'src/...' in the conf file...

Anyways, thanks for the tips.


Mike

You can still compile the module by itself, just do everything in the source directory, and copy the m_soper.so file to the install driectory. It will work just the same

As for the other modules, they are automagically auto-loaded by commands.so or whatever it's called (been a while since i've been IRC digging :p). Basically, it saves you having to manually create loadmodule directives for all the commands in the ircd .

You CAN do it manually if you want however.

When we are talking about "different installation target"-installs, I also would like to suggest to always KEEP the source you compiled from around as well.
Why? Because sometimes - like in January (8 months ago :p) - we release "hotfixes" which make it possible to fix a bug, recompile 1 or 2 module files, and then rehash (so no restart needed).
What the script was: patch the bug in the source, make, make install, ./unreal rehash, all automated...
On professional installations I usually just mkdir src, compile Unreal from ~/src/Unreal3.2 to ~/Unreal (or something), and don't rm -rf it afterwards. Same for anope and bopm (though, naturally, on every next version I remove the old one -- IF the upgrade went succesfull, that is ;p).

Actually, as you already pointed out, it does not only make sense for hotfixes, but also if you want to compile any 3rd party module (same story applies to anope).
Just wanted to point out that, even if you don't have 3rd party modules, it still makes sense to keep it.

w00t wrote:As for the other modules, they are automagically auto-loaded by commands.so or whatever it's called [...]

I c

Syzop wrote:When we are talking about "different installation target"-installs, I also would like to suggest to always KEEP the source you compiled from around as well.

I always do (not only for unreal) Is that why the default install is in the source directory? To keep people from deleting their sources (or at least make it more work)?


Mike

Actually I don't know why it's the default :p.

It could well be because of that.
Also, if people remove their source directory and unreal crashes, you don't get a nice backtrace unless you grab/extract the source again. And it also makes things more easier (just more messy).

Also.. in the past we did not do 'version checks' on modules. So modules compiled with 3.2-beta8 could be loaded on 3.2-beta16.. This caused horrible problems (unexplained crashes, slow memory corruption, etc). This problem mainly affected people with an "installation directory", because they simply forgot to copy 1 or more .so's over, and "things seemed to work" ;).