Le Blog Utux

Un seul serveur n'était pas suffisant pour moi, j'en ai donc acheté un deuxième. J'ai choisi un NUC6CAYH à 122€. Pour ce tarif on a droit à un mini-PC équipé d'un Intel Celeron J3455 (4@1,5GHz) sans RAM ni disque dur.

J'ai ajouté 8GB de RAM (Kingston KVR16LS11/8 pour 72€) et un disque dur 2,5" de 500GB que je stockais dans un placard. A propos de la RAM, attention car le NUC ne supporte que 8GB maximum et il faut respecter la QVL sous peine d'avoir un warning impossible à désactiver à chaque boot.

Matériel

Comme indiqué précédemment, ce NUC vient avec un Intel Celeron J3455, avec 4 vrais coeurs à 1,5GHz et un turbo boost à 2,3GHz. Le tout contenu dans un TDP de 10W, gravé en 14nm et avec les instructions de virtualisation et quelques features telles que AES-NI. Pour ce prix, et pour un usage modéré, c'est très intéressant. L'ensemble n'est pas fanless, mais grandement silencieux à l'usage.

Peut-on se risquer à parler d'un Raspberry Pi killer? Certainement pas, étant donné la gamme de prix et de matériel complètement différents. Mais il faut constater qu'un usage serveur @home est bien plus envisageable avec ce NUC qu'avec une framboise.

Le boîtier peut s'ouvrir par le dessus ou par le dessous, en retirant 4 grosses vis très accessibles, excellent point :) Par le dessous on accède à la cage du disque dur (2,5") ainsi qu'aux 2 slots de RAM

Il faut aussi noter qu'un kit de fixation vertical est fourni, par exemple pour fixer le NUC derrière un écran. Autre chose, ce mini-PC est assez lourd, vu ses dimensions je m'attendais à quelque chose de plus léger, mais ce n'est pas bien grave.

Système d'exploitation

S'agissant d'une plateforme x86_64 avec support uefi et legacy-bios, on peut se faire plaisir. J'ai pour le moment testé 3 systèmes d'exploitation, orientés virtualisation puisque c'est l'usage que je compte faire de ce NUC.

Rien à signer du côté des performances, ni rapide ni lent pour de la virtualisation, surtout avec un stockage sur disque mécanique. Idéal pour un petit labo ou serveur à la maison avec des VM Linux pouvant se contenter de peu de RAM. Je créé autant que possible mes VM avec une allocation dynamique 128/256MB et un stockage 30GB, ce qui permet d'en faire tourner pas mal simultanément.

Conclusion

Pour le moment je suis plutôt satisfait de ce NUC, même si je regrette la limitation à 8GB de RAM. Il offre un bon rapport qualité/prix pour un serveur @home et le Celeron J3455 se comporte plutôt bien avec des containers et de la virtualisation. Ce petit serveur Proxmox VE va se révéler très utile pour compléter mon NAS sous FreeNAS.

EDIT 01/05/2018: Je rencontre des problèmes avec ce NUC. J'ai défini le boot en "legacy" (non uefi) sur le disque, mais il ne détecte pas d'OS au démarrage et je suis obligé, à chaque fois, de brancher un clavier et utilise le menu pour sélectionner mon disque. Ensuite je rencontre des freezes à peu près chaque semaine, c'est très chiant. Je viens de faire une mise à jour du Bios, on va voir si cela résout les problèmes.

EDIT 29/07/2018: Je ne rencontre plus de freezes ni de problèmes de boot depuis que le bios a été mis à jour :)

Il y a deux ans j'affirmais aimer systemd dans l'article systemd, c'est bien. Aujourd'hui je parle de Firewalld, un service et ensemble d'outils permettant de gérer le pare-feu sous Linux.

La base du firewall sous Linux c'est iptables, et quand on a compris et beaucoup pratiqué, c'est pas si compliqué. Mais il y a toujours deux points qui me gênent:

• Il n'y a pas de service officiel pour charger les règles au démarrage, il faut faire son propre script ou en emprunter à droite à gauche.
• Les règles sont quand même indigestes et bas niveau, ce qui n'est pas toujours nécessaire.

