Archives par mot-clé : configuration

Autoriser la connexion de root en FTP avec vsFTPd

Publié le par
Répondre

ATTENTION : Ce que je détail ici est à titre informatif et n’est en aucun cas recommandé.

Le cas m’est arrivé une fois où je devais me connecter en root en FTP car je n’avais pas encore créé d’autre utilisateur. Ceci est à éviter autant que possible pour plusieurs raison :

  • La première est le fait que le protocole FTP utilisé sans SSL (FTPS) fait transiter en clair les informations de connexion. Ainsi, une personne qui intercepte le mot de passe root peut prendre un accès total de la machine.
  • La deuxième est que, selon moi, le root est l’administrateur de la machine et pas de chaque logiciel.

vsFTPd utilise un fichier qui contient la liste des utilisateurs n’ayant pas le droit de se connecter. Celui ci est /etc/ftpusers. On voit en première ligne que le nom de root y est apposé. Il suffit de supprimer la ligne correspondante et de redémarrer vsFTPd avec

/etc/init.d/vsftpd restart

pour que l’utilisateur root soit autorisé à se connecter.

Installation d’un serveur web sous Debian

Publié le par
Répondre

J’avais lors d’un précédent post, expliqué comment installer WordPress sur son serveur Web mais je n’avais pas expliqué comment installer ce serveur.

On partira donc du principe que l’on a besoin de mettre en place un serveur HTTP, un interpréteur PHP, un SGBD (Système de Gestion de Base de Données) et un serveur FTP. De plus pour le contrôler facilement à distance on utilisera le protocole SSH.

Tout d’abord le choix de la distribution. Ayant toujours utilisé des distributions basées sur Debian et Debian étant réputé pour sa stabilité, il m’a semblé évident de prendre cette distribution comme base. De plus les installations sont facilitées grâce à des dépôts bien remplis (pas toujours à jour, mais fournis).

Ainsi, après une installation standard de cette distribution, enfin, en tout cas sans gestionnaire de fenêtre vu que c’est pour un serveur, nous allons passer à la phase d’installation.

Les logiciels que j’ai choisis d’utiliser pour combler tous nos besoins sont :

  • Serveur HTTP : Apache
  • Serveur FTP : vsFTPd
  • Serveur SSH : openSSH
  • interpréteur PHP : PHP5
  • SGBD : MySQL

Nous allons commencer par installer openSSH afin de pouvoir administrer le serveur à distance par la suite à l’aide de la commande :

apt-get install ssh

Nous verrons les configurations à apporter à chaque logiciel par la suite. Installons maintenant le serveur Apache à l’aide de la commande :

apt-get install apache2

Puis PHP et son module pour apache en tapant :

apt-get install php5 libapache2-mod-php5

Pour MySQL, Debian se charge normalement tout seul de récupérer les paquets qui permettent les interactions avec PHP. Dans le cas contraire il faudra les rajouter en plus (paquet php5-mysql). On tapera donc :

apt-get install mysql-server

Un mot de passe root est demandé à ce moment là. Bien penser à en mettre un fort.

Nous allons enfin installer vsFTPd en tapant :

apt-get install vsftpd

Maintenant que tous les logiciels dont nous avons besoin sont installés, il va nous falloir les configurer. Toujours garder en tête cependant que les configurations sont la partie la plus personnelle de ce genre de mise en place car elles dépendent principalement de ce que l’on désire faire. Je ne détaillerais pas les configurations d’SSH car j’ai déjà mis un exemple détaillé dans ce post ci.

Commençons donc avec la configuration d’Apache. Un fichier de configuration extrêmement important est le fichier /etc/apache2/conf.d/security. C’est ce fichier qui déterminera le niveau de détail des messages d’erreur. Pour un serveur en production, afin d’éviter toute fuite d’information sensible en cas de faille, on mettra les lignes :

ServerTokens Prod
ServerSignature Off
TraceEnable Off

