noffle-devel Mailing List for Noffle - news server (Page 2)
Brought to you by:
bears
Menu
▾
▴
noffle-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(32) |
Jun
(17) |
Jul
(53) |
Aug
(14) |
Sep
(8) |
Oct
(16) |
Nov
(7) |
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(5) |
Feb
(4) |
Mar
(2) |
Apr
|
May
(22) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
|
Oct
(6) |
Nov
(23) |
Dec
(1) |
| 2002 |
Jan
(4) |
Feb
(1) |
Mar
(20) |
Apr
(7) |
May
(8) |
Jun
(9) |
Jul
(7) |
Aug
(4) |
Sep
|
Oct
(11) |
Nov
(2) |
Dec
(6) |
| 2003 |
Jan
(5) |
Feb
(11) |
Mar
(11) |
Apr
|
May
|
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(4) |
Oct
(1) |
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
(4) |
| 2006 |
Jan
(3) |
Feb
(2) |
Mar
(4) |
Apr
(2) |
May
(9) |
Jun
(26) |
Jul
(11) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Simon B. <ad...@th...> - 2003-03-19 20:44:15
|
Hi
Ive been trying to set up noffle to use stunnel to accept connections on
port 563.
Noffle works fine running without stunnel on port 119.
In my xinetd.conf file i have
service nntp
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = news
group = news
server = /usr/sbin/stunnel
server_args = -d nntps -l /usr/local/bin/noffle -- noffle
-r
}
i also have this in my stunnel.conf
[nntps]
accept = 563
connect = 119
protocol = nntp
When i try to connect to the server i get a message from outlook express
saying that the connection was unexpectedly terminated.
When i look in my syslog for news this is all that appears:
Mar 19 20:21:31 lightning stunnel[5358]:
/usr/local/etc/stunnel/stunnel.conf
connected from 192.168.7.2:2899
Mar 19 20:21:31 lightning stunnel[5358]: Connection closed: 570 bytes
sent to SSL, 0 bytes sent to socket
Has anyone got any idea what im doing wrong? Ive just started using
linux really so im not 100% sure where else to look on this.
thanks
Simon
-= <http://www.thelight.org.uk/> www.thelight.org.uk |
<http://www.into-infinity.co.uk/> www.into-infinity.co.uk |
<http://www.nipple.tk/> www.nipple.tk | <http://www.beforenet.org/>
www.beforenet.org =-
|
|
From: SourceForge.net <no...@so...> - 2003-03-16 21:10:26
|
Feature Requests item #704603, was opened at 2003-03-16 19:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=351044&aid=704603&group_id=1044 Category: None Group: None Status: Open Priority: 5 Submitted By: Simon Bell (simonbell) >Assigned to: Jim Hague (bears) Summary: client authorisation Initial Comment: It would be good to include some kind of client authentication. Either by PAM or just via a user file so that the server can be shared around a few friends but not accessed by anyone else. It'd be nice to see out of the box ssl support instead of having to use stunnel. thanks ---------------------------------------------------------------------- >Comment By: Jim Hague (bears) Date: 2003-03-16 21:22 Message: Logged In: YES user_id=184 Client authorisation via PAM or a user file has been in CVS since early January, and is in 1.1.4. Out of the box SSL support isn't implemented. I won't be doing it myself - I don't see a huge advantage in not using stunnel - but I would look kindly upon any patches adding SSL support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=351044&aid=704603&group_id=1044 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 19:17:31
|
Feature Requests item #704603, was opened at 2003-03-16 19:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=351044&aid=704603&group_id=1044 Category: None Group: None Status: Open Priority: 5 Submitted By: Simon Bell (simonbell) Assigned to: Nobody/Anonymous (nobody) Summary: client authorisation Initial Comment: It would be good to include some kind of client authentication. Either by PAM or just via a user file so that the server can be shared around a few friends but not accessed by anyone else. It'd be nice to see out of the box ssl support instead of having to use stunnel. thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=351044&aid=704603&group_id=1044 |
|
From: SourceForge.net <no...@so...> - 2003-02-18 15:13:15
|
Feature Requests item #537550, was opened at 2002-04-01 01:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=351044&aid=537550&group_id=1044 Category: None Group: None >Status: Closed Priority: 5 Submitted By: David Findlay (nedz) Assigned to: Nobody/Anonymous (nobody) Summary: Newsfeeds Initial Comment: I'd like to be able to set up noffle to collaborate with another noffle server. We are currently working on a community wireless WAN, and bandwidth charges here are expensive. So what I'd like to be able to do is have one server handle one bunch of groups(say the big 8), and another one handle the rest(alt). The two server would feed each other all the headers and bodies they have. If a user on the big 8 server tried to access an alt.* group, the request would be forwarded to the alt server which would download the required data, store it, then forward that back to the big 8 server. Similiar system for posting. Could this sort of system be added? Thanks, David ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-04-05 13:41 Message: Logged In: NO If you don't need true peering via IHAVE, etc., then noffle can do all this. Just subscribe in overview mode. Ehm, pseudo messages can mess up the article numbering, so switch to noffle --online mode and use the auto-subscribe facility. Please be careful using filters and be extra careful that you know how postings are treated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=351044&aid=537550&group_id=1044 |
|
From: SourceForge.net <no...@so...> - 2003-02-18 15:12:24
|
Feature Requests item #687945, was opened at 2003-02-17 12:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=351044&aid=687945&group_id=1044 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Jim Hague (bears) Summary: delay cancel processing Initial Comment: Please delay the processing of cancels or supersedes. It takes a lot of time to delete the old article from the database. Just delete the old overview (and leave deletion of the actual article for noffle --expire) or delete the old article after fetching all the new articles. ---------------------------------------------------------------------- >Comment By: Jim Hague (bears) Date: 2003-02-18 15:20 Message: Logged In: YES user_id=184 I think it's deleting the overview that likely to be taking the time. But unless the old article is widely crossposted, or in a group with a very large overview, the time taken to delete it shouldn't be that great. Are you saying that processing them in-line adds significantly to your connect time during a fetch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=351044&aid=687945&group_id=1044 |
|
From: SourceForge.net <no...@so...> - 2003-02-17 12:16:47
|
Feature Requests item #687945, was opened at 2003-02-17 04:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=351044&aid=687945&group_id=1044 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: delay cancel processing Initial Comment: Please delay the processing of cancels or supersedes. It takes a lot of time to delete the old article from the database. Just delete the old overview (and leave deletion of the actual article for noffle --expire) or delete the old article after fetching all the new articles. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=351044&aid=687945&group_id=1044 |
|
From: SourceForge.net <no...@so...> - 2003-02-12 10:29:48
|
Bugs item #684118, was opened at 2003-02-10 19:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101044&aid=684118&group_id=1044 Category: None Group: None >Status: Closed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jim Hague (bears) Summary: V1.1.3 does not authenticate correctly Initial Comment: Hello there, As a Debian Sid user, i upgraded my system this weekend, upgrading noffle to 1.1.3 by the way. I use a news server with authentication, and whenever i run "noffle -f" to fetch articles, noffle says: Connected to 81.202.216.250:119 Username rejected. Server stat: 381 PASS required Posting articles Username rejected. Server stat: 381 PASS required I've double-checked the user&password in the config file, and tested them via telnetting the server. And it works perfectly (i used "authinfo user my_username" and then "authinfo pass my_password", and worked). I hope you can fix this. Keep the good work, Iván Sánchez Ortega <iva...@wa...> ---------------------------------------------------------------------- Comment By: Jim Hague (bears) Date: 2003-02-11 11:13 Message: Logged In: YES user_id=184 Thanks for the bug report. This is a known problem with 1.1.3, which is now fixed in CVS, though I'm waiting for confirmation. I will release 1.1.4 as soon as I can check the fix. I'll be makin a new release shortly. In the meantime, if you want to apply the fix yourself, change STAT_AUTH_REQUIRED on line 169 of client.c to STAT_MORE_AUTH_REQUIRED. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101044&aid=684118&group_id=1044 |
|
From: Jim H. <jim...@ac...> - 2003-02-12 10:27:02
|
Sorry about the authentication stuffup in 1.1.3. I'd renamed some of the constants in protocol.h to better reflect RFC2980, and by doing so unwittingly uncovered a long-standing surprise in the client.c authentication code. -- Jim Hague - jim...@in... (Work), ji...@be... (Play) Never trust a computer you can't lift or you don't control. |
|
From: SourceForge.net <no...@so...> - 2003-02-11 11:06:22
|
Bugs item #684118, was opened at 2003-02-10 19:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101044&aid=684118&group_id=1044 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jim Hague (bears) Summary: V1.1.3 does not authenticate correctly Initial Comment: Hello there, As a Debian Sid user, i upgraded my system this weekend, upgrading noffle to 1.1.3 by the way. I use a news server with authentication, and whenever i run "noffle -f" to fetch articles, noffle says: Connected to 81.202.216.250:119 Username rejected. Server stat: 381 PASS required Posting articles Username rejected. Server stat: 381 PASS required I've double-checked the user&password in the config file, and tested them via telnetting the server. And it works perfectly (i used "authinfo user my_username" and then "authinfo pass my_password", and worked). I hope you can fix this. Keep the good work, Iván Sánchez Ortega <iva...@wa...> ---------------------------------------------------------------------- >Comment By: Jim Hague (bears) Date: 2003-02-11 11:13 Message: Logged In: YES user_id=184 Thanks for the bug report. This is a known problem with 1.1.3, which is now fixed in CVS, though I'm waiting for confirmation. I will release 1.1.4 as soon as I can check the fix. I'll be makin a new release shortly. In the meantime, if you want to apply the fix yourself, change STAT_AUTH_REQUIRED on line 169 of client.c to STAT_MORE_AUTH_REQUIRED. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101044&aid=684118&group_id=1044 |
|
From: SourceForge.net <no...@so...> - 2003-02-11 11:03:29
|
Bugs item #684118, was opened at 2003-02-10 19:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101044&aid=684118&group_id=1044 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Jim Hague (bears) Summary: V1.1.3 does not authenticate correctly Initial Comment: Hello there, As a Debian Sid user, i upgraded my system this weekend, upgrading noffle to 1.1.3 by the way. I use a news server with authentication, and whenever i run "noffle -f" to fetch articles, noffle says: Connected to 81.202.216.250:119 Username rejected. Server stat: 381 PASS required Posting articles Username rejected. Server stat: 381 PASS required I've double-checked the user&password in the config file, and tested them via telnetting the server. And it works perfectly (i used "authinfo user my_username" and then "authinfo pass my_password", and worked). I hope you can fix this. Keep the good work, Iván Sánchez Ortega <iva...@wa...> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101044&aid=684118&group_id=1044 |
|
From: SourceForge.net <no...@so...> - 2003-02-10 19:23:31
|
Bugs item #684118, was opened at 2003-02-10 11:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101044&aid=684118&group_id=1044 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: V1.1.3 does not authenticate correctly Initial Comment: Hello there, As a Debian Sid user, i upgraded my system this weekend, upgrading noffle to 1.1.3 by the way. I use a news server with authentication, and whenever i run "noffle -f" to fetch articles, noffle says: Connected to 81.202.216.250:119 Username rejected. Server stat: 381 PASS required Posting articles Username rejected. Server stat: 381 PASS required I've double-checked the user&password in the config file, and tested them via telnetting the server. And it works perfectly (i used "authinfo user my_username" and then "authinfo pass my_password", and worked). I hope you can fix this. Keep the good work, Iván Sánchez Ortega <iva...@wa...> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101044&aid=684118&group_id=1044 |
|
From: SourceForge.net <no...@so...> - 2003-02-10 18:32:01
|
Patches item #681598, was opened at 2003-02-06 11:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=301044&aid=681598&group_id=1044 Category: None Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jim Hague (bears) Summary: Fix auth in 1.1.3 Initial Comment: noffle 1.1.3 authentication didn't work for me without this patch. ---------------------------------------------------------------------- Comment By: Jim Hague (bears) Date: 2003-02-10 18:37 Message: Logged In: YES user_id=184 Applied, with thanks. That was a shocking cockup. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=301044&aid=681598&group_id=1044 |
|
From: SourceForge.net <no...@so...> - 2003-02-10 18:31:22
|
Patches item #681598, was opened at 2003-02-06 11:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=301044&aid=681598&group_id=1044 Category: None Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Jim Hague (bears) Summary: Fix auth in 1.1.3 Initial Comment: noffle 1.1.3 authentication didn't work for me without this patch. ---------------------------------------------------------------------- >Comment By: Jim Hague (bears) Date: 2003-02-10 18:37 Message: Logged In: YES user_id=184 Applied, with thanks. That was a shocking cockup. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=301044&aid=681598&group_id=1044 |
|
From: SourceForge.net <no...@so...> - 2003-02-06 11:29:17
|
Patches item #681598, was opened at 2003-02-06 03:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=301044&aid=681598&group_id=1044 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Fix auth in 1.1.3 Initial Comment: noffle 1.1.3 authentication didn't work for me without this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=301044&aid=681598&group_id=1044 |
|
From: Jim H. <jim...@ac...> - 2003-01-28 23:11:03
|
On 28-Jan-2003 Mirko Liss wrote: > Jim Hague wrote: >> On 27-Jan-2003 Miernik wrote: >> > That is not the timeout of noffle, but a 10 second receive timeout at >> > the upstream server, which I can't change. > >> That makes sense. I think what we need here is for Noffle to have a >> mechanism >> for automatically retrying operations that fail due to timeout or connection >> lost issues up to some configurable number of times before deciding to sound >> the alarms. I'll add to the TODO.... > > The remote host returned the status 503, a general error that says > nothing more than "Function not performed, closing connection". > An INN with a corrupt database might return just the same status code > when trying to fetch articles. AFAIK, there aren't any status codes > notifying a timeout or just any kind of temporary error. I'm thinking keeping it purely within client.c. When reading a status currently in getStat(), we return a fake status if the connection is lost. What I'm proposing would be to cache sufficient info in the client module that we could re-connect and repeat the last transaction if we get a failure of either STAT_CONNECTION_LOST (Noffle special) or STAT_PROGRAM_FAULT (503). Yes, an upstream server might well return the latter for a genuine fault, like a corrupt database, but in that case there won't be any harm (other than a delay) in retrying, reconnecting if necessary. You count the number of retries and stop after a threshold. By default I suggest never retrying. It would be fiddly and rather tedious to actually do this, but I think possible. I am unlikely to volunteer in the near future. -- Jim Hague - jim...@in... (Work), ji...@be... (Play) Never trust a computer you can't lift or you don't control. |
|
From: Mirko L. <mir...@we...> - 2003-01-28 18:55:11
|
Jim Hague wrote: > On 27-Jan-2003 Miernik wrote: > > That is not the timeout of noffle, but a 10 second receive timeout at > > the upstream server, which I can't change. > That makes sense. I think what we need here is for Noffle to have a mechanism > for automatically retrying operations that fail due to timeout or connection > lost issues up to some configurable number of times before deciding to sound > the alarms. I'll add to the TODO.... The remote host returned the status 503, a general error that says nothing more than "Function not performed, closing connection". An INN with a corrupt database might return just the same status code when trying to fetch articles. AFAIK, there aren't any status codes notifying a timeout or just any kind of temporary error. I have no idea how to determine timeout or connection lost issues. regards, Mirko |
|
From: Jim H. <jim...@ac...> - 2003-01-28 11:40:28
|
On 27-Jan-2003 Miernik wrote: > That is not the timeout of noffle, but a 10 second receive timeout at > the upstream server, which I can't change. Oh, I see. I misunderstood you. Sorry. >> You can't force it not to switch to offline mode. Noffle take the view that >> if the connection failed, something is pretty seriously wrong with your >> network connection or the server, and it should take action to ensure it >> doesn't keep pointlessly retrying. So it resets itself back to a mode >> where user action is required to initiate more network activity. > > But here the _only_ thing that was wrong, was that the upstream server > disconnected me because of it's 10 second receive timeout. There is > nothing more wrong. > > Retrying isn't pointless, because at the next, or second next try it > will manage to transmitt packets to the upstream server without a 10 > second gap. The timeout here happens only during the initial connection, > after that I can have gaps of more than 10 seconds without the upstream > server timeouting. That makes sense. I think what we need here is for Noffle to have a mechanism for automatically retrying operations that fail due to timeout or connection lost issues up to some configurable number of times before deciding to sound the alarms. I'll add to the TODO.... >> I'll put it on the TODO list, but it's not that easy to do given Noffle's >> present structure. *Cough* As Mirko noted, when I got to the TODO list, exactly that item was already there. I'm not going to start handing round TODO items to folk, but if anybody feels like having a crack at some of them, patches are always welcome. :-) A post stating intent to the noffle-devel list might be a good idea first, to prevent duplicated effort. I've got a small paper to write and a frame buffer driver to port to 2.5, so I'm going to be a bit busy on other matters for a while. -- Jim Hague - jim...@in... (Work), ji...@be... (Play) Never trust a computer you can't lift. |
|
From: Jim H. <jim...@ac...> - 2003-01-12 19:54:31
|
On 10-Jan-2003 Jim Hague wrote: > After some egging on from Martin, I've also gone all pompous about who can > run certain Noffle commands. Basically, unless you're root or news you won't > be allowed to run admin-type Noffle commands. After sleeping on it, I've relaxed this slightly. admin-type Noffle commands can now be run if you are root, news or are in group news. Thus you can add yourself to group news and carry on just as before, running any Noffle command you please. -- Jim Hague - jim...@in... (Work), ji...@be... (Play) Never trust a computer you can't lift or you don't control. |
|
From: Jim H. <jim...@ac...> - 2003-01-10 23:46:45
|
I didn't really intend to make any more major changes before 1.2, but... I've just checked in a whole bunch of stuff. Some of it is good - fixes to bugs reported by Noffle's new Debian packager, Martin Godish (thanks again, Martin). But I also got carried away and implemented simple authentication within the server. Y'see, a friend who has written a Windows news reader got a bug report against Noffle and wanted a server to test against. And I've kind-of wanted to have a Noffle facing the Big Wide World for other reasons, but I'm not in the business of running public news servers... So, AUTHINFO USER and AUTHINFO PASS are now supported. Authentication mechanism is determined at compile time, and can be either a plain text user/password file, or for when you want something cleverer, PAM. After some egging on from Martin, I've also gone all pompous about who can run certain Noffle commands. Basically, unless you're root or news you won't be allowed to run admin-type Noffle commands (subscribe/unsubscribe, delete articles/groups etc.) Noffle also tries a lot harder now to detect if it does not have the permissions it expects and gives civilised error messages. It all vaguely seems to work, but I'd be grateful for some more folk bashing on it. -- Jim Hague - jim...@in... (Work), ji...@be... (Play) Never trust a computer you can't lift or you don't control. |
|
From: <no...@so...> - 2002-12-25 10:01:27
|
Bugs item #658053, was opened at 2002-12-24 00:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101044&aid=658053&group_id=1044 Category: None Group: None >Status: Closed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jim Hague (bears) Summary: 501 server init error (noffle 1.1.2) Initial Comment: When using noffle version 1.1.2 with a server that identifies itself as "Nnrpproxy v1.16.06" when I attempt to connect (usually with noffle --query groups) I get a series of messages like this (thanks to log-debug protocol): [S] MODE READER [S FLUSH] [R] 200 Ok [S] AUTHINFO USER <username> [S FLUSH] [R] 381 Password next please [S] AUTHINFO PASS <password> [S FLUSH] [R] 281 Authentication successful, 1285120 dl of 1099511627776 max (0%) Getting groups [S] LIST ACTIVE [S FLUSH] [R] 501 bad command usage LIST ACTIVE failed: 501 bad command usage [S] QUIT [S FLUSH] [R] 205 Bye This is on a Redhat 7.3 machine, I've tried both RPM and source installs. The weird thing is that with 1.0.1 this doesn't happen, I'd be happy using this but find myself wanting to use the hostname function of 1.1.2's config. Paul Tipper <p dot tipper at lancs dot ac dot uk> ---------------------------------------------------------------------- >Comment By: Jim Hague (bears) Date: 2002-12-25 10:01 Message: Logged In: YES user_id=184 Paul reports now fixed in CVS. ---------------------------------------------------------------------- Comment By: Jim Hague (bears) Date: 2002-12-24 09:18 Message: Logged In: YES user_id=184 Sorry about that. The code that issues LIST ACTIVE to the upstream server is supposed to fall back to LIST if LIST ACTIVE isn't recognised, but was only doing this if you specified a group pattern. I've checked a fix into CVS. Would it be possible for you to get current CVS source and try it out? Otherwise I think you might be able to work around this by specifying getgroups newsgroup pattern(s) for that server, e.g. 'getgroups *'. This should make the fallback to LIST happen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101044&aid=658053&group_id=1044 |
|
From: <no...@so...> - 2002-12-24 09:18:39
|
Bugs item #658053, was opened at 2002-12-24 00:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101044&aid=658053&group_id=1044 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Jim Hague (bears) Summary: 501 server init error (noffle 1.1.2) Initial Comment: When using noffle version 1.1.2 with a server that identifies itself as "Nnrpproxy v1.16.06" when I attempt to connect (usually with noffle --query groups) I get a series of messages like this (thanks to log-debug protocol): [S] MODE READER [S FLUSH] [R] 200 Ok [S] AUTHINFO USER <username> [S FLUSH] [R] 381 Password next please [S] AUTHINFO PASS <password> [S FLUSH] [R] 281 Authentication successful, 1285120 dl of 1099511627776 max (0%) Getting groups [S] LIST ACTIVE [S FLUSH] [R] 501 bad command usage LIST ACTIVE failed: 501 bad command usage [S] QUIT [S FLUSH] [R] 205 Bye This is on a Redhat 7.3 machine, I've tried both RPM and source installs. The weird thing is that with 1.0.1 this doesn't happen, I'd be happy using this but find myself wanting to use the hostname function of 1.1.2's config. Paul Tipper <p dot tipper at lancs dot ac dot uk> ---------------------------------------------------------------------- >Comment By: Jim Hague (bears) Date: 2002-12-24 09:18 Message: Logged In: YES user_id=184 Sorry about that. The code that issues LIST ACTIVE to the upstream server is supposed to fall back to LIST if LIST ACTIVE isn't recognised, but was only doing this if you specified a group pattern. I've checked a fix into CVS. Would it be possible for you to get current CVS source and try it out? Otherwise I think you might be able to work around this by specifying getgroups newsgroup pattern(s) for that server, e.g. 'getgroups *'. This should make the fallback to LIST happen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101044&aid=658053&group_id=1044 |
|
From: <no...@so...> - 2002-12-24 00:28:54
|
Bugs item #658053, was opened at 2002-12-23 16:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101044&aid=658053&group_id=1044 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 501 server init error (noffle 1.1.2) Initial Comment: When using noffle version 1.1.2 with a server that identifies itself as "Nnrpproxy v1.16.06" when I attempt to connect (usually with noffle --query groups) I get a series of messages like this (thanks to log-debug protocol): [S] MODE READER [S FLUSH] [R] 200 Ok [S] AUTHINFO USER <username> [S FLUSH] [R] 381 Password next please [S] AUTHINFO PASS <password> [S FLUSH] [R] 281 Authentication successful, 1285120 dl of 1099511627776 max (0%) Getting groups [S] LIST ACTIVE [S FLUSH] [R] 501 bad command usage LIST ACTIVE failed: 501 bad command usage [S] QUIT [S FLUSH] [R] 205 Bye This is on a Redhat 7.3 machine, I've tried both RPM and source installs. The weird thing is that with 1.0.1 this doesn't happen, I'd be happy using this but find myself wanting to use the hostname function of 1.1.2's config. Paul Tipper <p dot tipper at lancs dot ac dot uk> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101044&aid=658053&group_id=1044 |
|
From: Jim H. <jim...@ac...> - 2002-12-16 12:40:37
|
Hi Chris, Thanks for reporting this and going to the trouble to strace it. Do you still have the strace log around? If you do, does it indicate which gdbm call failed? I've tried to check all the gdbm calls, but the reporting may well be screwed up. I wonder how much of your newsbase is currently active articles. If you're using a recent CVS version, I changed 'expire' to work a bit faster, and added a 'rebuild' to rebuild the article base from scratch to minimise the database size. Watch out for that. My largest newsbase is about 900Mb, but then I don't read binary groups. I really must get round to doing an optional 'traditional spool' backend. gdbm in many, many ways is a bit of a problem. -- Jim Hague - jim...@in... (Work), ji...@be... (Play) Never trust a computer you can't lift. |
|
From: <no...@so...> - 2002-12-16 12:05:43
|
Bugs item #654124, was opened at 2002-12-15 16:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101044&aid=654124&group_id=1044 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Jim Hague (bears) Summary: gdbm fatal: lseek error Initial Comment: The size of my articles.gdbm file is approaching the limit of a signed 32-bit integer: -rw-r--r-- 1 news news 2147483413 Dec 15 11:27 articles.gdbm This appears to be associated with an error I get while running noffle -r under strace: 29155 write(2, "gdbm fatal: lseek error.\n", 25) = 25 The first half of the bug is that there is no indication in any program output that I could see (server responses, syslogs) that this is a gdbm lseek error. I had to use strace to figure that out. If nothing else, you could make the source of this error more obvious. The second half of the bug is that maybe its time to start using O_LARGEFILE :) I've only been using noffle for a little while so I am not an expert by any means. I tried using noffle --expire to make the articles.gdbm file smaller and that worked, but only after a couple of iterations of making my default expire period smaller Chris Cobb, cc...@em... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101044&aid=654124&group_id=1044 |
|
From: <no...@so...> - 2002-12-15 16:52:49
|
Bugs item #654124, was opened at 2002-12-15 08:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101044&aid=654124&group_id=1044 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: gdbm fatal: lseek error Initial Comment: The size of my articles.gdbm file is approaching the limit of a signed 32-bit integer: -rw-r--r-- 1 news news 2147483413 Dec 15 11:27 articles.gdbm This appears to be associated with an error I get while running noffle -r under strace: 29155 write(2, "gdbm fatal: lseek error.\n", 25) = 25 The first half of the bug is that there is no indication in any program output that I could see (server responses, syslogs) that this is a gdbm lseek error. I had to use strace to figure that out. If nothing else, you could make the source of this error more obvious. The second half of the bug is that maybe its time to start using O_LARGEFILE :) I've only been using noffle for a little while so I am not an expert by any means. I tried using noffle --expire to make the articles.gdbm file smaller and that worked, but only after a couple of iterations of making my default expire period smaller Chris Cobb, cc...@em... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101044&aid=654124&group_id=1044 |
65 messages has been excluded from this view by a project administrator.
