En vue de peut-être mettre en place mon propre serveur de nouvelles, je
cherche à évaluer la difficulté de cette tâche, comparée à, disons, la
mise en place d'un service de courrier et de boîte aux lettres. Et du
travail de maintenance que cela représente, sachant qu'il s'agira
vraisemblablement d'un serveur familial uniquement. Déjà, est-ce
pertinent à votre avis ?
À ce que j'ai compris, mettre en place un serveur de nouvelles, ça
implique de l'installer, de trouver un autre serveur existant pour s'y
connecter, et de configurer tout ça. Si je décide de m'y mettre, je
devrais pouvoir découvrir ça au fur et à mesure, mais j'aimerais me
faire une idée de la difficulté avant de m'y lancer.
Ah, et tant que j'y suis, auriez-vous une idée des hiérarchies les plus
pertinentes : le big 8, fr.*, france.*, autre chose à considérer ?
Une idée du débit que cela représente (texte uniquement, pas
besoin de binaires ici) ?
On 2013-04-05, Julien Arlandis <"julien.arlandis at laposte.net"> wrote:
Nemo sera le serveur de news le plus facile à administrer quand il sera fini ;-)
Uuh, uuh...
-- % What to put into the "Organization:" header line. set organization "J'aurais bien vu du BAUDOT 5 moments"
Julien ÉLIE
Bonjour Tanguy,
Mon idée est effectivement de mettre en place un serveur accessible aux membres de ma famille uniquement, dans l'idée de fournir un service de nouvelles tout comme je fournis un service de courrier électronique par exemple. Un peu comme les FAI le font souvent pour leurs clients.
En revanche, le but serait de donner accès aux hiérarchies générales. La possibilité de définir des groupes locaux ne m'intéresse pas particulièrement.
Des groupes locaux pourraient être utiles pour « discuter » (au lieu d'un forum privé). Cela permet de diffuser l'information facilement (au même titre qu'un courrier électronique, sans avoir à saisir des adresses en CC), d'avoir les archives pour tout nouvel arrivant (souvent plus faciles à consulter et pour réaliser des recherches que des archives web de ml)... Tu peux autoriser le HTML ou des pièces jointes (photos par exemple) sur tes groupes locaux. Voilà, c'étaient quelques suggestions auxquelles je présume tu as déjà songé.
-- Julien ÉLIE
« Si le peuple est content des jeux, je te donnerai des sesterces. S'il n'est pas content, je te donnerai aux lions ! » (Astérix)
Bonjour Tanguy,
Mon idée est effectivement de mettre en place un serveur accessible aux
membres de ma famille uniquement, dans l'idée de fournir un service de
nouvelles tout comme je fournis un service de courrier électronique par
exemple. Un peu comme les FAI le font souvent pour leurs clients.
En revanche, le but serait de donner accès aux hiérarchies générales. La
possibilité de définir des groupes locaux ne m'intéresse pas
particulièrement.
Des groupes locaux pourraient être utiles pour « discuter » (au lieu
d'un forum privé). Cela permet de diffuser l'information facilement (au
même titre qu'un courrier électronique, sans avoir à saisir des adresses
en CC), d'avoir les archives pour tout nouvel arrivant (souvent plus
faciles à consulter et pour réaliser des recherches que des archives web
de ml)... Tu peux autoriser le HTML ou des pièces jointes (photos par
exemple) sur tes groupes locaux.
Voilà, c'étaient quelques suggestions auxquelles je présume tu as déjà
songé.
--
Julien ÉLIE
« Si le peuple est content des jeux, je te donnerai des sesterces.
S'il n'est pas content, je te donnerai aux lions ! » (Astérix)
Mon idée est effectivement de mettre en place un serveur accessible aux membres de ma famille uniquement, dans l'idée de fournir un service de nouvelles tout comme je fournis un service de courrier électronique par exemple. Un peu comme les FAI le font souvent pour leurs clients.
En revanche, le but serait de donner accès aux hiérarchies générales. La possibilité de définir des groupes locaux ne m'intéresse pas particulièrement.
Des groupes locaux pourraient être utiles pour « discuter » (au lieu d'un forum privé). Cela permet de diffuser l'information facilement (au même titre qu'un courrier électronique, sans avoir à saisir des adresses en CC), d'avoir les archives pour tout nouvel arrivant (souvent plus faciles à consulter et pour réaliser des recherches que des archives web de ml)... Tu peux autoriser le HTML ou des pièces jointes (photos par exemple) sur tes groupes locaux. Voilà, c'étaient quelques suggestions auxquelles je présume tu as déjà songé.
-- Julien ÉLIE
« Si le peuple est content des jeux, je te donnerai des sesterces. S'il n'est pas content, je te donnerai aux lions ! » (Astérix)
Julien ÉLIE
Bonjour Gérald,
Le fichier le plus tordus pour ma part est celui qui concerne l'authentification (readers.conf), c'est celui là qui mérite attention. Le reste étant très bien documenté.
Le principe des blocs auth/access rend effectivement la configuration moins directe. Lorsque tu dis que le reste est bien documenté, cela signifie-t-il qu'il manque des informations dans la doc de readers.conf ? Si oui, pourrais-tu préciser ce qui ne te semble pas clair et ce qu'il te semble manquer ? Je te remercie par avance.
Fichier de configuration fourni par défaut : http://www.eyrie.org/~eagle/software/inn/docs/samples/readers.conf
Documentation : http://www.eyrie.org/~eagle/software/inn/docs/readers.conf.html -> il y a une partie EXAMPLES
-- Julien ÉLIE
« Vina bibant homines, animantia cetera fontes. »
Bonjour Gérald,
Le fichier le plus tordus pour ma part est celui qui concerne
l'authentification (readers.conf), c'est celui là qui mérite attention.
Le reste étant très bien documenté.
Le principe des blocs auth/access rend effectivement la configuration
moins directe.
Lorsque tu dis que le reste est bien documenté, cela signifie-t-il qu'il
manque des informations dans la doc de readers.conf ? Si oui,
pourrais-tu préciser ce qui ne te semble pas clair et ce qu'il te semble
manquer ?
Je te remercie par avance.
Fichier de configuration fourni par défaut :
http://www.eyrie.org/~eagle/software/inn/docs/samples/readers.conf
Documentation :
http://www.eyrie.org/~eagle/software/inn/docs/readers.conf.html
-> il y a une partie EXAMPLES
Le fichier le plus tordus pour ma part est celui qui concerne l'authentification (readers.conf), c'est celui là qui mérite attention. Le reste étant très bien documenté.
Le principe des blocs auth/access rend effectivement la configuration moins directe. Lorsque tu dis que le reste est bien documenté, cela signifie-t-il qu'il manque des informations dans la doc de readers.conf ? Si oui, pourrais-tu préciser ce qui ne te semble pas clair et ce qu'il te semble manquer ? Je te remercie par avance.
Fichier de configuration fourni par défaut : http://www.eyrie.org/~eagle/software/inn/docs/samples/readers.conf
Documentation : http://www.eyrie.org/~eagle/software/inn/docs/readers.conf.html -> il y a une partie EXAMPLES
-- Julien ÉLIE
« Vina bibant homines, animantia cetera fontes. »
Julien ÉLIE
Bonjour Éric,
Même s'ils sont comparables par certains aspects, Diablo et INN n'ont pas la même finalité. Diablo est plus orienté gestion de flux (cas typique, gestion en entrée sortie des feeds) ; INN est plus orienté serveur de news.
Le module de lecture de nouvelles pour Diablo (dreader) permettant à un lecteur de nouvelles d'accéder aux messages n'a effectivement été ajouté que dans un deuxième temps. La force de Diablo est le feed. (INN ne démérite pour autant pas au niveau feed.)
Exemple typique : un gros FSI reçoit et réémet un nombre considérables d'articles, de et vers un nombre tout aussi considérable de feeds. Son boulot, c'est de transmettre et de recevoir vite, sans autre considération de contenu (il transmettra aussi les spams par exemple) ni des groupes transportés (il peut promener des hiérachies entières qui ne sont pas gérées par l'INN qui est derrière) de gestion d'acceptation / refus des articles, etc. Il bourrine le plus vite possible, et il le fait bien.
Derrière, INN se chargera de faire le tri entre les groupes/hiérachies qu'il sert ou pas, de trier les articles qu'il a déjà reçus, d'appliquer des règles antispam, etc.
Et parfois c'est aussi INN qui va servir les articles aux lecteurs de nouvelles.
-- Julien ÉLIE
« – Et fais attention de ne pas te cogner aux arbres ! – … – Le tout, c'est de faire attention de ne pas se cogner aux Gaulois ! » (Astérix)
Bonjour Éric,
Même s'ils sont comparables par certains aspects, Diablo et INN n'ont
pas la même finalité. Diablo est plus orienté gestion de flux (cas
typique, gestion en entrée sortie des feeds) ; INN est plus orienté
serveur de news.
Le module de lecture de nouvelles pour Diablo (dreader) permettant à un
lecteur de nouvelles d'accéder aux messages n'a effectivement été ajouté
que dans un deuxième temps. La force de Diablo est le feed. (INN ne
démérite pour autant pas au niveau feed.)
Exemple typique : un gros FSI reçoit et réémet un nombre considérables
d'articles, de et vers un nombre tout aussi considérable de feeds. Son
boulot, c'est de transmettre et de recevoir vite, sans autre
considération de contenu (il transmettra aussi les spams par exemple) ni
des groupes transportés (il peut promener des hiérachies entières qui ne
sont pas gérées par l'INN qui est derrière) de gestion d'acceptation /
refus des articles, etc. Il bourrine le plus vite possible, et il le
fait bien.
Derrière, INN se chargera de faire le tri entre les groupes/hiérachies
qu'il sert ou pas, de trier les articles qu'il a déjà reçus, d'appliquer
des règles antispam, etc.
Et parfois c'est aussi INN qui va servir les articles aux lecteurs de
nouvelles.
--
Julien ÉLIE
« – Et fais attention de ne pas te cogner aux arbres !
– …
– Le tout, c'est de faire attention de ne pas se cogner aux
Gaulois ! » (Astérix)
Même s'ils sont comparables par certains aspects, Diablo et INN n'ont pas la même finalité. Diablo est plus orienté gestion de flux (cas typique, gestion en entrée sortie des feeds) ; INN est plus orienté serveur de news.
Le module de lecture de nouvelles pour Diablo (dreader) permettant à un lecteur de nouvelles d'accéder aux messages n'a effectivement été ajouté que dans un deuxième temps. La force de Diablo est le feed. (INN ne démérite pour autant pas au niveau feed.)
Exemple typique : un gros FSI reçoit et réémet un nombre considérables d'articles, de et vers un nombre tout aussi considérable de feeds. Son boulot, c'est de transmettre et de recevoir vite, sans autre considération de contenu (il transmettra aussi les spams par exemple) ni des groupes transportés (il peut promener des hiérachies entières qui ne sont pas gérées par l'INN qui est derrière) de gestion d'acceptation / refus des articles, etc. Il bourrine le plus vite possible, et il le fait bien.
Derrière, INN se chargera de faire le tri entre les groupes/hiérachies qu'il sert ou pas, de trier les articles qu'il a déjà reçus, d'appliquer des règles antispam, etc.
Et parfois c'est aussi INN qui va servir les articles aux lecteurs de nouvelles.
-- Julien ÉLIE
« – Et fais attention de ne pas te cogner aux arbres ! – … – Le tout, c'est de faire attention de ne pas se cogner aux Gaulois ! » (Astérix)
[En-tête "Followup-To:" positionné à fr.comp.usenet.serveurs.]
Le Dimanche 14 avril 2013 à 11:02 UTC, Julien ÉLIE écrivait sur fr.comp.usenet.serveurs :
Le principe des blocs auth/access rend effectivement la configuration moins directe.
Oui c'est un peu ça.
Lorsque tu dis que le reste est bien documenté, cela signifie-t-il qu'il manque des informations dans la doc de readers.conf ?
Je me suis mal exprimé, pas d'inquiétude à avoir. ;-)
Disons que c'est la partie de la configuration qui m'a posé le plus de problèmes de compréhension (mon niveau en anglais y a contribué), je me suis même retrouvé sans le vouloir avec un serveur ouvert pendant quelques temps au début.
Et quand je parle de documentations, je parles des autres documents que la documentation qui vient avec Inn. Je parles des différents tuto ou docs qui détaillent, en français, l'installation et la configuration. C'est dans ces documents que la partie authentification est survolée si ce n'est ignorée.
@+ -- On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le gouvernement ; c'est la paix sans la violence. C'est le contraire précisément de tout ce qu'on lui reproche, soit par ignorance, soit par mauvaise foi. -+- Hem Day -+-
[En-tête "Followup-To:" positionné à fr.comp.usenet.serveurs.]
Le Dimanche 14 avril 2013 à 11:02 UTC, Julien ÉLIE écrivait sur
fr.comp.usenet.serveurs :
Le principe des blocs auth/access rend effectivement la configuration
moins directe.
Oui c'est un peu ça.
Lorsque tu dis que le reste est bien documenté, cela signifie-t-il qu'il
manque des informations dans la doc de readers.conf ?
Je me suis mal exprimé, pas d'inquiétude à avoir. ;-)
Disons que c'est la partie de la configuration qui m'a posé le plus de
problèmes de compréhension (mon niveau en anglais y a contribué), je
me suis même retrouvé sans le vouloir avec un serveur ouvert pendant
quelques temps au début.
Et quand je parle de documentations, je parles des autres documents
que la documentation qui vient avec Inn. Je parles des différents tuto
ou docs qui détaillent, en français, l'installation et la configuration.
C'est dans ces documents que la partie authentification est survolée si
ce n'est ignorée.
@+
--
On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le
gouvernement ; c'est la paix sans la violence. C'est le contraire
précisément de tout ce qu'on lui reproche, soit par ignorance, soit
par mauvaise foi. -+- Hem Day -+-
[En-tête "Followup-To:" positionné à fr.comp.usenet.serveurs.]
Le Dimanche 14 avril 2013 à 11:02 UTC, Julien ÉLIE écrivait sur fr.comp.usenet.serveurs :
Le principe des blocs auth/access rend effectivement la configuration moins directe.
Oui c'est un peu ça.
Lorsque tu dis que le reste est bien documenté, cela signifie-t-il qu'il manque des informations dans la doc de readers.conf ?
Je me suis mal exprimé, pas d'inquiétude à avoir. ;-)
Disons que c'est la partie de la configuration qui m'a posé le plus de problèmes de compréhension (mon niveau en anglais y a contribué), je me suis même retrouvé sans le vouloir avec un serveur ouvert pendant quelques temps au début.
Et quand je parle de documentations, je parles des autres documents que la documentation qui vient avec Inn. Je parles des différents tuto ou docs qui détaillent, en français, l'installation et la configuration. C'est dans ces documents que la partie authentification est survolée si ce n'est ignorée.
@+ -- On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le gouvernement ; c'est la paix sans la violence. C'est le contraire précisément de tout ce qu'on lui reproche, soit par ignorance, soit par mauvaise foi. -+- Hem Day -+-
yamo'
Salut,
Julien ÉLIE a tapoté, le 14/04/2013 13:02:
Lorsque tu dis que le reste est bien documenté, cela signifie-t-il qu'il manque des informations dans la doc de readers.conf ?
À mon avis, il manque un script qui parserait le fichier de conf comme nnrpd et qui indiquerait qui peut poster.
À mon avis, il manque un script qui parserait le fichier de conf comme nnrpd et qui indiquerait qui peut poster.
Le fait que de nombreux paramètres peuvent être déterminés par des scripts d'authentification extérieurs rendent l'indication de qui peut poster quasiment impossible de manière générale.
D'ailleurs, ne serait-il finalement pas plus « facile » (ou du moins plus lisible) d'avoir dans son readers.conf un unique bloc auth qui utilise la directive python_access ou perl_access ? Les droits d'accès seraient alors générés dynamiquement par un script Perl ou Python avec des règles ordonnées, claires, probablement plus compréhensibles qu'une série de blocs access dans readers.conf...
-- Julien ÉLIE
« Tant qu'il y a des marmites, il y a de l'espoir ! » (Astérix)
Bonjour Stéphane,
À mon avis, il manque un script qui parserait le fichier de conf comme
nnrpd et qui indiquerait qui peut poster.
Le fait que de nombreux paramètres peuvent être déterminés par des
scripts d'authentification extérieurs rendent l'indication de qui peut
poster quasiment impossible de manière générale.
D'ailleurs, ne serait-il finalement pas plus « facile » (ou du moins
plus lisible) d'avoir dans son readers.conf un unique bloc auth qui
utilise la directive python_access ou perl_access ? Les droits d'accès
seraient alors générés dynamiquement par un script Perl ou Python avec
des règles ordonnées, claires, probablement plus compréhensibles qu'une
série de blocs access dans readers.conf...
--
Julien ÉLIE
« Tant qu'il y a des marmites, il y a de l'espoir ! » (Astérix)
À mon avis, il manque un script qui parserait le fichier de conf comme nnrpd et qui indiquerait qui peut poster.
Le fait que de nombreux paramètres peuvent être déterminés par des scripts d'authentification extérieurs rendent l'indication de qui peut poster quasiment impossible de manière générale.
D'ailleurs, ne serait-il finalement pas plus « facile » (ou du moins plus lisible) d'avoir dans son readers.conf un unique bloc auth qui utilise la directive python_access ou perl_access ? Les droits d'accès seraient alors générés dynamiquement par un script Perl ou Python avec des règles ordonnées, claires, probablement plus compréhensibles qu'une série de blocs access dans readers.conf...
-- Julien ÉLIE
« Tant qu'il y a des marmites, il y a de l'espoir ! » (Astérix)
[En-tête "Followup-To:" positionné à fr.comp.usenet.serveurs.]
Le Lundi 15 avril 2013 à 19:18 UTC, Julien ÉLIE écrivait sur fr.comp.usenet.serveurs :
D'ailleurs, ne serait-il finalement pas plus « facile » (ou du moins plus lisible) d'avoir dans son readers.conf un unique bloc auth qui utilise la directive python_access ou perl_access ? Les droits d'accès seraient alors générés dynamiquement par un script Perl ou Python avec des règles ordonnées, claires, probablement plus compréhensibles qu'une série de blocs access dans readers.conf...
Si le script est fournit pourquoi pas, et avec un script pour générer le fichier login/mdp ce serait encore mieux. Ceci étant, une foi la logique de ce fichier assimilée (et pour une config simple) ça va.
@+ -- On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le gouvernement ; c'est la paix sans la violence. C'est le contraire précisément de tout ce qu'on lui reproche, soit par ignorance, soit par mauvaise foi. -+- Hem Day -+-
[En-tête "Followup-To:" positionné à fr.comp.usenet.serveurs.]
Le Lundi 15 avril 2013 à 19:18 UTC, Julien ÉLIE écrivait sur
fr.comp.usenet.serveurs :
D'ailleurs, ne serait-il finalement pas plus « facile » (ou du moins
plus lisible) d'avoir dans son readers.conf un unique bloc auth qui
utilise la directive python_access ou perl_access ? Les droits d'accès
seraient alors générés dynamiquement par un script Perl ou Python avec
des règles ordonnées, claires, probablement plus compréhensibles qu'une
série de blocs access dans readers.conf...
Si le script est fournit pourquoi pas, et avec un script pour générer
le fichier login/mdp ce serait encore mieux.
Ceci étant, une foi la logique de ce fichier assimilée (et pour une
config simple) ça va.
@+
--
On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le
gouvernement ; c'est la paix sans la violence. C'est le contraire
précisément de tout ce qu'on lui reproche, soit par ignorance, soit
par mauvaise foi. -+- Hem Day -+-
[En-tête "Followup-To:" positionné à fr.comp.usenet.serveurs.]
Le Lundi 15 avril 2013 à 19:18 UTC, Julien ÉLIE écrivait sur fr.comp.usenet.serveurs :
D'ailleurs, ne serait-il finalement pas plus « facile » (ou du moins plus lisible) d'avoir dans son readers.conf un unique bloc auth qui utilise la directive python_access ou perl_access ? Les droits d'accès seraient alors générés dynamiquement par un script Perl ou Python avec des règles ordonnées, claires, probablement plus compréhensibles qu'une série de blocs access dans readers.conf...
Si le script est fournit pourquoi pas, et avec un script pour générer le fichier login/mdp ce serait encore mieux. Ceci étant, une foi la logique de ce fichier assimilée (et pour une config simple) ça va.
@+ -- On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le gouvernement ; c'est la paix sans la violence. C'est le contraire précisément de tout ce qu'on lui reproche, soit par ignorance, soit par mauvaise foi. -+- Hem Day -+-