Pour un serveur de développement, le but étant d’obtenir un maximum d’informations, on mettra :

ServerTokens Full
ServerSignature On
TraceEnable Extended

La configuration de base d’Apache donne le dossier /var/www/ comme dossier du site principal. On peut héberger plusieurs sites sur un seul serveur en rajoutant des fichiers de configuration dans le dossier /etc/apache2/sites-available/ (De manière globale, tout fichier présent dans ce dossier est inclus dans le fichier de configuration au lancement d’Apache). Une configuration minimale de site possible est :

<VirtualHost <ADRESSE_DU_SERVEUR>:<PORT_DE_CONNEXION>>
ServerName <NOM_DU_SERVEUR>
ServerAdmin <ADRESSE_DU_WEBMASTER>

DocumentRoot <DOSSIER_DU_SITE>
<Directory <DOSSIER_DU_SITE>>
Options -Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>

CustomLog <URI_DU_FICHIER_DE_LOG> combined
LogLevel warn
</VirtualHost>

Pour plus de détail on peut aller sur la documentation officielle d’Apache sans oublier les conseils sur la sécurité. On pourra, selon la distinction que l’on voudra faire entre les différents sites web (différentes adresses IP, différents ports de connexion), utiliser cette page de documentation ou celle ci pour choisir ses options.
Vous remarquerez le -Indexes qui permet de ne pas lister le contenu d’un dossier lorsque le fichier index.html ou index.php n’existe pas. Pour d’autres options de sécurités on peut aller voir par là.

Il ne reste alors plus qu’à activer le site nouvellement configuré à l’aide de la commande

a2ensite <NOM_DU_FICHIER_DE_CONFIGURATION>

et à redémarrer apache (nous ferons ceci à la fin).

En ce qui concerne PHP, je ne rentrerais pas dans les détails de la configuration car ils sont beaucoup trop dépendants de ce que l’on souhaite mettre en place. De plus, ceux de base conviendront la plupart du temps.

La configuration de MySQL étant plus une configuration par base de données que dans sa globalité, les paramètres originaux feront largement l’affaire. Cependant, il ne faudra pas oublier de créer un nouvel utilisateur pour chaque base afin d’améliorer la sécurité et de ne pas laisser traîner le mot de passe root quelque part. J’avais détaillé le script de création dans mon post sur la mise en place de mon blog.

Il nous reste enfin à configurer vsFTPd. Mon choix s’est porté sur ce logiciel plutôt que sur ProFTP, qui est le plus souvent cité lorsque l’on cherche un serveur FTP, car, notamment, il a été conçu en étant orienté sécurité. Le fichier de configuration est /etc/vsftpd.conf. Il est bien détaillé et facile à paramétrer. On peut choisir de chrooter les utilisateurs, utiliser le serveur en IPv4/IPv6, autoriser l’accès anonyme, etc … J’ai détaillé une des configuration que j’utilise sur l’un de mes serveurs dans ce post.

Il suffit ensuite soit de redémarrer la machine (le plus simple), soit de redémarrer tous les services, après configuration. On peut les relancer un par un à l’aide des commandes :

/etc/init.d/apache restart
/etc/init.d/ssh restart
/etc/init.d/vsftpd restart

On a alors un serveur HTTP/FTP/MySQL/SSH prêt à être utilisé.

Configuration de subversion et lancement automatique

Publié le par
Répondre

Depuis quelques temps, j’ai pris l’habitude de gérer mes projets de développement à l’aide d’un gestionnaire de versions, en l’occurrence, subversion. Je n’ai encore jamais eu l’occasion de tester git donc ce choix est simplement basé sur mes préférences actuelles et elles peuvent être amenées à changer. J’utilise subversion car il est libre, facile à mettre en place, agréable à utiliser et surtout, je sais m’en servir.

