linux Archives - Boxydev

S’il vous est déjà arrivé de perdre votre mot de passe MySQL, ouvrez votre terminal et voilà la procédure à suivre :
Seules les lignes commençant par $ sont à tapées dans le terminal.
On stoppe MySQL.

$ sudo /etc/init.d/mysqld stop

On lance MySQL en « safe mode ».

$ sudo mysqld_safe --skip-grant-tables &

On lance mysql.

$ mysql

On effectue la requête pour changer le mot de passe de root.

$ UPDATE mysql.user SET password = password('VOTRENOUVEAUMOTDEPASSE') WHERE user = 'root'

On quitte mysql.

$ exit

On kill le process MySQL.

$ sudo ps -ax

$ sudo killall -9 15 (Si le process est 15)

On redémarre MySQL.

$ sudo /etc/init.d/mysqld start

Et voilà, le mot de passe MySQL est modifié.

En testant Magento 2, nous sommes tombés sur une petite erreur au niveau des permissions. En effet, les fichiers statiques générés dans pub/static renvoyaient une erreur 403. Depuis Magento 2, la bonne pratique est d’utiliser les droits 770 sur les répertoires et 660 sur les fichiers. C’est une très bonne pratique, mais elle est parfois difficilement adaptable, selon les systèmes.

Dans certains cas, il est difficile d’appliquer 770 et 660 et il faut donc 755 et 644, par exemple lorsqu’on utilise PHP-FPM. Nous n’entrerons pas dans les détails ici mais globalement, si on veut utiliser 770 et 660, il faut que les répertoires et fichiers appartiennent au moins au groupe Apache ou Nginx. Et si on héberge plusieurs instances Magento appartenant à plusieurs clients sur un seul serveur, cela peut-être assez gênant. Chez Boxydev, nous avons une couche de sécurité déjà effective, avec un chroot sur mesure, donc le répertoire en 755 est déjà protégé et de plus, il appartient à un utilisateur et un groupe unique !

L’umask de Magento est prédéfini dans le framework. Il faut donc aller éditer 2 fichiers source.

vim /vendor/magento/framework/Filesystem/DriverInterface.php
vim /lib/internal/Cm/Cache/Backend/File.php

On remplace donc 770 et 660 par 755 et 644.

interface DriverInterface
{
    const WRITEABLE_DIRECTORY_MODE = 0755;
    const WRITEABLE_FILE_MODE = 0644;
}

class Cm_Cache_Backend_File extends Zend_Cache_Backend_File
{
    protected $_options = array(
        'directory_mode' => 0755,
        'file_mode' => 0644,
    );
}

On s’assure que tous les dossiers et fichiers ont les bons chmod, libre à vous de sécuriser certains fichiers sensibles avec 600 ou 660 !

find . -type d -exec chmod 755 {} \; && find . -type f -exec chmod 644 {} \;

Il est évident que modifier des vendor directement est une très mauvaise pratique ! Mais c’est la solution la plus facile que nous ayons trouvé, vu que les droits sont définis directement dans une constante. Il faut espérer que Magento corrige cela par la suite en nous laissant le choix des droits à l’installation ou en nous permettant d’override l’umask par exemple. Bien entendu, 770 et 660 sont toujours plus sécurisés que 755 et 644. Ici, on parle d’un cas où il y a déjà une sécurité alternative, comme par exemple l’isolation d’un user dans un 700 ! D’ailleurs, la gestion des droits n’a vraiment rien à faire dans l’application, c’est le système qui doit logiquement s’occuper de tout cela…

Par ailleurs, si vous avez un soucis de 404, ce sont les Symlink, en mode dev’, les ressources se chargent de cette manière mais, il faut faire une copie en dur. Pour cela, il faut éditer le fichier suivant :

vim /app/etc/di.xml

<virtualType name="developerMaterialization" type="Magento\Framework\App\View\Asset\MaterializationStrategy\Factory">
    <arguments>
        <argument name="strategiesList" xsi:type="array">
            <item name="view_preprocessed" xsi:type="object">Magento\Framework\App\View\Asset\MaterializationStrategy\Copy</item>
            <item name="default" xsi:type="object">Magento\Framework\App\View\Asset\MaterializationStrategy\Copy</item>
        </argument>
    </arguments>
</virtualType>

Étiquette : linux

OverAPI : La bibliothèque du développeur web et du développeur

Changer le mot de passe root MySQL

Problème de permissions avec Magento 2