Category

côté serveur

WP-CLI

WP-CLI – Configurez WordPress en ligne de commande

By | côté serveur, Wordpress 4.2 | No Comments

WP-CLI est un petit fichier .phar, permettant la gestion de certaines tâches en ligne de commande.

WP-CLI est un logiciel qui s’adresse surtout au administrateurs systèmes qui doivent gérer un nombre conséquent de blog WordPress.
En effet ce couteau suisse en ligne de commande est le parfait compagnon pour manager l’installation de WordPress. Il est possible de mettre à jour les plugins, initialiser une installation multisite, et bien d’autres choses encore.

Prérequis

  • Un système d’exploitation de type UNIX (OS X, Linux, FreeBSD, Cygwin)
  • PHP 5.3.2 ou supérieur
  • WordPress 3.5.2 ou supérieur

Nota: pour les utilisateurs Windows, il faut savoir que WP-CLI n’est que partiellement compatible. Certaines commandes sont susceptibles de ne pas fonctionner.

Installation

Téléchargement du fichier via wget ou curl

# wget
$ wget https://raw.github.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

# curl
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

Vérifiez qu’il n’y est pas erreurs

$ php wp-cli.phar --info

Si aucune erreur n’est retourné, il est à présent possible d’utiliser WP-CLI en ajoutant php wp-cli.phar avant chaque ligne de commande.
Pour une installation plus ergonomique, poursuivez les instructions suivantes.

Pour ne taper que wp au lieu de php wp-cli.phar il est nécessaire de créer un exécutable et de le placer dans un dossier où l’utilisateur système pourra l’exécuter.

chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

# pour vérifier que tous fonctionne bien
$ wp --info

Pour ajouter l’auto complétion via la touche tabulation, télécharger le fichier <a href= »https://raw.githubusercontent.com/wp-cli/wp-cli/master/utils/wp-completion.bash » target= »_blank » title= »wp-completion.bash »>wp-completion.bash</a> puis ajouter-le comme fichier source dans <strong>~/.bash_profile</strong>

# téléchargement de wp-completion.bash
$ wget https://raw.githubusercontent.com/wp-cli/wp-cli/master/utils/wp-completion.bash

# Ajout de la source dans ~/.bash_profile
source /FULL/PATH/TO/wp-completion.bash

# Initialisation de la nouvelle source
$ source ~/.bash_profile

L’installation est à à présent complète. Tapé les lignes de commandes à la racine de WordPress ou dans l’un de ses sous-dossiers.

Quelques commandes utiles


# Afficher l'aide
$ wp help

# Installer un plugin (ex: hello dolly)
$ wp plugin install hello-dolly

Vérifier la présence de mises à jour de WordPress
$ wp core check-update

# Mise à jour de WordPress
$ wp core update

Toutes les commandes sont disponibles sur le site officiel.

Activer le protocole SSL sur votre site Wordpress

Activer le protocole SSL sur votre site WordPress

By | côté serveur, woocommerce, Wordpress 4.2 | No Comments

Cet article s’adresse à ceux qui souhaitent activer le protocole SSL sur votre site WordPress qui se trouve déjà en production.

Pourquoi activer le protocole SSL ?

Le protocole SSL pour Secure S Layer permet de crypter le téléchargent des pages. Ainsi, il n’est pas possible de récupérer au vol l’envoi de données d’un formulaire. Ce qui s’avère fortement utile pour les formulaires de payement sur les E-commerce.

De plus, Google et la fondation Mozilla (Firefox) encouragent les web-master à migrer du protocole HTTP à HTTPS.

Comment activer SSL ?

Avant de commencer, assurez-vous que la réécriture d’URL est bien active sur votre serveur (Apache2 mod_rewrite). et qu’il est possible d’éditer le fichier .htaccess ainsi que le fichier wp-config.php.

1. Côté serveur

L’activation propre dite du protocole SSL s’effectue sur le serveur. L’opération ne sera pas décrite ici car cela va dépendre de l’hébergeur de votre site. Toutefois il faut savoir que le cryptage des données s’effectue au moyen d’un certificat SSL qu’il faudra payer tous les ans.

2. Côté WordPress

