Articles professionnels | Bux Blog

Si vous utilisez nagios et que vous êtes confrontés a cette erreur lorsque vous souhaitez effectuer une opération a partir de l’interface web de nagios, cela est du aux droits du fichier. Si on regarde d’un peu plus près:

/usr/local/nagios/var/rw# ls -l
total 0
prw-rw---- 1 nagios nagios 0 11 sept. 14:32 nagios.cmd

On constate que le fichier ne peut être manipulé que pas l’utilisateur nagios. Or lorsque l’on utilise l’interface web, c’est l’utilisateur www-data qui est utilisé. Il faut donc mettre a jours les droits sur le fichier. Le problème c’est que ce fichier est recréé a chaque démarrage de nagios. On modifie donc le fichier /etc/init.d/nagios de façon a changer les droits sur le fichier lors de sa création:

[...]

case "$1" in

        start)
                echo -n "Starting nagios:"
                $NagiosBin -v $NagiosCfgFile > /dev/null 2>&1;
                if [ $? -eq 0 ]; then
                        su - $NagiosUser -c "touch $NagiosVarDir/nagios.log $NagiosRetentionFile"
                        rm -f $NagiosCommandFile
                        touch $NagiosRunFile
                        chown $NagiosUser:$NagiosGroup $NagiosRunFile
                        $NagiosBin -d $NagiosCfgFile
                        if [ -d $NagiosLockDir ]; then touch $NagiosLockDir/$NagiosLockFile; fi

                        # added by bux
                        chmod 770 $NagiosCommandFile
                        chown nagios:www-data $NagiosCommandFile
                        # end added by bux

                        echo " done."
                        exit 0
                else
                        echo "CONFIG ERROR!  Start aborted.  Check your Nagios configuration."
                        exit 1
                fi
                ;;


[...]

Et voilà !

If you have this error when you use webUI of nagios, you have to modify rights of this file

/usr/local/nagios/var/rw# ls -l
total 0
prw-rw---- 1 nagios nagios 0 11 sept. 14:32 nagios.cmd

Web interface execute this file with ‘www-data’ user. So we have to edit permissions of this file. But, nagios.cmd is created by nagios when he start. So we have to edit the init script of nagios:

[...]

case "$1" in

        start)
                echo -n "Starting nagios:"
                $NagiosBin -v $NagiosCfgFile > /dev/null 2>&1;
                if [ $? -eq 0 ]; then
                        su - $NagiosUser -c "touch $NagiosVarDir/nagios.log $NagiosRetentionFile"
                        rm -f $NagiosCommandFile
                        touch $NagiosRunFile
                        chown $NagiosUser:$NagiosGroup $NagiosRunFile
                        $NagiosBin -d $NagiosCfgFile
                        if [ -d $NagiosLockDir ]; then touch $NagiosLockDir/$NagiosLockFile; fi

                        # added by bux
                        chmod 770 $NagiosCommandFile
                        chown nagios:www-data $NagiosCommandFile
                        # end added by bux

                        echo " done."
                        exit 0
                else
                        echo "CONFIG ERROR!  Start aborted.  Check your Nagios configuration."
                        exit 1
                fi
                ;;


[...]

Et woilà !

Edit: Voir le commentaire de Bidule pour une solution plus simple

Il est très pratique d’isoler ses tests du reste de l’application. Il est donc nécessaire de faire en sorte que la base de donnée utilisé lors des tests soit indépendante de la base utilisé lors du développement. Cela évite de fausser ses tests si des données ont été modifier pendant le développement ainsi que d’utiliser une base fidèle aux fixtures entre chaque tests.

Cet article est issue de la combinaison des deux articles suivants:

Dans mon cas, l’article de haulynjason.net seul ne me permettait pas d’exécuter mes tests fonctionnels sur la même base que les tests unitaires. J’ai du utiliser l’astuce de l’article d’alexamdre-salome.fr.

Premièrement nous configurons de quoi éxécuter les tests dans une base sqlite, de façon a ce qu’elle soit isolé de la base de développement.

config_test.yml:

doctrine:
dbal:
driver: pdo_sqlite
path: ":memory:"
memory: true
orm:
auto_generate_proxy_classes: true
auto_mapping: true

Nous créons la classe ModelTestCase a partir de laquelle seront étendus nos classes de tests (git):

_kernel = new \AppKernel("test", true);
$this->_kernel->boot();
$this->_container = $this->_kernel->getContainer();
parent::__construct();
}

protected function get($service)
{
return $this->_container->get($service);
}

public function setUp()
{
$this->_application = new \Symfony\Bundle\FrameworkBundle\Console\Application($this->_kernel);
$this->_application->setAutoExit(false);

$this->runConsole("doctrine:schema:drop", array("--force" => true));
$this->runConsole("doctrine:schema:create");
$this->runConsole("cache:warmup");
$this->runConsole("doctrine:fixtures:load");
}

protected function runConsole($command, Array $options = array())
{
$options["-e"] = "test";
$options["-q"] = null;
$options = array_merge($options, array('command' => $command));
return $this->_application->run(new \Symfony\Component\Console\Input\ArrayInput($options));
}
}

A partir d’ici vos classes de tests unitaires étendus de cette classes utiliserons la base sqlite pour exécuter ses tests. Passons maintenant aux tests fonctionnels: définissons le paramètre test.client.class afin d’écrire notre propre classe Client:

