Got a couple oddball feature requests I'd like to bounce off you...
1 - External Auth Mechanism Currently, ngircd supports a single global server password option. I'd like to be able to do specific user/pass pairs on connect. Either setting them up in the conf, an external flat file, or the option to call an external script, pass it the user/pass pair, and allow the connect if it returns without error (allowing radius/ldap/etc based auth without having to support it directly in ngricd) would be slick.
2 - Toggle to restrict use of /nick and channel creation to those with +o. By itself this doesn't do much, but in combination with the above, this allows much more control of the ircd's use, making it appropriate to use in an internal LAN/buisiness environment.
One last question, have the services provisions been fleshed out enough to warrant trying third party service apps, or are they still too rough?
Joshua Coombs
Hi Josh!
1 - External Auth Mechanism Currently, ngircd supports a single global server password option. I'd like to be able to do specific user/pass pairs on connect. Either setting them up in the conf, an external flat file, or the option to call an external script, pass it the user/pass pair, and allow the connect if it returns without error (allowing radius/ldap/etc based auth without having to support it directly in ngricd) would be slick.
Right, I thought about it already and think that PAM integration would be handy: then you can plug-in every authentication mechanism you like.
2 - Toggle to restrict use of /nick and channel creation to those with +o. By itself this doesn't do much, but in combination with the above, this allows much more control of the ircd's use, making it appropriate to use in an internal LAN/buisiness environment.
"One" could implement a mechanism to restrict certain IRC commands to IRC operators ... this would be the most generic solution.
One last question, have the services provisions been fleshed out enough to warrant trying third party service apps, or are they still too rough?
Actuall ngIRCd lacks a services interface. Therefore services that act like servers probably could work, but none that require an extended/special interface.
Regards Alex
Alexander Barton schrieb:
2 - Toggle to restrict use of /nick and channel creation to those with +o. By itself this doesn't do much, but in combination with the above, this allows much more control of the ircd's use, making it appropriate to use in an internal LAN/buisiness environment.
"One" could implement a mechanism to restrict certain IRC commands to IRC operators ... this would be the most generic solution.
Arrrgl. I answered too fast ... You can't restrict channel creation this way ...
Regards Alex