On peut installer subversion assez simplement soit en passant par les dépôts de paquets des différentes distributions, soit en le compilant soit même (ayant eu besoin de la version 1.7.4 récemment et vu que la version disponible sous xubuntu était la 1.6.17, j’ai été amené à le faire sur mon poste client et cela se fait sans encombre) en installant préalablement ses dépendances (pour ma part zlib, apr et sqlite).

La première chose à faire lorsque subversion est installé est de créer le dépôt qui accueillera le projet. Pour ma part, j’ai créé un dossier /home/SVN dans lequel je créé chacun de mes dépôts à l’aide de la commande :

svnadmin create <nom_du_depot>

Nous allons maintenant configurer le dépôt pour rajouter des utilisateurs et gérer les droits sur les différents dépôts. Pour ce faire, nous allons nous rendre dans le dossier du dépôt, puis dans conf. Dans ce dossier, il y a 3 fichiers qui sont authz, passwd et svnserve.conf. Nous allons tout d’abord modifier le fichier passwd pour rajouter à la fin de nouveaux utilisateurs en suivant ce format :

login = motdepasse

Une fois les utilisateurs et leurs mots de passes ajoutés, nous allons modifier le fichier svnserve.conf. A part lorsque je ne souhaite pas que qui que ce soit puisse lire mon code source si il n’est pas authentifié, je dé-commente les lignes

anon-access = read
auth-access = write
password-db = passwd

Ceci a pour effet d’autoriser la lecture lors d’un accès anonyme et l’écriture pour les utilisateurs authentifiés dont les identifiants sont inscrits dans passwd.

Afin de ne pas laisser ces mots de passes qui sont en clair à la vue de tout le monde, je met les droits des 3 fichiers à 0600.

Il ne reste plus qu’à lancer le serveur à l’aide de la commande suivante :

svnserve -d -r <dossier_contenant_les_depots>

Ici, <dossier_contenant_les_depots> est /home/SVN/.

L’un des problèmes de subversion est que cette action est à répéter à chaque démarrage de la machine. Afin de pallier à ce problème, on peut créer un script de lancement et l’exécuter au démarrage de la machine. Voici le script que j’ai créé (ATTENTION : ce script est adapté à la position de mon dossier subversion mais est à adapter en fonction de la localisation de ce dernier) :

#!/bin/sh
#
### BEGIN INIT INFO
# Provides: svnserve
# Required-Start: $syslog
# Required-Stop: $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start and stop svnserve daemon at boot time
# Description: Controls the main subversion server \svnserve\ with /home/svn
### END INIT INFO

ECHO_BIN=/bin/echo

usage()
{
	$ECHO_BIN "Usage : $0 (stop|start|restart)"
}

SVN_stop()
{
	/sbin/start-stop-daemon --stop --exec /usr/local/bin/svnserve
	$ECHO_BIN "[+] Server stopped"
}

SVN_start()
{
	/usr/local/bin/svnserve -d -r /home/svn
	$ECHO_BIN "[+] Server launched on /home/svn"
}

if [ -x /usr/local/bin/svnserve ]
then
	if [ -z $1 ]
	then
		usage
	else
		case $1 in
			stop)
				SVN_stop
			;;
			start)
				SVN_start
			;;
			restart)
				SVN_stop
				SVN_start
			;;
			*)
				usage
				exit 1
		esac
	fi
else
	$ECHO_BIN "Svnserve not installed."
	exit 1
fi

exit 0

Il faut placer ce script dans /etc/init.d/ et bien penser à lui donner les droits 0755. Une fois à sa place, il ne reste plus qu’à l’activer au lancement de la machine en l’ajoutant aux différents /etc/rcx.d/ à l’aide la commande :

update-rc.d <nom du script> defaults

On peut vérifier à ce moment, après un redémarrage de la machine à l’aide de la commande

ps -e | grep svnserve

que tout est fonctionnel. On pourra alors accéder aux dépots en se connectant à :

svn://<nom_de_domaine_ou_IP>/<nom_du_depot>

Activer le wifi sur Xubuntu, sur un PC avec une touche de blocage physique

Publié le par
9

