Préparation d'un vKS OVH avec Debian 6.0

13 03 | 2012

Préparation d'un vKS OVH avec Debian 6.0

Rédigé par Sorrodje

Classé dans : Informatique, Mémos techniques , Tutos

Jusqu'ici, j'utilisais uniquement des VPS Gandi ( comme par exemple ici ) . Assez chère, cette solution présente pas mal d'avantages dont une extrême souplesse de gestion de ressources sans avoir à se préoccuper de matériel, le tout bien sur avec une gestion très autonome de son OS et donc de son serveur.

Les services que j'héberge nécessitant jusqu'ici peu de disque, ça m'allait bien. Néanmoins , une galerie photo et un espace d'échange de partages et d'échange de fichier AjaXplorer vont assez certainement exiger plus d'espace dans les semaines et mois qui viennent. J'en profite donc pour tester les toutes dernières offres VPS d'OVH les Virtual Kimsufi (vKS). 10 E TTC pour 1 vCPU, 1Go de RAM et 50 Go de disque , c'est un profil qui correspond plutôt bien à la fois à mon budget et mon usage.

Allons y donc pour les étapes de préparation de base de cet hébergement dédié avant installation des services qui m'intéressent.

L'interface de gestion OVH

Avant tout, aller faire un tour dans la console d'administration. Ayant personnellement un abonnement internet j'ai OVH , je suis déjà habitué au manager ovh, très clair et simple à aborder :

La console générale d'accès au service

La partie dédiée à la gestion du serveur vKS:

Avec des fonctionnalités très classiques:

Reboot
Réinstallation ( Debian 6.0, CentOS 6.0 et Ubuntu 10.04 , 10.10 , 11.04 disponibles )
Réinitialisation du mot de passe root
Paramètres avancés permettant la saisie du reverse DNS et donc du nom de domaine à associer à l'IP du serveur.

Le vKS à la sauce Debian est livré avec un utilisateur root et un mot de passe envoyé par mail. Après commande en ligne le serveur est dispo en quelques minutes. En cas de réinstallation, 1 ou 2 minutes suffisent pour avoir un serveur neuf. Je le sais, j'ai testé X fois après de multiples erreurs de configuration de pare-feu et de serveur ssh se soldant par la perte de la connexion à distance au serveur...

Première connexion au serveur vKS :

ssh root@IP_DU_SERVEUR

et utiliser le mot de passe fourni par OVH

une fois connecté en root :

:~#apt-get update  :~#apt-get upgrade

Ensuite on personnalise le mot de passe root :

:~# passwd root

On crée alors directement un utilisateur hors root :

:~# adduser sorrodje

Première opération de sécurité : installation de nano et modification de la configuration ssh.

:~# apt-get install nano 
:~# nano /etc/ssh/sshd_config

On modifie le port d'écoute ( d'origine à 22 ) pour adopter un port personnalisé et on interdit les connexions en root:

# Package generated configuration file 
# See the sshd_config(5) manpage for details  
# What ports, IPs and protocols we listen for  

Port 12345  ...  

LoginGraceTime 120 
PermitRootLogin no ...

