lindev.fr

Aller au contenu | Aller au menu | Aller à la recherche

14 juil. 2015

Monter un Bucket S3 sur un serveur Débian

S3, espace de stockage illimité chez Amazon avec des tarifs défiant toute concurrence. Qui en plus de son prix, offre des options plus qu’intéressantes...

  • chiffrement des données
  • versioning automatique
  • rotation ou mise en glacier des vielles versions ..


Etc ...
Je ne vais pas détailler ces options dans ce billet, mais juste expliquer comment monter un Bucket S3 ( répertoire S3 ) sur une machine / serveur linux afin d'y accéder comme un simple montage réseau . Nous verrons également comment le monter automatiquement via une simple ligne dans le fstab.

Prérequis

Nous allons utiliser fuse pour monter ce bucket, et l'authentification peut être chiffrée selon vos options, nous allons installer tout ce qu'il nous faut...

sudo apt-get install build-essential git libfuse-dev libcurl4-openssl-dev libxml2-dev mime-support automake libtool fuse-utils pkg-config libssl-dev

S3fs-fuse

Maintenant, S3 + fuse n'étant pas un "système de fichiers" conventionnel, nous allons utiliser l'outil s3fs-fuse disponible sur un dépôt Gît

cd /usr/local/src/
git clone https://github.com/s3fs-fuse/s3fs-fuse
cd s3fs-fuse/
./autogen.sh
./configure --prefix=/usr --with-openssl 
make
sudo make install

Authentification S3

Sauf si votre serveur se trouve sur la plateforme Amazon et que vous lui avez donné des droits spécifiques (S3) à sa création, il vous faudra obligatoirement préciser le couple "Access Key / Secret Key" récupéré sur la plateforme Amazon.
Personnellement, je donne à mes utilisateurs un minimum de droits. Dans mon exemple donc, mon utilisateur fictif "John Doe" aura uniquement accès à son bucket, qui sera appelé "jdbucket".
Nous allons donc éditer le fichier qui va lister les authentifications passwd-s3fs.

sudo vim /etc/passwd-s3fs

Le contenu devra respecter la forme suivante bucketName:accessKeyId:secretAccessKey :

jdbucket:AKIAIOSFODNN7EXAMPLE:wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Nous allons maintenant retirer un maximum de droits au fichier passwd-s3fs

sudo chmod 600 /etc/passwd-s3fs

Montage

Ne nous reste plus qu'à monter notre bucket jdbucket . Disons sur le répertoire /var/mntJdBucket

Commençons par créer le répertoire de montage.

sudo mkdir /var/mntJdBucket; sudo chmod 777 /var/mntJdBucket

Testons le montage avant de la mettre dans le fstab

/usr/bin/s3fs jdbucket /var/mntJdBucket -ouse_cache=/tmp,passwd_file=/etc/passwd-s3fs

Note: Spécifier le fichier de mot de passe S3 n'est pas obligatoire.
Si tout va bien .. vous voilà connecté à votre S3 !
Ne vous faite pas berner par le débit ( important ), ici le débit apparent sera celui de votre disque dur, car l'option use_cache=/tmp utilise un répertoire local comme cache entre votre système et le S3.

Fstab

Ne nous reste plus qu'à configurer notre montage dans le fstab, afin que le montage se fasse à chaque démarrage.

sudo vim /etc/fstab


Voici la ligne qu'il faut ajouter

#Fuse
s3fs#jdbucket	/var/mntJdBucket	fuse	rw,_netdev,use_cache=/tmp,allow_other,passwd_file=/etc/passwd-s3fs	0	0

Au niveau des options, du classique, droits en lecture et écriture pour les utilisateurs, attente de la connexion réseau pour tenter de monter le bucket, configuration du répertoire de cache et du fichier de mot de passe ( toujours facultatif )

Conclusion

Nous avons maintenant fait le tour du montage S3 sur une machine debian, rien de bien méchant. Cependant, suite à mes tests, je conseille d'utiliser les commandes s3cmd pour envoyer de gros fichiers ( plusieurs Gb ) celle-ci étant plus adaptée.

N'hésitez pas si vous avez des questions.

Ch.

07 mar. 2014

Wheezy & fsck

Le saviez-vous

Mon poste de travail, sous débian Wheezy redémarre régulièrement comme tout poste de travail et pourtant ... jamais il ne ma fait de check disque fsck au démarrage !

Et bien figurez-vous que c'est voulu !