J’ai récupéré un vieux PC portable avec 512Mo de RAM et j’ai décidé d’en faire un PC d’appoint pour les invités qui auraient besoin d’un accès à internet à la maison et qui n’auraient pas amené leur propre ordinateur. J’ai donc installé une distribution Xubuntu dessus, pour divers avantages que je lui trouve, avec tous les logiciels qui vont bien pour une utilisation d’appoint (firefox, vlc, gimp, libreoffice, …). Ce PC est un HP Compaq nx6110 et possède un bouton d’activation/désactivation du Wifi.

Une fois l’installation, avec une connexion câblée, terminée, un problème restait. Le wifi n’était pas activé avec comme source d’erreur un blocage physique. Une petite recherche sur internet m’a permis de trouver comment vérifier cela grâce à la commande :

rfkill list

Celle ci énumère les blocages existant sur les différentes cartes. En effet, ma carte wifi était bloquée physiquement. Un appuie sur le bouton du wifi et le statut avait changé. Je n’ai pas essayé de redémarrer à ce moment là pour savoir si ceci suffisait mais il est fortement possible que oui. J’ai cependant rajouté une étape qui consistait à taper :

rfkill unblock all

Celle ci me permettait de m’assurer qu’aucun blocage n’était maintenu. Après un redémarrage, ma carte était bien reconnue et débloquée mais le pilote n’était pas installé. Afin de savoir lequel installer, j’ai utilisé la commande :

lspci

qui permet de lister tout le matériel disponible dans l’ordinateur dont la carte wifi et ainsi de connaître la marque de celle ci. J’ai pu alors voir que je possédait une broadcom. Il m’a suffit d’installer les pilotes correspondant en l’occurrence :

apt-get install firmware-b43-installer

pour que ma carte wifi soit enfin fonctionnelle.

Une autre solution que j’avais trouvée sur internet mais que je n’ai pas du tout testée consistait à supprimer purement et simplement le fichier /dev/rfkill.

Enlever les memtests de grub

Publié le par
Répondre

Utilisant Xubuntu comme distribution principale, je me retrouve, comme avec Ubuntu d’ailleurs, avec memtest86+ d’installé par défaut. Or cette option me surcharge inutilement mon menu de boot grub alors que je ne suis amené à l’utiliser qu’une fois de temps en temps ou lors d’un gros crash de la machine dans lequel je soupçonne une défaillance matérielle (autant dire rarement).

Jusqu’ici, je supprimais purement et simplement memtest86+ de ma machine sans plus me poser de question puis j’actualisais mon menu avec grub-mkconfig.

Depuis ma dernière mise à jour de Xubuntu qui m’a réinstallé ce délicieux paquet, j’y ai réfléchis à deux fois et je me suis dit que je pouvais être amené à l’utiliser autrement qu’avec un liveCD (en vacances par exemple) et que ce n’était finalement pas une mauvaise chose de le conserver. Je ne voulais cependant toujorus pa qu’il figure dans mon menu de boot.

La solution s’est révélée simple puisqu’il m’a suffit de créer un dossier dans /etc/grub.d/, que j’ai nommé deactivate, mais le nom importe peu, et d’y mettre tous les scripts de /etc/grub.d/ que l’on ne souhaite plus voir exécuté. En l’occurence 20_memtest86+. Une fois ce petit déplacement fait, il suffit de regénérer son fichier /boot/grub/grub.cfg avec la commande :

grub-mkconfig -o /boot/grub/grub.cfg

pour ne plus voir apparaître cet énervant memtest au démarrage. Pour le réactiver, il me suffit de remettre 20_memtest86+ à sa place d’origine et à refaire la commande si dessus.

Sélection rectangulaire NetBeans

Publié le par
Répondre

Me mettant au développement Web pour différents projets dont une interface plus conviviale pour http://www.peanut-soft.com/, je suis tombé sur une option que je trouve fantastique et qui est la sélection verticale. Voulant l’avoir sur mon IDE favoris, je me suis lancé à la recherche d’un plugin me permettant de l’activer.

