El Gnap et ses geekeries
Et voilà, z’avez fait l’andouille, vous avez oublié de lancer screen/tmux avant de faire un yum update et la liaison s’est coupée en plein upgrade.
On commence par récuperer la liste des duplicates:
yum update | grep duplicate | sed ‘s/ is a.*//’ | sed ‘s/.*://’ > error-packages.list
Remplacer le FTP par le SFTP c’est bien mais il ne faut pas abaisser la sécurité pour autant. Et par défaut l’utilisateur à accès à toute la machine via SFTP, il faudra donc le chrooter.
Je vais donc vous expliquer pas à pas comment sécuriser une installation sftp.
Commencer par refuser la possibilité de login à tt les utilisateurs que vous utiliserez comme sftp en faisant soit chsh user et en mettant /bin/false ou en mettant dans /etc/default/useradd les valeurs suivantes:
SHELL=/bin/false
SKEL=/etc/skelempty
Il vous faudra créer le dossier /etc/skelempty qui ne contient rien (ceci afin d’éviter l’ajout automatique de fichier qu’un utilisateur uniquement sftp n’aura cure).
C’est avec fierté que je peux vous annoncer que ce blog ainsi que celui de doudoune ou encore le tld helpcomputer.org sont maintenant disponibles sous certificat SSL CACert.
Comme CACert est une autorité de certification qui ne se trouve pas encore dans tous les navigateurs, vous devrez l’installer vous même si vous ne l’avez déjà fait.
Vous devez tout d’abord vous rendre sur la page des root certificates de CACert.
Ensuite si vous êtes sous windows et que vous utilisez Internet Explorer, Chrome ou Safari vous devez télécharger et installer le “Windows Installer package” (n’oubliez pas de redémarrer votre browser après).
Pour Firefox, c’est un peu différent, il vous suffit de cliquer sur “Certificat racine (format PEM)|Root certificate (PEM format)” et de cocher “Confirmer cette AC pour identifier des sites Web” (expliqué en images sur parinux).
Une fois tout cela fait il suffit d’ajouter un gentil petit “s” à la fin de http dans votre barre d’adresse ;-).
Ou …. de cliquer sur les liens ci dessous : ce blog ainsi que celui de doudoune ou encore le tld helpcomputer.org sont
Avoir une interface web pour contrôler/gérer série de paramètres c’est bien. En l’occurrence moi j’ai du monitoring grâce à munin, un contrôle sur mpd grâce à relax, nzbget(web), transmission ou encore mon serveur git(web), mais voilà qui dit administration dit protection, ça me semble une évidence. Oui, bien sur vous avez le login/mdp habituel, mais quoi de mieux que d’avoir une administration qui N’EXISTE PAS aux yeux des pirates?! Et donc si elle n’existe pas, pas évident de hacker une interface qui n’existe pas.
Quand vous devez passer de Apache à NGinx vous savez déjà surement que vous allez devoir réécrire vos .htaccess dans le fichier de config du domaine lui même. Et donc les mot de passe aussi. Maix pour cela il faudrait savoir quels sont et où sont les fichiers de mots de passes utilisés.
Pour cela rien de plus simple: les instructions concernant les directives d’auth peuvent se trouver dans 2 endroits :
On va devoir fouiller ces deux endroits, et pour le premier.
Il y a quelques jours est venu un twitto @woueb demandant : comment faire pour voir l’origine d’une grosse fuite réseau ?
Ayant même pas regardé qu’il y avait un GIGANTESQUE menu Statistics je l’ai mis à l’amande et me suis donné du boulot :-P
Faut d’abord commencer par logguer tout ce qui passe sur la machine pour pouvoir traiter les données après. Commande on ne peut plus simple :
screen tcpdump -w tcp.dmp
Si vous pensez à faire le changement le jour où vous passez d’un serveur à l’autre c’est très simple.
Il vous suffira d’éditer le fichier /etc/awstats/awstats-nom-de-domaine.conf et d’éditer la ligne
LogFile=””
Et d’y mettre le path du nouveau fichier de log.
Je parlerai dans un autre poste de la partie affichage grâce à nginx, ici on parse déjà les bons fichiers de log, c’est déjà pas mal.