Archives pour la catégorie hebergement

RunAbove / DigitalOcean : nouveau comparatif des performances

Publié le par
1

Logos RunAbove et DigitalOcean

Il y'a quelques mois je vous présentais un comparatif des performances offertes par deux fournisseurs de VPS : RunAbove (assez fraichement lancé lors du premier test) et DigitalOcean. J'ai décidé de renouveler ce comparatif afin de voir  comment ont évolué ces deux hébergeurs (en sélectionnant cette fois ci les offres les moins coûteuses de chaque prestataire).

J'ai également modifié mon protocole de test en particulier pour Fio (qui me permet de mesurer l'efficacité des accès disques). Désormais je lance trois tests successifs permettant de mesurer :

  • la bande passante et le nombre d'IO par seconde sur des accès aléatoires en mixant écriture et lecture (ratio de 50% écriture / 50% lecture) - "randRW" dans le tableau de résultats
  • la bande passante et le nombre d'IO par seconde sur des accès aléatoires uniquement en lecture - "randRead"
  • la bande passante et le nombre d'IO par seconde sur des accès aléatoires uniquement en écriture - "randWrite"

Ces trois tests Fio sont réalisés sur un fichier de 1Go et par blocs de 16Ko. Les fichiers de tests sont systématiquement régénérés avant chaque test.

Le test de débit est, quand à lui, réalisé en lançant, à trois reprises, speedtest_cli.py à destination du serveur de test de Neo Telecoms (localisé en France). Une moyenne est ensuite calculée pour l'upload et le download. J'ai choisi Neo Telecoms pour ne pas avantager l'un des deux hébergeurs testés.

Le test de performance "processeur" est toujours réalisé à l'aide de UnixBench

Enfin, les VPS ont été commandés (et utilisés) uniquement pour les tests. Nous sommes donc sur la base d'une machine standard telle qu'elle est livrée, par défaut, par ces deux prestataires.

Les VPS utilisés pour ces tests présentent les caractéristiques suivantes :

RunAbove (Offre "CloudSandBox" / Offre "M")

  • Ram : 2Go
  • Processeur : 1 Core
  • Disque : 20Go SSD
  • OS : Linux Debian 7 (installation "neuve")
  • Datacenter : OVH / Strasbourg
  • Prix mensuel : 2,5$

DigitalOcean (Offre "premier niveau")

  • Ram : 512Mo
  • Processeur : 1 Core
  • Disque : 20Go SSD
  • OS : Linux Debian 7 (installation "neuve")
  • Datacenter : DigitalOcean / Londres
  • Prix mensuel : 5$

Les résultats (cliquez pour une image plus nette)

Pour tous les tests : plus la valeur est élevée meilleur est la performance

Tebleau comparatif des performances entre DigitalOcean et RunAbove

L'analyse des résultats montrent des performances assez proches entre les deux hébergeurs. RunAbove a réellement fait un bon boulot au niveau de l'optimisation des accès disques (le point faible lors du dernier test). Si j'ai bien compris, cette amélioration est probablement due à l'adoption de disques SSD locaux (au moins pour les offres "SandBox" & "1VM/HOST"). Au final RunAbove remporte la partie en étant gagnant pour 9 critères sur 11 au total et tout ça pour un coût inférieur de 50%.

