Pour faire suite à mon billet sur LXC, voici comme j’ai organisé mon réseau.

Avant d’aller plus loin : j’ai fait comme ça parce que c’était mon besoin, vous pouvez faire comme bon vous semble (et si vous voulez partager n’hésitez pas ;))

Alors, comme je l’ai expliqué, j’ai fait un réseau local dédié/conteneurs.

Quand je crée un conteneur je fais ça (que j’ai mis dans un script parce que bon, faut pas pousser mais la flemme c’est bon quand même) :

lxc-create -n nom.domaine -t debian -- -r stretch

Et j’enchaîne sur :

cp interfaces /var/lib/lxc/nom.domaine/rootfs/etc/network/interfaces
cp resolv.conf /var/lib/lxc/nom.domaine/rootfs/etc/resolv.conf
cp 99local /var/lib/lxc/nom.domaine/rootfs/etc/apt/apt.conf.d/
cp /etc/apt/sources.list /var/lib/lxc/nom.domaine/rootfs/etc/apt/sources.list

Mon interfaces contient ma conf par défaut (IP locale donc tu prends ce que tu veux en 192.168.xx.xx ou en 10.xx.xx.xx, enfin tu vois le principe quoi).

auto lo
  iface lo inet loopback
auto eth0
  iface eth0 inet static
   address xx.xx.xx.xx
   netmask 255.255.xx.xx
   gateway xx.xx.xx.xx
  iface eth0 inet6 static
   address xx::xx:xx
   netmask xxx
   gateway xx::xx:xxx

Mon resolv.conf reste un classique :

nameserver xx::xx:xxx
nameserver xx.xx.xx.xxx

Je remplace l’IP par celle que je veux dans /var/lib/lxc/nom.domaine/rootfs/etc/network/interfaces

(Tu vois l’intérêt du script ? Je n’ai qu’à lancer le .sh avec le nom de conteneur en $1 et le dernier chiffre de l’IP en $2 et rulz). Tu noteras sûrement que j’ai IPV4 et IPV6, attention à adapter ça à ton environnement. On start ensuite le conteneur :

lxc-start -n nom.domaine

et on liste :

lxc-ls --fancy

Bon ensuite il ne faut pas oublier ton iptable à modifier. Si tu me connais tu sais que le réseau c’est clairement pas mon fort donc pour les détails d’iptable je te laisse voir ici, lea-linux explique vachement mieux que moi xD

Je ne sais pas si la partie réseau est plus limpide comme ça… au pire tu sais où me trouver et je compléterai

The post LXC – Partie Réseau appeared first on Hackorn.

Après ma migration de dédié, j’ai conteneurisé mes services. Pour plusieurs raisons :

1. Pouvoir bouger les conteneurs en cas de mise à jour
2. Pouvoir créer un conteneur, upgrader et déplacer les services (ou tester une MAJ)
3. Confiner les services
4. Pouvoir tester des trucs sans défoncer le dédié mais sans pour autant créer des VMs qui sont souvent lourdes et c’est chiant.

Donc mon choix s’est assez simplement tourné vers LXC. D’abord parce que c’est simple, ensuite parce que c’est simple et enfin parce que c’est simple.

Je pars d’une base Debian Stretch, il faudra donc adapter ce tuto à votre environnement.

Donc on y va, on installe déjà LXC :

apt install lxc

Et pis on va créer un conteneur qui s’appellera prout et qui sera en Debian Stretch :

lxc-create -n prout -t debian -- -r stretch

Et puis on va le démarrer :

lxc-start -n prout

Si on préfère rester sur le host pour taper le conteneur, c’est pas compliqué non plus (ici par exemple pour un update) :

lxc-attach -n prout -- apt update

Et si on veut lister nos conteneurs :

lxc-ls

Bien entendu, pour arrêter le conteneur :

lxc-stop -n prout

Et pour l’effacer :

lxc-destroy -n prout

Attention cependant

Les conteneurs ont leur IPs propres, donc soit vous en avez plein et vous pouvez attribuer une IP par conteneur, soit il faudra faire un réseau local entre votre machine et vos conteneurs.

Perso j’ai fait un conteneur pour les mails, un pour tout ce qui est services web, un pour mes DNS etc… un par groupe de service.

