SChauveau a écrit 389 commentaires

Je suppose que cela permet d'accéder à une même IP avec plusieurs noms. il faut savoir que dans une requête HTML (entre autre), le serveur web n'utilise pas l'IP mais le nom pour décider quel site web il soit afficher. Cela permet à plusieurs sites webs de partager la même IP.

Je connais 4 autres façons d'associer rapidement un nom à une IP sans avoir à attendre la propagation mais chacune avec ses avantages et inconvénients.

La première est évidemment d'avoir son propre serveur DNS sur le réseau local pour définir des alias. Si vous êtes chez vous, il est probable que votre 'box internet' puisse faire cela.
La seconde est d'ajouter des entrées dans /etc/hosts (voir man 5 hosts). Il faut être root mais cela marche toujours.
La 3eme est d'utiliser HOSTALIASES (voir man 7 hostname) mais cela ne marche pas toujours bien.
La 4ieme est d'utiliser LD_PRELOAD pour redefinir gethostbyname() et autres fonctions systèmes (l y a plein d'exemples sur le net. Par exemple http://www.wensley.org.uk/c/libdivert.c )

La cubietruck (ou cubieboard3) semble être à 79$ en ce moment. C'est la cubieboard4 qui est à 199$

Cela reste quand même sensiblement plus cher qu'un R.Pi

Je ne m'y connais pas vraiment en USB et en SATA mais doute que le CPU soit totalement en charge des transferts. Il y a probablement des mécanismes de DMA qui permettent d'accéder directement à la mémoire sans utiliser le CPU. En gros, cela signifie qu'il doit être possible de saturer un lien USB2 même avec un CPU très lent si les paquets de donnée à transférer sont gros (du genre un flux vidéo). Par contre, le CPU sera beaucoup plus stressé si le protocole USB consiste en de multiples petit paquets.

Non! La version Wayland de systemd-emacs

VIM et Emacs sont tout deux très puissants mais difficile d'accès. Une fois que l'on a acquis quelques mois ou années d'expériences avec l'un, la difficulté inhérente à apprendre l'autre ne se justifie pas vraiment.

C'est rigolo. Moi j'utilise emacs car la première fois que je suis arrivé sous vim je n'ai réussi ni à insérer le texte que je désirais, ni à bouger le curseur et encore moins à sauver le résultat.

Pour info, pour quitter emacs il suffit de faire
ESC-! killall emacs

Les brocolis ne sont pas des Légumes. Ce sont des Saletés :-)

Je n'ai pas retrouvé de lien mais il y a quelques (dizaines d'?) années, un chercheur a codé un exemple de backdoor dans les sources d'un compilateur. Ce backdoor détectait la compilation d'un programme spécifique pour y insérer une autre backdoor (par exemple dans OpenSSH server). L'idée géniale est que la backdoor du compilateur était également capable de détecter la compilation du compilateur lui même pour se réinsérer dans le binaire.

En pratique, cela signifie que si une version binaire du compilateur avec backdoor pouvait être inséré dans une distribution alors toutes les versions suivantes du compilateur auront aussi la backdoor même si les sources de ceux ci sont propres. L'inspection des sources ne sert alors à rien.

Si on pousse le concept plus loin, la backdoor pourrait se trouver dans le binaire de quasiment n'importe quel outils utilisé pour programmer (compilateur, assembleur, linker, make , bash, editeur, …). La seule façon de faire un OS propre serait alors de créer son propre processeur et mémoires avec des transitors soudés à la main.

Sur Debian, dpkg conserve le checksum de tout les fichiers installés.
Le programme debsums permet de les vérifier

# debsums openssh-server
/lib/systemd/system/ssh.service                                               OK
/lib/systemd/system/ssh.socket                                                OK
/lib/systemd/system/ssh@.service                                              OK
/usr/lib/tmpfiles.d/sshd.conf                                                 OK
/usr/sbin/sshd                                                                OK
/usr/share/apport/package-hooks/openssh-server.py                             OK
/usr/share/doc/openssh-client/examples/sshd_config                            OK
/usr/share/lintian/overrides/openssh-server                                   OK
/usr/share/man/man5/sshd_config.5.gz                                          OK
/usr/share/man/man8/sshd.8.gz                                                 OK

Mais comme indiqué dans un post précédent, si le root du serveur se fait hacker alors debsum ou les fichiers contenant les checksums pourront aussi être modifiés.

Une vérification depuis un serveur externe est plus sûre mais même alors il sera difficile de s'assurer que le transfert d'information est sain.

