7

vendredi 18 mai 2018

Le rechaufement climatique et les e-mail

Au moment ou j'ai voulu rédiger cette article, je me suis dis, "tien me faut une image avec un ecolo super chiant", comme j'ai pas trouvé ...

Notre écolo super chiant c'est lui, un peut d'imagination.

Bon alors, c'est quoi ton problèmes avec les mails, mec!
J'ai pas de problèmes avec eux moi, mais la population ecolo est généralement faché contre eux. Surtout contre Gmail, comme si il n'y avait qu'eux a conserver des données inutiles et a fournir un service e-mail ...
Ba wé quoi, ce sont des con, ils utilise de l'énergie pour garder mes spam ...
Non non non non non ... mais oui.


Il y a effectivement de gros problèmes de consommations de ressources avec les e-mail, quand on regarde les chiffres donné par arobase.org (on vas les croire sur parole, leurs source radicati.com proposant son rapport pour 2500$ ...) on peut constater que le trafique est énorme et qu'il ne va pas baisser demain.

Je ne doute pas du fait que les géants du web aient réfléchies a comment y remédier, mais cela nécessiterais probablement un changement de vos habitudes et de renoncer au flicage, pour ex sur mon serveur e-mail, temps qu'un e-mail n'est pas rangé dans un dossier il est considéré comme a supprimer, et après 7jours d’existence il l'est effectivement.

C'est une méthode vraiment simple et efficace pour ne conserver que l'utile, mais qui implique que chacun soit responsable de sa communication, si vous ne rangez pas un message important il est supprimé c'est votre faute, alors que pour le moment un message perdu il est possible de mettre ça sur le dos de votre fournisseur mail.

Je me demande donc si les utilisateur sont prêt a assumer leurs responsabilité. A cette question il me semble que non, l'utilisateur reprochant a google d'utiliser de la place pour des e-mail poubelle, n'est pas pret a entendre qu'il est responsable de la place utilisé du fait qu'il ne prenne pas la peine de triller.

En ceci je trouve mon approche meilleur. J'ai la flemme de triller, mais en sachant que je risque de perdre des e-mail important je prend la peine d'archiver ce que je veux garder. Vient aussi qui est plus simple et rapide d'archiver 2mail que de devoir en supprimer 10 par jours.


Alors utilisateur, prends garde et abstiens toi de critiquer, supprime ce qui n'a pas d'utilité, car un jour, la main tu te verra forcé, et comme un benêt tu seras, face a tes e-mail supprimé. (ou alors on raseras peut être ton village pour un nouveau data center)



Je n'ai pas l’habitude d'écrire ce genre d'article, mais par moment il y en a qui ont vraiment le dons de vous courir sur le haricot :')



éa, les amis.

vendredi 11 mai 2018

[Scaleway] Avoir un OpenBSD (ou autre) sur les serveurs Scaleway

Moi: Vous savez quoi?
Vous: nan, mais tu vas nous le dire !
Moi: En serveur, je préfère grandement un OpenBSD a un Gnu/Linux
Vous: Et pourquoi donc ?
Moi: Pour pleins de raisons, comme son PF, HTTPD, SMTPD ...
Vous: Moué, enfin SMTPD il est aussi sur d'autres os, puis OpenBSD est pas disponible de base, et les solutions trouvé jusque là sur le net sont pas pratiques, et c'est compliqué et blabla bla ...

Je suis pas aussi confiant que Barney pour le coup ...

[Musique de Rocky]

But:
  • Installer un OpenBSD sur les serveurs x86 de chez scaleway
  • Pouvoir contrôler l'Os depuis l'interface scaleway
  • Ne pas devoir passer par une manipe manuel a chaque boot
  • Pouvoir en faire une image prés config a déployer
  • Que ça tourne sur les x86 des gammes Start/BareMetal/Pro