Et comme c’est encore tout frais dans ma tête je le pose là, comme ça ça fait un excellent aide mémoire en cas de besoin

The post Conteneurs LXC appeared first on Hackorn.

Suite à mon article, j’ai eu plusieurs retours. Je vais passer sur les personnes qui jugent sans connaître ce que je fais, et sans vouloir le savoir visiblement. Mais beaucoup m’ont demandé : vouloir changer oui… mais par quoi commencer ?

Déjà la première question à se poser c’est quels sont vos besoins ? La seconde c’est jusqu’où voulez-vous aller ? Et bien entendu… quelles sont vos compétences et votre temps disponible ?
En fonction de vos besoins, il faudra regarder ce qui vous correspond le mieux. Je peux vous dire : “le mieux est d’être full auto hébergé(e) et ainsi de reprendre le contrôle de vos données”. Sauf que ça ne va pas vous aider… On ne devient pas auto hébergé(e) du jour au lendemain, juste parce qu’on en a envie. Il y a des connaissances à acquérir, des informations à assimiler, des bases à avoir… Ce n’est clairement pas impossible, à la base je n’ai aucune formation en informatique et j’ai réussi, vous pouvez donc réussir également sans trop de mal… mais ça demande du temps. Beaucoup de temps.

J’ai commencé à tripoter mes PC, puis j’ai fait des petits sites internet, puis je me suis dit “c’est cool et si je l’hébergeais ? » et c’est là que tout a commencé. J’ai pris un serveur dédié, et j’ai commencé à installer mon système (Debian) puis j’ai sécurisé un minimum, puis j’ai fait mon serveur web, puis serveur IRC, puis xmpp, puis mail, RSS et ça ne s’arrête jamais…

Sauf que ça je l’ai fait sur mon temps libre à la base. Et qu’au bout de plus de 10 ans il y a toujours des choses à faire, à améliorer, à mettre à jour etc… et ça demande également un budget que tout le monde n’a pas. Même un petit serveur dédié a un coût. Après il y a des alternatives…

Le serveur dédié :

Un serveur dédié est, comme son nom l’indique, un serveur qui est “à vous”. Vous le louez à un hébergeur (Online, OVH etc…) et vous pouvez jouer avec. Il est exposé à internet (puisque distant) attention donc à l’utilisation que vous en ferez. Quoi qu’il arrive, faites toujours attention à ce que vous partagez.

Du moment que c’est sur internet, rien n’est sécurisé à 100% et il y a toujours un risque, même minime, que vos données fuitent.

Vous pouvez tout héberger dessus normalement (en tout cas je n’ai pas vraiment eu de souci avec un dédié jusqu’à présent).
L’avantage c’est que c’est rarement down, une coupure de service peut arriver, mais c’est assez rare il faut le reconnaître.
Ensuite, le plus gros du travail reste à faire : il faut installer un système d’exploitation, le sécuriser un minimum et installer les services que vous désirez. Alors autant ce n’est clairement pas impossible, autant si vous n’avez jamais touché à ça ce n’est clairement pas ce que je vous recommande.

Un vieux PC dans un coin :

Vous avez un vieux PC (pas trop vieux quand même ?) qui prend la poussière ? Installez votre système d’exploitation et tentez d’apprendre avec ça pour commencer, ça suffit largement pour comprendre et apprendre (et jouer parce que c’est important aussi). Et si vous le connectez à internet et que vous ouvrez les ports de votre box/routeur ça vous fait un petit serveur chez vous.

Un dédié comme un vieux pc, vous pouvez également vous simplifier la vie avec des outils qui vont vous guider.
Si vous avez un PC plus puissant, rien ne vous empêche de vous entraîner dessus non plus (mais mettez une machine virtuelle(1) quand même, ça peut éviter de casser son système si on ne sait pas trop où on va).

Yunohost :

YunoHost est un outil qui vous permet d’installer et d’utiliser facilement votre propre serveur. Il vous propose des applications afin de faciliter l’installation de vos produits en fonction de vos besoins. Il vous aidera à faire un premier pas dans l’auto hébergement (mails, cloud, blog etc…)

La brique internet :

Vous n’avez ni PC à utiliser ni serveur ? Vous pouvez utiliser la brique internet comme vpn et mini serveur et vous rapprochez d’une association afin qu’elle vous aide à la mettre en place et vous explique comment le faire correctement. Elle fonctionne également avec Yunohost afin de faciliter le tout.