En effet d’après ce que j'ai trouvé sur le web à ce sujet, les développeurs de debian estiment que dans le monde professionnel lorsque qu'une machine ( surtout un serveur ) lance son fsck au démarrage, la plupart du temps, c'est au mauvais moment, et provoque plus de frustrations des admin. sys. qu'autre chose .

Il est vrai que le fait de se baser uniquement sur un facteur temps, ou un nombre de montages des volumes pour exécuter cette commande rend sa réelle utilité très aléatoire.
Ils estiment donc que les Admin. Sys. sons assez "grands" pour planifier au moment opportun le fsck des disques .

Le réactiver par défaut à la création de partition

Lors de la création d'une nouvelle partition, pour réactiver par défaut le fsck sur le nombre de montages et l'intervalle de temps, il vous faut changer le paramètre suivant ( en le passant à 1 ):

enable_periodic_fsck = 0

Dans le fichier : /etc/mke2fs.conf

Le réactiver sur un partition existante

Pour réactiver le fsck tout les 50 montages :

sudo tune2fs -c 50 /dev/sdx

Pour réactiver le fsck si le dernier date de plus de 6 mois :

sudo tune2fs -i 6m /dev/sdx

Désactiver le fsck automatique

Si au contraire vous souhaiter tout désactiver,

tune2fs -c -1 -i 0 /dev/sde1

Forcer un fsck

C'est bien beau de tout désactiver, mais il peut être intéressant de lancer un check des disques de temps en temps quand même !
Pour lancer fsck au démarrage, 2 méthodes

Avec la commande shutdown

shutdown -r -F now

-r Redémarrer la machine après l'arrêt du système.
-F Forcer l'utilisation de fsck lors du redémarrage.

Avec le fichier forcefsck

Le simple fait de créer un fichier nommé forcefsck à la racine du système, va l'obliger à lancer un check fsck au démarrage . Ce fichier sera alors supprimé automatiquement .

sudo touch /forcefsck

Ch.

10 juin 2013

Projet Libérons le cahier Debian

Présentation

Après avoir libéré la traduction anglaise du livre, le but est de boucler la boucle et libérer le livre original, qui est en français.
La proposition est simple: achetez un exemplaire du livre Debian Squeeze, lisez-le tranquillement cet été, décorez votre ordinateur portable avec le magnifique autocollant Debian détouré qui l'accompagnera, et à la rentrée impressionnez vos collègues et amis en montrant tout ce que vous pouvez faire avec Debian (sans avoir déboursé le moindre centime en licences de logiciels) ! :-) 


 

23 fév. 2013

Linux LTSP : Restriction web par utilisateur

juanjo_Firewall.svg

J'administre aujourd'hui un serveur LTSP ( entre autres ) sur lequel se connectent une bonne quinzaine de clients.

Pas de problème jusque là, mais une problématique est apparue, en effet les clients n'ont pas tous les mêmes droits au niveau des accès vers l'extérieur ( le Net ).

Certains doivent avoir accès à 100% au net, d'autres ont le droit d’accès à l'intranet ou apli métier web uniquement .

Les clients se trouvant tous sur le même serveur, il m'est évidemment impossible de gérer celà depuis le Firewall principal.

Je vais donc exposer ici la solution qui me permet de gérer mes clients de façon simple et efficace .

La solution netfilter

le module netfilter ipt_owner va nous permettre de créer des règles de filtrage qui utilisent l'une des variables suivantes

  • UID
  • GID
  • PID
  • SID

Top ! voyons comment le mettre en place

Activer ipt_owner

L'activation est simple, il suffit d'activer le module ( s'il ne l'est pas déjà ) grâce à la commande modprobe

modprobe ipt_owner

info.png Pour l'activer automatiquement au démarrage, il vous suffit d'ajouter le nom du module dans le fichier /etc/modules


Les règles iptables

Voici les options disponibles pour les règles iptables

#Iptables' owner match extension adds four match criteria to the iptables command:
-- uid-owner UID: matches packets generated by a process whose user ID is UID
-- gid-owner GID: matches packets generated by a process whose group ID is GID.
-- pid-owner PID: matches packets generated by a process whose process ID is PID.
-- sid-owner SID: matches packets generated by a process whose session ID is SID.

Le script de règles

Pour faire les choses bien, nous allons commencer par créer un fichier shell pour éditer et activer simplement l'enssemble des règles

vim regles_ltsp.sh

Le contenu :

#!/bin/sh

#Supprime l'enssemble des régles
iptables -F

#Accepte les requêtes en loopback
iptables -A OUTPUT -o lo -j ACCEPT

#On autorise les requêtes sur le réseau local ( intranet applis metier )
iptables -A OUTPUT -o eth0 -d 10.0.0.0/24 -j ACCEPT