NotaBene: Attention , avec le PermitRootLogin à no, on interdit à OVH d'utiliser leur connexion root sur notre machine. Cette possibilité est en effet prévue à l'installation (voir l'existence du fichier .ssh/authorized_keys2 dans le /home de root) afin qu'VH puisse intervenir sur la machine. A vous donc de voir si vous voulez laisser ou non cette possibilité. Si vous voulez laisser une possibilité à OVH de se connecter en root via ssh au vKS , il faut passer la direcive PermitRootLogin à "without-password" et non plus à "no" (et en plus laisser en écoute sur le port 22 je présume)

On redémarre le serveur ssh:

:~#service ssh restart

A partir de là , on peut se connecter en ssh avec l'utilisateur crée en s'authentifiant par mot de passe . On reviendra ensuite interdire l'accès via mot de passe une fois adoptée et implantée l'authentification par clés publiques/privées.

Sur notre PC Ubuntu/Debian, créer la clé si ce n'est pas déjà fait :

:~$ssh-keygen -t dsa

et laisser l'endroit d'enregistrement par défaut à savoir le répertoire caché dans le /home: ~/.ssh

Envoyer alors la clé ainsi générée sur le serveur. Si une clé avait été créée pour un précédent serveur, on peut la réutiliser sans en créer une nouvelle:

:~$ssh-copy-id -i ~/.ssh/id_dsa.pub "sorrodje@IP_DU_SERVEUR -p 12345"

Ne pas oublier d'utiliser le port ssh définit dans /etc/ssh/sshd_config et le nouvel utilisateur créé. La connection est OK via l'identification par clés et on peut interdire l'authentification par mot de passe:

:~#nano /etc/ssh/sshd_config

On décommente et on modifie la ligne dédiée du fichier:

... # Change to no to disable tunnelled clear text passwords PasswordAuthentication no ...

L'accès au serveur est donc maintenant réservé à l'utilisateur sorrodje via le port 12345 , seul détenteur d'une clé d'authentification pour se connecter.

Installation et configuration d'un parefeu.

Je pensais utiliser ufw mais cet outil simplifié pour configurer Iptables pose des soucis de compatibilité avec une Machine virtuelle openVZ (ce qui est le cas des vKS). Donc on passe par Iptables et un script:

:~#nano /etc/init.d/firewall

et on crée le contenu suivant:

#!/bin/sh  
### BEGIN INIT INFO
# Provides:      iptables 
# Required-Start: 
# Should-Start: 
# Required-Stop: 
# Should-Stop: 
# Default-Start:   2 3 4 5 
# Default-Stop:       0 1 6 
# Short-description:   iptables 
# Description:       Firewall 
### END INIT INFO   

### RAZ  
iptables -t filter -F
iptables -t filter -X  

### FERMETURE TOTALE PAR DEFAUT 
iptables -t filter -P INPUT DROP  
iptables -t filter -P FORWARD DROP  
iptables -t filter -P OUTPUT DROP  

### MAINTIEN DES CONNEXIONS EXISTANTES 
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT  
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT  

### AUTORISATION DU LOOPBACK 
iptables -t filter -A INPUT -i lo -j ACCEPT  
iptables -t filter -A OUTPUT -o lo -j ACCEPT  

### AUTORISATION DU PING 
iptables -t filter -A INPUT -p icmp -j ACCEPT  
iptables -t filter -A OUTPUT -p icmp -j ACCEPT  

### AUTORISATIONS LIEES AUX SERVICES  

# SSH port 22 
#iptables -t filter -A OUTPUT -p tcp --dport 22 -j ACCEPT  
#iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT  

# SSH port 12345 
iptables -t filter -A OUTPUT -p tcp --dport 12345 -j ACCEPT  
iptables -t filter -A INPUT -p tcp --dport 12345 -j ACCEPT  

# DNS 
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT  
iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT 
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT  
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT  

# HTTP 
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT  
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT  

# HTTPS 
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT  
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT

A noter la neutralisation des règles concernant le port 22 et l'ouverture du port 1234 pour le ssh et l'utilisation de règles pour les ports 80 et 443 en prévision de l'installatio d'un serveur http/https. pour chaque service nécessitant l'ouverture d'un port particulier, il faut donc rajouter les règles iptables correspondantes.

L'en tête est nécessaire pour l'incorporation correcte du script dans le système de démarrage.

Le script étant positionné et executable and /etc/init.d, il est donc démarré automatiquement à chaque boot de la machine. Sinon pour en demander l'exécution à la main il suffit de faire :

#/etc/init.d/firewall

Pour une version plus "intelligente" et perfectionnée de ce genre de script le Wiki Debian-fr.org est votre ami.

Installation/configuration de fail2ban.

Fail2ban permet comme son nom l'indique de bannir pour une durée donnée ( par défaut 10 Mn ) les IPS qui font X erreurs (3 par défaut , 6 par défaut pour ssh) la connexion à tel ou tel service. Un serveur ssh fait assez classiquement l'objet de pas mal de tentatives d'intrusion d'où l'intérêt d'en protéger l'accès via fail2ban même si on évite déjà pas mal d'essais frauduleux en utilisant un autre port que le 22.

:~# apt-get install fail2ban

Puis il ne reste qu'à stipuler le port spécifique utilisé pour ssh en lieu et place du port par défaut. Après une installation fraîche, fail2ban est configuré pour surveiller uniquement le ssh , et bannir 10 mn les IP commettant 6 échecs consécutifs de connexion. Pour cela il faut éditer le fichier /etc/fail2ban/jail.conf et modifier la partie liée à ssh.

:~# nano /etc/fail2ban/jail.conf

...[ssh]  
enabled = true 
port    = 12345 
filter  = sshd 
logpath  = /var/log/auth.log 
maxretry = 6 ...

Et on obtient ainsi un cerbère de port ssh distribuant les coups de pied au derrière des intrus.

Ceinture et bretelles : portsentry ou comment se prémunir des sniffeurs de ports.

:~#apt-get install portsentry

Puis Au 13/03/2012: Paramétrage intégralement repris du wiki Debian : http://www.isalo.org/wiki.debian-fr/index.php?title=Portsentry

Modification du /etc/apt/sources.list

A la livraison on a ça:

deb http://ftp.debian.org/debian squeeze main contrib non-free 
deb http://security.debian.org squeeze/updates main contrib non-free

Ce qui est bien mais il manque le dépôt ex-'volatile" devenu squeeze-updates. Ce dépôt contient des MAJ particulières pour des paquets nécessitant des MAJ très régulières comme par exemple l'antivirus ClamAV et ses bases de données. Ici je le rajoute dans la perspective d'utiliser clamAV pour surveiller les fichiers de mon Ajaxplorer

Il suffit d'éditer /etc/apt/sources.list avec par exemple nano et rajouter la ligne qui va bien:

deb http://ftp.debian.org/debian squeeze main contrib non-free 
deb http://security.debian.org squeeze/updates main contrib non-free 
deb ftp://ftp.fr.debian.org/debian/ squeeze-updates main contrib  non-free

Il faudra bien penser ( Ceci est un EDIT du 21/03/2012...ahum...) d'ouvrir le port ftp dans les règles de parefeu... et donc rajouter les règles suivantes dans le fichier /etc/init.d/firewall :

# FTP 
iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT  
#iptables -t filter -A INPUT -p tcp --dport 21-j ACCEPT

puis faire appliquer le changement par :

#/etc/init.d/firewall

Je laisse la ligne INPUT commentée et donc inactive. Elle serait à décommenter/Activer en cas d'installation d'un serveur FTP sur la machine dotée de ce firewall.

Voilà une bonne base avant d'attaquer la mise en place des services proprement dit.

04/07/2012: Un exemple d'application ici avec l'installation de A à Z d'un petit serveur web sur un micro VKS généreusement offert par OVH pour les test de mise en production d'un nouveau data-center.

Quelques sources utilisées pour compléter/éclairer mon expérience personnelle :

Mots clés : vKS, OVH, Debian, Serveur, iptables, portsentry, fail2ban

46 commentaires

vendredi 23 mars 2012 à 16:27 kano a dit : #1

Vraiment merci pour cet article très utile !

J'aurais une question non pas en rapport avec l'installation, mais en rapport avec ce nouveau service d'OVH.

Leurs vcore cpu, combien de hz fait-il si vous pouvez le savoir avec une commande et quel est le cpu (i7, xenon ?).

Je trouve ça étonnant qu'ils ne mentionnent pas les hz, si ça ce trouve, ils utilisent plusieurs serveurs avec des processeurs différent et on peux tomber sur du tout (xenon) ou rien (core2duo), non ?

samedi 24 mars 2012 à 10:46 Sorrodje a dit : #2

@kano :
Merci pour le commentaire sympathique ;)

