Gecko64

J'espère aussi mais je me prépare quand même si il ne le faisait pas. Il aurait parlé de faire 6 DC en plus hors de France de ce que j'ai entendu dire. Du côté de Online, où je suis aussi, ils n'ont pas encore pris de décision ce qui ne m'a pas empêché de leur mettre la pression.

Bonjour, j'ai appris que la loi sur le renseignement était passée en France. Du coup, je cherche un nouvel hébergeur qui est hors de France et du Canada et qui proposerait des services similaires du style Kimsufi ou à ce qu'on retrouve sur Soyoustart. Je ne sais pas si vous auriez de bonnes adresses à me proposer ? Merci d'avance !

Ça se lance sans souci ;-) Je pense bien que je vais faire ça Dan...

En fait l'utilisateur paul peut l’exécuter car le thread apache2 est lancé sous l'utilisateur paul via apache2-mpm-itk. J'utilise chaque domaine virtuel avec son propre utilisateur système. paul a les droits d’exécution et de lecture de la configuration. Je reprécise que cette configuration sous wheezy marchait nickel et que depuis la mise à jour vers Jessie, ça foire.

En fait, quand je lance ce script php en console, il marche : <?php$cmdstr="/home/paul/public_html/smi/shoutcast/1.9.8-Linux/sc_serv /home/paul/public_html/smi/servers/8000Test.conf > /dev/null";echo $cmdstr;shell_exec($cmdstr);?> mais dès que je l'appelle via Apache2, ça ne fonctionne pas. pour ce qui est de suhosin, il n'est pas présent et pour la version de PHP, voilà les informations : PHP 5.6.6-2 (cli) (built: Feb 24 2015 10:07:30)Copyright (c) 1997-2015 The PHP GroupZend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2015, by Zend Technologies Pour ce qui est des droits d'accès, ils sont les mêmes que l'utilisateur système. J'ai mis apache2-mpm-itk qui fait tourner dans mon cas chaque thread apache sous l'utilisateur paul. Pour la petite anecdote, je remarque qu'à chaque fois qu'une nana rentre dans ma vie, ça me cause des soucis Oui, Jessie, c'est la cowgirl...

Ben en fait, comme elle allait sortir sous peu, je me suis dit que je pouvais passer dessus pour tester. Et puis, systemd permet de booter plus vite, ce qui est un point important vu que le downtime ne pourra être élevé en cas de redémarrage système.

Salut, je poste ce sujet car je suis en véritable prise de tête depuis deux semaines sous Debian Jessie suite à une mise à jour. Pour expliquer, j'avais une configuration fonctionnelle sous Debian Wheezy sur un serveur qui gère des streaming shoutcast (webradio). J'ai fait une mise à jour vers Debian Jessie et depuis, ça ne fonctionne plus. Ce serveur qui est équipé d'Apache2 avec support mysql et php possède un panel web de gestion des serveurs shoutcast, nommé SMI. Mon souci est que après du débug, j'ai remarqué que le shell_exec n'exécutait plus le sc_serv qui est le binaire de shoutcast. J'ai testé avec un "touch toto" à la place dans le shell_exec, et là il l’exécute bien. Autre chose, quand j’exécute en console avec "php -q script.php" un petit script php maison qui reproduit la commande, là le serveur shoutcast démarre. J'ai aussi tenté de faire un copier coller du "/etc/php5/cli/php.ini" vers "/etc/php5/apache2/php.ini" histoire d'avoir une configuration similaire mais rien n'y fait. Bref, là quelque chose m'échappe et je ne sais pas si quelqu'un aurait une idée ou rencontré un souci similaire ? Merci

Ah ok Merci

Oui j'ai lu sur le Forum d'OVH que ça serait lié à grsecurity mis par défaut sur les serveurs d'OVH. Sinon, tu sais pourquoi il me sors un chemin d'accès qui n'existe pas en ligne de commande pcq ça m'échappe ça ? Merci

