Re: Quelle stratégie contre le vol d'un serveur ?

[andre_debian]

On Tuesday 08 May 2018 23:39:56 Pierre Malard wrote:
> Merci à tous pour ces précisions,
> Elles me seront très utiles pour en rabattre avec les thuriféraires du
> Windows « vrai pro » et « sérieux » que je rencontre par trop ces temps-ci. 
> Encore merci

Sans compter nombres de sites qui vantent les serveurs sous Windows,
voire, le déclarent infiniment mieux que ceux sous Linux. Et combien le 
croiront encore...
Ces gens réagissent comme ça, car vexés par leur incapacité à manier Linux,
le presse bouton sans réfléchir, c'est plus simple.
Et Microsoft tente de rattraper son déclin du marché professionnel en se 
déclarant maintenant le virtuose de l'opensource, comme si il l'avait inventé
finalement et combien le croit...

> Le 8 mai 2018 à 17:43, andre_deb...@numericable.fr a écrit :
>https://mavielinux.com/2015/06/04/les-parts-de-marche-de-linux-en-mai-2015/
>www.journaldunet.com/solutions/expert/51207/l-ecrasante-domination-de-linux-dans-le-cloud---vers-90--de-part-de-marche.shtml
>www.developpez.com/actu/101333/Spiceworks-au-moins-une-entreprise-sur-deux-dans-le-monde-utilise-encore-Windows-Server-2003-quels-systemes-serveur-utilisez-vous-en-entreprise/
>Les gros calculateurs sont tous sous Linux, les impôts, les FAI, PSA...

Re: longue attente au boot [résolu]

[Frédéric Baldit]

Juste une remarque, pour finir: de nos jours un démarrage en presque
deux minutes, avec écran figé et aucune ligne de code montrant une
activité du système, peut laisser perplexe, surtout pour un premier
utilisateur de debian et surtout aussi pour ceux habitués à des temps
de boot devenus vraiment courts avec la démocratisation des SSD. En
fait, j'ai moi même mis un certains temps avant de constater qu'il me
fallait simplement attendre environ deux minutes pour pouvoir me
connecter, et j'ai plusieurs fois fait des Ctrl+Alt+Suppr ou
Ctrl+Alt+Fn intempestifs avant de commencer à comprendre. Celui qui,
démarrant une installation fraîche de stretch, observe ce comportement,
a de quoi rester perplexe et peut vite avoir envie de passer à un autre
linux...Peux-t-on faire remonter ce comportement comme un bug?

--
  Frédéric Baldit

Le mar. 08 mai 2018 à 16:29:11 +
Eric Degenetais  a écrit:

> Le 8 mai 2018 3:12 PM, "Frédéric Baldit"  a
> écrit :
> 
> 
> Bonjour,
> 
> merci aux deux personnes ayant répondu: en effet je comprends mieux
> pourquoi le système est si long à démarrer, c'est maintenant assez
> clair.
> 
> De rien :)
> 
> 
> J'ai adoptée la solution la plus rapide: installation de la version
> précédente du noyau (9.0.5) et ça marche!
> 
> Rq: je suis quand même étonné, étant donné l'importance de la qualité
> des générateurs aléatoires pour tout ce qui concerne la sécurité (du
> système en général), que celui implanté dans le noyau linux ne génère
> pas des nombres de qualité (aléatoire) suffisante, et ceci  en un
> temps qui ne pénalise pas la rapidité du démarrage. Ceci dit, je me
> doute que le problème est plus complexe que ça...et que je dois
> n'avoir qu'une idée très incomplète de la complexité de la situation.
> 
> Tel que je comprends, le problème est le suivant : comme tout
> logiciel, le noyau est déterministe. Il dépend donc de sources
> extérieures d'entropie pour générer des nombres aléatoires de bonne
> qualité. Il me semble qu'il a existé à une époque des périphériques
> matériels spécialisés dans la génération d'entropie, donc de nombres
> aléatoires, je ne sais pas si ça existe encore. Dans nos systèmes qui
> n'en sont pas équipés, le générateur est initialement dans un état
> connu, et accumule de l'entropie en provenance du clavier, de la
> souris, des cartes réseau, etc. Ça prend du temps de s'éloigner
> suffisamment de l'état initial prédictible. Concernant la fourniture
> d'entropie par un fichier sauvegardé au shutdown et relu, je me
> souviens clairement avoir vu passer les logs "random seed saved" et
> "random seed reloaded" à chaque shutdown et boot de mon PC sous
> gentoo, environ trois ans en arrière. J'ignore pourquoi ce procédé
> n'aurait pas été conservé depuis.
> 
> 
> Merci à vous deux,
> --
>   Frédéric Baldit
> 
> Le lun. 07 mai 2018 à 17:45:38 +
> Eric Degenetais  a écrit:
> 
> > D'après ce que j'ai compris, le traitement proposé repose sur deux
> > pistes extérieures au noyau :
> > 1) vérifier s'il y a vraiment besoin d'un nombre aléatoire de
> > qualité, sinon utiliser un autre appel système
> > 2) utiliser le bootloader pour conserver l'entropie lors d'un reboot
> > pour que le générateur soit plus rapidement près sans sacrifier la
> > sécurité
> >
> > Éric Dégenètais
> >
> > Le 7 mai 2018 17:42,  a écrit :
> >
> > Bonjour,
> >
> > C'est un bug lié au fonctionnement du générateur d'entropie du
> > noyau... Un bug est ouvert mais apparemment ça ne sera pas corrigé
> > sur le noyau car ça corrige une faille de sécu mais dans les
> > programmes en espace utilisateur (en gros, ton système attend qu'il
> > y ait assez d'entropie pour démarrer gdm).
> >
> > Tu peux booter sur l'ancien noyau en attendant.
> >
> > Julien  

Re: Quelle stratégie contre le vol d'un serveur ?

[Pierre Malard]

Merci à tous pour ces précisions,
Elles me seront très utiles pour en rabattre avec les thuriféraires du Windows 
« vrai pro » et « sérieux » que je rencontre par trop ces temps-ci.

Encore merci


> Le 8 mai 2018 à 17:43, andre_deb...@numericable.fr a écrit :
> 
> On Monday 07 May 2018 17:44:20 Pierre Malard wrote:
>> Sinon, je serait très intéressé pour avoir des sources sur la répartition
>> réelle GNU/Linux vs Windows. Les 50% annoncés, d’où viennent ils ?
> 
> En 2015, soit 3 ans :
> "Serveurs : Windows Server détient 30% des parts de marché derrière Linux
> avec 38%. BSD est à 1% et les autres basés sur Unix se maintiennent vers les
> 30%. Ces chiffres peuvent varier suivant le type de serveur analysé " :
> https://mavielinux.com/2015/06/04/les-parts-de-marche-de-linux-en-mai-2015/
> 
> "À la domination de Microsoft sur le poste de travail répond une domination de
> Linux du côté serveur, et dans le Cloud. On peut l'estimer à 90%" :
> www.journaldunet.com/solutions/expert/51207/l-ecrasante-domination-de-linux-dans-le-cloud---vers-90--de-part-de-marche.shtml
> 
> Linux à 50% en 2016 (2 ans) :
> www.developpez.com/actu/101333/Spiceworks-au-moins-une-entreprise-sur-deux-dans-le-monde-utilise-encore-Windows-Server-2003-quels-systemes-serveur-utilisez-vous-en-entreprise/
> 
> Les gros calculateurs sont tous sous Linux.
> 
> C'est clair, depuis 2 ans à 3 ans, microsoft a perdu la bataille
> de l'informatique professionnelle au profit de Linux,
> et celle des smartphones au profit d'Android.
> 
> Malheureusement, en postes de travail, windows reste majoritaire,
> à la communauté du Libre de le rendre minoritaire.
> 
> André
> 

--
Pierre Malard

   « Tant que les lions n’auront pas leurs propres historiens, les histoires
   de chasse tourneront toujours à la gloire du chasseur »
  Proverbe africain
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)  πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: Quelle stratégie contre le vol d'un serveur ?