Si tu utilises la commande #cat /proc/cpuinfo , tu obtiens le résultat suivant :

processor : 0
vendor_id : AuthenticAMD
cpu family : 16
model : 2
model name : AMD Opteron(tm) Processor 6172
stepping : 3
cpu MHz : 2100.024
cache size : 512 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 8
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch
bogomips : 4200.04
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:

Et , virtualisation openVZ oblige, ça donne les infos relatives au CPU de la machine hôte : CPU AMD Opteron donc ! . Pour le reste , je vais chercher dans les doc openVZ si on peut avoir depuis la VM une idée des ressources allouées . A suivre ;)

samedi 24 mars 2012 à 13:45 kano a dit : #3

Merci ! :)

mercredi 28 mars 2012 à 11:58 Pat a dit : #4

Tout dabord, merci beaucoup pour ce tuto, excellent petit recap:)

Concernant les accès SSH, Ovh est friand d'accèder aux serveurs via leurs utilisateurs root en utilisant leurs cléfs SSH.
J'ai pris pour habitude de laisser leurs cléfs dans le fichier authorized_keys et de spécifier dans le sshd_config le parametre suivant,
PermitRootLogin without-password, bonne, mauvaise habitude, ton avis?

Ah et dans la configuration du firewall, ya une petite coquille

# SSH port 44022
iptables -t filter -A OUTPUT -p tcp --dport 12345 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 12345 -j ACCEPT

Merci encore

mercredi 28 mars 2012 à 16:32 Sorrodje a dit : #5