Salut tout le monde ! Je viens à vous car je ne sais pas si vous avez rencontré le même souci que moi avec les Kimsufi de OVH. En fait, ma machine plante toutes les deux semaines et quand je relis mon /var/log/kern.log, j'y trouve ceci : Jun 30 08:20:01 ns3098199 kernel: PAX: size overflow detected in function atomic_add_return /var/home/fx/src/ovh-kernel/ovhkernel-xxxx-grs-ipv6-64/linux-3.10.23/arch/x86/include/asm/atomic.h:337 cicus.113_12 max, count: 3Jun 30 08:20:01 ns3098199 kernel: CPU: 1 PID: 28075 Comm: cron Not tainted 3.10.23-xxxx-grs-ipv6-64 #1Jun 30 08:20:01 ns3098199 kernel: Hardware name: OVH RPS/D945GCLF, BIOS LF94510J.86A.0229.2009.0729.0209 07/29/2009Jun 30 08:20:01 ns3098199 kernel: ffff88001432ff38 ffff88001432fe68 ffffffff81dde9c6 ffff88001432fe78Jun 30 08:20:01 ns3098199 kernel: ffffffff8118ea64 ffff88001432fe88 ffffffff811a1891 ffff88001432fec8Jun 30 08:20:01 ns3098199 kernel: ffffffff81190906 ffff88001432ff08 ffffffff810da638 00000000ffffffeaJun 30 08:20:01 ns3098199 kernel: Call Trace:Jun 30 08:20:01 ns3098199 kernel: [<ffffffff81dde9c6>] dump_stack+0x19/0x1bJun 30 08:20:01 ns3098199 kernel: [<ffffffff8118ea64>] report_size_overflow+0x24/0x30Jun 30 08:20:01 ns3098199 kernel: [<ffffffff811a1891>] get_next_ino+0x71/0x80Jun 30 08:20:01 ns3098199 kernel: [<ffffffff81190906>] create_pipe_files+0x36/0x1f0Jun 30 08:20:01 ns3098199 kernel: [<ffffffff810da638>] ? do_sigaction+0x198/0x1d0Jun 30 08:20:01 ns3098199 kernel: [<ffffffff81190afc>] __do_pipe_flags+0x3c/0xb0Jun 30 08:20:01 ns3098199 kernel: [<ffffffff81190bcb>] SyS_pipe2+0x1b/0x110Jun 30 08:20:01 ns3098199 kernel: [<ffffffff81074bd9>] ? do_page_fault+0x9/0x10Jun 30 08:20:01 ns3098199 kernel: [<ffffffff81deb482>] ? page_fault+0x22/0x30Jun 30 08:20:01 ns3098199 kernel: [<ffffffff81190ccb>] SyS_pipe+0xb/0x10Jun 30 08:20:01 ns3098199 kernel: [<ffffffff81deb9c9>] system_call_fastpath+0x18/0x1d et c'est assez ennuyant... De plus, l'endroit mentionné où se trouve le fichier atomic.h n'existe pas sur mon système de fichiers et ce à partir du /var/home... Bref, je pense que pour pallier au souci, je vais me recompiler un kernel mais mes deux questions sont de savoir si vous avez eu aussi le souci avec un de vos Kim et le pourquoi ce chemin d'accès n'existe pas sur mon système alors qu'il est pourtant bien mentionné dans mon log ? Merci d'avance ! Marc

Pour le troisième point, personnellement, quand c'est moi qui gère, je garde les codes d'accès que pour moi pour la simple et bonne raison que si votre client vient mettre son nez dedans et ensuite vous accuse après avoir fait une bourde... Ca évite les soucis et laisser un accès FTP ouvert non stop, perso, je n'aime pas trop faire ça... Je suis plus du genre à par exemple ouvrir le port quand j'en ai besoin ou alors, de faire un VPN avec mon PC de travail et de déposer les mises à jour par ce biais là... ;-)

Ok je vois oui. Pour le script c'est un panel complet PHP mais encodé avec un système dont j'ai oublié le nom ce qui rend la chose non éditable :-/ Sinon, je vais planifier un restart d'apache et demander à la personne qui gère les flux de se reconnecter ensuite à castcontrol pour relancer les serveurs shoutcast. Un grand merci en tout cas; je peux dire que vous m'avez appris pas mal de choses aujourd'hui

Oui en effet, j'ai vu 3eme colonne PPID dans le man mais il ne le sortait pas avec ps aux. En faisant ainsi, j'ai quand même le même résultat : Sinon certains process tournent sur des pères différents oui :

Il semblerait qu'il n'existe plus car il me sort que les process sc_serv contenant bien sûr 2448 en processus père mais aucun process avec le PID du père : Il n'aurait pas fait un fork du process ./sc_serv ? Le détacher du processus parent pour qu'il puisse tourner tout seul.

