Determining which Cycbuff has an article
John F. Morse
article.
Seems it used either the MessageID or the token, which I can get from
the MessageID with the grephistory command.
Any clues?
TIA.
--
John
Hauke Lampe
> I can't find the command to determine which Cycbuff contains a specific
> article.
The cycbuff name is encoded in the message token:
vindalf:~# grephistory "<37bea827-72e4-4f30...@u20g2000vbq.googlegroups.com>"
@03054F544845523133000004A58100000001@
^^^^^^^^^^^^^^
O T H E R 1 3
I don't know any tools shipped with INN that would decode this easily, though.
Hauke.
Szymon Sokół
This oneliner should do the trick (there are three regexp substitutions -
the first one cuts the relevant part of the token, the second one converts
it from hex to ASCII, and the third one removes trailing NULs):
grephistory "<37bea827-72e4-4f30...@u20g2000vbq.googlegroups.com>" |
perl -ple 's/^\@.{4}(.{16}).{16}\@$/$1/ && s/(..)/chr hex $1/eg && s/\0*$//'
--
Szymon Sokół (SS316-RIPE) -- Network Manager B
Computer Center, AGH - University of Science and Technology, Cracow, Poland O
http://home.agh.edu.pl/szymon/ PGP key id: RSA: 0x2ABE016B, DSS: 0xF9289982 F
Free speech includes the right not to listen, if not interested -- Heinlein H
Russ Allbery
> The cycbuff name is encoded in the message token:
> vindalf:~# grephistory "<37bea827-72e4-4f30...@u20g2000vbq.googlegroups.com>"
> @03054F544845523133000004A58100000001@
> ^^^^^^^^^^^^^^
> O T H E R 1 3
> I don't know any tools shipped with INN that would decode this easily,
> though.
sm -c in current development versions of INN. In previous versions,
contrib/showtoken should do it.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Please post questions rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
John F. Morse
Interesting.
My token(s) are not that long -- they do not contain the class name
(your "OTHER"?), only the buffer number (your "13"?).
But maybe you named your buffers with words as well as numerals in
cycbuff.conf? For instance, I used only numerals in mine, like the
following:
cycbuff:001:/var/spool/news/cycbuffs/001:65535
cycbuff:002:/var/spool/news/cycbuffs/002:262143
cycbuff:003:/var/spool/news/cycbuffs/003:524287
cycbuff:004:/var/spool/news/cycbuffs/004:2097151
cycbuff:005:/var/spool/news/cycbuffs/005:2097151
cycbuff:006:/var/spool/news/cycbuffs/006:2097151
cycbuff:007:/var/spool/news/cycbuffs/007:2097151
cycbuff:008:/var/spool/news/cycbuffs/008:2097151
cycbuff:009:/var/spool/news/cycbuffs/009:2097151
cycbuff:010:/var/spool/news/cycbuffs/010:2097151
cycbuff:011:/var/spool/news/cycbuffs/011:2097151
cycbuff:012:/var/spool/news/cycbuffs/012:2097151
cycbuff:013:/var/spool/news/cycbuffs/013:2097151
cycbuff:014:/var/spool/news/cycbuffs/014:2097151
cycbuff:015:/var/spool/news/cycbuffs/015:2097151
cycbuff:016:/var/spool/news/cycbuffs/016:2097151
cycbuff:017:/var/spool/news/cycbuffs/017:1048575
metacycbuff:veryfast:001
metacycbuff:fastbins:002
metacycbuff:fasttext:003
metacycbuff:slowbins:004
metacycbuff:slowtext:005,006,007,008,009,010,011,012,013,014,015,016:SEQUENTIAL
Then I used words in the metacycbuff descriptions.
One of my tokens is shown as:
@030230303200000000000001E1AD0000000C@
^^^^^^
0 0 2
The above shows buffer #002 which is correct and sufficient for my needs.
Thanks Hauke.
--
John
John F. Morse
> On Mon, 30 Nov 2009 13:26:18 +0000 (UTC), Hauke Lampe wrote:
>
>> John F. Morse schrieb:
>>
>>> I can't find the command to determine which Cycbuff contains a specific
>>> article.
>>>
>> The cycbuff name is encoded in the message token:
>>
>> vindalf:~# grephistory "<37bea827-72e4-4f30...@u20g2000vbq.googlegroups.com>"
>> @03054F544845523133000004A58100000001@
>> ^^^^^^^^^^^^^^
>> O T H E R 1 3
>>
>> I don't know any tools shipped with INN that would decode this easily, though.
>>
>
> This oneliner should do the trick (there are three regexp substitutions -
> the first one cuts the relevant part of the token, the second one converts
> it from hex to ASCII, and the third one removes trailing NULs):
>
> grephistory "<37bea827-72e4-4f30...@u20g2000vbq.googlegroups.com>" |
> perl -ple 's/^\@.{4}(.{16}).{16}\@$/$1/ && s/(..)/chr hex $1/eg && s/\0*$//'
>
news@optima5:/usr/lib/news/bin$ grephistory
"d5v7h59hs39unhrd8...@4ax.com" | perl -ple
's/^\@.{4}(.{16}).{16}\@$/$1/ && s/(..)/chr hex $1/eg && s/\0*$//'
002
^^^
That does show buffer 002 which is correct for this particular Message-ID.
The token is: @030230303200000000000001E1AD0000000C@
^^^^^^
0 0 2
Thanks for this information, Szymon.
--
John
John F. Morse
> Hauke Lampe <packbar...@blagga.openchaos.org> writes
>> The cycbuff name is encoded in the message token:
>>
>> vindalf:~# grephistory "<37bea827-72e4-4f30...@u20g2000vbq.googlegroups.com>"
>> @03054F544845523133000004A58100000001@
>> ^^^^^^^^^^^^^^
>> O T H E R 1 3
>>
>> I don't know any tools shipped with INN that would decode this easily,
>> though.
>>
>
> sm -c in current development versions of INN. In previous versions,
> contrib/showtoken should do it.
>
Hi Russ.
That Storage Manager -c option won't work with my INN 2.4.5. Was it the
2.5 version that added this?:
http://www.eyrie.org/~eagle/software/inn/docs-2.5/sm.html
The showtoken is available in /usr/lib/news/bin:
-rwxr-xr-x 1 root root 2305 2008-12-14 17:51 showtoken
However, it does nothing when launched in a terminal, and then ^C is
required to escape the terminal. Nothing is logged in syslog nor in
messages when showtoken is run, alone or with a Message-ID, quoted or
not. There is no man page.
Showtoken is a Perl script, but unless it just takes forever, and shows
nothing in top, it is not launching/running, even with the ".pl"
extension added.
What could I be missing?
--
John
Hauke Lampe
> But maybe you named your buffers with words as well as numerals in
> cycbuff.conf?
Yes, I keep groups of cycbuffs for different hierarchies.
> One of my tokens is shown as:
>
> @030230303200000000000001E1AD0000000C@
> ^^^^^^
> 0 0 2
>
> The above shows buffer #002 which is correct and sufficient for my needs.
As Russ said, contrib/showtoken decodes all information in a storage token:
$ echo "@030230303200000000000001E1AD0000000C@" |./showtoken
@030230303200000000000001E1AD0000000C@ type=cnfs class=2 buffer=002 offset=3c35a00 cycnum=c
# Format of a token:
# 1 type
# 1 class
# 16 token
# 1 index
# 4 offset
# 2 overlen
# 2 cancelled
# The fields "index" and following are not available with OV3 (INN 2.3 up)
#
# the "token" field is:
# for type=0 (trash) ignored
# for type=2 (timehash)
# 4 time
# 2 seqnum
# for type=3 (cnfs)
# 8 cycbuffname
# 4 offset/512
# 4 cycnum
# for type=4 (timecaf)
# 4 time
# 2 seqnum
# for type=5 (tradspool)
# 4 ngnum
# 4 artnum
Hauke.
Russ Allbery
> That Storage Manager -c option won't work with my INN 2.4.5. Was it the
> 2.5 version that added this?:
> http://www.eyrie.org/~eagle/software/inn/docs-2.5/sm.html
No, it's even more recent than 2.5.1.
> The showtoken is available in /usr/lib/news/bin:
> -rwxr-xr-x 1 root root 2305 2008-12-14 17:51 showtoken
> However, it does nothing when launched in a terminal, and then ^C is
> required to escape the terminal. Nothing is logged in syslog nor in
> messages when showtoken is run, alone or with a Message-ID, quoted or
> not. There is no man page.
I think it expects the token on standard input.
John F. Morse
> "John F. Morse" <jo...@example.invalid> writes:
>
>> That Storage Manager -c option won't work with my INN 2.4.5. Was it the
>> 2.5 version that added this?:
>> http://www.eyrie.org/~eagle/software/inn/docs-2.5/sm.html
>>
>
> No, it's even more recent than 2.5.1.
>
>> The showtoken is available in /usr/lib/news/bin:
>>
>> -rwxr-xr-x 1 root root 2305 2008-12-14 17:51 showtoken
>>
>> However, it does nothing when launched in a terminal, and then ^C is
>> required to escape the terminal. Nothing is logged in syslog nor in
>> messages when showtoken is run, alone or with a Message-ID, quoted or
>> not. There is no man page.
>>
>
> I think it expects the token on standard input.
>
That doesn't do anything either. :-(
--
John
Russ Allbery
Maybe it's waiting for an end of file before it reports the tokens? See
the example posted elsewhere in this thread.
John F. Morse
> John F. Morse schrieb:
>
>> But maybe you named your buffers with words as well as numerals in
>> cycbuff.conf?
>>
>
> Yes, I keep groups of cycbuffs for different hierarchies.
>
>> One of my tokens is shown as:
>>
>> @030230303200000000000001E1AD0000000C@
>> ^^^^^^
>> 0 0 2
>>
>> The above shows buffer #002 which is correct and sufficient for my needs.
>>
>
> As Russ said, contrib/showtoken decodes all information in a storage token:
>
> $ echo "@030230303200000000000001E1AD0000000C@" |./showtoken
> @030230303200000000000001E1AD0000000C@ type=cnfs class=2 buffer=002 offset=3c35a00 cycnum=c
>
Ah ha! Yes, that works great.
news@optima5:/usr/lib/news/bin$ echo
"@030230303200000000000001E1AD0000000C@" |./showtoken
@030230303200000000000001E1AD0000000C@ type=cnfs class=2 buffer=002
offset=3c35a00 cycnum=c
Thank you Hauke.
--
John
John F. Morse
> Maybe it's waiting for an end of file before it reports the tokens? See
> the example posted elsewhere in this thread.
>
Hi Russ. I got it, thanks to Hauke.
I was stuck on stupid (again) and trying to redirect ("<") the token
into showtoken, or "perl showtoken < ..." etc.
The reason I'm fiddling with this is I had an original class 2 buffer
#002 with a 256 MB size.
Well, for clarity, here is what is looks like:
Class fastbins for groups matching "*.bina*,!xanadu.binaries"
Buffer 002, size: 256 MBytes, position: 61.0 MBytes 11.24 cycles
Newest: 2009-11-30 17:23:56, 0 days, 3:45:44 ago
Oldest: 2009-10-14 9:02:40, 47 days, 13:07:00 ago
and
news@optima5:~$ cnfsheadconf -c 002
Buffer 002, len: 256.00 Mbytes, used: 60.96 Mbytes (23.8%) 11 cycles
Meta , order: 0, current: TRUE
Newest: 2009-11-30 17:23:56, 0 days, 3:46:17 ago
Then about two months ago I noticed the oldest articles were not even 24
hours old. I verified this by accessing the group using Pan and
downloading all articles.
So, afraid the messages were overrunning the buffer, I created a 1 GB
buffer and changed cycbuff.conf to point to only it. I thought that
would give me at least four times the days if the rate of posting stayed
the same. Of course old messages in 002 were still available for
readers, but all new articles were directed to buffer 017.
I've been watching 017 and it has barely grown in size -- or, oldest
message were getting a day older every day, and the buffer wasn't
filling very fast.
So last night I put the original cycbuff.conf back to buffer 002, and
watched the cnfsstat -a after a few articles were posted, just to make
sure they were indeed going where I wanted them to go.
Then I remembered I had used some command last summer to see what buffer
a Message-ID (or the token) pointed to, and I wanted to check that
against a newly-posted message after the cycbuff.conf change. I ran into
blanks despite much searching, so I asked here.
Now I know how to check, and I don't think I have to worry. The
partially-full buffer 017 is still available should I need to assign it
again. If not, I'll delete it, recreate it as a 2 GB buffer, and assign
it to the "*" slowtext groups as the next sequential buffer.
Thanks Russ.
--
John