HOAB

History of a bug

Springboot & listening address

Rédigé par gorki Aucun commentaire

Problème :

J'ai une configuration un peu particulière :

  • je développe et teste majoritairement sous Linux, Ubuntu
  • pour certains cas, je lance une VM Windows 10 sous virtualbox pour tester IE/Edge

Je lance comme d'habitude mon application, j'essaie de m'y connecter depuis la VM impossible...

Configuration de la VM :
- en NAT
- en virtual network

Solution :

Evidemment je pense au paramètre `server.address` de Spring boot car j'ai un log qui m'affiche : Listening on 127.0.0.1:8080
Mais ça ne marche pas...

Je tente X configurations différentes : dans le fichier de configuration, en paramètre avec le -Dserver.address

Je tente avec le port forwarding NAT de Virtualbox. Nada.

La connexion SSH fonctionne : je peux me connecter depuis la VM

Je vérifie le firewall, pas activé.

Jé vérifie IPTables, ça me semble OK

Le netstat a du mal à sortir les LISTEN, j'utilise : lsof -i -P -n | grep LISTEN

Et là :

1) Springboot écoute bien par défaut sur toutes les IPv4, comme décrit a plein d'endroit, le server.address fonctionne très bien
2) le log affiché était applicatif et codé en dur : argh :(
3) c'était le iptable qui bloquait...  il fallait regarder le FORWARD et pas le INPUT... pas sur d'avoir compris pourquoi, a priori on ne change pas de réseau/machine. A creuser. Commande iptable pour ouvrir le port.

 

 

 

Openvpn et serveurs du réseau ne réponde pas au ping

Rédigé par gorki Aucun commentaire

Problème :

Après avoir eu un reboot de serveur, j'ai du perdre une configuration quelque part et mon VPN ne marchait plus correctement.

J'ai un serveur A qui héberge OpenVPN en 10.8.0.0 avec un VLAN en 10.0.10.0.

  • la connexion était OK
  • le ping du serveur A qui héberge openVPN était OK (sur l'adresse du VPN et du VLAN)
  • le ping du serveur B était KO sur l'adresse du VLAN

Solution :

Alors je n'ai sans doute pas la bonne configuration, c'est du vite réparé, je creuserai plus tard.

1) il faut activer l'IP forwarding sur le serveur A et je pense qu'après le reboot, le paramètre n'était pas permanent. C'est facile, c'est partout sur le net

Comme ça ne marchait pas, j'ai procédé par étape et c'est plus ça qui est intéressant.

2) Faire des tcpdump sur les différentes interfaces :

  •  tcpdump -nni tun0 icmp sur le serveur A, si on voit du traffic on continue
  •  tcpdump -nni eth0.vlan icmp sur le serveur A, là c'était KO, activation de l'IP forwarding, si OK on continue
  •  tcpdump -nni eth0.vlan icmp sur le serveur B alors là, les paquets arrivent bien au 2nd serveur
  • depuis le serveur A, pinger le client
  • depuis le serveur B pinger le client

Et là était mon problème, j'ai tilté après quelques lectures que les paquets arrivent avec une adresse en 10.8.0.0 (VPN) au serveur en VLAN et il ne sait pas comment les renvoyer.

Solution rapide, sur le serveur B, ajouter une route :

route add -net 10.8.0.0 gw 10.0.10.1 netmask 255.255.255.0 dev eth0.vlan

Mais il doit y avoir des façons de faire plus adaptés, si j'avais un réseau entreprise, je devrais ajouter cette route sur tous mes serveurs.

Donc piste à suivre :

iptables -t nat -A POSTROUTING -o <eth0 or whatever else> -j MASQUERADE
  • dernier point, mais a priori ne s'applique pas à mon cas, lorsque le serveur openvpn ne sait pas retrouver les clients ce blogavec l'option iroute (voir ce blog)

 

 

Springboot + Maven + Junit5

Rédigé par gorki Aucun commentaire

Problème :

Migration de springboot vers  la 2.1.1 et Junit5... et plus rien ne marche, tests introuvables.

Après de multiples tests, ça marchait dans Intellij Idea, mais pas sous maven (MockBean retournait null....)

Solution :

J'ai fait beaucoup d'essais :

  • ajouter junit-platform-commons comme vu ici
  • j'ai suivi les guides de Mkyong Springboot + Maven + Junit5
  • j'ai exclu Junit4 de surefire, ajouter plateform-commons à surefire...

Rien n'y faisait :

  • soit pas de tests
  • soit NullPointerException sur les MockBeans
  • soit "Caused by: java.lang.ClassNotFoundException: org.junit.platform.engine.support.discovery.SelectorResolver"

Au final :

  1. Faire migrer les tests junit vers junit5
    1. Corriger les API 
      import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
    2. Remplacer le SpringRunner 
      @ExtendWith({SpringExtension.class})
  2. Simplifier le POM (vu ici : https://github.com/junit-team/junit5/issues/1773)
		<dependency>
			<groupId>org.junit.jupiter</groupId>
			<artifactId>junit-jupiter</artifactId>
			<version>${test.junit.version}</version>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>org.junit.jupiter</groupId>
			<artifactId>junit-jupiter-api</artifactId>
			<version>${test.junit.version}</version>
			<scope>test</scope>
		</dependency>
<!--
		<dependency>
			<groupId>org.junit.jupiter</groupId>
			<artifactId>junit-jupiter-engine</artifactId>
			<version>${test.junit.version}</version>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>org.junit.platform</groupId>
			<artifactId>junit-platform-commons</artifactId>
			<version>${test.junit.platform}</version>
			<scope>test</scope>
		</dependency>-->

Et bien sur :

		<!-- TEST -->
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-test</artifactId>
			<scope>test</scope>
			<exclusions>
				<exclusion>
					<groupId>junit</groupId>
					<artifactId>junit</artifactId>
				</exclusion>
			</exclusions>
		</dependency>

Et enfin :

			<!-- Testing -->
			<plugin>
				<artifactId>maven-surefire-plugin</artifactId>
				<version>2.22.2</version>
			</plugin>

 

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