Depuis mes accès (au boulot ou chez moi en ADSL Free), le nom foetuspary.free.fr n'est pas résolu. Aurais-tu un problème de DNS ou de résolution? (cache DNS non lis à jour, ou quelque chose de ce genre-là)
Ton serveur X utilise 256 couleurs, ton appli utilise également 256 couleurs, ... mais pas forcément les mêmes !
Il est possible que ton appli installe sa propre palette de couleurs.
Qu'est-ce que cela donne si tu lances ton serveur X avec une profondeur de couleurs différente (16 ou 24 bits) ? Est-ce que le problème persiste ?
Je me réponds rapidement à moi même avant de me afire incendier...
J'ai raconté des conneries à la fin de mon post précédent : si tu n'a pas accès au display, tu vas avoir du mal à exécuter la commande xhost...
La seule possibilité me semble donc d'exécuter xhost lors de l'ouverture de ta session graphique (petit script lancé au démarrage de gnome/kde/xfce ou du WM utilisé).
>ça voudra dire que seul les utilisateurs (ceux déclarés dans /home)
> pourront se connecter, d'où qu'ils proviennent ...
> ou ça veut dire que seuls les utilisateur en localhost pourront
> accéder au display ?
Heuuuuu, je comprends pas tout...
Mais bon, en résumé, cela signifie que tous les utilisateurs qui peuvent accéder à ton serveur X en le désignant par ":0.0" pourront l'utiliser. Cela exclue les connexions TCP, où le DISPLAY vaut <adresse_ip_ou_nom>:0.0, ainsi que les connexions sur 127.0.0.1:0.0.
Le serveur X sera accessible uniquement en local, c'est à dire par les personnes ayant ouvert une session sur la machine, quel que soit le moyen pour ouvrir cette session (gdm/xdm/kdm, logon dans la console en local, connexion distante en telnet/ssh.rlogin, ...).
En clair, ça veut dire qu'il faut que tu fasses confiance aux personnes susceptibles de se connecter sur ta machine (toutes celles qui possèdent un user/mot de passe), car elles pourront toutes lancer des applications qui utiliserons ton display (pour afficher des choses, mais également pour observer tout ce qui s'y passe).
>quel fichier est le plus propice pour recevoir les commandes
Si tu veux que les commandes xhost soient exécutés à chaque fois que tu te logues, tu peux les mettre dans ~/.bash_profile (ou ~/.profile) ou dans ~/.bashrc (le premie est utilisé sur un shell de login intercatif, le deuxième -normalement- dans les autes cas). Mais cela signifie que tu autorises les connexions locales au serveur X dès que tu te connectes. Tu peux aussi, pour lancer tes xclock, utiliser un script du genre :
Si la variable DISPLAY vaut :0.0, je continue de penser qu'un "xhost +client_ssh" ne servira à pas grand chose : la connexion au serveur X ne se fait pas en TCP, et certainement pas depuis l'adresse IP du client SSH (ou du proxy).
Un "xhost +" est à proscire absolument : c'est un énorme trou de sécurité !
En revanche, il y a peut être un compromis en utilisant simplement un "xhost +LOCAL:" : tu n'autorises ainsi que les utilisateurs locaux à utiliser le serveur X :0.0 (n'oublie pas de faire un "xhost -" avant).
Mais tout cela n'explique pas pourquoi l'authentification xauth ne fonctionne pas...
Oui, mais non justement :
- si on fixe la variable DISPLAY à la valeur :0.0 on ne passe pas par la pile tcp, mais sur un socket Unix. L'option "-nolisten tcp" ne devrait donc pas avoir d'influence (accessoirement cela se règle en général dans les fichiers de configuration de gdm/kdm/xdm et l'option n'est pas complètement débile puisque la plupart du temps les connexions TCP sur le serveur X ne sont pas utilisés et que cela n'empêche pas l'utilisation d'un tunnel SSH).
- le problème peut effectivement venir de l'authentification X11 (xauth), mais c'est assez étrange puisque la commande graphique est lancée en local (dans la session ssh), par le même utilisateur que celui qui a ouvert la session graphique. Les cookies d'authentification devraient donc être accessible de la même façon.
Il faut peut être chercher au niveau des variables d'environnement ou de la configuration de ssh...
Je pense effectivement qu'il faut oublier les histoires de xhost (tu essaies de lancer les applis localement) et de "ssh -X" (puisque tu as clairement expliqué dans ta question que ce n'est pas ce que tu voulais).
Il est en revanche fort possible que le problème vienne de xauth ou d'une configuration particulière de ssh/sshd (mais là je ne vois pas trop ce qui pourrait clocher).
Quelques pistes tout de même :
- dans ta session SSH, est-ce que la variable XAUTHORITY existe ?
- si oui, que vaut-elle ?
- si tu fixes la valeur de cette variable à ~toto/.Xauthority , il y a-t-il toujours le même problème ?
- que donne la commande "xauth list" dans la session ssh et en local?
- ... (si quelqu'un a des idées)
Il n'y a pas vraiment de raison que ça ne marche à condition de respecter certaines règles :
- il faut que sur ta machine à la maison toto ait une session graphique active.
- ensuite tu te connectes en SSH, sous le user toto, et tu tapes "export DISPLAY=:0.0".
- à partir de là tu dois pouvoir lancer des applications graphiques simplement en tapant les commandes qui vont bien, mais évidemment tu ne verras rien.
Une autre solution, peut être plus conviviale, serait l'utilisation d'un serveur VNC explortant le DISPLAY courant (X0vnc-server, vino, krfb ou d'autes en fonction de ta distrib et de ton environnement de bureau). Le client VNC existe sur à peu près toutes les plates-formes (linux, Windows, PalmOS, Amiga, MacOS, ...) et la connexion peut se faire via un tunnel SSH. Tu aurais alors l'énorme avantage de te retrouver avec ton bureau complet dans une fenêtre, et donc de voir ce qui se passe.
Je crois que là tu es cimplètement à côté de la plaque... (sans auncune intention de te vexer).
Les niveaux indiqués en paramètre à chkcinfig n'ont rien à voir avec un quelconque modèle réseau. Il s'agit de runlevel, c'est à dire des sortes de modes de démarrage de ta machine, dans lesquels différents services vont être exécutés. Par exemple, il est possible de paramétrer un service (serveur X-Window, Apache, Samba, ...) pour qu'il s'exécute avec le runlevel 3 et pas avec le runlevel 4. Ce chois des runlevel est parfaitement arbitraire et peut être différent en fonction des distributions. La plupart du temps, on ne s'en occupe pas vraiment et on n'utilise que le runlevel par défaut, déclaré dans le fichier /etc/inittab (ligne de la forme "id:3:initdefault:" pour indiquer que par défaut, au boot, on choisit le runlevel 3).
On peut changer de runlevel avec la commande "init".
Par convention, les runlevel 0,1 et 6 sont réservés pour l'arrêt de la machine, le mode "single user" et le reboot.
Ta commande indique donc simplement que samba sera lancé dans les runlevels 3, 4 et 5. Cela se fait simplement en créant un lien symbolique dans le répertoire /etc/rc3.d vers le script de démarrage de samba dans /etc/init.d.
Sinon, les téléphones portables acceptent pour la plupart les commandes AT et je pense qu'il doit être possible d'envoyer des SMS en utilisant ces commandes (j'avais joué un peu avec ça il y a quelques temps avec minicom ...).
Tout dépend du window-manager (ou de l'environnement du bureau) utilisé.
Avec gnome, il y a la commande gnome-session-save qui permet (malgré son nom) de terminer la session (cf entrée "Clore la session" du menu) avec ou sans fenêtre de confirmation.
Les autres environnements ont certainement des commandes équivalentes : il suffit de chercher un peu.
Ce qui est sûr, c'est que tu ne trouveras de commande magique fonctionnant partout avec tous les WM...
Lorsque tu n'es pas root, il semble que su vérifie que le shell de maven1 (indiqué dans /etc/passwd) est bien présent dans /etc/shells.
Vérifie si par hasard, tu n'aurais pas "/bin/false" dans le fichier /etc/shells de la première machine et pas sur la deuxième (si tu rajoutes la ligne ça devrait fonctionner, mais il y aura peut-être des effects de bord).
Si la différence entre les deux machines n'est pas là, il faut peut être regarder du côté des versions de su installés (paquet login) et des fichiers de configuration de pam (/etc/pam.d/su ).
Le shell offre certains mécanismes de contrôle des processus. Au moins avec bash (pour les autres [ksh, zsh, ...] il faudra vérifier ce que je raconte), il est possible de gérer assez finement ce qui se passe.
Regarde le manuel de bash (ou toute autre aide), et en particulier :
- trap : permet d'intercepter un signal et d'exécuter une action en fonction de ce signal. Tu peux par exemple intercepter le signal SIGTERM (15) pour aller tuer les processus fils
- jobs : cette comande interne permet de récupérer la liste des processus actifs avec leurs ID (jobs -l ou jobs -p)
- kill : pour envoyer un signal à un processus particulier. Essaie d'abord du tuer les fils avec un SIGTERM (15), avant d'envoyer un SIGKILL (9) : ça laissera une chance aux processus de se terminer proprement.
Avec ça tu devrais pouvoir commencer à correctement gérer les processus fils et les arrêts (pas trop) violents.
Je fais également appel à mes vieux souvenirs de déclaration des revenus...
Donc, si je me souviens bien, pour que le site fonctionne, il faut effectivement accepter de récupérer une applet java (je ne sais plus si cela concerne l'autentification ou bien uniquement la déclaration de revenus en ligne). Or cette applet veut à tout prix s'installer dans un répertoire système (et non pas sous le $HOME de l'utilisateur). La seule façon que j'ai trouvé pour faire fonctionner ça a été de récupérer cette applet avec un navigateur (firefox) exécuté par root (!!!!).
Ensuite, tout a fonctionné correctement avec le brouteur s'exécutant sous un utilisateur quelconque.
Lors de la première utilisation, il faut demander un certificat (en fournissant un certain nombre d'informations afin de garantir son identité). ce certificat est stocké dans le répertoire $HOME/teleir.
Enfin, je tiens à souligner que j'ai également eu des soucis à signer ma déclaration : l'appli java des impots a (avait ?) des problèmes liés à la locale courante. La signature ne fonctionnait absolument pas si l'utilisateur utilisait de l'Unicode (UTF-8). Il a fallu que je passe en ISO8859-1 (ou ISO8859-15) afin de pouvoir valider la signature de ma déclaration.
J'espère que ces informations seront utiles à ceux qui me liront (et que le problème de l'unicode sera corrigé avant la prochaine déclaration).
Dans la configuration des cartes WIFI "enc" (encryption) et "key" sont synonymes (cf le mn de iwconfig). Dans le fichier interfaces, on peut donc mettre de façon équivalente wireless-enc ou wireless-key, ou alors ça fait 6 mois que j'ai un réseau WIFI public chez moi ;-)
Salut,
Je ne connais pas ubuntu, mais je pense qu'il y a de grandes chances pour que la configuration des interfaces réseau se fassent comme sur d'autres distribution (et en particulier Debian).
Donc, tu dois pouvoir passer les paramètres à ta carte WIFI dans le fichier /etc/network/interfaces en y mettant quelque chose du genre :
Normalement, tu as déjà une entrée wlan0 dans ce fichier (sinon la commande ifup wlan0 ne fonctionnerait pas). Il faut donc simplement que tu rajoutes les lignes wireless-* avec les paramètres qui vont bien.
A+
JJD
Je ne comprends pas ce passage du manuel de la même façon que toi : s'il existe déjà un lien /etc/rcX.d/S??name, celui-ci n'est pas remplacé. C'est à dire que l'on peut modifier l'ordre d'exécution de ces scripts et que ces modifications sont conservées après les mises à jour.
En tout cas, il semble possible d'utiliser cela pour éviter le lancement de cetains démons, y compris après une mise à jour : il devrait suffire de créer un lien symbolique /etc/rcX.d/S??name vers un script qui ne fait rien. Lors des mises à jour, le lien symbolique existant, il ne sera pas remplacé.
Quelle URL utilises-tu pour accéder à l'interface HTTP de cups?
En fonction du paramétrage (cupsd.conf), les accès (au site ou à la partie administration) peuvent être autorisés sur l'adresse 127.0.0.1 (normalement localhost), mais pas avec l'adresse IP du serveur sur le réseau.
Est-ce que tu accèdes à la page d'accueil de cups ?
Est-ce que tu accèdes à certains des "menus"? (Imprimantes, Classes, Travaux, ...)
Quand tu essaies d'ajouter une imprimante (et que tu as une pop-up te demandant un user et un mot de passe), que se passe-t-il? Quel message d'erreur as-tu?
Ces informations permettront peut-être de mieux cerner le problème. Si ce n'est pas le cas, il faudra certainement que tu nous fournisses le fichier cupsd.conf.
Tout dépend de la locale que tu utilises. En gros, il faut mettre la même chose que dans le fichier /etc/environment.
Chez moi, comme je suis en français avec un jeu de cataractère latin9 (ISO-8859-15), j'ai mis :
LANG DEFAULT=fr_FR@euro
et ça marche parfaitement.
Suivant ta configuration, tu peux être ammené à remplacer fr_FR@euro par autre chose :
- "fr_FR" pour ISO-8859-1
- "fr_FR.UTF-8" ou "fr_FR.UTF-8@euro" pour utiliser de l'unicode.
Evidemment, après avoir modifié le fichier /etc/security/pam_env.conf (avec le user root), il faut que tu te délogues (fermeture de la session) et que tu te reconnectes pour que les chagements soient pris en compte.
A+
JJD
Apparemment, il faut attendre pour que cela soit corrigé dans une prochaine mise à jour (/etc/environment n'est plus pris en compte), ou bien rajouter ce qu'il y a dans ce fichier (en particulier LANG=...) dans /etc/security/pam_env.conf (sous le format :
LANG DEFAULT=...
je n'ai pas encore testé, mais je vais voir ce que cela donne ...
Après compilation de ton nouveau noyau, tu ne supprimes pas l'ancien (qui fonctionne) et tu gardes la possibilité, via grub ou lilo, de booter sur l'un ou l'autre des deux noyaux (il vaut mieux pour cela avoir un accès à la console du serveur pour choisir le noyau au boot, sinon il faut jouer jouer avec les options de lilo/grub).
Posté par JJD .
En réponse au message config logs.
Évalué à 3.
Salut,
Le fichier logrotate.conf te donne la configutation par défaut. De plus le paramètre "size" indique la taille limite pour laquelle il faut appliquer la règle adéquate : avec ta configuration, les fichiers de logs ne subiront une "rotation" que s'il dépassent les 2000MO, ce qui me semble énorme.
En revanche, dans la conf, il y a quelque chose d'intéressant :
include /etc/logrotate.d
Cette directive indique qu'il faut inclure les fichiers de conf contenus dans le répertoire /etc/logrotate.d. Pour information, sur mes machines, j'ai, dans de répertoire, un fichier "apache2" qui contient les lignes suivantes :
/var/log/apache2/*.log {
weekly
missingok
rotate 52
compress
delaycompress
notifempty
create 640 root adm
sharedscripts
postrotate
if [ -f /var/run/apache2.pid ]; then
/etc/init.d/apache2 restart > /dev/null
fi
endscript
}
Cela indique que tous les fichiers *.log du répertoire /var/log/apache2 subiront une rotation une fois par semaine, quelle que soit leur taille (pas de directive size), que 52 fichiers sont conservés sous une forme compressée (sauf le premier) et de plus apache est redémarré après la rotation de façon à ce que les fichiers de logs ouverts soient fermés (sans ça, apache va continuer à écrire dans le fichier renommé, c'est à dire access_log.1 au lieu de access_log).
Il te reste à adpter cela à tes besoins.
A part ça, il est fort possible que ton système de fichier limite la taille des fichiers à 2GO (ça dépend du FS utilisé et des options de formatage).
il est assez difficile de voir ce qui se passe lors du lancement du serveur X avec aussi peu d'informations.
Les fichiers intéressants sont /etc/X11/xorf.conf et /var/log/Xprg.0.log.
Pour les récupérer sur un autre disque, il y a plusieurs possibilités, ce qui rend assez difficile les conseils...
Enfin, essaie de taper la commande "mount" : si un disque Windows est accessible tu devrais voir une ligne commençant pas /dev/hda1 (si ton disque Windows est sur la première partition). Sur la ligne en question, tu verras alors le point de montage (c'est à dire l'endroit de ton arborescence où ta partition Windows est accéssible, par exemple /mnt/windows). Si tout va bien, tu peux copier les fichiers avec la comande "cp /etc/X11/xorf.conf /mnt/windows".
Tu peux aussi essayer de mettre les fichiers sur une clé USB. Insère ta clé et tappe la commande mount. Si tu vois quelque chose relatif à de l'USB tu peux copier les fichiers avec la commande cp. Sinon, essaie de monter ta clé en tapant "mount /dev/sda1 /mnt" : la clé sera alors accessible sur le chemin /mnt/ (s'il n'y a pas d'erreur).
Si tout cela échoue, le mieux serait que tu trouves quelqu'un dans ton entourage connaissant Linux et pouvant se déplacer chez toi : tous les forums ne remplaceront jamais le contact direct...
# DNS ???
Posté par JJD . En réponse au message Passerelle et perte de paquets?. Évalué à 1.
Depuis mes accès (au boulot ou chez moi en ADSL Free), le nom foetuspary.free.fr n'est pas résolu. Aurais-tu un problème de DNS ou de résolution? (cache DNS non lis à jour, ou quelque chose de ce genre-là)
JJD
# Pb palette
Posté par JJD . En réponse au message Pb Couleur Xwindows. Évalué à 2.
Ton serveur X utilise 256 couleurs, ton appli utilise également 256 couleurs, ... mais pas forcément les mêmes !
Il est possible que ton appli installe sa propre palette de couleurs.
Qu'est-ce que cela donne si tu lances ton serveur X avec une profondeur de couleurs différente (16 ou 24 bits) ? Est-ce que le problème persiste ?
JJD
[^] # Re: DISPLAY
Posté par JJD . En réponse au message SSH, lancer des applications X distantes, sans X. Évalué à 1.
J'ai raconté des conneries à la fin de mon post précédent : si tu n'a pas accès au display, tu vas avoir du mal à exécuter la commande xhost...
La seule possibilité me semble donc d'exécuter xhost lors de l'ouverture de ta session graphique (petit script lancé au démarrage de gnome/kde/xfce ou du WM utilisé).
JJD
[^] # Re: DISPLAY
Posté par JJD . En réponse au message SSH, lancer des applications X distantes, sans X. Évalué à 1.
> pourront se connecter, d'où qu'ils proviennent ...
> ou ça veut dire que seuls les utilisateur en localhost pourront
> accéder au display ?
Heuuuuu, je comprends pas tout...
Mais bon, en résumé, cela signifie que tous les utilisateurs qui peuvent accéder à ton serveur X en le désignant par ":0.0" pourront l'utiliser. Cela exclue les connexions TCP, où le DISPLAY vaut <adresse_ip_ou_nom>:0.0, ainsi que les connexions sur 127.0.0.1:0.0.
Le serveur X sera accessible uniquement en local, c'est à dire par les personnes ayant ouvert une session sur la machine, quel que soit le moyen pour ouvrir cette session (gdm/xdm/kdm, logon dans la console en local, connexion distante en telnet/ssh.rlogin, ...).
En clair, ça veut dire qu'il faut que tu fasses confiance aux personnes susceptibles de se connecter sur ta machine (toutes celles qui possèdent un user/mot de passe), car elles pourront toutes lancer des applications qui utiliserons ton display (pour afficher des choses, mais également pour observer tout ce qui s'y passe).
>quel fichier est le plus propice pour recevoir les commandes
Si tu veux que les commandes xhost soient exécutés à chaque fois que tu te logues, tu peux les mettre dans ~/.bash_profile (ou ~/.profile) ou dans ~/.bashrc (le premie est utilisé sur un shell de login intercatif, le deuxième -normalement- dans les autes cas). Mais cela signifie que tu autorises les connexions locales au serveur X dès que tu te connectes. Tu peux aussi, pour lancer tes xclock, utiliser un script du genre :
#!/bin/bash
xhost -
xhost +LOCAL:
xclock
xhost -LOCAL:
et tu appelles ce script en lieu et place de xclock.
Mais je voudrais bien savoir ce que tu vas faire de toutes ces horloges sur ton écran ;-)
A+
JJD
[^] # Re: DISPLAY
Posté par JJD . En réponse au message SSH, lancer des applications X distantes, sans X. Évalué à 2.
Un "xhost +" est à proscire absolument : c'est un énorme trou de sécurité !
En revanche, il y a peut être un compromis en utilisant simplement un "xhost +LOCAL:" : tu n'autorises ainsi que les utilisateurs locaux à utiliser le serveur X :0.0 (n'oublie pas de faire un "xhost -" avant).
Mais tout cela n'explique pas pourquoi l'authentification xauth ne fonctionne pas...
JJD
[^] # Re: "chez moi ça marche" !
Posté par JJD . En réponse au message SSH, lancer des applications X distantes, sans X. Évalué à 2.
- si on fixe la variable DISPLAY à la valeur :0.0 on ne passe pas par la pile tcp, mais sur un socket Unix. L'option "-nolisten tcp" ne devrait donc pas avoir d'influence (accessoirement cela se règle en général dans les fichiers de configuration de gdm/kdm/xdm et l'option n'est pas complètement débile puisque la plupart du temps les connexions TCP sur le serveur X ne sont pas utilisés et que cela n'empêche pas l'utilisation d'un tunnel SSH).
- le problème peut effectivement venir de l'authentification X11 (xauth), mais c'est assez étrange puisque la commande graphique est lancée en local (dans la session ssh), par le même utilisateur que celui qui a ouvert la session graphique. Les cookies d'authentification devraient donc être accessible de la même façon.
Il faut peut être chercher au niveau des variables d'environnement ou de la configuration de ssh...
JJD
[^] # Re: DISPLAY
Posté par JJD . En réponse au message SSH, lancer des applications X distantes, sans X. Évalué à 1.
Il est en revanche fort possible que le problème vienne de xauth ou d'une configuration particulière de ssh/sshd (mais là je ne vois pas trop ce qui pourrait clocher).
Quelques pistes tout de même :
- dans ta session SSH, est-ce que la variable XAUTHORITY existe ?
- si oui, que vaut-elle ?
- si tu fixes la valeur de cette variable à ~toto/.Xauthority , il y a-t-il toujours le même problème ?
- que donne la commande "xauth list" dans la session ssh et en local?
- ... (si quelqu'un a des idées)
JJD
# DISPLAY
Posté par JJD . En réponse au message SSH, lancer des applications X distantes, sans X. Évalué à 3.
Il n'y a pas vraiment de raison que ça ne marche à condition de respecter certaines règles :
- il faut que sur ta machine à la maison toto ait une session graphique active.
- ensuite tu te connectes en SSH, sous le user toto, et tu tapes "export DISPLAY=:0.0".
- à partir de là tu dois pouvoir lancer des applications graphiques simplement en tapant les commandes qui vont bien, mais évidemment tu ne verras rien.
Une autre solution, peut être plus conviviale, serait l'utilisation d'un serveur VNC explortant le DISPLAY courant (X0vnc-server, vino, krfb ou d'autes en fonction de ta distrib et de ton environnement de bureau). Le client VNC existe sur à peu près toutes les plates-formes (linux, Windows, PalmOS, Amiga, MacOS, ...) et la connexion peut se faire via un tunnel SSH. Tu aurais alors l'énorme avantage de te retrouver avec ton bureau complet dans une fenêtre, et donc de voir ce qui se passe.
A+
JJD
# Rien à voir !
Posté par JJD . En réponse au message Couche OSI samba. Évalué à 2.
Je crois que là tu es cimplètement à côté de la plaque... (sans auncune intention de te vexer).
Les niveaux indiqués en paramètre à chkcinfig n'ont rien à voir avec un quelconque modèle réseau. Il s'agit de runlevel, c'est à dire des sortes de modes de démarrage de ta machine, dans lesquels différents services vont être exécutés. Par exemple, il est possible de paramétrer un service (serveur X-Window, Apache, Samba, ...) pour qu'il s'exécute avec le runlevel 3 et pas avec le runlevel 4. Ce chois des runlevel est parfaitement arbitraire et peut être différent en fonction des distributions. La plupart du temps, on ne s'en occupe pas vraiment et on n'utilise que le runlevel par défaut, déclaré dans le fichier /etc/inittab (ligne de la forme "id:3:initdefault:" pour indiquer que par défaut, au boot, on choisit le runlevel 3).
On peut changer de runlevel avec la commande "init".
Par convention, les runlevel 0,1 et 6 sont réservés pour l'arrêt de la machine, le mode "single user" et le reboot.
Ta commande indique donc simplement que samba sera lancé dans les runlevels 3, 4 et 5. Cela se fait simplement en créant un lien symbolique dans le répertoire /etc/rc3.d vers le script de démarrage de samba dans /etc/init.d.
A+
JJD
# Quelques outils
Posté par JJD . En réponse au message script envoi de sms. Évalué à 1.
Essaie de regarder du côté de smstools (http://smstools.meinemullemaus.de/ ) ou de smsclient (http://www.smsclient.org/ ).
Sinon, les téléphones portables acceptent pour la plupart les commandes AT et je pense qu'il doit être possible d'envoyer des SMS en utilisant ces commandes (j'avais joué un peu avec ça il y a quelques temps avec minicom ...).
A+
JJD
# Quel WM ?
Posté par JJD . En réponse au message Sortir proprement du WM. Évalué à 1.
Tout dépend du window-manager (ou de l'environnement du bureau) utilisé.
Avec gnome, il y a la commande gnome-session-save qui permet (malgré son nom) de terminer la session (cf entrée "Clore la session" du menu) avec ou sans fenêtre de confirmation.
Les autres environnements ont certainement des commandes équivalentes : il suffit de chercher un peu.
Ce qui est sûr, c'est que tu ne trouveras de commande magique fonctionnant partout avec tous les WM...
A+
JJD
[^] # Re: script de prise de personnalité
Posté par JJD . En réponse au message script de prise de personnalité. Évalué à 1.
Lorsque tu n'es pas root, il semble que su vérifie que le shell de maven1 (indiqué dans /etc/passwd) est bien présent dans /etc/shells.
Vérifie si par hasard, tu n'aurais pas "/bin/false" dans le fichier /etc/shells de la première machine et pas sur la deuxième (si tu rajoutes la ligne ça devrait fonctionner, mais il y aura peut-être des effects de bord).
Si la différence entre les deux machines n'est pas là, il faut peut être regarder du côté des versions de su installés (paquet login) et des fichiers de configuration de pam (/etc/pam.d/su ).
A+
JJD
# Contrôle des processus du shell
Posté par JJD . En réponse au message arrete des scripts lancé par un script. Évalué à 3.
Le shell offre certains mécanismes de contrôle des processus. Au moins avec bash (pour les autres [ksh, zsh, ...] il faudra vérifier ce que je raconte), il est possible de gérer assez finement ce qui se passe.
Regarde le manuel de bash (ou toute autre aide), et en particulier :
- trap : permet d'intercepter un signal et d'exécuter une action en fonction de ce signal. Tu peux par exemple intercepter le signal SIGTERM (15) pour aller tuer les processus fils
- jobs : cette comande interne permet de récupérer la liste des processus actifs avec leurs ID (jobs -l ou jobs -p)
- kill : pour envoyer un signal à un processus particulier. Essaie d'abord du tuer les fils avec un SIGTERM (15), avant d'envoyer un SIGKILL (9) : ça laissera une chance aux processus de se terminer proprement.
Avec ça tu devrais pouvoir commencer à correctement gérer les processus fils et les arrêts (pas trop) violents.
A+
JJD
[^] # Re: vieux souvenirs (la suite)
Posté par JJD . En réponse au message Certificat des Impôts dans Firefox sous Ubuntu Hoary. Évalué à 2.
Je fais également appel à mes vieux souvenirs de déclaration des revenus...
Donc, si je me souviens bien, pour que le site fonctionne, il faut effectivement accepter de récupérer une applet java (je ne sais plus si cela concerne l'autentification ou bien uniquement la déclaration de revenus en ligne). Or cette applet veut à tout prix s'installer dans un répertoire système (et non pas sous le $HOME de l'utilisateur). La seule façon que j'ai trouvé pour faire fonctionner ça a été de récupérer cette applet avec un navigateur (firefox) exécuté par root (!!!!).
Ensuite, tout a fonctionné correctement avec le brouteur s'exécutant sous un utilisateur quelconque.
Lors de la première utilisation, il faut demander un certificat (en fournissant un certain nombre d'informations afin de garantir son identité). ce certificat est stocké dans le répertoire $HOME/teleir.
Enfin, je tiens à souligner que j'ai également eu des soucis à signer ma déclaration : l'appli java des impots a (avait ?) des problèmes liés à la locale courante. La signature ne fonctionnait absolument pas si l'utilisateur utilisait de l'Unicode (UTF-8). Il a fallu que je passe en ISO8859-1 (ou ISO8859-15) afin de pouvoir valider la signature de ma déclaration.
J'espère que ces informations seront utiles à ceux qui me liront (et que le problème de l'unicode sera corrigé avant la prochaine déclaration).
JJD
[^] # Re: Fichier de paramétrage
Posté par JJD . En réponse au message Problème de configuration wifi. Évalué à 2.
# Fichier de paramétrage
Posté par JJD . En réponse au message Problème de configuration wifi. Évalué à 3.
Donc, tu dois pouvoir passer les paramètres à ta carte WIFI dans le fichier /etc/network/interfaces en y mettant quelque chose du genre :
auto wlan0 iface wlan0 inet dhcp wireless-essid ton_essid wireless-mode Managed wireless-channel 6 wireless-enc ta_clé_wepNormalement, tu as déjà une entrée wlan0 dans ce fichier (sinon la commande ifup wlan0 ne fonctionnerait pas). Il faut donc simplement que tu rajoutes les lignes wireless-* avec les paramètres qui vont bien.A+ JJD
[^] # Re: les remplacer...
Posté par JJD . En réponse au journal Debian : contrôle du démarrage des services. Évalué à 1.
Je ne comprends pas ce passage du manuel de la même façon que toi : s'il existe déjà un lien /etc/rcX.d/S??name, celui-ci n'est pas remplacé. C'est à dire que l'on peut modifier l'ordre d'exécution de ces scripts et que ces modifications sont conservées après les mises à jour.
En tout cas, il semble possible d'utiliser cela pour éviter le lancement de cetains démons, y compris après une mise à jour : il devrait suffire de créer un lien symbolique /etc/rcX.d/S??name vers un script qui ne fait rien. Lors des mises à jour, le lien symbolique existant, il ne sera pas remplacé.
JJD
# Accès HTTP à cups
Posté par JJD . En réponse au message Problème d'imprimante. Évalué à 2.
Peux-tu fournir plus d'information ?
Quelle URL utilises-tu pour accéder à l'interface HTTP de cups?
En fonction du paramétrage (cupsd.conf), les accès (au site ou à la partie administration) peuvent être autorisés sur l'adresse 127.0.0.1 (normalement localhost), mais pas avec l'adresse IP du serveur sur le réseau.
Est-ce que tu accèdes à la page d'accueil de cups ?
Est-ce que tu accèdes à certains des "menus"? (Imprimantes, Classes, Travaux, ...)
Quand tu essaies d'ajouter une imprimante (et que tu as une pop-up te demandant un user et un mot de passe), que se passe-t-il? Quel message d'erreur as-tu?
Ces informations permettront peut-être de mieux cerner le problème. Si ce n'est pas le cas, il faudra certainement que tu nous fournisses le fichier cupsd.conf.
A+
JJD
[^] # Re: libpam
Posté par JJD . En réponse au message [interface] changement de langue depuis la dernière MAJ. Évalué à 2.
[^] # Re: libpam
Posté par JJD . En réponse au message [interface] changement de langue depuis la dernière MAJ. Évalué à 2.
- "fr_FR" pour ISO-8859-1
- "fr_FR.UTF-8" ou "fr_FR.UTF-8@euro" pour utiliser de l'unicode.
Evidemment, après avoir modifié le fichier /etc/security/pam_env.conf (avec le user root), il faut que tu te délogues (fermeture de la session) et que tu te reconnectes pour que les chagements soient pris en compte. A+ JJD# libpam
Posté par JJD . En réponse au message [interface] changement de langue depuis la dernière MAJ. Évalué à 4.
En étant en SID on peut effectivement être sujet à ce type de désagrément.
Sinon, le problème ne vient pas de la mise à jour du noyaux ou des headers, mais de pam, et en particulier de libpam-modules (authentification). Le bug a été reporté : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330458(...)
Apparemment, il faut attendre pour que cela soit corrigé dans une prochaine mise à jour (/etc/environment n'est plus pris en compte), ou bien rajouter ce qu'il y a dans ce fichier (en particulier LANG=...) dans /etc/security/pam_env.conf (sous le format :
LANG DEFAULT=...
je n'ai pas encore testé, mais je vais voir ce que cela donne ...
A+
JJD
# Boot Loader
Posté par JJD . En réponse au message restaurer le système. Évalué à 2.
JJD
# Et comme ça ?
Posté par JJD . En réponse au message recherche et incremente un numero au fichier. Évalué à 2.
# configuration de logrotate
Posté par JJD . En réponse au message config logs. Évalué à 3.
Le fichier logrotate.conf te donne la configutation par défaut. De plus le paramètre "size" indique la taille limite pour laquelle il faut appliquer la règle adéquate : avec ta configuration, les fichiers de logs ne subiront une "rotation" que s'il dépassent les 2000MO, ce qui me semble énorme.
En revanche, dans la conf, il y a quelque chose d'intéressant :
include /etc/logrotate.d
Cette directive indique qu'il faut inclure les fichiers de conf contenus dans le répertoire /etc/logrotate.d. Pour information, sur mes machines, j'ai, dans de répertoire, un fichier "apache2" qui contient les lignes suivantes :
/var/log/apache2/*.log {
weekly
missingok
rotate 52
compress
delaycompress
notifempty
create 640 root adm
sharedscripts
postrotate
if [ -f /var/run/apache2.pid ]; then
/etc/init.d/apache2 restart > /dev/null
fi
endscript
}
Cela indique que tous les fichiers *.log du répertoire /var/log/apache2 subiront une rotation une fois par semaine, quelle que soit leur taille (pas de directive size), que 52 fichiers sont conservés sous une forme compressée (sauf le premier) et de plus apache est redémarré après la rotation de façon à ce que les fichiers de logs ouverts soient fermés (sans ça, apache va continuer à écrire dans le fichier renommé, c'est à dire access_log.1 au lieu de access_log).
Il te reste à adpter cela à tes besoins.
A part ça, il est fort possible que ton système de fichier limite la taille des fichiers à 2GO (ça dépend du FS utilisé et des options de formatage).
A+
JJD
[^] # Plus d'infos...
Posté par JJD . En réponse au message Pb avec mon interface graphique... Évalué à 2.
il est assez difficile de voir ce qui se passe lors du lancement du serveur X avec aussi peu d'informations.
Les fichiers intéressants sont /etc/X11/xorf.conf et /var/log/Xprg.0.log.
Pour les récupérer sur un autre disque, il y a plusieurs possibilités, ce qui rend assez difficile les conseils...
Enfin, essaie de taper la commande "mount" : si un disque Windows est accessible tu devrais voir une ligne commençant pas /dev/hda1 (si ton disque Windows est sur la première partition). Sur la ligne en question, tu verras alors le point de montage (c'est à dire l'endroit de ton arborescence où ta partition Windows est accéssible, par exemple /mnt/windows). Si tout va bien, tu peux copier les fichiers avec la comande "cp /etc/X11/xorf.conf /mnt/windows".
Tu peux aussi essayer de mettre les fichiers sur une clé USB. Insère ta clé et tappe la commande mount. Si tu vois quelque chose relatif à de l'USB tu peux copier les fichiers avec la commande cp. Sinon, essaie de monter ta clé en tapant "mount /dev/sda1 /mnt" : la clé sera alors accessible sur le chemin /mnt/ (s'il n'y a pas d'erreur).
Si tout cela échoue, le mieux serait que tu trouves quelqu'un dans ton entourage connaissant Linux et pouvant se déplacer chez toi : tous les forums ne remplaceront jamais le contact direct...
A+
JJD