tontonflingueur a écrit 196 commentaires

L'erreur est ici :

> [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


@+

Ton problème est le suivant :

* 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 théorie, oui c'est le but de Kerberos.

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à

Est-ce que vous avez essayé les options les plus dures (les plus synchrones) :

* les options sync et no_wdelay au niveau de l'exports.

* sync et dirsync sur mount.

@+

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.

@+

Oui je suis désolé, je suis sous tomcat 4, mais je l'ai bien précisé dans mon post ...

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

@+

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).

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.

@+

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.

Le plus simple, à mon avis : faire héberger ton projet sur un site prévu pour ça, par exemple sourceforge.net ou savannah.org.

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.

Normalement c'est /sbin/ifconfig.

@+

Ah bah ça c'est facile. Tu peux par exemple faire quelque chose comme

> 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...

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 :

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 ...

Une hypothèse : tu n'aurais pas d'autres systèmes de fichiers montés sour /LaCie, qui seraient pris en compte dans du ?

Dans ce cas, rajoute l'option "-x" à du.

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 ...)

A+

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).

Avec Apache::Registry, si (à quelques subtilités près, liées au fait que les scripts ne sont compilés qu'une seule fois).

> 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
>

Voilà le script de compil que j'ai utilisé

./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+

Je crois que finalement j'avais compilé sans support de la SDL (ce n'est pas obligatoire, il me semble).

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+

Je crois que finalement j'avais compilé sans support de la SDL (ce n'est pas obligatoire, il me semble).

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+

Ldconfig ne fera rien. Le problème c'est que tu compiles (link-edit, plutot) en "static". Il recherche donc la libX11.a

> 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+

Il faut utiliser :

String plop = System.getProperty("user.dir");


par contre ne me demande pas comment changer le répertoire courant : je ne sais pas...

A+
Luc