La première étape consiste à mettre à jour l’URL de votre site. Rendez-vous dans la partie admin, allez dans Réglages -> Général puis dans les champs: Adresse web de WordPress (URL) et Adresse web du site (URL) ajouter un (s) devant le http. Enregistrez les modifications.

Ouvrer le fichier .htaccess et mettez-le à jour en fonction de la configuration ci-dessous:


<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.mon-site.fr/$1 [R,L]
</IfModule>

Pour ceux qui utilisent nginx pour leur serveur Web, ajoutez à la suite le code ci-dessous


server {
listen 80;
server_name yoursite.com www.yoursite.com;
return 301 https://yoursite.com$request_uri;
}

Cela permettra à nginx de faire des redirections 301 de l’ancienne URL vers la nouvelle. Apache2 gérant cela très bien, il n’est pas nécessaire d’y ajouter ces paramètres supplémentaires.

Dernière étape, le fichier wp-config.php. Ajouter la constante suivante :


define('FORCE_SSL_ADMIN', true);

Cela activera le protocole SSL dans l’admin du site.

Structure de la base de données Wordpress

Structure de la base de données WordPress

By | Aide et astuces, côté serveur | One Comment

La structure de la base de données WordPress se présente sous la forme de onze tables ayant le préfixe wp_.

Introduction

WordPress à besoin que d’une seule et unique base de données de type SQL pour fonctionner. La connexion à cette base de données s’effectue à l’aide de PDO, ce qui offre un large choix de système de gestion de base de données.

Seules les onze tables par défaut de WordPress sont citées ici.

Il est possible que des plugins aient créé d’autres tables voire même d’autres bases de données. Si un plugin créé de nouvelles tables elles porteront le même préfixe que celle de WordPress. Si un plugin créé une nouvelle base de données, elle est soumise à aucune restriction particulière.

Le préfixe wp_ est proposé par défaut durant l’installation. Il est fortement conseillé de le remplacer. En effet, dans le cas d’une injection SQL il est plus facile de cibler vos tables si elles ont gardé le préfixe par défaut.

 

Tour d’horizon des différentes tables

wp_commentmeta et wp_comments permettent la sauvegarde des commentaires sur les publications de site.

wp-links n’est plus utilisée aujourd’hui. Il y a quelques années de cela, le tableau de bord de WordPress proposé un menu appelé Liens. Il permettait d’ajouter toute une liste de liens et de les grouper par catégorie. C’est dans cette table que se trouvaient les liens.

wp_options contient les valeurs des paramètres du menu Réglages.

wp_postmeta et wp_posts contiennentt toutes les publications du site. Soit, les pages, les articles et le(s) menu(s). Depuis l’arrivée de la fonction Révision qui pour rappel permet de restaurer une page ou un article à une date antérieure, chaque version sauvegardée génère une nouvelle ligne dans la table wp_posts.

wp-term_relationships, wp_term_taxonomy et wp_terms contiennent les informations relatives aux catégories d’articles, aux mots-clés (tags) des articles, ainsi que leur lien avec les différents pages et articles.

wp_user et wp_usermeta. WordPress sépare dans deux tables les utilisateurs. wp_user contient la plupart des champs qu’il faut obligatoirement remplir pour créer un utilisateur. C’est dans cette table que figurent les noms, les adresses Email ainsi que les identifiants et mots de passe (encrypté) mais pas les Rôles. Les rôles quant à eux figurent dans wp-usermeta ainsi que les valeurs des champs non obligatoires.

rss-functions.php

Full Path Disclosure sur le fichier rss-functions.php

By | Aide et astuces, côté serveur, Sécurité, Wordpress 4.2 | One Comment

Full Path Disclosure ou (FPD) est un faille de sécurité qui concerne le fichier /wp-includes/rss-functions.php sur les sites WordPress.

 

Qu’es ce qu’une Full Path Disclosure ?