@Pat :

Ah oui merci pour la coquille je corrige du coup ;) .. là le port 12345 est un exemple , effectivement autant prendre le même exemple dans le commentaire et la directive ;) .

Pour l'autorisation laissée à ovh via un accès root sans mot de passe en ssh... bah je ne sais pas.

Du coup, je suis plus restrictif que toi et si je me plante (perte de mes clés ssh pour mon accès ssh ) je perds tout là où leur laisser leur accès doit pouvoir permettre à ovh de te sauver la mise... Du coup , je fais une sauvegarde minutieuse de mes clés.

Sinon je n'ai pas eu de problèmes particulier pour le moment ou d'alerte de leur part avec la fermeture de l'accès à root. Il serait sûrement intéressant d'avoir le point de vue d'ovh sur ce point. A suivre :)

jeudi 29 mars 2012 à 17:51 Momo a dit : #6

Il me semblait que c'était obligatoire, mais si ça ne l'est pas, ce serait bien !

J'ai toujours peur d'une faille ou d'une personne mal intentionné chez OVH et pourrait s’infiltrer dans mon serveur avec cet accès.

vendredi 30 mars 2012 à 10:53 sorrodje a dit : #7

Si on prend cette page ici : http://guide.ovh.com/InstallClefOVH, on voit en effet que c'est fortement déconseillé de suppprimer l'accès root d'OVH.

Pour autant, c'est avant tout une question de leur laisser la possibilité d'intervenir pour nous sortir de la mouise en cas de pépin. Il parait donc pertinent de laisser cet accès au cas où. Sinon il faut ne compter que sur soi-même ;).

Pour couper une VM très vite, je ne pense pas par contre qu'OVH ait besoin d'un accès ssh.

Du coup, je vais compléter mon récap en précisant ces points importants.

vendredi 30 mars 2012 à 18:34 Pat a dit : #8

En même temps momo, la personne qui serait mal intentionné chez ovh, n'as dans l'absolu pas besoin d'un accès ssh pour s'y connecter, elle peut soit s'y connecter en console via un clavier/ecran dans le cas d'un serveur, ou via une console sur le master dans le cas d'un vks. Mieux, elle veut t'embêter, elle fait que couper le jus de temps en temps sur ton serveur.

Je doute fortement que a ) ovh se fasse hacker leurs root de leurs machine d'authentification 2 ) qu'un tech prenne le risque de perdre son taff ( et sa crédibilité ) a faire une bétise de ce genre.

samedi 31 mars 2012 à 15:17 Aurelien a dit : #9

Salut,

Je suis devenu autoentrepreneur en 2010, mon activité était basé sur internet et je louais un dédié chez OVH.

Les débuts étaient assez difficiles, puis en 2011 j'ai pu commencer à me verser un salaire de 1200€/mois, j'ai démissionné du travail que j'avais à coté et j'ai fais un emprunt pour l'achat d'un appartement.

Juin 2011, je commande un nouveau serveur pour une durée de 1 ans, puis les ennuis commencent aussi-tôt, mon serveur se fait flooder.

Je n'ai que le minimum de connaissances en gestion de serveurs, je tente tant bien que mal de stopper l'attaque, mais en vain. OVH me résilie, 1 an de serveur de perdu.

Mon activité est suspendue durant 1 mois, le temps de trouver un nouveau serveur dédier et le temps d'apprendre à administrer un serveur.

Je relance mon activité chez un concurrent, aussi-tôt une nouvelle attaque ddos que je ne suis pas parvenus à stopper, contrat résilié de nouveau.

N'ayant plus d'argent et ayant un emprunt à remboursé, je ferme boutique et j’enchaîne les jobs.

Les attaques ddos c'est un cauchemar...

Comment protégez-vous vos serveurs de ces attaques ?

samedi 31 mars 2012 à 15:28 sorrodje a dit : #10

Aurelien : Des attaques ddos de quoi ? d'Apache ?

J'ai très peu d'expérience donc je ne suis pas vraiment le plus qualifié pour répondre à ce genre de question mais il me semble que la littérature est plutot abondante sur le sujet de la sécurité vis à vis des attaques ddos.

Sur un précédent serveur, j'ai installé un module apache2: mod-evasive voir http://www.isalo.org/wiki.debian-fr/index.php?title=Libapache2-mod-evasive par exemple.