Et bien la bonne nouvelle est que cette option est nativement intégrée à NetBeans depuis sa version 7.1. Donc à part de rares cas où l’emploi de la 6.9 est encore utile, une simple mise à jour suffit à posséder la sélection rectangulaire.

Pour l’utiliser, il suffit de cliquer sur l’icône correspondante au dessus de la zone de texte ou d’utiliser le raccourcis Ctrl + Shift + R.

Configuration de mes connexions SSH

Publié le par
Répondre

J’administre tous mes serveurs (tous sous Linux) en ligne de commande. L’interface graphique consomme en effet beaucoup de ressources inutilement et n’est pas nécessaire pour seulement quelques accès par mois. De plus, la ligne de commande est plus puissante.

Pour me connecter simplement et en toute sécurité j’utilise le protocole SSH qui est parfaitement adapté à la situation. Voici les quelques configurations que j’applique systématiquement.

Je commence tout d’abord par me générer une paire de clés qui me serviront à me connecter par la suite. Cette étape peut n’être faite qu’une fois, puisqu’il suffira d’utiliser la même clé pour tous ses serveurs après. La commande est :

ssh-keygen -t rsa -b 2048

Ceci générera une paire de clés RSA de 2048 bits. Il suffit de suivre les instructions lors de la génération des clés pour mettre un mot de passe à ces clés. Je copie ensuite la clé publique générée dans <HOME>/.ssh/authorized_keys sur le serveur.

Je modifie ensuite le fichier /etc/ssh/sshd_config de la manière suivante pour appliquer mes réglages de sécurité (ATTENTION : sans accès physique à la machine, laisser le paramètre PasswordAuthentication à yes jusqu’à ce que la connexion soit réussie avec la clé, autrement il sera très contraignant d’arriver à se reconnecter) :

# Numéro du port en écoute sur lequel on se connecte
Port <NUMERO DE PORT>

# Vérifier que la version est bien la 2 car la version 1 avait une faille critique
Protocol 2

# Bannière affichée avant l’autorisation de connexion (Je le met rarement mais ça égaye un peu la console à la connexion)
#Banner /etc/issue.net

# Empêche la connexion directe en root
# N’empêche pas de se connecter en root depuis un autre utilisateur
PermitRootLogin no

# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

# Temps en seconde pendant laquelle une connexion est ouverte sans être loggué
LoginGraceTime 10

# Nombre maximum d’essais d’authentification autorisés
MaxAuthTries 1

#Types d’authentifications autorisés
PubkeyAuthentication yes
RSAAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
UsePAM no
PasswordAuthentication no

# Fichier contenant les clés autorisées
AuthorizedKeysFile %h/.ssh/authorized_keys

#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Logging
SyslogFacility AUTH
LogLevel INFO

# check file modes and ownership of the user’s files and home directory before accepting login
StrictModes yes

# Don’t read the user’s ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don’t trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to ‘yes’ to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of « PermitRootLogin without-password ».
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to ‘no’.

# La plupart du temps je n’autorise que mon compte à se connecter
AllowUsers <NOM_DES_UTILISATEURS_AUTORISES>

# Si il faut mettre plusieurs comptes, mieux vaut utiliser ceci
#AllowGroups <NOM_DU_GROUPE_AUQUEL_APPARTIENNENT_TOUS_LES_COMPTES_AUTORISES>

# On peut aussi choisir de refuser juste certains utilisateurs/groupes
#DenyUsers <NOM_DES_UTILISATEURS_REFUSES>
# DenyGroups <NOM_DU_GROUPE_AUQUEL_APPARTIENNENT_TOUS_LES_COMPTES_REFUSES>

Une fois ce fichier modifié, je relance ssh à l’aide de :

/etc/init.d/ssh restart

et me voilà avec un serveur disposant d’une connexion SSH correctement sécurisée.