[Gabriel Moreau]

Les gros calculateurs sont tous sous Linux.


GNU/Linux


C'est clair, depuis 2 ans à 3 ans, microsoft a perdu la bataille
de l'informatique professionnelle au profit de Linux,
et celle des smartphones au profit d'Android.


Android est un noyau Linux ! Il faudrait dire a minima Android/Linux.

Toutes les "box" tournent sous noyau Linux à ma connaissance...

De plus en plus de commutateurs tournent sous Linux (un constructeur m'a 
même dit que c'était vendeur)...


> Malheureusement, en postes de travail, windows reste majoritaire,
> à la communauté du Libre de le rendre minoritaire.

Je pense que la prochaine bataille est de ne pas travailler pour les 
GAFA... Il faut faire très attention à mettre tous ses codes sous 
copyleft (GPL ou équivalent). Google (et Apple) cherche par tous les 
moyens à virer la couche GNU et l'étape d'après sera de virer la couche 
GPL du noyau.


gaby
--
Gabriel Moreau - IR CNRShttp://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France
mailto:gabriel.mor...@legi.grenoble-inp.fr  tel:+33.476.825.015

Re: longue attente au boot [résolu]

[Eric Degenetais]

Le 8 mai 2018 3:12 PM, "Frédéric Baldit"  a écrit :


Bonjour,

merci aux deux personnes ayant répondu: en effet je comprends mieux
pourquoi le système est si long à démarrer, c'est maintenant assez
clair.

De rien :)


J'ai adoptée la solution la plus rapide: installation de la version
précédente du noyau (9.0.5) et ça marche!

Rq: je suis quand même étonné, étant donné l'importance de la qualité
des générateurs aléatoires pour tout ce qui concerne la sécurité (du
système en général), que celui implanté dans le noyau linux ne génère
pas des nombres de qualité (aléatoire) suffisante, et ceci  en un temps
qui ne pénalise pas la rapidité du démarrage. Ceci dit, je me doute que
le problème est plus complexe que ça...et que je dois n'avoir qu'une
idée très incomplète de la complexité de la situation.

Tel que je comprends, le problème est le suivant : comme tout logiciel, le
noyau est déterministe. Il dépend donc de sources extérieures d'entropie
pour générer des nombres aléatoires de bonne qualité. Il me semble qu'il a
existé à une époque des périphériques matériels spécialisés dans la
génération d'entropie, donc de nombres aléatoires, je ne sais pas si ça
existe encore. Dans nos systèmes qui n'en sont pas équipés, le générateur
est initialement dans un état connu, et accumule de l'entropie en
provenance du clavier, de la souris, des cartes réseau, etc. Ça prend du
temps de s'éloigner suffisamment de l'état initial prédictible. Concernant
la fourniture d'entropie par un fichier sauvegardé au shutdown et relu, je
me souviens clairement avoir vu passer les logs "random seed saved" et
"random seed reloaded" à chaque shutdown et boot de mon PC sous gentoo,
environ trois ans en arrière. J'ignore pourquoi ce procédé n'aurait pas été
conservé depuis.


Merci à vous deux,
--
  Frédéric Baldit

Le lun. 07 mai 2018 à 17:45:38 +
Eric Degenetais  a écrit:

> D'après ce que j'ai compris, le traitement proposé repose sur deux
> pistes extérieures au noyau :
> 1) vérifier s'il y a vraiment besoin d'un nombre aléatoire de qualité,
> sinon utiliser un autre appel système
> 2) utiliser le bootloader pour conserver l'entropie lors d'un reboot
> pour que le générateur soit plus rapidement près sans sacrifier la
> sécurité
>
> Éric Dégenètais
>
> Le 7 mai 2018 17:42,  a écrit :
>
> Bonjour,
>
> C'est un bug lié au fonctionnement du générateur d'entropie du
> noyau... Un bug est ouvert mais apparemment ça ne sera pas corrigé
> sur le noyau car ça corrige une faille de sécu mais dans les
> programmes en espace utilisateur (en gros, ton système attend qu'il y
> ait assez d'entropie pour démarrer gdm).
>
> Tu peux booter sur l'ancien noyau en attendant.
>
> Julien

Re: longue attente au boot [résolu]

[BERTRAND Joël]

Frédéric Baldit a écrit :
> 
> Bonjour,
> 
> merci aux deux personnes ayant répondu: en effet je comprends mieux
> pourquoi le système est si long à démarrer, c'est maintenant assez
> clair.
> 
> J'ai adoptée la solution la plus rapide: installation de la version
> précédente du noyau (9.0.5) et ça marche!
> 
> Rq: je suis quand même étonné, étant donné l'importance de la qualité
> des générateurs aléatoires pour tout ce qui concerne la sécurité (du
> système en général), que celui implanté dans le noyau linux ne génère
> pas des nombres de qualité (aléatoire) suffisante, et ceci  en un temps
> qui ne pénalise pas la rapidité du démarrage. Ceci dit, je me doute que
> le problème est plus complexe que ça...et que je dois n'avoir qu'une
> idée très incomplète de la complexité de la situation.

Bonsoir,

C'est parce que les développeurs du noyau sont persuadés faire mieux
que l'état de l'art. Dans un tas de systèmes (les BSD, mais pas que),
l'état du générateur aléatoire est sauvegardé lors de l'extinction et
rechargé au démarrage suivant. Ça évite les problèmes de générateur
aléatoire qui part dans un état plus ou moins connu. Et le générateur
n'est réinitialisé qu'en cas de crash système pour lequel le fichier est
inexistant.

Cordialement,

JKB

Re: Quelle stratégie contre le vol d'un serveur ?

[andre_debian]

On Monday 07 May 2018 17:44:20 Pierre Malard wrote:
> Sinon, je serait très intéressé pour avoir des sources sur la répartition
> réelle GNU/Linux vs Windows. Les 50% annoncés, d’où viennent ils ?

En 2015, soit 3 ans :
"Serveurs : Windows Server détient 30% des parts de marché derrière Linux 
avec 38%. BSD est à 1% et les autres basés sur Unix se maintiennent vers les 
30%. Ces chiffres peuvent varier suivant le type de serveur analysé " :
https://mavielinux.com/2015/06/04/les-parts-de-marche-de-linux-en-mai-2015/

"À la domination de Microsoft sur le poste de travail répond une domination de 
Linux du côté serveur, et dans le Cloud. On peut l'estimer à 90%" :
www.journaldunet.com/solutions/expert/51207/l-ecrasante-domination-de-linux-dans-le-cloud---vers-90--de-part-de-marche.shtml

Linux à 50% en 2016 (2 ans) :
www.developpez.com/actu/101333/Spiceworks-au-moins-une-entreprise-sur-deux-dans-le-monde-utilise-encore-Windows-Server-2003-quels-systemes-serveur-utilisez-vous-en-entreprise/

Les gros calculateurs sont tous sous Linux.

C'est clair, depuis 2 ans à 3 ans, microsoft a perdu la bataille
de l'informatique professionnelle au profit de Linux,
et celle des smartphones au profit d'Android.

Malheureusement, en postes de travail, windows reste majoritaire,
à la communauté du Libre de le rendre minoritaire.

André

Re: longue attente au boot [résolu]

[Frédéric Baldit]

Bonjour,

merci aux deux personnes ayant répondu: en effet je comprends mieux
pourquoi le système est si long à démarrer, c'est maintenant assez
clair.

J'ai adoptée la solution la plus rapide: installation de la version
précédente du noyau (9.0.5) et ça marche!

Rq: je suis quand même étonné, étant donné l'importance de la qualité
des générateurs aléatoires pour tout ce qui concerne la sécurité (du
système en général), que celui implanté dans le noyau linux ne génère
pas des nombres de qualité (aléatoire) suffisante, et ceci  en un temps
qui ne pénalise pas la rapidité du démarrage. Ceci dit, je me doute que
le problème est plus complexe que ça...et que je dois n'avoir qu'une
idée très incomplète de la complexité de la situation.

Merci à vous deux,
--
  Frédéric Baldit

Le lun. 07 mai 2018 à 17:45:38 +
Eric Degenetais  a écrit:

> D'après ce que j'ai compris, le traitement proposé repose sur deux
> pistes extérieures au noyau :
> 1) vérifier s'il y a vraiment besoin d'un nombre aléatoire de qualité,
> sinon utiliser un autre appel système
> 2) utiliser le bootloader pour conserver l'entropie lors d'un reboot
> pour que le générateur soit plus rapidement près sans sacrifier la
> sécurité
> 
> Éric Dégenètais
> 
> Le 7 mai 2018 17:42,  a écrit :
> 
> Bonjour,
> 
> C'est un bug lié au fonctionnement du générateur d'entropie du
> noyau... Un bug est ouvert mais apparemment ça ne sera pas corrigé
> sur le noyau car ça corrige une faille de sécu mais dans les
> programmes en espace utilisateur (en gros, ton système attend qu'il y
> ait assez d'entropie pour démarrer gdm).
> 
> Tu peux booter sur l'ancien noyau en attendant.
> 
> Julien

Re: Reboot électrique distant

[Marc Jean]

Il existe des boitiers de télécommande de chauffage, qui se branchent 
entre la prise murale et le cordon de ton appareil, qui fonctionnent 
avec une carte SIM (faut un abonnement minimum, genre à 2€ par mois). 
Certains peuvent avoir un ou deux adaptateurs satellites.


On envoie un code de commande par sms. J'en ai un qui envoie un sms en 
cas de coupure de courant. En prime j'ai en retour température ambiante.


Si ton bios est paramétré pour que l'ordinateur démarre au retour du 
courant, ça permet le hard reboot brutal.


Aucune programmation nécessaire.

Le 07/05/2018 à 23:15, kaliderus a écrit :

Je cherche une solution pour rebooter électriquement (comme dans
l'ancien temps) quelques équipements à distance (une box et 2 ou 3
autres bricoles).

Re: Quelle stratégie contre le vol d'un serveur ?

[Jérôme]

On Mon, 7 May 2018 17:44:20 +0200
Pierre Malard  a écrit :

> Ou plus simplement pour ne pas susciter de stériles challenges… Genre
> « j’en ai une plus longue que la tienne ».
> 
> Sinon, je serait très intéressé pour avoir des sources sur la répartition
> réelle GNU/Linux vs Windows. Les 50% annoncés, d’où viennent ils ?
> 
> Cordialement

C'est très facile pour les serveurs web, il suffit de les interroger.
Contrairement aux postes clients, s'ils donnent plus ou moins de détails
selon les réglages, ils ne se font pas passer pour des windows XP ;)

