kna a écrit 759 commentaires

C'est un cercle vicieux. À partir du moment où tu es dans une situation trop contraignante pour utiliser uniquement transports en commun/vélo/pieds, tu te prends une voiture. Et une fois que tu as une voiture, tu es vite tenté de la prendre pour n'importe quel trajet, dès que l'alternative devient un tout petit peu contraignante. Il pleut ? Hop, voiture !
Puis tu n'utilises quasiment plus de transports en commun, donc tu n'as plus d'abonnement, et finalement tu ne les utilises plus du tout.

Qmail, c'était bien il y a 10-15 ans, mais aujourd'hui, c'est juste dépassé.

• ça foire quand le MX renvoie sur un nom trop long (sauf si tu utilises le dnscache du même auteur)
• ça accepte les messages à partir du moment où le domaine existe, puis seulement après, si l'utilisateur n'existe pas, il le rejette et renvoie un message failure notice. Alors dans le principe c'est bien, ça permet d'éviter qu'on puisse checker qu'une adresse existe, mais en pratique, tu reçois du spam avec des faux from, tu te retrouves à renvoyer une tétrachiée de failure notice à des adresses inexistantes ou qui ne sont pas à l'origine du spam. Tu as une mailqueue remplie et tu te fais cataloguer comme spammeur
• faire des services modulaires et des conf éclatées, c'est bien, mais quand tu pousses à l'extrême au point d'avoir un fichier par paramètre de conf, et un programme qui ouvre juste un port pour y brancher un service (tcpserver), ça commence à devenir lourd
• la documentation est pas terrible
• il y a plein de trucs que j'oublie, je n'en utilise plus et ne m'en porte pas plus mal.

Alors en pratique, tu trouveras des patchs pour corriger tous ces petits problèmes. Mais bon, quand on a des alternatives comme postfix/dovecot qui sont complets, maintenus, avec une configuration plutôt bien foutue, bien documentés, et empaquetés dans toutes les distribs ; je ne vois pas d'intérêt à déterrer qmail.

J'avais vu passer un autre exemple d'utilisation de XMPP sur https://linuxfr.org/news/synchroniser-vos-dossiers-locaux-distants

La synchronisation est en fait un script en python qui vérifie les modifications sur le dossier à synchroniser, et exécute :

• un commit
• un push
• l'envoi d'une notification xmpp aux autres clients

Lorsqu'un client reçoit une notification il effectue un pull.

Tu peux monter un volume (fichier ou partition) chiffré dans ton dossier, ou tu peux utiliser encfs.

Voici donc la barre oblique qui, d'un point de vue sémiotique, connote une division mais que l'on utilise une page plus loin sous la forme : « rapport femmes / hommes ».

Un rapport, ou quotient, c'est bien une division. Je ne vois pas le problème ! :-)

Exemple? sauvegarder = joli dessin de disquette, objet obsolète

Pas pour les applis Gnome, où tu as ça :

La commande watch va lancer dmesg en boucle, mais ne rendra jamais la main, du coup la ligne suivante (mkdir) ne sera jamais exécutée.
Une boucle while serait plus appropriée.

Le seul cas d'utilisation du compte Google c'est dans Youtube (je suis un grand fan de vidéos sur les échecs…) pour pouvoir m'abonner.

Tu peux utiliser les flux RSS de youtube sinon, https://www.youtube.com/feeds/videos.xml?user=NOM_DU_COMPTE ou https://www.youtube.com/feeds/videos.xml?channel_id=ID_DE_LA_CHAINE

Sauf si tu veux jouer à des jeux du type dungeonfs pour avoir quand même l'air de bosser :-)

Un serveur une fois installé n'est pas censé nécessiter de la maintenance tous les quarts d'heure sinon c'est qu'il est mal installé.

Alors qu'un desktop c'est un truc de ouf à administrer.

Bref tu n'as aucune idée des sites web qui ne fonctionnent pas ou mal sur ubuntu/debian, ni des bugs lié a X ou Y logiciel, ni des imprimantes pas compatible, etc