fail2ban est aussi une bonne piste pour bannir de l'IP aggressive en suivant l'activité de différents log et il me semble qu'il est configurable pour prévenir une attaque ddos. Voir ce billet ici : http://blog.nicolargo.com/2012/02/proteger-son-serveur-en-utilisant-fail2ban.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+LeBlogDeNicolargo+%28Le+blog+de+NicoLargo%29

dimanche 01 avril 2012 à 14:53 xPopey a dit : #11

Oula! J'aurais demandé à un professionnel de sécuriser le serveur, bien que ça doit coûter bonbon, quitte à faire un second emprunt !

Quoi que, je dis ça, mais est-ce qu'un pro aurait pu faire quelque chose ? Car à part avoir un second serveur en backup pour partager la charge durant l'attaque je vois pas trop... Si il existait un réel moyen de bloquer les DDOS ça ce saurait.

Je m'en suis déjà mangé une de type SYN flood, je ne suis pas parvenus à la bloquer avec fail2ban (je ne trouvais pas comment faire) et j'ai attendu que ça passe, heureusement l'attaque devait venir d'un amateur avec peu de moyens ou il en a eut marre et mon serveur s'en est sortit.

C'est quand même énervant qu'une attaque à la porté du premier kikou soit capable de couler un serveur, voir carrément une entreprise !

Perso, je ne peux gérer mon serveur que le weekend, donc si je reçoit une grosse attaque en semaine bye bye mes sites sites web. x_x

Je vis dans cette crainte depuis la première attaque que j'ai reçus (il y a 8 mois).

@sorrodje : Ton dernier lien est très intéressant ! Par contre, ça sert à contrer une attaque en cours, ce n'est pas automatique d'après ce que j'ai compris, donc si on est pas présent ça ne sert à rien. :s

dimanche 01 avril 2012 à 15:22 xPopey a dit : #12

Oops j'avais une question à poser à la base, mais j'ai oublié ! XD

Un VPS chez OVH avec 1vcor et 512Mo de ram c'est 20€HT/mois.
Chez kimsufi c'est 5€HT/mois.

La différence me semble tout de même énOrme avec un gros O.

Qu'est-ce qu'un VPS kimsufi a de moins ?

dimanche 01 avril 2012 à 16:24 Pat a dit : #13

Sans en être sur, surement qu'un expert pourrait le confirmer.

- Le cpu sur vps est dédiés, sur le vks, c'est selon l'utilisations des autres vm sur le même host

- Une limitation du traffic, limité à 2To sur le vks après, la bp est réduite à 1mbps ( SANS ) garantie pour le vks

- sauvegarde automatisé, augmentation/diminution des ressources, SLA de 99.9%, support. Sur les vks, le support est via le forum uniquement, et je n'ai pas vu de SLA ( bigleusité? )

- Point marrant, selon la ML :

Internet vers vKS (par IP destination du vKS)

ICMP 32Kbps
UDP 10Mbps
TCP 100Mbps

vKS vers Internet (par IP source du vKS)

ICMP 32Kbps
UDP 10Mbps
TCP 100Mbps

Alors que le vps c'est :
http://www.ovh.com/fr/vps/vps_dynamique_fiche_technique.xml

Le protocole TCP est ouvert et les débits sont plafonnés à 100 Mbps.
Le protocole UDP est ouvert et les débits sont autorisés à hauteur de 5 Mbps.
Le protocole ICMP est ouvert et les débits sont limités à 32 Kbps.

dimanche 01 avril 2012 à 18:01 Ed a dit : #14

Bonsoir,

Merci pour ce tutoriel très intéressant.

Je me permet une question : Une débian avec iptable, fail2ban, apache et mysql consomme combien de ram ?

C'est pour me faire une idée pour choisir entre le plant Small et le Medium.

Je voudrais y héberger un jeu web en php/mysql mais qui utilise aussi nodeJS (un interpréteur en python... python et ram... aie) pour des combats en temps réel.

Merci d'avance

dimanche 01 avril 2012 à 21:11 sorrodje a dit : #15

@Ed: Ta conso de RAM va dépendre de l'activité de ton serveur ;) ... A priori , OVH va permettre la montée en gamme des vks ...Donc tu prends un small, tu testes et tu upgrades si tu vois que ça ne suffit pas. Sinon fait des tests sur des VPS à ressources variables ( OVH ou Gandi par exemple ) et une fois que tu sais ce dont tu as besoin, tu optes pour la formule qui correspond à ton usage.

dimanche 01 avril 2012 à 21:20 sorrodje a dit : #16

