Ta partition sda5 est une partition logique. Faut-il en déduire que sda1 est une partition étendue (qui contient sda5) ?
Si c'est le cas, tu peux supprimer sda5 (après avoir fait un "swapoff /dev/sda5), puis sda1. A partir de là, tu pourras essayer de réorganiser le tout comme tu le désires.
Ton code pour tester le lancement de squid me semble assez bizarre. Est-ce que tu l'as testé ?
Sinon, pourquoi est-ce que tu relances squid avec juste la commande "squid" alors que tu l'arrêtes avec
/etc/init.d/squid stop ?
Il serait préférable de faire pareil pour le lancement :
/etc/init.d/squid start
En plus, je pense que cette commande te renverra un code retour différent de 0 s'il y a eu un soucis (code retour que tu retrouves dans la variable $?).
Enfin, pour tester si un processus contenant "squid" est en cours d'exécution tu peux tester ça :
ps aux | grep [s]quid >/dev/null 2>&1 || /etc/init.d/squid start
Mettre des crochets dans le motif de recherche ([s]quid) permet de ne pas retouner le process grep lui même. Le code résultat du grep vaut 0 si au moins une ligne est retournée et est non nul sinon. Les deux pipes (||) indiquent qu'il ne faut exécuter la suite que si le resultat de la commande précédente est non nul (donc si squi n'est pas lancé).
Bon et bien ce sera une box avec 384Mo de RAM et 512MO de mémoire flash, sans disque dur (possibilité éventuelle de rajouter un DD USB).
Côté logiciel, il y aura, en vrac :
- noyau linux 2.6.17 customisé
- firefox
- abiword
- gnumeric
- gqview pour visualiser les images
- gimp
- xine
- fluxbox entant que window manager
- pcman (explorateur de fichiers)
Donc ce sera plutôt du GTK+.
D'autres applis seront peut être ajoutées par la suite et le système devrait être remis à jour à chaque reboot (boot sur le réseau ?).
Enfin, tout ça est à prendre au conditionnel puisque j'ai tout pompé dans le SVM d'octobre
La page de man de ssh (je suis en version openssh 4.3p2) explique : By default, the listening socket on the server will be bound to the loopback interface only. This may be overriden by specifying a bind_address. An empty bind_address, or the address '*', indicates that the remote socket should listen on all interfaces. Specifying a remote bind_address will only succeed if the server's GatewayPorts option is enabled (see sshd_config(5)).
En clair, si tu mets simplement l'option -R80:localhost:80, le serveur sera à l'écoute sur le port 80 mais uniquement sur l'adresse de loopback (127.0.0.1) comme tu l'as constaté.
Pour être à l'écoute sur une IP particulière, il faut l'indiquer avec
-R IP_Serveur:80:localhost:80
ou
-R :80:localhost:80
Il faudra en plus que l'option "GatewayPorts clientspecified" apparaisse dans le sshd_config du serveur.
Je ne sais pas si putty permet de sécifier une adresse de bind pour le port forwarding sur le serveur. Si ce n'est pas le cas, tu peux essayer de mettre l'option "GatewayPorts yes" sur le serveur et vérifier si ça marche. Dans ce cas, tous les ports forwardés sur le sercveur par n'importe quel client seront accessibles sur le serveur.
Je n'ai pas tout compris au problème, mais s'il s'agit d'accéder au répertoire HOME d'un utilisateur donné, il est possible d'utiliser "~user" qui renvoie le chemin complet du HOME de user (/home/user par exemple).
Posté par JJD .
En réponse au message Problème ftp.
Évalué à 1.
Et bien dans ces logs, tu as tout ce que fait MySQL. La seule ligne vraiment intéressante (avant, ce sont des opérations de maintenance ?) est la dernière qui signale, à 11h16, une connexion sous le user root (si j'ai bien compris, proftpd utilise le user root avec le mot de passe Hakkodory pour se connecter à la base de données - c'est quoi ton adresse IP ;-))
Est-ce bien proftpd qui a fait cette connexion ?
Est-ce qu'il y avait une suite dans cette log ?
Si oui, tu devrais y voir les requêtes exécutées et peut-être comprendre ce qu'il se passe...
A part ça :
- ne laisse pas des log mysql aussi verbeuses en dehors des moments où tu fais des tests sinon tu vas rapidement avoir un fichier énoooorme
- il serait certainement plus propre et surtout plus sûr d'utiliser un autre user que root pour la connexion de proftpd à la base. Un user quelconque avec un simple droit de lecture sur la base ftp devrait faire l'affaire.
Posté par JJD .
En réponse au message Problème ftp.
Évalué à 1.
Dans le fichier /etc/proftpd/modules.conf, qu'est-ce que tu as laissé ?
Il me semble que si tu ne commentes pas la ligne
LoadModule mod_sql_postgres.c
lorsque tu veux utiliser un backend mysql, ça ne marche pas très bien...
Posté par JJD .
En réponse au message PROFTPD Mysql.
Évalué à 1.
Salut,
Un petit "apt-cache show proftpd-mysql" me dit que proftpd-mysql est : a dummy package used to migrate to the new modular package which uses Dynamic Shared Objects modules. You can safely remove it after upgrading.
En clair, proftpd-mysql ne contient rien lui-même et tu peux le supprimer sans conséquences. Il dépend simplement de proftpd, qui contient tout ce qu'il faut pour être utilisé avec mysql via des plugins chargeables.
Vérifie que tu as bien "LoadModule mod_sql_mysql.c" dans /etc/proftpd/proftpd.conf ou dans un des fichiers inclus.
En rajoutant "Include /etc/proftpd/modules.conf" dans proftps.conf et en commentant ce qui ne t'intéresse pas dans /etc/proftpd/modules.conf ça devrait marcher (attention : il semble il y avoir une erreur dans le chemin ModulePath dans modules.conf : je pense qu'il faut mettre /usr/lib/proftpd au lieu de /var/lib/proftpd).
Posté par JJD .
En réponse au message Probleme SSH.
Évalué à 3.
Bonjour,
Il faut également faire attention à quelques points importants :
- putty génère une paire de clé (clé privée/clé publique) dont le format n'est pas compatible avec OpenSSH. Sur le serveur OpenSSH, il faut copier la clé publique telle qu'elle apparaît dans la fenêtre de puttygen, pas celle contenue dans un éventuel fichier créé sur le disque (dans le fichier authorized_keys, la clé publique doit être sur une seule ligne).
- Sur le serveur, le répertoire HOME de l'utilisateur sous lequel tu te connectes ne doit être accessible en écriture que pour le propriétaire.
- Le répertoire $HOME/.ssh ne doit être accessible en lecture qu'au propriétaire.
Enfin, puttyagent ne permet pas de se connecter à un serveur SSH : pour cela il faut utiliser putty. puttyagent permet simplement de ne pas avoir à taper la passphrase protégeant la clé privée à chaque utilisation : au lancement de puttyagent, les clés privées sont chargées, les passphrases correspondantes demandées et ces clés sont ensuite servies à Putty lorsque cela est nécessaire.
Dans putty, il faut ouvrir la session en indiquant le fichier contenant la clé privée (dans Connection/SSH/Auth) : si tu ne l'as pas fait, putty ne tient pas compte de cette clé privée et la connexion de peut se faire puisque tu as, de plus, désactivé l'authentification par mot de passe.
J'espère que la réponse à tes questions se trouve dans les éléments indiqués.
Le paquet ftp fournit un client ftp en ligne de commande. Est-ce bien ce que tu veux ?
Si tu veux un client graphique, il faut en choisir un, mais il y a de grandes chances que tu aies déjà tout ce qu'il faut (les navigateurs WEB peuvent faire l'affaire, ainsi que les explorateurs de fichiers comme nautilus ou Konquerror).
Si tu recherches en serveur FTP, là aussi il en existe plusieurs. Essaie de taper dans un terminal "apt-cache search ftp server" pour en avoir une liste. Je pense cependant que proftp devrait convenir (apt-get install proftpd).
Posté par JJD .
En réponse au message Pb impression.
Évalué à 4.
Salut,
De mémoire, Acrobat Reader utilise la commande lpr pour imprimer. Or cette commande n'est pas systématiquement installé avec cups.
Tu peux vérifier en tapant dans une console "which lpr" (vérifie du même coup que tu as bien lp avec "which lp").
Pour corriger cela, il faut, par exemple, configurer tes logiciels pour utiliser lp à la place de lpr (en modifiant éventuellement les options), mais cela oblige à faire la manip pour toutes les apllis qui ont ce problème.
Une autre solution serait d'installer la paquet contenant la commande lpr (sous debian il s'agit de cupsys-bsd). Ceci à l'avantage de résoudre le problème une fois pour toutes.
Si tes soucis ne sont pas dus à l'absence de la commande lpr, essaie de vérifier les paramètres d'impression (taille de la page, ...)
Beh mi j'ai la chance d'habiter un pavillon, alors le chat il a débarqué il y a quelques années, il s'est installés nous a adoptés puis dressés.
A part ça, il est noir avec le bout des pattes blancs, et il est pas, mais alors pas du tout, castré : il sort quand il veut et mène sa vie peinard.
Il y a quand même eu un passage difficile au moment de la puberté quand il se prenait des raclée de la part des autres chats du quartier (les femelles non opérées sont une denrée rare) et qu'il compensaiten se tappant le bambi ou la marmotte (tous les deux en peluche) de ma fille...
L'organisation des fichiers de configuration avec Apache2 est légèrement différente de ce qui existait avec Apache.
En fait, ce que tu vois s'afficher est le site par défaut, dont la configuraton est lue dans apache2.conf grâce à la directive présente à la fin du fichier :
Include /etc/apache2/sites-enabled/[^.#]*
Le fichier de configuration est donc /etc/apache2/sites-enabled/00-default qui doit être un lien symbolique vers /etc/apache2/sites-available/default.
Donc si tu veux modifier le site par défaut, il faut que tu modifies le fichier en question (/etc/apache2/sites-available/default) ou, mieux, que tu crées ta configuration dans un fichier tout neuf (/etc/apache2/sites-available/mon_site) et que tu fasses pointer le lien symbolique dans le répertoire sites-enabled vers ce nouveau fichier.
Pour cette partie-là ta configuration est bonne. Il ne reste plus qu'à vérifier que le module apache "userdir" est bien installé et chargé.
Pour que ce module soit chargé, il faut qu'une directive du genre
LoadModule userdir_module /usr/lib/apache2/modules/mod_userdir.so
soit présente dans le(s) fichier(s) de configuration.
La façon de charger le module peut varier d'une distribution à l'autre : rajouter (ou décommenter) la ligne dans httpd.conf, création d'un lien symbolique, ...
Si tu ne trouves pas comment faire, indique-nous ta distribution...
La remarque que tu cites se voulait un peu ironique...
Effectivement, sur ces box, il n'est pas forcément possible de définir que le NAT concerne un serveur FTP (je vois déjà Orange t'explique que sur un accès grand public tu n'as pas à avoir un serveur). Dans ce cas, la seule solution est, comme tu l'as dit, de nater toute une plage de ports pour le FTP passif et de paramétrer le serveur FTP en conséquence (sans oublier d'indiquer l'adresse IP publique). Le FTP actif lui devrait fonctionner sans soucis (du moins côté serveur), puisque c'est le serveur qui se connecte sur le client pour les data.
Je pense tout de même que, même si le paramétrage n'est pas possible quand on a un serveur, le routeur de la livebox doit être capable de gérer le protocole FTP, sans cela les utilisateurs ne pourraient pas se connecter sur un serveur FTP en mode actif (rassure-moi : c'est bien possible ?)
Il me semble qu'il ne sera pas inutile, encore une fois, de donnre quelques détails sur le fonctionnement du FTP.
En mode actif, le client se connecte sur le port TCP 21 (ou n) du serveur. Toutes les commandes vont passer par cette connexion. Pour le transfert des données (put, get, ls, ...), le client indique au serveur le port et l'adresse IP à utiliser et le serveur établit une connexion TCP depuis le port TCP 20 (ou n-1) du serveur vers l'adresse IP et le port indiqués par le client. Pour que cela fonctionne correctement, il faut :
- que le serveur soit accessible sur le port 21 ;
- que le serveur puisse établir des connexions TCP ayant le port 20 comme origine ;
- que les connexions en provenance du port 20 du serveur arrivent jusqu'au client.
Donc, si le serveur est NATté, il faut que le routeur NATte le port 21 en entrée ainsi que le port 20 en sortie. Si le client est NATté, il faut que son routeur modifie les informations envoyées par le logiciel client (adresse IP et port à utiliser pour le canal de données) pour les remplacer par l'adresse IP publique et un port non utilisé. Il faudra également que ce routeur NATte les connexions entrantes en provenance du port 20 du serveur FTP vers le client concerné.
En mode passif, le client se connecte sur le port 21 du serveur (comme en actif) pour établir le canal de commandes. Pour le transfert des DATA, le serveur fournit au client l'adresse IP et le port (différent à chaque fois et tout le temps différent de 20) à utiliser et le client se connecte sur cette adresse et ce port. Ce mode est plus simple à utiliser pour le client (c'est lui qui se conecte sur le serveur tout le temps : il n'y a plus de connexion du serveur sur le client), mais la seule ouverture dur port 21 en sortie ne suffira pas (et ouvrir le port 20 ne servira à rien). Côte serveur, s'il y a du NAT, il peut être suffisant de définir, dans la configuration du serveur, une plage de port à utiliser et de NATté toute cette plage vers le serveur FTP (comme l'a écrit lgmdmdlsr).
Quoi qu'il en soit, la meilleure solution pour faire du FTP derrière un routeur qui fait du NAT est d'avoir un routeur qui supporte le protocole FTP. La plupart des routeurs actuels du marché devraient être capable de faire ça (sinon il faut en changer). En tout cas, netfilter/iptables s'en sort très bien grâce aux modules ip_conntrack_ftp et ip_nat_ftp (ouverture dynamique des ports nécessaires en fonction des échanges FTP sur le canal de commande et "masquerading" des adresses IP et des ports dans ces échanges). Je vous laisse un peu chercher dans l'abondante littérature sur le sujet pour voir comment paramétrer tout ça ;-)
Posté par JJD .
En réponse au message mail root.
Évalué à 3.
Bonjour,
Je voudrais simplement faire quelques petites remarques à ce sujet.
Effectivement, la sortie standard et la sortie d'erreur d'un programme exécuté par cron sont envoyées par mail à l'utilisateur sous lequel s'exécute le programme. Dans ton cas, il s'agit de root, mais cela fonctionnerait de la même façon pour un autre utilisateur.
Je pensais que le plus souvent, le mail de root n'arrivait pas directement sur le compte root mais était rerouté vers un autre utilisateur (cf fichier /erc/alliases). Visiblement ce n'est pas le cas sur toutes les distributions.
Pour éviter le mail, il faut soit avoir un programme qui ne génère pas de sortie, soit rediriger ces sorties (vers un fichier ou vers /dev/null).
Ces sorties peuvent avoir un intérêt pour détecter un problème à l'exécution. C'est pour cela qu'en général j'évite de tout rediriger vers /dev/null. Dans la mesure du possible, mes programmes en cron n'écrivent rien sur la sortie standard. Si cela n'est pas possible, je redirige cette sortie vers /dev/null ou un fichier en fonction de l'intérêt qu'elle peut avoir. En revanche, je touche rarement à la sortie d'erreur : si le programme écrit sur la sortie d'erreur, c'est qu'il y a eu un problème et dans ce cas il est intéressant de voir ce qu'il s'est passé pour le corriger, et recevoir cette erreur par mail est un moyen pas plus mauvais qu'un autre pour repérer un problème.
Bon, je ne sais pas si ces réflexions vous aideront vraiment, mais prenez-les simplement pour ce qu'elles sont : le résultat de mon expérience (je me sens vieux ce matin ;-( )
Posté par JJD .
En réponse au message Cron.
Évalué à 4.
Salut,
Je pense que tu ne prends pas le problème par le bon bout : IL NE FAUT PAS modifier directement le fichier /var/spool/cron/crontabs/www-data. [D'ailleurs www-data, comme n'importe quel autre utilisateur, ne devrait même pas y avoir accès en lecture].
Si tu veux modifier le crontab de www-data en non interactif, le plus simple est de mettre le contenu dans un fichier quelconque (fichier temporarire ?) et d'exécuter tout simplement :
crontab <ton_fichier_cron_temporaire
Comme ça, c'est simple, il n'y a aucun droit à modifier sur les fichiers ou les répertoires et aucun droit particulier à accorder à qui que se soit et le redémarrage du démon crond devient inutile (ce truc-là, ça ne se redémarre jamais !).
Comme les deux interfaces réseau sont sur la même plage d'adresse avec le même routeur, le test de l'interface WIFI n'est pas facile. Si la table de routage indique des routes passant par eth0, il est normal que ce soit la carte ethernet qui soit solicitée pour les réponses au ping (les paquets aller et retour peuvent prendre des chemins différents).
Pour vérifier que l'interface Wifi fonctionne, voici en vrac quelques pistes :
- modification de la table de routage en forçant le passage par rausb0 pour une adresse particulière de ton réseau local : tu regardes alors si les connexions s'établissent entre l'adresse 192.168.2.99 et cette adresse choisie.
- segmentation de la plage d'adresse actuelle (192.168.2.0/24) en utilisant un masque sur plus de 24 bits (peut être un peu compliqué...)
- désactivation de l'interface eth0 avec une réactivation automatique après un temps déterminé (avec un at ou quelque chose du genre "ifconfig eth0 down; sleep 60 ; ifconfig eth0 up"). Evidemment, ça dépend de ce qui est monté en NFS (est-ce que /sbin, /etc, /lib restent accessibles ?). Au pire des cas, est-il envisageable de récupérer la connexion réseau en rebootant ?
Sinon, je pense qu'il est effectivement normal d'avoir "Lien encap:Ethernet" dans le résultat du ifconfig pour la carte Wifi (en tout cas c'est comme ça chez moi).
Enfin, avant de faire ces tests, tu peux essayer de voir ce que donne comme résultat la commande iwconfig : si elle n'indique pas les bon paramètres (Mode, Essid, Cell, ...) il est inutile d'aller plus loin.
J'espère que ma modeste contribution t'aidera à arriver à tes fins.
[^] # Re: decoupage limité...
Posté par JJD . En réponse au message Un partitionnement chaotique. Évalué à 1.
Ta partition sda5 est une partition logique. Faut-il en déduire que sda1 est une partition étendue (qui contient sda5) ?
Si c'est le cas, tu peux supprimer sda5 (après avoir fait un "swapoff /dev/sda5), puis sda1. A partir de là, tu pourras essayer de réorganiser le tout comme tu le désires.
# As-tu testé ton code ?
Posté par JJD . En réponse au message Bash - Script de vérification d'un processus. Évalué à 1.
Sinon, pourquoi est-ce que tu relances squid avec juste la commande "squid" alors que tu l'arrêtes avec
/etc/init.d/squid stop ?
Il serait préférable de faire pareil pour le lancement :
/etc/init.d/squid start
En plus, je pense que cette commande te renverra un code retour différent de 0 s'il y a eu un soucis (code retour que tu retrouves dans la variable $?).
Enfin, pour tester si un processus contenant "squid" est en cours d'exécution tu peux tester ça :
ps aux | grep [s]quid >/dev/null 2>&1 || /etc/init.d/squid start
Mettre des crochets dans le motif de recherche ([s]quid) permet de ne pas retouner le process grep lui même. Le code résultat du grep vaut 0 si au moins une ligne est retournée et est non nul sinon. Les deux pipes (||) indiquent qu'il ne faut exécuter la suite que si le resultat de la commande précédente est non nul (donc si squi n'est pas lancé).
Est-ce que tout est clair ?
[^] # Re: Alors ??
Posté par JJD . En réponse au journal Neuf-Cegetel propose une ADSL-box/PC à base de Linux. Évalué à 4.
Côté logiciel, il y aura, en vrac :
- noyau linux 2.6.17 customisé
- firefox
- abiword
- gnumeric
- gqview pour visualiser les images
- gimp
- xine
- fluxbox entant que window manager
- pcman (explorateur de fichiers)
Donc ce sera plutôt du GTK+.
D'autres applis seront peut être ajoutées par la suite et le système devrait être remis à jour à chaque reboot (boot sur le réseau ?).
Enfin, tout ça est à prendre au conditionnel puisque j'ai tout pompé dans le SVM d'octobre
# Adresse d'écoute sur le serveur SSH
Posté par JJD . En réponse au message ssh et port forwarding. Évalué à 3.
La page de man de ssh (je suis en version openssh 4.3p2) explique :
By default, the listening socket on the server will be bound to the loopback interface only. This may be overriden by specifying a bind_address. An empty bind_address, or the address '*', indicates that the remote socket should listen on all interfaces. Specifying a remote bind_address will only succeed if the server's GatewayPorts option is enabled (see sshd_config(5)).
En clair, si tu mets simplement l'option -R80:localhost:80, le serveur sera à l'écoute sur le port 80 mais uniquement sur l'adresse de loopback (127.0.0.1) comme tu l'as constaté.
Pour être à l'écoute sur une IP particulière, il faut l'indiquer avec
-R IP_Serveur:80:localhost:80
ou
-R :80:localhost:80
Il faudra en plus que l'option "GatewayPorts clientspecified" apparaisse dans le sshd_config du serveur.
Je ne sais pas si putty permet de sécifier une adresse de bind pour le port forwarding sur le serveur. Si ce n'est pas le cas, tu peux essayer de mettre l'option "GatewayPorts yes" sur le serveur et vérifier si ça marche. Dans ce cas, tous les ports forwardés sur le sercveur par n'importe quel client seront accessibles sur le serveur.
Dis-nous si tout cela marche.
A+
JJD
# Répertoire HOME
Posté par JJD . En réponse au message Variable d'installation avec restriction. Évalué à 0.
Je n'ai pas tout compris au problème, mais s'il s'agit d'accéder au répertoire HOME d'un utilisateur donné, il est possible d'utiliser "~user" qui renvoie le chemin complet du HOME de user (/home/user par exemple).
JJD
[^] # Re: RE: logs et module postgresql
Posté par JJD . En réponse au message Problème ftp. Évalué à 1.
Est-ce bien proftpd qui a fait cette connexion ?
Est-ce qu'il y avait une suite dans cette log ?
Si oui, tu devrais y voir les requêtes exécutées et peut-être comprendre ce qu'il se passe...
A part ça :
- ne laisse pas des log mysql aussi verbeuses en dehors des moments où tu fais des tests sinon tu vas rapidement avoir un fichier énoooorme
- il serait certainement plus propre et surtout plus sûr d'utiliser un autre user que root pour la connexion de proftpd à la base. Un user quelconque avec un simple droit de lecture sur la base ftp devrait faire l'affaire.
A+
JJD
# Configuration
Posté par JJD . En réponse au message Problème ftp. Évalué à 1.
Il me semble que si tu ne commentes pas la ligne
LoadModule mod_sql_postgres.c
lorsque tu veux utiliser un backend mysql, ça ne marche pas très bien...
# description des paquets...
Posté par JJD . En réponse au message PROFTPD Mysql. Évalué à 1.
Un petit "apt-cache show proftpd-mysql" me dit que proftpd-mysql est :
a dummy package used to migrate to the new modular package which uses Dynamic Shared Objects modules. You can safely remove it after upgrading.
En clair, proftpd-mysql ne contient rien lui-même et tu peux le supprimer sans conséquences. Il dépend simplement de proftpd, qui contient tout ce qu'il faut pour être utilisé avec mysql via des plugins chargeables.
Vérifie que tu as bien "LoadModule mod_sql_mysql.c" dans /etc/proftpd/proftpd.conf ou dans un des fichiers inclus.
En rajoutant "Include /etc/proftpd/modules.conf" dans proftps.conf et en commentant ce qui ne t'intéresse pas dans /etc/proftpd/modules.conf ça devrait marcher (attention : il semble il y avoir une erreur dans le chemin ModulePath dans modules.conf : je pense qu'il faut mettre /usr/lib/proftpd au lieu de /var/lib/proftpd).
A+
JJD
[^] # Re: clés serveur
Posté par JJD . En réponse au message Probleme SSH. Évalué à 3.
Il faut également faire attention à quelques points importants :
- putty génère une paire de clé (clé privée/clé publique) dont le format n'est pas compatible avec OpenSSH. Sur le serveur OpenSSH, il faut copier la clé publique telle qu'elle apparaît dans la fenêtre de puttygen, pas celle contenue dans un éventuel fichier créé sur le disque (dans le fichier authorized_keys, la clé publique doit être sur une seule ligne).
- Sur le serveur, le répertoire HOME de l'utilisateur sous lequel tu te connectes ne doit être accessible en écriture que pour le propriétaire.
- Le répertoire $HOME/.ssh ne doit être accessible en lecture qu'au propriétaire.
Enfin, puttyagent ne permet pas de se connecter à un serveur SSH : pour cela il faut utiliser putty. puttyagent permet simplement de ne pas avoir à taper la passphrase protégeant la clé privée à chaque utilisation : au lancement de puttyagent, les clés privées sont chargées, les passphrases correspondantes demandées et ces clés sont ensuite servies à Putty lorsque cela est nécessaire.
Dans putty, il faut ouvrir la session en indiquant le fichier contenant la clé privée (dans Connection/SSH/Auth) : si tu ne l'as pas fait, putty ne tient pas compte de cette clé privée et la connexion de peut se faire puisque tu as, de plus, désactivé l'authentification par mot de passe.
J'espère que la réponse à tes questions se trouve dans les éléments indiqués.
A+
JJD
# Encodage URL
Posté par JJD . En réponse au message Cups, samba et mot de passe contenant #. Évalué à 3.
Tu devrais essayer de remplacer le caractère # par %23 (23 est le code hexadécimal de :).
A+
JJD
# Choix du paquet...
Posté par JJD . En réponse au message ftp: install et configuration sur debian 3.1. Évalué à 1.
Le paquet ftp fournit un client ftp en ligne de commande. Est-ce bien ce que tu veux ?
Si tu veux un client graphique, il faut en choisir un, mais il y a de grandes chances que tu aies déjà tout ce qu'il faut (les navigateurs WEB peuvent faire l'affaire, ainsi que les explorateurs de fichiers comme nautilus ou Konquerror).
Si tu recherches en serveur FTP, là aussi il en existe plusieurs. Essaie de taper dans un terminal "apt-cache search ftp server" pour en avoir une liste. Je pense cependant que proftp devrait convenir (apt-get install proftpd).
A+
JJD
# lpr ?
Posté par JJD . En réponse au message Pb impression. Évalué à 4.
De mémoire, Acrobat Reader utilise la commande lpr pour imprimer. Or cette commande n'est pas systématiquement installé avec cups.
Tu peux vérifier en tapant dans une console "which lpr" (vérifie du même coup que tu as bien lp avec "which lp").
Pour corriger cela, il faut, par exemple, configurer tes logiciels pour utiliser lp à la place de lpr (en modifiant éventuellement les options), mais cela oblige à faire la manip pour toutes les apllis qui ont ce problème.
Une autre solution serait d'installer la paquet contenant la commande lpr (sous debian il s'agit de cupsys-bsd). Ceci à l'avantage de résoudre le problème une fois pour toutes.
Si tes soucis ne sont pas dus à l'absence de la commande lpr, essaie de vérifier les paramètres d'impression (taille de la page, ...)
Bon courage,
JJD
[^] # Re: Beh
Posté par JJD . En réponse au journal Minou minou minou. Évalué à 4.
A part ça, il est noir avec le bout des pattes blancs, et il est pas, mais alors pas du tout, castré : il sort quand il veut et mène sa vie peinard.
Il y a quand même eu un passage difficile au moment de la puberté quand il se prenait des raclée de la part des autres chats du quartier (les femelles non opérées sont une denrée rare) et qu'il compensaiten se tappant le bambi ou la marmotte (tous les deux en peluche) de ma fille...
# Utilisation des VirtualHost
Posté par JJD . En réponse au message [Apache2] Directive DocumentRoot jamais pris en compte. Évalué à 2.
L'organisation des fichiers de configuration avec Apache2 est légèrement différente de ce qui existait avec Apache.
En fait, ce que tu vois s'afficher est le site par défaut, dont la configuraton est lue dans apache2.conf grâce à la directive présente à la fin du fichier :
Include /etc/apache2/sites-enabled/[^.#]*
Le fichier de configuration est donc /etc/apache2/sites-enabled/00-default qui doit être un lien symbolique vers /etc/apache2/sites-available/default.
Donc si tu veux modifier le site par défaut, il faut que tu modifies le fichier en question (/etc/apache2/sites-available/default) ou, mieux, que tu crées ta configuration dans un fichier tout neuf (/etc/apache2/sites-available/mon_site) et que tu fasses pointer le lien symbolique dans le répertoire sites-enabled vers ce nouveau fichier.
Voilà, j'espère que c'est à peu près clair,
JJD
# Module userdir
Posté par JJD . En réponse au message apache 2.0.54: config de httpd.conf pour avoir http://nomDns/~utilisateur. Évalué à 1.
Pour cette partie-là ta configuration est bonne. Il ne reste plus qu'à vérifier que le module apache "userdir" est bien installé et chargé.
Pour que ce module soit chargé, il faut qu'une directive du genre
LoadModule userdir_module /usr/lib/apache2/modules/mod_userdir.so
soit présente dans le(s) fichier(s) de configuration.
La façon de charger le module peut varier d'une distribution à l'autre : rajouter (ou décommenter) la ligne dans httpd.conf, création d'un lien symbolique, ...
Si tu ne trouves pas comment faire, indique-nous ta distribution...
A+
JJD
# Il faut 18 tuners
Posté par JJD . En réponse au message Materiel pour aquisition TNT. Évalué à 1.
[^] # Re: Serveur FTP derrière un NAT
Posté par JJD . En réponse au message Serveur FTP derrière un NAT. Évalué à 1.
Effectivement, sur ces box, il n'est pas forcément possible de définir que le NAT concerne un serveur FTP (je vois déjà Orange t'explique que sur un accès grand public tu n'as pas à avoir un serveur). Dans ce cas, la seule solution est, comme tu l'as dit, de nater toute une plage de ports pour le FTP passif et de paramétrer le serveur FTP en conséquence (sans oublier d'indiquer l'adresse IP publique). Le FTP actif lui devrait fonctionner sans soucis (du moins côté serveur), puisque c'est le serveur qui se connecte sur le client pour les data.
Je pense tout de même que, même si le paramétrage n'est pas possible quand on a un serveur, le routeur de la livebox doit être capable de gérer le protocole FTP, sans cela les utilisateurs ne pourraient pas se connecter sur un serveur FTP en mode actif (rassure-moi : c'est bien possible ?)
# Syntaxe mime
Posté par JJD . En réponse au message Metasend , petit probleme de syntaxe.... Évalué à 1.
Essaie quelque chose du genre :
metasend -b -F "adresse@mondomaine" -t destinataire -s "sujet" -f "/chemin/du/fichier/nom/du/fichier" -e "base64"-m 'application/ms-excel; name="fichier.xls"'
A+
JJD
[^] # Re: Serveur FTP derrière un NAT
Posté par JJD . En réponse au message Serveur FTP derrière un NAT. Évalué à 3.
Il me semble qu'il ne sera pas inutile, encore une fois, de donnre quelques détails sur le fonctionnement du FTP.
En mode actif, le client se connecte sur le port TCP 21 (ou n) du serveur. Toutes les commandes vont passer par cette connexion. Pour le transfert des données (put, get, ls, ...), le client indique au serveur le port et l'adresse IP à utiliser et le serveur établit une connexion TCP depuis le port TCP 20 (ou n-1) du serveur vers l'adresse IP et le port indiqués par le client. Pour que cela fonctionne correctement, il faut :
- que le serveur soit accessible sur le port 21 ;
- que le serveur puisse établir des connexions TCP ayant le port 20 comme origine ;
- que les connexions en provenance du port 20 du serveur arrivent jusqu'au client.
Donc, si le serveur est NATté, il faut que le routeur NATte le port 21 en entrée ainsi que le port 20 en sortie. Si le client est NATté, il faut que son routeur modifie les informations envoyées par le logiciel client (adresse IP et port à utiliser pour le canal de données) pour les remplacer par l'adresse IP publique et un port non utilisé. Il faudra également que ce routeur NATte les connexions entrantes en provenance du port 20 du serveur FTP vers le client concerné.
En mode passif, le client se connecte sur le port 21 du serveur (comme en actif) pour établir le canal de commandes. Pour le transfert des DATA, le serveur fournit au client l'adresse IP et le port (différent à chaque fois et tout le temps différent de 20) à utiliser et le client se connecte sur cette adresse et ce port. Ce mode est plus simple à utiliser pour le client (c'est lui qui se conecte sur le serveur tout le temps : il n'y a plus de connexion du serveur sur le client), mais la seule ouverture dur port 21 en sortie ne suffira pas (et ouvrir le port 20 ne servira à rien). Côte serveur, s'il y a du NAT, il peut être suffisant de définir, dans la configuration du serveur, une plage de port à utiliser et de NATté toute cette plage vers le serveur FTP (comme l'a écrit lgmdmdlsr).
Quoi qu'il en soit, la meilleure solution pour faire du FTP derrière un routeur qui fait du NAT est d'avoir un routeur qui supporte le protocole FTP. La plupart des routeurs actuels du marché devraient être capable de faire ça (sinon il faut en changer). En tout cas, netfilter/iptables s'en sort très bien grâce aux modules ip_conntrack_ftp et ip_nat_ftp (ouverture dynamique des ports nécessaires en fonction des échanges FTP sur le canal de commande et "masquerading" des adresses IP et des ports dans ces échanges). Je vous laisse un peu chercher dans l'abondante littérature sur le sujet pour voir comment paramétrer tout ça ;-)
A+
JJD
# tr '\\/' '/\\'
Posté par JJD . En réponse au message slash antislash. Évalué à 2.
man tr
A+
JJD
# Suppression ligne
Posté par JJD . En réponse au message Suprimer une ligne d'un fichier. Évalué à 2.
[^] # Re: modifier les sorties
Posté par JJD . En réponse au message mail root. Évalué à 3.
Je voudrais simplement faire quelques petites remarques à ce sujet.
Effectivement, la sortie standard et la sortie d'erreur d'un programme exécuté par cron sont envoyées par mail à l'utilisateur sous lequel s'exécute le programme. Dans ton cas, il s'agit de root, mais cela fonctionnerait de la même façon pour un autre utilisateur.
Je pensais que le plus souvent, le mail de root n'arrivait pas directement sur le compte root mais était rerouté vers un autre utilisateur (cf fichier /erc/alliases). Visiblement ce n'est pas le cas sur toutes les distributions.
Pour éviter le mail, il faut soit avoir un programme qui ne génère pas de sortie, soit rediriger ces sorties (vers un fichier ou vers /dev/null).
Ces sorties peuvent avoir un intérêt pour détecter un problème à l'exécution. C'est pour cela qu'en général j'évite de tout rediriger vers /dev/null. Dans la mesure du possible, mes programmes en cron n'écrivent rien sur la sortie standard. Si cela n'est pas possible, je redirige cette sortie vers /dev/null ou un fichier en fonction de l'intérêt qu'elle peut avoir. En revanche, je touche rarement à la sortie d'erreur : si le programme écrit sur la sortie d'erreur, c'est qu'il y a eu un problème et dans ce cas il est intéressant de voir ce qu'il s'est passé pour le corriger, et recevoir cette erreur par mail est un moyen pas plus mauvais qu'un autre pour repérer un problème.
Bon, je ne sais pas si ces réflexions vous aideront vraiment, mais prenez-les simplement pour ce qu'elles sont : le résultat de mon expérience (je me sens vieux ce matin ;-( )
A+
JJD
# Utilisation du crontab
Posté par JJD . En réponse au message Cron. Évalué à 4.
Je pense que tu ne prends pas le problème par le bon bout : IL NE FAUT PAS modifier directement le fichier /var/spool/cron/crontabs/www-data. [D'ailleurs www-data, comme n'importe quel autre utilisateur, ne devrait même pas y avoir accès en lecture].
Si tu veux modifier le crontab de www-data en non interactif, le plus simple est de mettre le contenu dans un fichier quelconque (fichier temporarire ?) et d'exécuter tout simplement :
crontab <ton_fichier_cron_temporaire
Comme ça, c'est simple, il n'y a aucun droit à modifier sur les fichiers ou les répertoires et aucun droit particulier à accorder à qui que se soit et le redémarrage du démon crond devient inutile (ce truc-là, ça ne se redémarre jamais !).
A+
JJD
# mdbtools
Posté par JJD . En réponse au message Recherche Driver Access ODBC. Évalué à 1.
Essaie de regarder du côté des mdbtools sur http://mdbtools.sourceforge.net/ ou dans les dépots de ta distribution préférée.
A+
JJD
[^] # Re: Résal
Posté par JJD . En réponse au message configuration des interfaces réseau. Évalué à 2.
Comme les deux interfaces réseau sont sur la même plage d'adresse avec le même routeur, le test de l'interface WIFI n'est pas facile. Si la table de routage indique des routes passant par eth0, il est normal que ce soit la carte ethernet qui soit solicitée pour les réponses au ping (les paquets aller et retour peuvent prendre des chemins différents).
Pour vérifier que l'interface Wifi fonctionne, voici en vrac quelques pistes :
- modification de la table de routage en forçant le passage par rausb0 pour une adresse particulière de ton réseau local : tu regardes alors si les connexions s'établissent entre l'adresse 192.168.2.99 et cette adresse choisie.
- segmentation de la plage d'adresse actuelle (192.168.2.0/24) en utilisant un masque sur plus de 24 bits (peut être un peu compliqué...)
- désactivation de l'interface eth0 avec une réactivation automatique après un temps déterminé (avec un at ou quelque chose du genre "ifconfig eth0 down; sleep 60 ; ifconfig eth0 up"). Evidemment, ça dépend de ce qui est monté en NFS (est-ce que /sbin, /etc, /lib restent accessibles ?). Au pire des cas, est-il envisageable de récupérer la connexion réseau en rebootant ?
Sinon, je pense qu'il est effectivement normal d'avoir "Lien encap:Ethernet" dans le résultat du ifconfig pour la carte Wifi (en tout cas c'est comme ça chez moi).
Enfin, avant de faire ces tests, tu peux essayer de voir ce que donne comme résultat la commande iwconfig : si elle n'indique pas les bon paramètres (Mode, Essid, Cell, ...) il est inutile d'aller plus loin.
J'espère que ma modeste contribution t'aidera à arriver à tes fins.
JJD