kna a écrit 761 commentaires

On pourrait ajouter :
* inverser source et destination avec rsync --delete ou dd
* taper mkfs au lieu de fsck

Je ne sais pas ce qu'il faut (ne pas avoir) pour ne pas comprendre!

Un public ?

L'exemple de Radiohead prouve autant que le crowdfounding fonctionne que Dan Brown ou Picasso prouvent qu'un écrivain ou un peintre peuvent vivre de leur art…

Les autres, ben ils vont là où ils peuvent avoir de la visibilité. Alors oui, certains s'en sortent (et même mieux) en dehors des circuits classiques, mais ça reste plus l'exception que la règle.

Pour éviter qu'un utilisateur puisse mettre un faux service en écoute sur le port et capturer mots de passe et autres joyeusetés.

Je concède qu'en pratique, ça s'avère assez difficile :
* il y a normalement déjà le vrai service en écoute, donc le port sera occupé (à moins de trouver un moyen de le stopper, ou d'attraper une fenêtre ou il redémarre) ;
* il n'a pas accès aux clés du serveur, donc le client renverra une alerte si ce n'est pas sa première connexion.

Je soutiens l’adoption de l’écriture inclusive pour sa portée symbolique, c’est un signe d’ouverture vers le sexe oppressé, qui permet de rappeler que les femmes sont là et que les deux sexes comptent autant l’un que l’autre. Ce n’est pas ça qui réglera le problème des inégalités salariales même si ça ne peut qu’aller dans ce sens.

Ben si c'est si important pour toi, tu prends la peine de tout écrire, par exemple : les lecteurs et les lectrices sont perturbés par le point-médian. C'est français, c'est lisible, et personne ne s'en plaint.

Il est clair que c'est gens qui essayent de se connecter en ssh non?

Oui. C'est commun sur un serveur SSH accessible publiquement, généralement des bots.

Assures-toi simplement d'utiliser des bons mots de passe, ou mieux, d'autoriser uniquement l'accès SSH avec une clé.

Pour éviter de pourrir tes logs, tu peux :
- firewaller le port SSH pour autoriser certaines adresses ;
- bloquer les adresses qui font trop d'auth fail avec par exemple fail2ban ;
- changer le port d'écoute de SSH - je conseille quand même de rester sur un port privilégié (<1024) ;
- faire du port knocking.

Il m'est arrivé de bosser dans de grosses structures où une bonne partie des adminsys sont des personnes qui ont passé l'âge de vouloir suivre "la mode technologique".

Entre suivre la dernière mode et être à la ramasse il y a un fossé.

Je veux bien que le passage à systemd ne soit pas inné et demande de changer quelques habitudes, mais de là à dire que ça coute énormément de formation ou qu'il faille réapprendre tout le métier de sysadmin, ça me parait beaucoup exagéré quand même…

Puis c'est pas comme si avant on avait Sys-V openrc, daemontools, supervisord, runit, upstart…

Le -delete devrait tout de même être plus rapide, jouer avec xargs/parrallels peut néanmoins être intéressant pour limiter la charge : https://web.archive.org/web/20130929001850/http://linuxnote.net/jianingy/en/linux/a-fast-way-to-remove-huge-number-of-files.html

• >> Une entreprise par définition, c'est publique.

Un site web… Aussi. Donc?

Euh, pas forcément non…
Tu peux utiliser ton nom de domaine pour héberger du mail, des dépots git privés, du owncloud/seafile, des applis web à usage privé (kresus par exemple), etc.

Par ailleurs, pour un site public, la loi fait bien la différence entre personne morale, personne physique, site avec ou sans activité commerciale dans les mentions légales.

C'est discutable, mais le débutant va utiliser la GUI, plus intuitive ; le confirmé aura accès à la CLI pour être en mode « fais ce que je te demandes sans discuter », ou pourra utiliser rm -i s'il veut une demande de confirmation.

C'est pas forcément représentatif, tu trouveras des gens qui ont eu des problèmes similaires avec Ubuntu, et d'autres qui n'ont jamais eu de problèmes avec Mageia…

C'est peut-être historique. Mageia est dérivée de feu Mandrake/Mandriva, qui était à une lointaine époque la distribution la plus accessible (quand Ubuntu, Mint et consorts n'existaient pas).