Après, pour les serveurs hors web, je suppose qu'ils font des enquêtes comme
tout le monde quand on fait des stats. Il y en a qui doivent avoir des
chiffres plus précis et détaillés, grâce a l'espionnage généralisé (qui n'a
rien a voir avec l'espionnage industriel, juré-craché), encore faut-il avoir
la capacité a tirer des informations pertinentes au tsunami de données
générées, il y a un goulet d'étranglement au niveau des interfaces
chaises-claviers entre autres...

Je ne connais pas la précisions des résultats et surtout la méthodologie
employée ce qui est le plus important pour qu'une publication de
statistiques ait une quelconque valeur non pifométrique :

- Méthode de collecte, échantillon
- Serveur sur le web (facile a trouver) ou dans un réseau (demande une
  enquête de terrain, et le terrain comprend quels pays ?).
- C'est quoi un serveur ? Matériel, logique ? Une machine
  virtuelle, une mini-machine en grappe comme les caissons de chez Google ?
  Un serveur de mails ? de base de donnée ? la réponse est de moins
  en moins évidente et ne se satisfait pas du tout d'un unique chiffre dans un
  titre de journaleux.

...

Si on se fie au passé, les enquêtes on systématiquement caviardé les
résultats et la méthodologie utilisée pour pénaliser Linux par rapport a des
clients plus rémunérateurs... donc s'ils disent 50% ça ne risque pas d'être
moins et peut être beaucoup plus, ce que je crois.