@xpopey : les solutions VPS OVH ou GANDI sont beaucoup plus chères mais c'est le prix d'une souplesse incomparable + les sauvegardes auto + les snapshots auto de machines et autres services vraiment précieux à plusieurs titres. Je dirais que le vks est un intermédiaire ente un hébergement mutualisé et un dédié bas de gamme. Sans avoir totalement la main sur la VM , on peut quand même administrer vraiment son serveur, monter ses services etc.

dimanche 01 avril 2012 à 21:27 ed a dit : #17

Je voulais dire la consommation à vide, sans aucune utilisation juste avec les logiciels de base installé, combien de mémoire reste t-il ?

Au passage encore une question noob, je n'ai jamais entendu parlé de snapshots, en quoi cela consiste ?
Ce que j'ai trouvé sur google n'est pas très clair.

Merci !

dimanche 01 avril 2012 à 22:00 sorrodje a dit : #18

@ed : J'ai jamais trop fait gaffe mais sur mes 1 GO actuels du vks sur lequel c'est surtout ce blog qui a un petit peu d'activité régulière ( 40/50 visiteurs jours et 8/10Mo de bande passante/jour ) j'ai une conso de RAM moyenne de 180 Mo avec un max à 270.

Les snapshots ce sont des copies instantanées de Machines virtuelles ..Genre tu cliques et ça fait une copie intégrale de la Machine à l'instant T. Cet instantané peut être redémarré en quelques dizaines de secondes en cas de besoin .

dimanche 01 avril 2012 à 22:16 ed a dit : #19

Ah ok, pratique en effet !

Pour la ram, il en faut tant que ça pour un blog ??
Sur mon jeu web j'ai jusqu'à 15 joueurs connectés sur le mutualisé où je suis (je veux un serveur pour pouvoir utiliser node js), ça risque donc d'être trop juste un vKS de 1Go ?

dimanche 01 avril 2012 à 22:17 ed a dit : #20

Est-ce possible de faire un snapshot soit-même ? C-à-d faire la copie du serveur et la télécharger ?

dimanche 01 avril 2012 à 22:47 sorrodje a dit : #21

@ed : Pour ton jeu, sincèrement je ne sais pas. Prends toi un VPS à ressource variable et teste!.

Pour ta copie de serveur, il me semble que ça n'est pas possible. En tous cas par le biais de modalités de snaphosts incluses dans le dispositif de virtualisation. Mais je n'en sais rien à vrai dire.

lundi 02 avril 2012 à 16:24 Pat a dit : #22

Pour répondre à l'une des questions précédentes, un vks vierge

root@vks:~# free -tm
total used free shared buffers cached
Mem: 512 15 496 0 0 10
-/+ buffers/cache: 4 507
Swap: 128 0 128
Total: 640 15 624

root@vks:~# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 8356 780 ? Ss Mar27 0:00 init [2]
root 2 0.0 0.0 0 0 ? S Mar27 0:00 [kthreadd/10397]
root 3 0.0 0.0 0 0 ? S Mar27 0:00 [khelper/10397]
root 365 0.0 0.1 5980 692 ? Ss Mar27 0:00 /sbin/syslogd
root 402 0.0 0.2 49172 1140 ? Ss Mar27 0:00 /usr/sbin/sshd
root 413 0.0 0.1 19332 940 ? Ss Mar27 0:00 /usr/sbin/xinetd -pidfile /var/run/xinetd.pid -stayalive -inetd_compat
root 416 0.0 0.1 22396 844 ? Ss Mar27 0:00 /usr/sbin/cron
root 1133 0.0 0.6 79000 3516 ? Ss 16:22 0:00 sshd: root@pts/0
root 1135 0.0 0.3 19220 1972 pts/0 Ss 16:22 0:00 -bash
root 1141 0.0 0.2 16336 1120 pts/0 R+ 16:23 0:00 ps aux

root@vks:~# mount
/dev/simfs on / type simfs (rw,relatime)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,relatime,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)

lundi 02 avril 2012 à 16:28 Pat a dit : #23

et avec tout le tsouin tsouin d'installé

#free -tm
total used free shared buffers cached
Mem: 512 276 235 0 0 234
-/+ buffers/cache: 42 469
Swap: 128 0 128
Total: 640 276 363

lundi 02 avril 2012 à 19:42 Bern a dit : #24

J'adore ce blog! Sorrodje j'ai l'impression que tu aurais mieux fait d'ouvrir un forum.XD

Alors pour l’histoire du jeu, vraiment ça dépend de ta façon de coder.