La solution la plus robuste consiste probablement à effectuer ces vérifications dans une VM depuis son hyperviseur.

Je pensais qu'on essayais toujours d'avoir une compatibilité ascendante. Dans ce cas-là, s'agit-il d'une erreur ? Ou vraiment un pc compatible avec une version X du noyau pourrait ne plus être reconnu par la version X+1 du noyau ?

La mise en veille est un problème complexe. Les constructeurs de portables implémentent des solutions plus ou moins foireuses en ne considérant en général que Windows pour lequel ils fournissent si nécessaire des pilotes corrigeant les bugs de leur BIOS. Le noyau Linux doit donc essayer de résoudre de la façon la moins pénible possible des dizaines ou centaines de cas particuliers.

Dans ces conditions, il n'est pas vraiment surprenant que des régressions se produisent fréquemment sur la mise en veille. On peut par exemple imaginer ce genre de scénario:

(1) Sortie d'un modèle de portable A1
(2) Ajout de la mise en veille pour A1
(3) Sortie du modèle A2. La mise en veille de A1 fonctionne correctement sur A2.
(4) Sortie du modèle A2b qui est une variante de A2.
La mise en veille (2) ne fonctionne pas correctement sur A2b.
(5) Ajout de la mise en veille pour A2b.

Malheureusement, le noyau décide de l'utiliser aussi pour A2 qui ressemble beaucoup à A2b.

==> Régression pour tout les utilisateurs de A2.

Dans cet exemple, la difficulté est que les développeurs de Linux n'ont jamais eu connaissance du modèle A2.

J'ai remarqué un bug en cas de completion non-existante( xxx est complété en xxx* ). La version suivante résout ce problème