Configuration de grub

Publié le par
Répondre

Installant toujours plusieurs systèmes d’exploitations sur mon ordinateur portable, j’ai besoin d’un bootloader me permettant de switcher facilement entre eux. Je détaillerais dans un prochain article les différents systèmes d’exploitation que j’utilise.

La version de grub que j’utilise est la version Grub 2 aussi connue sous le nom de grub-pc  (à l’opposé de la version 1, aussi nommée, grub-legacy).

Le fichier de configuration qui sera lu à chaque démarrage est le fichier /boot/grub/grub.cfg. Ce fichier est reconstruit à chaque fois qu’une nouvelle version du noyau est installée, ou, plus globalement à chaque fois que la commande grub-mkconfig est exécutée. Elle se sert des scripts situés dans /etc/grub.d/ pour générer le fichier de boot, ainsi que de /etc/default/grub.

Mes besoins de personnalisation de grub se limitent à l’édition de /etc/default/grub que je modifie comme ceci :

GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=5
GRUB_GFXMODE=1920×1080
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT= »quiet splash »
GRUB_CMDLINE_LINUX= » »

Je boot ainsi sur le premier élément de ma liste par défaut après 5 secondes si aucune touche n’est pressée.

Pour avoir plus de détail sur les options de ce fichier, on peut lancer la commande :

info -f grub -n 'Simple configuration'

Je rajoute depuis peu une image de fond à grub. Contrairement à grub-legacy, ceci est d’une simplicité déconcertante puisqu’il suffit de copier une image dans /boot/grub pour qu’elle soit automatiquement détectée et ajoutée à grub.cfg lors de sa génération. La première image rencontrée par ordre alphabétique est utilisée. Les formats jpg, png et tga sont supportés. Si l’on souhaite le faire manuellement, il est possible de spécifier le chemin de l’image avec l’option « GRUB_BACKGROUND=« .

Enfin, je supprime toujours memtest86+ dans /boot/ pour ne pas avoir une entrée dans le menu alors que je ne fais des tests mémoires que quand je rencontre des problèmes matériels (autant dire presque jamais).

Je compte rajouter un mot de passe sous peu pour bloquer l’accès à l’édition des commandes de boot. Ceci permet en effet de pallier à une faille de sécurité importante, conservée pour permettre le changement du mot de passe root en cas d’oublie, et qui permet de lancer un shell en super utilisateur, sans demander de mot de passe.

Configuration du serveur FTP

Publié le par
Répondre

Je voulais un serveur FTP pour pouvoir partager des données facilement et surtout pour avoir un espace de stockage accessible depuis n’importe où. Le premier besoin était de transmettre un gros fichier sans être limité par les quotas d’un mail.

Après avoir cherché un peu sur internet, j’ai décidé d’utiliser vsftpd mais d’autres font tout aussi bien l’affaire (proFTPd par exemple). Je l’ai donc installé avec :

apt-get install vsftpd

Je voulais que chaque utilisateur ait un espace qui lui est propre mais aussi un dossier qui serait commun à tous pour faciliter le partage. J’ai modifié le fichier de configuration ainsi :

listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
ftpd_banner=Bienvenue sur mon FTP
chroot_local_user=YES
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/private/vsftpd.pem

Ceci me permet de garder chaque utilisateur dans son dossier avec des droits de lecture et d’écriture.

EDIT : ATTENTION : Ce qui suit est absolument nul, faisable avec des options sur les commandes de base sans avoir besoin de faire des scripts compliqués, sera supprimé dès que je me serais re-penché sur la question et a été supprimé de mon serveur tellement c’est lourd. Last but not least : le dossier de partage ne fonctionne pas. 

Pour le dossier de partage, j’ai utilisé ce que je qualifierais de patch parce que lourd à mettre en place et à maintenir. Je cherche un moyen plus efficace de faire la même chose.J’ai actuellement procédé ainsi :

mkdir /home/partage
groupadd ftpusers
chown root /home/partage
chgrp ftpusers /home/partage