Re: Reboot électrique distant

[Daniel Huhardeaux]

Le 07/05/2018 à 23:15, kaliderus a écrit :

Bonsoir,
Bonjour,


Bonjour



Je cherche une solution pour rebooter électriquement (comme dans
l'ancien temps) quelques équipements à distance (une box et 2 ou 3
autres bricoles).

Avec ceci par exemple ?
https://support.usr.com/products/remotemanagement/console-server-product.asp?sku=USR4204#

Mais avec ce truc (je ne sais même pas comment l'appeler en Français),
est-ce que je vais pouvoir établir une communication analogique (comme
dans l'ancien temps) avec le modem qui lui sera collé au derrière,
sachant que je suis avec Free en dégroupé.

Ou un switch administrable, et dans ce cas, je suis tributaire de la
présence d'un réseau ip bien accessible et adéquatement configuré.

Je me tâte, si vous avez d'autres
pistes/conseils/tuyaux/infos/idées/ou/que/sais/je j'en serai
heureux...

Il existe des boitiers de reboot à distance via carte SIM. Les ordres 
sont transmis via SMS. Attention: tous les opérateurs grand public 
n'autorisent pas l'usage de leurs cartes à de telles fins.


--
Daniel

Re: Reboot électrique distant

[Yann Serre]

Le 08/05/2018 à 12:24, chris navas a écrit :

Bonjour,

y a très longtemps j'utiliser la detection de sonnerie pour piloter un 
relais j'ai plus le montage

mais un truc du genre pourrait tres bien faire l'affaire

http://www.sonelec-musique.com/electronique_realisations_ligne_tel_detection_sonnerie.html
et/ou
http://www.sonelec-musique.com/electronique_realisations_ligne_tel_repetiteur_sonnerie_001.html

Belle journée,
Chris.


Avec quand-même quelques conditions :
- avoir une ligne analogique :)
- avoir un dispositif qui est capable de reconnaitre un code (on ne va 
pas rebooter la box + le serveur à chaque appel téléphonique)


Si le code est un nombre de sonneries, ce n'est pas très fiable.
Si le code c'est plusieurs appels successifs avec un nombre de sonneries 
(combinaison), ça devient un peu lourd comme principe !
Si le dispositif implique un décrochage et l'analyse de signaux DTMF, on 
se prive de répondeur et c'est une technique en voie de disparition...


Comme on a une Freebox et qu'on peut déjà la rebooter à distance, on va 
plutôt passer par internet pour rebooter le serveur qui est derrière ?
Parce que si on n'a plus de liaison internet, on a plus besoin de 
rebooter un serveur ;)

Re: Reboot électrique distant

[Yann Serre]

Bonjour

As-tu cherché du côté d'Arduino ?

Le plus simple est de lire une information dans un fichier hébergé sur 
un site web (l'Arduino utilise la box pour lire ce fichier, toutes les 
5mn par exemple)


http://www.devsector.ch/cavimaster/2014/04/prise-230v-commandee-par-internet-arduino-relais/

Le principe est d'envoyer un ordre. Mais sans confirmation de réception 
et de bonne exécution en retour !


Le pilotage le plus rustique est de déposer le fichier contenant l'ordre 
de reboot via ftp, attendre entre 10mn, puis le remplacer par le fichier 
sans ordre de reboot.


L'Arduino, s'il ne trouve pas de fichier (ou s'il trouve le fichier sans 
ordre de reboot) ne fait rien.

Si l'Arduino trouve l'ordre de reboot :
- il actionne son relais (position "arret du courant")
- attend 3 secondes
- replace le relais en position "marche"
- attend 15mn avant de se remettre lire à nouveau le fichier distant 
toutes les 5mn.


Adaptation hardware pour minimiser la consommation : utiliser la broche 
"repos" du relais pour établir le courant et laisser la broche "travail" 
déconnectée.


C'est une des solutions les moins coûteuses.
Comme ce besoin de reboot est rare, le principe d'attendre 10mn ne me 
semble pas pénalisant.


***