Il s’agit d’une vulnérabilités permettent de voir le chemin d’accès au webroot dans la fenêtre du navigateur. Si votre site est assujettie à cette faille, le simple fait de taper l’URL complète du fichier rss-functions.php (ex: http://site-wordpress.fr/wp-includes/rss-functions.php) affichera dans le navigateur une Fatal error ainsi que le chemin complet depuis la racine du serveur jusqu’à ce fameux fichier rss-functions.php.

 

Fatal error: Call to undefined function _deprecated_file() in /homepages/19/d253383552/htdocs/wp-includes/rss-functions.php on line 8

 

La faille FDP est executé en injectant un caractère inattendu à certains paramètres d’une page web. Le script défaillant, ne s’attendant pas à l’injection de ce caractère, retourne un message d’erreur dans lequel figure, le nom de la fonction PHP incriminé _deprecated_file(), le webroot /homepages/19/d253383552/htdocs/ ainsi que le numéro de ligne où se trouve la fonction line 8.

 

Quel sont les risques ?

Les vulnérabilités FPD sont généralement perçues comme des menaces à faibles risques. Toutes fois, il ne faut pas oublier que les messages d’erreurs sont des gardes fous, qui s’adressent aux développeurs afin qu’ils puissent garantir code stable et intègre et non aux utilisateurs.

 

Local File Include et injection SQL

La faille Local File Include (LFI) permet l’injection de fichier malveillant sur le serveur. Quant à l’injection SQL appelé aussi faille XSS, permet quant à elle d’injecter du code (écrit en JavaScript) malveillant interprété par le serveur.

Mais pour s’assurer que ces scripts malveillants pointent bien vers les bons fichiers, il est nécessaire de connaitre son emplacement dans l’arborescence.

Et c’est à ce moment précis qu’une petite faille du type Full Path Disclosure est la bienvenue. Devenant pour l’occasion un véritable mouchard.

Comment combler la faille ?

 

La faille Full Path Disclosure peut être facilement comblé en désactivant l’affichage des messages d’erreur par le serveur Apache. Deux méthodes sont possibles:

Depuis le fichier de configuration de PHP, /etc/php5/apache2/php.ini


display_errors = 'off'

Depuis le fichier de configuration d’Apache, /etc/apache2/apache2.conf


php_flag  display_errors  off

Nota: Les chemins mentionnés ci-dessus s’appliquent au système  Debian et ses dérivée tel que Ubuntu. Il est possible que ces chemins diffèrent en fonction du système d’exploitation utilisé.

 

Le cas 1&1

Pour une raison inconnu, les serveurs Web de chez 1&1 sont configurer avec l’option display_errors = ‘on’. Malheureusement il n’est pas possible de changer ce paramètre sur off.

Pour résoudre ce problème, deux autres méthodes sont encore exploitables.

  1. La suppression pur et simple du fichier rss-functions.php. En effet, ce fichier est une relique, remplacé depuis par rss.php lui aussi un déprécier et remplacé par class-simplepie.php. Si après cette suppression, un plugin ou une fonction du thème rencontre des difficultés avec les flux RSS, rétablissez le fichier rss-functions.php et préférez la seconde méthode.
  2. Editer le fichier rss-functions.php et y ajouter le code ci-dessous juste avant la fonction:

(isset($var) && is_array($var)) ? logfunction() : /*continue*/;

Moins conviviales et pouvant être considérées comme du rafistolage, ces deux dernières méthodes ont un inconvenant commun: Les mise à jour de WordPress. A chaque fois que WordPress est mis à jour, un nouveau fichier rss-functions.php est créé, écrasant à chaque fois vos modifications. C’est pourquoi, il faudra renouveler l’opération après chaque mise à jour.

 

Personnaliser l'accès au tableau de bord Wordpress

Personnaliser l’accès au tableau de bord WordPress

By | Aide et astuces, côté serveur, Plugin Wordpress, Wordpress 3.6, Wordpress 3.7, Wordpress 3.8, wordpress 3.9, wordpress 4.0, Wordpress 4.1 | One Comment

Pour personnaliser l’accès au tableau de bord WordPress il existe deux méthodes:  le plug’in HC Custom WP-Admin URL et la redirection 301.

 

Je n’apprendrais rien à personne en disant que l’accès au tableau de bord de WordPress se fait en ajoutant /wp-admin à la suite de l’adresse de votre de blog. Tout le monde le sait, même les hackers ! D’où l’intérêt de personnaliser cette dernière. Car si le hacker ne sait pas comment parvenir jusqu’à la page du login, alors sa tentative de piratage de votre blog se compliquera très sérieusement.

L’idée est de trouver un bon compromis entre simplicités pour vos collaborateurs ou clients et complication pour les hackers. Donc choisissez bien le mot de substitution à /wp-admin.

Pour personnaliser sa page de connexion WordPress deux solutions possibles : à l’aide du plug’in HC Custom WP-Admin URL ou bien en éditant le fichier .htaccess situer à la racine du serveur.

Dans tous les cas l’idée est de faire une redirection 301. C’est pourquoi votre serveur Apache doit impérativement avoir le module mod_rewrite d’activer.

 

Le plugin HC Custom WP-Admin URL

C’est sans conteste la méthode la plus simple. Dans Extensions -> Ajouter recherchez HC Custom WP-Admin URL installez-le puis activez-le.

Personnaliser l’accès au tableau de bord WordPress, rendez-vous dans le menu Réglage -> Permaliens.

En bas de la page localisez le champ wp-admin slug, puis ajouter complétez-le avec le mot de votre choix.

Une fois remplacé fait un test avec le nouveau mot puis avec le bon vieux /wp-admin. Il y a de forte chance que cela fonctionne encore avec /wp-admin et /wp-login, car il ne faut pas oublier que WordPress génère un cookies lorsque l’on ouvre une session. Par conséquent, supprimez vos cookies et refait un test.

Pour ceux qui viennent d’activer le module mod_rewrite, modifier les permaliens est un excellant moyen de savoir si cela a été fait correctement.

Le fichier .htaccess

Localisez ou créez un fichier .htaccess à la racine de votre site WordPress puis ajouter la ligne de code suivante :


RewriteRule ^pseudo-text$ http://VOTRE_BLOG.com/wp-admin [NC,L]
RewriteRule ^pseudo-text$ http://VOTRE_BLOG.com/wp-login.php [NC,L]

Pour rappel, le fichier .htaccess permet de passer des instructions à Apaches lorsque l’on n’a pas accès au fichier de configuration d’Apache.

pseudo-texte$ est le mot qui remplacera /wp-admin.

http://VOTRE_BLOG.com/wp-admin  et http://VOTRE_BLOG.com/wp-login.php sont les liens par défauts.

erreur 500 internal server error

Erreur 500 Internal Server Error chez OVH après l’installation de wordpress

By | côté serveur, Plugin Wordpress | No Comments

Erreur 500 internal server error n’a rien de grave, mais il peut être désagréable d’être bloqué pour cela !

Lors de l’upload de votre site WordPress, vous devrez obligatoirement ouvrir les droits en écriture pour permettre la mise en place du fichier wp-config.php.

Si certains le font manuellement, un simple transfert FTP suffira. Sinon, l’ouverture des droits se fera en réglant vos droits d’écriture en 777.

Mais attention de ne pas laisser ces mêmes droits sur tous les dossiers en 77, surtout si vous êtes sur un hébergement mutualisé de type OVH, amen ou 1&1.

Si c’est le cas, vous aurez alors le fameux Erreur 500 internal server error. Si cela arrive, en réécrivant les droits à l’intérieur de votre fichier www en 705, tout devrait revenir dans l’ordre. Par la suite, pour faire évoluer votre site et le modifier à souhait, les droits d’écriture devront être en place que pour le fichier concerné.

Le fichier thème peut donc ensuite être mis en 777, vous permettant de faire les modifications CSS et PHP directement grâce à l’éditeur de code intégrer à l’admin de wordpress.

Bref, ne vous affolez donc pas sur cette erreur, que vous aurez très certainement sur ce type d’hébergement.

simple 301 redirect

Simple 301 redirect pour gérer les redirections 301

By | Aide et astuces, côté serveur, Plugin Wordpress, Référencement Wordpress | No Comments

Faire une redirection 301 sur WordPress à l’aide de extension Simple 301 redirect.

Si nous utilisons WordPress pour un blog ou un site vitrine, c’est essentiellement pour ses qualités de référencement naturel sur Google. Or Google souhaite simplifier les URL (changements depuis Penguin et Panda) cela nous impose pour les sites les plus anciens d’ajuster certaines pages web afin de maximiser leur fabrication sans pour autant perdre la puissance de la page.

Si la page ne change pas en revanche l’URL, elle va être modifiée.
Alors, pour ne pas perdre la puissance du Netlinking, nous opérons une redirection 301 de l’ancienne page vers la nouvelle page.
Cette redirection, sur la nouvelle URL, peut être faite de différentes manières sur WordPress.

  • Soit à l’aide d’un fichier Htaccess, qui va répertorier les modifications et dans lequel on peut mettre une succession de lignes correspondantes à toutes les URL qui vont être changées et sur lesquelles on souhaite poser une redirection 301.
  • Soit par l’intégration d’un plugin pour gérer la redirection 301, qui fera donc tout le boulot à notre place.

Une extension wordpress de redirection 301 simple, et rapide de configuration pour garder le positionnement de vos pages référencées sur Google.

La première méthode est pratique lorsqu’il s’agit d’automatiser un site largement référencé contenant plusieurs centaines de pages. Mais s’il s’agit d’une simple modification pour une optimisation de votre référencement naturel sur certaines pages, une extension très simple va vous aider à faire cela sur WordPress. L’extension s’appelle simple 301 redirect.

Elle porte plutôt bien son nom puisqu’elle s’active et se paramètre en quelques clics

Du côté gauche vous rentrez les anciennes URL, du côté droit la nouvelle URL, puis vous valider. Par la suite en faisant le test dans votre navigateur, vous pourrez observer qu’en tapant l’ancienne adresse de votre page Web vous tombez directement sur la nouvelle. Il est donc une redirection efficace que l’on observe, mais il y a également une redirection de la puissance Web de la page, ce qui est nécessaire et indispensable si on veut conserver la puissance de référencement de positionnement de l’ancienne page.

Simple 301 redirect est a priori à la référence pour des ajustements de quelques pages ou articles. Mais si jamais cette redirection n’est que provisoire, pensez aux redirections 302 qui sont là pour les sites en travaux.
Pour le reste n’oubliez pas qu’une redirection 301 communique et transmet toute la puissance de l’ancien de la nouvelle page. Attention donc aux pages pénalisées page Penguin : si vous êtes victime d’un déclassement d’une page, il n’est pas forcément malin d’utiliser une redirection 301…

Impossible de créer le dossier wp-content

Impossible de créer le dossier wp-content /uploads sur WordPress

By | Aide et astuces, côté serveur | One Comment

« fichier.jpg » n’a pas pu être mis en ligne suite à une erreur. Impossible de créer le dossier wp-content /uploads/2013/09. Son dossier parent est-il accessible en écriture par le serveur ?

 

Tel est le message d’erreur qui peut être rencontré lors de l’import d’un fichier dans la bibliothèque de WordPress.

Pour rappel, les fichiers figurant dans cette bibliothèque se trouvent dans le dossier wp-content/uploads suivi d’un ensemble de sous dossiers.

Dans le menu Réglages > Médias, il se peut que la ligne Organiser mes fichiers envoyés dans des dossiers mensuels et annuels, soit cochée. C’est un réglage par défaut qui signifie que WordPress va créer un ensemble de sous dossier dans /wp-content/uploads  en fonction de la date d’importation du fichier.

Exemple : Si un fichier à était importé le 12/09/13, alors WordPress va ranger ce fichier dans /wp-content/uploads/2013/09capture

Le sous dossier /2013 correspond à l’année où le fichier à était importé. Le second, /09, correspond au numéro du mois.

C’est la raison pour laquelle ce message d’erreur ne peut être rigoureusement identique chez tout le monde. D’autant plus, que le nom du fichier (ici 31.jpg) figure dans le message erreur.

Ce même problème peut être la raison de différentes causes. Ci-dessous, figure un ensemble de solutions qu’il faudra suivre dans cet ordre.

Solution 1

Accéder au dossier /wp-content/uploards via votre client FTP, (Filezilla, Cyberduck…) et y vérifier les droits en lecture/écriture et exécution soient bien en 775. Si ça n’est pas le cas, attribuer les droits en 775 au dossier uploads sans oublier d’activer la récusions afin que ses sous dossier en bénéficient également.

Solution 2

Profiter de l’accès FTP pour vérifier également les droits du dossier /wp-content. Il devrait être lui aussi à 775. Si ça n’est pas le cas, effectuer le changement puis tentez de nouveau l’importation d’une image. Toutefois, il peut arriver que sur certain serveur 775 soit encore trop restrictif. Essayez les droits en 777 toujours sur le dossier /wp-content.

Si cela fonctionne, ne le prenez surtout pas pour argent comptant, car cela n’est pas normal et surtout par prudent. Nécessitez par à contacter votre hébergeur afin de résoudre cette anomalie.

Solution 3

Allez dans le menu Réglages -> Médias, et décochez la ligne : Organiser mes fichiers envoyés dans des dossiers mensuels et annuels. Là encore cette étape peut faire des miracles. Vérifiez à nouveau en important un fichier dans la bibliothèque.

Solution 5

Si le problème n’est toujours par résolu, il reste encore une dernière solution. Retournez dans le dossier /wp-content (toujours à l’aide de votre client FTP préféré).

Renommez le dossier /uploads en /uploads_old, puis créer un nouveau dossier /uploads auquel il lui sera attribuer les droits 775. Le problème doit être résolu. Vérifiez une troisième fois en important un fichier dans la bibliothèque. Une fois cette vérification terminé (et  espérons-le  fructueuse), transférer le contenu du dossier /uploads_old dans dossier /uploads, afin de récupérer l’intégralité de vos fichiers.

Une fois le transfert terminé, le dossier /uploads_old pourra être supprimé.

Installer un serveur LAMP pour Wordpress

Installer un serveur LAMP pour WordPress

By | Aide et astuces, côté serveur | 2 Comments

Installer un serveur LAMP pour WordPress sur son réseau local peut être un bon moyen de départ pour ceux qui souhaitent s’adonner au développement de thèmes et de plugins.

Certains diront que cette idée est farfelue et qu’il suffit d’installer une suite logicielle telle que Xamp, Wamp pour Windows ou encore Mamp pour Mac OS X.
Mais il faut savoir, que ces suites logicielles ont souvent un train de retard sur les mises à jour, et plugins ne fonctionnent tous simplement pas avec ce type d’installation.

Les prés-requis techniques pour pouvoir installer un serveur LAMP pour WordPress

Avant d’installer WordPress il est primordial d’avoir :

  • un ordinateur dédié qui servira de serveur. Un vieux PC fera l’affaire, mais ne jamais prendre l’ordinateur familial, car il faudra formater le disque dur pour installer le nouvelle OS.
  • un second ordinateur qui fera office de client.
  • une carte Ethernet. Oubliez le Wi-Fi, trop instable.
  • un câble Ethernet pour relier le PC à votre modem box.

Remarque : Debian sera installé sans GUI (Graphical, User, Interface), il est donc toute a fait envisageable d’utiliser une machine virtuelle.

Notre environnement de travail

Notre environnement de travail est configuré de la manière suivante :

  • un PC vierge, connecté à un modem box en Ethernet.
  • un système d’exploitation Linux. Ici c’est Debian qui sera retenu.
  • un serveur Web. Apache est à privilégier avec WordPress
  • un SGBDR (Système de Gestion de Base de Données Récursive). Ici c’est MySQL qui sera retenu.
  • PhpMyAdmin, pour gérer la base de donné de façon plus conviviale.
  • le logiciel PHP afin qu’Apache puisse gérer le langage du même nom.
  • un serveur FTP. Les dépôts de Debian proposent Vsftp.

Remarque : Il sera question uniquement d’héberger WordPress. Le nom de domaine ne sera pas abordé ici. Pour plus de renseignements sur le sujet, rendez-vous sur la documentation officielle de Bind9.

Etape 1 : Installation système

Téléchargez la dernière version de Debian, puis fait une installation typique de Debian.
Pour plus de renseignements sur cette étape, n’hésitez pas à consulter la documentation officielle.

Optionnels : afin de ne pas encombrer le système de packages inutiles, lors de la sélection de logiciel, n’hésitez pas à décocher : environnement de bureau Debian et serveur d’impression. Ne gardez que : Utilitaires usuels du système.

Une fois l’installation terminée, l’ordinateur démarre pour la première fois sur le nouveau système. Par défaut la carte réseau est configurée en DHCP. La première étape va consister à l’attribution d’une IP fixe.

Etape 2 : Adresse IP fixe.

Dans le terminal, se connecter en tant que root :

$ su root
Mot de passe

Editez le fichier /etc/networks/interface :

# nano /etc/networks/interface

Modifiez le fichier comme ci-dessous en remplacent les valeurs en rouge par en fonction de vos paramètres réseau.

# The primary network interface
2 auto eth0
3 iface <span style="color: #ff0000;">eth0</span> inet static
4 address <span style="color: #ff0000;">192.168.1.254</span>
5 netmask <span style="color: #ff0000;">255.255.255.0</span>
6 gateway <span style="color: #ff0000;">192.168.1.1</span>

Modifiez également le fichier resolv.conf pour le DNS

#nano /etc/resolv.conf

Modifiez-le en renseignant les serveurs DNS 1 et DNS 2 fourni par votre FAI. Ces informations sont disponibles dans l’interface Web de votre box.

Redémarrer l’interface réseau eth0 afin qu’ils soient pris en considération

# /etc/init.d/networking restart

Afin de s’assurer que tous fonctionnent, profitez-en pour mettre à jour la liste des dépôts de Debian à l’aide la commande suivante :

# atp-get update

Si la mise à jour fonctionne, c’est que les paramètres sont bons. Dans le cas contraire il faut recommencer cette étape.

Etape 3: Le serveur FTP

Installation et configuration du serveur FTP à l’aide du deamon vsftpd (Very Secure FTP Daemon).

# apt-get install vsftpd

Le serveur est maintenant lancé et écoute sur le port 21.
Si le serveur n’est pas derrière un firewall, en attendant de l’avoir configuré il est sage de l’arrêter :

# /etc/init.d/vsftpd stop

Ouvrez le fichier de configuration, et suivez l’article pour les principales options :

# nano /etc/vsftpd.conf

A noter que le fichier est abondamment commenté en anglais et que toutes les options sont listées dans le manuel du même nom :
man vsftpd.conf

Par défaut seule la connexion anonyme est autorisée, elle a accès au répertoire /srv/ftp/ ce qui constitue une faille de sécurité. Pour le désactiver, modifiez la ligne comme ci-dessous :

anonymous_enable=NO

A la place définissez un compte du système précis comme propriétaire des fichiers envoyés. Pour cela retirer les commentaires (supprimer le # devant la ligne) pour :

chown_uploads=YES
chown_username=<span style="color: #ff0000;">$USER</span>

Pour permettre l’identification des utilisateurs système :
local_enable=YES
Pour autoriser l’écriture :

write_enable=YES

Enregistrez les modifications puis quittez nano. A présent il faut redémarrer le deamon :

# /etc/init.d/vsftpd start

Etape 4 : Installation de MySQL

Installez ensuite Mysql en utilisant les commandes suivantes :

# apt-get install mysql-server mysql-client

Durant l’installation MySQL demandera de créer un mot de passe pour l’utilisateur root de MySQL.

Etape 5 : Installation d’Apache2

Installez le serveur web comme ceci :

# apt-get install apache2 apache2-doc

Activez le module :

# a2enmod userdir

En tant qu’utilisateur (pas comme root), créez un dossier dans son dossier home :

# exit
$mkdir /home/$USER/public_html

En tant que root, changez le groupe du dossier et redémarrez le serveur :

# chgrp www-data /home//public_html
# service apache2 restart

Afin d’éviter toute erreur 403 « Forbidden » lorsque l’on essaye d’accéder à une page personnelle, mettez les permissions de /home/$USER en chmod 755 :

# chmod 755 /home/$USER

Vérifiez que le serveur Apache fonctionne bien. Sur l’ordinateur client tapez l’adresse IP du serveur dans la barre d’adresse du navigateur Web. Le message It Works ! doit apparaitre.

Etape 6: Installation de PHP

Le P de LAMP peut signifier PHP, Python ou encore Perl. WordPress étant écrit en PHP, c’est donc PHP qui sera installé avec la commande :

# apt-get install php5 php5-mysql libapache2-mod-php5

Testons à présent PHP. Supprimer le fichier /var/www/index.html en tant que root :

# rm /var/www/index.html

Créez à présent le fichier index.php mais cette fois-ci en qu’utilisateur :

# exit
$ nano /var/www/index.php

Dans ce fichier ajoutez la ligne de code suivante.

<!--?php phpinfo(); ?-->

Enregistrez, quittez.
Sur l’ordinateur client, dans le navigateur, retaper l’adresse IP du serveur, à la place du message It Works !, doit s’afficher la configuration de PHP.

Etape 7 : Installation de PhpMyAdmin

Worpdress nécessite la création d’une base de données. Les puristes créeraient la base donnée directement dans le terminal, mais pour ceux qui souhaitent quelques chose de plus user friendly, installez PhpMyAdmin comme suite :

# apt-get install phpmyadmin

Durant l’installation le mot de passe root de MySQL sera demandé, de même qu’un mot de passe root pour PhpMyAdmin. Inutile de préciser que pour des raisons de sécurité il est recommandé de choisir un mot de passe différent.

Retourner dans le navigateur Web de votre machine cliente, puis taper l’adresse IP du serveur suivit de /phpmyadmin

Ex : 192.168.1.254/phpmyadmin

Entez le nom d’utilisateur root, puis le mot de passe créé pendant l’installation.
Toujours pour des raisons de sécurité, il est conseillé de créer un nouvel utilisateur, pour cela allez dans Privilèges puis Ajouter un utilisateur. Renseignez les champs Nom d’utilisateur, Client (sélectionnez Utiliser la table Host) et Mot de passe. Cochez également la ligne :  Créer une base portant son nom et donner à cet utilisateur tous les privilèges sur cette base

A présent votre serveur est prêt à accueillir WordPress. L’installation de WordPress est décrite dans l’article intitulé: Sécuriser WordPress dès l’installation

Impossible de créer le dossier wp-content/uploads

Impossible de créer le dossier wp-content/uploads sur WordPress

By | Aide et astuces, côté serveur | 7 Comments

« fichier.jpg » n’a pas pu être mis en ligne suite à une erreur
Impossible de créer le dossier wp-content/uploads/2013/09. Son dossier parent est-il accessible en écriture par le serveur ?

Tel est le message d’erreur qui peut être rencontré lors de l’import d’un fichier dans la bibliothèque de WordPress.

Pour rappel, les fichiers figurant dans cette bibliothèque se trouvent dans le dossier wp-content/uploads suivit d’un ensemble de sous dossiers.

Dans le menu Réglages > Médias, il se peut que la ligne Organiser mes fichiers envoyés dans des dossiers mensuels et annuels, soit coché. C’est un réglage par défaut qui signifie que WordPress va créer un ensemble de sous dossier dans /wp-content/uploads  en fonction de la date d’importation du fichier.

Exemple : Si un fichier à était importé le 12/09/13, alors WordPress va ranger ce fichier dans /wp-content/uploads/2013/09

capture

Le sous dossier /2013 correspond à l’année où le fichier à était importé. Le second, /09, correspond au numéro du mois.

C’est la raison pour laquelle ce message d’erreur ne peut être rigoureusement identique chez tout le monde. D’autant plus, que le nom du fichier (ici 31.jpg) figure dans le message erreur.

Pour remédier à ce problème, il faut accéder au dossier /wp-content/uploards via votre client FTP, (filezilla, Cyberduck…) et y vérifier les droits en lecture/écriture. Ils doivent être en 777. Si ça n’est pas le cas, alors mettez les droits en 777 sans oublier d’activer la récusions afin que les sous dossier de /uploads bénéficient eux aussi des droits 777.

A ce stade il est possible que le problème soit résolu. Vérifiez en important un fichier dans la bibliothèque.

Dans le cas contraire, allez dans le menu Réglages > Médias, et décochez la ligne : Organiser mes fichiers envoyés dans des dossiers mensuels et annuels. Là encore cette étape peut faire des miracles. Vérifiez à nouveau en important un fichier dans la bibliothèque.

Si le problème n’est toujours par résolu, il reste encore une dernière solution. Retournez dans le dossier /wp-content (toujours à l’aide de votre client FTP préféré).

Renommez le dossier /uploads en /uploads_old, puis créer un nouveau dossier /uploads auquel il lui sera attribuer les droits 777. Le problème doit être résolu. Vérifiez une troisième fois en important un fichier dans la bibliothèque. Une fois cette vérification terminé (et  espérons-le  fructueuse), transférer le contenu du dossier /uploads_old dans dossier /uploads, afin de récupérer l’intégralité de vos fichiers.

Une fois le transfert terminé, le dossier /uploads_old pourra être supprimé.

Attention : Il est imprudent de laisser des fichiers et dossier avec des droits en 777. Une fois le problème résolut, n’oublier pas de remettre les dossier wp-content et ses sous-dossier avec des droits plus restreints (775 au minimum).