Oui avec le kill j'ai toujours bossé avec le numéro ou avec le nom complet. Quand j'ai vu -HUP, j'ai pensé a une série de paramètres passés :-/ Maintenant, pour la configuration de castcontrol, ce n'est pas moi qui m'en suis chargé et je ne saurais pas te donner plus d'infos là dessus mais je suis sur que c'est lancé par apache : Le nom d'utilisateur est www-data et seul apache l'utilise Sinon, Je sais que les process ./sc_serv lancés par castcontrol sont étroitement liés aux process d'apache et que si ceux-ci sont donc relancés, ceux qui en découlent vont aussi se couper. Je vais planifier une relance complète du service web et des shoutcast, ça sera plus simple je crois.

Ok, ben j'en aurai appris des choses moi aujourd'hui ! Moi je faisais toujours ça à la barbare genre /etc/init.d/apache restart

Le souci c'est que si apache redémarre, les process ./sc_serv vont aussi se couper car ils découlent du serveur apache2. Ou alors, il faut que le gars qui gère castcontrol soit là pour tout relancer ce qui ferait une micro coupure de quelques secondes, ce qui n'est pas encore la mort... Quand tu dis "sans fermer brutalement", le process va se relancer quand même ?

Voilà, j'ai fait un lsof | grep deleted > lsof-result.txt et effectivement, j'en ai du fichier ouvert ! Pour ceux que j'ai vérifiés, ils ne sont plus sur le disque dur ou alors affichent une taille 0 et sont tous liés au processus du serveur Web qui fait tourner Castcontrol. Faudrait donc faire un kill -HUP sur chaque process d'apache2 pour éviter le reboot du service web ? Je ne vois pas en fait le -HUP dans le MAN de la commande kill :-/

Oui il va falloir que je regarde ça pcq la distrib est toujours en Lenny et le miroir OVH est mort depuis et faire une upgrade la dessus, je ne le sens pas car j'ai un peu peur qu'un truc se passe mal pour le chargement de l'OS par le réseau. Ce n'est pas le genre de chose avec lequel j'ai l'habitude de jouer. Du coup, je suis un peu ennuyé pour installer le package tclx qui contient fstat d'autant plus que le disque étant full, même avec un .deb, je n'ai pas la place pour l'installer et ayant déjà vidé tous les logs. Je pense que je vais essayer de convaincre le gars à qui appartient le RPS qu'il serait mieux de passer sur un petit KIM où VPS pcq les RPS, c'est un peu dépassé comme produit chez OVH :-/ Merci beaucoup

Ok, merci Je peux dire que j'irai dormir moins ignorant ce soir Sinon j'ai un peu peur de faire un restart sur cette machine car elle gère l'émission de flux radio et vu son uptime, ça me fait toujours peur de tenter de la relancer, surtout avec si peu d'espace disque. J'ai même fait un apt-get clean mais là aussi, tout est vidé.

J'ai effectivement effacé pas mal de ficiers log mais uniquement ceux qui étaient archivés en .gz Pour les autres fichiers de log, ils utilisent très très peu de place. Sinon tu m'en as quand même appris une sur le fait qu'on pouvait encore remplir un fichier effacé de l'arbo, merci

Ah ça je ne savais pas... Je vais aller voir pour changer ça dans la configuration (tmpdir = /tmp) Merci Dan! EDIT : Je n'ai quasi rien dans le /tmp donc ça doit venir d'ailleurs je pense. C'est quand même étrange qu'une commande qui calcule l'espace disque utilisé ne comptabilise pas tout.

Bonjour, je ne sais pas si c'est moi qui me trompe dans mon raisonnement ou alors si c'est le RPS que je gère chez OVH qui a un souci avec l'espace disque. Dites moi si vous voyez quelque chose d'anormale dans ceci : En fait, la question que je me pose c'est que df -h me dit que j'ai 4.7Gb d'utilisé sur / alors que du -hs me dit que ce répertoire contient 1.2Gb ce qui me semble plus plausible. Je sais aussi que la machine a 951 jours d'uptime et que la liaison avec le SAN est tombée quelques fois depuis. Allez savoir si quelque chose n'aurait pas planté à cause de ça... Merci d'avance

En géneral pour ce genre de choses, en chroot l'utilisateur dans son répertoire cad qu'on le met un peu en "prison" dans un dossier duquel il ne peut sortir pour aller se promener dans le système. Voir ce lien : http://smhteam.info/wiki/index.linux.php5?wiki=ChrooterUnUtilisateur C'est long mais ca peut très facilement être scripté si jamais tu devais en ajouter une panoplie.