Previous: 2 Réglages de kde
Up: Nullix 107
Next: 4 Serveur apache
  Contents
Subsections
Les informations importantes sont éparpillés dans beaucoup de fichiers
divers. Il n'existe pas de mécanisme de test de la cohérence. Il est
donc indispensable de lister ces divers éléments.
-
- /etc/rc.config (n'existe plus dans
)
/etc/hosts
/etc/dhcp.conf
/etc/route.conf (n'existe plus dans
)
/etc/printcap
/etc/smb.conf
/etc/rc.config.d/firewall.rc.config
tcpdump fait cela
Le batch qyr a pour objectif la récupération de tous ces morceaux.
Son listing est donné LISTING 11.
- Les commandes /etc/init.d/* renvoient des messages en couleur
(codes ANSI). Cette mise en forme est commandée par /etc/rc.status.
Il faut donc désactiver ce mécanisme en déclarant TERM=raw au début
du batch.
- La mise en page des règles de routage par ce batch qyr a été bricolée
... et reste approximative. Il faut revoir tout cela. De même les
sauts de pages aux multiples de 63 lignes.
- Dans les anciens temps de la téléphonie, on appelait un ordinateur
distant à travers un réseau téléphonique vocal. Au prix de la minute
de téléphone, mieux valait appeler... juste le temps nécessaire. En
ces temps là , le gestionnaire de barnum était point to point protocol
(ppp).
- Le client KdE kppp n'a jamais vraiment fonctionné. Opinion formulée
en 2001 : est devenu obsolète avec le développement du réseau par
câble. Dans les lieux désolés sans réseau permanent, mieux valait
utiliser une machine winxx comme passerelle.
- Puis, les maniaques de la connexion sont revenus en force avec pppoE
(ppp over Ethernet). Ce protocole a commencé par empoisonner l'adsl,
puis (mars 2002) est venu empoisonner le câble monopolisé par wanadoo.
- L'un des buts avoués est de vous déconnecter de force toutes les 24
heures, et vous empêchant ainsi d'avoir une adresse ip fixée par dhcp,
et donc restant fixe au moins tant que la machine reste branchée.
- Évidemment, des contournements sont apparus (dns dynamique). Le résultat
principal est d'introduire une couche de plus, avec les surcoûts correspondants
en temps et en débit. Un autre résultat est d'augmenter l'anonymat
d'éventuelles agressions. En particulier, il est plus difficile de
contacter les utilisateurs de bonne foi mais mal configurés.
- Supprimer Lock option dans /etc/ppp/options.
- Conflit modem souris
- le port modem est respecté, tandis que le port souris semble recherché
"best effort" : le conflit n'est visible qu'à l'activation
du modem.
- remarque : le port série requis n'est monté qu'à la demande. Ainsi,
kde_control n'affiche interrupt 4 (= serial port) que lors d'une
requête modem, tandis que interrupt 3 (= serial port) est affiché
en permanence (souris).
- Comment avoir un dial on call (internet, mail, etc) ?
- Mort subite inexpliquée du nourrisson : kppp meurt assez souvent ....
(kppp's helper process died ...)
- Vérifier que pppd est suid, ou que les utilisateurs sont dans le groupe
dialout.
- Il faut rendre pppoed24, pppoed et pppd exécutables
par les membres du groupe dialout.
- Il faut rendre /etc/pppoed.conf lisible par les membres de dialout.
- Il se trouve que SuseConfig (
) réécrit cette autorisation
à chaque fois : le batch qzq_anti_suse fixe ce problème.
- Il se trouve aussi que ce fichier contient en clair le password de
la connexion : un choix est à faire. Il est stupide de devoir le faire.
- La commande ifconfig permet de constater l'apparition d'un nouveau
device, ppp0. Une habile sélection permet de récupérer l'adresse ip
attribuée (batch ipipip).
-
- ip1=`/sbin/ifconfig eth0 | grep "inet addr"
| sed -e "s/\ \ Bcast.*$//; s/^.*://"`
ip2=`/sbin/ifconfig ppp0 2>/dev/null | grep "inet addr"
| sed -e "s/\ P-t-P.*$//; s/^.*://"`
echo $ip1"___"$ip2
- Une commande ipsend permet d'envoyer cette adresse ip vers une machine
ayant une adresse fixe, le tout sous le contrôle de cron (édition
par kcron).
- Le mécanisme d'encapsulation diminue la valeur de MTU qui est
de 1500 pour le protocole Ethernet ordinaire. On constate que ppp0
est déclaré avec une valeur MTU=1490.
- Le réglage de MTU pour les cartes Ethernet se trouve dans /etc/rc.config.
On constate que la valeur MTU =1492 sur la deuxième carte du
serveur, et sur la première carte d'une machine cliente sous linux
suffit à faire fonctionner la chose.
- Les valeurs à négocier pour MTU/MRU sont déclarées dans /etc/ppp/peers/pppoe24.
La valeur positionnée par YaST2 est 1490. Si l'on met plus, par exemple
1524, la négociation avec wanadoo conduit à un MTU =1492.
- Lorsque la machine client est sous winxx, le MTU se règle en donnant
la valeur texte "1492" à la clef HKML/System/CurentControlSet/Services/Class/Nettrans/000x/MaxMtu.
On peut constater la valeur à donner par la commande ping peer_to_peer_host -f -l 1464.
Avec les
octets de l'encapsulation par le protocole icmp,
cela fait bien
octets.
- Sous WinXP, la clef est HKLM/System/CurrentControlSet/Services/Tcpip/Parameters/Interfaces/xxxxx/MTU.
Repérer le bon interface (xxxxx) par son adresse ip. Remarque : 1500=5dc,
1492=5d4. Le MTU peut être envoyé par le serveur dhcp en positionnant :
option interface-mtu 1492 ;
- Le DNS du provider ne semble pas accessible par les machines winxx
clientes. Déclarer un autre DNS peut être utile
- Consulter la documentation /usr/share/doc/packages/sysconfig.
- Réglage du MTU dans le réseau interne. Inclure dans /etc/sysconfig/network/ifcfg-eth0
une ligne :
-
- MTU='1492'
- Configuration par YaST2 (network_basic/dsl_configuration. Cela crée
un fichier /etc/sysconfig/network/ifcfg-dsl0 qui contient les
lignes suivantes
-
- DEVICE='eth1'
PPPMODE='pppoe'
PROVIDER='dsl-provider0'
STARTMODE='onboot'
- Le startmode est à l'origine manuel. Il est intéressant de remplacer
cela par onboot, de façon à avoir cette connexion en permanence.
- Le provider est en fait le nom d'un fichier /etc/sysconfig/network/providers/dsl-provider0,
qui contient
-
- PROVIDER="DSL provider"
DSLSUPPORTED="yes"
MODEMSUPPORTED="no"
ISDNSUPPORTED="no"
USERNAME="le nom de connexion"
PASSWORD="le password en clair"
IDLETIME="300"
DEMAND="no"
DNS1=""
DNS2=""
- Les diverses actions sont enregistrées dans le fichier /var/log/pppd.log
(??? ré-expliquer où cela se configure...). On sait que le barnum
est en vie lorsque /var/run/ppp0.pid existe.
- Et en outre, il faut relancer périodiquement tout cela par un fichier
cron.
- Créer un utilisateur xdialout:dialout. Placer dans xdialout/bin
un lien vers ipse/bin/qso_sync_pppoed qui contient la véritable
incantation de lancement du barnum.
-
- if test ! -f /var/run/ppp0.pid
then /sbin/ifup dsl0
fi
- Créer un fichier ipse/bin/qzs_send_pppoed qui envoie l'adresse
obtenue vers un certain destinataire.
-
- tmp=`/sbin/ifconfig ppp0 2> /dev/null | grep 'inet addr' \
| sed -e"s/^[^:]*:// ; s/\ .*$//"`
echo . | mail -s ipipip$tmp"___" douillet@ensait.fr
echo "done ==> "$tmp
- Créer les deux fichiers cron dans /var/spool/cron/tabs. (???
plus de détails !!! ).
- Où est donc passé kcrontab ?
De grandes manoeuvres financières ayant fait migrer ''wanadoo-câble''
en ''numericable'', il a fallu (02/07/2005) repasser la connexion
en dhcp.
- Reconfiguration des cartes réseau innocentes, de façon à revenir à
la valeur MTU=1500 sur l'ensemble du réseau interne (1500 est
le standard Ethernet, tandis que 1492 est une adaptation aux contraintes
pppoe).
- Sur les machines unix, modifier /etc/sysconfig/network/ifcfg-eth0,
puis valider par
/sbin/ifdown eth0
/sbin/ifup eth0
- Sur les machines winxp, modifier la clef HKLM/System/CurrentControlSet/Services/Tcpip/Parameters/Interfaces/xxxxx/MTU.
Repérer le bon interface (xxxxx) par son adresse ip. Remarque : 1500=5dc,
1492=5d4.
- Pour les autres machines winxx, le MTU se règle en donnant
la valeur texte "1500" à la clef HKML/System/CurentControlSet/Services/Class/Nettrans/000x/MaxMtu.
- Invalider la carte dsl0 par STARTMODE='off' dans /etc/sysconfig/network/ifcfg-dsl0.
- Reconfigurer le firewall, la carte externe étant désormais eth1 et
pas ppp0. Se reporter à la Subsection 1.7.
- Réautoriser la modification dynamique de resolv.conf et de named.conf
dans /etc/sysconfig/network/config.
- Reconfigurer la carte réseau donnant sur l'extérieur par STARTMODE='onboot',
BOOTPROTO='dhcp', puis valider par
/sbin/ifdown eth1
/sbin/ifup eth1
- On obtient alors les valeurs suivantes dans resolv.conf
search modulonet.fr
nameserver 85.68.0.8
nameserver 85.68.0.7
connexion dhcp, adresse ip vraiment fixe.
Documentation sponsorisée par Bill Gates et MacroMedia. Cela se résume
à : on branche les cables en les branchant. Et on constate que le
"kit internet" ne délivre qu'une adresse ethernet
non routable 192.168.1.20. A jeter.
- Certaines modifications sont prises en compte immédiatement, d'autres
doivent être resynchronisées. D'où les batchs qsx.
- Les scripts de démarrage des démons ont changé de place. Depuis la
, ils se trouvent désormais dans /etc/init.d au
lieu de /sbin/init.d (cf TAB. 11).
TAB. 11:
Les scripts de démarrage
|
|
- Le script qsn déconnecte pppoE. Il existe donc une option (qsn z)
qui relance pppoE. Dans les deux cas, le script qsn se termine par
le lancement de ifconfig (avec une temporisation).
- les adresses lues dans /etc/route.conf sont du texte ascii.
Par conséquent 213.056.050.001 n'est pas reconnue comme étant 213.56.50.1.
Par contre, les adresses lues dans /etc/hosts sont en numérique.
3.7 Serveur d'adresses dhcp
- Lorsque l'on place le dhcp de la zone local.local sur une machine
interne, il ne faut pas que la passerelle soit sabotée par le dhcp
interne.
- Le gateway de la passerelle doit rester le gateway externe (et pas
réenvoyer sur la passerelle elle-même). En cas de problème, il faut
repérer la passerelle externe, la confirmer et vérifier
ifstatus eth1
route add default gw xx.xx.xx.xx ; route
- Les serveurs dns de la passerelle doivent contenir explicitement les
serveurs externes. Sinon les fonctions onboot (dont ntp) se passent
mal.
- Il se pourrait que les problèmes avec le gateway externe viennent
d'une absence de réponse dns lors de l'enregistrement de cette passerelle
(à tester en détail lorsque le problème de fixation des adresses ip
sera résolu)
- En bref, il faudrait que le dhcp interne et le dhcp externe ajoutent
leurs fonctionnalités au lieu de les écraser mutuellement.
- Les packages concernés sont :
- dhcdbd
- dhcp d-bus daemon
- dhcpcd
- client dhcp par défaut (chrooted in /var/lib/dhcpcd)
- dhcp
- isc dhcp : common files
- ~-client
- isc dhcp : client
- ~-relay
- isc dhcp : relay
- ~-server
- isc dhcp : server
- ~-tools
- isc dhcp : tools
- A partir de
, le lancement se fait par les runlevels (niveaux
3 et 5) et la configuration du serveur se fait par /etc/dhcpd.conf.
Pour la
, un modèle de fichier de configuration se trouvait
en /usr/share/doc/packages/dhcp/dhcpd.conf.
- Pour la
, lire les man et /usr/share/doc/packages/dhcp/README.
Le démon ne démarre pas lorsque la syntaxe du fichier de configuration
n'est pas correcte. En particulier, il faut une commande "ddns-update-style
none" pour diriger les dialogues entre le service dhcp
et le service ddns (dynamical dns). De toutes façons, la bonne marche
du service dépend du DNS (ou du fichier /etc/hosts).
- Configuration fixe d'une machine :
-
- host ZentEur {
hardware ethernet 00:48:54:82:e3:e8;
ddns-hostname zenteur;
fixed-address 215.56.50.88;
}
- La carte serveuse est identifiée par son adresse mac (et non plus
par son nom dynamique en ethx). Il n'est pas nécessaire que
les autres cartes soient démarrées ou aient reçu une adresse (par
un dhcp extérieur). Par contre, la carte serveuse doit être configurée
on boot, avec une adresse statique.
- La version 3.0.5-7 fournie avec
ne fonctionne pas correctement
(pas de logs). Ceci est fixé par la 3.0.5-9 (YoU)
- L'enregistrement des leases ne concerne que les adresses dynamiques.
Ce n'est donc pas un bug si ce fichier reste vide lorsqu'il n'y a
que des adresses fixes.
- Une aide à la mise en place se trouve dans YaST (modules réseau).
Est-ce bien utile ?
- Pour des raisons de sécurité, le dhcp est maintenant exécuté sur une
machine interne, pas sur le firewall.
- Le démon est exécuté par dhcpd:nogroup plutôt que par root,
et est de plus exécuté "chrooted". Le répertoire
prison est /var/lib/dhcp/ et contient :
/etc/localtime
/etc/host.conf
/etc/hosts
/etc/resolv.conf... and you might have to keep these current if they
are modified dynamically by other programs.
- Les messages arrivent sur /var/log/dhcpd/dhcpd.log (commandé
par dhcpd.conf et syslog).
- Bien entendu, les clients doivent eux aussi être configurés. Le fichier
correspondant est /etc/dhclient.conf, et l'activation se fait
sous YaST.
- Dans les anciennes versions, l'activation se faisait dans /etc/rc.config,
clef "IFCONFIG_X".
- Sous winx, le programme winipcfg est utile. Sous winx+, on
obtient les mêmes fonctionnalités avec l'icône "câble réseau"
(activer cette icône dans la fenêtre configuration de la carte).
- Jusqu'à
, le lancement du serveur dhcp se décide dans /etc/rc.config
par START_DHCPD = yes. La configuration du démon dépend de
/etc/rc.config.d/dhcpd.rc.config.
- Remarques jusqu'à
:
- Il faut que toutes les cartes réseau soient actives (avec une adresse
ip fixée ou obtenue).
- Il faut que tous les réseaux (repérés par leur adresse de groupe)
soient mentionnés, y compris pour dire qu'on ne leur parle pas.
- Le démon a tendance à ne pas suivre les directives, et préfère écouter
eth0. Renommer les interfaces en conséquence.
- Caveat : l'identification carte physique - numéro ethx est commandée
par le fichier /etc/modules.conf, tandis que l'adresse ip attribuée
à un numéro ethx est commandée par le fichier /etc/sysconfig/network/ifcfg-eth0.
Pour s'y retrouver, arrêter le réseau /etc/init.d/network/stop
et décharger les modules par rmmod.
- D'ailleurs, il est prudent d'utiliser des cartes réseau pilotées par
des modules différents, cela permet une meilleure identification.
- Dans le même genre d'idées, le routeur général doit être sur eth1
(sinon, le serveur dns n'est pas utilisable. La commande route donne
alors le gateway par son adresse ip et non par son nom).
3.7.6 Traitement des logs du serveur dhcp
- Premier principe : exploiter les logs depuis le compte d'un utilisateur
spécial
- Le traitement effectué est conditionné à la fois par la taille (très
petite) du réseau et par le niveau de confiance (très élevé) dans
les utilisateurs. Il s'agit donc uniquement de repérer des dysfonctionnements
matériels.
- Le traitement donne trois résultats : l'ensemble trié des identifiants
utilisés ne serait-ce qu'une fois, l'ensemble trié des messages (sans
les dates, ni les commentaires), la répartition chronologique des
messages pour chaque carte concernée.
- Constatations :
- Le fait que le serveur ne soit pas "authoritative"
a été détecté plusieurs fois par le seul menteur, dans un contexte
ancien et oublié (second démon dhcpd sous unix sur menteur ?)
- Lors du changement de carte réseau dans une machine, cette machine
continue à bénéficier de son ancienne adresse " un certain
temps" .
- Les noms de machine figurant dans le fichier dhcpd.conf ne sont pas
utilisés. Pourquoi ?
- Charger tous les modules, c'est à dire : bind bind-chrootenv
bind-doc bind-libs bind-libs-32bit bind-utils. Lire /usr/share/doc/packages/bind/arm/Bv9ARM.html
(il y en a un paquet...).
- Une zone est un groupement connexe sur lequel un serveur a autorité.
Le serveur envoie des AA (authoritative answers).
- YaST
Network Services propose un utilitaire de configuration.
Si le lancement n'est pas "on boot", le serveur
est mort après l'utilitaire.
- Lorsque le serveur fonctionne, il peut être le seul DNS déclaré
de la machine. Puis être le seul DNS déclaré du réseau.
- Le démon s'appelle named et s'exécute chrooted.
- Le répertoire /etc/named.d/ contient les fichiers de configuration
à inclure. Il y a forwarders.conf, fourni d'origine, et d'autres fichiers
*.fonc. Cette extension est fantaisiste et destinée à différencier
ces fichiers d'avec *.conf qui est inclus à l'intérieur de la section
options.
- Il faut un *.fonc pour décrire le mécanisme rncd
- Il faut un *.fonc pour chaque lookup direct ou reverse. Quand on
a ajouté quelque chose dans le répertoire named.d, il faut supprimer
/etc/named.conf.include (déclenche une recompilation).
- Contrôle : rndc stats. Ne fonctionne pas (cherche /var/lib/named/var/log/named/named.stats).
File not found s'il n'existe pas et acces denied s'il existe avec
tous les droits d'écriture. Persiste même avec la manoeuvre rndc-confgen.
- Syntaxe : ssh -X machine_distante [-l utilisateur]
- Les identifiants de connexion se trouvent dans ipse/.ssh.
- Ne pas oublier d'installer le package telnet-server !!!
- Activer le service dans /etc/inetd.conf
- Consulter les traces dans auth.log.
- Faire des essais en local et en semi-local.
- Il est utile de disposer d'un visuel rappelant que l'on est sur une
console à distance. Pour cela, on configure l'application konsole
(cf Subsection 2.10).
- Consulter le TimePrecision-HowTo : "Managing Accurate Date
and Time HowTo". La section Installx/Configuration/Documentation/Howto
décrit où diable se trouvent les HowTo.
- Dans le monde Unix, il y a deux horloges. L'horloge matérielle -HWclock-
et l'horloge immatérielle -SYSclock-. L'horloge matérielle (à quartz)
est lue une fois au boot pour initialiser l'horloge immatérielle,
puis est ignorée. A partir de là, SYSclock vit une vie erratique,
utilisant une partie la puissance de calcul du processeur pour faire
avancer ses aiguilles. Le mécanisme des interruptions fait que la
gestion de SYSclock n'est qu'approximative. En conséquence, cette
horloge se décale horriblement et il est nécessaire de mettre en oeuvre
un mécanisme de resynchronisation.
- La commande date lit la SYSclock, tandis que hwclock
lit la HWclock.
- Dans le monde tout court, l'heure n'est pas la même en tous les points
du globe. Le fichier binaire /usr/lib/zoneinfo/localtime contient
les descriptifs voulus. Plus précisément, ce fichier est un lien vers
/etc/localtime qui lui-même est un lien vers le bon fichier
de la base de données.
- Cette base de données est située en /usr/share/zoneinfo/. Pour
ce qui nous concerne, nous utilisons /usr/share/zoneinfo/Europe/Paris.
- La TimeZone est également enregistrée dans le fichier /etc/sysconfig/clock.
Ce fichier indique également si la HWclock est réglée en temps utc
ou bien en temps local.
HWCLOCK="-u"
TIMEZONE="Europe/Paris"
- Package xntp
- Serveurs : on peut utiliser des serveurs anonymes, ou des serveurs
nommés, ou des serveurs décrits par une adresse ip (pour rester effectif
même si le dns est en panne) :
server 0.pool.ntp.org
chronos.cru.fr (195.220.94.163)
canon.inria.fr
ntp-p1.obspm.fr
ntp-sop.inria.fr
ntp1.curie.fr
- Paramétrisation /etc/sysconfig/ntp (cf LISTING 12).
Ce service doit être utilisé "chrooted".
- Configuration /etc/ntp.conf(cf LISTING 13).
- Le réglage par défaut (
) des *.log ne convient pas. Préférer
une gestion directe par syslog (Section 1.4) et
envoyer le tout dans un répertoire spécial. Régler le niveau des *.log
: logconfig =all ou bien logconfig =syncstatus +sysevents.
- On constate que /var/log/ntp et /var/log/ntp sont acceptés
comme fichiers *.log, mais que les autres échouent "Cannot
open log file". En outre, on ne récupère pas tout (une partie
va sur messages.log).
- Erreur de syntaxe dans ntp.conf : à la ligne logconfig, il faut un
espace devant le +, et pas d'espace après (comme pour le =).
- Lanceur /etc/init.d/ntp. La variable INITIAL_NTPDATE
règle le fonctionnement de la commande /etc/init.d/ntp ntptimeset
: ou bien utiliser le serveur spécialement déclaré ou bien (valeur
auto-x) les x premiers serveurs déclarés dans /etc/ntp.conf.
- Lien avec dhcpd : définir un serveur de temps sur le réseau local,
et utiliser ce serveur pour les autres machines du réseau local. Quelle
est le meilleur endroit (passerelle ou dhcp ?).
- Le lanceur s'appelait xntpd. A spécifier aux niveaux 3 et 5 du runlevel-editor
(dans YaST2).
- En utilisant "exactement" les mêmes configurations
sur madras et moonlight, on obtient un serveur de temps reconnu (par
un client TARDIS tournant sur une machine winxx du réseau interne)
comme synchronisé sur madras, et reconnu non synchronisé sur moonlight.
Previous: 2 Réglages de kde
Up: Nullix 107
Next: 4 Serveur apache
  Contents
douillet@ensait.fr
2007-12-07