Vous ne voulez pas franchir le pas tout de suite mais vous aimeriez quand même utiliser des alternatives ?
Et bien ça existe aussi

On y va ?
Je ne vais pas TOUT citer parce qu’il y aurait vraiment beaucoup beaucoup de choses, mais si vous avez des propositions n’hésitez pas à les faire en via les réseaux sociaux par exemple.

Donc on commence par les mails : Pour sortir de Google, il est possible d’utiliser simplement les mails de votre fournisseur d’accès internet mais il est également possible d’utiliser Protonmail.
Ah… oui les mails sont accessibles sur mobile également, ça paraît évident (ou pas ?) mais il existe des applications telles que K9mail ou encore l’application Protonmail pour ça.

Pour quitter Facebook ?
C’est magique, parce qu’il existe Diaspora/Framasphère qui reste un équivalent assez proche et assez simple d’utilisation : il suffit de créer un compte et pof, ça marche juste.
Alors oui, il y a moins de monde… mais si tout le monde bouge dessus, bah il y en aura plus (Captain Obvious inside).

Et Twitter ?
Trop facile, il y a un équivalent (mais à 500 caractères parce que bon, on a plein de choses à dire quand même) qui s’appelle Mastodon. Le principe est d’avoir plein d’instances qui se causent entre elles. Le plus compliqué est d’en choisir une mais TheKinrar a fait ça pour nous aider à la choisir en fonction des goûts et des choix de chacun.

Je ne vais pas citer l’agenda, les clouds, des sites/blogs etc… mais vous pouvez aller visiter le site de framasoft qui fait ça très bien et mieux que moi.

L’avantage avec les produits de Framasoft, c’est que non seulement vous pouvez les utiliser… mais vous pouvez également les implémenter vous-même.

Hostux propose également des services (instance Mastodon, hébergement d’images, mails, un pod Disaspora, un IRC etc…) que vous pouvez utiliser.

Un dernier point important à mes yeux : les messageries instantanées.

Aujourd’hui vous pouvez utiliser le chat Facebook, les DM Twitter, Hangout etc… mais il y a également des alternatives. Vous pouvez avoir une messagerie instantanée assez facilement avec Telegram, Signal, Wire où il suffit de s’inscrire et commencer à avoir vos amis dessus.

Vous avez également l’alternative XMPP qui est un protocole de communication. Là il faut choisir un client (Gajim par exemple pour PC ou Conversations pour mobile) et créer un compte sur un serveur existant ou chez un ami à vous.

Alors ? On commence quand ?

The post Vie privée : par où commencer ? appeared first on Hackorn.

Élan, soit ELK en anglais, veut dire sans jeu de mot foireux ElasticSearch, Logstash et Kibana.

Qu’est ce que c’est ?

ELK est une suite logicielle qui permet d’indexer les données, de les filtrer et de les afficher.
Elasticsearch est un serveur utilisant Lucene pour l’indexation et la recherche des données (Source).
Logstash est un ETL (Extract-transform-load). Il permet d’effectuer des synchronisations massives d’information d’une source de données vers une autre (Source).
Kibana fournit des fonctions de visualisation sur du contenu indexé dans une grappe Elasticsearch (Source).

Comment ça marche ?

Dans mon contexte, je l’ai utilisé comme concentrateur de logs. Logstash va recevoir les logs, puis les filter pour ensuite les renvoyer dans ElasticSearch. Kibana va ensuite afficher les résultats de ce qu’on veut. Il va également permettre de créer des filtres par rapport à ce que l’on recherche. Du coup c’est finit les grep dans tous les sens pour trouver une info… là on a tout sous la main.

Donc on installe la suite logicielle (je te fais pas de dessins, il y a pas mal de docs dessus, et puis un apt install y’a rien de sorcier, on va plutôt aller voir un peu plus loin).
Ta suite est installée sauf que là, bah t’es un peu perdu(e) vu que la suite reste très difficile à documenter…

ElasticSearch :

On commence par configurer ElasticSearch (exemple que tu peux trouver ici).
Le fichier de conf se trouve dans /etc/elasticsearch/elasticsearch.yml :