Peut-être qu'il devrait y avoir deux informatiques : une d'outils, qui part du principe que l'utilisateur sait ce qu'il fait, et qui peut se torcher avec beaucoup de protections ; et une autre grand public qui devrait effectivement partir du principe que l'utilisateur n'a pas à connaitre les détails de fonctionnement ?

Oui. Je m'attends à ce qu'un GUI m'affiche une boite de dialogue de confirmation quand je fais clic droit > supprimer. En revanche, si en CLI je tape rm fichier je m'attends à ce que le fichier soit supprimé sans confirmation.

tri les fichiers par ordre apparamment arbitraire, en fait ça semble être trié par adresse du fichiers

C'est courant sur les autoradios : https://linuxfr.org/users/jihele/journaux/fatsort-a-la-rescousse-des-autoradios-mp3

Et je suis la seule personne sur ce serveur mail. C'est peut être pour ça que je n'ai pas trop de soucis.

Oui. J'ai aussi un serveur mail que je suis seul à utiliser, et pour lequel je n'ai eu quasiment aucun problème en 10 ans. À côté de ça, j'ai travaillé sur des serveurs mail mutualisés, c'est beaucoup moins joyeux…

Sur un champ SPF, on peut indiquer quoi faire des adresses qui n'y sont pas présentes (~all, ?all ou -all). Avec DKIM, on peut ajouter un champ ADSP.

Du coup, DMARC a-t-il une utilité si on ne souhaite pas un controle plus fin (pct) ni recevoir d'alertes ?

Avec ansible, tu peux aussi utiliser ansible-pull. C'est un script qui pull un repository et lance un playbook localement. On peut le lancer via un cron.

Néanmoins, ça implique d'avoir ansible installé sur chaque machine (pour exécuter le playbook). Mais pas besoin d'agent qui tourne sur la machine ni de pouvoir lancer des connexions vers elle. Il faut juste que la machine puisse accéder au repository.

Avec dhcpcd aussi (man dhcpcd-run-hooks)

Ben le ./configure && make && make install, c'est juste le point de départ classique en fait. Mais ça pourrait bien être du cmake ou ./install.sh --prefix /tmp/monpaquet ou même une arborescence créée manuellement, la méthode reste la même derrière…

Partant de là, je créé un fichier control et je lance dpkg-deb. On a fait pire comme complexité, non ?

La version stretch est aussi vulnerable d'après : https://security-tracker.debian.org/tracker/source-package/webkit2gtk

Si on clique sur un des CVE, on voit :

https://webkitgtk.org/security/WSA-2018-0003.html
Not covered by security support

Tu peux aussi voir tous les paquets de stable affectés : https://security-tracker.debian.org/tracker/status/release/stable

En cadeau bonux, un script de construction de paquet debian, très inspiré des SlackBuilds :

#!/bin/sh
# Debian package creation script

# Last release: https://github.com/valr/cbatticon/releases


NAME="cbatticon"
#VERSION="1.6.7"
PKG="/tmp/build/$NAME"
DOC="Changelog COPYING README"
SRC="https://github.com/valr/cbatticon.git"
#SRC="https://github.com/valr/cbatticon/archive/$VERSION.tar.gz"

REVISION=${REVISION:-1}

SECTION="x11"
PRIORITY="optional"
ARCH="amd64"
DEPENDS=""
MAINTAINER="masao"
DESCRIPTION="A lightweight and fast battery icon that sits in your system tray"
HOMEPAGE="https://github.com/valr/cbatticon"
CONFFILES=""
CWD=$(pwd)

set -e
umask 022

if [ "$(id -u)" = "0" ]; then
        echo "Don't run this script as root !"
        exit 1
fi


## GIT
# Check if there is update
if [ -d "$NAME" ]; then
        cd $NAME
        if [ $REVISION -eq 1 ]; then
                git fetch origin
                if [ -z "$(git log HEAD..origin/master --oneline)" ]; then
                        echo "Already up to date"
                        exit 0
                fi
        fi
else
        git clone $SRC
        cd $NAME
fi

# Get last version
git pull
version=$(git log --date=short | grep '^Date' | head -1 | sed -r 's/.*([0-9]{4}-[0-9]{2}-[0-9]{2})/\1/' | tr -d '-')