function _ccd() {
    local cur prev opts
    cur="${COMP_WORDS[COMP_CWORD]}"    
    COMPREPLY=( $(shopt -s nullglob; echo $HOME/.signet/save${cur}* ) )
    COMPREPLY=( ${COMPREPLY[@]#$HOME/.signet/save} ) 
    return 0
}

complete -F _ccd ccd

Voici une version possible de la completion BASH pour la commande ccd de l'article ci-dessus.

function _ccd() {
    local cur
    cur="${COMP_WORDS[COMP_CWORD]}"    
    COMPREPLY=( $HOME/.signet/save${cur}* )
    COMPREPLY=( ${COMPREPLY[@]#$HOME/.signet/save} ) 
    return 0
}

complete -F _ccd ccd

ou ceci

find "$MARKPATH" -maxdepth 1 -type l -printf "%-15f -> %l\n"

Ta commande marks est effectivement un peu trop complexe et pas très robuste. Chez moi cela marche pas. Je pense que le 1er sed devrait être 's/ */ /g'

Quelque chose comme cela serait probablement plus élégant (en bash):

for i in $MARKPATH/* ; do    
  printf "%-10s -> %s\n" "$(basename "$i")" "$(readlink "$i")"; 
done | sort

Je suis surpris que personne n'ai mentionné CDPATH.
Il s'agit d'une variable d'environnement similaire à PATH, mais qui indique à 'cd' où chercher le dossier destination.

Je m'aperçois que ma macro n'est pas résistante aux espaces dans les noms de dossier. Honte sur moi!

 function @ () {
  local DIR HERE DEST
  DIR="$PWD"
  HERE="$PWD/"
  DEST=
  while [[ "$DIR" != "/" ]] ; do 
    if [ -L "$DIR/.at" -a -d "$DIR/.at" ] ; then 
      DIR2="$(readlink -n "$DIR/.at")"
      cd "${HERE/#$DIR/$DIR2}"
      return 
    fi
    DIR="$(dirname "$DIR")" ;
  done
  echo "*** unmanaged directory (symlink '.at' not found) ***"
}

Pour ceux intéressés

#
# Toggle between directory structures with similar hierarchies.
#
# The root of each directory structure must contain a symbolic link '.at' 
# pointing to the root of the other directory. 
# 
# IMPORTANT: Both symbolic links must be absolute (/udd/bob/foo but not ../foo)
#
# Example: 
#
#  Consider two directories /udd/bob/work and /udd/scratch/work with identical 
#  structured (as created by a typical 'configure' script) 
# 
#  cd /udd/bob/work ; ln -s /udd/scratch/work .at
#  cd /udd/scratch/work ; ln -s /udd/bob/work .at
#
# Then you can do things like that:
#
#  cd /udd/bob/work/src/lib 
#  edit myfile.c
#  @                            -> equivalent to 'cd /udd/scratch/work/src/lib'
#  make                           
#  @                            -> equivalent to 'cd in /udd/bob/work/src/lib' 
#  edit myfile.c 
#
#
function @ () {
  local DIR HERE DEST
  DIR=$PWD
  HERE="$PWD/"
  DEST=
  while [[ "$DIR" != "/" ]] ; do 
    if [ -L $DIR/.at -a -d $DIR/.at ] ; then 
      DIR2=$(readlink -n $DIR/.at)
      cd ${HERE/#$DIR/$DIR2}
      return 
    fi
    DIR=$(dirname $DIR) ;
  done
  echo "*** unmanaged directory (symlink '.at' not found) ***"
}

Si vous êtes programmeur, vous connaissez certainement l'astuce consistant à séparer le dossier de 'build' du dossier contenant les sources. Cela évite de polluer celui ci avec tout un tas de fichiers inutiles pour SVN, GIT, …

Les systèmes de build permettant cela vont en général créer un clone de la hiérarchie de dossiers sources. Se pose alors le problème de passer rapidement d'un dossier à un autre ; par exemple de …/src/xxx/yyy/zzz/ à …/build/xxx/yyy/zzz et inversement.

Au boulot, j'ai une macro '@' pour cela (si! si! c'est legal en bash).
Je suis entre 2 jobs donc mon bashrc est archivé. Je peux le retrouver ci cela intéresse quelqu'un (mais la macro n'est pas non plus très difficile à coder)

L'idée est qu'il suffit de créer une paire de liens symboliques pour associer les
racines des deux dossiers src et build
…/src/.at -> …/build
…/build/.at -> …/src

La macro @ explore récursivement le dossier actuel et ses parents à la recherche d'un lien .at et saute alors au sous dossier correspondant.

Par exemple, @ depuis …/src/xxx/yyy/zzz/
- pas de …/src/xxx/yyy/zzz/.at
- pas de …/src/xxx/yyy/.at
- pas de …/src/xxx/.at
- trouve …/src/.at -> …/build/
donc 'cd ../build/xxx/yyy/zzzz'

Et cela marche évidemment dans les 2 sens et c'est vraiment très pratique.

C'est pas celui ou ils sont dans un char en chute libre et ils tirent vers le sol pour ne pas s'écraser?

Une information que je trouve très intéressante dans cette page est que

There are basically two ways to do key exchange: Diffie-Hellman and Elliptic Curve Diffie-Hellman. Both provide forward secrecy which the NSA hates because they can’t use passive collection and key recovery later. The server and the client will end up with a shared secret number at the end without a passive eavesdropper learning anything about this number.

En pratique, cela signifie qu'il y a une double sécurité: la clef ssh et un échange de secrets (un peu comme dans SSL).

Même si la NSA (ou autre) enregistre vos communications ssh et casse votre magnifique clef 4096 bits d'ici quelques années, ils ne seront pas capable de décoder les enregistrement.

Indirectement, cela implique que le décodage en temps réel n'est pas possible même si ils connaissent votre clef ssh.

Bien sur, dans ce cas, une attaque de type man-in-the-middle reste toujours possible et ils peuvent se connecter à votre place pour installer des programmes espions sur vos serveurs.

Merci

fail2ban est très bien mais j'hésite à l'installer.
Je me suis déjà fait interdire de mon propre serveur (pour seulement 48H heureusement) alors que je testais une installation de svn+ssh
On ne rigole pas! merci

La sécurité est toujours une affaire de compromis: La sécurité optimale consiste à garder les serveurs éteints, non connectés à Internet et dans une cage de Faraday mais bon … c'est pas super pratique.

… je conseille de lire cette page:

https://stribika.github.io/2015/01/04/secure-secure-shell.html

Après, je ne garantie pas que ces informations ne sont pas un plan machiavélique de la NSA pour accéder à votre collection de film por^ H^ H^ H coquins.

Quoi qu'il en soit, cette page a le mérite de montrer que c'est un problème complexe.

ps: Je n'ai pas trouvé l'astuce pour faire des ^ H correct :-(

D'un autre coté, l'auteur de l'article aurait pu ajouter -N "" pour éviter l'erreur.

J'avoue que j'ai été un peu surpris quand le pop-up de passphrase s'est ouvert (outre le fait que je déteste les applications shell qui ouvrent un popup X11).