Newsgroup: it.comp.os.linux.sys
Titolo: Probelma con server news inn

 : reason : 436 cant store
article
10 Messages Posted
Elapsed Time = 0 mins 0.40 seconds
Cleaning up after myself
===================================================================
In pratica il download attraverso suck funziona senza problemi,
il punto dolente è invece come si vede il posting in locale degli
articoli.
L'errore è appunto "436 cant store article".
Vi chiederei, se aveste mai avuto a che fare con un problema del
genere e se per caso aveste la soluzione a portata di mano.
Inoltre aggiungo altri dettagli:
La versione di inn che uso è  inn-2.4.3-i486-1  slackware 12.1
Osservo che gli articoli in
/var/spool/news/articles/it/comp/os/win/xp/
sono ben più di 10!!
Questo perchè come ho anticipato il gruppo in questione tempo fa
lo avevo sul server.
Che sia questo il problema?
Non so magari i nuovi messaggi vengono numerati partendo da 1
mentre localmente l'articolo 1 c'è già e da qui l'errore che
ho riportato sopra...?
Ma in teoria gli articoli di un gruppo che viene rimosso non
dovrebbero essere anche loro rimossi?
Perchè pur avendo rimosso quel gruppo tempo fà ho ancora in
/var/spool/news/articles/it/comp/os/win... ? È normale? no
dovrebbe essere rimosso se lo elimino dal server?
tant'è che nel file active non c'è più.
Così a naso il problema potrebbe proprio essere questo:
nel file active leggo la riga:
it.comp.os.win.xp 0000000010 0000000001 y
Non sarà che gli articoli scaricati vengano inseriti in nello
spool numerati da 1 a 10?
Se così fosse mi pare ovvio che ci si ritrovi in una situazione
di equivoco...
Infatti per esempio il messaggio numero 1 c'è già, ma non è per
niente quello che ho appena scaricato, infatti:
news@localhost:~$ cat /var/spool/news/articles/it/comp/os/win/xp/1|grep Date
Date: Sat, 23 Aug 2008 11:24:40 GMT
Sono passati più di sei mesi, non può essrere il numero 1 del
file active che suck ha appena scaricato con successo. Anche
perchè in effetti non è riuscito a postarlo.
Una riprova potrebbe essere l'aggiunta di un nuovo gruppo che non
ho mai avuto sul server, probabilmente con quello non dovrebbero
esserci errori.
Per quanto riguarda l'esempio del gruppo ico.win.xp si
risolverebbe rimuovendolo dal server con "ctlinnd rmgrpup",
quindi cancellando a mano i vecchi articoli ed eventualmente
anche la directory presente nello spool...
Per poi riaggiungere il gruppo con "ctlinnd newgroup"?
Spero possiate chiarirmi un attimo la situazione o eventualmente
consigliarmi un link che la spieghi in modo semplice.
Grazie mille.

 Per poi riaggiungere il gruppo con "ctlinnd newgroup"?
Si questo è corretto.  Però se accetti un consiglio invece di usare 
'ctlinnd rmgrpup xx.xxx.xxxx.xxxx' per rimuovere un gruppo aggiungi 
semplicemente il nome del gruppo nel file 'active-ignore'.
Questo permette, dopo un certo tempo, di svuotare la directory del 
gruppo (o di archiviare i messaggi) senza intervenire manualmente. 
Per riabilitare il gruppo sarà sufficiente commentare o rimuovere 
l'entry nel file active-ignore.
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   Registered Linux user #337974  < 
http://giovanni.homelinux.net/
 >

 Giovanni

 numerazioni indipendenti, ma chiedo per conferma.