Moi, je suis très orienté objet, j'ai des 10enes de class d’incluses par page, beaucoup de gros arrays (objets sérialisés en session) et je monte à 6Mo ram/page en moyenne.

Donc à moins d'avoir une 100ene de visiteurs qui demandent à voir une page au même moment, pas de raison qu'un gros site (comme un jeu) en php puisse ramer sur un vKS.

Par contre, tu parles de node js, ça peux coincer à ce niveau car le temps réel ça consomme des ressources en permanence. Je n'ai pas d'exp dans ce domaine... Si tu vois que ça ram, tu pourrais limiter le nombre de joueurs pouvant accéder à ton application qui utilise node js ?

Sorrodje, merci pour tes articles enrichissants !

lundi 02 avril 2012 à 19:55 Bern a dit : #25

Euh, sinon, pourquoi ne pas utiliser virtualbox ?

Tu virtualise ta debian avec 1Go de ram et 1cpu et tu lances des bots sur ton application en temps réel, ça te donneras une idée !

lundi 02 avril 2012 à 21:27 anon a dit : #26

Comment faire une installation de debian de façon optimisé pour OpenVZ ?

OpenVZ gère bizarrement la mémoire, d'après OVH c'est à nous utilisateurs de faire en sorte d'optimiser l'installation pour OpenVZ.

mardi 03 avril 2012 à 14:42 Pat-trick a dit : #27

Mémo bien utile !

@celui qui parle de node.js : Es-tu sûr que c'est supporté sur les vKS ?

Sorro, savez-vous si c'est le cas ?

Par exemple tomcat ne fonctionne pas dessus, alors node.js...

Ce serait bon à savoir car si ce petit virtualisé le supporte, je serais bien tenté !

mardi 03 avril 2012 à 15:10 sorrodje a dit : #28

Merci pour les commentaires sympa, ça fait plaisir ;)

Vous me flattez avec vos questions mais en général, je n'en sais pas plus que vous ... Donc je vais faire un tour chez mon ami Google. Après, quand la recherche a été complexe ou que j'ai réussi à me faire une procédure à peu près fiable à répéter, Je m'en fais un mémo pour moi ou pour faciliter le travail du gars qui se va se retrouver un jour comme moi à brasser google pour essayer de recoller les morceaux.

Rien de plus.

mardi 03 avril 2012 à 21:09 plopyplopa a dit : #29

Sorrodje, as tu déjà testé les VPS tonbnc.fr ?

D'après la description ce sont de vrais VPS (pas comme les vKS) aved 1Go de ram et 2 coeurs de i7 920 pour 10€/mois.

L'offre me semble trop alléchante, je me demande les perfs réels... -_-

mardi 03 avril 2012 à 22:29 sorrodje a dit : #30

@plopyplopa : Non pas testé et je ne connaissais pas d'ailleurs .. A priori tu auras plus de retours ici : http://www.siteduzero.com/forum-83-524827-p1-tonbnc-vps-serveurs-dedies-virtuels.html ;)

mercredi 04 avril 2012 à 15:15 plopyplopa a dit : #31

On peux s'engager pour seulement 1 mois. Je vais m'en prendre un à 4€ (c'est TTC d'après le sujet sur le sdz O_O) pour voir ce que ça vaut !

vendredi 06 avril 2012 à 15:53 Escaflowne a dit : #32

Très utile ce mémo, merci pour le partage !

jeudi 24 mai 2012 à 20:54 numero8 a dit : #33

Excellent tuto merci beaucoup.

vendredi 22 juin 2012 à 19:57 Ludo a dit : #34

Hello,

venant de récupérer un micro vks, ton tuto m'a beaucoup aidé, et je t'en remercie.

Petite question de débutant, tu en conviendras : il est suffisant de créer le fichier /etc/init.d/firewall pour activer iptables ? Je ne crois pas t'avoir vu indiquer quoi faire, comme installer un package, relancer un service, etc...

Merci d'avance !

lundi 25 juin 2012 à 11:48 Sorrodje a dit : #35

Hello,

En fait le script crée dans le répertoire /etc/init.d et écrit tel que décrit plus haut va s'exécuter à chaque démarrage. Si tu veux le démarrer en dehors du processus de démarrer il suffit d'utiliser la commande /etc/init.d/firewall start .. ou stop si tu veux arrêter le pare-feu .

lundi 25 juin 2012 à 14:40 Ludo a dit : #36

C'est bien ce que je pensais avoir compris, mais c'est beaucoup plus clair ainsi.
Par-contre, je pense qu'il serait bon de le préciser dans l'article, ça serait parfait; on ne prévoit pas souvent de rebooter son serveur :)