config.yml:

parameters:
test.client.class: MyApp\CoreBundle\lib\Test\Client

requested) {
$this->kernel->shutdown();
$this->kernel->boot();
}

$this->injectConnection();
$this->requested = true;

return $this->kernel->handle($request);
}

protected function injectConnection()
{
if (null === self::$connection) {
self::$connection = $this->getContainer()->get('doctrine.dbal.default_connection');
} else {
if (! $this->requested) {
self::$connection->rollback();
}
$this->getContainer()->set('doctrine.dbal.default_connection', self::$connection);
}

if (! $this->requested) {
self::$connection->beginTransaction();
}
}
}

Nous écrivons la classe WebTestCase a partir de laquelle nous étendrons nos classe de test fonctionnels:

get('test.client');
$client->setServerParameters($server);

return $client;
}

}

Et voilà, nos tests fonctionnels seront étendu de WebTestCase, nos tests unitaires seront eux étendus de ModelTestCase et ils seront totalement isolé de la base de dév puisque ils travailleront avec une base indépendante. Les performances de vos tests seront affectés puisque avec cette méthode chaque test (fichier, pas fonction) effectue une rechargement de la base.Edit: Look at Bidule comment for easier solution

It’s very usefull to have isolated tests in symfony. It’s necessary to have separated databases for test and dev.

This article is a combination of these articles:

In my case, the haulynjason.net script alone doesn’t work for functionals tests. But with d’alexamdre-salome.fr tips all my tests was isolated.

First we configure sqlite for test environnement:

config_test.yml:

doctrine: 
dbal: 
driver: pdo_sqlite 
path: ":memory:" 
memory: true 
orm: 
auto_generate_proxy_classes: true 
auto_mapping: true

We create ModelTestCase class for extends ours functional and unit tests classes (git):

<?php /* * Adapt to your AppKernel.php path */ require_once(__DIR__ . "../../../../../../app/AppKernel.php"); /** * @see http://haulynjason.net/weblog/2012/01/fully-isolated-tests-in-symfony2/ */ class ModelTestCase extends \PHPUnit_Framework_TestCase { protected $_kernel; protected $_application; protected $_container; public function __construct() { $this->_kernel = new \AppKernel("test", true); 
$this->_kernel->boot(); 
$this->_container = $this->_kernel->getContainer(); 
parent::__construct(); 
}
 protected function get($service) 
{ 
return $this->_container->get($service); 
}
 public function setUp() 
{ 
$this->_application = new \Symfony\Bundle\FrameworkBundle\Console\Application($this->_kernel); 
$this->_application->setAutoExit(false);
 $this->runConsole("doctrine:schema:drop", array("--force" => true)); 
$this->runConsole("doctrine:schema:create"); 
$this->runConsole("cache:warmup"); 
$this->runConsole("doctrine:fixtures:load"); 
}
 protected function runConsole($command, Array $options = array()) 
{ 
$options["-e"] = "test"; 
$options["-q"] = null; 
$options = array_merge($options, array('command' => $command)); 
return $this->_application->run(new \Symfony\Component\Console\Input\ArrayInput($options)); 
} 
}

Now your unit test classes extends form ModelTestCase will use sqlite database. For functional tests we have to replace the default class of Client:

config.yml:

parameters: 
test.client.class: MyApp\CoreBundle\lib\Test\Client

<?php namespace MyApp\CoreBundle\lib\Test; use Symfony\Bundle\FrameworkBundle\Client as BaseClient; class Client extends BaseClient { static protected $connection; protected $requested; protected function doRequest($request) { if ($this->requested) { 
$this->kernel->shutdown(); 
$this->kernel->boot(); 
}
 $this->injectConnection(); 
$this->requested = true;
 return $this->kernel->handle($request); 
}
 protected function injectConnection() 
{ 
if (null === self::$connection) { 
self::$connection = $this->getContainer()->get('doctrine.dbal.default_connection'); 
} else { 
if (! $this->requested) { 
self::$connection->rollback(); 
} 
$this->getContainer()->set('doctrine.dbal.default_connection', self::$connection); 
}
 if (! $this->requested) { 
self::$connection->beginTransaction(); 
} 
} 
}

We write WebTestCase class for extends our functionals tests:

<?php namespace MyApp\CoreBundle\lib\Test; use MyApp\CoreBundle\lib\Test\ModelTestCase; class WebTestCase extends ModelTestCase { /** * * @param array $server * @return Symfony\Bundle\FrameworkBundle\Client */ protected function createClient(array $server = array()) { $client = $this->get('test.client'); 
$client->setServerParameters($server);
 return $client; 
}
}

It’s Okay ! Our functionals tests are extends from WebTestCase, our unit tests are extends from ModelTestCase and they are isolated ! Just one thing: tests will be more long because every test file will reload your database fixtures.

Bux Blog

Archives de catégorie : Articles professionnels

Could not open command file ‘/usr/local/nagios/var/rw/nagios.cmd’ for update!Could not open command file ‘/usr/local/nagios/var/rw/nagios.cmd’ for update!

Configurer thunderbird pour google app (email)Configure thunderbird for google app (email)

Isoler les tests fonctionnels et unitaires dans symfony2Isolate functional and unit tests in symfony2

code, systems, geek and life