HOAB

History of a bug

Fast browsing and DNS

Rédigé par gorki Aucun commentaire

Problem :

I was surfing on some sites blocked by my DNS provider (no, not yggtorrent. Absolutely not).

So Firefox provide DNS over HTTP with NextDNS, sometimes slower than my provider DNS but well, not so bad.

Then for some reason, I tried to host a local DNS resolver. Well, it WAS slow.

Solution :

Unbound is DNS resolver :

  • easy to install
  • cache request locally, so save a few ms for a lot of requests !
  • and support DNS over https, etc…

Setup is quite simple thanks to internet knowledge :

Installation :
(https://memo-linux.com/debian-installer-le-serveur-dns-unbound/

apt install unbound
cd /var/lib/unbound/ 
wget ftp://ftp.internic.net/domain/named.cache
mv named.cache root.hints && chown unbound:unbound root.hints
mv /etc/unbound/ 
unbound.conf.d/root-auto-trust-anchor-file.conf root-auto-trust-anchor-file.conf.original
mkdir /var/log/unbound
chown unbound: /var/log/unbound
# modify apparmor (see at the end)
systemctl restart unbound

My configuration file :

server:
statistics-interval: 0
extended-statistics: yes
statistics-cumulative: yes
verbosity: 3
interface: 127.0.0.1
port: 53
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
access-control: 127.0.0.0/8 allow ## j'autorise mon serveur
access-control: 0.0.0.0/0 refuse ## j'interdis tout le reste de         l'Internet !
auto-trust-anchor-file: "/var/lib/unbound/root.key"
root-hints: "/var/lib/unbound/root.hints"
hide-identity: yes
hide-version: yes
harden-glue: yes
harden-dnssec-stripped: yes
use-caps-for-id: yes
cache-min-ttl: 3600
cache-max-ttl: 86400
prefetch: yes
num-threads: 6
msg-cache-slabs: 16
rrset-cache-slabs: 16
infra-cache-slabs: 16
key-cache-slabs: 16
rrset-cache-size: 256m
msg-cache-size: 128m
so-rcvbuf: 1m
unwanted-reply-threshold: 10000
do-not-query-localhost: yes
val-clean-additional: yes
#use-syslog: yes
#val-log-level:2 (0: default, nothing, 2: full)
logfile: /var/log/unbound/unbound.log
harden-dnssec-stripped: yes
cache-min-ttl: 3600
cache-max-ttl: 86400
prefetch: yes
prefetch-key: yes

And an additional apparmor configuration to be able to write in a dedicated file :
(https://b4d.sablun.org/blog/2018-09-27-when-unbound-wont-write-logs/)

vim /etc/apparmor.d/local/usr.sbin.unbound

# Site-specific additions and overrides for usr.sbin.unbound.
# For more details, please see /etc/apparmor.d/local/README.
/var/log/unbound/unbound.log rw,

 

Lire la suite de Fast browsing and DNS

OVH mutualisé et owncloud

Rédigé par gorki Aucun commentaire

Le problème :

J'essaie d'utiliser Owncloud avec un OVH mutualisé.

J'ai déplacé des fichiers dans cette arborescence, et il faut maintenant faire de la ligne de commande… qui n'est pas disponible en OVH mutualisé.

Solution :

Ligne de commande à exécuter : 

./occ files:scan <mon chemin> <mon user>

Quelques difficultés : 

  1. Accès à la ligne de commande, on utilise un shell PHP, par exemple P0wnyShell
  2. Trouver le binaire occ : il est à la racine :)
  3. Droit d'exécution sur occ : chmod 744 occ
  4. Identifier l'exécutable PHP : ps -aef | grep php
2617  9693  0 09:44 ?        00:00:00 php7.4 -c /usr/local/php7.4/etc/php-cgi.ini -d display_errors=0 -d session.force_path=1 -- p0wnyshell.php
  1. Modifier le fichier occ pour mettre le bon chemin : #!/usr/bin/env /usr/local/php7.4/bin/php
  2. Executer : 
./occ files:scan <mon chemin> <mon user>

 

Lire la suite de OVH mutualisé et owncloud

Raspberry as network monitor

Rédigé par gorki Aucun commentaire

Problem :

I built a network monitoring solution following this guides :

Truly, a great job.

But I has build the solution at home for another network, I would like that my raspberry start and monitor at boot. And I missed in the comments or text a few thing.

Solution :

I created services as described in the comment for prometheus, add another for the tcpdump. Don't forget prometheus working directory in this configuration (no specific user for prometheus).
 

[Unit]
Description=Prometheus
After=tcpdump.service

[Service]
User=pi
Group=pi
Type=simple
WorkingDirectory=/home/pi/prometheus/prometheus-2.23.0.linux-armv7
ExecStart=/home/pi/prometheus/prometheus-2.23.0.linux-armv7/prometheus \
    --config.file /home/pi/prometheus/prometheus.yml

[Install]
WantedBy=multi-user.target
/etc/systemd/system/tcpdump.service

[Unit]
Description=TCPDump service for traffic monitoring
After=network-online.target
[Service]
Type=idle
ExecStart=python3 /home/pi/network-traffic-metrics/network-traffic-metrics.py "(src net 192.168.10.0/24 and not dst net 192.168.10.0/24) or (dst net 192.168.10.0/24 and not src net 192.168.10.0/24)"
[Install]
WantedBy=default.target

But I had some network issues :

First, disable dhcpcd and install isc-dhcp-server

In my case, I keep dhcpcd as it mount the network interfaces eth0 & eth1. I also put a no gateway on eth0 (my lan part)

My dhcpcd.conf configuration for interfaces :


interface eth1
static ip_address=192.168.1.10
static routers=192.168.1.1
static domain_name_servers=1.1.1.1
static domain_search=1.1.1.1

interface eth0
static ip_address=192.168.10.1
static routers=192.168.10.1
static domain_name_servers=1.1.1.1
static domain_search=1.1.1.1
nogateway

But with this configuration, at boot :

  • isc-dhcp-server and tcpdump

were not started because eth0 was not up or plugged. In my case, I could plug eth0 later.

So I took a while, but I found the network hook that works (forget all /etc/network thing, dhcpcd do not use it).

Create a file (not a directory...) called /etc/dhcpcd.exit-hook with

#!/bin/bash

if [ "$interface" = "eth0" & "$reason" = "STATIC" & "$if_up" = "true" ]
then
	systemctl start tcpdump
	systemctl start isc-dhcp-server.service
fi 

And all is starting when eth0 is going up.

Upgrade debian et lost network

Rédigé par gorki Aucun commentaire

Problem :

I manage a dedicated server in OVH and I upgrade my debian from jessie to buster. Upgrade works quite well (it seems...) and I try to restart.

Server reboot fails as unreachable, fortunately OVH rescue mode allows me to login.

I check error log and first lost myself in RAID error message, but it was more simple than that.

Solution :

I check the /etc/network/interfaces file, it was OK

I check the logs files, clean, reboot, check again, still OK except that network was unreachable for named.

I finally remember that Debian switch to systemD in latest version so I tried to create system networking file manually : too complicate, it was not working.

In rescue mode, you can access your files as a mounted point so usual commands as systemctl does not work.

The solution was to chroot a shell :

  1. mkdir /mnt/md2
  2. mount /dev/md2 /mnt/md2
  3. chroot /mnt/md2 bash
  4. systemctl enable networking

And it works...

Now I have to check all other system to be sure that everything is working...

Begining with :

sudo apt-get update

sudo apt-get clean

sudo apt-get autoremove

sudo apt-get update && sudo apt-get upgrade

sudo dpkg --configure -a

 

Montage Samba et erreurs à côté de la plaque

Rédigé par gorki Aucun commentaire

Le problème :

Dans deux cas, j'exécute la commande mount via ansible pour monter un partage samba sur deux clients Linux.

Dans les deux cas, le montage est en échec pour cause :

  • soit "CIFS VFS: validate protocol negotiate failed: -13"
  • soit "CIFS VFS: BAD_NETWORK_NAME"

Solution :

Les erreurs venaient à chaque fois de ma configuration Samba côté serveur.

Les tests que j'ai réalisé pour retrouver la cause :

  1. Tester le montage du partage à partir de Windows (j'obtenais la même erreur : le problème vient du serveur)
  2. A partir des linux : smbclient -L <monserveur> -A /path/to/mycredentials
    • ça, ça marchait dans 1 cas, dans l'autre cas, le nom du partage était mauvais : tilt ! (n°1)
  3. Avec le user samba, je suis aller dans le répertoire partagé pour vérifier que j'avais bien les droits
    • et là ça ne marchait pas pour le 2ème cas (negociation failed)

Après avoir remis les droits pour l'un, corrigé mon template ansible pour l'autre, tout marche.

Pour info la configuration mis en place :

[global]
  workgroup = SAMBA
  security = user
  unix password sync = no
  log file = /var/log/samba/log.%m
  guest account = {{samba_user.user}}
  force group = {{samba_user.group}}
  force user = {{samba_user.user}}
  create mode = 0660
  directory mode = 0770

[myshare]
  path={{samba_share.export_path}}
  public=yes
  valid users={{samba_user.user}}
  writable=yes
  browseable = yes
  force create mode = 0660
  force directory mode = 0770

Et pour autoriser les users à se connecter via leur compte unix et toujours autoriser ce user générique à accéder aux fichiers :

# Ensure all files are owned by {{ samba_user.user }}
  shell: "chown -R {{ samba_user.user }}:{{ samba_user.group }} {{samba_share.export_path}}" 

# Ensure sticky bit is present on all directories
  shell: "find {{ samba_share.export_path }} -type d -exec chmod g+s {} +" 

# Add default rw for default group on {{ samba_share.export_path }}
  shell: "setfacl -m d:g::rwx {{ samba_share.export_path }}" 

# Add default rw for default group on subdirectories
  shell: "find {{ samba_share.export_path }} -type d -exec setfacl -m d:g::rwx {} +" 

Merci à eux :

https://superuser.com/questions/381416/how-do-i-force-group-and-permissions-for-created-files-inside-a-specific-directo
https://lea-linux.org/documentations/Gestion_des_ACL

Fil RSS des articles de cette catégorie