Merci encore !

lundi 25 juin 2012 à 17:47 Sorrodje a dit : #37

Remarque justifiée. Je compléterai la partie de mise en place du firewall :)

lundi 25 juin 2012 à 21:52 Sorrodje a dit : #38

@Ludo:

En fait je crois que je t'ai dit des bêtises. En fait, le script en l'état exécute "bêtement" un certain nombre de règles iptables. Pour simplement le mettre en oeuvre, il suffit de passer la commande /etc/init.d/firewall en tant que root et les règles iptables se mettent en place.

Pour annuler le pare feu, il faudrait créer un script passant des règles d'ouverture des port ou passer les commander iptables à la main.

Au reboot, si le script n'était pas executé à l'initialisation , il faudrait à chaque reboot passer la commande /etc/init.d/firewall.

L'intérêt alors est de concocter un script plus complexe comme par exemple dans ce tuto : http://www.isalo.org/wiki.debian-fr/index.php?title=Parefeu_Simplifi%C3%A9 .

Dans mon propre tuto en fait j'ai voulu rester le plus proche posssible d'une configuration "par un nul" sans copier/coller les excellentes création d'autres Debianneux ;)

vendredi 21 septembre 2012 à 17:49 Visier a dit : #39

Super tuto.
Penser à rendre le fichier du firewall exécutable (chmod ugo+x /etc/init.d/firewall) sinon, il ne se lancera pas.
Je ne sais pas si les trois lettres(ugo) sont indispensables, dans le doute j'ai mis les 3.

dimanche 07 octobre 2012 à 20:13 fred a dit : #40

Je viens de commander mon pack small vks pour essayer sur 3 mois,j'éspère que ce tutoriel va m'aider à venir a bout de l'installation car je n'est jamais fait.

Une question me viens à l'esprit, quel solution de sauvegarde vaut-il mieux prendre ?

vendredi 23 novembre 2012 à 18:16 Matt a dit : #41

Euh, petite question sûrement stupide. Comment peux-on accéder après au compte root si on a désactivé le ssh pour le root. Genre pour créer le /etc/init.d/firewall, on a pas les droits !?

En tout cas merci pour ce petit tuto. Je pense bientôt me prendre un vks et ça devrait me faciliter un peu la tâche ! :)

samedi 24 novembre 2012 à 15:09 Sorrodje a dit : #42

@Matt :y'a jama'is de question stupide. Pour passer en "root" soit tu passes root avec "su root" soit tu as configuré un sudo et tu utilises sudo (à la Ubuntu quoi) après t'être connecté via ssh avec ton utilisateur normal. La seule chose bloquée pour root ici c'est l'accès ssh direct.

mardi 27 novembre 2012 à 14:14 bobi a dit : #43

Bon bin apparement la démo VKS c'est fini :/

snif me servait bien cette petite seedbox comment j'vais faire maintenant ? une idée ? no Money § ! :)

mardi 22 janvier 2013 à 15:47 Rouche a dit : #44

Il y à un point que je ne comprend pas dans votre tutoriel. (Je fais mes test dans VirtualBox sous Debian) avant de passer à mon Kimsufi.

Vous dites :
"On modifie le port d'écoute ( d'origine à 22 ) pour adopter un port personnalisé et on interdit les connexions en root:"

Après cette opération je ne peux plus me connecter en root sur la machine mais bien avec le compte utilisateur créé.

C'est la qu'est le problème avec le compte créé avec adduser je ne peu plus modifier /etc/ssh/sshd_config ainsi que les fichiers appartenant à root.

Heureusement je suis sous VirtualBox donc je peut remettre le paramètre 'PermitRootLogin' sur 'yes'.

Je ne vois pas ce que j'ai loupé dans votre méthode pour que ça fonctionne.

mardi 22 janvier 2013 à 15:54 Sorrodje a dit : #45

@Rouche: l'intérêt est justement que root ne puisse plus se connecter. Du coup ça demande de se connecter avec un utilisateur normal puis pour les tâches le nécessitant de passer root via "su root" après avoir accédé à la machine via ssh en tant qu'utilisateur normal.

mardi 22 janvier 2013 à 15:56 Rouche a dit : #46

Effectivement je viens de comprendre mon erreur.
L'utilisation du 'su' est donc la solution.
Merci pour ce tuto, je passe à la suite.

Fil RSS des commentaires de cet article

sorrodje.alter-it.org