Maintenant, à la création de chaque utilisateur, on le rendra membre du groupe ftpusers, on créera un dossier de partage et on montera /home/partage dedans. En plus, j’ai fait manuellement toutes ces opérations parce que je n’avais pas lu la manpage de useradd. Tout ceci peut donc évidemment être amélioré.

Voici les deux scripts que j’utilise actuellement pour créer et supprimer des utilisateurs :

Création :

#!/bin/sh
group="/etc/group";
fstab="/etc/fstab";

if [ -z $1 ]
 then
		echo "Usage : $0 username";
		echo "This script was designed to add a user and to give him an access to the shared zone";
 else
		useradd $1;
		mkdir -p /home/$1/partage;
		chown -R $1 /home/$1;
		chgrp -R $1 /home/$1;
		chmod 740 /home/$1
		mount --bind /home/partage /home/$1/partage;
		cp $group $group~
		sed -i "/ftpusers*/ s/.*/&amp;,$1/" $group;
		echo "/home/partage\t/home/$1/partage\tnone\tbind,defaults,auto\t0\t0" &gt;&gt; $fstab;
		echo "Initialisation du mot de passe\n";
		passwd $1;
		echo "User $1 created with success";
 fi

Suppression :

#!/bin/sh
fstab="/etc/fstab";

if [ -z $1 ]
then
        echo "Usage : $0 username";
        echo "This script was designed to add a user and to give him an access to the shared zone";
else
        umount /home/$1/partage;
        userdel $1;
        mv /home/$1 /home/archive;
        sed -i "/*$1*/ s/.*//" $fstab;
        sed -i '/^$/d' $fstab;
        echo "User $1 deleted with success";
fi

Je me rend compte en écrivant cet article que je ne supprime pas la ligne correspondante dans fstab.

A la suppression je déplace l’utilisateur dans le dossier archive au cas où il aurait fallut récupérer des données lui appartenant.

Je pense que ce que je veux faire est possible avec des utilisateurs virtuels. Ce sera mon prochain fil de recherche.

Configuration et mise en place de WordPress

Publié le par
Répondre

Voici un petit article uniquement consacré à WordPress puisque j’ai décidé de l’héberger moi même désormais.

Après pas mal de temps à chercher quels étaient les droits à donner aux différents dossiers pour que WordPress cesse de m’afficher des erreurs de permissions dès qu’il essaye de faire quelque chose, je me suis rendu compte qu’il suffisait d’attribuer www-data comme utilisateur et groupe pour que tout fonctionne. En réalité, j’ai fait un wget pour récupérer la dernière version directement sur le serveur et je l’ai décompressée (tar -xzf latest.tar.gz). Il s’est chargé de conserver les droits.

En ce qui concerne la base de donnée MySql, je voulais créer un utilisateur de blog qui aurait la possibilité de gérer toute la base sans pouvoir toucher aux autres.
J’ai donc fait :

CREATE DATABASE <NOM_DE_LA_BASE>;
GRANT ALL PRIVILEGES ON `<NOM_DE_LA_BASE>`.* TO '<LOGIN>'@'localhost' IDENTIFIED BY '<MOT_DE_PASSE>';

J’obtiens ainsi un utilisateur qui a un accès total à la base de donnée de WordPress, qui ne peut se connecter qu’en local et qui ne peut pas toucher à mes autres BDD.

Pour ce qui est de la réécriture des liens afin d’avoir des permalinks facilement lisibles, j’ai dû activer le module rewrite d’apache en tapant la commande :

a2enmod rewrite

Il m’a fallut ensuite modifier dans /etc/apache2/site-available le fichier default en remplaçant dans la sous-catégorie correspondante à mon site (en l’occurrence <Directory /var/www>) « AllowOverride None » par «  »AllowOverride All ».

Il ne me reste alors plus qu’à configurer le CMS depuis l’interface d’installation disponible depuis l’adresse du site.