Si. Se fai un controllo in sucknewsrc (man suck) vedrai che contiene 
il numero dell'ultimo messaggio scaricato dal server e può contenere 
il numero max di messaggi da scaricare. p.e.
"nome.grup.po xxxxx -yy"
Quando togli il gruppo da active-ignore (basta commentare l'entry) 
scarica gli ultimi messaggi ma li posta localmente usando la 
numerazione di active.  Rimettendo il gruppo in active-ignore congela 
la situazione fino a che non vuoi ripartire.
Questo purtroppo non va bene se fai generare sucknewsrc 
automaticamente con le opzioni di suck.  Il numero di messaggi viene 
perso e viene usato il default (100) od il valore passato a suck con 
l'opzione "-i xxx".


 l'opzione "-i xxx".
Azz... ehh, in effetti la -i nelle opzioni ce l'ho.
Anche la -A che si basa sul file active locale.
Era comodo perchè per aggiungere un nuovo gruppo mi bastava usare
ctlinn newgroup.
In ogni caso, scusa ma il problema di cuistiamo parlando
influisce solo sui vecchi gruppi:
se non elimino il gruppo dal server l'opzione -i non è
importante, infatti non posso aggiungere un gruppo che c'è già.
quando sblocco il gruppo decomentandolo dall'active-ignored basta
aggiungere alla terza colonna il massimo numero di messaggi che
si vogliono scaricare.
Inoltre vedo dal man di suck che mettendo 0 alla terza colonna
non viene scaricato alcun articolo, come alternativa all'active
ignored.

   ecc.
Continuo questa discussione anche se il problema che ho adesso è
leggermente diverso...
Non sto a specificare troppo perchè non ho capito neanche io
quale sia il problema...o meglio dove stia.
Diciamo che ho il sospetto che un gruppo non venga aggiornato
adeguatamente. Infatti quando eseguo il suck degli articoli non
mi scarica alcun articolo eppure se provo a controllare da
nntp.it
 per esempio, il gruppo contiene nuovi articoli più
recenti che io non ho in locale.
Dubito che sia un problema del server news remoto (motzarella),
ma non ne sono sicurissimo.
Così avrei pensato di fare tabula rasa per quel gruppo.
Il fatto è che inn non è semplicissimo, e io non lo conosco così
in profondità.
L'obiettivo sarebbe:
eliminare quel gruppo dal server locale
eliminare tutti i messaggi scaricati, archiviati ecc ecc
modificare eventuali file di configurazione
*in modo tale da portare il server e il mio sistema ad una*
*situazione "come se" il gruppo non fosse mai stato presente sul*
*mio sistema.*
L'alternativa sarebbe capire perchè non riesco a
scaricare/iniettare_in_locale gli articoli di quel gruppo.
Francamente non saprei dove cercare risposte. Nei log non ci
capisco troppo ma non mi sembra vi siano errori.  :-?
Grazie in anticipo,spero possiate rispondermi.
Saluti.  :-)

 recenti che io non ho in locale.
Stop...
Devo ritrattare quanto ho affermato: ossevando per più tempo il
comportamento del server/suckfeed devo affermare che:
0- il gruppo in questione è moderato (mi ero scordato di questo
   particolare.
1- suck funziona bene scaricando normalmente gli articoli di
   questo gruppo.
2- l'"iniezione" in locale degli articoli di quel gruppo avviene
   senza errori, almeno eseguendo suck gli X mesaggi da scaricare
   vengono scaricati e risultano correttamente "X articles posted"
Ma allora qual'è il problema?
Partiamo dai "sintomi":
Due parole sull'utilizzo di Tin newsreader:
- Apro tin che uso come "rtin" collegandomi al server locale
- Nella prima "schermata" si vedono tutti i gruppi con a sinistra
  di ciascuno un numerino che indica la presenza dei messaggi non
  letti, se ve ne sono.
- Se entro in un gruppo contente messaggi non letti mi appare una
  schermata con il titolo di ogni thread contenente tali messaggi
  non letti, i thread senza nuovi messaggi non vengono
  visualizzati.
  Premendo "r" vengono visualizzati tutti i thread anche quelli
  contenenti articoli già letti.
Veniamo al problema col newsgrup "non funzionante":
- Effettuo il suck degli articoli e per quel gruppo
  vengonoscaricati X nuovi articoli, correttamente postati nello
  spool locale attraverso inn.
- Lancio "rtin" e mi aspetto di trovare nella prima schermata il
  gruppo in questione con i nuovi messaggi scaricati e postati in
  locale indicati correttamente come messaggi non letti.
  *Invece il gruppo risulta non contenere nuovi messaggi!!!*
  *Per quale santo ?!?*
- Entro nel gruppo e la schermata appare vuota, come se non ci
  fossero nuovi messaggi non letti.
- Caparbiamente premo "r" per vedere i messaggi già letti.
  Per caso scopro che tra questi thread/articoli vi sono anche i
  nuovi messaggi che non ho ancora letto.
Conlcusione:
Per il ng in questione che ha la caratteristica d'essere moderato
gli articoli risultano sempre già letti anche quando non lo sono.
Ora io ho in mente due ipotesi:
- gestione dei gruppi moderati mal impostata nella configurazione
  del server locale, questo potrebbe ripercuotersi sulla
  visualizzazione nel newsreader tin.
  La butto lì eh...solo un'ipotesi.
- problema relativo unicamente al news reader, magari il fatto
  che gli articoli siano vecchiotti visto che vengono moderati e
  passa un po' prima di essere postati...
  Magari rivedo le impostazioni di tin.
Avete idee in merito? altre ipotesi? qualsiasi cosa...
Grazie in anticipo.  :-)


 anticipo.  :-)