Plus coûteux (en énergie électrique aussi -> 1A) serait de faire tourner 
un serveur web sur un Raspberry (Raspbian) et utiliser la redirection de 
port de la Freebox pour accéder à une page de commande depuis l'extérieur.


On se connecte à distance (login/mot de passe/fail2ban).
(http://ip.de.ma.freebox:port/dossier_reboot...)
On commande un relais connecté au Raspberry
(3,3V => transitor => relais).

Dans ce cas on peut aussi ajouter en entrée des capteurs qui permettent 
de vérifier l'état des appareils connectés (détection de courant, 
température,...) et on a donc des informations en retour sur l'état de 
son installation.


***

Bonne journée




Le 07/05/2018 à 23:15, kaliderus a écrit :

Bonsoir,
Bonjour,

Je cherche une solution pour rebooter électriquement (comme dans
l'ancien temps) quelques équipements à distance (une box et 2 ou 3
autres bricoles).

Avec ceci par exemple ?
https://support.usr.com/products/remotemanagement/console-server-product.asp?sku=USR4204#

Mais avec ce truc (je ne sais même pas comment l'appeler en Français),
est-ce que je vais pouvoir établir une communication analogique (comme
dans l'ancien temps) avec le modem qui lui sera collé au derrière,
sachant que je suis avec Free en dégroupé.

Ou un switch administrable, et dans ce cas, je suis tributaire de la
présence d'un réseau ip bien accessible et adéquatement configuré.

Je me tâte, si vous avez d'autres
pistes/conseils/tuyaux/infos/idées/ou/que/sais/je j'en serai
heureux...

Merci.

Re: Ajout d'une route sur une interface virtuelle

[Pascal Hambourg]

Salut Fred,

Le 07/05/2018 à 22:25, Frederic Zulian a écrit :


J'ai une Freebox en mode routeur avec un PC portable faisant office de
serveur Web.​

Je souhaite transformer mon pc portable en routeur et mettre la Freebox en
bridge.


Pour quelle raison ?


Est-il techniquement possible de passer ma Freebox en bridge puis de
transformer le PC portable en routeur
en utilisant sa seule interface physique.


Oui, mais il y a des contraintes.


Dans ce cas il y aurait sur la même interface physique trois interfaces
virtuelles  :

- eth0 ou enp2s0  avec mon ip  publique

- eth0:1 192.168.1.x


eth0:1 n'est pas une interface virtuelle mais un "alias IP", une simple 
étiquette associée à une adresse IPv4 (ça n'existe pas pour IPv6) 
additionnelle configurée sur eth0 pour des raisons historiques, ifconfig 
ne gérant pas plusieurs adresses IPv4 sur une même interface. Pour le 
routage, iptables, etc. ça n'existe pas ; seule eth0 existe avec ses 
deux adresses IP.



- tunl0 en 44.151.31.x


Qu'est-ce que c'est ? Un VPN ?
En tout cas ce n'est pas concerné


D'ou la question  est-ce que le routage peut-être fonctionnel avec une
seule carte réseau ?


Oui, mais...
Si les deux adresses sont utilisées sur l'interface brute, alors les 
deux réseaux IP seront portés par le même réseau ethernet.

Conséquences :
- La box voit le trafic du LAN  (au moins le broadcast).
- Le filtrage et NAT des paquets par iptables sera moins fiable car il 
ne pourra se baser sur les interfaces d'entrée et de sortie pour 
distinguer l'origine et la destination du trafic.
- Si un serveur DHCP tourne sur le PC portable routeur, il y aura deux 
serveurs DHCP sur le réseau avec celui de la box.
- L'interface de sortie étant égale à l'interface d'entrée, le routeur 
peut envoyer des messages ICMP "redirect" pour informer l'émetteur d'un 
paquet qu'il existe un chemin plus direct. Si l'émetteur en tient compte 
et envoie directement les paquets au noeud suivant, cela court-circuite 
le routeur et ses règles de filtrage et NAT.


L'utilisation de VLAN permettrait de séparer logiquement le trafic des 
deux réseaux, avec un switch "intelligent" ou directement entre les 
machines.