#Compte autorisés à aller sur le net
iptables -A OUTPUT -o eth0 -m owner --uid-owner cdsl -j ACCEPT
iptables -A OUTPUT -o eth0 -m owner --uid-owner root -j ACCEPT

#Groupe(s) autorisés à aller sur le net
#iptables -A OUTPUT -o eth0 -m owner --gid-owner net -j ACCEPT

#On bloque les autres
iptables -A OUTPUT -j DROP

On le rend exécutable

chmod +x regles_ltsp.sh

Les commentaires sont assez clair, on bloque tout, puis seuls les utilisateurs cdsl et root sont autorisés à sortir, ainsi que les utilisateurs du groupe net.

Ainsi pour autoriser un autre utilisateur sans toucher / recharger les règles iptables, il suffira de l'ajouter au groupe net

adduser <user> net

Cool !

Bien maintenant comment charger automatiquement nos règles au démarrage du système et de façon efficace.

Chargement automatique

iptables est fournit avec deux commandes très pratiques

  • iptables-save
  • iptables-restore

qui permettent respectivement de "compiler et extraire" les règles actuellement en cours , et de restaurer des règles sauvegardées avec iptables-save

Commençons par activer nos règles, car pour le moment nous avons uniquement créé le script mais nous ne l'avons pas exécuté . Pour voir les règles actuellement en place nous pouvons utiliser la commande iptable -L

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

Aucune règle pour le moment.

On exécute notre script ( en root )

./regles_iptables.sh
# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             10.0.0.0/24         
ACCEPT     all  --  anywhere             anywhere            owner UID match root 
ACCEPT     all  --  anywhere             anywhere            owner GID match net 
DROP       all  --  anywhere             anywhere            

Magnifique !

Sauvegardons nos règles

Nous allons les sauvegarder dans le fichier ( en root ) /etc/iptables.up.rules

iptables-save > /etc/iptables.up.rules

Puis nous allons créer un petit script pour appliquer les régles juste avant de connecter les interfaces réseaux

vim /etc/network/if-pre-up.d/iptables

Voici le contenu, qui utilise la commande iptables-restore

#!/bin/bash
/sbin/iptables-restore < /etc/iptables.up.rules

Et on le rend exécutable

chmod +x /etc/network/if-pre-up.d/iptables

info.png Pour effacer l'enssemble des régles, utiliser la commande iptables -F


Conclusion

Et voilà comment gérer vos règles iptables simplement et proprement au démarrage, en ayant la possibilité de filtrer par utilisateur ou groupe d'utilisateurs.

Bon tests . Ch.

12 juil. 2012

LTSP V5 et Debian Squeeze

logo-ltsp.png

LTSP ( Linux Terminal Server Project )

J'ai pour mission d'informatiser une zone de production de prés de 7000m2, après le câblage de la zone ( RJ45 10/100/1000 ), il m'a fallu trouver un moyen économique / facile à maintenir et surtout résistant à un environnement de production.

Installer des machines autonomes ( PC standard ) n'est donc pas la meilleure solution.

J'ai donc opté pour un système client-serveur, ou les clients dit (léger) n'ont besoin que d'une interface réseau compatible PXE, et d'une carte/chip. graphique pour l'affichage sur l’écran. ( et évidemment , le trio Ecran/clavier/souris ).

Pour ce qui est de la puissance nécessaire, la station gérant uniquement l'affichage ( dans mon cas ) un cpu type atom peut suffire ( C'est l'occasion de recycler les vielles machines qui trainent), n'importe quel client léger peut faire l'affaire .

Je parle, je parle , mais c'est quoi exactement LTSP ....

le principe est simple, d'un coté il y a un serveur ( relativement puissant, cette variante va dépendre du nombre de clients à gérer ), sur lequel vous devrez créer les comptes utilisateurs. De l'autre les clients léger, qui ne sont là que pour déporter l'affichage de la session utilisateur, enfin entre les deux parties un réseau 100/1000.

Plusieurs avantages à ce principe:

  • installation ou mise à jour à un seul endroit, pour l'enssemble des clients
  • Maintenant aisé ( juste un remplacement de matériel, pas de restauration necessaire )
  • Backup simplifié ( une seule origine )

Le Fonctionnement

Avant de vous expliquer comment monter un tel serveur, je vais vous présenter rapidement comment cela se passe entre le client et le serveur.

Commençons par un petit schéma de notre infra .. j'adore les schémas

ltsp-1.png

Nous avons donc un réseau avec un parc de clients légers, un serveur DHCP déjà existant, et enfin notre serveur LTSP, le tout, évidemment relié à l'aide d'un concentrateur de qualité 10/1000/1000.