###### Cluster ######
#Ici on met un nom de cluster... chaque node qui sera rattaché à ce cluster devra porter le même nom.
cluster.name: prout


###### Node ######
#Nom d'un node... afin qu'on puisse le reconnaître.
node.name: "prout-01"

#On peut déterminer si un node sera un master ou non. Sachant que tous vos nodes peuvent être ET master et data. ElasticSearch gère plutôt pas trop mal la répartition. 
#node.master: true
#node.data: true

###### Index ######
#On peut ici indiquer le nombre de shards et de replicas.
index.number_of_shards: 2
index.number_of_replicas: 1


###### Paths ######

path.conf: /path/to/conf
path.data: /path/to/data
path.logs: /path/to/logs

###### Network And HTTP ######

network.host: prout01.localhost
http.port: 9200

###### Discovery ######

discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]
discovery.zen.minimum_master_nodes: 1
discovery.zen.ping_timeout: 100s
discovery.zen.fd.ping_timeout: 100s

C’est une conf basique. Simple. C’est surtout pour comprendre le principe.

ATTENTION : C’est une conf par défaut à adapter à votre environnement (elasticsearch écoute sur Internet par défaut, pas d’authentification, ça peut se faire trouer facilement). Donc soit on évite le localhost, soit on expose pas la machine à Internet.

Je vais m’attarder un peu sur les shards et les replicas… Un shard va répendre la donnée sur tous les nodes, alors qu’un replica va le répliquer. Le tout est de savoir combien il en faut en fonction des données à traiter etc… Perso j’ai commencé à m’y intéresser quand j’ai perdu un node donc bon…

Logstash :

Logstash va permettre de filter ce que vous voulez garder.
Attention cependant à bien organiser tout ça dès le départ. Pour MON besoin j’ai découpé les fichiers en fonction de l’ordre.

ATTENTION : Les inputs doivent toujours se trouver AVANT les filters. Les Outputs doivent toujours se trouver APRES.

Du coup j’ai fait un truc du genre :
001input
200filters
400output

Comme ça on peut ajouter d’autres fichiers par exemple 201filters qui aura un filtre firewall par exemple ou un autre pour les syslogs etc…
Pour les filtres là c’est un peu plus compliqué mais si tu cherches sur ton canard préféré tu devrais trouver quelques templates pour d’aiguiller.

Kibana :

Pour Kibana c’est bien plus simple je crois… On prend le /etc/kibana/kibana.yml (tu peux trouver un exemple ici) :

server.port: 5601
server.host: "localhost"
server.name: "prout01"
kibana.index: ".kibana"

Voilà à peu près ce qu’il vous faut pour que ça marche juste.

Donc on récapétète : on installe, on configure et on démarre et pof ça marche.

Si tu as des questions tu sais où me trouver. Je ferai peut être un article si ça intéresse des gens sur le fonctionnement un peu plus poussé de kibana… Mais c’est déjà un bon début pour commencer à comprendre le principe et jouer avec.

Merci aux gens pour les corrections et les compléments pour cet article <3

The post Et si on parlait d’élan ? appeared first on Hackorn.