Firewalld implémente un système de "zones" dans lesquelles vous allez définir des paramètres, autoriser des services: internet, public, dmz... elles peuvent être définies à partir de l'interface ou de la source, c'est assez souple. Le paramétrage se fait soit en cli (firewalld-cmd) soit graphiquement (firewall-config) ou encore au travers d'une api et introduit la notion de "permanent" pour savoir si il faut conserver les modifications au démarrage.

Bien entendu, firewalld est un service système donc il n'y a pas de script à écrire pour charger ses règles au boot, il suffit de l'activer dans sytemd.

Firewalld est présent sur Fedora, CentOS, RedHat mais peut être installé sur d'autres sytèmes comme Debian car il est proposé dans les dépôts. Et moi, je migre mes serveurs sur Firewalld avec prise en charge par Ansible, parce que je gagne un temps fou et je fais les choses proprement.

Merci Red Hat ces logiciels qui terminent en "d" et qui modernisent un peu Linux :)

Je note un comportement assez désagréable depuis quelques temps. Le fait de simplement ouvrir le store Microsoft sur mon BallmerPhone Lumia 950 provoque une chauffe excessive et un vidage rapide de la batterie. En moins de 2h je passe de 100% à 20-30%. En fait l'appareil est tellement chaud qu'on pourrait le mettre dans un RTG à la place du plutonium (au moins ça réchauffe les doigts). Même quand je reboote le smartphone ça continue, et c'est pénible. Il s'est éteint la nuit dernière et ne m'a donc pas réveillé le matin... heureusement le chat l'a fait.

Il est difficile de trouver de l'aide sur le web car:

• Il y a de moins en moins d'utilisateurs de Windows Phone, donc on tombe souvent sur de vieux topics de 2014.
• Beaucoup de résultats peu pertinents qui concernent Windows sur desktop.
• Résponses inutiles du genre: vérifie tes applications en arrière plan, regarde le gestionnaire de consommation de batterie (qui ne dit rien d'utile), blablabla.

Mais il y a toujours de l'espoir et je suis tombé sur ce topic: Lumia 950 heat and battery drain. En fait c'est bien lié au Store Microsoft qui a des applications en cours de téléchargement ou de mise à jour dans un état bloqué. Et apparemment chez Microsoft les timeout ça n'existe pas, l'appareil va essayer de télécharger jusqu'à la mort. Donc il faut lister les téléchargements en cours et les stopper quand c'est possible. On essaie 10x puis on reboote et ça fini par fonctionner.

Quand on voit la merde qu'est Windows Update sur desktop et les problèmes que rencontrent les Lumia on se dit quand même que Microsoft et les mises à jour c'est toujours pas ça.

Article pense-bête. J'écris un petit rôle pour configurer firewalld, en gros je veux spécifier quelles interfaces et quels services il faut ajouter dans les zones. Mon idée c'est de définir tout ça dans un dictionnaire dans le playbook, et ensuite de récupérer les élements et sous-élements dans le rôle.

Voici ce que ça donne:

# install.yml

- hosts: nas

  roles:
    - nfs-server
    - firewalld

  vars:
    firewalld_zones:
      - zone: internal
        interfaces:
          - eth0
        services:
          - mountd
          - nfs
          - rpc-bind

  - name: Define zones for interfaces
    firewalld:
      zone: "{{ item.0.zone }}"
      permanent: true
      immediate: true
      interface: "{{ item.1 }}"
      state: enabled
    with_subelements:
      - "{{ firewalld_zones }}"
      - interfaces

  - name: Allow services for zones
    firewalld:
      zone: "{{ item.0.zone }}"
      permanent: true
      immediate: true
      service: "{{ item.1 }}"
      state: enabled
    with_subelements:
      - "{{ firewalld_zones }}"
      - services

Mouais. C'est quand même loin d'être clair ou évident. Mais c'est le seul moyen que j'ai trouvé pour le moment. Si quelqu'un connaît une méthode plus propre/lisible je suis preneur.