Salut,
Je viens d'installer (hier, pendant la nuit) le client Boinc sur un PC tournant sur un vieux linux (Mandrake 9.1).
Il se trouve à distance, et je n'ai pas d'interface graphique dessus, alors je me suis débrouillé pour l'atteindre grace à mon Windows que j'ai chez moi. Tout va bien
 
Je l'ai lancé hier, en mettant comme premier projet SETI@home. Il a commencé à DL des trucs, tout avait l'air ok. Cependant, je ne l'avais pas lancé en background, et quand j'ai quitté ma console, ben tout s'est arrêté. J'ai essayé de le relancer, j'ai eu des pb, j'ai viré le fichier keylog, finalement après quelques manip, j'ai réussi à le faire tourner à nouveau.
les autres projets fonctionnent bien (download ce qu'il faut, quand ils peuvent, ou indiquent qu'il n'y a pas de boulot disponible), mais en ce qui concerne SETI@Home, j'ai ce message en rouge qui apparaît dans ma console :  
 
09/06/2007 11:43:35||[error] Can't create HTTP response output file projects/setiathome.berkeley.edu/setiathome-5.12.i686-pc-linux-gnu.so
09/06/2007 11:43:35|SETI@home|Backing off 2 hr 44 min 0 sec on download of file setiathome-5.12.i686-pc-linux-gnu.so
 
(la date changeant, et le fichier voulant être téléchargé aussi). Les fichiers étant les fichiers de "base", j'imagine.
 
Je pensais qu'il s'agissait d'un problème au niveau du serveur SETI@home, mais j'ai lancé le client sur mon PC windows, et il arrive à récupérer les fichiers nécessaires.
 
Avez-vous déjà eu ce problème ? Si oui, comment le régler ?  
 
Merci d'avance !

Rien que ça j'aimerai vérifier. Tu as mis VNC server sur ton linux que tu pilotes via VNC client sur ton poste Windows. C'est ça ?
 
Mais c'est le coup de je n'ai pas d'interface graphique qui me perturbe  
 
Je vais peut être dire une connerie mais le user qui se connecte à distance il a le droit d'écriture sur ton répertoire BOINC ?

Ligne de commande rewlz, spèce de lamerzzzz  
 
Bon, blague à tabac part, le backing off montre que le client seti est en ordre de marche. il rate la connexion alors il réssaye plus tard en choisissant un délai aléatoire.
pour le ratage de la connexion, pas d'idée par contre  

Oui, effectivement, je fais toutes les manips par SSH. Je vais expliquer un peu comment je procède, ça peut servir :
 
- Tout d'abord lancer une première fois le client : ./boinc
l'arréter :

 
- Ouvrir le fichier  gui_rpc_auth.cfg : dedans se trouve un pass généré par le client, qui est le pass permettant le monitoring à distance. On peut changer le pass indiqué.
 
- Ensuite, 2 possibilités : On se trouve sur une adresse fixe, et on pense ne se connecter que de son adresse. Dans ce cas on crée un fichier nommé remote_host.cfg, et dedans on entre simplement la ou les adresses avec lesquelles ont souhaite prendre la main à distance. Je ne sais pas comment faire par contre pour entrer des plages d'adresse (j'ai essayé avec 255, mais cela ne fonctionnait pas).
2nd cas, qui me conserne, mon IP changeant tous les jours :  
On démarre le client avec le paramètre : -allow_remote_gui_rpc
Je démarre aussi en bacground, pour que je puisse fermer ma console, ce qui donne :  

(le & étant là pour lancer en background).
 
- J'oublie pas d'ouvrir les ports qu'il faut (le 31416) sur mon firewall, et a priori, on a rien oublié.
 
Voilà donc comment je procède, je n'ai pas à utiliser le moniteur sous linux, et de toute façon aujourd'hui j'étais devant le serveur, avec un KDE, j'ai essayé de le lancer mais il a refusé (il manque des librairies que je ne peux pas installer sans tout mettre à jour mon linux, apparement).
 
Donc OSEF.
 
Maintenant, oui, sur mon windows, pour SETI tout va bien. Je viens de rentrer, et je constate que sur le linux, il y a toujours le même truc.
Je suppose donc qu'il y a un fichier de config où quelque chose, peut-être à réinitialiser (supprimer quoi), je sais pas quoi CAR : la première fois que j'ai lancé le client, comme je l'ai dit, il a réussi à télécharger les premiers fichiers. Je vais essayer de voir de ce coté, en espérant pas tout supprimer les paramètres des autres projets.
 
Enfin, si vous avez une idée, n'hésitez pas.  
 
Je me suis mis à ce truc hier soir, de 10 h à 3 h du mat, et ça me passionne déjà je connaissais pas vraiment le principe avant cela, mais c'est pas mal, de se dire qu'on participe à un truc global (moi ce qui me fait juste un peu peur, c'est de penser qu'il y a p e des gens qui utiliseront ces procédé pas pour des trucs honorables comme la recherche contre des maladies, mais pour détruire le monde où des trucs comme ça).  

Bon ben voilà, c'est résolu
Il s'agissait simplement d'un problème de droits :  
dans le dossiers /project, le dossier  setiathome.berkeley.edu avec comme propriétaire root, du au fait qu'au premier lancement, j'avais du oublier de changer d'utilisateur. Le message d'erreur indiquait simplement qu'il ne pouvait pas écrire dans ce dossier.
Je rappelle pour changer les droits :

où -R indique qu'on veut changer les droits pour les sous-dossiers et fichiers contenus dans le dossier, récurcivement, boinc est le nom de l'utilisateur, et setiathome.berkeley.edu le nom du répertoire
 
Au passage, d'après mes recherches sur internet sur ce problème, celui-ci peut intervenir aussi sur des systèmes Windows. Le problème a priori est alors identique (problème de droit du dossier du projet, où encore, le dossier peut être endommagé : impossible d'écrire dedans, de le supprimer, etc.).
 
Voilà, si des personnes ont des questions sur le fonctionnement sous linux, ils peuvent se mettrent en relation avec moi, qu'on découvre ensemble

 
Ou avec moi  
 

Ce que tu as mis en gras n'a pas vraiment de rapport en fait
Le problème n'était pas du tout lié à la prise en main du client à distance, mais à l'écriture du client sur le disque dur, dans des répertoire ou le client n'avait pas les droits appropriés.
 
En gros, je m'étais créé un utilisateur 'boinc', avec lequel j'ai lancé le client. Malheureusement, j'avais auparavant lancé une première fois le client en SU, et certains dossiers avaient donc reçu les privilèges root, et était donc inaccessible en écriture pour les autres utilisateurs.
 
Pour la connexion à distance, comme je l'ai dit, il suffit simplement d'autoriser l'adresse distante de connexion, par une des deux méthodes que j'ai précisé, et de récupérer le mot de passe dans le fichier gui_rpc_auth.cfg. Et bien sur de configurer son firewall pour ouvrir les ports qu'écoute le client.

Yep c'est pour ça que jai demandé si on user avait le droit d'écrire dans le répertoire  
 
Non mais