Dans l’article précédent je t’expliquais que je faisais tout via playbook ansible. Je ne vais pas t’expliquer ce que c’est ni comment l’installer, il y a suffisamment de sites qui en parlent (par exemple tu peux voir ici pour l’installation.

Nous allons surtout voir comment commencer réellement (parce qu’on ne va pas se mentir, c’est assez relou de trouver comment bien faire les choses quand on ne sait pas trop comment ça fonctionne). Je vais te montrer ce que j’ai fait… mais ça ne veut pas dire que cette méthode est la meilleure du monde, juste qu’elle est adaptée à mon besoin personnel.

Mon besoin de départ : installer et faire les updates de serveurs.

On commence par créer (si ce n’est pas déjà fait) un répertoire ansible (dans /opt). Il sera notre répertoire de travail. Il vous faudra, au minimum, un fichier hosts, un playbook.yml et un répertoire roles/. Le fichier hosts renseignera tous vos hosts qui seront touchés par votre playbook. Vous pourrez y classez les hosts par catégorie en fonction de votre besoin.

En voici un exemple :

[local]
localhost ansible_connection=local

[DEV]
host.de.dev.1
host.de.dev.2
host.de.dev.3

[PRE-PROD]
host.de.pp.1
host.de.pp.2
host.de.pp.3

[PROD]
host.de.prod.1
host.de.prod.2
host.de.prod.3

Tu peux aussi y ajouter des variables :

[local]
 localhost ansible_connection=local

[DEV]
 host.de.dev.1
 host.de.dev.2
 host.de.dev.3

[DEV:vars]
 environment=development

[PRE-PROD]
 host.de.pp.1
 host.de.pp.2
 host.de.pp.3

[PRE-PROD:vars]
 environment=preproduction

[PROD]
 host.de.prod.1
 host.de.prod.2
 host.de.prod.3

[PROD:vars]
 environment=production

Ces variables peuvent être ensuite appelées dans le playbook afin de cibler qu’une catégorie. Par exemple, si l’environnement est production, il ne faut pas reboot le serveur n’importe quand.

Nous verrons le playbook un peu plus tard.

Pour ce qui est du répertoire roles/ voici comment je l’ai organisé : Un répertoire par soft (par exemple tmux) qui sera composé de :
* – defaults/*
* – files/*
* – handlers/*
* – meta/*
* – tasks/*
* – templates/*
* – vars/*

Même si ces répertoires ne contiennent pas de fichiers, ils sont présents (histoire d’uniformiser l’architecture et de pouvoir évoluer par la suite si les rôles se complètent).

Les répertoires sont assez parlants, après tu peux toujours aller voir quelques repos git pour voir les constructions.

Un fichier important à renseigner est le tasks/main.yml. C’est ici que seront indiquées les actions à mener.

Si je reprends mon tasks/main.yml de tmux, voici ce que j’ai :

---

- name: install tmux
  apt: name=tmux state=latest

- name: deploy etc_tmux_conf file
  copy:
  src: roles/tmux/templates/etc_tmux_conf
  dest: /etc/tmux.conf
  owner: root
  group: root
  mode: 0644
  backup: no
  force: yes

On va décomposer : – Un fichier .yml pour ansible commence toujours par

• name: permet de nommer l’action (sera visible lorsque le playbook se lancera)
• apt: l’action à mener (ici un apt)

puis name= avec le nom du paquet et state=latest pour la dernière version.

Pour la seconde action, il s’agit simplement de déposer un fichier de conf personnalisé. Comme tu peux le voir, ce fichier de conf est dans templates. Pour faciliter la lecture, je nomme le fichier par le chemin où il est (ici etc/tmux.conf). Il n’y a pas réellement besoin de fichier de configuration pour tmux, mais ça permet surtout de mettre des entêtes du type :

############################################################################
# This file is managed by Ansible, any manual changes will be OVERWRITTEN #
############################################################################

C’est simplement un exemple hein, tu n’es pas obligé(e) de poser un fichier de conf à chaque fois, après c’est toi qui vois.

Nous avons donc notre rôle tmux.

Donc là, nous avons le rôle, une task, une conf et des hosts. Il nous reste qu’à faire un playbook pour relier le tout.

Nous allons donc le créer. Appelons-le par exemple playbook-install.yml.

---

- hosts: "{{ target }}"
  user: username
  become: true
  become_method: sudo
 
roles:
  - { role: tmux }

Et… voilà. Oui hein, c’est pas grand chose. Alors oui, tu peux faire simplement un playbook, sans répertoire ni rien. Sauf que lorsque tu veux ajouter un truc ça devient vite crappy. Alors que là… tu fais un rôle par soft, si ça foire tu sais où chercher, tu commentes ou tu laisses en fonction des machines que tu vises si besoin mais en attendant tu n’as qu’un playbook pour l’installation. Tu peux ajouter tous les softs dont tu as besoin pour ton environnement (Apache/nginx – PHP – PostGreSQL etc…) et les configurer une seule fois… et déployer la même configuration partout.

Après, si toutes les configurations ne sont pas identiques, tu peux aussi jouer avec les variables en fonction de l’host visé… mais bon on y va petit à petit hein

Pour l’update tu peux simplement faire un roles/updates/tasks/main.yml avec :

---

- name: Update packages list
  apt:
  update_cache=yes
  cache_valid_time=3600

- name: Simulate update packages
  apt:
  upgrade: dist
  check_mode: yes
  register: output_s

- name: Check changes
  set_fact:
  update_need: true
  when: not output_s.stdout | search("0 upgraded, 0 newly installed")

- name: update apt cache
  apt:
  update_cache=yes
  cache_valid_time=3600
  tags: update_apt_cache

- name: upgrade all packages
  command: apt-get upgrade -y
  tags: upgrade_packages
  when: update_need is defined and update_need == true

- name: upgrade linux kernel
  apt:
  upgrade: dist
  register: output
  tags: upgrade_linux_kernel

- name: autoremove obsolete packages
  apt:
  autoremove: yes
  tags: auto_remove_packages

- name: clean
  apt:
  autoclean: yes
  tags: clean_packages
Et modifier ton playbook de la sorte :

---

- hosts: "{{ target }}"
  user: username
  become: true
  become_method: sudo

roles:
  - { role: tmux }
  - { role: updates }

Et tu peux bien évidemment faire la même avec un reboot par exemple… et tout ce que tu veux.

Attention toutefois à bien respecter la structure et les espaces, sinon le playbook risque de crasher et tu vas perdre des heures à comprendre pourquoi…

En espérant qu’Ansible te sera moins obscure à présent.

Et comme toujours, si tu as des questions, tu sais où me trouver

The post Ansible : et si on commençait ? appeared first on Hackorn.

Allay on va commencer par le commencement. Il y a quelques temps j’avais pas mal galéré pour faire un preseed complet.

C’est chose faite.

Le playbook (qui passe par la console de management) va forcer le serveur à boot sur l’ISO au prochain boot, reboot le serveur, qui va donc boot sur l’ISO d’installation… avec le preseed. Et ensuite l’installation se fait toute seule. Tranquille, pépouze.

Bon ok, tu n’as rien compris. Je pars du principe qu’on installe une Debian ici, vu que c’est ce que j’utilise pour mes serveurs.Un fichier de preseed est un fichier que tu vas charger pendant l’installation et qui va répondre à ces questions qui te font perdre un temps précieux, surtout si tu dois installer 15 ou 20 serveurs. L’installation sera lancée et se fera toute seule, sans intervention humaine (sauf si ça plante, parce que oui, des fois ça marche pas).Pour savoir comment renseigner le preseed, il vaut mieux faire déjà une installation de base, noter les réponses que l’on souhaite, puis construire le preseed avec ce qu’on veut.Pour faciliter les choses et ne pas avoir à renseigner ce preseed (qui serait une intervention humaine), l’ISO sera regénérée avec le preseed.il vous faut donc un fichier de preseed configuré avec Amour et bien entendu votre ISO.

Je vous glisse le fichier de preseed que j’ai plus ou moins utilisé.

!!! ATTENTION !!!

Le fichier de preseed doit servir de base uniquement. Vous devez l’adapter à VOTRE environnement. J’ai retiré ce qui était trop spécifique au mien.

### Localization
# Preseeding only locale sets language, country and locale.
# d-i debian-installer/locale string fr_FR.UTF-8
d-i debian-installer/locale string fr_FR.UTF-8

# Keyboard selection.
# Disable automatic (interactive) keymap detection.
d-i console-setup/ask_detect boolean false
d-i keyboard-configuration/layoutcode string fr_FR.UTF-8

d-i debian-installer/language string fr
d-i debian-installer/country string FR
d-i debian-installer/locale string fr_FR.UTF-8
d-i keyboard-configuration/xkb-keymap select fr(latin9)

### Network configuration
# netcfg will choose an interface that has link if possible. This makes it
# skip displaying a list if there is more than one interface.
d-i netcfg/choose_interface select auto

# Just in case our DHCP server is busy.
d-i netcfg/dhcp_timeout string 60

# Any hostname and domain names assigned from dhcp take precedence over
# values set here. However, setting the values still prevents the questions
# from being shown, even if values come from dhcp.
d-i netcfg/get_hostname string unassigned-hostname
d-i netcfg/get_domain string unassigned-domain

# Added by @analytically: always install the server kernel
d-i base-installer/kernel/override-image string linux-server

### Mirror settings
d-i mirror/country string manual
d-i mirror/http/hostname string ftp.fr.debian.org
d-i mirror/http/directory string /debian

### Clock and time zone setup
# Controls whether or not the hardware clock is set to UTC.
d-i clock-setup/utc boolean true

# You may set this to any valid setting for $TZ; see the contents of
# /usr/share/zoneinfo/ for valid values.
d-i time/zone string Europe/Paris

# Controls whether to use NTP to set the clock during the install
# d-i clock-setup/ntp boolean true
# d-i clock-setup/ntp-server string NTP SERVER 

### Partitioning
d-i partman-auto/disk string /dev/sda

d-i partman/early_command string [ -b /dev/sda ] && dd if=/dev/zero of=/dev/sda bs=1024 count=1024 | | true

d-i partman-auto/purge_lvm_from_device boolean true
d-i partman-lvm/device_remove_lvm_span boolean true

#Set force UEFI to true - Attention
d-i partman-efi/non_efi_system boolean true

# The presently available methods are:
# - regular: use the usual partition types for your architecture
# - lvm: use LVM to partition the disk
# - crypto: use LVM within an encrypted partition
d-i partman-auto/method string lvm

# If one of the disks that are going to be automatically partitioned
# contains an old LVM configuration, the user will normally receive a
# warning. This can be preseeded away...
d-i partman-lvm/device_remove_lvm boolean true
# The same applies to pre-existing software RAID array:
d-i partman-md/device_remove_md boolean true
# And the same goes for the confirmation to write the lvm partitions.
d-i partman-lvm/confirm boolean true

# For LVM partitioning, you can select how much of the volume group to use
# for logical volumes.
#d-i partman-auto-lvm/guided_size string max

# You can choose one of the three predefined partitioning recipes:
# - atomic: all files in one partition
# - home: separate /home partition
# - multi: separate /home, /usr, /var, and /tmp partitions
d-i partman-auto/choose_recipe select multi

# If you just want to change the default filesystem from ext3 to something
# else, you can do that without providing a full recipe.
d-i partman/default_filesystem string ext4

# This makes partman automatically partition without confirmation, provided
# that you told it what to do using one of the methods above.
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
d-i partman-lvm/confirm boolean true
d-i partman-lvm/confirm_nooverwrite boolean true

### Base system installation
### Account setup
# Alternatively, to skip creation of a normal user account.
d-i passwd/make-user boolean true
# Skip creation of a root account (normal user account will be able to
# use sudo).
d-i passwd/root-login boolean false

# The installer will warn about weak passwords. If you are sure you know
# what you're doing and want to override it, uncomment this.
d-i user-setup/allow-password-weak boolean true

#d-i passwd/root-password password changeme
#d-i passwd/root-password-again password changeme

# Set to true if you want to encrypt the first user's home directory.
d-i user-setup/encrypt-home boolean false

# To create a normal user account.
# d-i passwd/user-fullname string USERNAME
# d-i passwd/username string USERNAME
# d-i passwd/user-password-crypted password PASSWORD
# d-i passwd/user-uid string UID

### Apt setup
d-i apt-setup/non-free boolean true
d-i apt-setup/contrib boolean true
tasksel tasksel/first multiselect standard, ssh-server

# Verbose output and no boot splash screen
d-i debian-installer/quiet boolean false
d-i debian-installer/splash boolean false

### Boot loader installation
# This is fairly safe to set, it makes grub install automatically to the MBR
# if no other operating system is detected on the machine.
d-i grub-installer/only_debian boolean true

# This one makes grub-installer install to the MBR if it also finds some other
# OS, which is less safe as it might not be able to boot that other OS.
d-i grub-installer/with_other_os boolean false

# Wait for two seconds in grub
d-i grub-installer/timeout string 2

d-i grub-installer/bootdev string /dev/sda

### Finishing up the installation
# Avoid that last message about the install being complete.
d-i finish-install/reboot_in_progress note

Après ça vous avez une install de base normalement avec le ssh. Il suffit ensuite de lancer un second playbook pour finir l’install avec les softs et les confs que vous voulez. Je ferai sans doute un post avec un playbook de base Ansible. Si tu n’as strictement rien compris à ça (et si ça t’intéresse), je te propose un peu de lecture : 

• Le principe de preseed
• Ansible (anglais)
• Mais tu peux aller comprendre le principe encore ici pour savoir si ça correspond bien à ton besoin.

Et si tu as des questions, comme d’habitude, n’hésite pas

The post Tu prendras bien un petit preseed ? appeared first on Hackorn.