まこと の ブログ

MaKoTo no burogu — Journal de bord…

Aller au contenu | Aller au menu | Aller à la recherche

informatique › Auto-Hébergement internet

Votre site perso, votre blog, vos mails, etc... tout çà chez vous, çà c'est internet !
Sinon vous faites du minitel 2.0

Historique de mon expérience sur un petit serveur web perso

Fil des billets - Fil des commentaires

samedi, 1 décembre 2018

Changer la date de publication d'une vidéo Peertube

J'ai récemment crée plusieurs chaînes Peertube sur mon serveur auto-hébergé (dans ma cuisine donc hein, pas un truc loué dans une salle machine).
Plusieurs afin de cloisonner un peu les sujets des vidéos publiées, à défaut de fonctionnalité « playlist » (disponible pour bientôt), bien que le raccourci « locales » présente tout par date décroissante.
Et autant en publiant au long court, comme un blog, les vidéos sont disponibles chronologiquement, autant lorsqu'on a déjà un stock de vidéos à mettre à disposition, il peut-être utile de pouvoir anti-dater les vidéos, et ce pour deux raisons :
- Je veux lister telle vidéo avant telle autre dans la liste des vidéos locales.
- Je veux simuler la publication des vidéos de l'époque, car Peertube n'existait pas encore.

J'ai donc gratté un peu, car une telle fonction n'existe pas, et conclu assez rapidement qu'il me faudrait éditer la base de donnée PostgreSQL de Peertube.
peertube.png

Prérequis :

  • On a besoin du nom de la base, du nom d'utilisateur et du mot de passe associé.

En fonction du type d'installation, vous n'aurez peut-être pas eu accès à ces infos. C'est le cas avec Yunohost qui m'a permis d'installer Peertube en un click !
Il faut donc consulter le fichier production.yaml pour y lire ces infos :

cat /var/www/peertube/config/production.yaml
# Your database name will be "peertube"+database.suffix
database:
  hostname: 'localhost'
  port: 5432
  suffix: '_peertube'
  username: 'peertube'
  password: 'xxxxxxxxxxx'

Le mot de passe est en clair, j'ai mis des xxxxx à la place.

Précautions :

  • Avant de faire quoique ce soit, il est sage de sauvegarder la base de donnée.

On peut le faire avec Yunohost par la fonctionnalité de backup > app, qui fait qu'on retrouve la base sous forme de fichier texte /apps/peertube/backup/db.sql dans l'archive.
Pour le faire manuellement, l'équivalent est cette commande :

pg_dump --file peertubeBasePostgreSQL_20181201.txt -d peertube_peertube -U peertube

Il peut être intéressant d'en profiter pour faire aussi une sauvegarde dans le format custom, l'intérêt peut se révéler utile en cas de soucis particulier, comme indiqué ici.

pg_dump --format=custom --file peertubeBasePostgreSQL_20181201.dump -d peertube_peertube -U peertube


Logiciel :

Pour éditer la base, j'ai choisis le logiciel pgAdmin qui sera installé sur un poste client du réseau local, car évidemment, le serveur qui fait tourner Peertube ne dispose pas d'interface graphique.

sudo apt install pgadmin3
  • Une fois installé, via le menu « Fichier > Ajouter un serveur…» on va pourvoir renseigner les infos utiles récoltées précédemment pour se connecter à la base :

pgadmin.png

Lire la suite...

samedi, 4 janvier 2014

TTRSS, Could not update headlines

  • Depuis hier je suis confronté à un message d'erreur de mon lecteur de flux.

En effet, en cliquant comme d'habitude sur Tous les articles afin de rafraîchir la liste des flux, celui-ci s'est mis à tourner en boucle assez longtemps avant de m'indiquer :

Could not update headlines (invalid object received - see error console for details)

La console d'erreur restant malheureusement vide.

  • J'ai fini par trouver d'où provenait le problème, et de l'indiquer ici, car impossible de trouver une solution écrite sur le net !!

J'ai donc pensé que peut-être un flux en particulier bloquait quelque chose et j'ai donc rafraichis un à un mes groupes de flux (catégories), pensant trouver le groupe fautif, puis le flux à l'intérieur.
En fait tous les groupes se sont bien rafraîchit… Sauf les groupes système Tous les articles et aussi Lus récemment.

Depuis un bail, j'avais des flux en erreurs, causés par l'effacement par leurs auteurs des sites et blogs associés, indiqué par le message :

Aucun article non lu à afficher.

Flux mis à jour à 12:58
Des erreurs sont survenues pendant la mise à jour de certains flux (cliquer ici pour les détails)

Quand on regarde le détail, s'affiche la liste des blogs en erreur (souvent HTTP Code: 503 ou HTTP Code: 404), que malgré tout je conservais car, les articles de ces flux restaient consultables dans TTRSS qui a l'avantage de tout conserver, alors que les blogs sont morts.