Sul server locale in NG non deve essere moderato.


     =foo.bar Articles are filed in the group foo.bar instead.
A questo punto direi che locaalmente il gruppo non risulta
moderato giusto?
Quindi ne posso concludere che il problema č un'altro oppure
occorre guardare anche da qualche altra parte?
E se invece il problema stesse piů semplicemente nel newsreader?

 E se invece il problema stesse più semplicemente nel newsreader?
Io normalmente uso Thunderbird e non ho alcun problema sui NG moderati.


 Io normalmente uso Thunderbird e non ho alcun problema sui NG moderati.
No, il problema sicuramente non è *quale* newsreader uso, ma come
tale newsreader è configurato.
In ogni caso il fatto che il ng in questione sia moderato
non è l'unico discriminante:
infatti per controprova ho aggiunto al server it.test.moderato,
et voilà...i nuovi messaggi ci sono e sono evidenti come per
tutti gli altri gruppi funzionanti regolarmente.
Potrei dedurne che il fatto della moderazione non centra nulla,
in realtà potrebbe centrare indirettamente quindi non mi
sbilancio.
Piuttosto aggiungo che, come avevo detto nei primi messaggi della
discussione, il gruppo in questione ha seguito un certo
trattamento nel corso del tempo sul mio server:
1- avevo aggiunto il gruppo e funzionava.
2- avevo cancellato il gruppo dal server
3- lo avevo riaggiunto
Sempre all'inizio della discussione avevamo concluso che questa
manovra è meglio evitarla: conviene sostituire al punto 2 il
congelamento del gruppo aggiungendolo all'active-ignore di suck.
Altrimenti i messaggi del gruppo eliminato permangono nello spool
delle news e quando il gruppo si riaggiunge è molto probabile che
la numerazione dei nuovi messaggi scaricati sia inferiore al
numero dei messaggi rimasti nello spool. Questo genera un errore
durante il post in locale dei nuovi messaggi.
Per quanto riguarda il gruppo che non funziona bene avevo rimosso
gli articoli rimasti e poi lo avevo riaggiunto, quindi problemi
di posting non dovrebbero essercene. E infatti non ve ne sono.
Però il newsreader si rifiuta di riconoscere i nuovi messaggi
come non letti.
Non so dove tali nuovi messaggi vengano etichettati come già
letti, se è un problema di inn o un problema di tin...
Oltre alla numerazione deve esserci qualche altro file che
dovrebbe essere messo apposto.
Mi viene in mente l'history o il database, ma così puramente a
naso...
non so.
Però...scrivendo queste cose, mi viene in mente che vi erano dei
file riguardanti le news nella mia home.
Ho controllato il file ~/.newsrc e presenta delle righe del tipo:
gruppo.non.funzionante  1-3023
gruppo.funzionante 1-16976
altro.gruppo.funzionante 1-1530
L'ho confrontato con il file active del server locale do ve ho:
gruppo.non.funzionante  0000000346 0000000001
gruppo.funzionante 0000016977 0000000159
altro.gruppo.funzionante 0000001530 0000000001 y
Ok in questa situazione dove io ho riportato solo alcune righe,
ad avere problemi è solo uno: il gruppo non funzionante.
Ed a presentare una divergenza così marcata nei due file di
configurazione è solo il gruppo non funzionante.
Il primo gruppo funzionante sgarra di un articolo, ma
probabilmente perchè sul server ho scritto e postato, mentre e
forse sul ~/.newsrc non è ancora stato aggironamento della
situazione. La butto lì. Inoltre in tale gruppo nel file active
si parte dal 159esimo articolo....non so perchè, ma comunque a
quanto pare non è un problema, da quanto vedo l'importante è che
sia rispettato il numero dell'ultimo articolo.
Io ne deduco un ragionamento e vi chiederei se vi pare sensato
oppure no:
il file active per il ng non funzionante contiene 346 articoli
il file ~/.newsrc contiene ben 3023 articoli per lo stesso ng.
Ciò implica che quando il newsreader accede a tale ng trova per
esempio l'articolo 346 e però vede dal ~/.newsrc che ne sono
stati letti ben 3023, per cui considera il 346 come già letto.
Posso dichiarare conclusa l'indagine?
A voi la domanda.
Se vi siete già trovati in pasticci simili...o anche no ma avete
le idee chiare: come rimediare in modo un po' pulito?
Grazie in anticipo e nuovamente per la disponibilità.  :-)

 Grazie in anticipo e nuovamente per la disponibilità.  :-)
