[kr0hm]

Bonjour,
J'ai eu le même problème dernièrement avec Ubuntu 16.04 Server (64 bits). J'avais activé le pare-feu au démarrage via webmin. Mais je ne suis pas certain d'avoir reboot le VPS depuis que l'option avait été activé...
Bref, pas de bol, il a fallu un incident OVH et donc un reboot de l'infra, pour que mon instance se retrouve inaccessible ^^

Le problème de conf apparait dans le syslog lors du démarrage:

systemd[1]: Reached target Network (Pre).
systemd[1]: Starting Raise network interfaces...
sh[770]: /etc/network/interfaces:8: misplaced option
sh[770]: ifquery: couldn't read interfaces file "/etc/network/interfaces"
ifup[775]: /etc/network/interfaces:8: misplaced option
ifup[775]: /sbin/ifup: couldn't read interfaces file "/etc/network/interfaces"
systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start Raise network interfaces.
systemd[1]: Dependency failed for Initial cloud-init job (metadata service crawler).
systemd[1]: cloud-init.service: Job cloud-init.service/start failed with result 'dependency'.
systemd[1]: networking.service: Unit entered failed state.
systemd[1]: networking.service: Failed with result 'exit-code'.

Pour ma part après avoir commenté la ligne dans "/etc/network/interfaces", je l'ai remise dans le fichier de conf "50-cloud-init.cfg" qui se trouve dans le dossier "/etc/network/interface.d/" comme ci-dessous :

auto lo
iface lo inet loopback

auto ens3
iface ens3 inet dhcp
post-up iptables-restore < /etc/iptables.up.rules

Les règles du pare-feu sont bien chargées au démarrage, mais dans webmin l'option est marqué à off.
Ca m'évite l'oubli du pare-feu en cas de redémarrage ^^

[doc_denis]

Bonjour, oui avec la combine que j'ai indiqué plus haut
a savoir : passer en rescue et désactivation du pare-feu au boot

comme indiqué sur ce post plus haut : https://forum.ovh.com/showthread.php...l=1#post660382

ensuite évidement on lance le pare-feu en manu à chaque reboot pour éviter de tout refaire à chaque fois

[édit] Donc, personnellement je n'active pas le pare-feu au démarrage sur un serveur qui à rencontré ce problème.

[d.harlaut]

Bonjour,
nous rencontrons exactement le même problème que vous sur un VPS2016 Cloud (en utilisant webmin également). Avez-vous réussi à résoudre votre problème ?

[doc_denis]

pour faire le point :
j'ai mis mes filtres et rebooter sans probleme (tant que le pare-feu n'est pas activé au démarrage).

Puis j'ai réactivé le pare-feu au boot via webmin et ça re-bloque tout au reboot

donc je vais à nouveau passer en rescue puis commenter la ligne et relancer le pare-feu manuellement après le reboot (seule solution trouvée).

[doc_denis]

BINGO !

Le fait de commenter la ligne du fichier /mnt/vdb1/etc/network/interfaces comme ceci :

# post-up iptables-restore < /etc/iptables.up.rules

m'a redonner mon accès ssh, redonner accès à l'unique host du vps ...bref ça retourne.

mais il y à bien une pétouille avec la config iptable de webmin depuis la MAJ.
je vais tenté de repasser par webmin > réseau > parefeu pour voir ce qui ce passe

[doc_denis]

1- les taches re-fonctionnent, je retourne en mode rescue.
j'ai tout passé en accept dans mon mnt/vdb1/etc/iptables.up.rules

2- retour en normal = pareil ...c'est pas iptable

3- retour en rescue, je vais vérifier la config réseau mnt/vdb1/etc/network/interfaces
il contient :

auto lo
iface lo inet loopback
        source /etc/network/interfaces.d/*.cfg
        post-up iptables-restore < /etc/iptables.up.rules

je regarde : cd interfaces.d
il y à un eth0.cfg ...alors nano eth0.cfg qui donne :

# The primary network interface
auto eth0
iface eth0 inet dhcp

ça à l'air d'être en dhcp tout auto, donc ça devrait tourner...
sur les vps 2014 classic la config est totalement différente ...j'en perd mon latin

je vais tenter de commenter la ligne :

 post-up iptables-restore < /etc/iptables.up.rules

du fichier /mnt/vdb1/etc/network/interfaces, c'est peut-être par ici que ça merdoie.

je vérifie en même temps mon fichier /etc/iptables.up.rules (tout à l'air normal) :

# Generated by webmin
*filter
:OUTPUT ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
-A INPUT -p tcp -m tcp --dport 10000:10010 -j ACCEPT
-A INPUT -p udp -m udp --dport domain -j ACCEPT
-A INPUT -p tcp -m tcp --dport 10000 -j ACCEPT
-A INPUT -p tcp -m tcp --dport https -j ACCEPT
-A INPUT -p tcp -m tcp --dport http -j ACCEPT
-A INPUT -p tcp -m tcp --dport imaps -j ACCEPT
-A INPUT -p tcp -m tcp --dport imap -j ACCEPT
-A INPUT -p tcp -m tcp --dport pop3s -j ACCEPT
-A INPUT -p tcp -m tcp --dport pop3 -j ACCEPT
-A INPUT -p tcp -m tcp --dport ftp-data -j ACCEPT
-A INPUT -p tcp -m tcp --dport ftp -j ACCEPT
-A INPUT -p tcp -m tcp --dport domain -j ACCEPT
-A INPUT -p tcp -m tcp --dport submission -j ACCEPT
-A INPUT -p tcp -m tcp --dport smtp -j ACCEPT
-A INPUT -p tcp -m tcp --dport ssh -j ACCEPT
COMMIT
# Completed
# Generated by webmin
*mangle
:FORWARD ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed
# Generated by webmin
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed

globalement, je ne vois rien d'étrange.

pour le moment je le repasse en mode normal pour vérifier.

[doc_denis]

RÉSOLU Post 3

Bonjour,
"VPS 2016 SSD 1"
Pas de ping suite à une mise à jour de Ubuntu server 14.04 64bits (avec webmin/virtualmin)
sudo apt-get update && sudo apt-get upgrade

ouverture d'un ticket support passage en rescue.

réinstallation du serveur hier 25 janvier, et à la dernière maj, un reboot et ...pareil, pas de ping
Pas de bol dès hier soir, le manager ne reboot pas en rescue. Sans doute à cause de : http://travaux.ovh.com/?do=details&id=16310

Pour info, iptable était activé au démarrage, mais avec les réglages standard juste des :
"jeter" sur les services pop, smtp, imap, ftp-data, ftp...
"accepté" sur les http, https, ssh, domain, submission,..

dans le coup, je ne fais pas les MAJ sur mes autres VPS et/ou Dédiés ubuntu avant la résolution de celui-ci.