Ce qui jusqu'alors n'avait jamais posé de problème !

  • À tout hasard j'ai décidé de les supprimer, en procédant un à un, jusqu'à trouver le fautif, et laisser les autres.

Et ça fonctionne !

L'erreur bloquant le rafraîchissement de la liste des flux Tous les articles n'apparaît plus, et j'ai pu garder les autres flux en erreur, mais toujours consultable dans mon TTRSS !

lundi, 25 février 2013

Dotclear et le spam des commentaires

Le spam des commentaires est malheureusement une chose inévitable lorsque le blog commence à être bien référencé.

  • Les filtres de l'extension « Antispam » de dotclear sont assez efficaces, pour le peu qu'on enregistre suffisamment de mots clés dans le filtre : Bad Words, Liste de termes interdits.

C'est simple, il suffit d'entrer les termes anglais les plus usités, genre : That (80% de positif !) , quartz, hello, you, etc
Le seul inconvénient étant de chopper aussi les commentaires pertinents dont l'auteur aura voulu utiliser un anglicisme.

  • Au départ les spam étaient peu nombreux, pas un problème donc.

Puis de temps en temps un « chinois »[1] passait par ici et écrivait 500 fois le même commentaire toutes les 30 secondes, depuis la même IP.
Facile à bloquer avec une règle IP table du type :

iptables -I INPUT -s xxx.xxx.xxx.xxx -j DROP

Jusque là, ça reste gentillet, les filtres font leurs taf, on trie les faux-positifs, ça se gère tranquillement sans perte de temps (quelques vingtaines par semaines).
Puis ça se corse !

  • Ces mêmes « chinois » reviennent mieux armés, dans le sens où cette fois, après un ban iptables, ils reviennent avec une IP différentes, mais faisant partie de la même plage.

Un simple commande whois sur cette IP donne la plage dédiée au spammeur, et hop, un iptables manuel sur la plage… Oui c'est pas bien, mais ça défoule ^^; D'autant plus que d'autres viennent avec des plages différentes, et avec les contenu de spam et les fausse adresses mail utilisées on se doute que ce sont les mêmes gus.

iptables -I INPUT -p tcp --dport 80 -m iprange --src-range xxx.xxx.xxx.xxx-xxx.xxx.xxx.xxx -j DROP

Au bout de quelques ban manuel on finit par avoir la paix… Sauf que !
On se rend alors compte que ces salopiots ont cochés la case mise à disposition par le plugin dotclear bien pratique pour le visiteur humain, subscribeToComments 1.4-alpha1 servant à s'abonner au commentaire pour être prévenu par e-mail d'une réponse à ce commentaire.
Et là, c'est une autre affaire, car on se retrouve avec des tonnes d'abonnements bidons dans la page de gestion du plugin, et presqu'autant de mailer-daemon témoignant de l'échec d'envoi des e-mails de notifications… vu que les spammeurs rempilent derrière leurs propres spam, alors même qu'il se sont vu filtrés par le filtre Antispam et que donc leurs spam ne sont pas publiés.

  • Depuis quelques temps ces « chinois » me laissent tranquille, mais une nouvelle sorte de spammeur à débarqué… Les Zombies !

Vu la nature de ces spams, j'imagine qu'il s'agit de PC Windaube infectés de virus spammeur qui partagent une base de données avec mon IP publique dedans !
En effet, contrairement aux «chinois », ces spams débarquent du monde entier, avec des contenus plus ou moins du même genre, et des adresses e-mail dans un style différent et plus élaborées. Impossible ici de s'amuser à bannir les IP à la main avec dans les 60 spams par jours, ni à chopper les plages IP, car cette fois on est susceptible de réellement bloquer des visiteurs légitimes !
Ho, les filtres Antispam de dotclear font toujours bien le travail, mais il devient pénible de trier à la main les faux-positif et de nettoyer les abonnement aux commentaires… De fait et a regret, j'ai donc dû prendre la décision de désactiver subscribeToComments rendant le suivit des commentaires inexistant pour les visiteurs.
Voyous de publicitaires $#ø%@'&€…



Il est donc temps d'étudier une solution automatique pour bannir ces IP malignes.

Ça m'entrainera à écrire du script… L'idée ici est donc la suivante,

Toutes les 12 heures :

- Pour les 12 dernières heures écoulées, faire une requête sur la base de donnée de dotclear pour lister toutes les adresses IP des commentaires marqués indésirable par l'Antispam.
- Virer les doublons (car oui, ils reviennent, soit dans les minutes, soit les jours suivants)
- Bannir toutes les IP de cette liste avec iptables.
- Écrire un fichier de log horodaté.
- Envoyer le fichier de log par e-mail.

#!/bin/bash
 
###################################################
# BANNIR LES SPAMMEURS des commentaires DOTCLEAR #
# À programmer dans crontab toutes les 12h ################
###################################################
# ——————————— #
# Initilisation des variables #
# ——————————— #
 
