Projet de robotique

Un peu de changement par rapport aux articles précédents, ce n’est pas un tutoriel mais la présentation d’une équipe des écoles UPMC & INSTA  qui développe un robot pour la coupe de France de robotique 2016 !

Cette année les robots vont à la plage ! Voici un descriptif des actions à mener pendant les épreuves :

Les objectifs

Côté technique, le robot est en format 4 roues motrices, équipé de divers capteurs (télémètre à ultrasons, accéléromètre, gyroscope, …) et pour gérer le tout, il dispose d’une carte Nucleo­F401RE. Pour les curieux, c’est un processeur de type ARM mais loin des puissances apportées par les Raspberry Pi. Ici le processeur dispose d’une fréquence de 84 MHz et de 512 KB de mémoire flash. Un vrai challenge pour l’équipe !

NUCLEO-F401RE

Et voici le prototype de l’engin en 3D :

Robot

N’hésitez pas à suivre le projet sur leur site internet :

http://robotique.insta.fr/2016/

Rendez-vous les 5,6 et 7 mai pour les épreuves !

Let’s Encrypt sous Debian – Apache

Parlons rapidement de Let’s Encrypt avant de passer à l’action.

149e86cd7f135095e9c92f4e67a4b6a7b80a60c0

Let’s Encrypt est une autorité de certification qui a pour but de proposer des certificats SSL, ou plutôt TLS pour ne pas faire d’abus de langage totalement gratuit. C’est un projet rassemblant des acteurs importants dans le monde du web comme Gandi, OVH, Mozilla, Cisco, Facebook, etc … ( https://letsencrypt.org/sponsors/ )

La volonté première est de rendre l’httpS accessible à tous et de la manière la plus simple possible, avec une installation quasi automatique des certificats sur le serveur.

Sorti tout récemment de la phase de beta-test depuis le 3 décembre, le service est ouvert à tous et le code du client est disponible sur GitHub à cette adresse :

https://github.com/letsencrypt/letsencrypt

lets

1- Installations du client Let’s Encrypt

Cet article décrit la procédure d’installation et de configuration sur une Debian 8.2 à jour.

Continuer la lecture de Let’s Encrypt sous Debian – Apache

Reverse proxy avec Apache

Après Nginx voici un autre exemple de reverse proxy, cette fois-ci nous utiliserons Apache avec Redmine.

Si vous utilisez un serveur avec Redmine, voici l’url d’accès à l’application :

http://redmine.myserver.com:3000

De même que pour l’exemple de Kibana, cette URL n’est ni pratique ni jolie, ni même utilisable à travers certains réseaux qui limitent l’utilisation de certains port. Cela donne un avantage de plus quand à l’utilisation d’un reverse proxy.

Nous commençons par installer apache :

httpd_logo_wide_new

Sous Gentoo (en ayant ajouter les variables USE proxy et proxy_http :

# emerge -avq apache

Sous Debian :

# apt-get install apache2

Nous configurons ensuite le vhost correspondant à Redmine et dans le bloc <VirtualHost *:80> nous ajoutons ces lignes :

ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/

ProxyPass permet d’indiquer que nous relayons les requêtes envoyées sur la racine vers notre Redmine sur le port 3000.

ProxyPassReverse permet de retransmettre les informations entre les deux parties.Voilà, votre Redmine est joignable directement sur une URL sur le port 80 :

http://redmine.myserver.com

Reverse proxy avec Nginx

Tout d’abord, voici une petite explication de l’utilité de mettre en place un reverse proxy. Nous allons prendre ici l’exemple d’un serveur disposant du groupe ELK (Elasticsearch  Logstash Kibana) avec l’interface web de Kibana qui écoute par défaut sur le port 5601. Pour y accéder vous devez passer par cette URL :

http://myelk.myserver.com:5601/

Cela oblige à ouvrir le port vers l’extérieur et ce n’est pas très joli à écrire.

Voici comment utiliser Nginx comme reverse proxy pour obtenir une url sans port à spécifier et même permettre de mettre en place une authentification simple par .htaccess.

nginx

Tout d’abord, installer Nginx ( http://nginx.org/ ) sous Debian :

# apt-get install nginx

Allons ensuite configurer le reverse proxy dans le fichier de base d’un nginx fraichement installé :

# vim /etc/nginx/sites-available/default

Voici le bloc à modifier dans ce vhost :

location / {
                proxy_pass http://localhost:5601;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection 'upgrade';
                proxy_set_header Host $host;
                proxy_cache_bypass $http_upgrade;
 }

Petite explication de ces lignes :

Nous indiquons à proxy_pass l’url vers laquelle on souhaite envoyer les requêtes, soit Kibana pour notre exemple. proxy_http_version indique la version du protocole HTTP à utiliser et les proxy_set_header permettent de faire suivres des informations dans les en-têtes.

Petit plus, vous pouvez ajouter un .htaccess via ces deux lignes à placer avant location / :

auth_basic "Access restreint";
auth_basic_user_file /etc/nginx/htpasswd;

Et sans oublier d’inscrire des utilisateurs dans ce fichier (la commande htpasswd est obtenu grace au paquet apache2-utils ):

htpasswd -c /etc/nginx/htpasswd my-user

Déploiement d’applications Windows via RemoteApp (Windows Server 2012 R2)

Voici un article le déploiement d’application via Microsoft RemoteApp. Nous allons aller de l’installation à la mise à disposition d’applications en passant par les différentes étapes de configurations.

941270_0__8569312

Techniquement, nous allons tout installer sur un seul et même serveur virtualisé sous Proxmox.

Continuer la lecture de Déploiement d’applications Windows via RemoteApp (Windows Server 2012 R2)

Récupérer licence Windows 8/8.1 OEM

Lorsque vous avez acheter votre PC, vous avez en général une licence Windows fournie avec. Avant Windows 8 la licence se trouvait sur une étiquette présente sur le boîtier de celui-ci. Depuis Windows 8, et pour simplifier la vie des utilisateurs, la licence se trouve intégrée dans le BIOS/UEFI et n’est pas accessible depuis son interface.

Si vous avez formaté le disque dur de votre machine pour y installer Linux uniquement, vous n’avez plus la possibilité d’utilisé les différents logiciels de récupérations de clefs disponibles sous Windows. Il y a cependant une petite astuce pour récupérer cette licence et la réutilisée sur une machine virtuelle par exemple.

Dans votre terminal en ROOT :

# strings /sys/firmware/acpi/tables/MSDM

Vous récupérez alors la licence sous ce format :

MSDMU
HPXXXX-CPX	 
AMI 
NWZ27-42VV2-XXXX-XXXX-XXXX

Indiquez cette licence dans l’installation de Windows 8 et vous ne serez pas obligé d’en racheter une.

windows8.1-serial2

Cluster Proxmox chez Online.net (dedibox)

——————–

Nouvelle article avec la version 4 de proxmox et le RPN :

https://blog.waccabac.com/cluster-proxmox-4-chez-online-net-dedibox-avec-le-reseau-rpn/

——————–

Cet article va vous décrire les différentes étapes pour créer un cluster sous Proxmox avec des serveurs dédiés chez Online.net. Il faut savoir que le cluster est créé par défaut pour communiquer en multicast, protocole qui est bloqué chez la plupart des hébergeurs tels qu’Online ou OVH. Nous allons utiliser une alternative en choisissant l’unicast.

Pour faire notre cluster Proxmox, nous allons utiliser 3 serveurs de chez Online, qui ont pour chacun la configuration suivante :

server-poweredge-r410-overview1

– Dell R410
– Processeur : 2x Intel® Xeon® E5620
– Mémoire : 64Go DDR3 ECC
– Disques : 2x2To SAS

Continuer la lecture de Cluster Proxmox chez Online.net (dedibox)

Etre informé des mises à jour Debian

Pour être informé automatiquement des mises à jour des paquets de vos serveurs Debian par email, il vous suffit d’installer le paquet apticron.

# apt-get install apticron

Ensuite on le configure en éditant son fichier :

# vim /etc/apticron/apticron.conf

On va régler l’adresse email sur laquelle nous recevrons les notifications, l’objet du mail, et la provenance.

EMAIL="admin@domain.com"
CUSTOM_SUBJECT="[apticron] $SYSTEM: $NUM_PACKAGES package update(s)
CUSTOM_FROM="backup@domain.com"

La vérification s’effectue tous les jours et un email vous sera envoyé si une mise à jour est disponible.

https://packages.debian.org/wheezy/apticron

Graphs MRTG sous Gentoo

mrtg_logo

MRTG est un logiciel qui permet de générer des graphiques de la bande passante du réseau. D’autres systèmes plus poussés existent mais nous les verrons plus tard.

Prérequis : il faut disposer du service SNMP. La configuration de base fonctionne sans y toucher.

emerge -avq net-analyzer/net-snmp
mv /etc/snmp/snmpd.conf.example /etc/snmp/snmpd.conf
/etc/init.d/snmpd start

Passons maintenant à MRTG et commençons par installer le paquet :

emerge -avq net-analyzer/mrtg

Il faut ensuite créer le dossier de destination des graphiques (à configurer selon vos besoins).

mkdir /var/www/localhost/htdocs/mrtg/

Nous devons ensuite créer le fichier de configuration dont mrtg a besoin grâce à la commande « cfgmaker »:

cfgmaker --global 'WorkDir: /var/www/localhost/htdocs/mrtg/' --global 'Options[_]: bits,growright' --output /etc/mrtg.conf public@localhost

Puis lançons le service :

/etc/init.d/mrtg start

A ce stade, le service MRTG est démarré et va actualiser les données toutes les 5 minutes. Vous pouvez dès à présent voir les graphiques générés en allant dans le dossier « /var/www/localhost/htdocs/mrtg/ » et en affichant les fichiers HTML.

Voici un exemple d’un graphique seul :

graph

C’est terminé !

Laissez passer quelques dizaines de minutes et le graphique va se remplir.

 

Configuration OpenSSH (6.4)

OpenSSH est un logiciel qui permet d’utiliser le protocole SSH pour l’accès à distance sur des machines Linux et le transfert de fichiers de manière sécurisé.

Site officiel du projet : http://www.openbsd.org/openssh/fr/index.html

Voici la configuration détaillée d’un serveur ssh réalisé à l’aide d’OpenSSH (ici en version 6.4)  qui se trouve dans le fichier /etc/ssh/sshd_config

Port 22
Protocol 2
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 2m
PermitRootLogin no
StrictModes yes
AllowUsers john
PermitEmptyPasswords no
UsePAM yes
X11Forwarding no
PrintLastLog yes
UsePrivilegeSeparation sandbox

Les directives Port et Protocol sont optionnelles puisque ces valeurs sont celles présentes par défaut.

SyslogFacility et LogLevel permet d’activer les logs d’OpenSSH de façon suffisante pour pouvoir les traiter avec Fail2ban par exemple.

LoginGraceTime indique le temps maximum pour s’identifier avant que la connexion soit coupée.  Ici 2 minutes.

PermitRootLogin interdit ici la connexion directe de l’utilisateur root. Même avec le bon mot de passe, vous ne pourrez pas vous connecter en root directement. Il convient d’utiliser un simple utilisateur pour se connecter en ssh puis de passer root ensuite. L’utilisateur doit faire partie du groupe wheel.

# gpasswd -a john wheel

StrictModes permet de vérifier les autorisations des utilisateurs.

AllowUsers indique les utilisateurs ayant le droit de se connecter. Cette directive est à associer à PermitRootLogin. Au final, root ne peut jamais se connecter et seul john le peut même si d’autres utilisateurs sont présents sur la machine.

PermitEmptyPasswords interdit la connexion avec un mot de passe nul.

UsePAM utilise PAM pour vérifier les utilisateurs.

X11Forwarding interdit l’affichage à distance d’un environnement graphique.

PrintLastLog affiche la date, l’heure et l’ip de la dernière connexion juste après la connexion.

UsePrivilegeSeparation permet d’isoler via un processus fils la connexion d’un utilisateur avant de créer un nouveau processus avec les droits de cet utilisateur lorsque celui-ci est bien authentifié.

Vous trouverez sur le site officiel toutes les directives : http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config

N’hésitez pas à commenter !