Des sites web qui fonctionnent mal sous Firefox ou Chrome ?
Des imprimantes non compatibles dans un environnement Linux ?

S'il faut le temps de le former ou qu'il s'adapte à de l'outillage qu'il n'a jamais touché, c'est une perte de temps (= d'argent) voir une prise de risque (que tu ne t'adaptes pas) que le patron n'a pas toujours les moyens de se permettre.

C'est mignon, mais en dehors du monde des bisounours, un sysadmin qui débarque dans un environnement inconnu, il va mettre un peu temps à s'adapter. Le poste de travail, c'est juste une broutille à côté.

C'est un détail totalement arbitraire, tu ne sais pas ce que la personne que tu recrutes fait avec son PC personnel. Je préfère un mec compétent qui a choisi Windows pour son usage perso pour une raison X ou Y plutôt qu'un mec qui a installé Ubuntu il y a 15 jours.

J'ai plein de collègues qui préfèrent avoir leur poste sous Win, ou qui utilisent MacOS chez eux. Ils sont pas pour autant moins compétents pour l'administration de serveurs Linux.

En plus, juger à partir de leur laptop personnel c'est un pas puéril c'est juste idiot, les gens choisissent leur OS en fonction de leur besoin, leur environnement, leur préférences.
Si le mec veut utiliser son PC pour jouer tu lui refuses le poste ? S'il a un PC fixe, tu lui refuses aussi dans le doute ?

Le plus drôle, c'est que dans l'annonce il y a quand même « Sait administrer une station Windows »…

Autre solution : lancer la VM au démarrage sans affichage (c'est faisable avec qemu/kvm, à voir avec VirtualBox), et lancer l'application en remote app via RDP.

C'est les pièces le problème. On devrait faire des billets de 1 et 2 euros, et garder les pièces uniquement pour les centimes (et encore !)

En milieu pro, quand tu es dans un environement Windows avec ActiveDirectory, Exchange, docs MS Office, imprimantes pas supportées sous Linux, et autres applis propriétaires c'est pas évident.

Pour ma part, j'ai quand même réussi à passer sous Linux au boulot, malgré l'environnement hostile. La seule contrainte qu'on m'a imposé est qu'il soit lié à l'ActiveDirectory. Je m'en suis sorti avec :

• realmd/sssd pour l'ActiveDirectory
• evolution-ews pour Exchange, fonctionnel sauf :
  • la visualisation des contacts (mais l'autocomplétion me trouve bien les contacts quand j'écris un message)
  • les filtres, mais comme j'y touche pas souvent, j'utilise l'interface web (OWA)
  • un des clients m'envoie des demandes de réunion avec un tableau, la mise en forme est un peu en vrac (je m'y fais ou utilise OWA)
• samba pour les shares CIFS
• foomatic pour les imprimantes Canon
• un client XMPP (pidgin) pour la messagerie Cisco Jabber (ça gère juste pas le téléphone, mais la messagerie texte fonctionne)
• rdesktop sur une machine Windows pour MS Office

EDIT; mal lu

Dans sa réponse la ministre indiquait à la parlementaire que « le ministère des Armées n'a connaissance d'aucun élément objectif qui conduirait à écarter Microsoft Irlande de l'attribution de marchés publiques […]

C'est pas mal comme réponse, quand on te reproche de ne pas avoir fait de marché public…

D'autant que sous debian, les certificats du paquet ca-certificates proviennent de… mozilla !

$ apt show ca-certificates
[...]
Description: certificats CA courants
 Ce paquet inclut les autorités de certifications livrées avec les
 navigateurs Mozilla afin de permettre aux applications basées sur SSL de
 vérifier l'authenticité des connexions SSL.
[...]

$ ls /usr/share/ca-certificates
mozilla

Ce qu'ils visent, c'est surtout celui qui ne l'a pas acheté, la majorité des visites sur un site d'e-commerce se terminent sans achat. Du coup, la pub est censée t'inciter à y retourner.

Quand tu dis le lancer au démarrage du serveur graphique, cela veut dire que tu n'as pas de mot de passe sur ta clef ssh ?

Non, je veux dire que je lance ssh-agent au démarrage de X.
Je lance X avec startx, j'ai mis eval $(ssh-agent -s) dans mon ~/.xinitrc. Tout ce que je lance dans ma session X prend alors en compte l'agent.

J'ai aussi un ~/.ssh/config contenant :

AddKeysToAgent yes

Comme ça, il me demande la passphrase à la première connexion, et l'enregistre automatiquement (pas besoin de faire ssh-add).

Quand tu lances ssh-agent ainsi, il renvoie en sortie ce que tu dois exécuter pour que les variables soient prises en compte.

Il faut que tu copies-colles la sortie de ssh-agent, ou que tu lances :

eval $(ssh-agent -s)

Par contre, ça ne sera pris en compte que dans la session en cours. Pour ma part, je le lance au démarrage du serveur graphique pour l'avoir tout le temps.

Pareil, mon rôle ansible :
- créé l'user
- lui génère une clé SSH
- récupère la clé générée, la dépose dans le authorized_keys du serveur git
- clone le repository dotfiles
- créé les liens symboliques

mais aussi :
- installe les paquets essentiels
- pousse le .bashrc de root, et d'autres confs dans /etc (vimrc, screenrc)
- génère un motd avec figlet
- pousse mon lesspipe
- installe un firewall (iptables + fail2ban)
- installe ntpd

Tant qu'on est dans les tops

Hop : 80 linux monitoring tools

atop permet d'enregistrer un « top » régulier dans un log que tu peux lire après.

atop -w rawfile [-a] [-S] [ interval [ samples ]]
atop -r [ rawfile ] [-b hh:mm ] [-e hh:mm ] [-g|-m|-d|-n|-u|-p|-s|-c|-v|-o] [-C|-M|-D|-N|-A] [-f1x] [-L linelen] [-Plabel[,label]...] 

Le --single-transaction, ça fonctionne uniquement lorsque tu est en full-InnoDB. Sinon, ton dump ne va pas être consistent.

Mais le gros problème des dumps, comme dit plus haut, c'est que c'est très lent à réimporter. Sur une grosse base, le temps de restauration se compte en jours !
Une sauvegarde physique (xtrabackup) est beaucoup plus rapide à restaurer. Ça n'empêche pas d'avoir une sauvegarde logique (mysqldump ou mydumper) en plus pour la souplesse que ça procure (backup par base ou par table notamment).

Ne pas suivre les tutoriels qui te font installer tous les anti-machins possibles sans rien comprendre. Commencer par le B.A.BA :

• faire des mises à jour de sécurité régulières sur tous les softs utilisés
• utiliser des mots de passe forts, ou mieux de l'authentification par clé
• faire des backups, mais des vrais (automatiques, réguliers, monitorés, sur site distant, sur machine dédiée inaccessible par les machines backupées, avec tests de restauration réguliers)
• limiter les services qui tournent, s'assurer qu'ils tournent avec des users non privilégiés qui n'ont pas accès aux données des autres services.
• un firewall, en cas de fail sur le point précédent, c'est pas pour ce que ça coûte.

Ensuite, voir ce que tu peux ajouter en fonction :
* de ce que tu héberges (et des risques associés) : un simple blog au contenu public ? des données personnelles ? des sites e-commerce ou autres qui rapporte un peu de sous ? beaucoup de sous ? des secrets industriels ? ;
* de tes compétences ;
* du coût (pour un particulier, il y a des équipements qui coûtent un bras) ;
* des contraintes que tu veux/peux assumer (est-tu prêt à lire un tétrachiée de logs tous les matins, 365 jours/an ? ou juste un rapport automatique ?).

Et te reposer ces questions de temps en temps (au bout d'un an ou deux, tu hébergeras peut-être plus de choses, aura gagné en comptétences, aura plus/moins le temps de t'en occuper).
La sécurité n'est pas le but, elle est le chemin…