Quelques points complémentaires pour modérer (un peu) cette analyse :

  • l'offre RunAbove semble être une sorte de Beta (on parle des "Labs"). J'espère que cette offre sera pérenne (si des membres de l'équipe de RunAbove passent par ici qu'ils n'hésitent pas à nous en dire un peu plus ...)
  • j'aime beaucoup l'interface d'administration de RunAbove qui pour moi est une vraie réussite (simple, complète et efficace ...). Il manque toutefois une fonction INDISPENSABLE qui est la génération automatique (et à chaud)  des backups sous la forme de snapshots. Certes il est actuellement possible de créer des Snapshot mais manuellement, à la demande et en stoppant la VM. J'espère que cette fonction sera bientôt proposée ...
  • Les offres DigitalOcean sont disponibles ICI
  • Les offres RunAbove sont disponibles ICI

Yubikey : sécurisez vos accès SSH (sous Debian) avec une double authentification [HowTo]

Publié le par
6

Yubikey

C'est désormais une certitude, les simples mots de passe ne sont plus suffisants pour assurer l'accès à des services critiques. En ce qui me concerne j'utilise, dès que cette option existe, le système de double authentification ("authentification à facteurs multiples"). Le principe est d'associer un mot de passe classique avec un deuxième identifiant à usage unique. Beaucoup utilisent Google Authenticator, ou bien la réception d'un SMS pour obtenir cette information.

Il existe une solution un peu moins connue mais particulièrement intéressante :  Yubikey. Il s'agit d'une petite clé usb (cf. la photo d'illustration de ce billet) particulièrement robuste, légère et ne nécessitant pas de pile. Il suffit de l’insérer dans un port USB et d'appuyer sur le bouton central. La Yubikey se comporte alors comme un clavier (pas besoin de driver spécifique) et génère automatiquement le code à usage unique. Cette clé est vendue sur le net à un tarif abordable (environ 23€ sur Amazon). Certaines sociétés (comme OVH,  par exemple) ont adopté massivement ce dispositif afin de sécuriser l'accès à leur système d'information.

J'utilise une Yubikey depuis quelques mois et je dois reconnaître que cette dernière est particulièrement pratique (pour sécuriser l'accès à mon compte LastPass par exemple). J'ai également commencé à sécuriser l'accès SSH de certains de mes serveurs avec ce dispositif et j'ai décidé de créer ce how-to pour aider ceux qui souhaiteraient faire de même.

Comme d'habitude, ce tuto est basé sur Debian 7, mais il devrait être assez facilement utilisable avec d'autres distributions.

Avertissement important : durant toutes ces opérations ne redémarrez pas le service SSH (ni votre serveur), vous risqueriez de ne plus pouvoir vous connecter ! Une fois la configuration achevée (et le service SSH relancé) conservez votre session SSH ouverte et testez en lançant une nouvelle connexion en parallèle : si les choses tournent mal (connexion impossible) vous conserverez ainsi un accès 🙂

La première opération à réaliser est d'installer la librairie PAM pour Yubico/Ybikey

apt-get install libpam-yubico

Il faut ensuite créer le fichier qui va contenir la liste des Yubikey habilitées à se connecter avec un compte utilisateur donné

mkdir ~/.yubico
vim ~/.yubico/authorized_yubikeys

Pour mémoire le "~" représente le home directory de l'utilisateur actuellement connecté. Si vous êtes connecté en root, le fichier sera donc créé dans "/root/.yubic/authorized_yubikeys"

et d'y placer la liste des Yubikey autorisées à se connecter de la façon suivante

username:token_ID

Le username correspond à votre login Unix (root par exemple) et le token_ID peut être récupéré à cette adresse.

Rendez-vous sur cette page, insérez votre Yubikey sur un port USB, sélectionnez "OTP" (1) dans "source format" et générez une clé en appuyant sur le bouton de votre clé (2).

yubi_screen1

Vous obtiendrez en retour une "input string" composé de 12 caractères et commençant par 6 fois la lettre "c". De la forme "ccccccabcdef". Cette chaine est votre "token_ID". Ajuster le fichier "authorized_yubikeys" avec cette valeur. On obtient donc quelque chose comme "root:ccccccabcdef".

yubi_screen2

Si vous devez donner l'accès à plusieurs Yubikey pour le même login vous pouvez accumuler les Token_ID avec quelque chose du type "root:token_yubikey1:token_yubikey2..."

On édite ensuite le fichier

/etc/pam.d/sshd

Ajoutez la ligne suivante après "@include common-auth"

auth required pam_yubico.so id=16

Si vous préférez devoir générer votre code à usage unique avant d'avoir à mentionner votre mot de passe placez cette ligne avant "@include common-auth" (à vous de décider ce que vous souhaitez faire).

Éditez ensuite le fichier

/etc/ssh/sshd_config

Afin de modifier la directive suivante

ChallengeResponseAuthentication yes

Redémarrez SSH

/etc/init.d/ssh restart

Essayez d'ouvrir une nouvelle session (conservez la session en cours active - on ne sait jamais ...). Vous devriez obtenir ça

yubi_screen3

 

  • Commander une Yubikey sur Amazon : ICI
  • Plus d'information sur Yubikey : ICI

 

 

Monitority : recevez gratuitement une alerte SMS lorsque votre site est down !

Publié le par
Répondre

monitorityIl existe une multitude de services proposant de superviser vos sites web. Ceux qui vous permettent de monitorer un nombre illimité d'URL (avec une fréquence rapide) et de vous alerter gratuitement par SMS sont par contre beaucoup plus rares ...

C'est justement ce que propose Monitority, un service qui vient de voir le jour. Parmi les fonctionnalités proposées :

  • tests possibles :  HTTP, HTTPS & FTP (avec recherche d'une chaine de caractères au sein de la page)
  • nombre de sites testés : illimité
  • tests réalisés à partir de plusieurs localisations dans le monde (ces emplacements ne sont toutefois pas précisés)
  • alertes gratuites par SMS, email et Twitter
  • système "anti-flood de notification" en cas d'alerte
  • intervalle entre les tests : < 1 minute
  • interface simple et ergonomique (10s suffisent à paramétrer un nouveau test)

Bref ce système semble être parfait. J'ai toutefois un doute sur le modèle économique. Certes les créateurs de Monitority donnent quelques informations à ce sujet (voir ci-dessous) mais j'ai quand même un peu de mal à comprendre leurs motivations et on peut légitimement se poser quelques questions sur la viabilité à long terme de la solution.

The question we hear most: How is it free?
We have a network of servers worldwide running various services (not related to Monitority) that we are able to harness, keeping our actual monitoring cost very low. Email is close to zero, so we are only left with SMS as a big expense. SMS prices are also on the decline especially when you ramp up volume.
We strongly feel that this niche industry is about to change - we plan to be in the forefront of this disruption.

En attendant, pourquoi ne pas profiter de la gratuité du système tout en sachant que les informations que vous fournissez à Monitority restent limitées.

Monit : la supervision en toute simplicité

Publié le par
Répondre

monitoringSi vous gérez des serveurs, vous avez déjà certainement été confronté à la mise en place d'un système de supervision. Les solutions techniques ne manquent pas (Nagios, Zabbix ...) mais la plupart restent assez lourdes à mettre en œuvre et on tombe vite dans l'usine à gaz !

Si vos besoins sont simples (monitoring de l'espace disque, de la charge mémoire/processeur, requêtes simples sur un serveur distant, surveillance d'un processus local ...) je vous conseille de jeter un coup d’œil du côté de Monit. Cette solution m'a séduit par sa simplicité et sa rapidité de mise en œuvre : un petit "apt-get install" (sous Debian ou Ubuntu / le paquet est disponible dans les dépôts officiels) et un seul et unique fichier de conf. On peut difficilement faire plus simple !

Un bémol toutefois : cette solution n'est pas capable d'aller interroger un agent localisé sur un serveur distant (comme on peut le faire avec Nagios par exemple). Il est toutefois possible de superviser le fonctionnement d'une machine distante au travers de requêtes standards (ping, http, smtp ...)

Concernant l'installation et le paramétrage c'est assez simple (pour Debian / Ubuntu) :

apt-get install monit

Editez ensuite le fichier de configuration : /etc/monit/monitrc (au passage je vous conseille de faire une copie du fichier original : cp /etc/monit/monitrc /etc/monit/monitrc.original )

* vers la ligne 19 : la directive "set daemon" permet de définir l'intervalle entre deux tests (en secondes). On peut aussi retarder l'exécution du premier test avec "start delay" pour être sûr que le serveur ait bien fini de booter

* vers la ligne 52 : on définie "set mailserver" le serveur smtp à utiliser pour transmettre les alertes (il est possible d'en spécifier plusieurs en les séparant par une virgule)

* vers la ligne 84 : la directive "set mail-format" vous permet de modifier la structure et le contenu des emails d'alerte

* vers la ligne 109 : on mentionne l'adresse du contact qui recevra les alertes ( "set alert" ). De nombreuses options sont disponibles dans cette rubrique pour limiter l'envoi de certaines alertes à des contacts spécifiques par exemple. Consultez la doc pour en savoir plus

Vous trouverez ensuite quelques configurations types de tests pouvant être réalisés par Monit.

A titre trois exemples (très simples) que j'utilise personnellement :

* Pour tester l'espace disque disponible (envoi d'une alerte si l'espace disque occupé dépasse 90%)

check filesystem rootfs with path /dev/sda1
    if space usage > 90% then alert

* Pour tester un hôte distant et envoyer une alerte si ce dernier ne répond plus au ping et/ou ne répond plus à une requête smtp sur le port 25

check host mail.votre_serveur.com with address mail.votre_serveur.com
    if failed icmp type echo count 3 with timeout 2 seconds then alert
    if failed port 25 protocol smtp with timeout 10 seconds then alert

* Pour tester la présence du process "Apache", lancer une requête http sur le port 80 du serveur et alerter en cas d'échec

check process apache with pidfile /var/run/apache2.pid
    if failed
    host www.votre_serveur.com port 80 protocol http
    then alert

Les possibilités offertes par Monit sont très vastes (il est possible par exemple de relancer automatiquement un service en cas de dysfonctionnement ...). Je vous invite à consulter la doc qui est particulièrement bien détaillée (ICI).

A noter que Monit propose également un serveur web embarqué vous permettant de visualiser les équipements supervisés (et de gérer les services) à partir d'un simple navigateur. Vous pouvez activer et paramétrer cette fonctionnalité au sein du fichier de configuration "monitrc" (vers la ligne 118). Là encore le nombre d'options est important (authentification, gestion des droits ...) il est donc impératif de consulter la documentation pour en savoir plus.

  • Site officiel de Monit : http://mmonit.com/monit/

  • Lien direct vers la documentation : ICI

  • Si le sujet de la supervision vous intéresse voici un site assez complet présentant les différentes solutions disponibles : ICI

 

RunAbove // Digital Ocean : le Match !

Publié le par
6

Logo DO RunAbove

La semaine dernière j'ai assisté à l'édition lyonnaise de l'OVH World Tour (félicitations au passage pour la qualité de l'organisation). Parmi les produits proposés par OVH, il a été présenté RunAbove la nouvelle offre de machines virtuelles à "hautes performances".

Curieux j'ai décidé d'entreprendre quelques tests (sur la lignée de mon précédent billet ) pour vérifier si effectivement les performances sont bien au rendez-vous ...

Suite à l'OVH World Tour, j'ai reçu un code permettant de tester une VM RunAbove gratuitement pour quelques jours. J'en ai donc profité pour mettre en œuvre rapidement une machine de test.

Pour réaliser ce comparatif j'ai décidé de m'appuyer sur une méthodologie similaire à ce que j'ai réalisé il y a quelques jours pour le test "Linode / DigitalOcean / Amazon".

J'ai également décidé de prendre comme base de comparaison le "vainqueur" de mon précédent test : DigitalOcean.

Caractéristiques des instances utilisées :

RunAbove OVH

  • instance de type "Compute Optimized"
  • 16 Go ram
  • 6 cœurs
  • 240 Go SSD
  • connexion réseau : 10Gbs
  • OS : Ubuntu 14.04 - 64bits
  • datacenter : Canada / Beauharnois (BHS)
  • coût 160 $ / mois (ou 0,24$ / heure) + bande passante sortante : 0,01$ / Go (soit 10$ / To)

Digital Ocean

  • 16 Go ram
  • 8 cœurs
  • 160Go SSD
  • OS : Ubuntu 14.04 - 64bits
  • datacenter : US / New York
  • coût : 160$ / mois (ou 0,24$ / heure) + 6To de bande passante sortante intégrés dans le prix

Les résultats sont les suivants :

Test RunAbove DigitalOcean
HD test1 (bande passante) 20,71 Mo/s 62,42 Mo/s
HD test2 (iops) 5 178 iops 15 700 iops
HD Hdparm (sans cache) 296,34 Mo/s 701,87 Mo/s
CPU (durée du calcul) 8,79 s 12,6 s
MEM (durée du test) 4,16 s 7,06 s
MEM (bande passante) 12 278 Mo/s 7 246 Mo/s
score "Byte Unix" (1 proc) 1 262,7 689,6
Score "Byte Unix" (tous les procs.) 3 942,8 2 324,1
Speedtest Download (cible OVH/FR) 100,56 Mbit/s 39,91 Mbit/s
Speedtest Upload (cible OVH/FR) 24,14 Mbit/s 25,29 Mbit/s
Speedtest Download (auto. proche)* 934,69 Mbit/s 858,67 Mbit/s
Speedtest Upload (auto. proche)* 716,80 Mbit/s 209,57 Mbit/s

* : contrairement aux précédents tests j'ai ajouté un SpeedTest en mode automatique (avec localisation du serveur le plus proche) afin de ne pas pénaliser DigitalOcean.

On constate rapidement que les performances sont bien au rendez-vous avec l'offre RunAbove. En particulier pour ce qui concerne le processeur et la mémoire où les résultats sont impressionnants.

DigitalOcean prend toutefois le dessus sur les accès disque (et ce même si les deux hébergeurs ont opté pour des disques SSD). Visiblement le savoir-faire de DigitalOcean en la matière est meilleur.

La connexion à l'internet est bonne dans les deux cas même si j’espérai obtenir de meilleurs résultats avec la VM RunAbove et un SpeedTest à destination des serveurs d'OVH à Roubaix.

A signaler également que l'offre RunAbove n'intègre pas de bande passante sortante : il faudra donc intégrer ce coût supplémentaire (0.01$ / Go).

  • les offres RunAbove sont disponibles ICI
  • les offres DigitalOcean sont disponibles ICI

Amazon AWS EC2, DigitalOcean & Linode : test comparatif des performances

Publié le par
1

Virtual Server

Aujourd'hui, lorsqu'on souhaite héberger une application web un peu conséquente le recours à un (ou plusieurs) serveurs dédiés n'est plus la seule solution. On s'oriente de plus en plus souvent vers un système virtualisé offrant beaucoup plus de souplesse et d’options en matière d'administration. Je suis pour ma part entièrement convaincu par ce type d'offres et je ne vois plus beaucoup d’intérêt à opter pour un "vrai" serveur dédié ...

On trouve de nombreux acteurs sur ce marché, mais j'ai décidé de me concentrer sur 3 fournisseurs de serveurs privés virtuels particulièrement bien implantés sur ce secteur : Amazon avec son offre "Elastic Cloud Computing / EC2", Linode et DigitalOcean.

Comparer leurs offres n'est pas simple. En effet certains fournisseurs comme Amazon propose une multitude de configurations différentes ...

J'ai donc arbitrairement décidé de me mettre à la place d'un bloggeur souhaitant héberger son site avec un budget mensuel aux alentours de 20$. J'ai mis en place une méthodologie de test (certainement perfectible) permettant de comparer les points suivants : les performances des accès disques, des processeurs, de la mémoire ainsi que de la connectivité réseau.

Les outils utilisés sont les suivants :

  • "fio" : pour le premier test d'accès disques. Le test est basé sur une lecture aléatoire
  • "hdparm" : pour le deuxième test d'accès disques (test réalisé sans cache)
  • "sysbench" : pour le test du processeur et de la mémoire
  • "byte-unixbench" : pour obtenir un score de performance global
  • "Speedtest_Cli" : pour le test de débit (raccordement à l'Internet - les tests sont effectués en sélectionnant les serveurs d'OVH à Roubaix comme cible)

Afin de réaliser ces tests, j'ai commandé (le dimanche 13/4/2014) 3 serveurs virtuels auprès des différents fournisseurs. Ces serveurs étaient tous équipés d'une distribution "Ubuntu 13.10 - 64bits" et localisés en Europe (Irelande pour Amazon, Amsterdam pour DigitalOcean et Londres pour Linode). Les tests réalisés sont rigoureusement identiques sur les 3 VPS.

Les résultats des tests sont les suivants :

Test Amazon EC2 DigitalOcean Linode
HD test1 (bande passante) 9,56Mo/s 48,31Mo/s 13,21Mo/s
HD test2 (iops) 2 391 iops 12 800 iops 3 301 iops
HD Hdparm (sans cache) 9,76Mo/s 379,81Mo/s 223,68Mo/s
CPU (durée du calcul) 18,47s 14,45s 11,91s
MEM (durée du test) 9,30s 7,52s 12,53s
MEM (bande passante) 5 504Mo/s 6 807Mo/s 4 085Mo/s
score "Byte Unix" (1 proc) 235,7 1 167,7 522,2
Score "Byte Unix" (tous les procs.) 235,7 1 939,5 1 563.3
Speedtest Download 87,28Mbit/s 785.05Mbit/s 691,19Mbit/s
Speedtest Upload 106,12Mbit/s 104,59Mbut/s 160,22Mbit/s

Les caractéristiques (en date du 13/4/2014) des différentes offres souscrites pour ces tests sont les suivantes :

  • Amazon AWS EC2
    • instance de type "t1.micro" (à la demande)
    • abonnement mensuel : 22,05$
    • ram : 615Mo
    • disque : 30Go (EBS)
    • bande passante par mois : 51 Go
    • Mode de calcul du prix mensuel :
      • instance : 14,40$ / mois
      • disque EBS : 30Go x 0.055$ / mois = 1,65$ / mois
      • bande passante : 50Go x 0,120$ / mois = 6 $ / mois
  • DigitalOcean (premier pour 8 critères)
    • offre : "2Go"
    • abonnement mensuel : 20$
    • ram : 2Go
    • disque : 40Go
    • bande passante par mois : 3 To
  • Linode (premier pour 2 critères)
    • offre "Linode 1GB"
    • abonnement mensuel : 20$
    • ram : 1Go
    • disque : 48Go
    • bande passante par mois : 2To

C'est donc l'offre de DigitalOcean (premier pour 8 critères) qui présente les meilleures caractéristiques (pour un budget mensuel d'environ 20$). Le fait d'utiliser, en standard, des disques SSD lui donne un avantage certain sur ses concurrents (12 800 iops en lecture !). L'offre de Linode (premier pour 2 critères) est en deuxième position suivi par Amazon.

A signaler également le coût relativement important de la bande passante pour l'offre d'Amazon. En effet seul 1Go est intégré au coût mensuel de l'instance et le Go supplémentaire est facturé 0,12$ (pour une consommation inférieure à 1To / mois - une dégressivité est ensuite appliquée - attention quand même car 1To = 1000Go = 1000 x 0,12$ = 120$ / mois ...).

Il ne faut pas interpréter ce test trop négativement pour Amazon. En effet comme je l'ai précisé au début de ce billet le scénario retenu ici pour comparer les offres est spécifique (cas d'un bloggeur avec un budget mensuel de 20$ / mois ...). Amazon propose des offres très performantes mais avec un positionnement plus haut de gamme et destinées principalement aux entreprises. A signaler également qu'Amazon propose gratuitement des fonctionnalités spcécifiques et exclusives : load balancer, création automatique et "à la volée" de nouvelle instances en fonction de la charge ... On ne trouve actuellement pas d'équivalent chez les autres prestataires.

Bref, si vous disposez d'un budget de 20$ / mois et que vous souhaitez mettre en place un VPS, c'est probablement vers DigitalOcean que vous devez vous orienter !

Ce type d'offres étant en perpétuelle évolution je pense réaliser régulièrement d'autres tests de ce style en conservant ces 3 prestataires et en y ajoutant éventuellement d'autres fournisseurs.

Linux // Effectuer un reboot d’urgence à distance

Publié le par
7

stopVote serveur est hébergé dans un datacenter à plusieurs centaines de kilomètres. Vous disposez toujours d'un accès SSH mais la machine refuse de rebooter (Init 6, reboot, halt ... rien ne fonctionne...). Bien entendu vous ne disposez pas de module de contrôle de l'alimentation à distance ... C'est une situation que j'ai rencontré il y a peu de temps suite à un problème NFS sur l'un de mes serveurs.

Si vous rencontrez ce type de problème vous pouvez tenter les commandes "de la dernière chance" ;-).

Attention : en appliquant ces commandes vous allez engendrer un reboot direct (un peu comme si vous appuyez sur le bouton "reset" du serveur ...). Autant vous dire tout de suite que ce n'est pas vraiment ce qu'il y a de plus clean : rien ne va être fermé proprement, pas de sync sur les disques bref un vrai reboot à l'arrache (avec toutes les conséquences possibles ...) !

Voici donc les commandes à utiliser :

echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger

Si vous préférez arrêter complétement le serveur (attention quand même si vous êtes à plusieurs centaines de kilomètres c'est peut être pas une très bonne idée  😉 ) :

echo 1 > /proc/sys/kernel/sysrq
echo o > /proc/sysrq-trigger

Ces commandes ont pour effet de simuler l'usage de la combinaison de touche apellée "magic SysRq key". Cette combinaison de touche reconnue par le Kernel permet d’effectuer des opérations d'assez bas niveau sur votre système. Si vous souhaitez en savoir plus vous pouvez consulter cet article Wikipedia .

Comment obtenir gratuitement un certificat SSL

Publié le par
2

padlock

Quand on souhaite sécuriser l'accès à son site web en utilisant SSL il est nécessaire de configurer son serveur HTTP (Apache, Nginx ...) pour que ce dernier utilise un certificat adéquat.

Deux  solutions sont alors envisageables :

  •  générer soit même cet élément (on parle alors de certificat "auto signé") avec comme principal inconvénient de voir apparaître à la connexion sur le site, un message d'alerte du navigateur du type "Attention ce certificat n'est pas valide - vous ne devriez pas faire confiance à ce site" . Pas top pour l'image !
  • acheter un certificat émis par une autorité de certification reconnue par les principaux navigateurs. Là les prix sont très variables ...

Il n'existait (à ma connaissance) jusqu'à maintenant qu'une seule autorité de certification qui proposait des certificats gratuits ( CACert  ) mais malheureusement cette dernière n'est pas reconnue par les navigateurs du marché. Il faut donc que l'utilisateur ait déjà importé la "racine" de CACert pour ne pas voir apparaître le message d'avertissement. Autant dire qu'on se retrouve quasiment dans la même situation qu'avec un certificat "auto-signé" ...

J'ai découvert, un peu par hasard, une autorité de certification ( StartSSL ) qui propose gratuitement des certificats reconnus par la plupart des navigateurs du marché. Il s'agit de certificats "simples" (Classe 1 / "Domain Validated" / simple validation de l'URL) mais suffisant pour assurer le cryptage des données entre le client et le serveur sans avoir à subir le fameux message d'avertissement !

start_ssl_illust

Un bon plan à retrouver ICI ...

Petite précision, l'offre "gratuite" semble être réservée aux particuliers : il n'est pas possible de faire mention d'un nom de société lors de la demande de certificat.

Hébergez (gratuitement) votre Raspberry Pi dans un datacenter

Publié le par
2

rasp_pi2

En bons geeks, nous avons tous besoin d'une petite machine toujours connectée à l'Internet pour diverses tâches : héberger un petit site, un serveur de mail, tester de nouveaux trucs, lancer un traceroute depuis l'extérieur, monitorer, monter un VPN perso ...

La solution habituellement choisie consiste à souscrire un petit VPS (voir un dédié low-cost type OVH Kimsufi). D'autres, préféreront l'auto-hébergement sur la base de leur connexion perso ...

Il existe désormais une alternative. Si vous disposez d'un Raspberry Pi vous pouvez l'héberger (gratuitement) dans un datacenter en bénéficiant ainsi d'un environnement adapté et sécurisé (bande passante optimale, continuité de service, température contrôlée, sécurité physique ...).

C'est à l'hébergeur autrichien EDIS que l'on doit  cette offre de colocation qui intègre : 100Go de trafic mensuel, une bande passante de 100Mbs et bien entendu une IP ! Cet hébergement ne vous coûtera rien : aucun frais de mise en service, pas d'abonnement mensuel. Une seule contribution aux frais de transport de 10€ vous sera demandée lorsque vous souhaiterez récupérer votre matériel !

Si vous êtes intéressé il suffit de vous rendre sur cette page afin de valider votre commande. Vous recevrez ensuite un mail de la part d'EDIS avec les informations nécessaires à l'expédition de votre serveur (ce dernier sera hébergé en Autriche) ainsi que l'IP qui vous sera attribuée (attention de bien paramétrer votre Raspberry avant de l'expédier // pour vous aider des how-to sont disponibles ICI & ICI) .

Si vous avez besoin d'un peu plus de stockage il est même possible de joindre à votre envoi une clé USB (taille max. 4cm). Dernière précision : en cas de besoin (serveur planté ...) il est possible de demander le reboot de votre serveur (avec un délai de 24/48h ...).

  • l’offre de colocation gratuite d'EDIS c'est par ICI

« Adminer » : une bonne alternative à PhpMyAdmin

Publié le par
1

logo_adminerJusqu'à maintenant, lorsque j'installais un serveur LAMP j'avais pour habitude d'y ajouter systématiquement PhpMyAdmin. Non pas que je sois allergique à la ligne de commande (ça serait même plutôt l'inverse ...) mais il faut reconnaître que pour manipuler rapidement une base de données MySQL une interface web n'est pas de trop !

Malheureusement, au fil du temps, PhpMyAdmin est devenu de plus en plus lourd et de plus en plus complexe. C'est donc avec plaisir que j'ai découvert, essayé et approuvé "Adminer". Il s'agit d'une alternative intéressante à PhpMyAdmin pour les raisons suivantes :

- Adminer tient dans un seul et même script PHP. Et oui vous avez bien lu : pour l'installer il suffit de télécharger le script (un peu moins de 300ko), de le placer au sein de votre espace d'hébergement, de faire pointer votre navigateur dessus et le tour est joué !

- bien que l'interface soit particulièrement simple et sobre (ce qui n'est pas sans me déplaire) toutes les fonctions de PhpMyAdmin semblent être présentes (du moins je n'ai pas constaté de fonction manquante pour mes usages) ;

- Adminer est également compatible avec d’autres bases de données : PostgreSQL, SQLite, MS SQL & Oracle (mais là je n'ai pas essayé ...) ;

- Les mises à jour sont simplifiées à l’extrême : vous remplacez tout simplement l'ancien script par le nouveau.

adminer_screen_db

Petite information pour les utilisateurs de Debian (mais certainement aussi pour les autres distribs) il est nécessaire d'ajouter préalablement le module php5-mysql à l'aide de la commande "apt-get install php5-mysql" (nécessaire pour que Adminer puisse communiquer avec votre base de données Mysql).

Plus d'infos sur Adminer ? C'est par ICI