Hi everyone,
After a lot of wait and hurry up, W3C flipped the switch last week and put our ngIRCd server into production. It's been running smoothly ever since and many of our users are quite happy with it.
In the run-up to production, we had to adjust a few constants in src/ngircd/defines.h to better suit our needs:
* CLIENT_ID_LEN: While I respect the RFC, we had to increase this in order to authenticate users with longer usernames in our existing account system.
* MAX_RPL_LIST: We generally have around 200 channels, so the default limit of 100 seemed a little sharp to us.
* MAX_RPL_WHO: Users who joined channels with more than 25 people in them were getting notices in their clients about reaching this limit, and they were happy to voice their complaints about it to me. :) Apparently we're not the only ones who have dealt with this: see also http://colloquy.info/project/ticket/3251.
Would you be willing to consider patches that made all of these values configurable in ngircd.conf's [Limits] section? A patch could also enforce the value of CLIENT_ID_LEN with --strict-rfc. I'd be happy to write something up if we can get it upstream.
Thanks again,
Hi Brett!
On Wed, Oct 24, 2012 at 09:18:07AM -0400, Brett Smith wrote:
After a lot of wait and hurry up, W3C flipped the switch last week and put our ngIRCd server into production. It's been running smoothly ever since and many of our users are quite happy with it.
Cool, that's great news :-)
In the run-up to production, we had to adjust a few constants in src/ngircd/defines.h to better suit our needs:
- CLIENT_ID_LEN: While I respect the RFC, we had to increase this in
order to authenticate users with longer usernames in our existing account system.
This is 64 in ngIRCd. Which value are you using now? Or are you adjusting CLIENT_USER_LEN, which is 10? And how long are your user names!?
- MAX_RPL_LIST: We generally have around 200 channels, so the default
limit of 100 seemed a little sharp to us.
To prevent overloading the server, restricting the possoble LIST command reply seemed to be a good idea; so your user would have to use something like "/LIST nam*" to search for channels. But you are right, this could be to limiting ...
- MAX_RPL_WHO: Users who joined channels with more than 25 people in
them were getting notices in their clients about reaching this limit, and they were happy to voice their complaints about it to me. :) Apparently we're not the only ones who have dealt with this: see also http://colloquy.info/project/ticket/3251.
I think it would be best to not enforce this limit at all for channels the user requesting the list is a member of. Or?
Would you be willing to consider patches that made all of these values configurable in ngircd.conf's [Limits] section? A patch could also enforce the value of CLIENT_ID_LEN with --strict-rfc. I'd be happy to write something up if we can get it upstream.
As noted above, we probably don't even need a configuration option for the WHO listing; but a configurable limit for LIST output would be very handy, indeed.
I'm not so sure about CLIENT_ID_LEN, because I fear clients that can't cope with longer client IDs ... But speaking about "client user names", are you really changing the CLIENT_ID_LEN, not CLIENT_USER_LEN?
Regards Alex
On 10/24/2012 11:35 AM, Alexander Barton wrote:
- CLIENT_ID_LEN: While I respect the RFC, we had to increase this in
order to authenticate users with longer usernames in our existing account system.
This is 64 in ngIRCd. Which value are you using now? Or are you adjusting CLIENT_USER_LEN, which is 10? And how long are your user names!?
Sorry, yes, that was my mix-up; everywhere I said CLIENT_ID_LEN, read CLIENT_USER_LEN instead. We had one user whose username was exactly ten characters, so it got truncated by the terminating null, which caused PAM authentication to fail.
- MAX_RPL_LIST: We generally have around 200 channels, so the default
limit of 100 seemed a little sharp to us.
To prevent overloading the server, restricting the possoble LIST command reply seemed to be a good idea; so your user would have to use something like "/LIST nam*" to search for channels. But you are right, this could be to limiting ...
Yes, I agree having a limit is prudent and wouldn't want to remove it outright, or see it raised a lot by default. We're in kind of a special situation: our server is technically public, but meant to be used for W3C activities. So we occasionally skim the channel list to see if there are people playing on it. It's short enough that this is doable—and if it's not, that's a sign of something weird in itself. :) That's why I suggested making it configurable; I expect different administrators will want to strike different balances between network load and user convenience.
- MAX_RPL_WHO: Users who joined channels with more than 25 people in
them were getting notices in their clients about reaching this limit, and they were happy to voice their complaints about it to me. :) Apparently we're not the only ones who have dealt with this: see also http://colloquy.info/project/ticket/3251.
I think it would be best to not enforce this limit at all for channels the user requesting the list is a member of. Or?
I'd be happy with that approach too.
Best regards,
Hi Brett!
Am 24.10.2012 um 17:47 schrieb Brett Smith brett@w3.org:
On 10/24/2012 11:35 AM, Alexander Barton wrote:
- CLIENT_ID_LEN: While I respect the RFC, we had to increase this in
order to authenticate users with longer usernames in our existing account system.
This is 64 in ngIRCd. Which value are you using now? Or are you adjusting CLIENT_USER_LEN, which is 10? And how long are your user names!?
Sorry, yes, that was my mix-up; everywhere I said CLIENT_ID_LEN, read CLIENT_USER_LEN instead. We had one user whose username was exactly ten characters, so it got truncated by the terminating null, which caused PAM authentication to fail.
Okay, I see. And I don't see why we can't augment this limit to some other sane default (when not in "strict" mode, probably). Suggestions for a higher limit? 20?
I think making this dynamic is overkill …
- MAX_RPL_LIST: We generally have around 200 channels, so the default
limit of 100 seemed a little sharp to us.
To prevent overloading the server, restricting the possoble LIST command reply seemed to be a good idea; so your user would have to use something like "/LIST nam*" to search for channels. But you are right, this could be to limiting ...
Yes, I agree having a limit is prudent and wouldn't want to remove it outright, or see it raised a lot by default. We're in kind of a special situation: our server is technically public, but meant to be used for W3C activities. So we occasionally skim the channel list to see if there are people playing on it. It's short enough that this is doable—and if it's not, that's a sign of something weird in itself. :) That's why I suggested making it configurable; I expect different administrators will want to strike different balances between network load and user convenience.
I happily will take a patch introducing a new "MaxListSize" (or something like this) configuration option ;-)
- MAX_RPL_WHO: Users who joined channels with more than 25 people in
them were getting notices in their clients about reaching this limit, and they were happy to voice their complaints about it to me. :) Apparently we're not the only ones who have dealt with this: see also http://colloquy.info/project/ticket/3251.
I think it would be best to not enforce this limit at all for channels the user requesting the list is a member of. Or?
I'd be happy with that approach too.
And powering on my brain, I think it is already fixed in our master branch, see commit 2205227c (http://arthur.barton.de/cgi-bin/gitweb.cgi?p=ngircd.git;a=commitdiff;h=22052...) and bug #125 (https://arthur.barton.de/bugzilla/show_bug.cgi?id=125).
Regards Alex
On 10/24/2012 03:39 PM, Alexander Barton wrote:
Am 24.10.2012 um 17:47 schrieb Brett Smith brett@w3.org:
On 10/24/2012 11:35 AM, Alexander Barton wrote: Sorry, yes, that was my mix-up; everywhere I said CLIENT_ID_LEN, read CLIENT_USER_LEN instead. We had one user whose username was exactly ten characters, so it got truncated by the terminating null, which caused PAM authentication to fail.
Okay, I see. And I don't see why we can't augment this limit to some other sane default (when not in "strict" mode, probably). Suggestions for a higher limit? 20?
I think making this dynamic is overkill …
20 would work for me. We have only one account with a longer name, and that's a company account that's not going to be logging into IRC directly.
We have more than 100 accounts with 15-character usernames, so we would need at least 16.
- MAX_RPL_LIST: We generally have around 200 channels, so the default
limit of 100 seemed a little sharp to us.
[snip]
I happily will take a patch introducing a new "MaxListSize" (or something like this) configuration option ;-)
Great, I'll get to work on it.
And powering on my brain, I think it is already fixed in our master branch, see commit 2205227c (http://arthur.barton.de/cgi-bin/gitweb.cgi?p=ngircd.git;a=commitdiff;h=22052...) and bug #125 (https://arthur.barton.de/bugzilla/show_bug.cgi?id=125).
That's even better. That was the patch I was most nervous about writing, so I'm glad I don't have to now. Thanks for letting me know.
Best regards,
On 10/24/2012 04:23 PM, Brett Smith wrote:
On 10/24/2012 03:39 PM, Alexander Barton wrote:
Am 24.10.2012 um 17:47 schrieb Brett Smith brett@w3.org:
On 10/24/2012 11:35 AM, Alexander Barton wrote:
- MAX_RPL_LIST: We generally have around 200 channels, so the default
limit of 100 seemed a little sharp to us.
[snip]
I happily will take a patch introducing a new "MaxListSize" (or something like this) configuration option ;-)
Great, I'll get to work on it.
Done: https://gitorious.org/~bretts/ngircd-irc-daemon/bretts-ngircd/commits/config...
Am 25.10.2012 um 20:49 schrieb Brett Smith brett@w3.org:
On 10/24/2012 04:23 PM, Brett Smith wrote:
On 10/24/2012 03:39 PM, Alexander Barton wrote:
Am 24.10.2012 um 17:47 schrieb Brett Smith brett@w3.org:
On 10/24/2012 11:35 AM, Alexander Barton wrote:
- MAX_RPL_LIST: We generally have around 200 channels, so the default
limit of 100 seemed a little sharp to us.
[snip]
I happily will take a patch introducing a new "MaxListSize" (or something like this) configuration option ;-)
Great, I'll get to work on it.
Done: https://gitorious.org/~bretts/ngircd-irc-daemon/bretts-ngircd/commits/config...
Thank you, I committed the patch to our master branch. GIT commit ID is 32f63ab.
And I added the new option to the ngircd.conf.5 manual page :-)
Regards Alex
-
Alexander Barton -
Brett Smith