Bon très bien, quand j'appuie sur le bouton "power" de mon client léger ... il se passe quoi

ltsp-2.png

Bon , détaillons tout ça ..

  1. La carte mère est alimentée, elle détecte ses périphériques, le bios indique que le boot commence via le LAN , ok je balance donc sur le réseau une requête afin que quelqu'un me réponde avec une IP à me donner et les instructions nécessaires à mon Boot système.
  2. Notre serveur DHCP reçoit évidemment cette requête ( comme toute les autres machines présentes sur le réseau ) lui attribut une adresse IP libre ainsi que les paramètres supplémentaires ( Adresse sur Serveur LTSP, Fichier image à charger ... ) que nous détaillerons plus tard
  3. Super nous voilà connecté et identifié sur le réseau, nous pouvons maintenant contacter le serveur LTSP et charger le fichier image via le protocole tftp ( ftp en mode udp )
  4. Le fichier image reçu ( avec les fichiers de conf qui vont avec ), il est chargé en mémoire ( en RAM ) et on continue notre chemin en lançant le système fraichement chargé .
  5. Le système chargé ( distribution debian minimaliste ) nous avons droit à un superbe écran de connexion ( graphisme customisable au passage ). Bien! identifions nous .. login ... mot de passe, notre système minimaliste tente donc à distance de se connecter avec le couple login mot de passe ( tout se fait en SSH, donc rien ne passe en clair à ce moment sur le réseau )
  6. L’authentification réussi on peut voir sur notre client léger, la session (Gnome par exemple) s'afficher. Il nous est alors possible de lancer n'importe quelle application avec la puissance du serveur, tout en étant sur une machine de plus de 10 ans.

Voilà grosso modo comment cela fonctionne avec LTSP . Bien! nous allons maintenant pouvoir aborder la mise en place du serveur, avec plus de facilité.

Environnement Graphique

Et oui .. fatalement il nous faut un environnement graphique sur notre serveur .. n'en n'ayant jamais installé sur aucun de mes serveurs, il m'a fallu commencer par là ...

apt-get install gnome gdm

Continuons ...

LTSP Server

Deux solutions s'offrent à nous à ce stade, soit nous installons le paquet ltsp-server-standalone, soit le paquet ltsp-server ...

Quelle est la différence vous aller me dire ...

C'est très simple, le paquet ltsp-server-standalone est un paquet "tout en un" c'est à dire qu'en plus de vous installer le serveur ltsp, il va aussi installer un serveur DHCP, et TFTP . Ayant dans mon cas un serveur DHCP en place, je vais installer le second paquet ltsp-server.. ( si vous n'en n'avez pas, installer le premier, la seule différence va être que votre DHCP sera sur la même machine que le serveur LTSP ).

Donc ( avec les paquets suggérés ):

apt-get install ltsp-server dnsmasq libasound2-plugins ltspfs ldm-server sdm pulseaudio-esound-compat esound-clients nas-bin ltsp-docs qemu-user-static syslinux-common

Système de fichier NFS

