Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: nnrp conf (Noel Butler)
2. Re: nnrp conf (Russ Allbery)
3. Re: nnrp conf (Edwardo Garcia)
4. Re: nnrp conf (Russ Allbery)
5. Re: nnrp conf (Jeffrey M. Vinocur)
----------------------------------------------------------------------
Message: 1
Date: Thu, 04 Dec 2014 22:00:30 +1000
From: Noel Butler <[email protected]>
To: [email protected]
Subject: Re: nnrp conf
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
On 04/12/2014 14:35, Russ Allbery wrote:
> Edwardo Garcia <[email protected]> writes:
>
>> Great thank you for that!
>
>> I have one more question, limit user conncurant? Is innflag -H 6 -X 3600 the
>> only way? Because I concern at 128 limit I read?
>
> I'm not sure what the last part of that sentence meant, but yes, those
> flags are the only method out of the box for controlling the number of
> concurrent connections. Unfortunately, those are not by user; rather,
> they're by IP address. That may be good enough in your situation. I'm
> not sure.
I'm sure OP will correct me if I'm wrong, but using the -Hx -X xx has a
table limit of 128 entries does it not, I guess that's what he means.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/inn-workers/attachments/20141204/c728793e/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 04 Dec 2014 08:23:30 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: nnrp conf
Message-ID: <[email protected]>
Content-Type: text/plain
Noel Butler <[email protected]> writes:
> On 04/12/2014 14:35, Russ Allbery wrote:
>> Edwardo Garcia <[email protected]> writes:
>>> Great thank you for that!
>>> I have one more question, limit user conncurant? Is innflag -H 6 -X
>>> 3600 the only way? Because I concern at 128 limit I read?
>> I'm not sure what the last part of that sentence meant, but yes, those
>> flags are the only method out of the box for controlling the number of
>> concurrent connections. Unfortunately, those are not by user; rather,
>> they're by IP address. That may be good enough in your situation. I'm
>> not sure.
> I'm sure OP will correct me if I'm wrong, but using the -Hx -X xx has a
> table limit of 128 entries does it not, I guess that's what he means.
Ah, yes, good call.
I'm pretty sure that's just a table of incoming connections: in other
words, connections innd has accepted but hasn't decided what to do with
yet. Any given connection should only live in that table for a very short
period of time, so while 128 sounds small, it's more akin to a listen
queue than anything else. It's not the total number of open connections
the server can rate limit.
However, I've not used this code, so I may be misunderstanding it. The
logic is in innd/rc.c, particularly RCreader().
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 3
Date: Fri, 5 Dec 2014 10:37:01 +1000
From: Edwardo Garcia <[email protected]>
To: Russ Allbery <[email protected]>
Cc: [email protected]
Subject: Re: nnrp conf
Message-ID:
<canso6ehdkulkjsr139fjmakoxc5bt_vv+m7-k-0xp1mck2b...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On 12/5/14, Russ Allbery <[email protected]> wrote:
> Noel Butler <[email protected]> writes:
>> On 04/12/2014 14:35, Russ Allbery wrote:
>>> Edwardo Garcia <[email protected]> writes:
>
>>>> Great thank you for that!
>
>>>> I have one more question, limit user conncurant? Is innflag -H 6 -X
>>>> 3600 the only way? Because I concern at 128 limit I read?
>
>>> I'm not sure what the last part of that sentence meant, but yes, those
>>> flags are the only method out of the box for controlling the number of
>>> concurrent connections. Unfortunately, those are not by user; rather,
>>> they're by IP address. That may be good enough in your situation. I'm
>>> not sure.
>
>> I'm sure OP will correct me if I'm wrong, but using the -Hx -X xx has a
>> table limit of 128 entries does it not, I guess that's what he means.
>
> Ah, yes, good call.
>
> I'm pretty sure that's just a table of incoming connections: in other
> words, connections innd has accepted but hasn't decided what to do with
> yet. Any given connection should only live in that table for a very short
> period of time, so while 128 sounds small, it's more akin to a listen
> queue than anything else. It's not the total number of open connections
> the server can rate limit.
>
> However, I've not used this code, so I may be misunderstanding it. The
> logic is in innd/rc.c, particularly RCreader().
>
Halo,
So, this may no stop single user from multiple login afterall?
Second, how inn handsle new groups add by upstream? Is simple
process or cron to run daily to update active file and add new groups?
Wondering how I need handle this, since we not seem to have all group
since setup, upstream seem add 19 new group we dont seem have, should
upstream be send us control so it happen on fly or manual intervention
require?
Thank you for all help too, Inn now running ok then, and prove to my
boss it not open to thrid party now, he happy too.
------------------------------
Message: 4
Date: Thu, 04 Dec 2014 17:52:35 -0800
From: Russ Allbery <[email protected]>
To: Edwardo Garcia <[email protected]>
Cc: [email protected]
Subject: Re: nnrp conf
Message-ID: <[email protected]>
Content-Type: text/plain
Edwardo Garcia <[email protected]> writes:
> So, this may no stop single user from multiple login afterall?
Sorry, that was probably confusing. I was worried that the innd support
wouldn't scale if you had a lot of users, but after looking at the code,
I'm pretty sure it will be fine. So as long as you're happy restricting
by IP address, not authenticated user, those flags should do what you
want.
> Second, how inn handsle new groups add by upstream? Is simple process or
> cron to run daily to update active file and add new groups? Wondering
> how I need handle this, since we not seem to have all group since setup,
> upstream seem add 19 new group we dont seem have, should upstream be
> send us control so it happen on fly or manual intervention require?
Control message handling is a whole giant topic with a lot of differing
opinions. It's sadly pretty complicated, since different people want
different things.
I'm not sure we have a good guide to all the different options. The two
main approaches are to set up your server to process and verify control
messages (those don't come from your upstream -- they come from anyone on
Usenet who wants to send them, but there's a way to authenticate them), or
to synchronize your newsgroups from someone else.
If you want to do the first, see the "Processing Newsgroup Control
Messages" section in INSTALL (it's at the end of the file). If you want
to do the second, read the man page for actsync, which will automatically
make your list of newsgroups match a list retrieved via FTP or from
another news server against which you can run LIST ACTIVE. (I'm sorry
it's so complicated, but the EXAMPLES section will hopefully help.)
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
------------------------------
Message: 5
Date: Fri, 5 Dec 2014 05:00:48 -0500 (EST)
From: "Jeffrey M. Vinocur" <[email protected]>
To: [email protected]
Subject: Re: nnrp conf
Message-ID: <[email protected]>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Tue, 2 Dec 2014, Russ Allbery wrote:
> Edwardo Garcia <[email protected]> writes:
>
>> Can we please have the access methods of nnrp,conf brought back!!?!
>
> [...]
> If someone feels up to tackling this, the easiest approach at this point
> would probably be to write a program that took the old syntax as input and
> converted it to an equivalent readers.conf file. It's not as good as
> being able to use the old syntax directly, but it might provide most of
> the benefits and would be considerably less work.
Funny you mention it.
I have the below "nnrp.access2readers.conf.pl" on my server, timestamped
from 2003. I have no recollection of how well it works, presumably I
shared it on inn-workers or news.software.nntp at the time although I find
only a passing allusion to it in google. Anyway, it would probably meet
Edwardo's needs.
Edwardo, it appears I intended for this to be included with INN and never
finished that process, so I apologize if it would have been helpful for
you.
(Russ or Julien, I am a little fuzzy on the svn process these days but if
either of you thinks this is worth throwing in contrib/ feel free.)
#!/usr/bin/perl -w
# (XXX - this should be a .pl.in file)
# Written by Jeffrey M. Vinocur <[email protected]>
# This work is hereby placed in the public domain by its author.
use strict;
my ($src, $passwd, $dst, $debug);
if(@ARGV == 1) {
$src = shift;
$passwd = 'passwd';
$debug = 1;
} elsif(@ARGV == 3) {
($src, $passwd, $dst) = @ARGV;
$debug = 0;
} else {
usage();
}
my ($address, $access, $user, $pass, $groups);
my %passwords;
my @badsyntax;
my @duplicates;
my $OUT;
open(SRC, $src) or die "Could not open $src: $!\n";
if($debug) {
$OUT = \*STDOUT;
} else {
open(DST, ">$dst") or die "Could not open $dst: $!\n";
$OUT = \*DST;
}
while(<SRC>) {
chomp;
next if /^\#/;
s/\#.*//;
($address, $access, $user, $pass, $groups) = split /:/;
unless (defined $groups) {
push @badsyntax, $.;
next;
}
# XXX - what exactly were the semantics of using
# whitespace in user/pass to disable access?
unless($user eq '') {
push @duplicates, $. if defined $passwords{$user};
$passwords{$user} = $pass;
}
print $OUT "auth \"$address\" {\n";
print $OUT " hosts: \"$address\"\n";
print $OUT " key: \"line$.\"\n";
print $OUT " auth: \"ckpasswd -f $passwd\"\n" unless $user eq '';
print $OUT "}\n";
print $OUT "access \"$address\" {\n";
print $OUT " key: \"line$.\"\n";
print $OUT " newsgroups: \"$groups\"\n";
print $OUT " access: \"$access\"\n";
print $OUT " users: \"$user\"\n" unless $user eq '';
print $OUT "}\n\n";
}
close SRC;
srand($$^time);
# XXX - if $passwd exists, should we overwrite, append, or merge?
if(!$debug) {
close $OUT;
open(PASSWD, ">$passwd") or die "Could not open $passwd: $!\n";
$OUT = \*PASSWD;
}
while (my ($user, $pass) = each %passwords) {
$pass = crypt($pass, seedchar().seedchar());
print $OUT "$user:$pass\n";
}
close PASSWD unless $debug;
print STDERR "Had trouble with syntax on line",
@badsyntax > 1 ? 's ' : ' ',
join(", ", @badsyntax), ".\n"
if @badsyntax;
print STDERR "Found username duplication on line",
@duplicates > 1 ? 's ' : ' ',
join(", ", @duplicates), ".\n"
if @duplicates;
sub seedchar { # from Randal Schwarz
('a'..'z','A'..'Z','0'..'9','.','/')[rand(64)];
}
sub usage {
print STDERR << "__END__";
Usage:
$0 <nnrp.access file> [<passwd file> <readers.conf file>]
Use $0 to convert an old-style nnrp.access file to readers.conf
format. All unique user/password pairs from the nnrp.access file are
placed in the passwd file (in format suitable for ckpasswd).
If the second and third arguments are missing, everything is
printed instead to stdout for examination purposes.
__END__
exit 1;
}
--
Jeffrey M. Vinocur
[email protected]
------------------------------
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
End of inn-workers Digest, Vol 67, Issue 5
******************************************
