> [Wed Jul 13 23:49:06 2005] [jk_ajp_common.c (1198)]: Error
> connecting to tomcat. Tomcat is probably not started or is listenning > on the wrong port. Failed errno = 2
Le connecteur mod_jk s'attend à parler à tomcat sur le port 8009 sur 127.0.0.1. De deux choses l'une :
* ou tomcat est démarré et n'écoute pas sur le port 8009. Envoie-nous ton server.xml
* ou tomcat n'est pas démarré. Je suis désolé de rappeler des évidences, mais apache n'**embarque** pas tomcat comme il embarque php ou mod_perl. tomcat est un processus séparé que
tu dois démarrer à part.
Qu'est-ce qui se passe si tu fais un telnet 127.0.0.1 8009
* tu as un soft qui ne marche sur un OS donné.
* l'OS en question ne marche pas sur ton matériel.
Tu as deux approches :
1) ou tu essaies d'adapter l'OS pour le faire marcher sur ton matériel.
2) ou tu essaies d'adatper l'OS pour faire marcher le soft en question.
Mon avis est que la solution 2) est préférable, parce que si tu restes bloquée sur une Mandrake 9.2, celle-ci ne sera bientôt plus supportée (c'est même peut-être déjà le cas), et tu n'auras plus
de mises à jour de sécurité ou de corrections de bug.
Donc je pense que avant d'essayer de bidouiller l'OS pour le faire marcher sur ton matériel, tu devrais essayer d'explorer la deuxième piste. Ca te donnera un environnement plus propre et plus pérenne, tu ne crois pas ?
Pour Motif, il y a deux types de bibliothèques que tu peux installer. Lesstif, qui est en GPL vient avec toutes les distributions Linux (dont Mandriva), et qui permet de faire marcher des applications Motif simples. Mais je pense que dans ton cas ça ne marchera pas, parce qu'il ne doit y avoir qu'une compatibilité source, pas une compatibilité binaire.
Il y a aussi OpenMotif dont tu peux télécharger les sources ici : http://www.opengroup.org/openmotif/downloads.html.(...) La license d'OpenMotif n'est pas considérée comme Open Source - en fait, les
sources sont disponibles, mais tu dois t'enregistrer pour la télécharger, et tu t'engages à ne les utiliser que sur des systèmes Open source (*BSD ou Linux, pas Solaris, AIX ou HP-UX), donc les
distributions ne les proposent pas toujours.
Il y a des rpm sur rpmfind.net - pas pour Mandriva malheureusement. Je ne connais pas bien les systèmes à base de rpm, donc je ne sais pas jusqu'à quel point on peut installer un package Fedora FC3 sur une Mandriva 10.2 ... Mais tu peux peut-être partir du src.rpm pour FC3, le bidouiller et le compiler sur une Mandriva 10.2 pour distribuer le rpm compilé à tes utilisateurs.
En fait dans sa configuration de base, tu appelles un programme appelé "kinit", tu fournis ton nom d'utilisateur et un mot de passe, et le "serveur Kerberos", il te donne un "ticket", qui est stocké sous forme d'un petit fichier.
Les noms consacrés pour le nom d'utilisateur sont "principal", et pour ce que j'ai appelé "serveur Kerberos", on parle
de KDC (key distribution center).
Après tu peux théoriquement utiliser le ticket pour te connecter au différents services, sans avoir à te resigner. Mais c'est là que ça devient compliqué. Il faut que les services soient "kerbérisés", ce qui signifie que :
* le code du programme (serveur et client) doit être spécifiquement prévu pour supporter Kerberos. Il existe des versions kerberisées de telnet, ftp, rlogin. openssh, postgresql, samba, openldap, firefox, lynx.... Il existe un module kerberos pour apache. Le futur NFSv4 devrait le supporter.
* le programme (serveur et client) doit être compilé avec le support Kerberos, ce qui n'est pas toujours le cas, ni dans les distributions Linux ni dans les Unix propriétaires. Dans Debian 3.1 (Sarge), la plupart des packages ont l'air d'être systématiquement kerberisés (postgreql, firefox, ssh), mais ce n'était pas le cas de Debian 3.0 (Woody), par exemple. L'adoption de Kerberos a été longue, à cause des restrictions à l'exportation des logiciels de cryptage aux USA.
* le programme (serveur) doit être configuré pour supporter Kerberos. En gros il faut déclarer un utilisateur (principal) pour le service, générer une clef, et l'ajouter dans un fichier de configuration (/etc/krb5.keytab, de mémoire) sur la machine sur laquelle tourne le service.
* l'implémentation entre le client et le serveur doivent être compatibles. Par exemple, la kerberisation d'openssh est encore
considérée par les auteurs du programme comme expérimentale. Entre les version 3.7 et 3.8 elle a changé sans préavis. Ce qui fait que le client openssh kerberisé sous Woody est incompatible avec le serveur sous Sarge (et réciproquement).
Pour ce qui est de Windows, l'infrastructure Active Directory repose sur Kerberos 5. Un serveur Active Directory peut être très facilement utilisé comme KDC par des machines UNIX, mais naturellement l'inverse est plus difficile, car Active Directory est plus que Kerberos 5. A priori le futur Samba 4 devrait pouvoir agir comme un contrôleur de domaine Active Directory.
Pour résumer, la réponse est oui, mais il faut que tu regardes avec attention les services que tu veux déployer et les postes client que tu utilises ...
Bon je viens de relire ton post et de voir que les machines étaient bien à la même date.
Ceci dit :
* l'utilisation de xntpd assure une synchronisation continue, ce qui n'est pas le cas de ntpdate, mais ceci dit j'utilise ntpd et j'ai le même problème ici.
* ensuite, vu les noms, tu veux tester ton makefile pour une des compilations. Il faut bien voir qu'il y a une différence entre touch et cc.
touch intervient sur la date et l'heure du fichier. C'est donc une opération extrêmement courte, alors qu'une compilation est beaucoup plus longue. Même avec xntpd, la synchronisation n'est pas parfaite vu que touch est très courte, tu tombes au-dessous de la marge d'erreur
de make.
En outre, j'ai le problème si je boucle sans temporisation. En faisant la boucle avec une temporisation de 1s, je n'ai plus d'erreur. Un développeur ne va pas s'amuser à compiler plusieurs fois par secondes pas vrai ?
Il n'y a normalement pas de problème pour utiliser make sur NFS, sauf que pour travailler, make utilise les dates des fichiers.
Il faut donc absolument que la date sur ton client et ton serveur
soient parfaitement synchronisés. Je te conseille d'utiliser NTP.
xntpd est normalement fourni sur tous les UNIX propriétaires, et aussi
sur la plupart des distributions Linux.
Je ne vois pas le contenu de ton fichier server.xml.
Vérifier que tu as bien un Connector Coyote/JK2 AJP 1.3 sur le port 8009 (pour rester cohérent avec ton fichier workers.properties).
Normalement, l'entrée existe dans le fichier livré par défaut. Il suffit
de la décommenter - la déclaration dans ton cas ne sera probablement pas tout à fait la même car j'utilise Tomcat 4.
Il n'est pas recommandé d'utiliser dd pour faire un backup. Je ne sais pas exactement à quoi ça tient - je ne me suis jamais penché sur les arcanes des systèmes de fichiers - mais je crois que le résultat va dépendre de la géométrie de ton disque dur, ce qui fait que tu ne pourras le restaurer que sur un disque dur de même modèle.
Utilise tar pour faire un backup. En ce qui me concerne, j'utilise la commande suivante pour backuper tout mon système sur bande.
> tar -c --exclude=/dev/* --exclude=/proc/* -f backup.tar /
Tu peux rajouter les options -z (pour compresser avec gzip), -p (pour préserver les permissions).
Si tu ne veux sauvegarder que le système de fichier root, il a aussi une option pour ça (regarde la page de man / info). Si tu fais ça, évidemment les options --exclude deviennent inutiles.
pour le lire, et après tu peux accéder aux valeurs de VAR1 et VAR2 depuis ton shell. En théorie, il faut un truc pour locker le fichier (tu peux utiliser un fichier fichier.lck, par exemple) pour être sûr que l'un n'est pas en train de lire/écrire en même temps que l'autre.
En outre, il faudrait faire gaffe à la sécurité, parce que l'autre pourrait mettre des trucs méchants (genre "rm -rf $HOME/" dans fichier.tmp au pire, ou au mieux bidouiller les données de l'autre). Mais bon le fait de partager un même compte n'est pas terrible pour la sécurité de toute façon...
OK, je comprends. Est-ce que tu peux nous donner exactement le sujet de ton exercice ?
A quoi tu as droit et à quoi tu n'as pas droit. Parce que c'est clair qu'avec du shell tout seul, tu n'arriveras jamais à partager des données entre deux machines.
Tu peux utiliser soit netpipes déjà mentionné, soit un shell distant (ssh, rsh, rlogin, rexec), soit ftp ou le mail.
Et n'oublie pas que multi-utilisateurs ça veut pas dire forcément plusieurs machines, on est sous UNIX qui est multi-utilisateurs depuis 1970.
Si je comprends bien, tu veux faire du réseau avec du shell script ... Pour cela, il existe un programme appelé netpipes, que tu trouveras à cette adresse :
Je ne sais pas dans quelle mesure il existe des packages pour les différentes distributions. Pour debian, ça a l'air d'exister pour unstable, <troll> c'est à dire celle qui devrait sortir en 2008</troll>.
Mais bon, le shell script c'est pas terrible pour faire du réseau, c'est même pas terrible pour la programmation tout court dès que ça devient un peu trop compliqué. En ce qui me concerne, je n'arrive jamais à me souvenir comment faire ne serait-ce que deux if imbriqués ou même une comparaison numérique, autant dire que je suis très admiratif que tu sois déjà arrivé jusqu'ici. Donc si ce n'est pas pour un exercice de style (après tout il y a bien un fou qui a réussi à implémenter sokoban en ... sed), je te conseille de passer à un langage de programmation plus adapté : perl, tcl, python, ruby, lisp, pour ne rester qu'aux langages interprétés : tu as le choix. Ils ont tous des supports réseaux, soit intégrés directement dans le langage, soit sous forme de module. Tu verras que tu souffriras beaucoup moins ...
Et bien j'avais exactement le même comportement avec mon fichier au format DOS. Ce sera la même chose si tu as des caractères non imprimable après le #!/bin/bash
Tape
> xxd ./test.sh
ce qui nous donnera le dump en hexa du fichier et envoie le résultat ...
(installe xxd au besoin, ça vient avec vim, je crois ...)
En fait j'ai déjà rencontré ce problème il y a quelques temps ...
J'avais un fichier shell du même genre, disons hello.sh
> #!/bin/sh
> echo "hello world"
si je faisais
> ./hello.sh
J'obtenais
> No such file or directory
et si je faisais
> bash ./hello.sh
ça marchait. La raison ? Par une diablerie inexplicable, le fichier était au format DOS. Regarde dans la barre en bas de Vim si tu n'as pas marqué [dos] dans la barre en bas.
Fichier-> Enregistrer sous.
Choisir le type de fichier "Microsoft Word 97".
Si l'éditeur d'équations d'openoffice est incompréhensible, celui de Word est très pénible pour des équations complexes. C'est typiquement LE cas où apprendre LaTeX est un excellent investissement (à supposer que tu aies le choix des armes pour le format de publication de ton papier).
[^] # Re: Quelques conseils
Posté par tontonflingueur . En réponse au message Apache 2, Tomcat 5, mod_jk. Évalué à 1.
> [Wed Jul 13 23:49:06 2005] [jk_ajp_common.c (1198)]: Error
> connecting to tomcat. Tomcat is probably not started or is listenning > on the wrong port. Failed errno = 2
Le connecteur mod_jk s'attend à parler à tomcat sur le port 8009 sur 127.0.0.1. De deux choses l'une :
* ou tomcat est démarré et n'écoute pas sur le port 8009. Envoie-nous ton server.xml
* ou tomcat n'est pas démarré. Je suis désolé de rappeler des évidences, mais apache n'**embarque** pas tomcat comme il embarque php ou mod_perl. tomcat est un processus séparé que
tu dois démarrer à part.
Qu'est-ce qui se passe si tu fais un telnet 127.0.0.1 8009
@+
[^] # Re: RE: salut je voudrai installer une version antérieur a celle que ...
Posté par tontonflingueur . En réponse au message salut je voudrai installer une version antérieur a celle que j'ai déja, comment faire... (problème SATA). Évalué à 1.
* tu as un soft qui ne marche sur un OS donné.
* l'OS en question ne marche pas sur ton matériel.
Tu as deux approches :
1) ou tu essaies d'adapter l'OS pour le faire marcher sur ton matériel.
2) ou tu essaies d'adatper l'OS pour faire marcher le soft en question.
Mon avis est que la solution 2) est préférable, parce que si tu restes bloquée sur une Mandrake 9.2, celle-ci ne sera bientôt plus supportée (c'est même peut-être déjà le cas), et tu n'auras plus
de mises à jour de sécurité ou de corrections de bug.
Donc je pense que avant d'essayer de bidouiller l'OS pour le faire marcher sur ton matériel, tu devrais essayer d'explorer la deuxième piste. Ca te donnera un environnement plus propre et plus pérenne, tu ne crois pas ?
@+
# RE: salut je voudrai installer une version antérieur a celle que ...
Posté par tontonflingueur . En réponse au message salut je voudrai installer une version antérieur a celle que j'ai déja, comment faire... (problème SATA). Évalué à 1.
Il y a aussi OpenMotif dont tu peux télécharger les sources ici : http://www.opengroup.org/openmotif/downloads.html.(...) La license d'OpenMotif n'est pas considérée comme Open Source - en fait, les
sources sont disponibles, mais tu dois t'enregistrer pour la télécharger, et tu t'engages à ne les utiliser que sur des systèmes Open source (*BSD ou Linux, pas Solaris, AIX ou HP-UX), donc les
distributions ne les proposent pas toujours.
Il y a des rpm sur rpmfind.net - pas pour Mandriva malheureusement. Je ne connais pas bien les systèmes à base de rpm, donc je ne sais pas jusqu'à quel point on peut installer un package Fedora FC3 sur une Mandriva 10.2 ... Mais tu peux peut-être partir du src.rpm pour FC3, le bidouiller et le compiler sur une Mandriva 10.2 pour distribuer le rpm compilé à tes utilisateurs.
@+
# RE: Kerberos et SSO.
Posté par tontonflingueur . En réponse au message Kerberos et SSO. Évalué à 2.
En fait dans sa configuration de base, tu appelles un programme appelé "kinit", tu fournis ton nom d'utilisateur et un mot de passe, et le "serveur Kerberos", il te donne un "ticket", qui est stocké sous forme d'un petit fichier.
Les noms consacrés pour le nom d'utilisateur sont "principal", et pour ce que j'ai appelé "serveur Kerberos", on parle
de KDC (key distribution center).
Après tu peux théoriquement utiliser le ticket pour te connecter au différents services, sans avoir à te resigner. Mais c'est là que ça devient compliqué. Il faut que les services soient "kerbérisés", ce qui signifie que :
* le code du programme (serveur et client) doit être spécifiquement prévu pour supporter Kerberos. Il existe des versions kerberisées de telnet, ftp, rlogin. openssh, postgresql, samba, openldap, firefox, lynx.... Il existe un module kerberos pour apache. Le futur NFSv4 devrait le supporter.
* le programme (serveur et client) doit être compilé avec le support Kerberos, ce qui n'est pas toujours le cas, ni dans les distributions Linux ni dans les Unix propriétaires. Dans Debian 3.1 (Sarge), la plupart des packages ont l'air d'être systématiquement kerberisés (postgreql, firefox, ssh), mais ce n'était pas le cas de Debian 3.0 (Woody), par exemple. L'adoption de Kerberos a été longue, à cause des restrictions à l'exportation des logiciels de cryptage aux USA.
* le programme (serveur) doit être configuré pour supporter Kerberos. En gros il faut déclarer un utilisateur (principal) pour le service, générer une clef, et l'ajouter dans un fichier de configuration (/etc/krb5.keytab, de mémoire) sur la machine sur laquelle tourne le service.
* l'implémentation entre le client et le serveur doivent être compatibles. Par exemple, la kerberisation d'openssh est encore
considérée par les auteurs du programme comme expérimentale. Entre les version 3.7 et 3.8 elle a changé sans préavis. Ce qui fait que le client openssh kerberisé sous Woody est incompatible avec le serveur sous Sarge (et réciproquement).
Pour ce qui est de Windows, l'infrastructure Active Directory repose sur Kerberos 5. Un serveur Active Directory peut être très facilement utilisé comme KDC par des machines UNIX, mais naturellement l'inverse est plus difficile, car Active Directory est plus que Kerberos 5. A priori le futur Samba 4 devrait pouvoir agir comme un contrôleur de domaine Active Directory.
Pour résumer, la réponse est oui, mais il faut que tu regardes avec attention les services que tu veux déployer et les postes client que tu utilises ...
Voilà
[^] # Options sync et no_wdelay sur exports sync et dirsync au mount
Posté par tontonflingueur . En réponse au message NFS et Makefile. Évalué à 1.
* les options sync et no_wdelay au niveau de l'exports.
* sync et dirsync sur mount.
@+
# Est-ce si grave finalement ?
Posté par tontonflingueur . En réponse au message NFS et Makefile. Évalué à 2.
Ceci dit :
* l'utilisation de xntpd assure une synchronisation continue, ce qui n'est pas le cas de ntpdate, mais ceci dit j'utilise ntpd et j'ai le même problème ici.
* ensuite, vu les noms, tu veux tester ton makefile pour une des compilations. Il faut bien voir qu'il y a une différence entre touch et cc.
touch intervient sur la date et l'heure du fichier. C'est donc une opération extrêmement courte, alors qu'une compilation est beaucoup plus longue. Même avec xntpd, la synchronisation n'est pas parfaite vu que touch est très courte, tu tombes au-dessous de la marge d'erreur
de make.
En outre, j'ai le problème si je boucle sans temporisation. En faisant la boucle avec une temporisation de 1s, je n'ai plus d'erreur. Un développeur ne va pas s'amuser à compiler plusieurs fois par secondes pas vrai ?
@+
# NFS + Makefile : synchronisation de l'heure nécessaire.
Posté par tontonflingueur . En réponse au message NFS et Makefile. Évalué à 0.
Il faut donc absolument que la date sur ton client et ton serveur
soient parfaitement synchronisés. Je te conseille d'utiliser NTP.
xntpd est normalement fourni sur tous les UNIX propriétaires, et aussi
sur la plupart des distributions Linux.
@+
[^] # Re: Tu dois ajouter un dans ton server.xml
Posté par tontonflingueur . En réponse au message Apache 2, Tomcat 5, mod_jk. Évalué à 1.
Autre question tomcat est bien démarré ?
$CATALINA_HOME/bin/startup.sh (de mémoire). Donc dans ton cas ça doit être /usr/local/bin/startup.sh
@+
# Tu dois ajouter un dans ton server.xml
Posté par tontonflingueur . En réponse au message Apache 2, Tomcat 5, mod_jk. Évalué à 1.
Vérifier que tu as bien un Connector Coyote/JK2 AJP 1.3 sur le port 8009 (pour rester cohérent avec ton fichier workers.properties).
La déclaration est comme suit :
<Connector className="org.apache.ajp.tomcat4.Ajp13Connector"
port="8009" minProcessors="5" maxProcessors="75"
acceptCount="10" debug="0"/>
Normalement, l'entrée existe dans le fichier livré par défaut. Il suffit
de la décommenter - la déclaration dans ton cas ne sera probablement pas tout à fait la même car j'utilise Tomcat 4.
@+
# Ah non, utilise tar !!!
Posté par tontonflingueur . En réponse au message commande DD pour faire un backup de mon Système de Fichiers Gentoo. Évalué à 1.
Utilise tar pour faire un backup. En ce qui me concerne, j'utilise la commande suivante pour backuper tout mon système sur bande.
> tar -c --exclude=/dev/* --exclude=/proc/* -f backup.tar /
Tu peux rajouter les options -z (pour compresser avec gzip), -p (pour préserver les permissions).
Si tu ne veux sauvegarder que le système de fichier root, il a aussi une option pour ça (regarde la page de man / info). Si tu fais ça, évidemment les options --exclude deviennent inutiles.
# sourceforge.net ou savannah.org
Posté par tontonflingueur . En réponse au message Développement collaboratif. Évalué à 3.
Il y a quelques services par défaut, dont un CVS, des mailing-lists, un espace pour héberger sa documentation, ...
@+
PS : mais je suis d'accord que subversion est mieux que cvs.
# Re : l'adresse IP
Posté par tontonflingueur . En réponse au message l'adresse IP. Évalué à 2.
@+
[^] # Re: Le script, il sent fort de la bouche ?
Posté par tontonflingueur . En réponse au message Multi utilisateurs d'un script. Évalué à 1.
> echo > fichier.tmp << EOF
> VAR1=var1
> VAR2=var2
> EOF
Pour l'écrire, et
> . fichier.tmp
pour le lire, et après tu peux accéder aux valeurs de VAR1 et VAR2 depuis ton shell. En théorie, il faut un truc pour locker le fichier (tu peux utiliser un fichier fichier.lck, par exemple) pour être sûr que l'un n'est pas en train de lire/écrire en même temps que l'autre.
En outre, il faudrait faire gaffe à la sécurité, parce que l'autre pourrait mettre des trucs méchants (genre "rm -rf $HOME/" dans fichier.tmp au pire, ou au mieux bidouiller les données de l'autre). Mais bon le fait de partager un même compte n'est pas terrible pour la sécurité de toute façon...
[^] # Re: Le script, il sent fort de la bouche ?
Posté par tontonflingueur . En réponse au message Multi utilisateurs d'un script. Évalué à 1.
A quoi tu as droit et à quoi tu n'as pas droit. Parce que c'est clair qu'avec du shell tout seul, tu n'arriveras jamais à partager des données entre deux machines.
Tu peux utiliser soit netpipes déjà mentionné, soit un shell distant (ssh, rsh, rlogin, rexec), soit ftp ou le mail.
Et n'oublie pas que multi-utilisateurs ça veut pas dire forcément plusieurs machines, on est sous UNIX qui est multi-utilisateurs depuis 1970.
[^] # Re: Le script, il sent fort de la bouche ?
Posté par tontonflingueur . En réponse au message Multi utilisateurs d'un script. Évalué à 1.
http://web.purplefrog.com/~thoth/netpipes/ftp/(...)
Je ne sais pas dans quelle mesure il existe des packages pour les différentes distributions. Pour debian, ça a l'air d'exister pour unstable, <troll> c'est à dire celle qui devrait sortir en 2008</troll>.
Mais bon, le shell script c'est pas terrible pour faire du réseau, c'est même pas terrible pour la programmation tout court dès que ça devient un peu trop compliqué. En ce qui me concerne, je n'arrive jamais à me souvenir comment faire ne serait-ce que deux if imbriqués ou même une comparaison numérique, autant dire que je suis très admiratif que tu sois déjà arrivé jusqu'ici. Donc si ce n'est pas pour un exercice de style (après tout il y a bien un fou qui a réussi à implémenter sokoban en ... sed), je te conseille de passer à un langage de programmation plus adapté : perl, tcl, python, ruby, lisp, pour ne rester qu'aux langages interprétés : tu as le choix. Ils ont tous des supports réseaux, soit intégrés directement dans le langage, soit sous forme de module. Tu verras que tu souffriras beaucoup moins ...
# Re : espace libre sur disque dur USB
Posté par tontonflingueur . En réponse au message espace libre sur disque dur USB. Évalué à 3.
Dans ce cas, rajoute l'option "-x" à du.
[^] # Re: Est-ce un fake? : non pas forcément ...
Posté par tontonflingueur . En réponse au message script bash. Évalué à 1.
Tape
> xxd ./test.sh
ce qui nous donnera le dump en hexa du fichier et envoie le résultat ...
(installe xxd au besoin, ça vient avec vim, je crois ...)
A+
[^] # Re: Est-ce un fake? : non pas forcément ...
Posté par tontonflingueur . En réponse au message script bash. Évalué à 2.
J'avais un fichier shell du même genre, disons hello.sh
> #!/bin/sh
> echo "hello world"
si je faisais
> ./hello.sh
J'obtenais
> No such file or directory
et si je faisais
> bash ./hello.sh
ça marchait. La raison ? Par une diablerie inexplicable, le fichier était au format DOS. Regarde dans la barre en bas de Vim si tu n'as pas marqué [dos] dans la barre en bas.
# Re : convertir sxw en doc
Posté par tontonflingueur . En réponse au message convertir sxw en doc. Évalué à 1.
Choisir le type de fichier "Microsoft Word 97".
Si l'éditeur d'équations d'openoffice est incompréhensible, celui de Word est très pénible pour des équations complexes. C'est typiquement LE cas où apprendre LaTeX est un excellent investissement (à supposer que tu aies le choix des armes pour le format de publication de ton papier).
[^] # Re: adapter les scripts
Posté par tontonflingueur . En réponse à la dépêche Sortie de mod_perl 2.0.0. Évalué à 7.
> User Contributed Perl Documentation Apache::Registry(3)
>
>
>
> NAME
> Apache::Registry - Run unaltered CGI scrips under mod_perl
>
>SYNOPSIS
> #in httpd.conf
>
> Alias /perl/ /perl/apache/scripts/ #optional
> PerlModule Apache::Registry
>
> <Location /perl>
> SetHandler perl-script
> PerlHandler Apache::Registry
> Options ExecCGI
>
[^] # Re: ldconfig ?
Posté par tontonflingueur . En réponse au message Impossible de compiler qemu.. Évalué à 2.
./configure --prefix=/usr/local --target-list=i386-softmmu &&
make &&
make install
apparemment c'est le --target-list=i386-softmmu qui fait toute la différence.
A+
[^] # Re: ldconfig ?
Posté par tontonflingueur . En réponse au message Impossible de compiler qemu.. Évalué à 2.
Si tu veux bien attendre quelques jour que j'aie accès à la machine sur laquelle j'avais fait le test, je pourrai te poster mes scripts de compil ...
A+
[^] # Re: ldconfig ?
Posté par tontonflingueur . En réponse au message Impossible de compiler qemu.. Évalué à 1.
Si tu veux bien attendre quelques jour que j'aie accès à la machine sur laquelle j'avais fait le test, je pourrai te poster mes scripts de compil ...
A+
[^] # Re: ldconfig ?
Posté par tontonflingueur . En réponse au message Impossible de compiler qemu.. Évalué à 1.
> gcc -static
J'ai eu le meme problème, mais je ne sais plus du tout comment je l'ai résolu... Il me semble qu'il y a un flag dans le configure de qemu ...
A+
# C'est la propriété "user.dir".
Posté par tontonflingueur . En réponse au message obternir le repertoire courant.. Évalué à 3.
String plop = System.getProperty("user.dir");
par contre ne me demande pas comment changer le répertoire courant : je ne sais pas...
A+
Luc