Aller au contenu

Gecko64

Membre+
  • Compteur de contenus

    419
  • Inscrit(e) le

  • Dernière visite

Tout ce qui a été posté par Gecko64

  1. Souci avec SMI

    Hello tout le monde ! Je viens vers vous pcq j'ai un souci avec php et plus précisément avec la fonction shell_exec. Pour expliquer, une webradio où je fais de la maintenance à un souci avec un vieux panel de gestion de serveur de streaming shoutcast 1. Ce panel étant compatible php5 maximum, j'ai du un peu chipoter pour avoir une Debian 9 avec cette version. Cependant, tout marche bien, tout sauf une irréductible ligne de code qui résiste encore à l'envahisseur du bon fonctionnement. Alors dans le code suivant, on voit qu'on prépare la commande d’exécution pour lancer le serveur shoutcast avec la configuration qui va avec, le tout stocké dans $cmdstr. $cmdstr = "nohup ".$config['sc_serv']." ".$config['smi_path']."/servers/".$port."".$srvname.".conf > /dev/null & echo $!"; echo $cmdstr; $pid = shell_exec($cmdstr); echo $pid; Quand je fais un echo de $cmdstr, il me sort la commande parfaite sans erreur de syntaxe; commande que j'ai même testé avec succès en bash sous le même utilisateur sous lequel apache2 exécute celle-ci. Le souci, c'est dès que je regarde si le shell_exec a bien exécuté cette commande quand je passe par apache2 et non directement en bash, aucun serveur shoutcast ne se lance. Je récupère bien un PID dans $pid mais aucune trace du serveur de streaming. Du coup je ne sais pas si des gens baignant plus dans php que moi auraient une piste pour moi ? Ce code tournait nickel sous Debian Wheezy, distribution sur laquelle ils sont encore mais plus pour longtemps... Merci d'avance !
  2. Présentation

    Bienvenue ;-)
  3. Souci avec SMI

    Je viens d'essayer mais pareil... :-/
  4. Souci avec SMI

    Je viens de le faire mais le problème persiste. Par contre j'ai un trou niveau administration, c'est comment je pourrais garder une historique des pid qui existent durant un certain temps ? Pcq il récupère bien un pid mais pas moyen de voir à quelle commande il appartient vu que ça disparait aussitôt. Je pensais faire un "ps aux" en boucle super rapide qui ajoute tout à un fichier et aller chercher là dedans mais bon, chipotage chipotage ^^
  5. Souci avec SMI

    " Parce qu'installer un php5.x sous debian 9 n'est pas ce que j'appellerais une bonne idée... " Tout à fait d'accord mais il ne veut pas lâcher son panel de gestion et je me vois mal, rouillé comme je suis en PHP, commencer à upgrader tout le code... :-/ Sinon c'est php_mod en version 5.6 ( php5_module (shared) ). J'ai ajouté le repository de Jessie et j'ai mis les priorités de packet dans /etc/apt/preferences.d/jessie C'est ainsi que j'ai pu le mettre sur Stretch, même si j'avoue aussi ne pas aimer faire ça.
  6. Souci avec SMI

    Rien n'est en relatif, j'ai testé les deux. En console il se lance mais dès que je mets la commande en shell_exec, fini. J'ai encore fait un shell_exec juste en dessous shell_exec("touch toto.txt"); et là on voit bien que ça marche et tourne sous l'utilisateur gecko : -rw-r--r-- 1 gecko gecko 0 Jul 13 19:45 toto.txt Il y a un utilisateur différent de apache2 pour php ? Pcq moi je fais tourner apache2 sous un utilisateur spécifique et tout ce qui en découle est effectué sous cette identité là. Mais sinon, ceci dans un fichier de test, ça ne marche pas : shell_exec("nohup /home/gecko/website/smi/shoutcast/1.9.8-Linux/sc_serv /home/gecko/website/smi/servers/8000SERVER.conf > /dev/null & echo $!");
  7. Souci avec SMI

    J'ai testé mais pareil, il refuse de se lancer. C'est vraiment étrange...
  8. Souci avec SMI

    Non il tourne sous l'utilisateur gecko; j'utilise le module mpm-itk et j'ai bien vérifié ça avec un htop. C'est d'ailleurs sous ce même utilisateur que j'ai testé en bash directement. Pour les droits d'accès, j'ai testé et aucun souci de ce côté, d'ailleurs il se lance directement en bash. J'ai aussi testé un touch avec le shell_exec et la fonction existe bien, il me crée bien le fichier que j'ai passé en paramètre. Pour le serveur, il y a eu pas mal de changements dans apache2, niveau domaine virtuel de ce que j'ai vu. Pour le reste de la config, je suis resté avec celle par défaut. En fait, j'en suis même arrivé à penser que comme mon binaire crée un socket réseau, par sécurité, il pourrait le bloquer. Merci !
  9. Bonjour à tous

    Salut à toi et bienvenue ;-)
  10. 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 !
  11. Ok merci Ils sont quand même fort chers...
  12. Si, je suis au courant mais pour moi c'est encore un signe d'intrusion en plus (trop ?). Le second problème, c'est que dans une société, ce n'est pas toi qui décide de ce qu'on peut te reprocher. Alors aujourd'hui, il y a peut être rien de spécial pour eux sur mes serveurs mais qui sait ce qu'il en sera dans le futur ? Pour ce qui est du mobile, je suis repassé sur un bête GSM justement à cause du manque de fiabilité point de vue sécurité sur les smartphones, même si les sms sont analysés... Et je vais peut être sembler parano mais pour moi, l'excuse de la sécurité, c'est clairement bidon à mes yeux pour différentes raisons qui s'éloignent du sujet principal de ce poste. Limite on peut en parler en privé
  13. 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.
  14. Debian Jessie; souci avec shell_exec

    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
  15. Debian Jessie; souci avec shell_exec

    Ça se lance sans souci ;-) Je pense bien que je vais faire ça Dan...
  16. Debian Jessie; souci avec shell_exec

    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.
  17. Debian Jessie; souci avec shell_exec

    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 TechnologiesPour 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...
  18. Debian Jessie; souci avec shell_exec

    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.
  19. ♪♪♫♪♫♫♪♫♪...

  20. Plantage régulier sur kimsufi

    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/0x1det 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
  21. Plantage régulier sur kimsufi

    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
  22. relations webmaster - client

    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à... ;-)
  23. Souci d'espace disque sur un RPS

    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
×