## RELEASE
#[ -e "$NAME-$VERSION" ] || wget $SRC -O $NAME-$VERSION.tar.gz
#tar xvf $NAME-$VERSION.tar.gz
#cd $NAME-$VERSION
#version=$VERSION


[ -d $PKG ] || mkdir -p $PKG
make
make install DESTDIR=$PKG

# Install documentation
mkdir -p $PKG/usr/share/doc/$NAME-$version
cp -a $DOC $PKG/usr/share/doc/$NAME-$version

# Compress man pages
if [ -d $PKG/usr/share/man ]; then
        find $PKG/usr/share/man -type f -name "*.?" -exec gzip -9 {} \;
        for manpage in $(find $PKG/usr/share/man -type l -name "*.?") ; do
                ln -s $(readlink $manpage).gz $manpage.gz
                rm -f $manpage
        done
fi

# Copy systemd unit, if any
if [ -r $CWD/${NAME}.service ]; then
        mkdir -p $PKG/lib/systemd/system
        cp $CWD/${NAME}.service $PKG/lib/systemd/system
fi


# Strip binaries, libraries and archives
find $PKG -type f | xargs file | grep "ELF \(32\|64\)-bit LSB" | cut -d: -f1 | \
        xargs strip --strip-unneeded 2> /dev/null || echo "No binaries and/or shared objects to strip"
find $PKG -type f | xargs file | grep "current ar archive" | cut -f 1 -d : | \
        xargs strip -g 2> /dev/null || echo "No archives to strip"

# Prepare package
mkdir $PKG/DEBIAN

cat >$PKG/DEBIAN/control <<EOF
Package: $NAME
Version: $version-$REVISION
Section: $SECTION
Priority: $PRIORITY
Architecture: $ARCH
Depends: $DEPENDS
Maintainer: $MAINTAINER
Description: $DESCRIPTION
Homepage: $HOMEPAGE
EOF
if [ -n "$CONFFILES" ]; then
        for conffile in $CONFFILES ; do
                echo $conffile >>$PKG/DEBIAN/conffiles
        done
fi

for script in postrm prerm preinst postinst ; do
        if [ -r $CWD/$script ]; then
                cp $CWD/$script $PKG/DEBIAN/
                chmod 755 $PKG/DEBIAN/$script
        fi
done

# Build package
fakeroot dpkg-deb --build $PKG $CWD/$NAME-$version-${REVISION}.deb
rm -rf $PKG

Si la question se pose effectivement, je ne serais pas si alarmiste.

Les certificats sont générés pour 3 mois. La doc de Let'sEncrypt conseille de lancer cerbot --renew tous les jours, il ne fera rien si le certificat est a plus d'un mois de son expiration, et le renouvelle 1 mois avant son expiration.
Donc si on les monitore correctement, on peut voir le problème un mois avant que le site soit entièrement indisponible.

Comme alternative, il y a quand même… tout ce qui existait avant Let'sEncrypt. On trouve toujours des marchands de certificats « legacy » (sauf ceux qui se font retirer des navigateurs parce qu'ils font de la merde). Pour des sites importants, on en trouve dans tes tarifs abordables… même si j'en connais qui (re-)vendent des certificats pour plusieurs centaines d'euros.

Enfin, c'est loin d'être le seul « SPOF de l'Internet » : cloudflare, amazon s3,…

Effectivement, c'est cohérent. Ça ne donne pas une solution au top du top mais ça pourrait permettre de démocratiser le chiffrement, en le faisant fonctionner out-the-box.

Sauf que, à moins que je sois passé à côté de quelque chose, il reste 2 soucis :
* si la clé est perdue, on peut repartir avec une nouvelle clé, mais les messages reçus précédemment ne sont plus lisibles
* ça ne fonctionne que si on utilise un seul client de messagerie sur un seul terminal
Ce qui doit être rédhibitoire pour pas mal de monde…

Sauf que si j'en crois le journal, c'est pas seulement on first use

Si Bob change de clé, l’entête de ces messages va changer. Les destinataires de ces messages seront donc au courant du changement dès que bob leur écrira.

Sur https://haveibeenpwned.com/Passwords, si je tape « correcthorsebatterystaple » :

Oh no — pwned!
This password has been seen 103 times before

Vous employez quoi vous ?

Téléphone, SMS et emails. Parfois je sors de chez moi aussi.