login=utilisateur				# Le nom d'utilisateur ayant les droits sur la base de donnée.
password=motdepasse		# Le mot de passe associé.
base=blog					# Le nom de la base de donnée.
table=dc_comment			# La table des commentaires.
champ1=comment_spam_filter	# Le champ des commentaires marqués comme filtrés.
champ2=comment_ip			# Le champ de l'IP.
champ3=comment_dt			# Le champ de la date et heure.
condition=dcFilter% 			# Le filtre pour ne conserver que les lignes dont le champ1 commence par : dcFilter.
depuis=$(date -d "12 hour ago" "+%F %T") # La date moins 12 heures.
requete1="SELECT $champ1,$champ2,$champ3 FROM $base.$table WHERE $champ1 LIKE 'dcFilter%' AND $champ3 BETWEEN '$depuis' AND now()"
 
# ———— #
# Fonctions #
# ———— #
 
bannir () {					# Bannir l'adresse IP contenue dans la variable: ip2.
iptables -I INPUT -s $ip2 -j DROP
}
 
# ————————————————————— #
# Requête MYSQL pour réccupérer les IP à bannir #
# ————————————————————— #
 
# mysql -uutilisateur -pmotdepasse -e "SELECT comment_spam_filter,comment_ip,comment_dt FROM blog.dc_comment WHERE comment_spam_filter LIKE 'dcFilter%' AND comment_dt BETWEEN '2013-02-08 20:01:30' AND now()";
 
mysql -u$login -p$password -e "$requete1" | while read spamfilter ip date		# Lire la requête mysql ligne par ligne et récupérer les valeurs de chaque champs pour les affecter respectivement aux variables: spamfilter ip date.
						do
							if [ "$ip" = "comment_ip" ]; then		# Si la variable: ip, contient le mot: comment_ip, Alors.
								echo "comment_ip" > /dev/null	# L'envoyer au trou noir !
							else								# Sinon,
								echo  "$ip"					# Appeler successivement la valeur de la variable: ip.
							fi
						done | sort -u > /tmp/dc_spam.tmp		# Stocker les ip dans le fichier tmp en supprimant les doublons.
# —————————— #
# Bannir les IP récoltées #
# —————————— #
 
date '+%Y-%m-%d %X' >> /var/log/dc_BannedIP.log			# Écrit la date dans le fichier log: dc_BannedIP.log.
echo -e "\n" >> /var/log/dc_BannedIP.log						# Saute une ligne dans le fichier log: dc_BannedIP.log.
 
if [ -s /tmp/dc_spam.tmp ]; then								# Si le fichier tmp n'est pas vide.
	while read ip2										# Lire le fichier: tmp, ligne par ligne.
	do
		echo "$ip2"                  								# Appeler successivement la valeur de la variable: ip2.
		bannir   	 	                     							# Appeler la fonction: bannir.
	done < /tmp/dc_spam.tmp >> /var/log/dc_BannedIP.log		# Ajouter la liste des IP que l'on vient de bannir dans le fichier log: dc_BannedIP.log
	echo -e "———————————————————" >> /var/log/dc_BannedIP.log	# Écrit une ligne horizontale dans le fichier log: dc_BannedIP.log.
else
	echo "aucune IP à bannir" >> /var/log/dc_BannedIP.log		# Sinon, ne rien faire.
	echo -e "———————————————————" >> /var/log/dc_BannedIP.log	# Écrit une ligne horizontale dans le fichier log: dc_BannedIP.log.
fi
 
# ————————————— #
# Envoie d'un email avec le log #
# ————————————— #
 
mutt -s "IP Bannies pour Dotclear" admin@mondomaine.org -a /var/log/dc_BannedIP.log < /root/scripts/emailmessage.txt

Note

[1] le whois indique des IP depuis la Chine…

vendredi, 1 février 2013

interruption de service -3-

 Retour de mes sites après quelques jours off-line !!

En effet un problème de connectiques pourries a impacté depuis mardi midi la moitié des résidents de mon immeuble.

Pour les lecteurs hors « planète auto-hébergement » qui ne le saurait pas, cela fait trois ans maintenant que j'auto-héberge mes services internet.
Depuis lors, je n'ai eu à déplorer que deux coupures de longue durée, l'une de 1 journée car mon disjoncteur EDF avait sauté et la présente de 3 jours, due au câblage du FAI.

D'autres soucis mineurs lié à l'administration du serveur sont survenu en trois ans, notamment apache qui saturait la mémoire du serveur, et plantait la machine, un simple reboot du serveur suffisant à faire repartir la disponibilités de mes pages, et depuis ce problème est résolu en activant le multi-threading php.
Mais j'ai envie de dire que ce genre de panne surviendrait tout autant avec un hébergement payant et centralisé, donc ça compte pas :D

- page 2 de 8 -