* C'est la win
** C'est la loose pour le moment
Observations:
  • Avec "fdisk -l" on constate une partions EFI
  • Sans OS sur le disque, le serveur "hard reboot" puis passe en mode off
  • En écoutant le port 80 au boot on peut surprendre une discutions avec 169.254.42.42
    • xxx IP xxx > 169.254.42.42.http: Flags [P.], seq 1225680221:1225680383, ack 1681506505, win 229, options [nop,nop,TS val 6113219 ecr 329066878], length 162: HTTP
      E...".@.@...
      .B...**.z.PI.e]d9......!......
      .]G...)~PATCH /state HTTP/1.1
      Host: 169.254.42.42
      User-Agent: curl/7.52.1
      Accept: */*
      Content-Type: application/json
      Content-Length: 26

      {"state_detail": "booted"}
    • 17:13:11.459660 IP 169.254.42.42.http > xxx: Flags [P.], seq 1:164, ack 162, win 235, options [nop,nop,TS val 329067003 ecr 6113219], length 163: HTTP: HTTP/1.1 200 OK
      E.....@.;.4...**
      .B..P.zd9..I.e............
      ..)..]G.HTTP/1.1 200 OK
      Server: Tengine
      Date: Tue, 08 May 2018 17:13:11 GMT
      Content-Type: text/plain
      Content-Length: 20
      Connection: keep-alive

      STATE_DETAIL=booted
  • Avec un petit grep -rn on trouve un script contenant "state_detail" nomé scw-signal-state
Solution:
  1. Créer un serveur x86 64 avec un volume 50G pour OpenBSD
  2. Installer qemu et Dl miniroot**.fs
  3. New VM miniroot**.fs et en utilisant le volume prévus
    qemu-system-x86_64 -curses -drive file=miniroot**.fs -drive file=/dev/vdb -net nic -net user
  4. Installer OpenBSD comme vous voulez, sauf pour: 
    • IPv4 address for em0? (or 'dhcp' or 'none') [dhcp]
    • Change the default console to com0? [no] yes (Pour utiliser la console en ligne)
    • Which disk is the root disk? ('?' for details) [wd0] wd1
    • Use (W)hole disk MBR, whole disk (G)PT or (E)dit? [whole] G (Partition GTP pour EFI)
    • Installez BSD.mp affin d'étre en kernel MultiProcessor (il fonctionne aussi en sigle core) 
    • A la fin de l'install, copier la hostname pour l'interface vio0 (nom de l'interface des vps sous OpenBSD)
      # cp /etc/hostname.em0 /etc/hostname.vio0
  5. Quand c'est fini on éteins tout, on fait un snapshot du volume et création d'un nouveau serveur avec ce snapshot
  6. /*ATTENTION le serveur hard reboot après quelques minutes temps que l'on send pas la validation, pour finir en erreur */
  7. Une fois le serveur boot, il faut installer curl (et wget d'apres moi), puis mettre en place le script scw-signal-state (j'ai hébergé les script, car je ne les ai pas trouvé en ligne)
  8. Vous pouvez éteindre le serveur et openBSD afin de faire un snapshot stable.
- Si le signal n'est pas envoyé, peut étre que votre PATH est mal renseigné, un petit "whereis curl" afin de vérifier ça.
- Si il est impossible de résoudre les nom de dommaines, modifiez votre /etc/resolv.conf en ajoutant par ex le name serveur de google 8.8.8.8. Le temps de fixer ça plus tard

A ce moment là vous pouvez réaliser une image d'installation dans votre interface avec le snapshot précédemment crée.

Vous trouverez ici : https://git.iglou.eu/NonIgImport/Scaleway-scripts/tree/master le repos ou j'ai upload deux script scw-*, celui qui send le "booted" et un autre qui vous renvois toutes les informations relatives au serveur. J'ai aussi mis une version modifié de scw-signal-state, qui fait un loop temps qu'elle n'a pas put effectué l'envoi du signal, car j'avais de temps en temps un signal envoyé avant que le serveur soit connecté.

Et ça ne fonctionne que sur la gamme start, donc un petit fail quand même !


Pour les serveurs BareMetal et Pro, n'ayant pas la possibilité d’accéder au local boot, grub ou iPXE ... C'est pas gagné. Mais je reste en recherche !

Rien ne devrais empêcher cette "technique" de fonctionner avec n'importe quel Os.

Si vous avez des question, ou des améliorations a me proposer, je reste disponible :)


éa, les amis.