Thunderbird ha un file analogo ed in passato, quando avevo la linea 
dial-up, si incasinava e thunderbird, al contrario di quanto succede a 
te, segnalava che vi erano dei messaggi non letti.  Aprendo il NG 
questi messaggi sparivano ma ritornavano alla successiva riapertura 
del programma.  Nel file risultava ad esempio:
it.comp.os.linux.sys: 1-1234,1236-1238,1240-1266,1268-1555
Cioè era come se ci fossero alcuni messaggi che non riusciva a leggere 
dal server.  Per risolvere cancellavo la lista dei messaggi, ma 
dovrebbe essere sufficiente "Unsuscribe" il NG, uscire dal newsreader 
e "Subscribe" al successivo riavvio.  Non so se questo sia valido per 
tutti i reader ma per thunderbird funzionava.
Dico funzionava perché da quando ho l'adsl sono sempre connesso, suck 
scarica ogni 10 minuti ed il problema non si è più presentato.


 scarica ogni 10 minuti ed il problema non si è più presentato.
Scusa ma non capisco il nesso:
anche io pur non avendo l'adsl scarico ogni tot con suck. Però
poi per la lettura dei messaggi....serve sempre un newsreader
ovviamente e nel mio caso collegarmi al server locale o ad un
server remoto, non cambia nulla in termini di configurazione del
newsreader (a parte l'indirizzo del server intendo, ovvio).
*********
Comunque a quanto pare ho risolto... Prima di leggere questo
messaggio che probabilmente nella tua prima frase che ho
riportato contiene la soluzione.
In ogni caso ho editato a mano il file ~/.newsrc alla riga
corrispondente al gruppo non funzionante.
Il file active era del tipo:
gruppo.non.funz 0000000NNN 0000000001 y
nel ~/.newsrc ho messo:
gruppo.non.funz 1-(NNN-10) 
dove NNN-10 è un numero risultante dalla espressione aritmetica
stessa.
In pratica ho imposto nel newsrc che il gruppo non funzionante
avesse 10 messaggi non letti rispetto al numero di articoli
presenti sul server locale (file active).
Sono ancora in tempo per fare la prova con la manovra
consigliata:
unsubscribe-exit-enter-subcribe
Comunque il problema è risolto.