Je te propose:
1) D'ajouter une route spécifique sur chaque client (via le serveur DHCP) qui indique que pour atteindre @IP_Publique (celle du domaine), il faudra passer par la machine 192.168.0.1.
A cela, il faut ajouter une interface alias (plutôt sur lo0 que sur eth0) portant l'@IP_Publique sur le serveur 192.168.0.1.
Cela redirigera tous les flux en interne à destination de l'@IP_Publique sur cette machine ce qui n'est pas forcément ce que tu souhaites :s.
2) De gérer un DNS privé dans lequel les noms ont pour résolution la ou les machines à l'intérieur.
Ainsi, vu de l'internet:
www -> @IP_Publique
et vu de l'intranet (interne à ton réseau):
www -> 192.168.0.1 (voir le nom de la machine, car DNS connait les alias via CNAME)
Le coût est principalement pour la gestion de plusieurs fichiers de zones et de plusieurs vues dans le DNS.
C'est ce type de solution que j'utilise chez moi avec notamment un petit truc sioux: mondomaine.tld (vue internet) <-> mondomaine.local (vue locale). Cela facilite la gestion en séparant les services pour l'internet et pour l'intranet.
Pas d'idée sur le pourquoi ça ne marche pas :( !
Peut-être qu'avec le fichier named.conf et encore.
Juste une petite remarque, j'utiliserais bien une autre syntaxe dans la déclaration de zone:
$ORIGIN domain.tld. @ IN SOA dns-auth.domain.tld. email.domain.tld. ( ...
Par contre, il y a des outils pour tester le DNS comme:
¤ [http://www.zonecheck.fr/] ZoneCheck qui existe en version téléchargeable pour Linux :-)
¤ [http://www.dnsreport.com/] DNS Report qui produit un rapport décrivant l'ensemble des tests réalisés avec leur statut commenté :-)
¤ |http://www.dnsstuff.com/] DNS Stuff - le couteau suisse DNS ? (au moins, un des miens)
Si tel est le cas, alors je suggèrerais bien Request Tracker [http://bestpractical.com/rt/] parce qu'il me plait bien (non, ce n'est pas un troll ^__^ !)
Bonne chance !
Cdlt,
PS: Mais en y repensant bien, c'est plutôt un GroupWare qu'il faudrait :-)
(eGroupWare, phpGroupWare, ...)
Mon conseil: suivre l'une des solutions proposées (LTSP, Debian Netboot, ...) et à priori mieux documentées ^__^
Après, si tu optes pour un disque dur sur chaque poste, j'aurais opté pour y installer une (mini-)distrib (Suggestion: une debian "nue" + swap + Support NFS Kernel / User ? + Quelques outils) et le fonctionnement sera alors identique à un autre Linux sauf que certains montages seront NFS (/usr/local, /opt, éventuellement /usr car les packages s'installent souvent là par défaut).
Pour le /dev/console, je connais (expérience perso) un /dev avec seulement MAKEDEV dedans :D
Forcément, ça marche moins bien.
Sinon, pas de problèmes particuliers à priori pour ce type d'installation.
Pour information, il y a les approches initrd & co pour avoir un mini disque en RAM au moment du chargement du noyau qui fournit un certain nombre de modules noyau, ...
Voili, voilà.
Bon Amusement (sisi, après, quand / si ça marche...)
Ooops ! Désolé, je croyais que le serveur était sous controle et de préférence sous Linux (ou équivalent).
Je donnais un exemple basé sur proftpd car j'avais une syntaxe sous la main pour faire des ACLs (tiens, j'avais pas fait attention, mais la balise fermant a disparue :!).
Pour sudo, il est alors possible d'écrire un petit wrapper en shell ou équivalent:
===
ftpput.sh fichier1, ..., fichierN ftp://serveur/path
===
et là, sudo limite l'utilisateur à prendre du pouvoir (par exemple, lire le .netrc qui contient login/password, ou autre) que pour lancer le wrapper.
Je ne connaissais pas "LTSP" (merci pour l'info ^__^).
Pour le retour d'expérience, j'ai vécu (juste vécu) différents environnements de type NFS (université & école) avec un partage ne concernant que les programmes (/usr/local /opt ...) et les répertoires persos (/home & co).
A priori, ce serait déjà pas mal d'avoir sur chaque poste, un disque dur (même de petite capacité) pour y stocker:
¤ swap (sauf s'il est possible de mettre plus de RAM :D)
¤ /boot /etc & /dev pour le démarrage local et la configuration (minimale si nécessaire) de la machine
¤ [facultatif] /bin /sbin & co pour avoir quelques exécutable en cas de problème.
=> Cela peut réduire le trafic réseau notamment pour la swap.
Après, si les cartes réseaux sont PXE (et Wake on Lan), pourquoi pas envisager le reste à distance.
Le switch c'est un plus, mais rien n'empêche de tester avec le hub (qui existe déjà <=> moins de couts) et évaluer s'il y a des points blocants (charge du serveur NFS, redondance, ... qui seront +chères) !
Un des points négatifs de mes quelques expériences est la latence des serveurs NFS. Par exemple: quand tout le monde ouvre/clôture sa session (bcp de demandes lecture/écriture parallèles, ...) à heure identique. C'est assez dépendant du comportement de chaque environnement, malheureusement.
Effectivement, la méthode find se base sur les dates systèmes (creation: ctime, modification:mtime, acces:atime & leur version en *min), donc le nom de fichier n'est pas pris en compte.
Pour contourner ce problème, on pourrait (mais dans le cas présent ce n'est pas nécessaire) compléter le script de backup par la commande "touch" sur chaque fichier/répertoire sauvegardé.
Cela permet de forcer la mse à jour des dates d'accès et de modification à celle du lancement de la commande :-)
C'est sioux, mais je l'utilise pour les snapshots via rsync (merci à ceux qui ont documenté cette fonctionnalité ^__^). Dans ce cas, je limite l'action au seul répertoire au format AAAAMMJJ et je limite donc le find à une profondeur de 1 par rapport au répertoire de snapshots... (ca devient hors-sujet, désolé).
Je te suggère plutôt de limiter les fonctions côté serveur FTP.
Il doit exister des ACL sur les commandes pour des utilisateurs (il y a au moins le serveur proftpd qui le fait, et j'ai bien dit au moins ^__^).
Par exemple (juste pour avoir un ordre d'idée, sans réelle application telle-que :P):
===
# On bloque tout
<Limit ALL>
DenyALL
# La commande PUT est autorisée pour xxxx
<Limit PUT>
Allow xxxx
===
La commande sudo est, à mon humble avis, un moyen d'obtenir les privillèges que l'on a pas dans le cas normal (user devient super-user). Eventuellement, il peut être intéressant de limiter les commandes disponibles pour l'utilisateur qui bénéficie de cette "dérogation" de privillèges.
Par contre, dès que ça touche au service lui-même (ici c'est le serveur FTP), il vaut mieux agir, si c'est possible, de son côté (FTP).
Pourquoi ne pas utiliser la commande find avec comme conditions:
¤ catégorie: répertoire
¤ date: ancienne de 4 jours (pour l'exemple)
A cela, un pipe ("|") xargs pour une suppression (rm --recursive --force).
Petite illustration:
===
find /backups -type d -mtime +4 | xargs rm --recursive --force
===
supprime tous les répertoires de /backups vieux de +4 jours.
Attention, s'il y a des sous-répertoires, il faut affiner la recherche du find avec des conditions sur la profondeur de recherche (min/max depth)
=> Voir alors la doc de la commande find pour leur utilisation.
Bon courage !
Cdlt,
PS: Ne pas hésiter à tester la première partie de la commande (find) pour voir les résultats et confirmer que cela correspond à ce qui doit être supprimé ^__^
Malheureusement, je ne pourrais pas être d'une aide quelconque :(
Soit l'une des deux applications (eGW, serveur IMAP) n'est pas suffisament tunée (quelques paramétrages ici & là pour l'utiliser pleinement), soit eGW a un comportement "aggressif" (ou peut-être voulu fonctionnellement) en intérogeant le serveur IMAP sur l'ensemble des informations.
Selon ce que tu expliques à la fin du message, eGW rappatrierait des informations (peut-être histoire de faire du pre-fetch :P) sans qu'elles aient été sollicitées. Il devrait y avoir un paramètre de configuration dans le soft pour désactiver cette "fonctionnalité".
Toutefois, il y a au moins un point important: le serveur IMAP est un point sensible car il ne filtre (limite) pas son service en vue d'assurer une qualité. Autrement dit, il peut être plus judicieux de refuser de servir pour éviter le risque de "planter" et donc de mal rendre le service ^__^.
J'ai trouvé un document d'installation sur lea-linux [1], mais je n'y vois pas de problème lié à l'application webmail->imap.
Peut-être pourrais tu essayer la mailing-list du projet à condition que tu puisses répondre à leurs questions (une petite synchro avec l'admin du site serait bienvenue).
Je ne connais pas eGroupWare et je ne pourrais pas t'aider sur son paramétrage (ni sur son impact avec Apache).
Par contre, ce qui me titille, c'est la partie IMAP.
C'est un protocole de récupération de mail (une alternative au POP2/3) et j'aimerais bien savoir:
¤ Quel est le serveur utilisé ? (est-ce inclut dans eGW ou est-ce un soft à part genre imapd-machin-bidule-super-secure ?)
¤ Y a-t-il des logs applicatifs (que j'espère plus parlant) sur cette partie qui relaterait un fonctionnement anormal de IMAP ?!?
¤ Qu'entends tu par "écrouler" ? Est-ce une mort du processus (avec peut-être un core dump), est-ce un service dégradé (limitation forte des réponse), ... ?
Enfin, pour enlever le doute, n'y aurait-il pas un problème de taille disque ou quota ?!? (c'est vraiment par pure paranoia :P)
Pourrais tu compléter ta demande avec les infos suivantes:
¤ Un état du montage du disque /dev/sda5
===
mount | grep sda5
===
¤ Un listing détaillé du ou des répertoires incriminés et en particulier du répertoire "/media/rack":
=== Pour un répertoire
ls -ld /media/rack/chemin/pour/un/repertoire/bizarre
===
=== Pour un fichier
ls -l /media/rack/chemin/pour/un/fichier/bizarre
===
¤ L'utilisateur qui effectue les manipulations non préfixées par sudo (normalement, avec sudo c'est root ^__^)
===
id
===
¤ Tout autre info qui pourrait éclairer un peu plus ;-)
Merci d'avance !
Cdlt,
PS: Le seul cas particulier que je connais serait le répertoire lost+found qui n'est pas de bon augure.
PS2: Sinon, ext2 supporte-il les ACLs ?!? (j'en apprendrai tous les jours)
Je ne connais pas assez bien *carp pour pouvoir répondre à cette question.
Le mieux est de tester "en vrai" ce qui se passe lors d'une coupure/bascule et de mesurer les indicateurs qui t'intéresse: temps d'indisponibilité, temps de convergence si elle fonctionne, ...
Est-ce que le document
[http://linuxtips.castres-wireless.org/article.php3?id_articl(...)]
ne pourrait pas t'aider ?
En effet, il s'agit d'une procédure assez détaillée pour une RedHat Entreprise 4, mais les points sont transposables aux autres distributions Linux.
Bonne Lecture & Bon Courage !
Cdlt,
PS: J'ai vérifié sur mes OpenBSDs, carp utilise de lui-même une adresse MAC Ethernet spéciale (format 00:00:5e:00:01:<CARP_ID>)
Seulement, la consigne était "pas BSD" ;-)
La configuration du mail pour les messages de l'extérieur ne m'inspire pas :'(
L'association entre les domaines extérieurs et le domaine local m'a l'air partielle et il est possible de spécifier un USER local en plus pour affiner la configuration. Autrement dit, tu pourrais faire une association du type
===
tonton.labidouille@tlabidouille.dyndns.org tonton_labidouille_wanadoo
===
Toutefois, je peux juste confirmer le point suivant: tant que l'utilisateur propriétaire du .procmailrc recevra et (merci procmail) triera les messages, ces derniers héritent en général (sisi, il y a bien des cas particuliers :P) du même propriétaire. Autrement dit, je suppose que l'utilisateur qui reçoit les mails de l'extérieur est root et qu'il dispose du fichier .procmailrc (dont tu as donné un extrait) associant les adresses extérieures aux dossiers locaux.
Il ne te reste qu'à potasser un peu plus sendmail (ou autre) et à lui faire faire ce dont tu as besoin :-)
Bon courage !
Cdlt,
PS: En me relisant, je me demande s'il n'est pas possible de rediriger les messages aux utilisateurs qui eux effectueront le trie.
Dans le procmailrc, il suffit de renvoyer le message à l'utilisateur local et celui-ci pourra dans son procmailrc faire le trie adéquat....
PS2: Et si ... (non, je m'auto censure parce que suggérer de se mettre root n'est pas une solution, mais un palliatif ^__^)
PSn: Mouais, après une n-ième relecture, bof :s
Vraiment pas d'idée :( !
Merci pour toutes ces explications (j'étais finalement pas si loin ^__^).
En fait, j'ai une piste qui dépend des pré-requis suivants:
¤ chaque compte configuré dans fetchmail doit appartenir à un seul utilisateur. Cela n'empêche pas d'avoir plusieurs comptes pour un même utilisateur, mais les mails d'une boite auront toujours le même destinataire local.
¤ sendmail peut délivrer (fonction MDA) les mails à chaque user et non qu'à l'utilisateur ROOT (pas "très courant" le cas des mails de l'extérieur qui sont redirigés qu'à root !);
Alors, dans la configuration de fetchmail, il est possible de lui indiquer qu'un compte est localement associé à un utilisateur. En voici une syntaxe [1]:
===
poll pop.provider.com with proto POP3
user 'utilisateur1' there with password 'passe' is utilisateur1 here options fetchall
user 'utilisateur2' there with password 'passe' is utilisateur2 here options fetchall
===
Dans cet exemple, sur le pop.provider.com, fetchmail récupère les mails du compte "utilisateur1" et les soumet à sendmail pour l'utilisateur local 'utilisateur1' (le nom n'est pas lié au compte, mais là c'est un exemple, donc simplifié :P), de même le compte "utilisateur2" à pour équivalent local 'utilisateur2'.
Charge à chacun des utilisateurs de faire le tri avec leur outil favori (même si ma préférence va à procmail :P)
Reste que cette piste va à l'encontre de la solution actuelle car elle empêche la gestion du mail de manière à priori "centralisée" (ie via un seul user root/admin ?) et qui surement permet de faire un ménage efficace des virus, spam et autres.
Sinon, en gardant la solution actuelle, il est possible (pardon procmail pour ce que je vais évoquer) de rajouter des commandes à procmail pour qu'il les exécute à chaque message. Il s'agit de "faire faire" à procmail ce qui est fait manuellement à l'aide de "variables fictives". Par exemple:
===
...
# Avant les règles de filtrages SANS GARANTIE SUR LA SYNTAXE
PARDON=$(chown -R user /Disk0/Mail/Electro_bidouille_wanadoo)
PARDON=$(chown -R user /Disk0/Mail/tonton_labidouille_free)
# etc...
# Règle de filtrages
...
===
Bon courage !
Cdlt,
PS: Je nierai avoir eu connaissance de la solution "rajouter de commandes" ^__^
J'aimerais avoir plus d'informations sur le fonctionnement du "trio":
J'ai l'impression (et je peux me tromper) qu'il n'y a qu'un fetchmail qui récupère les mails de tous les utilisateurs (donc un fichier de type ".fetchmailrc").
Puis, fetchmail transmet à sendmail ce qu'il a récupéré :
1) à destination d'un compte qui aurait un procmail global de tri;
2) à destination des différentes personnes et chacune dispose de son procmail pour le tri;
3) autre ?
N'y aurait-il pas de scripts portant le nom (au choix):
¤ ifdown/ifup qui permet de "couper"/"initialiser+démarrer" une interface. Si c'est le cas, il faudrait essayer:
=== pour une interface eth0
ifdown eth0
ifup eth0
===
¤ /etc/init.d/network* (peut-être networking) qui est LE script pour initialiser toutes les interfaces réseaux (y compris la loopback ?). Si c'est le cas, il faudrait essayer:
=== (supposons que le script s'appelle networking)
/etc/init.d/networking restart
===
NOTE: Toutes ces manipulations sont à réaliser EN LOCAL SUR LA MACHINE (ie pas en passant par le réseau) :)
Voici quelques éléments complémentaires pour éclairer les précédents messages:
1) Sous un noyau 2.4.x, Debian propose de gérer les modules dans 2 fichiers:
a) /etc/modules: ce fichier liste les modules chargés de manière "statique"; autrement dit même s'ils ne sont pas utilisés;
Pour le modifier, il faut utiliser son éditeur favori et mettre les mains dedans;
Dans le cas présent, cela correspond à l'ajout d'une ligne "ipw2200".
b) /etc/modules.conf: ce fichier liste les modules chargés "dynamiquement"; autrement dit, qu'en cas de besoin
Pour le modifier, Debian propose la commande update-modules qui fonctionne sur des fichiers créés dans le répertoire /etc/modutils.
Dans le cas présent, cela correspondrait à créer un fichier /etc/modutils/eth1 contenant "alias eth1 ipw2200" (ou équivalent - à adapter) et à lancer la commande "update-modules"
2) Sous un noyau 2.6.x, Debian proposer une autre manière pour gérer les modules dans le répertoire: /etc/modprobe.d
Pour cela, il faut consulter la documentation du paquet "module-init-tools".
J'espère avoir pu rendre (un peu) moins obscure la gestion des modules :-)
Est-ce qu'il n'y aurait pas des pilotes à charger avant de lancer la configuration réseau (un pour la carte eth et/ou un autre pour la wifi) ?
Pour cela, il faudrait vérifier la liste des modules chargés au démarrage par le système (/etc/modules).
Ce fichier est utilisé par (/etc/init.d/modutis ou équivalent) juste après la phase du boot et avant de passer la main aux scripts RC comme /etc/init.d/networking.
Bon courage !
Cdlt,
PS: un petit lsmod dans un terminal et dmesg | grep eth pour savoir si ca correspondrait bien.
Enfin, classique mais sûr, un petit ls -l /etc/modutils/eth*
Juste pour ajouter que find peut travailler sur différents niveaux de profondeur (voir la page man/info).
Donc, soit find parcourt un répertoire et tous ses sous-répertoires (cas par défaut), soit tu lui fixes des limites ;-)
Il se peut aussi que quelques process aient encore en mémoire l'ancien nom (je pense en particulier à syslog, à quelques daemon, ...).
Pour t'en assurer, un petit tour dans /var/log et une commande tail sur quelques fichiers devraient confirmer la bonne prise en compte du nom.
Si certains sont récalcitrants, le SIGHUP (kill -s HUP <pid>) pourrait être suffisant, mais d'autres auront besoin de plus (cycle stop/start via invoke-rc.d <nom_service> restart).
Effectivement, j'y avais pas pensé, mais le script de démarrage réseau de la redhat parcourt bien tous les fichiers ifcfg-*
Par contre, je suis surpris du fait que ifconfig n'affiche pas ce type d'information (qui ressemble à un alias IP)...
... personne n'aurait une idée pour avoir toutes les interfaces ?
J'aurais bien utilisé la commande "netstat" en mode statistiques d'interface (option -i) mais sans aucune garantie !
# Routage ? DNS Privé ?
Posté par Steve Azriel . En réponse au message Carte réseau - ifconfig & alias. Évalué à 2.
Je te propose:
1) D'ajouter une route spécifique sur chaque client (via le serveur DHCP) qui indique que pour atteindre @IP_Publique (celle du domaine), il faudra passer par la machine 192.168.0.1.
A cela, il faut ajouter une interface alias (plutôt sur lo0 que sur eth0) portant l'@IP_Publique sur le serveur 192.168.0.1.
Cela redirigera tous les flux en interne à destination de l'@IP_Publique sur cette machine ce qui n'est pas forcément ce que tu souhaites :s.
2) De gérer un DNS privé dans lequel les noms ont pour résolution la ou les machines à l'intérieur.
Ainsi, vu de l'internet:
www -> @IP_Publique
et vu de l'intranet (interne à ton réseau):
www -> 192.168.0.1 (voir le nom de la machine, car DNS connait les alias via CNAME)
Le coût est principalement pour la gestion de plusieurs fichiers de zones et de plusieurs vues dans le DNS.
C'est ce type de solution que j'utilise chez moi avec notamment un petit truc sioux: mondomaine.tld (vue internet) <-> mondomaine.local (vue locale). Cela facilite la gestion en séparant les services pour l'internet et pour l'intranet.
Bon courage !
Cdlt,
# Pas de solution, mais quelques pistes...
Posté par Steve Azriel . En réponse au message Problème de dns. Évalué à 2.
Pas d'idée sur le pourquoi ça ne marche pas :( !
Peut-être qu'avec le fichier named.conf et encore.
Juste une petite remarque, j'utiliserais bien une autre syntaxe dans la déclaration de zone:
Par contre, il y a des outils pour tester le DNS comme:
¤ [http://www.zonecheck.fr/] ZoneCheck qui existe en version téléchargeable pour Linux :-)
¤ [http://www.dnsreport.com/] DNS Report qui produit un rapport décrivant l'ensemble des tests réalisés avec leur statut commenté :-)
¤ |http://www.dnsstuff.com/] DNS Stuff - le couteau suisse DNS ? (au moins, un des miens)
Bon courage !
Cdlt,
PS: Ah oui, de la doc
¤ [http://doc.fedora-fr.org/Configuration_d'un_serveur_DNS] avec de nombreux pointeurs en bas ^__^
¤ [http://lea-linux.org/cached/index/Reseau-index.html] Lea-Linux
PS2: N'y aurait-il pas des ACL à mettre dans le named.conf pour ?!?
# Request Tracker
Posté par Steve Azriel . En réponse au message Gestion de taches .... Évalué à 1.
Si ce n'est pas un GroupWare, c'est peut-être un "Tracking System".
Pour cela, il y a WikiPedia et leur comparatif (en Anglais)
[http://en.wikipedia.org/wiki/Comparison_of_ticket-tracking_s(...)]
Si tel est le cas, alors je suggèrerais bien Request Tracker [http://bestpractical.com/rt/] parce qu'il me plait bien (non, ce n'est pas un troll ^__^ !)
Bonne chance !
Cdlt,
PS: Mais en y repensant bien, c'est plutôt un GroupWare qu'il faudrait :-)
(eGroupWare, phpGroupWare, ...)
[^] # Re: retirer une chaîne de caractère à la fin du nom de fichier
Posté par Steve Azriel . En réponse au message retirer une chaîne de caractère à la fin du nom de fichier. Évalué à 1.
Cela devrait mieux fonctionner avec "&max=.*" dans la commande sed:
Ainsi:
deviendrait
Bon courage !
Cdlt,
PS: Pour faire un nettoyage du nom du fichier par rapport au premier '&' trouvé, sed est encore un bon camarade:
A tester avant toute intégration :-)
[^] # Re: Quelques petites infos :-)
Posté par Steve Azriel . En réponse au message Boot de plusieurs clients sur un serveur NFS. Évalué à 1.
Mon conseil: suivre l'une des solutions proposées (LTSP, Debian Netboot, ...) et à priori mieux documentées ^__^
Après, si tu optes pour un disque dur sur chaque poste, j'aurais opté pour y installer une (mini-)distrib (Suggestion: une debian "nue" + swap + Support NFS Kernel / User ? + Quelques outils) et le fonctionnement sera alors identique à un autre Linux sauf que certains montages seront NFS (/usr/local, /opt, éventuellement /usr car les packages s'installent souvent là par défaut).
Pour le /dev/console, je connais (expérience perso) un /dev avec seulement MAKEDEV dedans :D
Forcément, ça marche moins bien.
Sinon, pas de problèmes particuliers à priori pour ce type d'installation.
Pour information, il y a les approches initrd & co pour avoir un mini disque en RAM au moment du chargement du noyau qui fournit un certain nombre de modules noyau, ...
Voili, voilà.
Bon Amusement (sisi, après, quand / si ça marche...)
Cdlt,
[^] # Re: Pour ne pas modifier la configuration du serveur FTP ?
Posté par Steve Azriel . En réponse au message limitations sudo. Évalué à 1.
Ooops ! Désolé, je croyais que le serveur était sous controle et de préférence sous Linux (ou équivalent).
Je donnais un exemple basé sur proftpd car j'avais une syntaxe sous la main pour faire des ACLs (tiens, j'avais pas fait attention, mais la balise fermant a disparue :!).
Pour sudo, il est alors possible d'écrire un petit wrapper en shell ou équivalent:
===
ftpput.sh fichier1, ..., fichierN ftp://serveur/path
===
et là, sudo limite l'utilisateur à prendre du pouvoir (par exemple, lire le .netrc qui contient login/password, ou autre) que pour lancer le wrapper.
Bon courage !
Cdlt,
# Quelques petites infos :-)
Posté par Steve Azriel . En réponse au message Boot de plusieurs clients sur un serveur NFS. Évalué à 1.
Je ne connaissais pas "LTSP" (merci pour l'info ^__^).
Pour le retour d'expérience, j'ai vécu (juste vécu) différents environnements de type NFS (université & école) avec un partage ne concernant que les programmes (/usr/local /opt ...) et les répertoires persos (/home & co).
A priori, ce serait déjà pas mal d'avoir sur chaque poste, un disque dur (même de petite capacité) pour y stocker:
¤ swap (sauf s'il est possible de mettre plus de RAM :D)
¤ /boot /etc & /dev pour le démarrage local et la configuration (minimale si nécessaire) de la machine
¤ [facultatif] /bin /sbin & co pour avoir quelques exécutable en cas de problème.
=> Cela peut réduire le trafic réseau notamment pour la swap.
Après, si les cartes réseaux sont PXE (et Wake on Lan), pourquoi pas envisager le reste à distance.
Le switch c'est un plus, mais rien n'empêche de tester avec le hub (qui existe déjà <=> moins de couts) et évaluer s'il y a des points blocants (charge du serveur NFS, redondance, ... qui seront +chères) !
Un des points négatifs de mes quelques expériences est la latence des serveurs NFS. Par exemple: quand tout le monde ouvre/clôture sa session (bcp de demandes lecture/écriture parallèles, ...) à heure identique. C'est assez dépendant du comportement de chaque environnement, malheureusement.
Enfin, pour rendre ce message utile, je rajoute quelques petites références:
* [http://www.gentoo.org/doc/fr/diskless-howto.xml] en Français (pour la version en Anglais, changez /fr/ -> /en/ dans l'URL)
* [http://www.freeos.com/articles/2444/] en Anglais avec ses pointeurs un peu anciens, mais toujours intéressants :-)
* [http://www.cs.cmu.edu/~dlr/debian_netboot_v1.2.pdf] en Anglais
Bon courage & Bonne Année !
Cdlt,
[^] # Re: ou alors date +%s
Posté par Steve Azriel . En réponse au message script de backup avec suppression de sauvegardes antérieures à n jours. Évalué à 1.
Effectivement, la méthode find se base sur les dates systèmes (creation: ctime, modification:mtime, acces:atime & leur version en *min), donc le nom de fichier n'est pas pris en compte.
Pour contourner ce problème, on pourrait (mais dans le cas présent ce n'est pas nécessaire) compléter le script de backup par la commande "touch" sur chaque fichier/répertoire sauvegardé.
Cela permet de forcer la mse à jour des dates d'accès et de modification à celle du lancement de la commande :-)
C'est sioux, mais je l'utilise pour les snapshots via rsync (merci à ceux qui ont documenté cette fonctionnalité ^__^). Dans ce cas, je limite l'action au seul répertoire au format AAAAMMJJ et je limite donc le find à une profondeur de 1 par rapport au répertoire de snapshots... (ca devient hors-sujet, désolé).
Voili voilà !
Cdlt,
# Pour ne pas modifier la configuration du serveur FTP ?
Posté par Steve Azriel . En réponse au message limitations sudo. Évalué à 1.
Je te suggère plutôt de limiter les fonctions côté serveur FTP.
Il doit exister des ACL sur les commandes pour des utilisateurs (il y a au moins le serveur proftpd qui le fait, et j'ai bien dit au moins ^__^).
Par exemple (juste pour avoir un ordre d'idée, sans réelle application telle-que :P):
===
# On bloque tout
<Limit ALL>
DenyALL
# La commande PUT est autorisée pour xxxx
<Limit PUT>
Allow xxxx
===
La commande sudo est, à mon humble avis, un moyen d'obtenir les privillèges que l'on a pas dans le cas normal (user devient super-user). Eventuellement, il peut être intéressant de limiter les commandes disponibles pour l'utilisateur qui bénéficie de cette "dérogation" de privillèges.
Par contre, dès que ça touche au service lui-même (ici c'est le serveur FTP), il vaut mieux agir, si c'est possible, de son côté (FTP).
Bon courage !
Cdlt,
# find | xargs ?
Posté par Steve Azriel . En réponse au message script de backup avec suppression de sauvegardes antérieures à n jours. Évalué à 2.
Pourquoi ne pas utiliser la commande find avec comme conditions:
¤ catégorie: répertoire
¤ date: ancienne de 4 jours (pour l'exemple)
A cela, un pipe ("|") xargs pour une suppression (rm --recursive --force).
Petite illustration:
===
find /backups -type d -mtime +4 | xargs rm --recursive --force
===
supprime tous les répertoires de /backups vieux de +4 jours.
Attention, s'il y a des sous-répertoires, il faut affiner la recherche du find avec des conditions sur la profondeur de recherche (min/max depth)
=> Voir alors la doc de la commande find pour leur utilisation.
Bon courage !
Cdlt,
PS: Ne pas hésiter à tester la première partie de la commande (find) pour voir les résultats et confirmer que cela correspond à ce qui doit être supprimé ^__^
[^] # Re: [complément d'info] problème imap
Posté par Steve Azriel . En réponse au message problème imap. Évalué à 1.
Malheureusement, je ne pourrais pas être d'une aide quelconque :(
Soit l'une des deux applications (eGW, serveur IMAP) n'est pas suffisament tunée (quelques paramétrages ici & là pour l'utiliser pleinement), soit eGW a un comportement "aggressif" (ou peut-être voulu fonctionnellement) en intérogeant le serveur IMAP sur l'ensemble des informations.
Selon ce que tu expliques à la fin du message, eGW rappatrierait des informations (peut-être histoire de faire du pre-fetch :P) sans qu'elles aient été sollicitées. Il devrait y avoir un paramètre de configuration dans le soft pour désactiver cette "fonctionnalité".
Toutefois, il y a au moins un point important: le serveur IMAP est un point sensible car il ne filtre (limite) pas son service en vue d'assurer une qualité. Autrement dit, il peut être plus judicieux de refuser de servir pour éviter le risque de "planter" et donc de mal rendre le service ^__^.
J'ai trouvé un document d'installation sur lea-linux [1], mais je n'y vois pas de problème lié à l'application webmail->imap.
Peut-être pourrais tu essayer la mailing-list du projet à condition que tu puisses répondre à leurs questions (une petite synchro avec l'admin du site serait bienvenue).
Bon courage !
Cdlt,
Ref:
[1] [http://www.lea-linux.org/cached/index/Leapro-pro_appli-egrou(...)]
[^] # Re: [complément d'info] problème imap
Posté par Steve Azriel . En réponse au message problème imap. Évalué à 1.
Je ne connais pas eGroupWare et je ne pourrais pas t'aider sur son paramétrage (ni sur son impact avec Apache).
Par contre, ce qui me titille, c'est la partie IMAP.
C'est un protocole de récupération de mail (une alternative au POP2/3) et j'aimerais bien savoir:
¤ Quel est le serveur utilisé ? (est-ce inclut dans eGW ou est-ce un soft à part genre imapd-machin-bidule-super-secure ?)
¤ Y a-t-il des logs applicatifs (que j'espère plus parlant) sur cette partie qui relaterait un fonctionnement anormal de IMAP ?!?
¤ Qu'entends tu par "écrouler" ? Est-ce une mort du processus (avec peut-être un core dump), est-ce un service dégradé (limitation forte des réponse), ... ?
Enfin, pour enlever le doute, n'y aurait-il pas un problème de taille disque ou quota ?!? (c'est vraiment par pure paranoia :P)
Bon courage !
Cdlt,
PS: Sinon, pour Apache, j'ai quelques pointeurs sur le Web:
[http://httpd.apache.org/docs/2.2/fr/vhosts/details.html]
[http://www.illiweb.com/manuel/Apache_1.3_VF/mod/core.html#na(...)]
[http://www.linux-sottises.net/serveurs_virtuels.php]
A priori, rien de bien grave :-)
# Des infos svp :-)
Posté par Steve Azriel . En réponse au message Fichiers et repertoires verouillées. Évalué à 1.
J'ai pas vraiment tout compris :S
Pourrais tu compléter ta demande avec les infos suivantes:
¤ Un état du montage du disque /dev/sda5
===
mount | grep sda5
===
¤ Un listing détaillé du ou des répertoires incriminés et en particulier du répertoire "/media/rack":
=== Pour un répertoire
ls -ld /media/rack/chemin/pour/un/repertoire/bizarre
===
=== Pour un fichier
ls -l /media/rack/chemin/pour/un/fichier/bizarre
===
¤ L'utilisateur qui effectue les manipulations non préfixées par sudo (normalement, avec sudo c'est root ^__^)
===
id
===
¤ Tout autre info qui pourrait éclairer un peu plus ;-)
Merci d'avance !
Cdlt,
PS: Le seul cas particulier que je connais serait le répertoire lost+found qui n'est pas de bon augure.
PS2: Sinon, ext2 supporte-il les ACLs ?!? (j'en apprendrai tous les jours)
[^] # Re: Suggestion: Un article du Net
Posté par Steve Azriel . En réponse au message Ucarp et adresse MAC. Évalué à 1.
Je ne connais pas assez bien *carp pour pouvoir répondre à cette question.
Le mieux est de tester "en vrai" ce qui se passe lors d'une coupure/bascule et de mesurer les indicateurs qui t'intéresse: temps d'indisponibilité, temps de convergence si elle fonctionne, ...
Bon courage !
Cdlt,
# Suggestion: Un article du Net
Posté par Steve Azriel . En réponse au message Ucarp et adresse MAC. Évalué à 1.
Est-ce que le document
[http://linuxtips.castres-wireless.org/article.php3?id_articl(...)]
ne pourrait pas t'aider ?
En effet, il s'agit d'une procédure assez détaillée pour une RedHat Entreprise 4, mais les points sont transposables aux autres distributions Linux.
Bonne Lecture & Bon Courage !
Cdlt,
PS: J'ai vérifié sur mes OpenBSDs, carp utilise de lui-même une adresse MAC Ethernet spéciale (format 00:00:5e:00:01:<CARP_ID>)
Seulement, la consigne était "pas BSD" ;-)
[^] # Re: Pas d'idée :(
Posté par Steve Azriel . En réponse au message fetchmail + sendmail + procmail. Évalué à 1.
La configuration du mail pour les messages de l'extérieur ne m'inspire pas :'(
L'association entre les domaines extérieurs et le domaine local m'a l'air partielle et il est possible de spécifier un USER local en plus pour affiner la configuration. Autrement dit, tu pourrais faire une association du type
===
tonton.labidouille@tlabidouille.dyndns.org tonton_labidouille_wanadoo
===
Toutefois, je peux juste confirmer le point suivant: tant que l'utilisateur propriétaire du .procmailrc recevra et (merci procmail) triera les messages, ces derniers héritent en général (sisi, il y a bien des cas particuliers :P) du même propriétaire. Autrement dit, je suppose que l'utilisateur qui reçoit les mails de l'extérieur est root et qu'il dispose du fichier .procmailrc (dont tu as donné un extrait) associant les adresses extérieures aux dossiers locaux.
Il ne te reste qu'à potasser un peu plus sendmail (ou autre) et à lui faire faire ce dont tu as besoin :-)
Bon courage !
Cdlt,
PS: En me relisant, je me demande s'il n'est pas possible de rediriger les messages aux utilisateurs qui eux effectueront le trie.
Dans le procmailrc, il suffit de renvoyer le message à l'utilisateur local et celui-ci pourra dans son procmailrc faire le trie adéquat....
PS2: Et si ... (non, je m'auto censure parce que suggérer de se mettre root n'est pas une solution, mais un palliatif ^__^)
PSn: Mouais, après une n-ième relecture, bof :s
Vraiment pas d'idée :( !
[^] # Une piste...
Posté par Steve Azriel . En réponse au message fetchmail + sendmail + procmail. Évalué à 1.
Merci pour toutes ces explications (j'étais finalement pas si loin ^__^).
En fait, j'ai une piste qui dépend des pré-requis suivants:
¤ chaque compte configuré dans fetchmail doit appartenir à un seul utilisateur. Cela n'empêche pas d'avoir plusieurs comptes pour un même utilisateur, mais les mails d'une boite auront toujours le même destinataire local.
¤ sendmail peut délivrer (fonction MDA) les mails à chaque user et non qu'à l'utilisateur ROOT (pas "très courant" le cas des mails de l'extérieur qui sont redirigés qu'à root !);
Alors, dans la configuration de fetchmail, il est possible de lui indiquer qu'un compte est localement associé à un utilisateur. En voici une syntaxe [1]:
===
poll pop.provider.com with proto POP3
user 'utilisateur1' there with password 'passe' is utilisateur1 here options fetchall
user 'utilisateur2' there with password 'passe' is utilisateur2 here options fetchall
===
Dans cet exemple, sur le pop.provider.com, fetchmail récupère les mails du compte "utilisateur1" et les soumet à sendmail pour l'utilisateur local 'utilisateur1' (le nom n'est pas lié au compte, mais là c'est un exemple, donc simplifié :P), de même le compte "utilisateur2" à pour équivalent local 'utilisateur2'.
Charge à chacun des utilisateurs de faire le tri avec leur outil favori (même si ma préférence va à procmail :P)
Reste que cette piste va à l'encontre de la solution actuelle car elle empêche la gestion du mail de manière à priori "centralisée" (ie via un seul user root/admin ?) et qui surement permet de faire un ménage efficace des virus, spam et autres.
Sinon, en gardant la solution actuelle, il est possible (pardon procmail pour ce que je vais évoquer) de rajouter des commandes à procmail pour qu'il les exécute à chaque message. Il s'agit de "faire faire" à procmail ce qui est fait manuellement à l'aide de "variables fictives". Par exemple:
===
...
# Avant les règles de filtrages SANS GARANTIE SUR LA SYNTAXE
PARDON=$(chown -R user /Disk0/Mail/Electro_bidouille_wanadoo)
PARDON=$(chown -R user /Disk0/Mail/tonton_labidouille_free)
# etc...
# Règle de filtrages
...
===
Bon courage !
Cdlt,
PS: Je nierai avoir eu connaissance de la solution "rajouter de commandes" ^__^
Ref:
1 - [http://www.linux-france.org/article/mail/serveur-mdk/config.(...)]
# Demande de précisions ...
Posté par Steve Azriel . En réponse au message fetchmail + sendmail + procmail. Évalué à 1.
J'aimerais avoir plus d'informations sur le fonctionnement du "trio":
J'ai l'impression (et je peux me tromper) qu'il n'y a qu'un fetchmail qui récupère les mails de tous les utilisateurs (donc un fichier de type ".fetchmailrc").
Puis, fetchmail transmet à sendmail ce qu'il a récupéré :
1) à destination d'un compte qui aurait un procmail global de tri;
2) à destination des différentes personnes et chacune dispose de son procmail pour le tri;
3) autre ?
Merci d'avance :)
Cdlt,
# Script ifdown/ifup ou /etc/init.d/network*
Posté par Steve Azriel . En réponse au message Problème table de routage. Évalué à 2.
N'y aurait-il pas de scripts portant le nom (au choix):
¤ ifdown/ifup qui permet de "couper"/"initialiser+démarrer" une interface. Si c'est le cas, il faudrait essayer:
=== pour une interface eth0
ifdown eth0
ifup eth0
===
¤ /etc/init.d/network* (peut-être networking) qui est LE script pour initialiser toutes les interfaces réseaux (y compris la loopback ?). Si c'est le cas, il faudrait essayer:
=== (supposons que le script s'appelle networking)
/etc/init.d/networking restart
===
NOTE: Toutes ces manipulations sont à réaliser EN LOCAL SUR LA MACHINE (ie pas en passant par le réseau) :)
Bon courage !
Cdlt,
[^] # Re: Problème de chargement de Drivers ?
Posté par Steve Azriel . En réponse au message Réseau wifi (WPA) non automatique au démarrage. Évalué à 1.
Voici quelques éléments complémentaires pour éclairer les précédents messages:
1) Sous un noyau 2.4.x, Debian propose de gérer les modules dans 2 fichiers:
a) /etc/modules: ce fichier liste les modules chargés de manière "statique"; autrement dit même s'ils ne sont pas utilisés;
Pour le modifier, il faut utiliser son éditeur favori et mettre les mains dedans;
Dans le cas présent, cela correspond à l'ajout d'une ligne "ipw2200".
b) /etc/modules.conf: ce fichier liste les modules chargés "dynamiquement"; autrement dit, qu'en cas de besoin
Pour le modifier, Debian propose la commande update-modules qui fonctionne sur des fichiers créés dans le répertoire /etc/modutils.
Dans le cas présent, cela correspondrait à créer un fichier /etc/modutils/eth1 contenant "alias eth1 ipw2200" (ou équivalent - à adapter) et à lancer la commande "update-modules"
2) Sous un noyau 2.6.x, Debian proposer une autre manière pour gérer les modules dans le répertoire: /etc/modprobe.d
Pour cela, il faut consulter la documentation du paquet "module-init-tools".
J'espère avoir pu rendre (un peu) moins obscure la gestion des modules :-)
Bon courage !
Cdlt,
Ref:
¤ [http://lea-linux.org/cached/printable=yes/index/Kernel-modul(...)]
¤ [http://lists.debian.org/debian-user-french/2004/09/msg00119.(...)]
etc...
PS:
Le chargement du module "marchand de sable" peut avoir perturbé le contenu de ce message ^__^
[^] # Re: Problème de chargement de Drivers ?
Posté par Steve Azriel . En réponse au message Réseau wifi (WPA) non automatique au démarrage. Évalué à 1.
Je serais d'avis de répondre "qui ne tente rien n'a rien" ;-)
Enfin, sauf erreur, je crois qu'il faut déclarer les modules de la carte (ipw) dans /etc/modules et essayer le redémarrage de la machine.
Par contre, je ne suis pas sûr que ce soit la méthode "officielle" pour Debian et qu'il existe peut-être un autre moyen "plus conforme".
Voici pour info, un lien qui donne (à partir de la section §7.2) des exemples de périphériques dont le modules est listé dans /etc/modules
[http://www.debian.org/doc/manuals/reference/ch-kernel.fr.htm(...)]
Bonne chance !
Cdlt,
# Problème de chargement de Drivers ?
Posté par Steve Azriel . En réponse au message Réseau wifi (WPA) non automatique au démarrage. Évalué à 2.
Est-ce qu'il n'y aurait pas des pilotes à charger avant de lancer la configuration réseau (un pour la carte eth et/ou un autre pour la wifi) ?
Pour cela, il faudrait vérifier la liste des modules chargés au démarrage par le système (/etc/modules).
Ce fichier est utilisé par (/etc/init.d/modutis ou équivalent) juste après la phase du boot et avant de passer la main aux scripts RC comme /etc/init.d/networking.
Bon courage !
Cdlt,
PS: un petit lsmod dans un terminal et dmesg | grep eth pour savoir si ca correspondrait bien.
Enfin, classique mais sûr, un petit ls -l /etc/modutils/eth*
[^] # Re: "" => Pareil avec maxdepth et mindepth
Posté par Steve Azriel . En réponse au message appliquer une action à chaque fichier d'un répertoire. Évalué à 2.
Juste pour ajouter que find peut travailler sur différents niveaux de profondeur (voir la page man/info).
Donc, soit find parcourt un répertoire et tous ses sous-répertoires (cas par défaut), soit tu lui fixes des limites ;-)
Cdlt,
# Quelques process à surveiller...
Posté par Steve Azriel . En réponse au message Hostname. Évalué à 2.
Il se peut aussi que quelques process aient encore en mémoire l'ancien nom (je pense en particulier à syslog, à quelques daemon, ...).
Pour t'en assurer, un petit tour dans /var/log et une commande tail sur quelques fichiers devraient confirmer la bonne prise en compte du nom.
Si certains sont récalcitrants, le SIGHUP (kill -s HUP <pid>) pourrait être suffisant, mais d'autres auront besoin de plus (cycle stop/start via invoke-rc.d <nom_service> restart).
Cdlt,
[^] # Re: ifcfg-eth0.old => Bravo !
Posté par Steve Azriel . En réponse au message changer d'@ IP et de nom sur une machine FC3. Évalué à 3.
Effectivement, j'y avais pas pensé, mais le script de démarrage réseau de la redhat parcourt bien tous les fichiers ifcfg-*
Par contre, je suis surpris du fait que ifconfig n'affiche pas ce type d'information (qui ressemble à un alias IP)...
... personne n'aurait une idée pour avoir toutes les interfaces ?
J'aurais bien utilisé la commande "netstat" en mode statistiques d'interface (option -i) mais sans aucune garantie !
Cdlt,