Le système de fichier de notre distribution minimaliste étant situé sur le serveur LTSP ( il n'est pas chargé en RAM ), ce dernier est monté nia NFS, il nous faut donc l'installer et configurer le fichier /etc/exports afin d'y ajouter le répertoire contenant notre système de fichiers.

apt-get install nfs-kernel-server
vim /etc/exports

Nous allons y ajouter la ligne suivante

/opt/ltsp *(ro,no_root_squash,async,no_subtree_check)

Nous pouvons ensuite relancer le service NFS

invoke-rc.d nfs-kernel-server restart

Tftp

Tout à l'heure j'ai parlé du serveur TFTP, utiliser par le client PXE pour charger le noyau minimaliste, et les quelques fichiers de conf ..

Installons le :

apt-get install atftpd

La configuration par défaut n'est pas valide, nous allons donc le reconfigurer.

Commençons par supprimer la ligne suivante du fichier /etc/inetd.conf

tftp            dgram   udp4    wait    nobody /usr/sbin/tcpd /usr/sbin/in.tftpd --tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=5 /srv/tftp

Puis reconfigurons le

dpkg-reconfigure atftpd

Gardez toutes les valeurs par défaut, sauf au moment ou il vous demande de spécifier la plage réseau ( indiquer la votre )

atftpd.png

Enfin, nous pouvons le relancer ...

invoke-rc.d openbsd-inetd restart

Ip Forwarding

Notre serveur va relayer les paquets de nos clients léger, nous devons donc activer l'ip forwarding

Pour le faire en "one shoot", sans redémarrer

echo "1" > /proc/sys/net/ipv4/ip_forward

Et pour que ce soit ... durable

mettez à 1 le paramètre net.ipv4.ip_forward du fichier /etc/sysctl.conf

L'image minimale

Bien maintenant que tout nos services sont Ok, on va pouvoir créer notre image minimale ainsi que le système de fichier, qui sera utiliser par notre client léger.

Pour accomplir cette tâche nous allons utiliser la commande

ltsp-build-client --arch i386 --chroot classique
  • --arch permet de spécifier une architecture pour notre client ( attention à ne pas l'oublier si votre serveur tourne avec une debian 64Bits et votre client en 32, par défaut l'architecture du serveur sera utilisé, tout comme la version du noyau linux à charger )
  • --chroot permet de nommer notre environnement minimaliste, par défaut le nom de l'architecture est utilisé "i386" ( vous noterez qu'il est possible d'utiliser plusieurs images différentes, avec des noms différents pour tel ou tel client léger )

Je vous laisse le loisir de parcourir la page de man de la commande pour le reste des paramètres, qui permettent par exemple de charger un noyau linux de la branche unstable, ou testing ou autre ... bref mettre la version de vôtre choix ( par défaut elle est identique à celle du serveur , squeeze dans mon cas ).

Une fois terminé, nous allons mettre à jour les clefs SSH entre notre serveur et l'environnement fraichement créé ( utilisé pour la liaison réseau client - serveur )

ltsp-update-sshkeys

DHCP

Et oui je ne vous ai pas encore parlé de cette partie essentiel au bon fonctionnement .

Comme nous l'avons vu, un client léger commence par chercher un serveur DHCP sur le réseau pour passer à la suite.

Dans mon exemple, le serveur LTSP possède l'adresse 10.0.0.221, et le serveur DHCP 10.0.0.8

Afin de structurer la configuration au niveau du DHCP, nous allons créer un fichier spécifique pour les clients léger , puis le déclarer dans le fichier de configuration principale du serveur DHCP

Commençons par créer ce fameux fichier

touch /etc/ltsp/dhcpd.conf

Puis on le déclare dans notre configuration principale du DHCP

vim /etc/dhcp3/dhcpd.conf

Et on y ajoute à la fin :

include "/etc/ltsp/dhcpd.conf";

Bien, revenons au contenu du fichier /etc/ltsp/dhcpd.conf

Nous allons créer un groupe afin de pouvoir déclarer des paramètres pour l’ensemble des clients, voici un exemple que vous pouvez utiliser en adaptant les ip et adresses MAC:

group {
#Système de fichier à monter
option root-path "/opt/ltsp/classique";
#Adresse du serveur LTSP
next-server     10.0.0.221;
#Fichier image à charger
if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
filename "/ltsp/classique/pxelinux.0";
} else {
filename "/ltsp/classique/nbi.img";
}
#Client leger Dell
host pxeDell {
hardware ethernet 00:14:0b:80:e5:1a;
fixed-address   10.0.0.101;
}
#Client leger HP
host pxeHP {
hardware ethernet 00:16:17:5e:57:ec;
fixed-address   10.0.0.102;
}
#Client de test
host pxeTest {
hardware ethernet 00:14:67:e5:57:ab;
fixed-address   10.0.0.103;
filename "/ltsp/unstable/pxelinux.0";
option root-path "/opt/ltsp/unstable";
}
}

Dans ce groupe nous commençons par spécifier le système de fichier par défaut à monter, l'image à charger et l'adresse du serveur LTSP , vient ensuite la déclaration des clients PXE, identifié par un nom , une ip et une adresse MAC.

Il est possible de spécifier une autre image ou un autre système de fichier à monter pour un poste particulier, ex : host unstable qui chargera l'image nommée unstable ( souvenez-vous , l'option --chroot de la commande ltsp-build-client )

Nous n'avons plus qu'à redémarrer notre serveur DHCP, et tester avec un des client léger paramétré ci-dessus.

invoke-rc.d dhcp3-server restart

Premier Test

Il suffit d'appuyer sur le bouton "power" et normalement .... vous devriez découvrir ceci

N'hésitez à poster vos commentaires sur le sujet, nous verrons dans le prochain article, comment monter une clef usb ou un CD à partir du client léger, ou encore y faire passer le son, nous verrons aussi comment configurer les client PXE de façon globale ou pour un client unique.

Bref ... vous n'avez pas fini avec ce sujet :) restez à l'écoute .

Ch.

- page 1 de 4