Re: Conseils sur la configuration DNS d'un serveur

2023-09-22 Par sujet Stephane Bortzmeyer 
On Fri, Sep 22, 2023 at 05:19:08PM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 13 lines which said:

> Oui. Cloudflare 1.1.1.1 ne fait pas autrement, il n'a pas de
> privilège particulier, il parle aux serveurs faisant autorité, comme
> le fait le résolveur public de FDN, ou comme le fait le petit
> résolveur Knot qui est chez moi.

La preuve avec dig. Voici la requête qu'un résolveur enverrait à un
des serveurs faisant autorité pour .fr, le d.nic.fr. La réponse arrive
bien, alors qu'elle est partie d'une petite machine Debian ordinaire, bêtement
connectée à un FAI grand public (Free) :

% dig +dnssec +norecurse @d.nic.fr www.paypal.fr 

; <<>> DiG 9.18.16-1-Debian <<>> +dnssec +norecurse @d.nic.fr www.paypal.fr 
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44594
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 55a74fbb3177a8130100650db3019fb5c6c75bc88734 (good)
;; QUESTION SECTION:
;www.paypal.fr. IN 

;; AUTHORITY SECTION:
paypal.fr.  3600 IN NS ns1.p57.dynect.net.
paypal.fr.  3600 IN NS pdns100.ultradns.net.
paypal.fr.  3600 IN NS pdns100.ultradns.com.
paypal.fr.  3600 IN NS ns2.p57.dynect.net.
paypal.fr.  3600 IN DS 49549 8 2 (
D99B0F323A7E1161CD598AA9ACDAC29235F6707D0E4A
C6EBC59FCB703E96AB63 )
paypal.fr.  3600 IN RRSIG DS 13 2 3600 (
20231126092821 20230915144228 60747 fr.
UouuMe6fve2zA8wRqaJCWXoPqjFDh0XafGdfwQ5sM65a
eRJotF77ify6lIXaYkt9iT0XueXYMDCRjeXafdBIzg== )

;; Query time: 0 msec
;; SERVER: 2001:678:c::1#53(d.nic.fr) (UDP)
;; WHEN: Fri Sep 22 15:30:09 UTC 2023
;; MSG SIZE  rcvd: 334

Re: Conseils sur la configuration DNS d'un serveur

2023-09-22 Par sujet Stephane Bortzmeyer 
On Fri, Sep 22, 2023 at 04:49:07PM +0200,
 Olivier  wrote 
 a message of 10 lines which said:

> Quand on installe sur sa machine, un logiciel comme Unbound, celui-ci
> sait-il directement interroger les serveurs DNS centraux qui gèrent
> les .com, .fr et autres  (ie sans passer par les serveurs comme
> 1.1.1.1 ou autres ) ?

Oui. Cloudflare 1.1.1.1 ne fait pas autrement, il n'a pas de privilège
particulier, il parle aux serveurs faisant autorité, comme le fait le
résolveur public de FDN, ou comme le fait le petit résolveur Knot qui
est chez moi.

Re: Conseils sur la configuration DNS d'un serveur

2023-09-22 Par sujet Stephane Bortzmeyer 
On Fri, Sep 22, 2023 at 04:55:05PM +0200,
 Olivier  wrote 
 a message of 11 lines which said:

> > Et pas besoin de passer par quad9 ou cloudflare bind peut forwarder en
> > direct.
> >
> Je n'avais pas compris que c'était possible !

Tout le monde peut installer un vrai résolveur (qui parle directement
aux serveurs faisant autorité). Enfin, pour l'instant : parions que le
gouvernement va proposer une loi pour interdire cela.

Re: Conseils sur la configuration DNS d'un serveur

2023-09-22 Par sujet Olivier 
Le ven. 22 sept. 2023 à 15:20, Michel Verdier  a écrit :

>

> Et pas besoin de passer par quad9 ou cloudflare bind peut forwarder en
> direct.
>
Je n'avais pas compris que c'était possible !
Merci à Michel et Stéphane pour leur réponse qui change pas mal de choses.

Re: Conseils sur la configuration DNS d'un serveur

2023-09-22 Par sujet Olivier 
Le ven. 22 sept. 2023 à 15:03, Stephane Bortzmeyer
 a écrit :
> - pourquoi d'ailleurs utiliser un résolveur en aval, plutôt que de
> parler directement aux serveurs faisant autorité ?

Quand on installe sur sa machine, un logiciel comme Unbound, celui-ci
sait-il directement interroger les serveurs DNS centraux qui gèrent
les .com, .fr et autres  (ie sans passer par les serveurs comme
1.1.1.1 ou autres ) ?

Re: Conseils sur la configuration DNS d'un serveur

2023-09-22 Par sujet Stephane Bortzmeyer 
On Fri, Sep 22, 2023 at 11:01:52AM +0200,
 Olivier  wrote 
 a message of 48 lines which said:

> - pour chaque VLAN, j'aimerai pouvoir désigner un fichier
> /etc/hosts.vlanx dans lequel je liste quelques ressources locales
> (imprimante, ...) pouvant être résolues.

Hmmm, ça va sérieusement compliquer les choses (et le déboguage !). À
part avec les vues, je ne vois pas comment faire.

> Vis à vis du DNS amont, j'utilise un fichier /etc/resolv.conf dont le
> contenu est:
> options rotate timeout:1 retries:1
> search monsuperdomain.lan
> nameserver 1.1.1.1
> nameserver 9.9.9.9

Alors, quatre remarques :

- pourquoi utiliser des résolveurs étatsuniens qui font Dieu sait quoi
des données récoltées ?
- pourquoi d'ailleurs utiliser un résolveur en aval, plutôt que de
parler directement aux serveurs faisant autorité ?
- /etc/resolv.conf est pour les clients finaux, pas pour un résolveur,
- avoir à la fois un résolveur non menteur et un menteur va être assez
cauchemardesque pour le déboguage.

> 1. Préférez-vous séparer le paramétrage DNS amont (/etc/resolv.conf)
> de celui en aval ?

Pas clair. Pas compris.

> 2. Activer le DNSSEC engendre-t-il des difficultés pour
> l'exploitant ?

On est en 2023, tous les résolveurs sérieux valident avec DNSSEC.

> Les utilisateurs lambda perçoivent-ils selon vous, des bénéfices ou
> des inconvénients ?

Bénéfice : sécurité
Inconvénient : comme toutes les techniques de sécurité, ça peut
bloquer des accès légitimes

> 3. Quand on sert des utilisateurs qui consomment du Netflix, TikTok
> ou youtube, faut-il attendre des bénéfices avec du cache DNS (par
> rapport à une configuration où les utilisateurs interrogent
> directement des DNS publics) ?

Tester. (En administration système, il faut mesurer, pas supposer.)

> 4. Conseillez-vous unbound ? Si non, quelle alternative ?

Unbound est très bien, mais Knot Resolver aussi.

Re: Conseils sur la configuration DNS d'un serveur

2023-09-22 Par sujet Stephane Bortzmeyer 
On Fri, Sep 22, 2023 at 02:02:36PM +0200,
 Michel Verdier  wrote 
 a message of 31 lines which said:

> > 4. Conseillez-vous unbound ? Si non, quelle alternative ?
> 
> bind9 est quand même LE serveur DNS.

En 2023, c'est une affirmation très bizarre. Cela fait de nombreuses
années qu'il existe de meilleurs logiciels. BIND est utile dans deux
cas :
- si on veut une option très exotique qui n'existe que sur BIND,
- si on aime les patches de sécurité à appliquer en urgence tous les mois.

> - forwarder en servant de cache

Comem tous les résolveurs (encore heureux).

> - mettre DNSSEC

Comme tous les résolveurs (encore heureux).

> Et pas besoin de passer par quad9 ou cloudflare bind peut forwarder en
> direct.

Comme tous les résolveurs (encore heureux).

Re: Conseils sur la configuration DNS d'un serveur

2023-09-22 Par sujet Michel Verdier 
Le 22 septembre 2023 Olivier a écrit :

> 3. Quand on sert des utilisateurs qui consomment du Netflix, TikTok ou
> youtube, faut-il attendre des bénéfices avec du cache DNS (par rapport
> à une configuration où les utilisateurs interrogent directement des
> DNS publics) ?

un cache accélère nettement

$ dig @cache netflix.com

premier appel :

;; Query time: 11 msec

deuxième appel :

;; Query time: 2 msec

>
> 4. Conseillez-vous unbound ? Si non, quelle alternative ?

bind9 est quand même LE serveur DNS. Il permet de
- forwarder en servant de cache
- servir des zones internes selon le vlan avec les views ce qui
dispense des /etc/hosts
- mettre DNSSEC
Et pas besoin de passer par quad9 ou cloudflare bind peut forwarder en
direct.

Conseils sur la configuration DNS d'un serveur

2023-09-22 Par sujet Olivier 
Bonjour,

J'ai besoin d'implémenter un serveur (sous Bullseye pour l'instant)
qui va faire office de cache DNS pour les machines de réseaux locaux
(une centaine de machines réparties dans plusieurs VLAN).
Une précision importante: je ne maîtrise pas ces machines réparties
dans plusieurs VLAN: il peut s'agir de smartphones, PC ou console de
tout type.

Mes besoins:
- pour chaque VLAN, j'aimerai pouvoir désigner un fichier
/etc/hosts.vlanx dans lequel je liste quelques ressources locales
(imprimante, ...) pouvant être résolues.

- si l'existence de cache DNS accélère la résolution DNS des machines
du réseau local, tant mieux, sinon c'est pas grave.

Vis à vis du DNS amont, j'utilise un fichier /etc/resolv.conf dont le
contenu est:
options rotate timeout:1 retries:1
search monsuperdomain.lan
nameserver 1.1.1.1
nameserver 9.9.9.9

Je découvre unbound qui m'a l'air de bien coller à mes besoins. Mes questions:

1. Préférez-vous séparer le paramétrage DNS amont (/etc/resolv.conf)
de celui en aval ?

2. Activer le DNSSEC engendre-t-il des difficultés pour l'exploitant ?
Les utilisateurs lambda perçoivent-ils selon vous, des bénéfices ou
des inconvénients ?

3. Quand on sert des utilisateurs qui consomment du Netflix, TikTok ou
youtube, faut-il attendre des bénéfices avec du cache DNS (par rapport
à une configuration où les utilisateurs interrogent directement des
DNS publics) ?

4. Conseillez-vous unbound ? Si non, quelle alternative ?

Slts

Re: [HS] imprimante laser sans wifi et conseils achat

2023-07-07 Par sujet didier gaumet 

Le 06/07/2023 à 23:33, ajh-valmer a écrit :


J'en profite alors :
Quelle imprimante laser couleurs, wifi, scanner, me conseillez vous ?
(le prix des cartouches est important et sa bonne compatibilité Linux).
Merci.
Bonne fin de soirée,


- concernant le choix d'une laser couleur, Bernard t'a indiqué un 
comparatif, tu peux en chercher d'autres pour compléter le panorama


- perso j'ai un combo laser/scanner mais pas couleur (n), j'ai pris 
une laser parce que j'imprime peu souvent et avec une jet d'encre 
classique à cartouche (pas les jets d'encre à réservoirs d'encre, 
généralement ça ne sèche pas mais elle sont largement plus chères)


- au niveau fiabilité même si jusqu'à présent je n'ai jamais eu de pb à 
ce niveau avec une imprimante/scanner, je pense que c'est la même chose 
qu'avec les ordinateurs: pour une meilleure fiabilité privilégier les 
modèles destinés aux professionnels, même TPE


- au niveau coût, avec une laser, une idée reçue est que ça coûte moins 
cher à la page qu'une jet d'encre mais ça dépend beaucoup de la gamme 
d'imprimantes, du toner ou des cartouches/réservoirs et volume 
d'impressions à effectuer dur une période donnée. En clair les laser ne 
sont pas toujours moins chères en coût à la page, loin de là. Et il faut 
regarder le coût de remplacement du toner de l'imprimante envisagée 
avant d'acheter celle-ci: pour les gammes "consommateur" les toners sont 
généralement largement plus chers, me semble-t-il


- Autre coût: la consommation électrique, au repos, comme à 
l'impression, est beaucoup plus faible avec une jet d'encre qu'avec une 
laser.


Conclusion perso, dans mon cas, un petit combo laser/scanner HP N 
(gamme MFP) me convient, mais si j'imprimais plus ou que j'avais décidé 
d'investir plus à l'achat et moins à l'entretien, j'aurais probablement 
pris une jet d'encre à réservoirs d'encre liquide

Re: [HS] imprimante laser sans wifi et conseils achat

2023-07-06 Par sujet Frederic Zulian 
La lexmark est fournie avec  son  pilote en .deb

Frédéric ZULIAN



Le ven. 7 juil. 2023 à 00:39, Bernard Schoenacker <
bernard.schoenac...@free.fr> a écrit :

> Hallo,
>
> Die wache hat etwas gefunden :
>
>
> https://www.futura-sciences.com/tech/comparatifs/meilleure-imprimante-laser-couleur-comparatif/
>
> mfg
>
> Bernard
>
>
> - Mail original -
> De: "ajh-valmer" 
> À: debian-user-french@lists.debian.org
> Envoyé: Jeudi 6 Juillet 2023 23:33:32
> Objet: Re: [HS] imprimante laser sans wifi et conseils achat
>
> On Wednesday 05 July 2023 09:26:27 didier gaumet wrote:
> > Pour compléter la réponse de François avec de possibles alternatives:
> > - utiliser un adaptateur wifi ethernet (chercher ça sur Amazon donne des
> > pistes pour voir ce qui existe même si on achète ailleurs)
> > - utiliser un routeur ou répéteur wifi avec prise ethernet
> > - utiliser un truc minimaliste genre Raspberry Pi sur lequel on installe
> > ce qu'il faut pour servir de serveur de scan et d'impression
>
> J'en profite alors :
> Quelle imprimante laser couleurs, wifi, scanner, me conseillez vous ?
> (le prix des cartouches est important et sa bonne compatibilité Linux).
> Merci.
> Bonne fin de soirée,
>
>

Re: [HS] imprimante laser sans wifi et conseils achat

2023-07-06 Par sujet Bernard Schoenacker 
Hallo,

Die wache hat etwas gefunden :

https://www.futura-sciences.com/tech/comparatifs/meilleure-imprimante-laser-couleur-comparatif/

mfg 

Bernard


- Mail original -
De: "ajh-valmer" 
À: debian-user-french@lists.debian.org
Envoyé: Jeudi 6 Juillet 2023 23:33:32
Objet: Re: [HS] imprimante laser sans wifi et conseils achat

On Wednesday 05 July 2023 09:26:27 didier gaumet wrote:
> Pour compléter la réponse de François avec de possibles alternatives:
> - utiliser un adaptateur wifi ethernet (chercher ça sur Amazon donne des 
> pistes pour voir ce qui existe même si on achète ailleurs)
> - utiliser un routeur ou répéteur wifi avec prise ethernet
> - utiliser un truc minimaliste genre Raspberry Pi sur lequel on installe 
> ce qu'il faut pour servir de serveur de scan et d'impression

J'en profite alors :
Quelle imprimante laser couleurs, wifi, scanner, me conseillez vous ?
(le prix des cartouches est important et sa bonne compatibilité Linux).
Merci.
Bonne fin de soirée,

Re: [HS] imprimante laser sans wifi et conseils achat

2023-07-06 Par sujet ajh-valmer 
On Wednesday 05 July 2023 09:26:27 didier gaumet wrote:
> Pour compléter la réponse de François avec de possibles alternatives:
> - utiliser un adaptateur wifi ethernet (chercher ça sur Amazon donne des 
> pistes pour voir ce qui existe même si on achète ailleurs)
> - utiliser un routeur ou répéteur wifi avec prise ethernet
> - utiliser un truc minimaliste genre Raspberry Pi sur lequel on installe 
> ce qu'il faut pour servir de serveur de scan et d'impression

J'en profite alors :
Quelle imprimante laser couleurs, wifi, scanner, me conseillez vous ?
(le prix des cartouches est important et sa bonne compatibilité Linux).
Merci.
Bonne fin de soirée,

Re: Conseils sur PXE pour l'installation de serveurs

2022-12-15 Par sujet Olivier 
J'ai pu initialiser ce matin, ma première machine en utilisant PXE et preseed.
La seule action qu'il me reste à faire au clavier est de sélectionner
l'option PXE/Pressed que j'ai ajoutée à celles de l'installeur Debian
: presque tout le reste est choisi automatiquement sans action de ma
part.

1. Objectivement, la seule chose qui me gêne maintenant est le partitionnement.

J'ai supposé n'avoir à chaque qu'un unique disque, utiliser en totalité.
Je le partitionne avec LVM, en swap, /root, /usr, /var, /home et /tmp
en utilisant l'algo par défaut de l'installeur.
Le seul point qui me gène dans cette procédure est que la taille de
/var est nettement plus petite que celle de /home.
Pour des serveurs, j'ai très souvent eu besoin d'avoir des partitions
/home et /var de même taille.

Pour palier à cette limitation, j'ai une clé system-rescue avec
laquelle je sais importer et exécuter un programme qui église les
tailles de /home et /var (ie qui diminue /home au profit de /var).

Idéalement, je préférerai remplacer l'utilisation de  system-rescue
par des paramètres dans mon fichier preseed.

2. Autre point à améliorer

J'aimerai avoir une procédure rigoureuse pour identifier les firmwares
qui manquent.
Aujourd'hui, je vais parcourir rapidement le contenu de dmesg mais
c'est fastidieux.


Le sam. 10 déc. 2022 à 21:15, Erwann Le Bras
 a écrit :
>
> bonsoir
>
> à mon sens, c'est une très bonne idée d'utiliser un serveur PXE pour des 
> installations car cela évite de s’embêter avec un jeu de CD ou de clé USB.
> Enfin, si le client le permet. A part des modèles antediliviens, tous savent 
> démarrer en PXE.
>
> PXE sert pour l'amorçage ; une fois démarré, on se retrouve comme si on avait 
> démarré sur une clé USB ou sur un CD. D'ailleurs, PXE permet de télécharger, 
> monter et booter directement sur un ISO (mais attention à sa taille il est 
> téléchargé et monté en RAM).
>
> Le client a tout ce qu'il faut en natif pour rechercher et booter sur un 
> serveur PXE présent.
>
> Le serveur PXE présente au client un menu (pour choisir le système à 
> démarrer) ou a des consignes pour que le client télécharge directement une 
> amorce, par TFTP, HTTP ou NFS le plus souvent.
>
> Une fois cette amorce chargé, le reste du démarrage continue comme pour un CD 
> ; donc oui, à mon sens, il est possible de faire tout ce que le démarrage  
> "standard" prévoit.
>
> Debian propose un kit d'install prévu pour être démarré par PXE. Il suffit de 
> le télécharger et d'indiquer au serveur de démarrer dessus.
> On les trouve par exemple sur 
> https://pkgmaster.devuan.org/devuan/dists/beowulf/main/installer/current/images/netboot
>
> amuse-toi bien
>
> Erwann
>
> Le 08/12/2022 à 18:19, Olivier a écrit :
>
> Bonjour,
>
> Je souhaite me lancer dans l'utilisation du PXE pour initialiser des
> serveurs x86 classiques le permettant.
>
> Actuellement, j'initialise ces serveurs en utilisant une clé USB sur
> laquelle j'ai copié un fichier ISO comme celui en [1].
>
> Pour l'initialisation par PXE, j'ai compris qu'il fallait utiliser un
> fichier du type netboot.tar.gz à la place de ces fichiers ISO.
>
> 1. Existe-t-il de tels fichiers netboot.tar.gz incluant aussi les
> firmware exotiques pour le cas où le serveur en aurait besoin ?
>
> 2. Beaucoup de machines savent démarrer en mode EFI ou en mode Legacy.
> C'est souvent configurable au niveau du BIOS.
> Je n'ai pas de connaissance des enjeux liés à ce choix.
> Quels sont-ils ?
>  Y a-t-il des précautions particulières à prendre à cet égard (en
> sélectionnant via le BIOS, le mode EFI ou Legacy) ou bien on ne risque
> pas grand chose à laisser le hasard faire les choses (ie on prépare le
> serveur PXE pour qu'il sache répondre à tout type de demande (EFI,
> ...) ?
>
> 3. J'ai l'habitude de fournir un fichier preseed.cfg volontairement
> incomplet quand j'installe par clé USB. Les réponses non renseignées
> dans le fichier preseed.cfg sont demandées à l'écran.
> A-t-on toujours cette possibilité avec PXE ou bien faut-il
> impérativement répondre à toutes les questions.
>
> 4. Il m'est arrivé (rarement, heureusement) de rencontrer des serveurs
> NUC dont l'interface réseau était mal supportée par Stretch.
> Est-il possible de lancer une initialisation par PXE sur un adaptateur
> réseau externe (sur port USB) (je n'ai jamais vu ce type d'option mais
> sait-on jamais)
>
> [1] 
> https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.5.0+nonfree/multi-arch/iso-cd/firmware-11.5.0-amd64-i386-netinst.iso
>
> Slts
>

Re: Conseils sur PXE pour l'installation de serveurs

2022-12-10 Par sujet Erwann Le Bras 

bonsoir

à mon sens, c'est une très bonne idée d'utiliser un serveur PXE pour des 
installations car cela évite de s’embêter avec un jeu de CD ou de clé USB.
Enfin, si le client le permet. A part des modèles antediliviens, tous 
savent démarrer en PXE.


PXE sert pour l'amorçage ; une fois démarré, on se retrouve comme si on 
avait démarré sur une clé USB ou sur un CD. D'ailleurs, PXE permet de 
télécharger, monter et booter directement sur un ISO (mais attention à 
sa taille il est téléchargé et monté en RAM).


Le client a tout ce qu'il faut en natif pour rechercher et booter sur un 
serveur PXE présent.


Le serveur PXE présente au client un menu (pour choisir le système à 
démarrer) ou a des consignes pour que le client télécharge directement 
une amorce, par TFTP, HTTP ou NFS le plus souvent.


Une fois cette amorce chargé, le reste du démarrage continue comme pour 
un CD ; donc oui, à mon sens, il est possible de faire tout ce que le 
démarrage  "standard" prévoit.


Debian propose un kit d'install prévu pour être démarré par PXE. Il 
suffit de le télécharger et d'indiquer au serveur de démarrer dessus.
On les trouve par exemple sur 
https://pkgmaster.devuan.org/devuan/dists/beowulf/main/installer/current/images/netboot


amuse-toi bien

Erwann

Le 08/12/2022 à 18:19, Olivier a écrit :

Bonjour,

Je souhaite me lancer dans l'utilisation du PXE pour initialiser des
serveurs x86 classiques le permettant.

Actuellement, j'initialise ces serveurs en utilisant une clé USB sur
laquelle j'ai copié un fichier ISO comme celui en [1].

Pour l'initialisation par PXE, j'ai compris qu'il fallait utiliser un
fichier du type netboot.tar.gz à la place de ces fichiers ISO.

1. Existe-t-il de tels fichiers netboot.tar.gz incluant aussi les
firmware exotiques pour le cas où le serveur en aurait besoin ?

2. Beaucoup de machines savent démarrer en mode EFI ou en mode Legacy.
C'est souvent configurable au niveau du BIOS.
Je n'ai pas de connaissance des enjeux liés à ce choix.
Quels sont-ils ?
  Y a-t-il des précautions particulières à prendre à cet égard (en
sélectionnant via le BIOS, le mode EFI ou Legacy) ou bien on ne risque
pas grand chose à laisser le hasard faire les choses (ie on prépare le
serveur PXE pour qu'il sache répondre à tout type de demande (EFI,
...) ?

3. J'ai l'habitude de fournir un fichier preseed.cfg volontairement
incomplet quand j'installe par clé USB. Les réponses non renseignées
dans le fichier preseed.cfg sont demandées à l'écran.
A-t-on toujours cette possibilité avec PXE ou bien faut-il
impérativement répondre à toutes les questions.

4. Il m'est arrivé (rarement, heureusement) de rencontrer des serveurs
NUC dont l'interface réseau était mal supportée par Stretch.
Est-il possible de lancer une initialisation par PXE sur un adaptateur
réseau externe (sur port USB) (je n'ai jamais vu ce type d'option mais
sait-on jamais)

[1]https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.5.0+nonfree/multi-arch/iso-cd/firmware-11.5.0-amd64-i386-netinst.iso

Slts

Conseils sur PXE pour l'installation de serveurs

2022-12-08 Par sujet Olivier 
Bonjour,

Je souhaite me lancer dans l'utilisation du PXE pour initialiser des
serveurs x86 classiques le permettant.

Actuellement, j'initialise ces serveurs en utilisant une clé USB sur
laquelle j'ai copié un fichier ISO comme celui en [1].

Pour l'initialisation par PXE, j'ai compris qu'il fallait utiliser un
fichier du type netboot.tar.gz à la place de ces fichiers ISO.

1. Existe-t-il de tels fichiers netboot.tar.gz incluant aussi les
firmware exotiques pour le cas où le serveur en aurait besoin ?

2. Beaucoup de machines savent démarrer en mode EFI ou en mode Legacy.
C'est souvent configurable au niveau du BIOS.
Je n'ai pas de connaissance des enjeux liés à ce choix.
Quels sont-ils ?
 Y a-t-il des précautions particulières à prendre à cet égard (en
sélectionnant via le BIOS, le mode EFI ou Legacy) ou bien on ne risque
pas grand chose à laisser le hasard faire les choses (ie on prépare le
serveur PXE pour qu'il sache répondre à tout type de demande (EFI,
...) ?

3. J'ai l'habitude de fournir un fichier preseed.cfg volontairement
incomplet quand j'installe par clé USB. Les réponses non renseignées
dans le fichier preseed.cfg sont demandées à l'écran.
A-t-on toujours cette possibilité avec PXE ou bien faut-il
impérativement répondre à toutes les questions.

4. Il m'est arrivé (rarement, heureusement) de rencontrer des serveurs
NUC dont l'interface réseau était mal supportée par Stretch.
Est-il possible de lancer une initialisation par PXE sur un adaptateur
réseau externe (sur port USB) (je n'ai jamais vu ce type d'option mais
sait-on jamais)

[1] 
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.5.0+nonfree/multi-arch/iso-cd/firmware-11.5.0-amd64-i386-netinst.iso

Slts

Re: Conseils pour dessiner sur ordinateur

2021-12-05 Par sujet Haricophile 
Le Fri, 03 Dec 2021 07:52:55 +0100,
Sébastien Dinot  a écrit :

> Plus petit ? Tiens, retour intéressant, mais divergent de ceux que
> j'ai eu jusqu'ici, qui allaient plutôt en faveur de tablettes de
> grande taille, permettant un geste ample.
> 
> Par curiosité, puis-je savoir ce qui te ferait privilégier aujourd'hui
> une tablette de taille plus réduite ?
> 
> Sébastien

La taille je pense que ça dépend de l'usage et de la personne: 

- Si tu travaille sur des images artistiques ça peut être pas mal
  d'utiliser une grande tablette (A4..) en utilisant des coordonnées
  absolues.

- Si tu travaille sur des mangas, tu travaille dans des cases et sur
  des petites surfaces à la fois, il y a des chances qu'utiliser des
  coordonnées relatives soient une meilleure option. Une tablette A5
  sera beaucoup plus manipulable (et transportable partout). 

Le premier critère est la qualité, et Wacom n'est pas le moins cher
mais reste une référence.

Voilà pour mon opinion personnelle qui n'engage que moi.

Re: Conseils pour dessiner sur ordinateur

2021-12-03 Par sujet Billard François-Marie 
En effet une grande tablette permet des gestes plus amples, mais dans 
mon cas l'usage est surtout pour du croquis et de la prise de note . 
Donc plus petite pour plus de mobilité et moins d'encombrement.


François-Marie

Le 03/12/2021 à 07:52, Sébastien Dinot a écrit :

Le 2021-12-03 07:31, Billard François-Marie a écrit :

Aujourd'hui je reprendrai un modèle équivalent mais sans doute plus
petit si besoin.


Plus petit ? Tiens, retour intéressant, mais divergent de ceux que j'ai
eu jusqu'ici, qui allaient plutôt en faveur de tablettes de grande
taille, permettant un geste ample.

Par curiosité, puis-je savoir ce qui te ferait privilégier aujourd'hui
une tablette de taille plus réduite ?

Sébastien

Re: Conseils pour dessiner sur ordinateur

2021-12-02 Par sujet Sébastien Dinot 

Le 2021-12-03 07:31, Billard François-Marie a écrit :

Aujourd'hui je reprendrai un modèle équivalent mais sans doute plus
petit si besoin.


Plus petit ? Tiens, retour intéressant, mais divergent de ceux que j'ai
eu jusqu'ici, qui allaient plutôt en faveur de tablettes de grande
taille, permettant un geste ample.

Par curiosité, puis-je savoir ce qui te ferait privilégier aujourd'hui
une tablette de taille plus réduite ?

Sébastien


--
Sébastien Dinot
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
https://www.palabritudes.net/

Re: Conseils pour dessiner sur ordinateur

2021-12-02 Par sujet Billard François-Marie 

Bonjour

l'achat d'une tablette Wacom A4 il y a quelques années en promotion m'a 
conforté dans le choix de cet outil. Il est compatible Linux sans 
problème avec des outils disponibles pour configurer les boutons de la 
tablette.


Je l'utilise avec Gimp, Inksccape essentiellement. Aujourd'hui je 
reprendrai un modèle équivalent mais sans doute plus petit si besoin.


Pour les manga Krita semble plus adapté.

Bon choix

François-Marie

Le 02/12/2021 à 21:51, Sébastien Dinot a écrit :

Bonsoir,

Je n'ai aucune expérience en la matière, mais je suis un fan de David
Revoy, de ses œuvres, de son approche libriste de son travail, de son
gout du partage (plutôt rare chez les graphistes) :

https://www.davidrevoy.com/

David utilise principalement Krita et il a même créé une collection de
brosses pour ce logiciel :

https://www.davidrevoy.com/categorie3/tutorials-brushes-extras

Bien évidemment, comme il vit de son art, il s'intéresse à du matériel
professionnel, dont le cout est déraisonnable pour un simple amateur :

https://www.davidrevoy.com/article842/review-of-the-xp-pen-artist-24-pro-on-linux

Mais il continue à utiliser aussi de vieilles tablettes, plus basiques
et abordables :

https://www.davidrevoy.com/article820/cintiq-or-intuos-or-both-the-tablets-i-use

Et il s'est même fendu d'un article sur l'ergonomie des tablettes :

https://www.davidrevoy.com/article30/ergonomics-of-graphics-tablets

Sébastien

Re: Conseils pour dessiner sur ordinateur

2021-12-02 Par sujet Sébastien Dinot 
Bonsoir,

Je n'ai aucune expérience en la matière, mais je suis un fan de David
Revoy, de ses œuvres, de son approche libriste de son travail, de son
gout du partage (plutôt rare chez les graphistes) :

https://www.davidrevoy.com/

David utilise principalement Krita et il a même créé une collection de
brosses pour ce logiciel :

https://www.davidrevoy.com/categorie3/tutorials-brushes-extras

Bien évidemment, comme il vit de son art, il s'intéresse à du matériel
professionnel, dont le cout est déraisonnable pour un simple amateur :

https://www.davidrevoy.com/article842/review-of-the-xp-pen-artist-24-pro-on-linux

Mais il continue à utiliser aussi de vieilles tablettes, plus basiques
et abordables :

https://www.davidrevoy.com/article820/cintiq-or-intuos-or-both-the-tablets-i-use

Et il s'est même fendu d'un article sur l'ergonomie des tablettes :

https://www.davidrevoy.com/article30/ergonomics-of-graphics-tablets

Sébastien


-- 
Sébastien Dinot, sebastien.di...@free.fr
http://www.palabritudes.net/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

Re: Conseils pour dessiner sur ordinateur

2021-12-02 Par sujet Basile Starynkevitch 



On 02/12/2021 17:13, Bernard Schoenacker wrote:

- Mail original -


De: "Olivier" 
À: "ML Debian User French" 
Envoyé: Jeudi 2 Décembre 2021 17:09:48
Objet: Conseils pour dessiner sur ordinateur
Bonjour,
Mon fils de 13 ans se passionne depuis peu pour le dessin et les
mangas. Il dessine sur papier uniquement.
Pour Noël, j'envisage de lui offrir une tablette graphique de type
Watcom.



J'ai une tablette Watcom. N'étant pas très doué pour le dessin, je m'en 
sers peu.



Il est déjà équipé d'un Raspberry 4 sous Raspbian (Buster).



Le détail important, c'est aussi quel écran.


1. Quel appareil choisir ? Quels sont les principaux critères à
prendre en compte ?
2. Quel logiciel choisir pour dessiner ?
3. Quel logiciel choisir pour dessiner une planche de bande dessinée
?
4. Avez-vous un retour d'expérience sur le passage du mode
papier-crayon au mode sur ordinateur ? Passé un stade
d'apprentissage, quel mode conserve la préférence des dessinateurs ?
L'apprentissage est-il difficile ?
Conseils et remarques ?



Il faut être patient. Et un dessin, ça s'imprime à un moment donné.


Slts

Bonjour Olivier,

Pour le dessin artistique, voici les solutions qui me
paraissent pertinentes

- Krita
- Karbon



NB. Hors sujet, mais professionnel: je cherche des partenaires 
HorizonEurope intéressés par http://refpersys.org/


(me contacter alors par courriel au boulot: basile.starynkevi...@cea.fr 
travaillant au https://www-list.cea.fr/ )



--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: Conseils pour dessiner sur ordinateur

2021-12-02 Par sujet Basile Starynkevitch 



On 02/12/2021 18:13, Basile Starynkevitch wrote:


On 02/12/2021 17:13, Bernard Schoenacker wrote:

- Mail original -


De: "Olivier" 
À: "ML Debian User French" 
Envoyé: Jeudi 2 Décembre 2021 17:09:48
Objet: Conseils pour dessiner sur ordinateur
Bonjour,
Mon fils de 13 ans se passionne depuis peu pour le dessin et les
mangas. Il dessine sur papier uniquement.
Pour Noël, j'envisage de lui offrir une tablette graphique de type
Watcom.



J'ai une tablette Watcom. N'étant pas très doué pour le dessin, je 
m'en sers peu.



Il est déjà équipé d'un Raspberry 4 sous Raspbian (Buster).



Le détail important, c'est aussi quel écran



J'ai oublié de dire que inkscape (une version récente) marche très bien 
avec ma tablette Wacom. Sur un ordinateur portable (i7, 32Go de RAM, 
Debian/Testing), pas un  RaspberryPi



- Karbon



NB. Hors sujet, mais professionnel: je cherche des partenaires 
HorizonEurope intéressés par http://refpersys.org/


(me contacter alors par courriel au boulot: 
basile.starynkevi...@cea.fr travaillant au https://www-list.cea.fr/ )




--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: Conseils pour dessiner sur ordinateur

2021-12-02 Par sujet Bernard Schoenacker 


- Mail original - 

> De: "Olivier" 
> À: "ML Debian User French" 
> Envoyé: Jeudi 2 Décembre 2021 17:09:48
> Objet: Conseils pour dessiner sur ordinateur

> Bonjour,

> Mon fils de 13 ans se passionne depuis peu pour le dessin et les
> mangas. Il dessine sur papier uniquement.

> Pour Noël, j'envisage de lui offrir une tablette graphique de type
> Watcom.
> Il est déjà équipé d'un Raspberry 4 sous Raspbian (Buster).

> 1. Quel appareil choisir ? Quels sont les principaux critères à
> prendre en compte ?
> 2. Quel logiciel choisir pour dessiner ?
> 3. Quel logiciel choisir pour dessiner une planche de bande dessinée
> ?
> 4. Avez-vous un retour d'expérience sur le passage du mode
> papier-crayon au mode sur ordinateur ? Passé un stade
> d'apprentissage, quel mode conserve la préférence des dessinateurs ?
> L'apprentissage est-il difficile ?
> Conseils et remarques ?

> Slts

Bonjour Olivier,

Pour le dessin artistique, voici les solutions qui me 
paraissent pertinentes 

- Krita
- Karbon


Merci pour ton aimable attention

Bien à toi

Bernard

Conseils pour dessiner sur ordinateur

2021-12-02 Par sujet Olivier 
Bonjour,

Mon fils de 13 ans se passionne depuis peu pour le dessin et les mangas. Il
dessine sur papier uniquement.

Pour Noël, j'envisage de lui offrir une tablette graphique de type Watcom.
Il est déjà équipé d'un Raspberry 4 sous Raspbian (Buster).

1. Quel appareil choisir ? Quels sont les principaux critères à prendre en
compte ?
2. Quel logiciel choisir pour dessiner ?
3. Quel logiciel choisir pour dessiner une planche de bande dessinée ?
4. Avez-vous un retour d'expérience sur le passage du mode papier-crayon au
mode sur ordinateur  ? Passé un stade d'apprentissage, quel mode conserve
la préférence des dessinateurs ?
L'apprentissage est-il difficile ?
Conseils et remarques ?

Slts

Conseils sur l'utilisation de firewalld

2021-09-08 Par sujet Olivier 
Bonjour,

J'ai découvert firewalld tout dernièrement sur une machine sous Bullseye.

J'ai trouvé son utilisation assez intuitive avec son programme
firewalld-cmd pour changer de façon temporaire ou persistante, la
configuration du firewall.

Un point aussi très intéressant est le fait de fonctionner aussi bien avec
iptables qu'avec nftables.


Auparavant, j'avais l'habitude de consigner dans un scripts  exécutable
/etc/network/if-pre-up.d/fw, une longue liste de commandes iptables comme
suit:

#!/bin/sh

WAN_IF=ens9
LAN_IFS="ens3.3 ends3.15"


iptables -F
iptables -X
iptables -t nat -F
iptables -t mangle -F

iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t nat -A POSTROUTING -o ${WAN_IF} -j MASQUERADE
for i in ${LAN_IFS}; do
  iptables ...
...


J'imaginais "traduire" le fichier ci-dessus en un fichier équivalent basé
sur des commandes firewall-cmd sans paramètre de persistance (puisque le
script est exécuté à chaque démarrage mais c'est à discuter).

Avant de me jeter dans la bataille, je serai très curieux de recevoir vos
conseils et suggestions sur des méthodes alternatives.

Slts

Re: Conseils sur l'exploitation d'un cluster Keepalived

2021-08-19 Par sujet Gregory 
Hello 

Le Wed, 18 Aug 2021 16:35:23 +0200,
Olivier  a écrit :


> 1. Le doc [1] mentionne un mécanisme de track file avec lequel il me
> semble possible de changer à la volée la priorité d'un noeud et donc
> de forcer son état Actif ou Passif. Ai-je bien compris ce mécanisme ?
> Y a-t-il des alternatives ?


avec ce mécanisme, mon paragraphe lance un script shell.

Quand je veux forcer un déplacement de master :
 * mon script shell check la présence d'un fichier. si ce fichier est
   présent je "exit 1" , keepalived fait la bascule en conséquence
 * s'assurer de ne pas automatiquement revenir sur  " le  master
   historique " : nopreempt de mémoire 

 * ne pas faire autre chose que 0 ou 1 comme code retour du script ce
   qui est > 1 ne semble pas pris en compte par keepalived


vrrp_script chk_mysql {
   script "/etc/keepalived/scripts/chk_mysql.sh"
   [...]

[...]

track_script {
chk_mysql
}


> 
> 2. Quels sont les risques d'un cluster dont des membres sont dans des
> versions Debian différentes (le but est d'aider à la montée de
> version) ?

J'ai jamais eu de problèmes


> 
> 3. J'imagine mettre à niveau de la façon suivante:

j'ai pas compris :-D

Conseils sur l'exploitation d'un cluster Keepalived

2021-08-18 Par sujet Olivier 
Bonjour,

J'ai cluster Keepalived à deux noeuds sous Debian.
À chaque instant, l'un des deux est actif quand l'autre est passif.
Ces deux noeuds sont des VM hébergées sur des hôtes différents et
indépendants.

Pour faciliter les opérations de mise à jour (changement d'OS ou de version
de logiciel), je m'interroge sur l'intérêt de doubler le nombre de noeud
sur chaque hôte toute en ne conservant, normalement à chaque instant, qu'un
unique noeud actif.

Avant de tester cela, je serai très curieux de lire vos commentaires,
suggestions et retours d'expérience sur ce type de mises en oeuvre.

Mes questions en vrac, sont:

1. Le doc [1] mentionne un mécanisme de track file avec lequel il me semble
possible de changer à la volée la priorité d'un noeud et donc de forcer son
état Actif ou Passif. Ai-je bien compris ce mécanisme ? Y a-t-il des
alternatives ?

2. Quels sont les risques d'un cluster dont des membres sont dans des
versions Debian différentes (le but est d'aider à la montée de version) ?

3. J'imagine mettre à niveau de la façon suivante:
3.1 le même jour, on immobilise deux noeuds passifs (1 sur chaque hôte de
virtualisation)
3.2 on met à jour les 2 noeuds immobilisés
3.3 à l'heure idoine, on bascule vers l'un des 2 noeuds à jour (avec retour
arrière en cas d'échec)
3.4 quelques temps après, on immobilise deux noeuds restants et on répète
les opérations 3.1 à 3.4
Voyez-vous une meilleure façon de procéder ?
Pour moi, ses inconvénients (qui me semblent acceptables) sont:
deux ruptures de service à chaque migration,
deux noeuds sont migrés sans véritablement avoir été testés.

[1] https://www.redhat.com/sysadmin/advanced-keepalived

Slts

Re: Conseils sur l'utilisation de certificats Letsencrypt

2020-12-17 Par sujet Sébastien Dinot 
Bonjour Stéphane,

Stéphane Rivière a écrit :
> J'arrive certainement après la bataille mais acmemgr.sh, compagnon de
> acme.sh pourrait répondre à ta demande... En tout cas, chez nous, c'est
> ainsi qu'on l'utilise... et ce pourquoi il a été conçu. La doc et les
> diagrammes sont assez explicites mais tu peux toujours demander des
> précisions par [MP]...
> 
> https://github.com/sowebio/acmemgr.sh

Ce projet semble fort intéressant en effet, je vais l'étudier de près.

Merci pour ce retour.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://www.palabritudes.net/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

Re: Conseils sur l'utilisation de certificats Letsencrypt

2020-12-11 Par sujet Stéphane Rivière 

Bonjour Sébastien,

J'arrive certainement après la bataille mais acmemgr.sh, compagnon de 
acme.sh pourrait répondre à ta demande... En tout cas, chez nous, c'est 
ainsi qu'on l'utilise... et ce pourquoi il a été conçu. La doc et les 
diagrammes sont assez explicites mais tu peux toujours demander des 
précisions par [MP]...


https://github.com/sowebio/acmemgr.sh



Le 26/11/2020 à 12:13, Sébastien Dinot a écrit :

Raphaël POITEVIN a écrit :

Sébastien Dinot  writes:


Bof, beaucoup de complications pour rien. Le seul cas de figure où
la chose est intéressante, c'est lorsqu'on veut confier à Let's
Encrypt la création de certificats pour des machines qui ne sont pas
exposées (seul leur nom étant alors publié dans la zone DNS
publique). Le « proxy » public dialogue alors avec les serveurs de
Let's Encrypt et un outil maison distribue ensuite les certificats
sur les machines qui en ont besoin en interne (et bien évidemment,
dans ce cas, la résolution DNS interne ne donne pas le même résultat
que la résolution DNS externe).


Petite question à ce sujet : est-ce que le reverse proxy en front
auquel on accède en https renvoie bien les informations chiffrées à la
machine cible, sur la quelle je n’ai pas installé le certificat ?


J'ai peur de ne pas avoir compris la question ou de m'être mal expliqué
dans mon message initial. Il ne s'agit pas ici de mettre en place un
(reverse) proxy. Mais seulement une machine mandataire, exposée
publiquement et dont la seule fonction est le renouvèlement des
certificats. Ces certificats sont ensuite distribués aux machines qui en
ont besoin sur le réseau interne. Une rapide recherche sur Internet
vient de me montrer qu'il existe pas mal d'articles sur le sujet sur le
net, de qualité inégale. Celui-ci me semble pas mal :

https://geontech.com/using-letsencrypt-ssl-internally/

J'ai évoqué cette solution car, par design, Let's Encrypt ne peut pas
être utilié pour gérer les certificats d'un réseau interne.

Sébastien



--
Stéphane Rivière
Ile d'Oléron - France

Re: Conseils sur l'utilisation de certificats Letsencrypt

2020-11-26 Par sujet François TOURDE 
Le 18591ième jour après Epoch,
Olivier écrivait:

> Bonjour,
>
> Je viens d'obtenir avec certbot mon premier certificat Letsencrypt via le
> challenge DNS-01 (cf [1]).

Bravo !

> Pour différentes raisons (parmi elles, celle qui consiste à éviter
> d'installer Certbot et des identifiants sensibles sur de multiples
> machines),

certbot n'est pas gourmand en mémoire et CPU, et il n'y a pas
d'identifiants particuliers qui lui sont associés.

> Si j'ai bien compris, le fichier /etc/crond.d/certbot renouvelle tous les
> certificats toutes les 12 heures:
> 0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system &&
> perl -e 'sleep int(rand(43200))' && certbot -q renew

Non, il vérifie si ça doit ou non être renouvellé. Tu peux (mais est-ce
nécessaire) modifier cette fréquence pour le faire tous les mois si tu
veux, à condition que ta machine soit active à ce moment-là.

> 1. Que pensez-vous de centraliser la gestion des certificats ?

C'est un choix personnel. Je suis plutôt dans la politique "chacun sa
merde", et ça m'évite un SPOF sur la machine qui renouvelle.

> 2. Que conseillez-vous pour la fréquence de renouvellement ?

Le out-of-the-box est très bien, non?

> 3. Est-il possible de disposer simultanément d'un certificat wildcard
> *.mondomaine.tld et d'un autre foo.mondomaine.tld ?
> 4. Quels usages légitimes pour un certificat wildcard, quand on peut créer
> rapidement un nouveau certificat et qu'on veut pouvoir les répudier au cas
> par cas ?

Jamais joué avec les wildcards pour le moment, et jamais eu besoin de
répudier un certif.

> 5. Comment sauvegarder la machine avec laquelle on gère ses
> certificats ?

Euh ... Pareil que pour le serveur postgreSQL ou nginx ? Ou bien un truc
m'échappe ?

Re: Conseils sur l'utilisation de certificats Letsencrypt

2020-11-26 Par sujet Raphaël POITEVIN 
Daniel Caillibaud  writes:
>> En résumé, est-ce que si on sniffe dans mon réseau interne on verra en
>> clair ?
>
> Oui

Merci, je m’en doutais un peu.
-- 
Raphaël
www.leclavierquibave.fr

Re: Conseils sur l'utilisation de certificats Letsencrypt

2020-11-26 Par sujet Daniel Caillibaud 
Le 26/11/20 à 11h07, raphael.poite...@gmail.com (Raphaël POITEVIN) a écrit :
> Petite question à ce sujet : est-ce que le reverse proxy en front auquel
> on accède en https renvoie bien les informations chiffrées à la machine
> cible, sur la quelle je n’ai pas installé le certificat ?

Non

> Dans mon nginx, j’ai par exemple :
> upstream sous-domaine.example.fr {
> server 192.168.x.x;
> }
> 
> et bien sûr le bloc habituel pour écouter sur le 443 et rediriger.
> 
> En résumé, est-ce que si on sniffe dans mon réseau interne on verra en
> clair ?

Oui

-- 
Daniel

Nous n'héritons pas la terre de nos ancêtres,
nous l'empruntons à nos enfants.
Seattle (chef indien)

Re: Conseils sur l'utilisation de certificats Letsencrypt

2020-11-26 Par sujet Raphaël POITEVIN 
Sébastien Dinot  writes:

> J'ai peur de ne pas avoir compris la question ou de m'être mal expliqué
> dans mon message initial. Il ne s'agit pas ici de mettre en place un
> (reverse) proxy. Mais seulement une machine mandataire, exposée
> publiquement et dont la seule fonction est le renouvèlement des
> certificats. Ces certificats sont ensuite distribués aux machines qui en
> ont besoin sur le réseau interne. Une rapide recherche sur Internet

ah oui d’accord, j’ai compris.

> vient de me montrer qu'il existe pas mal d'articles sur le sujet sur le
> net, de qualité inégale. Celui-ci me semble pas mal :
>
> https://geontech.com/using-letsencrypt-ssl-internally/
Merci.
>
> J'ai évoqué cette solution car, par design, Let's Encrypt ne peut pas
> être utilié pour gérer les certificats d'un réseau interne.

En effet.

Re: Conseils sur l'utilisation de certificats Letsencrypt

2020-11-26 Par sujet Sébastien Dinot 
Raphaël POITEVIN a écrit :
> Sébastien Dinot  writes:
> 
> > Bof, beaucoup de complications pour rien. Le seul cas de figure où
> > la chose est intéressante, c'est lorsqu'on veut confier à Let's
> > Encrypt la création de certificats pour des machines qui ne sont pas
> > exposées (seul leur nom étant alors publié dans la zone DNS
> > publique). Le « proxy » public dialogue alors avec les serveurs de
> > Let's Encrypt et un outil maison distribue ensuite les certificats
> > sur les machines qui en ont besoin en interne (et bien évidemment,
> > dans ce cas, la résolution DNS interne ne donne pas le même résultat
> > que la résolution DNS externe).
> 
> Petite question à ce sujet : est-ce que le reverse proxy en front
> auquel on accède en https renvoie bien les informations chiffrées à la
> machine cible, sur la quelle je n’ai pas installé le certificat ?

J'ai peur de ne pas avoir compris la question ou de m'être mal expliqué
dans mon message initial. Il ne s'agit pas ici de mettre en place un
(reverse) proxy. Mais seulement une machine mandataire, exposée
publiquement et dont la seule fonction est le renouvèlement des
certificats. Ces certificats sont ensuite distribués aux machines qui en
ont besoin sur le réseau interne. Une rapide recherche sur Internet
vient de me montrer qu'il existe pas mal d'articles sur le sujet sur le
net, de qualité inégale. Celui-ci me semble pas mal :

https://geontech.com/using-letsencrypt-ssl-internally/

J'ai évoqué cette solution car, par design, Let's Encrypt ne peut pas
être utilié pour gérer les certificats d'un réseau interne.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://www.palabritudes.net/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

Re: Conseils sur l'utilisation de certificats Letsencrypt

2020-11-26 Par sujet Raphaël POITEVIN 
Bonjour,

Sébastien Dinot  writes:

> Bof, beaucoup de complications pour rien. Le seul cas de figure où la
> chose est intéressante, c'est lorsqu'on veut confier à Let's Encrypt la
> création de certificats pour des machines qui ne sont pas exposées (seul
> leur nom étant alors publié dans la zone DNS publique). Le « proxy »
> public dialogue alors avec les serveurs de Let's Encrypt et un outil
> maison distribue ensuite les certificats sur les machines qui en ont
> besoin en interne (et bien évidemment, dans ce cas, la résolution DNS
> interne ne donne pas le même résultat que la résolution DNS externe).

Petite question à ce sujet : est-ce que le reverse proxy en front auquel
on accède en https renvoie bien les informations chiffrées à la machine
cible, sur la quelle je n’ai pas installé le certificat ?

Dans mon nginx, j’ai par exemple :
upstream sous-domaine.example.fr {
server 192.168.x.x;
}

et bien sûr le bloc habituel pour écouter sur le 443 et rediriger.

En résumé, est-ce que si on sniffe dans mon réseau interne on verra en
clair ?

C’est juste pour ma gouverne. Tout seul à la maison je ne risque pas
grand chose, surtout avec ce que je fais. :-)

Cordialement,
-- 
Raphaël
www.leclavierquibave.fr

Re: Conseils sur l'utilisation de certificats Letsencrypt [RESOLU]

2020-11-25 Par sujet Olivier 
Merci à tous pour ces précieux éléments de réponse.

Je n'avais visiblement pas compris le rôle de /etc/cron.d/certbot: c'est
compris maintenant.

Pour la centralisation de la gestion, je me rends compte qu'elle est
probablement handicapante pour une machine publique dont le certificat est
renouvelable par le challenge HTTP-01.

Encore merci.

Re: Conseils sur l'utilisation de certificats Letsencrypt

2020-11-25 Par sujet Sébastien Dinot 
Olivier a écrit :
> Si j'ai bien compris, le fichier /etc/crond.d/certbot renouvelle tous
> les certificats toutes les 12 heures:

Non, il vérifie toutes les 12 heures si ces certificats doivent être
renouvelés. Les certificats générés par Let's Encrypt ont une durée de
validité de 3 mois, mais Certbot les renouvèle au bout de 2 mois (à
moins qu'on ne réduise le paramètre renew_before_expiry et qu'on ramène
le délai par exemple à 7 jours).

> Pourtant lors de sa création, mon certificat est annoncé comme valide
> jusqu'au 2021-02-23

C'est normal pour un certificat créé le 2020-11-23.

> 1. Que pensez-vous de centraliser la gestion des certificats ?

Bof, beaucoup de complications pour rien. Le seul cas de figure où la
chose est intéressante, c'est lorsqu'on veut confier à Let's Encrypt la
création de certificats pour des machines qui ne sont pas exposées (seul
leur nom étant alors publié dans la zone DNS publique). Le « proxy »
public dialogue alors avec les serveurs de Let's Encrypt et un outil
maison distribue ensuite les certificats sur les machines qui en ont
besoin en interne (et bien évidemment, dans ce cas, la résolution DNS
interne ne donne pas le même résultat que la résolution DNS externe).

> 2. Que conseillez-vous pour la fréquence de renouvellement ?

Ils ne sont valides que 3 mois et il me semble inutile de vouloir les
renouveler toutes les semaines. Pour ma part, je ramène juste le délai
de renouvèlement avant échéance de 30 à 7 jours.

> 3. Est-il possible de disposer simultanément d'un certificat wildcard
>*.mondomaine.tld et d'un autre foo.mondomaine.tld ?

Je n'ai jamais essayé, mais je pense que Certbot braille dans ce cas.

> 4. Quels usages légitimes pour un certificat wildcard, quand on peut
>créer rapidement un nouveau certificat et qu'on veut pouvoir les
>répudier au cas par cas ?

Dans les infrastructures cloud élastiques, pour lesquelles on ne connait
pas à l'avance le nombre de serveurs et la ventilation des services.
Mais dans ce cas, on réserve souvent le wildcard à un sous domaine. Par
exemple :

www.domain.tld
gitlab.domain.tld
*.cloud.domain.tld

(et non *.domain.tld)

> 5. Comment sauvegarder la machine avec laquelle on gère ses
>certificats ?

Comme toute autre machine, en n'oubliant pas de sauvegarder le
répertoire /etc/letsencrypt. ;)

Sébastien


-- 
Sébastien Dinot, sebastien.di...@free.fr
http://www.palabritudes.net/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

Re: Conseils sur l'utilisation de certificats Letsencrypt

2020-11-25 Par sujet Daniel Caillibaud 
Le 25/11/20 à 17h38, Olivier  a écrit :

> Bonjour,
> 
> Je viens d'obtenir avec certbot mon premier certificat Letsencrypt via le
> challenge DNS-01 (cf [1]).
> C'est l'occasion pour moi de définir ma façon de gérer ces certificats.
> 
> Pour différentes raisons (parmi elles, celle qui consiste à éviter
> d'installer Certbot et des identifiants sensibles sur de multiples
> machines),

Il n'y a rien de sensible sur la machine qui lance certbot.

J'utilise certbot sur chaque frontal https, lorque je veux ajouter un vhost
foo.mondomaine.tld
- j'ajoute foo dans le dns de mondomaine.tld (seulement une entrée A, pour 
  pointer sur le bon frontal web)
- je génère le premier certificat manuellement (sur le frontal concerné) 
  avec la commande
certbot certonly --rsa-key-size 4096 --webroot -w /var/www/certbot -d
foo.mondomaine.tld
  (plusieurs -d possibles)
- je crée la conf nginx du vhost avec ce certif
et ensuite ça roule tout seul…

J'ai juste ajouté un override systemd pour ne faire le check qu'une fois par 
nuit
et pour appeler un hook maison afin d'être prévenu à chaque renouvellement.


Pour que ça fonctionne, j'ai une règle nginx sur le http_default (le vhost 
est pas encore créé car j'ai pas encore le certif)

  location ~ ^/.well-known/acme-challenge {
root /var/www/certbot;
  }

(le user qui lance la commande certbot doit avoir les droits d'écriture sur
/var/www/certbot, pour que LE retrouve ses petits dans ce dossier lorsqu'il 
fait sa vérif)

> j'imagine centraliser la gestion (création, renouvellement,
> suppression) des certificats sur une machine unique et de mécaniser, si
> possible, la copie de ces certificats sur les machines où ils sont
> nécessaires.
> 
> Si j'ai bien compris, le fichier /etc/crond.d/certbot renouvelle tous les
> certificats toutes les 12 heures:
> 0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system &&
> perl -e 'sleep int(rand(43200))' && certbot -q renew

non, il regarde toutes les 12 heures s'il faut le renouveler.

> Pourtant lors de sa création, mon certificat est annoncé comme valide
> jusqu'au 2021-02-23

Oui, c'est 3 mois, et certbot va le renouveler 20j avant l'échéance.

> 1. Que pensez-vous de centraliser la gestion des certificats ?

Pas très bien compris, amha c'est plus compliqué.

> 2. Que conseillez-vous pour la fréquence de renouvellement ?

Ça c'est pas toi qui choisit, c'est LE qui impose 3 mois de validité.

> 3. Est-il possible de disposer simultanément d'un certificat wildcard
> *.mondomaine.tld et d'un autre foo.mondomaine.tld ?

Je crois pas que LE propose de wildcard, mais tu peux lister autant de 
domaines que tu veux dans le même certif (pas forcément tous des sous-domaines 
du même domaine).

> 4. Quels usages légitimes pour un certificat wildcard, quand on peut créer
> rapidement un nouveau certificat et qu'on veut pouvoir les répudier au cas
> par cas ?

Pas bien compris, j'utilise toujours un certif par sous-domaine et j'en ai 
jamais répudié, mais je suppose que tu répudie le certif global et que tu 
en recrée un nouveau avec la même chose sauf ce que tu veux répudier.

> 5. Comment sauvegarder la machine avec laquelle on gère ses certificats ?

Comme n'importe quelle autre machine, mais j'ai probablement pas compris la 
question.

> [1] https://buzut.net/certbot-challenge-dns-ovh-wildcard/

Ça me paraît bien compliqué, pour ma part j'installe le paquet debian certbot 
et 
rien d'autre, et c'est hors de question de lui filer un droit de modif sur mes 
dns 
ou ma conf nginx.

-- 
Daniel

Plus je grossis, plus je m'aigris.
Philippe Geluck, Le chat

Conseils sur l'utilisation de certificats Letsencrypt

2020-11-25 Par sujet Olivier 
Bonjour,

Je viens d'obtenir avec certbot mon premier certificat Letsencrypt via le
challenge DNS-01 (cf [1]).
C'est l'occasion pour moi de définir ma façon de gérer ces certificats.

Pour différentes raisons (parmi elles, celle qui consiste à éviter
d'installer Certbot et des identifiants sensibles sur de multiples
machines), j'imagine centraliser la gestion (création, renouvellement,
suppression) des certificats sur une machine unique et de mécaniser, si
possible, la copie de ces certificats sur les machines où ils sont
nécessaires.

Si j'ai bien compris, le fichier /etc/crond.d/certbot renouvelle tous les
certificats toutes les 12 heures:
0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system &&
perl -e 'sleep int(rand(43200))' && certbot -q renew

Pourtant lors de sa création, mon certificat est annoncé comme valide
jusqu'au 2021-02-23


1. Que pensez-vous de centraliser la gestion des certificats ?
2. Que conseillez-vous pour la fréquence de renouvellement ?
3. Est-il possible de disposer simultanément d'un certificat wildcard
*.mondomaine.tld et d'un autre foo.mondomaine.tld ?
4. Quels usages légitimes pour un certificat wildcard, quand on peut créer
rapidement un nouveau certificat et qu'on veut pouvoir les répudier au cas
par cas ?
5. Comment sauvegarder la machine avec laquelle on gère ses certificats ?

[1] https://buzut.net/certbot-challenge-dns-ovh-wildcard/

Slts

Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux

2020-11-21 Par sujet Jerome Flesch 
Bonjour,


Pour ma part je développe depuis quelques années un programme
cross-plateforme (Windows/Linux) en client lourd :
https://openpaper.work/ .

C'est du Python+GTK.

Python est un langage très plaisant à utiliser. Par contre, dès qu'on
utilise des librairies qui ne sont pas pure-Python, le packaging
devient vite très compliqué. L'utilisation des bindings
Gobject-introspection pour accéder à GTK n'améliore pas la situation.

Sous GNU/Linux, je distribue ça surtout sous forme de Flatpak[1][2].
Ça me permet notamment de faire du déploiement continu[3][4]. Ça pose
juste des problèmes d'accès aux scanners (et quelques autres
périphériques pour d'autres applis) :/.
Je le distribue aussi sous forme de paquets pip[5]. Les paquets
incluent une commande à lancer pour vérifier et installer les
dépendances qui ne peuvent pas être prises en charge par pip
(`paperwork-gtk chkdeps`). Mais c'est moins pratique pour les
utilisateurs, et ce n'est donc plus la méthode recommandée.
Avec le temps, de gentils mainteneurs de paquets ont fait des paquets
pour diverses distributions. Ça reste de loin la méthode la plus
simple pour les utilisateurs. Le défaut pour moi, c'est que je ne peux
pas faire de déploiement continu.

Sous Windows, j'avais étudié la possibilité de faire de la
cross-compilation, mais je n'ai pas retenu cette solution finalement.
J'ai buté sur les bindings GObject Introspection : Si j'ai bien
compris, le programme qui les génère (g-ir-scanner) a besoin de
tourner sur le même système que le systẽme cible.
De façon générale, dès qu'on utilise des librairies natives, la
cross-compilation risque de causer des problèmes. Il me semble que
pour cross-compiler des programmes Windows, la seule solution est
d'utiliser les librairies Wine (ne serait-ce que pour le linkage). Du
coup, c'est difficile d'être certain que le résultat fonctionnera de
façon fiable sur un vrai Windows.
Le même problème se pose pour les tests automatiques : On peut les
lancer avec Wine, mais il n'y a aucune garantie que le comportement
sera exactement le même que sur un vrai Windows.

Vu que j'utilise GTK, le plus simple que j'ai trouvé est d'utiliser
une VM Windows et MSYS2[6]. Dans MSYS2, j'utilise cx-freeze[7] pour
créer un exécutable Windows. Cx_freeze n'a pas l'air de gérer très
bien les bindings GObject-Introspection, donc j'ai dû bricoler un peu
pour que ça passe (ajout de dépendances manquées par Cx_freeze à la
main)[8].
L'exécutable est accompagné de plein de fichiers de données. J'en fait
donc un ZIP[9] et l'upload sur un object storage OVH. C'est
l'installateur NSIS[10][11] qui va le télécharger et l'extraire à
l'installation. Du coup il télécharge toujours la dernière version
construite par CI/CD (donc on est presque sur du CI/CD complet de bout
en bout).

Pour être honnête, je regrette d'avoir fait le portage à Windows de
mon application. Ça m'a pris énormément de temps (développement de
Pyinsane puis Libinsane pour accéder aux scanners sous Windows,
difficulté pour packager, bugs à la c*n, etc). Mais bon, le gros de la
difficulté est passé, et des gens s'en servent maintenant ...
En tout cas, je ne porterais pas mes prochaines applications à Windows.

Concernant Go, il ne me semble pas que Go intègre de librairie de GUI
par défaut. Ça m'étonnerait aussi fortement qu'il existe une librairie
en pure-Go cross-plateforme. Ça veut dire qu'il faut des bindings
coincoin sur Qt ou GTK. Ça sent les problèmes aussi tordus que ceux
que j'ai eu avec Python. De plus, je ne suis pas certain que
l'éco-système de librairies pour le desktop basé sur Go soit aussi
développé que celui de Python.

Pour les applications Javascript genre Électron, dans le cadre de mes
développements, je fais une allergie sévère au Javascript et aux
machins « web ». Je trouve le langage Javascript infect, et de mon
point de vue, cette approche est une rustine sur un problème qui
aurait déjà dû être réglé plus proprement il y a longtemps. De toute
façon, avec ça, je n'aurais sûrement pas pu accéder aux scanners.

Pour Flutter/Dart, je ne connais pas.

Au final, pour faire des GUI cross-plateformes, je me dis que
l'approche Java/Swing était peut-être la bonne.


Cordialement,

---
[1] 
https://gitlab.gnome.org/World/OpenPaperwork/paperwork/-/blob/master/doc/install.flatpak.markdown
[2] 
https://gitlab.gnome.org/World/OpenPaperwork/paperwork/-/blob/master/flatpak/master.json
[3] 
https://gitlab.gnome.org/World/OpenPaperwork/paperwork/-/blob/3c9f624ef35b118f456b97b6bc0c7d6d3ee51742/.gitlab-ci.yml#L71
[4] https://gitlab.gnome.org/World/OpenPaperwork/paperwork/pipelines
[5] https://pypi.org/project/paperwork/
[6] https://www.msys2.org/
[7] 
https://gitlab.gnome.org/World/OpenPaperwork/paperwork/-/blob/3c9f624ef35b118f456b97b6bc0c7d6d3ee51742/.gitlab-ci.yml#L147
[8] 
https://gitlab.gnome.org/World/OpenPaperwork/paperwork/-/blob/3c9f624ef35b118f456b97b6bc0c7d6d3ee51742/paperwork-gtk/Makefile#L39
[9] https://download.openpaper.work/windows/x86/paperwork-master-latest.zip

Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux

2020-11-21 Par sujet guillaume.lehmann 
Bonjour,    Compiler un programme golang sous Linux avec une cible MS Windows 
est très simple... quand tu n'embarques pas de libs exotiques. Evidemment, il 
faut éviter que le programme utilise des spécificités de Linux, comme par 
exemple le fait d'envoyer ses logs à Syslog. Pour certaines libs externes, ca 
cross compile mais ca plante au lancement sur la nouvelle plateforme. Par 
exemple le driver SQLite sous Golang sur une plateforme Mac car le developpeur 
de ce connecteur n'a pas de quoi tester sur Mac. Je te conseille donc d'avoir 
un MS Windows pour tester le bon fonctionnement même si tout s'est bien passé à 
la compilation. Ceci étant dit, entre Linux et MS Windows, ca marche plutôt 
bien si on reste avec les libs tierces connues. Il n'y a que pour la partie 
boites à outils graphiques que je galère. Pour être tranquille, je passe 
maintenant par du web avec Javascript en front et Go en back. Golang embarque 
un backend web dans sa lib std, donc la crosscompil est "garantie" sur le 
backend web. Pour les frameworks web Golang, pour ceux qui se reposent sur 
net/http de la lib std, ils doivent aussi passer en cross compil. S'agissant 
des boîtes à outils pour faire des clients lourds : Gtk+Golang ca va sous Linux 
mais je n'ai pas réussi à le faire tourner sous MS Windows (en cross compil ou 
en natif). Qt+Go n'était pas assez mature à l'époque. Tk essayé non pas avec 
Golang mais avec Perl (et ppar pour la transformation en .exe).En conclusion, 
Go+web ca marche du tonnerre et tu peux compiler sous Linux pour MS Windows. En 
client lourd, je n'ai pas réussi à faire ce que tu demandes. Mais il y a plein 
de nouvelles libs qui sont apparues depuis mes derniers tests, qui remontent à 
3 ans.Bonne fin de semaine Guillaume
 Message d'origine De : Olivier  Date : 
20/11/2020  09:00  (GMT+01:00) À : ML Debian User French 
 Objet : Re: Conseils pour le 
développement sur Debian d'applications natives Windows/Linux @Etienne:Gcab est 
effectivement intéressant à connaître.Merci beaucoup pour ce lien.Le ven. 20 
nov. 2020 à 08:14, Étienne Mollier  a écrit 
:Bonjour Olivier,

Olivier, on 2020-11-19 16:11:32 +0100:
> 2. Un point très important pour moi est, par contre, si c'est possible de
> pouvoir empaqueter depuis Linux/Debian l'application Windows et son
> installateur sans utiliser Windows.
> (Plusieurs outils comme Kivy annonce la possibilité de développer pour
> plusieurs plateformes, mais si j'ai bien compris, il faut empaqueter sur la
> même plateforme que la cible).

Je ne suis absolument pas versé dans le domaine de la
distribution de programmes pour Windows, mais en faisant une
petite recherche dans les paquets de Debian Sid, je suis tombé
sur "gcab".  L'outil est mis à disposition via la collection des
"msitools" :

        https://wiki.gnome.org/msitools

| msitools plans to be a solution for packaging and deployment
| of cross-compiled Windows applications. 

C'est un collection de programmes pour empaqueter et déployer
des utilitaires cross-compilés à destination de Windows.
J'ignore ce que ça vaut en pratique, mais à la description, ça
me semblait correspondre à votre cahier des charges.

Quant à tester l'installateur, je suppose que wine ferait
l'affaire dans un premier temps.  Mais à terme, je pense qu'il
faudrait au moins faire un test sur une machine Windows native,
juste pour s'assurer qu'une coquille n'est pas passée entre les
mailles du filet.

Bonne journée,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/3, please excuse my verbosity.

Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux

2020-11-20 Par sujet Olivier 
@Etienne:
Gcab est effectivement intéressant à connaître.
Merci beaucoup pour ce lien.

Le ven. 20 nov. 2020 à 08:14, Étienne Mollier 
a écrit :

> Bonjour Olivier,
>
> Olivier, on 2020-11-19 16:11:32 +0100:
> > 2. Un point très important pour moi est, par contre, si c'est possible de
> > pouvoir empaqueter depuis Linux/Debian l'application Windows et son
> > installateur sans utiliser Windows.
> > (Plusieurs outils comme Kivy annonce la possibilité de développer pour
> > plusieurs plateformes, mais si j'ai bien compris, il faut empaqueter sur
> la
> > même plateforme que la cible).
>
> Je ne suis absolument pas versé dans le domaine de la
> distribution de programmes pour Windows, mais en faisant une
> petite recherche dans les paquets de Debian Sid, je suis tombé
> sur "gcab".  L'outil est mis à disposition via la collection des
> "msitools" :
>
> https://wiki.gnome.org/msitools
>
> | msitools plans to be a solution for packaging and deployment
> | of cross-compiled Windows applications.
>
> C'est un collection de programmes pour empaqueter et déployer
> des utilitaires cross-compilés à destination de Windows.
> J'ignore ce que ça vaut en pratique, mais à la description, ça
> me semblait correspondre à votre cahier des charges.
>
> Quant à tester l'installateur, je suppose que wine ferait
> l'affaire dans un premier temps.  Mais à terme, je pense qu'il
> faudrait au moins faire un test sur une machine Windows native,
> juste pour s'assurer qu'une coquille n'est pas passée entre les
> mailles du filet.
>
> Bonne journée,
> --
> Étienne Mollier 
> Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
> Sent from /dev/pts/3, please excuse my verbosity.
>

Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux

2020-11-19 Par sujet Fabrice BAUZAC-STEHLY 
Olivier writes:

> Je serai très curieux de recueillir ici des retours d'expérience sur le
> développement sous Debian (Buster) d'applications natives Windows/Linux.
>
> 1. Par application native, j'entends une application graphique avec
> quelques champs de saisie et quelques boutons.
> L'homogénéité du style de l'application avec les autres n'a pas
> d'importance pour mon cas.
> Le fait de coder avec des technos Web (HTML, JS, CSS) ou classiques n'est
> pas important non plus.

Je pense que tu peux le faire sans trop de problemes avec Java, en
utilisant la GUI Swing (ou JavaFX), et Maven.

--
Fabrice BAUZAC-STEHLY
PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D

Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux

2020-11-19 Par sujet Olivier 
@Basile:

Merci pour tes réponses.

La possibilité de cross-compiler est une fonction clairement mise en avant
par le language Go (cf [4]).
Il semble même possible de cibler MacOS sans posséder la moindre licence ou
le moindre matériel Apple !
J'imagine que "le terrain a été juridiquement balayé".


[4]
https://www.digitalocean.com/community/tutorials/how-to-build-go-executables-for-multiple-platforms-on-ubuntu-16-04

Le jeu. 19 nov. 2020 à 16:58, Basile Starynkevitch 
a écrit :

>
> On 11/19/20 4:11 PM, Olivier wrote:
>
> Bonjour,
>
> Je serai très curieux de recueillir ici des retours d'expérience sur le
> développement sous Debian (Buster) d'applications natives Windows/Linux.
>
>
> Nota Bene:* je n'ai jamais de ma vie utilisé Windows!* (Mais Linux depuis
> 1993, et Unix depuis 1985)
>
>
> Ça doit être faisable, mais *ça peut prendre des semaines de travail*, et
> il n'est pas certain que l'exécutable ainsi produit soit légalement
> diffusable. Je suggère une approche WSL et la *consultation d'un avocat
> spécialiste en licences logicielles*.
>
>
> Des pistes possibles seraient
>
>
> Lire avec attention http://www.fr.linuxfromscratch.org/
>
> Compiler GNU binutils depuis son code source depuis
> https://www.gnu.org/software/binutils/
>
> Compiler GCC depuis son code source sur http://gcc.gnu.org/
>
> Utiliser une bibliothèque serveur HTTP telle que
> https://coralbits.com/static/onion/
>
> Il se trouve que j'ai contribué aussi bien à GCC qu'à libonion.
>
>
>
> La question centrale, c'est combien de temps êtes vous prêt à dépenser, et
> pourquoi (et pour vous, qui vous paie ce temps de travail, qui se compte en
> semaines).
>
>
> Il est possible que l'acquisition d'une licence Windows soit moins
> onéreuse que tout le travail à faire pour l'éviter.
>
>
> Cordialement
>
>
> --
> Basile Starynkevitch   
> 
> (only mine opinions / les opinions sont miennes uniquement)
> 92340 Bourg-la-Reine, France
> web page: starynkevitch.net/Basile/
>
>

Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux

2020-11-19 Par sujet Olivier 
C. Sur Flutter/Dart, dans [2], on peut lire qu'il faut
construire/empaqueter sur la même plateforme que la plateforme cible.

D. J'ai découvert Guark (cf [3]). Ça a l'air particulièrement intéressant.

[2] https://flutter.dev/desktop

[3] https://github.com/guark/guark


Le jeu. 19 nov. 2020 à 16:11, Olivier  a écrit :

> Bonjour,
>
> Je serai très curieux de recueillir ici des retours d'expérience sur le
> développement sous Debian (Buster) d'applications natives Windows/Linux.
>
> 1. Par application native, j'entends une application graphique avec
> quelques champs de saisie et quelques boutons.
> L'homogénéité du style de l'application avec les autres n'a pas
> d'importance pour mon cas.
> Le fait de coder avec des technos Web (HTML, JS, CSS) ou classiques n'est
> pas important non plus.
> Si j'ai la possibilité, j'apprécierai de coder en Python.
>
> 2. Un point très important pour moi est, par contre, si c'est possible de
> pouvoir empaqueter depuis Linux/Debian l'application Windows et son
> installateur sans utiliser Windows.
> (Plusieurs outils comme Kivy annonce la possibilité de développer pour
> plusieurs plateformes, mais si j'ai bien compris, il faut empaqueter sur la
> même plateforme que la cible).
>
> A. Qu'en pensez-vous ? Avez-vous déjà expérimenté une telle chose ?
> B. En surfant, j'ai lu que le langage Go (cf [1] annonce la possibilité
> d'empaqueter sur Linux pour Windows. Qu'en penser ?
> C. J'ai lu des infos sur Flutter/Dart ou Qt mais rien de précis sur
> l'empaquetage.
>
> [1] https://golangr.com/gui/
>
> Slts
>

Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux

2020-11-19 Par sujet Étienne Mollier 
Bonjour Olivier,

Olivier, on 2020-11-19 16:11:32 +0100:
> 2. Un point très important pour moi est, par contre, si c'est possible de
> pouvoir empaqueter depuis Linux/Debian l'application Windows et son
> installateur sans utiliser Windows.
> (Plusieurs outils comme Kivy annonce la possibilité de développer pour
> plusieurs plateformes, mais si j'ai bien compris, il faut empaqueter sur la
> même plateforme que la cible).

Je ne suis absolument pas versé dans le domaine de la
distribution de programmes pour Windows, mais en faisant une
petite recherche dans les paquets de Debian Sid, je suis tombé
sur "gcab".  L'outil est mis à disposition via la collection des
"msitools" :

https://wiki.gnome.org/msitools

| msitools plans to be a solution for packaging and deployment
| of cross-compiled Windows applications. 

C'est un collection de programmes pour empaqueter et déployer
des utilitaires cross-compilés à destination de Windows.
J'ignore ce que ça vaut en pratique, mais à la description, ça
me semblait correspondre à votre cahier des charges.

Quant à tester l'installateur, je suppose que wine ferait
l'affaire dans un premier temps.  Mais à terme, je pense qu'il
faudrait au moins faire un test sur une machine Windows native,
juste pour s'assurer qu'une coquille n'est pas passée entre les
mailles du filet.

Bonne journée,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/3, please excuse my verbosity.


signature.asc
Description: PGP signature

Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux

2020-11-19 Par sujet Basile Starynkevitch 


On 11/19/20 4:56 PM, Basile Starynkevitch wrote:



On 11/19/20 4:11 PM, Olivier wrote:

Bonjour,

Je serai très curieux de recueillir ici des retours d'expérience sur 
le développement sous Debian (Buster) d'applications natives 
Windows/Linux.



Nota Bene:*je n'ai jamais de ma vie utilisé Windows!* (Mais Linux 
depuis 1993, et Unix depuis 1985)



Ça doit être faisable, mais *ça peut prendre des semaines de travail*, 
et il n'est pas certain que l'exécutable ainsi produit soit légalement 
diffusable. Je suggère une approche WSL et la *consultation d'un 
avocat spécialiste en licences logicielles*.



Des pistes possibles seraient


Lire avec attention http://www.fr.linuxfromscratch.org/

Compiler GNU binutils depuis son code source depuis 
https://www.gnu.org/software/binutils/


Compiler GCC depuis son code source sur http://gcc.gnu.org/

Utiliser une bibliothèque serveur HTTP telle que 
https://coralbits.com/static/onion/


Il se trouve que j'ai contribué aussi bien à GCC qu'à libonion.





J'ai oublié de préciser que GCC et binutils sont compilables puis 
utilisables comme compilateur croisé (/cross-compiler/).



Le dévelopement d'application Windows sous Debian est possible.


Une alternative est bien sûr de livrer un fichier bytecode compilé avec 
Ocaml. Voir http://ocaml.org/ pour les détails. Les fichiers bytecode 
Ocaml sont portables entre Windows et Linux, moyennant un certain nombre 
de précautions.


(Il se trouve que j'ai marginalement contribué à Ocaml)

Librement

--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: Conseils pour le développement sur Debian d'applications natives Windows/Linux

2020-11-19 Par sujet Basile Starynkevitch 


On 11/19/20 4:11 PM, Olivier wrote:

Bonjour,

Je serai très curieux de recueillir ici des retours d'expérience sur 
le développement sous Debian (Buster) d'applications natives 
Windows/Linux.



Nota Bene:*je n'ai jamais de ma vie utilisé Windows!* (Mais Linux depuis 
1993, et Unix depuis 1985)



Ça doit être faisable, mais *ça peut prendre des semaines de travail*, 
et il n'est pas certain que l'exécutable ainsi produit soit légalement 
diffusable. Je suggère une approche WSL et la *consultation d'un avocat 
spécialiste en licences logicielles*.



Des pistes possibles seraient


Lire avec attention http://www.fr.linuxfromscratch.org/

Compiler GNU binutils depuis son code source depuis 
https://www.gnu.org/software/binutils/


Compiler GCC depuis son code source sur http://gcc.gnu.org/

Utiliser une bibliothèque serveur HTTP telle que 
https://coralbits.com/static/onion/


Il se trouve que j'ai contribué aussi bien à GCC qu'à libonion.



La question centrale, c'est combien de temps êtes vous prêt à dépenser, 
et pourquoi (et pour vous, qui vous paie ce temps de travail, qui se 
compte en semaines).



Il est possible que l'acquisition d'une licence Windows soit moins 
onéreuse que tout le travail à faire pour l'éviter.



Cordialement


--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Conseils pour le développement sur Debian d'applications natives Windows/Linux

2020-11-19 Par sujet Olivier 
Bonjour,

Je serai très curieux de recueillir ici des retours d'expérience sur le
développement sous Debian (Buster) d'applications natives Windows/Linux.

1. Par application native, j'entends une application graphique avec
quelques champs de saisie et quelques boutons.
L'homogénéité du style de l'application avec les autres n'a pas
d'importance pour mon cas.
Le fait de coder avec des technos Web (HTML, JS, CSS) ou classiques n'est
pas important non plus.
Si j'ai la possibilité, j'apprécierai de coder en Python.

2. Un point très important pour moi est, par contre, si c'est possible de
pouvoir empaqueter depuis Linux/Debian l'application Windows et son
installateur sans utiliser Windows.
(Plusieurs outils comme Kivy annonce la possibilité de développer pour
plusieurs plateformes, mais si j'ai bien compris, il faut empaqueter sur la
même plateforme que la cible).

A. Qu'en pensez-vous ? Avez-vous déjà expérimenté une telle chose ?
B. En surfant, j'ai lu que le langage Go (cf [1] annonce la possibilité
d'empaqueter sur Linux pour Windows. Qu'en penser ?
C. J'ai lu des infos sur Flutter/Dart ou Qt mais rien de précis sur
l'empaquetage.

[1] https://golangr.com/gui/

Slts

Re: conseils généraux -pour un vieux geek- pour tablette Android & Debian

2019-09-12 Par sujet Romain Gobert 
L'app UserLAnd devrait vous plaire : 
https://play.google.com/store/apps/details?id=tech.ula


On 11/09/2019 20:35, Basile Starynkevitch wrote:
Utiliser le plus possible ma tablette comme j'utilise mon PC Linux. La 
ligne de commande est mon interface préférée.

Re: conseils généraux -pour un vieux geek- pour tablette Android & Debian

2019-09-12 Par sujet didier . gaumet 
Le mercredi 11 septembre 2019 20:40:02 UTC+2, Basile Starynkevitch a écrit :
[...] 
> Je rêve de pouvoir faire sur ma tablette ce que je sais faire
>   avec aisance sur un ordinateur portable Linuxien:
> 
>   Compiler un GCC récent pour ma tablette (peut-être en
> "canadian cross build", compilé sur mon desktop Debian). 
> 
>   
>   Utiliser GCC sur ma tablette en ligne de commande.
>   Utiliser le plus possible ma tablette comme j'utilise mon PC
> Linux. La ligne de commande est mon interface préférée.
> 
>   
>   Développer -sur ma tablette, dans le RER ou le TGV, sans Wifi-
> pour m'amuser une petite application Android en GPLv3+ qui mixe
> du code natif C++ ou même Guile ou Ocaml (que je sais déjà
> écrire) avec du code Java (que je saurais écrire; j'ai déjà
> écrit un ou deux milles lignes de Java mais il y a environ dix
> ans; j'ai potassé  au siècle dernier la spécification de la JVM
> et de son bytecode et j'avais rédigé un rapport technique
> interne à son sujet). 
[...]

Comme je ne maîtrise pas le sujet (donc pas la peine de me demander plus de 
détails, je ne connais pas), j'énonce juste quelques points dont tu as 
peut-être déjà connaissance ou qui seront sans intérêt pour toi, mais dans le 
doute:

- tu peux activer le "mode développeur" sous Android, qui après paramétrage te 
donne la possibilité d'utiliser un terminal. Plus de détails sur l'activation 
là:
https://www.frandroid.com/comment-faire/tutoriaux/184906_comment-acceder-au-mode-developpeur-sur-android

- en passant, d'après ce que j'ai compris, Android a suivi le même chemin que 
les *BSD pour passer de gcc à clang comme compilo principal il ya quelques 
années

- directement sous Android, il existe une appli C4droid qui peut être 
complémentée par un plugin gcc. Donc je suppose que yu dois te trouver à 
certains moments dans une interface styme terminal et que tu dois être à même , 
une fois le plugin installé, d'appeler les commandes gcc depuis le vrai 
terminal android. 
https://play.google.com/store/apps/details?id=com.n0n3m4.droidc

- il y a un article du wiki Debian concernant l'installation de Debian sur 
Android:
https://wiki.debian.org/ChrootOnAndroid

conseils généraux -pour un vieux geek- pour tablette Android & Debian

2019-09-11 Par sujet Basile Starynkevitch 

Bonjour à tous


(un message un peu moins hors sujet que pas mal d'autres ici, y compris 
signés de moi)


Je connais très bien Unix, et depuis 1987. Je l'ai appris à l'époque en 
lisant les pages de man dans des classeurs papiers de la section 1 à la 
section 9. J'ai lu avec attention le ALP 
. (et j'ai 
l'orgueil d'imaginer que je pourrais le mettre au goût du jour). Ça vous 
forge le caractère :-D


Je pratique Linux depuis 1993, et Debian depuis le siècle dernier. Au 
bureau comme à la maison: Debian/Sid sur de gros desktops (Intel à 10 
coeurs + 128Go RAM au taf, AMD Ryzen Threadripper 2970WX + 64Go RAM à la 
maison); deux larges écrans dans les deux cas (je suis vieux donc 
bigleux);  et j'y ai le mot de passe root (et aussi la compétence 
associée). Je suis donc bien plus à l'aise avec la ligne de commande en 
zsh, les scripts bash ou guile , le 
bon vieux émulateur de terminal (mon premier était le cmdtool de SunOS 
3.2, 
actuellement j'oscille entre lxterminal & xfce4-terminal et je pousse 
parfois la coquetterie jusqu'à gnome-terminal), les gestionnaires de 
fenêtres X11 à l'ancienne (xfce4, icewm, ...)  qu'avec les GUIseries et 
clikodromes de tous poils.


Professionnellement, je suis ingénieur chercheur en cybersécurité au 
CEA/LIST. J'y développe du logiciel libre spécialisé de TRL 
 bas; voir le 
code en http://github.com/bstarynk/bismon (en GPLv3+, sous copyright 
CEA) et le brouillon de rapport en 
http://starynkevitch.net/Basile/bismon-chariot-doc.pdf (souvent mis à jour).


Je sais -sans difficulté notable autre que 
 ma motivation et ma patience et les 
deux sont limitées et en décroissance- compiler GCC, Clang/LLVM, le 
noyau Linux, Qt, Clang, Xorg, opam,  depuis leur code source (que je 
saurais améliorer si le coeur m'en disait), y compris pour obtenir des 
compilateurs croisés (car j'ai même autrefois professionnellement 
contribué à GCC , via GCC MELT 
).



Ma vision est mauvaise (j'ai été opéré de la cataracte il y a un 
trimestre).


Ma mémoire est encore bonne (je me souviens bien d'Unix et du million de 
lignes de code source -pour Unix ou Linux- écrit en une carrière) et je 
n'ai jamais utilisé Windows de ma vie.


Je sais qu'Android 
 est à base de 
noyau Linux.


Pour mes 60 ans, mes enfants (tous adultes) m'ont généreusement offert 
une tablette Huawei MediaPad M5 (Android 8) et je l'ai complétée avec 
une housse clavier logitech qui marche très bien avec. Emacs est déjà 
installé dessus.


Je rêve de pouvoir faire sur ma tablette ce que je sais faire avec 
aisance sur un ordinateur portable Linuxien:


 * Compiler un GCC récent pour ma tablette (peut-être en "canadian
   cross build", compilé sur mon desktop Debian).
 * Utiliser GCC sur ma tablette en ligne de commande.
 * Utiliser le plus possible ma tablette comme j'utilise mon PC Linux.
   La ligne de commande est mon interface préférée.
 * Développer -sur ma tablette, dans le RER ou le TGV, sans Wifi- pour
   m'amuser une petite application Android en GPLv3+ qui mixe du code
   natif C++ ou même Guile ou Ocaml (que je sais déjà écrire) avec du
   code Java (que je saurais écrire; j'ai déjà écrit un ou deux milles
   lignes de Java mais il y a environ dix ans; j'ai potassé  au siècle
   dernier la spécification de la JVM et de son bytecode et j'avais
   rédigé un rapport technique interne à son sujet).


J'imagine que les techniques setuid 
 et chroot 
 sont fortement utilisées sous 
Android.


Je ne veux pas perdre la garantie (donc pas de tentative de rootkit 
avant un an).


J'ai besoin d'apprendre, mais quoi et où?

La ressource la plus chère, c'est mon propre temps.

Librement


--
Basile STARYNKEVITCH   == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France; 
(mobile phone: cf my web page / voir ma page web...)

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

2019-03-27 Par sujet Erwann Le Bras 


Le 26/03/2019 à 15:13, Olivier a écrit :

À mon sens, il y a deux aspects bien distincts:
1- empêcher les accès illégitimes
2- empêcher les conséquences néfastes d'un accès illégitime.

J'ai quand même l'impression que sur une machine Linux sur laquelle 
root a beaucoup (trop ?), le point 2 n'est vraiment pas facile à traiter.

Qui sait vraiment cloisonner une machine ?

Mon sentiment est que la majorité se focalise sur le point 1 en 
gardant pour plus tard le point 2, un jour ou on aura le temps ...




c'est pas facile...

chez "moi" les accès sont nominatifs et habilités derrière à acquérir du 
pouvoir par un "simple" sudo su - id, id étant root, oracle, ou qu'en 
sais-je encore.


les grands pouvoirs incluants de grandes responsabilités on n'est jamais 
à l'abri d'une mauvaise manipulation ayant de lourdes conséquences. Ces 
conséquences sont atténuées :


 * par de petits pouvoirs incluant de petits effets néfastes
 * des effets de masquage et réparations importants : sauvegarde,
   redondance, fermes de clusters...

mé bon chez "moi" c'est du gros...

root c'est dieu : seuls des sysadmins devraient y avoir accès, et donc 
eux seuls devraient avoir la possibilité (habilitation technique) 
d'effectuer des opérations sensibles. Pour le reste, l'éducation des 
utilisateurs, le traçage des actions et menace de tirages d'oreilles 
doivent cantonner les utilisateurs à leur simple rôle.

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

2019-03-26 Par sujet Olivier 
À mon sens, il y a deux aspects bien distincts:
1- empêcher les accès illégitimes
2- empêcher les conséquences néfastes d'un accès illégitime.

J'ai quand même l'impression que sur une machine Linux sur laquelle root a
beaucoup (trop ?), le point 2 n'est vraiment pas facile à traiter.
Qui sait vraiment cloisonner une machine ?

Mon sentiment est que la majorité se focalise sur le point 1 en gardant
pour plus tard le point 2, un jour ou on aura le temps ...

C'est sûr que si une société doit exposer une machine sur Internet et qu'en
plus elle est susceptible d'attaques ciblées de la part de concurrents ou
autres, prêts à investir pour la voler ou lui nuire ...


Le mar. 26 mars 2019 à 14:58, Daniel Caillibaud  a
écrit :

> Le 26/03/19 à 10:36, BERTRAND Joël  a écrit :
> > Le nombre de clients que j'ai déjà vus avoir des machines
> > compromises avec un accès root total parce que le mot de passe était trop
> > compliqué
>
> Des mdp root… Question sécurité ça commence mal, donc ensuite, pass mysql
> ou pas…
>
> > et qu'ils ont collé un mot de passe à la turc avec un accès ssh
> > distant possible pour root ne se comptent plus (et même sans ça, le plus
> > beau était un compte ftpuser/ftpuser avec un root/toor, sans accès
> > distant à root par ssh, durée de vie de la machine sur le grand terne, un
> > week-end !). Donc par défaut, l'accès à une base de données se fait chez
> > moi avec un mot de passe même en étant root.
>
> J'ai toujours pas compris ce que ça apportait question sécurité…
>
> Avec un shell root tu change le pass du root db comme tu veux, donc le fait
> qu'il ait un pass ne protège de rien du tout.
>
> --
> Daniel
>
> L'esprit, c'est l'inverse de l'argent, moins on en a, plus on est heureux.
> Voltaire
>
>

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

2019-03-26 Par sujet Daniel Caillibaud 
Le 26/03/19 à 10:36, BERTRAND Joël  a écrit :
> Le nombre de clients que j'ai déjà vus avoir des machines
> compromises avec un accès root total parce que le mot de passe était trop
> compliqué

Des mdp root… Question sécurité ça commence mal, donc ensuite, pass mysql
ou pas…

> et qu'ils ont collé un mot de passe à la turc avec un accès ssh
> distant possible pour root ne se comptent plus (et même sans ça, le plus
> beau était un compte ftpuser/ftpuser avec un root/toor, sans accès
> distant à root par ssh, durée de vie de la machine sur le grand terne, un
> week-end !). Donc par défaut, l'accès à une base de données se fait chez
> moi avec un mot de passe même en étant root.

J'ai toujours pas compris ce que ça apportait question sécurité…

Avec un shell root tu change le pass du root db comme tu veux, donc le fait
qu'il ait un pass ne protège de rien du tout.

-- 
Daniel

L'esprit, c'est l'inverse de l'argent, moins on en a, plus on est heureux.
Voltaire

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

2019-03-26 Par sujet Florian Blanc 
Tous les root passwords de tes machines doivent être différents.
Alors perso je les notes sur un calepin.
Mais attention, je note pas tout.
Par exemple j'ai 3 password en tête un court, un mi-long et un long.
Ce ne sont pas des mots c'est vraiment illogique.
À partir de la sur mon calepin par exemple je note :
Machine.domaine Mysql root : L3ML/Cq
L c'est mon password long
ML c'est le mi long
C le court

Voilà voilà pour ma petite astuce 

On Tue, Mar 26, 2019, 10:48 Florian Blanc 
wrote:

> En même temps BERTRAND.  SOWY
>
> On Tue, Mar 26, 2019, 10:44 Florian Blanc 
> wrote:
>
>> Mwé,
>>
>> root system et root db c'est pas vraiment pareil.
>> root db doit avoir un password différent de root system,
>> Et, allow root db connection only from localhost.
>>
>> (il faudrait trouver un principe qui lock le login Shell from localhost
>> après X logins fails & send mail. Il faudrait que ça soit intégré à mysql
>> par contre).
>>
>> Par contre, après tu peux déjà parse les logs et send mail après un login
>> fail.
>> Ça te permettra de disconnect all root and change password for root sys.
>>
>> Mais bon voilà voilà il faut penser à faire perdre du temps à l'attaquant
>> pour que tu puisse l'expulser avant trop de dégâts.
>>
>> Dans tous les cas si root corrompu, save tes data et formate. 
>>
>> On Tue, Mar 26, 2019, 10:01 Daniel Caillibaud  wrote:
>>
>>> Le 25/03/19 à 14:06, BERTRAND Joël  a écrit :
>>> >   Je considère que ce n'est pas un trou de sécurité, mais une
>>> faille
>>> > délirante. root doit se connecter avec un mot de passe.
>>>
>>> ???
>>>
>>> Si t'es root sur la machine, tu as accès à tous les contenus de toutes
>>> les
>>> bases, je vois pas ce que ça change coté sécurité qu'il puisse se
>>> connecter
>>> sans mot de passe… (on parle localement, un root qui a déjà un shell sur
>>> la
>>> machine).
>>>
>>> --
>>> Daniel
>>>
>>> Il faut choisir, dans la vie, entre gagner de l'argent et le dépenser,
>>> on n'a pas le temps de faire les deux.
>>> Edouard Bourdet
>>>
>>>

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

2019-03-26 Par sujet Florian Blanc 
En même temps BERTRAND.  SOWY

On Tue, Mar 26, 2019, 10:44 Florian Blanc 
wrote:

> Mwé,
>
> root system et root db c'est pas vraiment pareil.
> root db doit avoir un password différent de root system,
> Et, allow root db connection only from localhost.
>
> (il faudrait trouver un principe qui lock le login Shell from localhost
> après X logins fails & send mail. Il faudrait que ça soit intégré à mysql
> par contre).
>
> Par contre, après tu peux déjà parse les logs et send mail après un login
> fail.
> Ça te permettra de disconnect all root and change password for root sys.
>
> Mais bon voilà voilà il faut penser à faire perdre du temps à l'attaquant
> pour que tu puisse l'expulser avant trop de dégâts.
>
> Dans tous les cas si root corrompu, save tes data et formate. 
>
> On Tue, Mar 26, 2019, 10:01 Daniel Caillibaud  wrote:
>
>> Le 25/03/19 à 14:06, BERTRAND Joël  a écrit :
>> >   Je considère que ce n'est pas un trou de sécurité, mais une faille
>> > délirante. root doit se connecter avec un mot de passe.
>>
>> ???
>>
>> Si t'es root sur la machine, tu as accès à tous les contenus de toutes les
>> bases, je vois pas ce que ça change coté sécurité qu'il puisse se
>> connecter
>> sans mot de passe… (on parle localement, un root qui a déjà un shell sur
>> la
>> machine).
>>
>> --
>> Daniel
>>
>> Il faut choisir, dans la vie, entre gagner de l'argent et le dépenser,
>> on n'a pas le temps de faire les deux.
>> Edouard Bourdet
>>
>>

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

2019-03-26 Par sujet Florian Blanc 
Mwé,

root system et root db c'est pas vraiment pareil.
root db doit avoir un password différent de root system,
Et, allow root db connection only from localhost.

(il faudrait trouver un principe qui lock le login Shell from localhost
après X logins fails & send mail. Il faudrait que ça soit intégré à mysql
par contre).

Par contre, après tu peux déjà parse les logs et send mail après un login
fail.
Ça te permettra de disconnect all root and change password for root sys.

Mais bon voilà voilà il faut penser à faire perdre du temps à l'attaquant
pour que tu puisse l'expulser avant trop de dégâts.

Dans tous les cas si root corrompu, save tes data et formate. 

On Tue, Mar 26, 2019, 10:01 Daniel Caillibaud  wrote:

> Le 25/03/19 à 14:06, BERTRAND Joël  a écrit :
> >   Je considère que ce n'est pas un trou de sécurité, mais une faille
> > délirante. root doit se connecter avec un mot de passe.
>
> ???
>
> Si t'es root sur la machine, tu as accès à tous les contenus de toutes les
> bases, je vois pas ce que ça change coté sécurité qu'il puisse se connecter
> sans mot de passe… (on parle localement, un root qui a déjà un shell sur la
> machine).
>
> --
> Daniel
>
> Il faut choisir, dans la vie, entre gagner de l'argent et le dépenser,
> on n'a pas le temps de faire les deux.
> Edouard Bourdet
>
>

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

2019-03-26 Par sujet BERTRAND Joël 
Daniel Caillibaud a écrit :
> Le 25/03/19 à 14:06, BERTRAND Joël  a écrit :
>>  Je considère que ce n'est pas un trou de sécurité, mais une faille
>> délirante. root doit se connecter avec un mot de passe.
> 
> ???
> 
> Si t'es root sur la machine, tu as accès à tous les contenus de toutes les
> bases, je vois pas ce que ça change coté sécurité qu'il puisse se connecter
> sans mot de passe… (on parle localement, un root qui a déjà un shell sur la
> machine).
> 

Le nombre de clients que j'ai déjà vus avoir des machines compromises
avec un accès root total parce que le mot de passe était trop compliqué
et qu'ils ont collé un mot de passe à la turc avec un accès ssh distant
possible pour root ne se comptent plus (et même sans ça, le plus beau
était un compte ftpuser/ftpuser avec un root/toor, sans accès distant à
root par ssh, durée de vie de la machine sur le grand terne, un week-end
!). Donc par défaut, l'accès à une base de données se fait chez moi avec
un mot de passe même en étant root. Ce truc m'a déjà sauvé la vie
plusieurs fois. Parce que lorsqu'une machine est compromise, ce n'est
jamais la faute du type qui a installé un service mal configuré, c'est
toujours de la faute du type qui a fournit l'installation. J'en suis
même arrivé dans mes CGV à indiquer brutalement que les GTR ne
s'appliquaient qu'en cas de configuration hard et soft non modifiée par
le client. Même mysqladmin demande un mot de passe :

root@hilbert:~# mysqladmin processlist
mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'root'@'localhost' (using password: NO)'

Pour l'instant, je ne suis pas encore tombé sur un attaquant qui se
soit permis d'arrêter une base pour utiliser mysqladmin brutalement ou
qui soit passé outre le mot de passe administrateur de la base de
données, ils cherchent plutôt à récupérer des infos sans qu'on s'en
rende compte ou de corrompre des systèmes fonctionnels. En espérant que
ça ne change pas.

Donc oui, le fait d'avoir un mot de passe sur l'accès à la base ne
protège pas de tout, loin de là, mais ça peut emmerder et ralentir
substantiellement l'attaquant.

Bien cordialement,

JKB

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

2019-03-26 Par sujet Daniel Caillibaud 
Le 25/03/19 à 14:06, BERTRAND Joël  a écrit :
>   Je considère que ce n'est pas un trou de sécurité, mais une faille
> délirante. root doit se connecter avec un mot de passe.

???

Si t'es root sur la machine, tu as accès à tous les contenus de toutes les
bases, je vois pas ce que ça change coté sécurité qu'il puisse se connecter
sans mot de passe… (on parle localement, un root qui a déjà un shell sur la
machine).

-- 
Daniel

Il faut choisir, dans la vie, entre gagner de l'argent et le dépenser, 
on n'a pas le temps de faire les deux. 
Edouard Bourdet

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

2019-03-25 Par sujet BERTRAND Joël 
Olivier a écrit :
> 
> 
> Le lun. 25 mars 2019 à 12:19, BERTRAND Joël  > a écrit :
> 
> 
> 
>         Pas chez moi :
> 
> 
> @Joel:
> Que donne 'SELECT host, user, password, plugin FROM mysql.user;' sur ta
> machine ?
> Sur la mienne, j'ai bien le plugin unix_socket qu'Alexandre mentionne
> dans son message.

Je vire toujours la socket Unix.

MariaDB [(none)]> select host,user,password,plugin from mysql.user where
user='root';
+---+--+---++
| host  | user | password  | plugin |
+---+--+---++
| localhost | root | *8DD098CAB69587D2A67BE8E8A66010A99DF39A75 ||
| rayleigh  | root | *8DD098CAB69587D2A67BE8E8A66010A99DF39A75 ||
+---+--+---++
2 rows in set (0.000 sec)

Je considère que ce n'est pas un trou de sécurité, mais une faille
délirante. root doit se connecter avec un mot de passe.

JKB

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

2019-03-25 Par sujet Olivier 
Le lun. 25 mars 2019 à 12:19, BERTRAND Joël  a
écrit :

>
>
> Pas chez moi :
>
>
> @Joel:
Que donne 'SELECT host, user, password, plugin FROM mysql.user;' sur ta
machine ?
Sur la mienne, j'ai bien le plugin unix_socket qu'Alexandre mentionne dans
son message.

@Alexandre:
Merci pour ton lien: il explique bien le nouveau paramétrage.
Le lien [1] le détaille aussi.
Pour l'instant, je conserve ce nouveau fonctionnement en l'état.
Je marque néanmoins ce fil de discussion comme RESOLU car je pense qu'il
pourra être utile à d'autres.

Merci à vous

[1] https://mariadb.com/kb/en/library/authentication-plugin-unix-socket/

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ?

2019-03-25 Par sujet Alexandre Goethals 
Bonjour,

pour la connexion au compte root sans mot de passe (en local), c'est
parce que ce compte utilise le plugin unix socket:

|SELECThost,user,password,plugin FROMmysql.user; devrait donner quelque
chose comme: 
||+---+--+--+-+|host
|user|password |plugin
|+---+--+--+-+|localhost
|root ||unix_socket
|+---+--+--+-+ Donc il
faut faire: ||UPDATEmysql.userSETplugin =''WHEREuser='root'ANDhost 
='localhost';FLUSH
PRIVILEGES; redémarrer mariadb source:
https://stackoverflow.com/questions/7179894/how-to-disable-mysql-root-logins-when-no-password-is-supplied
|

Le 25/03/2019 à 12:19, BERTRAND Joël a écrit :
> Olivier a écrit :
>> Bonjour,
>   Bonjour,
>
>> Je travaille sur une configuration de Freeradius avec une base de
>> données pour Debian Buster.
>>
>> Comme la documentation de Freeradius avec base de données se réfère
>> massivement à MySQL, j'ai installé sur une VM, MySQL/MariaDB avec la
>> commande apt-get install default-mysql-server suivie de
>> mysql_secure_installation.
>>
>> J'ai volontairement installé default-mysql-servercar dans mon cas, je
>> suis indifférent au choix MySQL/MariaDB: je souhaite juste mettre au
>> point une configuration qui fonctionnera quand Buster sera la version
>> stable de Debian.
>>
>> Ce faisant, j'ai été surpris de constater qu'après ces 2 commandes, la
>> méthode d'accès à MySQL/MariaDB avait changé:
>>
>> - l'utilisateur root peut se connecter sans mot de passe ou avec un mot
>> de passe erroné
>   Pas chez moi :
>
> Root rayleigh:[~] > mysql -uroot -p
> Enter password:
> ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using
> password: YES)
> Root rayleigh:[~] >
>
>   Naturellement, si je fournis le bon mot de passe, ça fonctionne comme
> attendu.
>
>> - un utilisateur lambda ne peut plus se connecter en tant qu'utilisateur
>> MySQL/MariaDB root même en fournissant le bon mot de passe.
>   Pas chez moi :
>
> rayleigh:[~] > mysql -uroot -p
> Enter password:
> Welcome to the MariaDB monitor.  Commands end with ; or \g.
> Your MariaDB connection id is 10044
> Server version: 10.3.13-MariaDB-1-log Debian buildd-unstable
>
> Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
>
> Type 'help;' or '\h' for help. Type '\c' to clear the current input
> statement.
>
> MariaDB [(none)]> quit
> Bye
> rayleigh:[~] > whoami
> bertrand
>
>   À mon avis, le problème est ailleurs ;-)
>
>   Je commencerais pas jeter un oeil à la configuration de mariadb.
>
>   Bien cordialement,
>
>   JKB
>

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ?

2019-03-25 Par sujet BERTRAND Joël 
Olivier a écrit :
> Bonjour,

Bonjour,

> Je travaille sur une configuration de Freeradius avec une base de
> données pour Debian Buster.
> 
> Comme la documentation de Freeradius avec base de données se réfère
> massivement à MySQL, j'ai installé sur une VM, MySQL/MariaDB avec la
> commande apt-get install default-mysql-server suivie de
> mysql_secure_installation.
> 
> J'ai volontairement installé default-mysql-servercar dans mon cas, je
> suis indifférent au choix MySQL/MariaDB: je souhaite juste mettre au
> point une configuration qui fonctionnera quand Buster sera la version
> stable de Debian.
> 
> Ce faisant, j'ai été surpris de constater qu'après ces 2 commandes, la
> méthode d'accès à MySQL/MariaDB avait changé:
> 
> - l'utilisateur root peut se connecter sans mot de passe ou avec un mot
> de passe erroné

Pas chez moi :

Root rayleigh:[~] > mysql -uroot -p
Enter password:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using
password: YES)
Root rayleigh:[~] >

Naturellement, si je fournis le bon mot de passe, ça fonctionne comme
attendu.

> - un utilisateur lambda ne peut plus se connecter en tant qu'utilisateur
> MySQL/MariaDB root même en fournissant le bon mot de passe.

Pas chez moi :

rayleigh:[~] > mysql -uroot -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 10044
Server version: 10.3.13-MariaDB-1-log Debian buildd-unstable

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.

MariaDB [(none)]> quit
Bye
rayleigh:[~] > whoami
bertrand

À mon avis, le problème est ailleurs ;-)

Je commencerais pas jeter un oeil à la configuration de mariadb.

Bien cordialement,

JKB

Conseils sur l'administration de MySQL/MariaDB sur Buster ?

2019-03-25 Par sujet Olivier 
Bonjour,

Je travaille sur une configuration de Freeradius avec une base de données
pour Debian Buster.

Comme la documentation de Freeradius avec base de données se réfère
massivement à MySQL, j'ai installé sur une VM, MySQL/MariaDB avec la
commande apt-get install default-mysql-server suivie de
mysql_secure_installation.

J'ai volontairement installé default-mysql-servercar dans mon cas, je suis
indifférent au choix MySQL/MariaDB: je souhaite juste mettre au point une
configuration qui fonctionnera quand Buster sera la version stable de
Debian.

Ce faisant, j'ai été surpris de constater qu'après ces 2 commandes, la
méthode d'accès à MySQL/MariaDB avait changé:

- l'utilisateur root peut se connecter sans mot de passe ou avec un mot de
passe erroné
- un utilisateur lambda ne peut plus se connecter en tant qu'utilisateur
MySQL/MariaDB root même en fournissant le bon mot de passe.

J'ai trouvé sur Internet vraiment très peu de doc sur l'administration de
MySQL/MariaDBsous Buster.

Avez-vous des conseils sur ceci dans le cas où on a besoin d'exécuter des
scripts de création-configuration de base de données MySQL ?

Faut-il installer MySQL plutôt que MariaDB ? Le contraire ?
Y-a-t-il une autre commande que mysql_secure_installation à exécuter ?
Peut-on sans état d'âme ignorer cette différence avec les versions de MySQL
sous Jessie ou autre ?
Documentation ?

Slts

Re: Conseils sur la configuration de PostgreSQL

2019-03-19 Par sujet Alexandre Goethals 
Bonjour,

personnellement, je ne mets pas de mot de passe au compte postgres, mais
je fais en sorte que seul root puisse se connecter en tant que postgres
(su - postgres).

Pour scripter des commandes psql, avec un mot de passe, je fais quelque
chose comme:

PGPASSWORD=motdepasse psql -U compteutilisateur -d basededonnées -c
'commande sql ;'

(le tout sur une seule ligne)

Une autre solution est de faire exécuter le script par un compte système
pour lequel il existe un rôle postgresql avec le même nom et qui se
connecte par la méthode peer (comme postgres), ou alors jouer avec le
mapping des comptes dans pg_ident.conf. Dans ce cas, plus besoin de
fournir la variable PGPASSWORD avant la commande psql

Voir aussi man psql pour les autres options fort utiles de psql,
notamment par rapport à des exécutions non interactives (sortir les
résultats selon un certain formalisme, etc)

Je n'ai pas bien compris la question pour pg_hba.conf. Je ne me sers de
ce fichier que pour définir quels rôles sont habilités à se connecter
sur telle ou telle base, depuis quel(s) hôte(s) et selon quelle méthode
(le plus souvent peer ou md5)

Le 19/03/2019 à 15:05, Olivier a écrit :
> Hello,
>
> Déformé par des années de pratique (peu intensive) de MySQL, je
> découvre PostgreSQL.
>
> J'ai un peu de mal à me faire une religion sur la façon canonique de
> configurer PostgreSQL.
> Avez-vous des conseils sur le sujet ?
>
> 1. Est-ce un bon objectif de configurer un mot de passe pour
> l'utilisateur postgres ? Si oui, quelle méthode conseillez-vous pour
> scripter (cf [2]) des commandes PostgreSQL ?
> 3. Comment maintenir le fichier pg_hba.conf ? En y ajoutant une
> directive indiquant un fichier externe (perso.conf, local.conf, ...)
> de façon à bien distinguer les paramètres de Debian de ses propres
> paramètres ?
>
> Slts
>
> [1] https://wiki.debian.org/PostgreSql
> [2]
> https://blog.sleeplessbeastie.eu/2014/03/23/how-to-non-interactively-provide-password-for-the-postgresql-interactive-terminal/

Conseils sur la configuration de PostgreSQL

2019-03-19 Par sujet Olivier 
Hello,

Déformé par des années de pratique (peu intensive) de MySQL, je découvre
PostgreSQL.

J'ai un peu de mal à me faire une religion sur la façon canonique de
configurer PostgreSQL.
Avez-vous des conseils sur le sujet ?

1. Est-ce un bon objectif de configurer un mot de passe pour l'utilisateur
postgres ? Si oui, quelle méthode conseillez-vous pour scripter (cf [2])
des commandes PostgreSQL ?
3. Comment maintenir le fichier pg_hba.conf ? En y ajoutant une directive
indiquant un fichier externe (perso.conf, local.conf, ...) de façon à bien
distinguer les paramètres de Debian de ses propres paramètres ?

Slts

[1] https://wiki.debian.org/PostgreSql
[2]
https://blog.sleeplessbeastie.eu/2014/03/23/how-to-non-interactively-provide-password-for-the-postgresql-interactive-terminal/

Re: Conseils sur la mise à jour d'application maison développée avec Django

2019-02-13 Par sujet Daniel Caillibaud 
Le 12/02/19 à 14:34, Olivier  a écrit :
> Avez-vous des conseils pour que les changements de version s'opèrent en
> douceur ?

Si tu prévois des évolutions du schéma de données, il faut impérativement
gérer des scripts d'updates.

Tu peux faire
- tu coupes
- tu passe ton script de mise à jour de la structure et déploie tes fichiers
- tu redémarres avec la nouvelle version

Mais souvent on coupe pas et ça se fait au démarrage de l'application :
- déployer les nouveaux fichiers de l'application
- lancer un reload qui devra gérer les étapes suivantes :

- je regarde dans la base de données quelle est le dernier update appliqué
- je regarde dans le dossier d'updates si y'en a un plus récent à appliquer
- si oui je le lance et quand il a fini je repars au début
- sinon je démarre vraiment l'application et je peux commencer à répondre
  aux requêtes 

Pour limiter les coupures sur des applis avec de grosses bases, on peut
gérer la notion de mises à jour non bloquantes (par ex un update qui va
ajouter un champ calculé, mais dont l'absence ne plante pas l'appli), tu
peux gérer cet aspect bloquant / non bloquant dans les étapes décrites
ci-dessus (si tous les updates qui restent à appliquer sont non-bloquants
tu peux démarrer quand même et les lancer en tâche de fond, mais en
séquentiel).

Pour la mise à jour sans modif de schéma, en général c'est rsync puis
redémarrage du serveur applicatif. Je suppose que django ne relit les
fichiers qu'au démarrage ou à leur premier appel et que ça pose pas de pb
si le rsync dure qq secondes.

-- 
Daniel

Moi, je ne me pose jamais aucune question. 
Je me demande d'ailleurs bien pourquoi…

Conseils sur la mise à jour d'application maison développée avec Django

2019-02-12 Par sujet Olivier 
Bonjour,

Je dois bientôt démarrer le développement d'une application "maison" avec
Django (et Postgres pour la base de données).

J'imagine livrer plusieurs versions successives de l'application avec entre
deux versions principalement des modifications du modèle et du code
applicatif mais peut être aussi l'ajout ou la mise à jour de modules Django.

L'application gère relativement peu de données (des données de
configuration) et pour donner un ordre de grandeur, la perte de toutes les
données saisies pendant une saisie me semble acceptable.

Avez-vous des conseils pour que les changements de version s'opèrent en
douceur ?
Comment opèrent ceux qui font du CI/CD au petit déjeuner ?

Slts

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-24 Par sujet Daniel Huhardeaux 

Le 24/01/2019 à 11:32, Olivier a écrit :



Le jeu. 24 janv. 2019 à 11:18, Daniel Huhardeaux > a écrit :




Rien ne t'empêche de mettre une seconde configuration VPN en parallèle
chez tes clients (et chez toi) sur un autre port !

Je suis d'accord.


Pour ma part, je réitère: un serveur VPN central sur lequel vont se
connecter les clients et toi, du réseau bureau ou déplacement.

                  serveur VPN
                  /     | ...\
              clt1    clt2    Cltx

Le lien est permanent pour les clients sauf pour toi (si tu le désire)


Je suis d'accord sauf peut-être sur la persistance des liens car ne 
l'oublions pas, j'ai des plages d'adresses identiques sur des sites 
différents et ça va rester.


Quelle techno de VPN te sembles la plus adaptée pour ça ?


tun

On garde OpenVPN (pas de logiciels supplémentaire à installer): juste 
une re-configuration au cas par cas pour la deuxième instance d'OpenVPN ?

Ça me semble une très bonne idée mais je préfère demander.


Oui




Pas de port ouvert sauf celui pour le VPN et ssh en secours. Cela veut
dire que tu pourras te connecter (ssh avec mot de passe) chez tes
clients à partir de n'importe quel matériel, pas seulement de ceux qui
te sont connus.


 >
 >
 >
 > Le mer. 23 janv. 2019 à 16:16, Pascal Hambourg
mailto:pas...@plouf.fr.eu.org>
 > >>
a écrit :
 >
 >     Le 23/01/2019 à 15:58, Olivier a écrit :
 >      >
 >      > [1]
https://serverfault.com/questions/736274/openvpn-client-to-client
 >
 >     Ce lien confirme ce que j'écrivais ci-dessous :
 >
 >      > Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg
 >     mailto:pas...@plouf.fr.eu.org>
>> a
 >      > écrit :
 >      >
 >      >> Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :
 >      >>>
 >      >>> 1. Oui tu as bien compris, client-to-client ne transite
pas le
 >     paquet par
 >      >>> le serveur. Du coup pas de filtrage possible si c'est option
 >     est activée.
 >      >>
 >      >> Si j'ai bien compris, plus précisément les paquets envoyés à
 >     l'intérieur
 >      >> du tunnel entre deux clients ne transitent pas par
l'interface
 >     tun/tap
 >      >> ni la pile réseau de la machine qui fait tourner le
serveur openvpn,
 >      >> mais les paquets transportant le tunnel passent quand
même par le
 >      >> serveur openvpn.
 >

Re: Conseils sur le routage de client à client avec OpenVPN [RESOLU]

2019-01-24 Par sujet Olivier 
Grâce aux différents conseils ici reçus, j'ai pu rapidement mettre en place
un prototype de VPN dédié à la télé-gestion de réseaux locaux distants en
complément de mon VPN dédié à la télé-gestion de machines distantes.

- Mes deux VPN utilisent OpenVPN.
- On peut faire tourner parallèlement plusieurs instances d'OpenVPN mais
chacune doit avoir son propre procole/port d'écoute.
- On peut mettre en communs des certificats et clés.
- La topologie subnet est recommandée (celle par défaut est net30)
- L'option client-to-client facilite les communications "directes"
inter-clients
- Chaque instance d'OpenVPN produit son fichier openvpn-status.lo qui
contient une photo de la table de routage interne à OpenVPN à savoir la
liste des clients OpenVPN et la liste des réseaux locaux déclarés par ces
clients
- Au démarrage, un client OpenVPN modifie la table de routage du client: je
n'ai pas eu besoin d'ajouter des règles pour le NAT.

Merci infiniment à tous pour votre aide

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-24 Par sujet Olivier 
Le jeu. 24 janv. 2019 à 11:18, Daniel Huhardeaux  a
écrit :

>
>
> Rien ne t'empêche de mettre une seconde configuration VPN en parallèle
> chez tes clients (et chez toi) sur un autre port !
>
Je suis d'accord.


> Pour ma part, je réitère: un serveur VPN central sur lequel vont se
> connecter les clients et toi, du réseau bureau ou déplacement.
>
>  serveur VPN
>  / | ...\
>  clt1clt2Cltx
>
> Le lien est permanent pour les clients sauf pour toi (si tu le désire)
>

Je suis d'accord sauf peut-être sur la persistance des liens car ne
l'oublions pas, j'ai des plages d'adresses identiques sur des sites
différents et ça va rester.

Quelle techno de VPN te sembles la plus adaptée pour ça ?
On garde OpenVPN (pas de logiciels supplémentaire à installer): juste une
re-configuration au cas par cas pour la deuxième instance d'OpenVPN ?
Ça me semble une très bonne idée mais je préfère demander.


>
> Pas de port ouvert sauf celui pour le VPN et ssh en secours. Cela veut
> dire que tu pourras te connecter (ssh avec mot de passe) chez tes
> clients à partir de n'importe quel matériel, pas seulement de ceux qui
> te sont connus.
>
>
> >
> >
> >
> > Le mer. 23 janv. 2019 à 16:16, Pascal Hambourg  > > a écrit :
> >
> > Le 23/01/2019 à 15:58, Olivier a écrit :
> >  >
> >  > [1]
> https://serverfault.com/questions/736274/openvpn-client-to-client
> >
> > Ce lien confirme ce que j'écrivais ci-dessous :
> >
> >  > Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg
> > mailto:pas...@plouf.fr.eu.org>> a
> >  > écrit :
> >  >
> >  >> Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :
> >  >>>
> >  >>> 1. Oui tu as bien compris, client-to-client ne transite pas le
> > paquet par
> >  >>> le serveur. Du coup pas de filtrage possible si c'est option
> > est activée.
> >  >>
> >  >> Si j'ai bien compris, plus précisément les paquets envoyés à
> > l'intérieur
> >  >> du tunnel entre deux clients ne transitent pas par l'interface
> > tun/tap
> >  >> ni la pile réseau de la machine qui fait tourner le serveur
> openvpn,
> >  >> mais les paquets transportant le tunnel passent quand même par le
> >  >> serveur openvpn.
> >
>
>

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-24 Par sujet Daniel Huhardeaux 

Le 24/01/2019 à 10:54, Olivier a écrit :

Bonjour,

La nuit porte conseil et en repensant à ce qui précède, je pense que mon 
besoin premier est d'utiliser mon VPN comme un tunnel laissant passer 
des flux entre deux clients du VPN

sans les interpréter lui-même.

Le VPN est le seul lien que j'ai avec des sites distants et je ne peux 
pas risquer de perdre un lien en reconfigurant OpenVPN.
Or il me semble que les paramètres de routage d'OpenVPN ont une portée 
générale avec des précautions que j'ai du mal à respecter (adresses 
uniques, ...).


En conclusion:
1- je ne change pas ma configuration d'OpenVPN
2- s'il existe une technique pour utiliser ma configuration OpenVPN 
comme un "tunnel entre mon PC et un LAN distant" et sans le 
re-configurer, ça m'intéresse
3- s'il existe une autre technologie de VPN (IPSEC ? Wireguard ? ...) 
pour faire ce que je recherche et utilisable en parallèle à OpenVPN, ça 
m'intéresse aussi.


Pour le point 3, je n'ai pas besoin d'avoir un tunnel permanent entre 
mon PC et le LAN distant: j'ai juste besoin de pouvoir établir ce tunnel 
le temps d'une session de déboguage.
Je peux pouvoir initier ce tunnel quand je suis en déplacement et 
connecté à réseau local dont je ne pourrai pas modifier la configuration 
du routeur: je devrai donc passer par une machine tierce sur Internet 
qui aura les ports ouverts nécessaires.


Pour compléter mon cahier des charges:
- toutes les machines concernées (mon PC, machine tierce, routeur sur le 
LAN distant) sont sous Debian avec toutefois des versions variées 
(jessie, stretch, ...).


Conseils, remarques et suggestions bienvenues !


Rien ne t'empêche de mettre une seconde configuration VPN en parallèle 
chez tes clients (et chez toi) sur un autre port !


Pour ma part, je réitère: un serveur VPN central sur lequel vont se 
connecter les clients et toi, du réseau bureau ou déplacement.


serveur VPN
/ | ...\
clt1clt2Cltx

Le lien est permanent pour les clients sauf pour toi (si tu le désire)

Pas de port ouvert sauf celui pour le VPN et ssh en secours. Cela veut 
dire que tu pourras te connecter (ssh avec mot de passe) chez tes 
clients à partir de n'importe quel matériel, pas seulement de ceux qui 
te sont connus.







Le mer. 23 janv. 2019 à 16:16, Pascal Hambourg <mailto:pas...@plouf.fr.eu.org>> a écrit :


Le 23/01/2019 à 15:58, Olivier a écrit :
 >
 > [1] https://serverfault.com/questions/736274/openvpn-client-to-client

Ce lien confirme ce que j'écrivais ci-dessous :

 > Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg
mailto:pas...@plouf.fr.eu.org>> a
 > écrit :
 >
 >> Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :
 >>>
 >>> 1. Oui tu as bien compris, client-to-client ne transite pas le
paquet par
 >>> le serveur. Du coup pas de filtrage possible si c'est option
est activée.
 >>
 >> Si j'ai bien compris, plus précisément les paquets envoyés à
l'intérieur
 >> du tunnel entre deux clients ne transitent pas par l'interface
tun/tap
 >> ni la pile réseau de la machine qui fait tourner le serveur openvpn,
 >> mais les paquets transportant le tunnel passent quand même par le
 >> serveur openvpn.

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-24 Par sujet Olivier 
Bonjour,

La nuit porte conseil et en repensant à ce qui précède, je pense que mon
besoin premier est d'utiliser mon VPN comme un tunnel laissant passer des
flux entre deux clients du VPN
sans les interpréter lui-même.

Le VPN est le seul lien que j'ai avec des sites distants et je ne peux pas
risquer de perdre un lien en reconfigurant OpenVPN.
Or il me semble que les paramètres de routage d'OpenVPN ont une portée
générale avec des précautions que j'ai du mal à respecter (adresses
uniques, ...).

En conclusion:
1- je ne change pas ma configuration d'OpenVPN
2- s'il existe une technique pour utiliser ma configuration OpenVPN comme
un "tunnel entre mon PC et un LAN distant" et sans le re-configurer, ça
m'intéresse
3- s'il existe une autre technologie de VPN (IPSEC ? Wireguard ? ...) pour
faire ce que je recherche et utilisable en parallèle à OpenVPN, ça
m'intéresse aussi.

Pour le point 3, je n'ai pas besoin d'avoir un tunnel permanent entre mon
PC et le LAN distant: j'ai juste besoin de pouvoir établir ce tunnel le
temps d'une session de déboguage.
Je peux pouvoir initier ce tunnel quand je suis en déplacement et connecté
à réseau local dont je ne pourrai pas modifier la configuration du routeur:
je devrai donc passer par une machine tierce sur Internet qui aura les
ports ouverts nécessaires.

Pour compléter mon cahier des charges:
- toutes les machines concernées (mon PC, machine tierce, routeur sur le
LAN distant) sont sous Debian avec toutefois des versions variées (jessie,
stretch, ...).

Conseils, remarques et suggestions bienvenues !



Le mer. 23 janv. 2019 à 16:16, Pascal Hambourg  a
écrit :

> Le 23/01/2019 à 15:58, Olivier a écrit :
> >
> > [1] https://serverfault.com/questions/736274/openvpn-client-to-client
>
> Ce lien confirme ce que j'écrivais ci-dessous :
>
> > Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg 
> a
> > écrit :
> >
> >> Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :
> >>>
> >>> 1. Oui tu as bien compris, client-to-client ne transite pas le paquet
> par
> >>> le serveur. Du coup pas de filtrage possible si c'est option est
> activée.
> >>
> >> Si j'ai bien compris, plus précisément les paquets envoyés à l'intérieur
> >> du tunnel entre deux clients ne transitent pas par l'interface tun/tap
> >> ni la pile réseau de la machine qui fait tourner le serveur openvpn,
> >> mais les paquets transportant le tunnel passent quand même par le
> >> serveur openvpn.
>
>

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-23 Par sujet Pascal Hambourg 

Le 23/01/2019 à 15:58, Olivier a écrit :


[1] https://serverfault.com/questions/736274/openvpn-client-to-client


Ce lien confirme ce que j'écrivais ci-dessous :


Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg  a
écrit :


Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :


1. Oui tu as bien compris, client-to-client ne transite pas le paquet par
le serveur. Du coup pas de filtrage possible si c'est option est activée.


Si j'ai bien compris, plus précisément les paquets envoyés à l'intérieur
du tunnel entre deux clients ne transitent pas par l'interface tun/tap
ni la pile réseau de la machine qui fait tourner le serveur openvpn,
mais les paquets transportant le tunnel passent quand même par le
serveur openvpn.

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-23 Par sujet Olivier 
Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg  a
écrit :

>
> Il y a une bidouille possible à base de double NAT source+destination.
> Pour chaque réseau utilisant l'adressage 192.168.1.0/24 en interne, on
> définit un réseau externe unique, on configure le routage des réseaux
> externes sur le serveur openvpn et on met en place des règles NETMAP sur
> la passerelle de chaque réseau pour faire en sorte que :
> - quand un paquet est émis vers le tunnel, son adresse source est mappée
> en son adresse externe correspondant au réseau ;
> - quant un paquet est reçu par le tunnel à destination d'une adresse
> externe, son adresse est mappée en l'adresse interne correspondante.
>
> Evidemment, ça ne marche qu'avec les protocoles supportés par le NAT.
>
>
Excellent !
Je ne connaissait pas l'option -j NETMAP qui a l'air adaptée car si sur
beaucoup de sites distants, je retrouve les mêmes adresses IP, j'ai aussi
une nomenclature avec un entier unique pour chaque site.
Il devrait pas être difficile d'associer cet entier à une plage d'adresse
propre à chaque site.

Merci infiniment pour l'avoir signalée

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-23 Par sujet Olivier 
Mea culpa: voici le lien manquant !

[1] https://serverfault.com/questions/736274/openvpn-client-to-client

Le mer. 23 janv. 2019 à 15:46, Pascal Hambourg  a
écrit :

> Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :
> >
> > 1. Oui tu as bien compris, client-to-client ne transite pas le paquet par
> > le serveur. Du coup pas de filtrage possible si c'est option est activée.
>
> Si j'ai bien compris, plus précisément les paquets envoyés à l'intérieur
> du tunnel entre deux clients ne transitent pas par l'interface tun/tap
> ni la pile réseau de la machine qui fait tourner le serveur openvpn,
> mais les paquets transportant le tunnel passent quand même par le
> serveur openvpn.
>
> > 2. Si tous les réseaux connectés sont sur le même réseau (192.168.1.0/24
> ),
> > je ne vois pas comment il sera possible de router les paquets d'un réseau
> > comme il faut. Donc je ne vois pas comment ça peut marcher.
>
> Il y a une bidouille possible à base de double NAT source+destination.
> Pour chaque réseau utilisant l'adressage 192.168.1.0/24 en interne, on
> définit un réseau externe unique, on configure le routage des réseaux
> externes sur le serveur openvpn et on met en place des règles NETMAP sur
> la passerelle de chaque réseau pour faire en sorte que :
> - quand un paquet est émis vers le tunnel, son adresse source est mappée
> en son adresse externe correspondant au réseau ;
> - quant un paquet est reçu par le tunnel à destination d'une adresse
> externe, son adresse est mappée en l'adresse interne correspondante.
>
> Evidemment, ça ne marche qu'avec les protocoles supportés par le NAT.
>
> >> J'ai découvert que je pouvais utiliser l'option client-to-client
> d'OpenVPN
> >> pour permettre la communication directe entre deux clients OpenVPN.
> >> J'ai lu en [1], que cette communication s'opérait à "l'insu de la
> >> configuration réseau du serveur OpenVPN" : les flux passaient
> directement
> >> d'un client OpenVPN à un autre sans que je puisse, avec le firewall du
> >> serveur OpenVPN définir des régles très précises comme celle de
> n'autoriser
> >> que la communication depuis ou vers un ou deux clients OpenVPN.
>
> Qu'est-ce que [1] ?
>
>

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-23 Par sujet Pascal Hambourg 

Le 23/01/2019 à 14:39, Olivier Bitsch a écrit :


1. Oui tu as bien compris, client-to-client ne transite pas le paquet par
le serveur. Du coup pas de filtrage possible si c'est option est activée.


Si j'ai bien compris, plus précisément les paquets envoyés à l'intérieur 
du tunnel entre deux clients ne transitent pas par l'interface tun/tap 
ni la pile réseau de la machine qui fait tourner le serveur openvpn, 
mais les paquets transportant le tunnel passent quand même par le 
serveur openvpn.



2. Si tous les réseaux connectés sont sur le même réseau (192.168.1.0/24),
je ne vois pas comment il sera possible de router les paquets d'un réseau
comme il faut. Donc je ne vois pas comment ça peut marcher.


Il y a une bidouille possible à base de double NAT source+destination.
Pour chaque réseau utilisant l'adressage 192.168.1.0/24 en interne, on 
définit un réseau externe unique, on configure le routage des réseaux 
externes sur le serveur openvpn et on met en place des règles NETMAP sur 
la passerelle de chaque réseau pour faire en sorte que :
- quand un paquet est émis vers le tunnel, son adresse source est mappée 
en son adresse externe correspondant au réseau ;
- quant un paquet est reçu par le tunnel à destination d'une adresse 
externe, son adresse est mappée en l'adresse interne correspondante.


Evidemment, ça ne marche qu'avec les protocoles supportés par le NAT.


J'ai découvert que je pouvais utiliser l'option client-to-client d'OpenVPN
pour permettre la communication directe entre deux clients OpenVPN.
J'ai lu en [1], que cette communication s'opérait à "l'insu de la
configuration réseau du serveur OpenVPN" : les flux passaient directement
d'un client OpenVPN à un autre sans que je puisse, avec le firewall du
serveur OpenVPN définir des régles très précises comme celle de n'autoriser
que la communication depuis ou vers un ou deux clients OpenVPN.


Qu'est-ce que [1] ?

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-23 Par sujet Baptiste Chappe 
Hello,

Première intervention sur la ML :)

Je remote avec un VPS OVH 600 sites distants via du OpenVPN et du Mikrotik
sur site. Des sites en chine (pas HK) via des protocoles exotiques pour ne
pas être filtrer (voir stunnel).
Les réseaux clients ne doivent pas avoir de même subnet.
C'est un peu compliqué au départ mais en étant rigoureux, je fais du 1
touch provisionning  sur mes clients OpenVPN

Un exemple de configuration de ma "tete" vpn vers un client Mikro en Europe.

port 443
proto tcp
dev tun


ca /etc/openvpn/CL001-XXX/ca.crt
cert /etc/openvpn/CL001-XXX/server.crt
key /etc/openvpn/CL001-XXX/server.key
dh /etc/openvpn/CL001-XXX/dh2048.pem

# IP DU SERVEUR
server 172.30.1.0 255.255.255.0

client-config-dir /etc/openvpn/CL001-XXX/CSO
ccd-exclusive

# LE SERVEUR APPRENDS LES ROUTES - TAPER ROUTE

route 192.168.1.0 255.255.255.0
route 192.168.68.0 255.255.255.0
route 192.168.5.0 255.255.255.0

keepalive 10 120
cipher aes256
auth sha1

log-append /var/log/openvpn.log
status /var/log/openvpn-status.log
verb 4
mute 20

Un exemple de configuration de ma "tete" vpn vers un client Mikro

### CSO ##

#ifconfig-push 172.30.1.2 172.30.1.1
push "route 172.30.2.0 255.255.255.0"
push "route 172.30.99.0 255.255.255.0"
#push "route 192.168.5.0 255.255.255.0"
iroute 192.168.1.0 255.255.255.0

Une trace depuis un autre VPS

root@ > traceroute 192.168.1.251
traceroute to 192.168.1.251 (192.168.1.251), 30 hops max, 60 byte packets
 1  VPN-OVH-MONITORING (172.30.2.1)  11.316 ms  22.360 ms  22.343 ms
 2  MF-MONITORING (192.168.1.251)  33.140 ms  44.087 ms  44.108 ms
root@ ~ >

Bon courage,

Baptiste Chappe



Le mer. 23 janv. 2019 à 14:39, Olivier Bitsch  a
écrit :

> Bonjour Olivier,
>
> 1. Oui tu as bien compris, client-to-client ne transite pas le paquet par
> le serveur. Du coup pas de filtrage possible si c'est option est activée.
>
> 2. Si tous les réseaux connectés sont sur le même réseau (192.168.1.0/24),
> je ne vois pas comment il sera possible de router les paquets d'un réseau
> comme il faut. Donc je ne vois pas comment ça peut marcher.
>
> 3. Pour les étapes B et C, et sous réserve que chaque réseau aient leur
> propre adressage, il faut utiliser la topologie subnet avec OpenVPN. Je
> peux te donner des exemples si tu en as besoin.
>
> obitwo
>
> Le mar. 22 janv. 2019 à 16:48, Olivier  a écrit :
>
>> Bonjour,
>>
>> J'ai plusieurs réseaux locaux distants dont le routeur est un serveur
>> Debian sur lequel un client OpenVPN  est installé.
>>
>> Je souhaite pouvoir depuis mon propre PC sur lequel est aussi installé un
>> client OpenVPN, atteindre les machines connectées des différents réseaux
>> locaux distants qui par ailleurs, sont à peu près tous configurés de la
>> même façon (tous en 192.168.1.0/24, par exemple).
>>
>> Pour fixer les choses, j'envisage d'opérer de la façon suivante:
>> +  sur mon PC:
>> A. je lance mon client OpenVPN
>> B. j'adapte ma configuration réseau en indiquant comment atteindre les
>> machines d'un réseau distant
>> + sur mon serveur OpenVPN
>> C. j'adapte ma configuration réseau
>> + sur un routeur Debian distant particulier:
>> D. j'adapte la configuration réseau afin que les machines du réseau local
>> puissent communiquer avec mon PC (par chance, le routeur Debian est déjà la
>> passerelle par défaut de ces machines).
>>
>> Le serveur OpenVPN est une machine sur le cloud.
>> J'ai découvert que je pouvais utiliser l'option client-to-client
>> d'OpenVPN pour permettre la communication directe entre deux clients
>> OpenVPN.
>> J'ai lu en [1], que cette communication s'opérait à "l'insu de la
>> configuration réseau du serveur OpenVPN" : les flux passaient directement
>> d'un client OpenVPN à un autre sans que je puisse, avec le firewall du
>> serveur OpenVPN définir des régles très précises comme celle de n'autoriser
>> que la communication depuis ou vers un ou deux clients OpenVPN.
>>
>> Mes questions:
>> 1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?
>>
>> 2. J'imaginais configurer l'étape D si dessus par un simple NAT avec
>> iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):
>> iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
>> Qu'en pensez-vous ?
>>
>> 3. Que faire pour les étapes B et C ?
>> J'ai essayé sans trop de succès différentes commande "ip route add" sans
>> succès pour l'instant.
>>
>> Slts
>>
>>
>>
>>
>>
>>
>>

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-23 Par sujet Olivier 
Le mer. 23 janv. 2019 à 14:39, Olivier Bitsch  a
écrit :

> Bonjour Olivier,
>
> 1. Oui tu as bien compris, client-to-client ne transite pas le paquet par
> le serveur. Du coup pas de filtrage possible si c'est option est activée.
>
> 2. Si tous les réseaux connectés sont sur le même réseau (192.168.1.0/24),
> je ne vois pas comment il sera possible de router les paquets d'un réseau
> comme il faut. Donc je ne vois pas comment ça peut marcher.
>

Je viens d'y passer la matinée mais sans succès malheureusement.

En mode client-to-client, les clients peuvent facilement se parler mais
c'est tout:
une commande "ip route add 192.168.1.0/24 via 10.8.1.40"  est refusée même
si je peux atteindre (via openvpn) l'adresse 10.8.1.40.

J'ai l'impression qu'il faut jouer avec des paramètres OpenVPN  comme route
(côte client OpenVPN) et/ou iroute (côte serveur OpenVPN) mais je n'ai pas
encore essayé.

>
> 3. Pour les étapes B et C, et sous réserve que chaque réseau aient leur
> propre adressage, il faut utiliser la topologie subnet avec OpenVPN. Je
> peux te donner des exemples si tu en as besoin.
>
> obitwo
>
> Le mar. 22 janv. 2019 à 16:48, Olivier  a écrit :
>
>> Bonjour,
>>
>> J'ai plusieurs réseaux locaux distants dont le routeur est un serveur
>> Debian sur lequel un client OpenVPN  est installé.
>>
>> Je souhaite pouvoir depuis mon propre PC sur lequel est aussi installé un
>> client OpenVPN, atteindre les machines connectées des différents réseaux
>> locaux distants qui par ailleurs, sont à peu près tous configurés de la
>> même façon (tous en 192.168.1.0/24, par exemple).
>>
>> Pour fixer les choses, j'envisage d'opérer de la façon suivante:
>> +  sur mon PC:
>> A. je lance mon client OpenVPN
>> B. j'adapte ma configuration réseau en indiquant comment atteindre les
>> machines d'un réseau distant
>> + sur mon serveur OpenVPN
>> C. j'adapte ma configuration réseau
>> + sur un routeur Debian distant particulier:
>> D. j'adapte la configuration réseau afin que les machines du réseau local
>> puissent communiquer avec mon PC (par chance, le routeur Debian est déjà la
>> passerelle par défaut de ces machines).
>>
>> Le serveur OpenVPN est une machine sur le cloud.
>> J'ai découvert que je pouvais utiliser l'option client-to-client
>> d'OpenVPN pour permettre la communication directe entre deux clients
>> OpenVPN.
>> J'ai lu en [1], que cette communication s'opérait à "l'insu de la
>> configuration réseau du serveur OpenVPN" : les flux passaient directement
>> d'un client OpenVPN à un autre sans que je puisse, avec le firewall du
>> serveur OpenVPN définir des régles très précises comme celle de n'autoriser
>> que la communication depuis ou vers un ou deux clients OpenVPN.
>>
>> Mes questions:
>> 1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?
>>
>> 2. J'imaginais configurer l'étape D si dessus par un simple NAT avec
>> iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):
>> iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
>> Qu'en pensez-vous ?
>>
>> 3. Que faire pour les étapes B et C ?
>> J'ai essayé sans trop de succès différentes commande "ip route add" sans
>> succès pour l'instant.
>>
>> Slts
>>
>>
>>
>>
>>
>>
>>

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-23 Par sujet Olivier Bitsch 
Bonjour Olivier,

1. Oui tu as bien compris, client-to-client ne transite pas le paquet par
le serveur. Du coup pas de filtrage possible si c'est option est activée.

2. Si tous les réseaux connectés sont sur le même réseau (192.168.1.0/24),
je ne vois pas comment il sera possible de router les paquets d'un réseau
comme il faut. Donc je ne vois pas comment ça peut marcher.

3. Pour les étapes B et C, et sous réserve que chaque réseau aient leur
propre adressage, il faut utiliser la topologie subnet avec OpenVPN. Je
peux te donner des exemples si tu en as besoin.

obitwo

Le mar. 22 janv. 2019 à 16:48, Olivier  a écrit :

> Bonjour,
>
> J'ai plusieurs réseaux locaux distants dont le routeur est un serveur
> Debian sur lequel un client OpenVPN  est installé.
>
> Je souhaite pouvoir depuis mon propre PC sur lequel est aussi installé un
> client OpenVPN, atteindre les machines connectées des différents réseaux
> locaux distants qui par ailleurs, sont à peu près tous configurés de la
> même façon (tous en 192.168.1.0/24, par exemple).
>
> Pour fixer les choses, j'envisage d'opérer de la façon suivante:
> +  sur mon PC:
> A. je lance mon client OpenVPN
> B. j'adapte ma configuration réseau en indiquant comment atteindre les
> machines d'un réseau distant
> + sur mon serveur OpenVPN
> C. j'adapte ma configuration réseau
> + sur un routeur Debian distant particulier:
> D. j'adapte la configuration réseau afin que les machines du réseau local
> puissent communiquer avec mon PC (par chance, le routeur Debian est déjà la
> passerelle par défaut de ces machines).
>
> Le serveur OpenVPN est une machine sur le cloud.
> J'ai découvert que je pouvais utiliser l'option client-to-client d'OpenVPN
> pour permettre la communication directe entre deux clients OpenVPN.
> J'ai lu en [1], que cette communication s'opérait à "l'insu de la
> configuration réseau du serveur OpenVPN" : les flux passaient directement
> d'un client OpenVPN à un autre sans que je puisse, avec le firewall du
> serveur OpenVPN définir des régles très précises comme celle de n'autoriser
> que la communication depuis ou vers un ou deux clients OpenVPN.
>
> Mes questions:
> 1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?
>
> 2. J'imaginais configurer l'étape D si dessus par un simple NAT avec
> iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):
> iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
> Qu'en pensez-vous ?
>
> 3. Que faire pour les étapes B et C ?
> J'ai essayé sans trop de succès différentes commande "ip route add" sans
> succès pour l'instant.
>
> Slts
>
>
>
>
>
>
>

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-22 Par sujet Daniel Huhardeaux 

Le 22/01/2019 à 19:18, Olivier a écrit :



Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux > a écrit :


Le 22/01/2019 à 16:48, Olivier a écrit :
 > Bonjour,

Bonjour



1. les machines des réseaux de l'entreprise: un serveur OpenVPN en mode
tun, tous les serveurs des sites clients s'y connectent, je peux
joindre
n'importe quel machine sur ces autres réseaux, aucun n'a le même plan
d'adresses IP.

Comment le "routage" entre le réseau distant et les clients du VPN ?


Le serveur OpenVPN sait comment joindre chaque IP puisque chaque client 
pousse sa route. Pour que cela fonctionne aussi avec les machines 
Windows un masquerade fait son job. J'ai créé un script (cde up de la 
config openvpn) qui fait le travail lorsque le VPN est monté, script 
installé sur chaque client OpenVPN d'un site.


--
Daniel

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-22 Par sujet Daniel Huhardeaux 

Le 22/01/2019 à 19:16, Olivier a écrit :

Merci Daniel pour ta réponse.

J'aurai pu le préciser mais j'arrive à me connecter ponctuellement aux 
équipements distants via des commandes SSH du type ssh -f -N foo@remote 
-L1234:192.168.151:80 mais c'est assez fastidieux car je dois désigner 
les ports distants, choisir des ports disponibles sur ma machine, 
ajouter un éventuel rebond.


Je recherche maintenant à re-configurer le réseau afin d'avoir une 
re-configuration ponctuelle plus générique


Justement, en centralisant les connexions sur un serveur, VPN et/ou ssh, 
tu ne reconfigures plus le réseau: le fichier ~/.ssh/config contiendra 
les commandes nécessaires afin de ne faire qu'un simple "ssh "


Je trouve d'ailleurs dommage que mosh ne gère pas le fichier config de ssh.



Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux > a écrit :


Le 22/01/2019 à 16:48, Olivier a écrit :
 > Bonjour,

Bonjour

 >
 > J'ai plusieurs réseaux locaux distants dont le routeur est un
serveur
 > Debian sur lequel un client OpenVPN  est installé.
 >
 > Je souhaite pouvoir depuis mon propre PC sur lequel est aussi
installé
 > un client OpenVPN, atteindre les machines connectées des différents
 > réseaux locaux distants qui par ailleurs, sont à peu près tous
 > configurés de la même façon (tous en 192.168.1.0/24

 > , par exemple).
 >
 > Pour fixer les choses, j'envisage d'opérer de la façon suivante:
 > +  sur mon PC:
 > A. je lance mon client OpenVPN
 > B. j'adapte ma configuration réseau en indiquant comment
atteindre les
 > machines d'un réseau distant
 > + sur mon serveur OpenVPN
 > C. j'adapte ma configuration réseau
 > + sur un routeur Debian distant particulier:
 > D. j'adapte la configuration réseau afin que les machines du réseau
 > local puissent communiquer avec mon PC (par chance, le routeur
Debian
 > est déjà la passerelle par défaut de ces machines).
 >
 > Le serveur OpenVPN est une machine sur le cloud.
 > J'ai découvert que je pouvais utiliser l'option client-to-client
 > d'OpenVPN pour permettre la communication directe entre deux clients
 > OpenVPN.
 > J'ai lu en [1], que cette communication s'opérait à "l'insu de la
 > configuration réseau du serveur OpenVPN" : les flux passaient
 > directement d'un client OpenVPN à un autre sans que je puisse,
avec le
 > firewall du serveur OpenVPN définir des régles très précises
comme celle
 > de n'autoriser que la communication depuis ou vers un ou deux
clients
 > OpenVPN.
 >
 > Mes questions:
 > 1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?
 >
 > 2. J'imaginais configurer l'étape D si dessus par un simple NAT avec
 > iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):
 > iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
 > Qu'en pensez-vous ?
 >
 > 3. Que faire pour les étapes B et C ?
 > J'ai essayé sans trop de succès différentes commande "ip route
add" sans
 > succès pour l'instant.

Perso j'utilise 2 types d'organisations:

1. les machines des réseaux de l'entreprise: un serveur OpenVPN en mode
tun, tous les serveurs des sites clients s'y connectent, je peux
joindre
n'importe quel machine sur ces autres réseaux, aucun n'a le même plan
d'adresses IP.

L'inconvénient pour toi est que justement tous les réseaux auxquels tu
veux te joindre ont le même plan d'adressage IP

2. les réseaux des clients: j'utilise un serveur OpenVPN mode tun en DC
auquel les serveurs clients se connectent soit via OpenVPN soit en ssh
avec autossh (reverse ssh).

Dans les 2 cas, à partir de mon portable je peux joindre n'importe quel
machine derrière les réseaux clients en utilisant les commandes ssh
(pour le cas 2 essentiellement ProxyCommand pour tous les clients,
Hostname en plus pour ceux en VPN)

-- 
Daniel

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-22 Par sujet Olivier 
Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux  a
écrit :

> Le 22/01/2019 à 16:48, Olivier a écrit :
> > Bonjour,
>
> Bonjour
>
>
>
> 1. les machines des réseaux de l'entreprise: un serveur OpenVPN en mode
> tun, tous les serveurs des sites clients s'y connectent, je peux joindre
> n'importe quel machine sur ces autres réseaux, aucun n'a le même plan
> d'adresses IP.
>
> Comment le "routage" entre le réseau distant et les clients du VPN ?

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-22 Par sujet Olivier 
Merci Daniel pour ta réponse.

J'aurai pu le préciser mais j'arrive à me connecter ponctuellement aux
équipements distants via des commandes SSH du type ssh -f -N foo@remote
-L1234:192.168.151:80 mais c'est assez fastidieux car je dois désigner les
ports distants, choisir des ports disponibles sur ma machine, ajouter un
éventuel rebond.

Je recherche maintenant à re-configurer le réseau afin d'avoir une
re-configuration ponctuelle plus générique

Le mar. 22 janv. 2019 à 17:31, Daniel Huhardeaux  a
écrit :

> Le 22/01/2019 à 16:48, Olivier a écrit :
> > Bonjour,
>
> Bonjour
>
> >
> > J'ai plusieurs réseaux locaux distants dont le routeur est un serveur
> > Debian sur lequel un client OpenVPN  est installé.
> >
> > Je souhaite pouvoir depuis mon propre PC sur lequel est aussi installé
> > un client OpenVPN, atteindre les machines connectées des différents
> > réseaux locaux distants qui par ailleurs, sont à peu près tous
> > configurés de la même façon (tous en 192.168.1.0/24
> > , par exemple).
> >
> > Pour fixer les choses, j'envisage d'opérer de la façon suivante:
> > +  sur mon PC:
> > A. je lance mon client OpenVPN
> > B. j'adapte ma configuration réseau en indiquant comment atteindre les
> > machines d'un réseau distant
> > + sur mon serveur OpenVPN
> > C. j'adapte ma configuration réseau
> > + sur un routeur Debian distant particulier:
> > D. j'adapte la configuration réseau afin que les machines du réseau
> > local puissent communiquer avec mon PC (par chance, le routeur Debian
> > est déjà la passerelle par défaut de ces machines).
> >
> > Le serveur OpenVPN est une machine sur le cloud.
> > J'ai découvert que je pouvais utiliser l'option client-to-client
> > d'OpenVPN pour permettre la communication directe entre deux clients
> > OpenVPN.
> > J'ai lu en [1], que cette communication s'opérait à "l'insu de la
> > configuration réseau du serveur OpenVPN" : les flux passaient
> > directement d'un client OpenVPN à un autre sans que je puisse, avec le
> > firewall du serveur OpenVPN définir des régles très précises comme celle
> > de n'autoriser que la communication depuis ou vers un ou deux clients
> > OpenVPN.
> >
> > Mes questions:
> > 1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?
> >
> > 2. J'imaginais configurer l'étape D si dessus par un simple NAT avec
> > iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):
> > iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
> > Qu'en pensez-vous ?
> >
> > 3. Que faire pour les étapes B et C ?
> > J'ai essayé sans trop de succès différentes commande "ip route add" sans
> > succès pour l'instant.
>
> Perso j'utilise 2 types d'organisations:
>
> 1. les machines des réseaux de l'entreprise: un serveur OpenVPN en mode
> tun, tous les serveurs des sites clients s'y connectent, je peux joindre
> n'importe quel machine sur ces autres réseaux, aucun n'a le même plan
> d'adresses IP.
>
> L'inconvénient pour toi est que justement tous les réseaux auxquels tu
> veux te joindre ont le même plan d'adressage IP
>
> 2. les réseaux des clients: j'utilise un serveur OpenVPN mode tun en DC
> auquel les serveurs clients se connectent soit via OpenVPN soit en ssh
> avec autossh (reverse ssh).
>
> Dans les 2 cas, à partir de mon portable je peux joindre n'importe quel
> machine derrière les réseaux clients en utilisant les commandes ssh
> (pour le cas 2 essentiellement ProxyCommand pour tous les clients,
> Hostname en plus pour ceux en VPN)
>
> --
> Daniel
>
>

Re: Conseils sur le routage de client à client avec OpenVPN

2019-01-22 Par sujet Daniel Huhardeaux 

Le 22/01/2019 à 16:48, Olivier a écrit :

Bonjour,


Bonjour



J'ai plusieurs réseaux locaux distants dont le routeur est un serveur 
Debian sur lequel un client OpenVPN  est installé.


Je souhaite pouvoir depuis mon propre PC sur lequel est aussi installé 
un client OpenVPN, atteindre les machines connectées des différents 
réseaux locaux distants qui par ailleurs, sont à peu près tous 
configurés de la même façon (tous en 192.168.1.0/24 
, par exemple).


Pour fixer les choses, j'envisage d'opérer de la façon suivante:
+  sur mon PC:
A. je lance mon client OpenVPN
B. j'adapte ma configuration réseau en indiquant comment atteindre les 
machines d'un réseau distant

+ sur mon serveur OpenVPN
C. j'adapte ma configuration réseau
+ sur un routeur Debian distant particulier:
D. j'adapte la configuration réseau afin que les machines du réseau 
local puissent communiquer avec mon PC (par chance, le routeur Debian 
est déjà la passerelle par défaut de ces machines).


Le serveur OpenVPN est une machine sur le cloud.
J'ai découvert que je pouvais utiliser l'option client-to-client 
d'OpenVPN pour permettre la communication directe entre deux clients 
OpenVPN.
J'ai lu en [1], que cette communication s'opérait à "l'insu de la 
configuration réseau du serveur OpenVPN" : les flux passaient 
directement d'un client OpenVPN à un autre sans que je puisse, avec le 
firewall du serveur OpenVPN définir des régles très précises comme celle 
de n'autoriser que la communication depuis ou vers un ou deux clients 
OpenVPN.


Mes questions:
1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?

2. J'imaginais configurer l'étape D si dessus par un simple NAT avec 
iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):

iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
Qu'en pensez-vous ?

3. Que faire pour les étapes B et C ?
J'ai essayé sans trop de succès différentes commande "ip route add" sans 
succès pour l'instant.


Perso j'utilise 2 types d'organisations:

1. les machines des réseaux de l'entreprise: un serveur OpenVPN en mode 
tun, tous les serveurs des sites clients s'y connectent, je peux joindre 
n'importe quel machine sur ces autres réseaux, aucun n'a le même plan 
d'adresses IP.


L'inconvénient pour toi est que justement tous les réseaux auxquels tu 
veux te joindre ont le même plan d'adressage IP


2. les réseaux des clients: j'utilise un serveur OpenVPN mode tun en DC 
auquel les serveurs clients se connectent soit via OpenVPN soit en ssh 
avec autossh (reverse ssh).


Dans les 2 cas, à partir de mon portable je peux joindre n'importe quel 
machine derrière les réseaux clients en utilisant les commandes ssh 
(pour le cas 2 essentiellement ProxyCommand pour tous les clients, 
Hostname en plus pour ceux en VPN)


--
Daniel

Conseils sur le routage de client à client avec OpenVPN

2019-01-22 Par sujet Olivier 
Bonjour,

J'ai plusieurs réseaux locaux distants dont le routeur est un serveur
Debian sur lequel un client OpenVPN  est installé.

Je souhaite pouvoir depuis mon propre PC sur lequel est aussi installé un
client OpenVPN, atteindre les machines connectées des différents réseaux
locaux distants qui par ailleurs, sont à peu près tous configurés de la
même façon (tous en 192.168.1.0/24, par exemple).

Pour fixer les choses, j'envisage d'opérer de la façon suivante:
+  sur mon PC:
A. je lance mon client OpenVPN
B. j'adapte ma configuration réseau en indiquant comment atteindre les
machines d'un réseau distant
+ sur mon serveur OpenVPN
C. j'adapte ma configuration réseau
+ sur un routeur Debian distant particulier:
D. j'adapte la configuration réseau afin que les machines du réseau local
puissent communiquer avec mon PC (par chance, le routeur Debian est déjà la
passerelle par défaut de ces machines).

Le serveur OpenVPN est une machine sur le cloud.
J'ai découvert que je pouvais utiliser l'option client-to-client d'OpenVPN
pour permettre la communication directe entre deux clients OpenVPN.
J'ai lu en [1], que cette communication s'opérait à "l'insu de la
configuration réseau du serveur OpenVPN" : les flux passaient directement
d'un client OpenVPN à un autre sans que je puisse, avec le firewall du
serveur OpenVPN définir des régles très précises comme celle de n'autoriser
que la communication depuis ou vers un ou deux clients OpenVPN.

Mes questions:
1. Ai-je bien compris [1] et [1] est-il bien toujours valable ?

2. J'imaginais configurer l'étape D si dessus par un simple NAT avec
iptables du type (10.8.1.70 est l'IP dans le VPN du routeur Debian):
iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to-source 10.8.1.70
Qu'en pensez-vous ?

3. Que faire pour les étapes B et C ?
J'ai essayé sans trop de succès différentes commande "ip route add" sans
succès pour l'instant.

Slts

Re: [HS] Conseils sur le choix d'un point d'accès WiFi

2018-09-28 Par sujet Bernard Schoenacker 


- Mail original - 

> De: "Olivier" 
> À: "ML Debian User French" 
> Envoyé: Vendredi 28 Septembre 2018 10:53:17
> Objet: [HS] Conseils sur le choix d'un point d'accès WiFi

> Bonjour,

> Pour servir de passerelle WiFi à des appareils ne pouvant se
> connecter en WPA2 Entreprise (consoles, TV) , je recherche un
> appareil aux caractéristiques ci-après.

> Certaines caractéristiques sont simplement souhaitées. Les autres
> sont requises.

> Général:
> - Pas trop cher (<50 E.HT )
> - Disponible à la vente en France

> Matériel:
> - 802.11ac double bande
> - 1 ou 4 ports Ethernet or Gigabit
> - si possible, alimentable en 5V (USB, microUSB ou non)
> - bouton reset
> - si possible, pas de port USB (pour la sécurité)

> - assez performant pour le jeu en réseau

> - si possible, bouton programmable avec LED pour qu'un même appareil
> puisse servir plusieurs modes de fonctionnement

> Logiciel:

> - si possible openwrt

> - sinon facile à configurer

> Avez-vous un appareil qui vous vient à l'esprit ?
> Slts

bonjour,

désolé mais c'est un GAFAM :

https://www.amazon.fr/TP-Link-Routeur-Wi-FI-Gigabit-Bi-Bande/dp/B071RSD473/ref=sr_1_6?ie=UTF8=1538125692=8-6=routeur+wifi

https://www.amazon.fr/TP-Link-Routeur-Wi-Fi-Ethernet-TL-WR841N/dp/B001FWYGJS/ref=sr_1_4?ie=UTF8=1538125692=8-4=routeur+wifi


merci
slt
bernard

[HS] Conseils sur le choix d'un point d'accès WiFi

2018-09-28 Par sujet Olivier 
Bonjour,

Pour servir de passerelle WiFi à des appareils ne pouvant se connecter en
WPA2 Entreprise (consoles, TV) , je recherche un appareil aux
caractéristiques ci-après.

Certaines caractéristiques sont simplement souhaitées. Les autres sont
requises.

Général:
- Pas trop cher (<50 E.HT)
- Disponible à la vente en France

Matériel:
- 802.11ac double bande
- 1 ou 4 ports Ethernet or Gigabit
- si possible, alimentable en 5V (USB, microUSB ou non)
- bouton reset
- si possible, pas de port USB (pour la sécurité)
- assez performant pour le jeu en réseau
- si possible, bouton programmable avec LED pour qu'un même appareil puisse
servir plusieurs modes de fonctionnement

Logiciel:
- si possible openwrt
- sinon facile à configurer

 Avez-vous un appareil qui vous vient à l'esprit ?

Slts

Re: Conseils sur l'utilisation des mémoires eMMC, SDHC ou flash sur des serveurs télé-administrés

2018-06-21 Par sujet Belaïd 
Bonjour,

Pour la question 4, je pense qu'il faudrait plus ce penché sur la
configuration du bootloader et non du Bios. Pour Grub je ne sais pas trop,
 mais je sais que par exemple dans l'embarqué avec uBoot on peut faire le
test sur la présence ou non d'un périphérique  et booté dessus.  J'imagine
que Grub aussi devrait avoir la même chose ...

Le jeu. 21 juin 2018 13:08, Olivier  a écrit :

> Bonjour,
>
> Depuis plusieurs années maintenant, il existe des machines de tout format
> (NUC, tower, ...) dotées de mémoire eMMC, d'interfaces USB3 et d'interface
> pour carte mémoire.
>
> Qui utilise ces mémoires dans machines sans écran, fournissant des
> services réseau (sécurité, réseau, ToIP, ...) sur des sites distants et
> souhaiterai partager ici son expérience ?
>
> J'imagine des utilisations avancées comme:
>
> 1. J'installe un OS de base sur la carte eMMC, et un autre sur une clé
> USB3 (de petit format). Je boote prioritairement sur la clé USB3 puis la
> carte eMMC. En cas de problème, ou pour changer sans risque de version de
> Debian, je change de clé USB. En la retirant, je peux faire des diagnostics.
>
> 2. Idem que précédemment mais avec une carte mémoire plutôt qu'un clé USB3.
>
> Aussitôt, pas mal de questions me viennent à l'esprit:
>
> 1. Quelles sont les mémoires les plus durables ?
> 2. Comment se comparent les performances ?
> 3. Comment vieillit une mémoire eMMC ? Et logiquement, comment se comporte
> son OS installé en 2018 et qu'on ré-utilise 4 ans plus tard ?
> 4. Peut-on réellement implémenter des règles comme "je boote
> prioritairement sur la clé USB3 puis la carte eMMC" y compris quand on
> change de clé USB3 (j'ai la vague impression que les BIOS étaient
> surprenant à cet égard et avec ce type de machine pas d'accès possible au
> BIOS) ?
> 5. Conseils ? Suggestions ?
>
>
> Slts
>
>
>
>
>
>
>
>

Conseils sur l'utilisation des mémoires eMMC, SDHC ou flash sur des serveurs télé-administrés

2018-06-21 Par sujet Olivier 
Bonjour,

Depuis plusieurs années maintenant, il existe des machines de tout format
(NUC, tower, ...) dotées de mémoire eMMC, d'interfaces USB3 et d'interface
pour carte mémoire.

Qui utilise ces mémoires dans machines sans écran, fournissant des services
réseau (sécurité, réseau, ToIP, ...) sur des sites distants et souhaiterai
partager ici son expérience ?

J'imagine des utilisations avancées comme:

1. J'installe un OS de base sur la carte eMMC, et un autre sur une clé USB3
(de petit format). Je boote prioritairement sur la clé USB3 puis la carte
eMMC. En cas de problème, ou pour changer sans risque de version de Debian,
je change de clé USB. En la retirant, je peux faire des diagnostics.

2. Idem que précédemment mais avec une carte mémoire plutôt qu'un clé USB3.

Aussitôt, pas mal de questions me viennent à l'esprit:

1. Quelles sont les mémoires les plus durables ?
2. Comment se comparent les performances ?
3. Comment vieillit une mémoire eMMC ? Et logiquement, comment se comporte
son OS installé en 2018 et qu'on ré-utilise 4 ans plus tard ?
4. Peut-on réellement implémenter des règles comme "je boote
prioritairement sur la clé USB3 puis la carte eMMC" y compris quand on
change de clé USB3 (j'ai la vague impression que les BIOS étaient
surprenant à cet égard et avec ce type de machine pas d'accès possible au
BIOS) ?
5. Conseils ? Suggestions ?


Slts

Re: [HS] Choix registrar, conseils

2017-12-05 Par sujet andre_debian 
On Tuesday 05 December 2017 07:25:07 Eric Degenetais wrote:
> D'une manière générale derrière un service qui répond vite et un plan de
> continuité béton, il y a du monde au travail. À moins de cautionner
> l'esclavage on peut difficilement se plaindre des faiblesses du low cost.

Si low-cost = personnel exploité,
là c'est bien ennuyeux, mais j'ai l'impression que même
dans le high-cost on exploite aussi le personnel.

André

Re: [HS] Choix registrar, conseils

2017-12-04 Par sujet Eric Degenetais 
Le 4 déc. 2017 15:39,  a écrit :

> andre_deb...@numericable.fr wrote
> J'ai un serveur chez OVH-Kimsufi, pour mes sauvegardes.
> - Hotline très difficile à contacter (des heures),
> - Augmentation des factures abonnement,
> - Réponses biaisantes sur tickets d'incidents,
> - Un jour, effacement complet de tout le disque dur,
>   j'ai dû tout réinstaller suite erreur d'OVH,
>   obligé donc de faire aussi sauvegardes sur mon propre ordinateur,
>   alors que j'ai un serveur pour ça...
> - Serveur non fiable = inutile !

On Monday 04 December 2017 12:55:51 Yann Serre wrote:
> C'est simple et clair.
> Vous choisissez du low cost, vous avez un service low cost ou très
> automatisé (qui parfois est très rapide et performant quand on ne lui
> présente pas un mouton à 7 pattes).
> Si on part du principe que les impayés / relances / contentieux de 1%
> des clients plombent la rentabilité *, alors des grandes structures
> comme OVH font le choix de déplaire (un peu) en généralisant la mise en
> place d'un prélèvement CB ou banque. Dans leur situation vous prendriez
> la même décision ! :)
> (...ou vous feriez le choix d'être un hébergeur associatif à taille
> humaine dans votre région avec des solutions au cas par cas donc chères).
> * et que ces 1% qui ne sont pas réglos sont comme par hasard la plupart
> de ceux qui cherchent aussi à contourner les lois ou qui explosent les
> bandes passantes moyennes (sur lesquelles se basent les forfaits low
> cost pour être rentables)...

> kimsufi n'est clairement pas un service fiable, c'est du serveur pas
> cher en mode "débrouille toi", sans trop de garanties,
> mais c'est presque écrit dessus ;-).
> Ça n'a pas grand chose à voir avec les serveurs ovh
> (pas de garantie de BP ni de SAV, pas de
> raid, etc.), mais c'est pas le même prix, c'est d'ailleurs
> pour ça qu'ils ont mis une autre marque.

Qu'il y ait quelques soucis techniques avec le low-cost, soit...,
mais ce genre de pratiques :
- Hotline très difficile à contacter (des heures),
- Augmentation des factures abonnement sur motif pipeau,
- Réponses biaisantes sur tickets d'incidents...
- Effacement complet disque dur serveur dédié sans motif ni excuses,
- Pannes graves électrique sur 2 sites impactant tous les serveurs,
  même ceux à contrats plus chers.

En payant plus cher, aura t-on un meilleur service, càd pas ces
pratiques et pannes ci-dessus ?  À voir...

Free mobile à 2€ / mois, ça marche très bien.
SFR à 25€ / mois, que de soucis...

André

D'une manière générale derrière un service qui répond vite et un plan de
continuité béton, il y a du monde au travail. À moins de cautionner
l'esclavage on peut difficilement se plaindre des faiblesses du low cost.

Re: [HS] Choix registrar, conseils

2017-12-04 Par sujet andre_debian 
> andre_deb...@numericable.fr wrote
> J'ai un serveur chez OVH-Kimsufi, pour mes sauvegardes.
> - Hotline très difficile à contacter (des heures),
> - Augmentation des factures abonnement,
> - Réponses biaisantes sur tickets d'incidents,
> - Un jour, effacement complet de tout le disque dur,
>   j'ai dû tout réinstaller suite erreur d'OVH,
>   obligé donc de faire aussi sauvegardes sur mon propre ordinateur,
>   alors que j'ai un serveur pour ça...
> - Serveur non fiable = inutile !

On Monday 04 December 2017 12:55:51 Yann Serre wrote:
> C'est simple et clair.
> Vous choisissez du low cost, vous avez un service low cost ou très 
> automatisé (qui parfois est très rapide et performant quand on ne lui 
> présente pas un mouton à 7 pattes).
> Si on part du principe que les impayés / relances / contentieux de 1% 
> des clients plombent la rentabilité *, alors des grandes structures 
> comme OVH font le choix de déplaire (un peu) en généralisant la mise en 
> place d'un prélèvement CB ou banque. Dans leur situation vous prendriez 
> la même décision ! :)
> (...ou vous feriez le choix d'être un hébergeur associatif à taille 
> humaine dans votre région avec des solutions au cas par cas donc chères).
> * et que ces 1% qui ne sont pas réglos sont comme par hasard la plupart 
> de ceux qui cherchent aussi à contourner les lois ou qui explosent les 
> bandes passantes moyennes (sur lesquelles se basent les forfaits low 
> cost pour être rentables)...

> kimsufi n'est clairement pas un service fiable, c'est du serveur pas 
> cher en mode "débrouille toi", sans trop de garanties, 
> mais c'est presque écrit dessus ;-). 
> Ça n'a pas grand chose à voir avec les serveurs ovh 
> (pas de garantie de BP ni de SAV, pas de 
> raid, etc.), mais c'est pas le même prix, c'est d'ailleurs 
> pour ça qu'ils ont mis une autre marque.

Qu'il y ait quelques soucis techniques avec le low-cost, soit...,
mais ce genre de pratiques :
- Hotline très difficile à contacter (des heures),
- Augmentation des factures abonnement sur motif pipeau,
- Réponses biaisantes sur tickets d'incidents...
- Effacement complet disque dur serveur dédié sans motif ni excuses,
- Pannes graves électrique sur 2 sites impactant tous les serveurs,
  même ceux à contrats plus chers.

En payant plus cher, aura t-on un meilleur service, càd pas ces 
pratiques et pannes ci-dessus ?  À voir...

Free mobile à 2€ / mois, ça marche très bien.
SFR à 25€ / mois, que de soucis...

André

Re: [HS] Choix registrar, conseils : gaffe terrible !

2017-12-04 Par sujet Daniel Caillibaud 
Le 02/12/17 à 13:05, andre_deb...@numericable.fr a écrit :
AF> Voici ce qu'il fallait lire :
AF> J'ai un serveur chez OVH-Kimsufi, pour mes sauvegardes.
AF> - Hotline très difficile à contacter (des heures),
AF> - Augmentation des factures abonnement,
AF> - Réponses biaisantes sur tickets d'incidents,
AF> - Un jour, effacement complet de tout le disque dur,
AF>   j'ai dû tout réinstaller suite erreur d'OVH,
AF>   obligé donc de faire aussi sauvegardes sur mon propre ordinateur,
AF>   alors que j'ai un serveur pour ça...
AF> - Serveur non fiable = inutile !

kimsufi n'est clairement pas un service fiable, c'est du serveur pas cher en 
mode "débrouille
toi", sans trop de garanties, mais c'est presque écrit dessus ;-).

Ça n'a pas grand chose à voir avec les serveurs ovh (pas de garantie de BP ni 
de SAV, pas de
raid, etc.), mais c'est pas le même prix, c'est d'ailleurs pour ça qu'ils ont 
mis une autre
marque.

-- 
Daniel

Lorsque j'ai été kidnappé, ma mère a réagi tout de suite: elle a sous-loué ma 
chambre.
Woody Allen

Re: [HS] Choix registrar, conseils

2017-12-04 Par sujet Yann Serre 

Bonjour

C'est simple et clair.

Vous choisissez du low cost, vous avez un service low cost ou très 
automatisé (qui parfois est très rapide et performant quand on ne lui 
présente pas un mouton à 7 pattes).


Si on part du principe que les impayés / relances / contentieux de 1% 
des clients plombent la rentabilité *, alors des grandes structures 
comme OVH font le choix de déplaire (un peu) en généralisant la mise en 
place d'un prélèvement CB ou banque. Dans leur situation vous prendriez 
la même décision ! :)


(...ou vous feriez le choix d'être un hébergeur associatif à taille 
humaine dans votre région avec des solutions au cas par cas donc chères).


Bonne semaine

Yann

* et que ces 1% qui ne sont pas réglos sont comme par hasard la plupart 
de ceux qui cherchent aussi à contourner les lois ou qui explosent les 
bandes passantes moyennes (sur lesquelles se basent les forfaits low 
cost pour être rentables)...






Le 04/12/2017 à 11:15, BERTRAND Joel a écrit :
 Guère mieux que Gandi. Je me souviens avoir débarqué au siège 
social de Gandi pour taper du point sur la table pour un client. Il 
fallait simplement que quelqu'un se penche sur le problème.


 Bref, en dessous d'un certain prix, on n'en a que pour son argent.

 J'avoue ne pas les avoir tous testés, mais j'ai eu des déboires 
avec Gandi, OVH, 1and1, Ikoola (instabilités électriques, pertes de 
données, migrations impossibles, prérequis étranges sur des 
mutualisés...). Rien que cette année, OVH m'a planté trois fois des 
serveurs (IPBX + services divers). Pour l'instant, pas de problème avec 
Amen, Equinix ou Nérim (là, j'ai une baie vide louée où je colle mon 
matériel).


 Je n'ai jamais trouvé un vrai service en dessous de 50 ou 60 
€/mois. En dessous, ce sont des prix d'appel. Tout peut parfaitement 
bien se passer, mais en cas de problème, on n'a que ses yeux pour 
pleurer. De toute façon, il est possible de faire un calcul simple : 
coût mensuel du serveur et de la maintenance sur cinq ans plus 
électricité et accès internet, plus climatisation et techniciens de 
maintenance. Ça fait un coût incompressible pour un hébergeur sérieux.


 Bien cordialement,

 JKB

Re: [HS] Choix registrar, conseils

2017-12-04 Par sujet BERTRAND Joel 

andre_deb...@numericable.fr a écrit :

On Monday 04 December 2017 10:19:58 fab wrote:
...

Enfin, concernant OVH et c'est mon petit coup de gueule,
cette façon (très récente) d'obliger les clients à lier un compte ou une
carte bancaire à leurs services a fini de me convaincre que ce n'était
plus un hébergeur intérresant.


Je confirme,

OVH a besoin d'investir et cherche de l'argent chez le client.
- Politique d'inscription à la financière,
- Augmentation des factures sur motifs pipeau,
- Impossibilité d'avoir le type de contrat, CDD ou CDI, et réponses
   biaisantes,
- Panne grave (effacement données) sans la moindre excuse,
- Graves pannes électrique récentes sur 2 sites (Strasbourg et Roubaix)...


	Guère mieux que Gandi. Je me souviens avoir débarqué au siège social de 
Gandi pour taper du point sur la table pour un client. Il fallait 
simplement que quelqu'un se penche sur le problème.


Bref, en dessous d'un certain prix, on n'en a que pour son argent.

	J'avoue ne pas les avoir tous testés, mais j'ai eu des déboires avec 
Gandi, OVH, 1and1, Ikoola (instabilités électriques, pertes de données, 
migrations impossibles, prérequis étranges sur des mutualisés...). Rien 
que cette année, OVH m'a planté trois fois des serveurs (IPBX + services 
divers). Pour l'instant, pas de problème avec Amen, Equinix ou Nérim 
(là, j'ai une baie vide louée où je colle mon matériel).


	Je n'ai jamais trouvé un vrai service en dessous de 50 ou 60 €/mois. En 
dessous, ce sont des prix d'appel. Tout peut parfaitement bien se 
passer, mais en cas de problème, on n'a que ses yeux pour pleurer. De 
toute façon, il est possible de faire un calcul simple : coût mensuel du 
serveur et de la maintenance sur cinq ans plus électricité et accès 
internet, plus climatisation et techniciens de maintenance. Ça fait un 
coût incompressible pour un hébergeur sérieux.


Bien cordialement,

JKB

Re: [HS] Choix registrar, conseils

2017-12-04 Par sujet andre_debian 
On Monday 04 December 2017 10:19:58 fab wrote:
...
> Enfin, concernant OVH et c'est mon petit coup de gueule,  
> cette façon (très récente) d'obliger les clients à lier un compte ou une 
> carte bancaire à leurs services a fini de me convaincre que ce n'était 
> plus un hébergeur intérresant.

Je confirme,

OVH a besoin d'investir et cherche de l'argent chez le client.
- Politique d'inscription à la financière,
- Augmentation des factures sur motifs pipeau,
- Impossibilité d'avoir le type de contrat, CDD ou CDI, et réponses  
  biaisantes,
- Panne grave (effacement données) sans la moindre excuse,
- Graves pannes électrique récentes sur 2 sites (Strasbourg et Roubaix)...

André

Re: [HS] Choix registrar, conseils

2017-12-04 Par sujet fab 

'lut,


https://ouvaton.coop/ qui récemment fait aussi registrar en
collaboration avec gandi je crois, à vérifier...

Je confirme leur travail avec Gandi. Et puis l'idée de la coop, tout ça...
Par ailleurs, concernant l'aspect purement technique. Pour des sites 
identiques (wordpress sur mutu), j'ai pu observer des meilleures perf 
chez ouvaton. Enfin, concernant ovh et c'est mon petit coup de gueule, 
cette façon (très récente) d'obliger les clients à lier un compte ou une 
carte bancaire à leurs services a fini de me convaincre que ce n'était 
plus un hébergeur intérresant.


Belle journée,

f.




Bonne journée

--
Benoit

Le 30 novembre 2017 à 11:27, Pierre L. <pet...@miosweb.mooo.com> a écrit :

Bonjour,

Je viens à vous pour quelques conseils (avec ce fil totalement en dehors du
monde Debian je le conçois, mais je suis certain que beaucoup de
connaisseurs sont par ici à propos du sujet) dans une recherche de registrar
pour 1er achat de nom de domaine.

Il me semble intéressant qu'il soit doté d'une interface client assez
simple, french/english peu importe.
Le but est de s'amuser à tester/gérer l'hébergement de plusieurs petits
services (plus simple avec un domaine de 1er niveau que les sous-domaines
gratis) :
* serveur mails (donc il faut l'accès à l'enregistrement MX si je ne me
trompe pas),
* divers services HTTP(S)
Pour le coté sous-domaine, par exemple mail.mondomaine.fr et
blog.mondomaine.fr
ce sera moi ou le registrar qui va gérer cela ? (via mon serveur DNS je
pense ?)
Sinon rien de grave si on se trouve avec un mondomaine.fr/blog +
mondomaine.fr/cloud + mondomaine.fr/site1

Et si par exemple je déplace mon serveur sur une autre IP, il sera possible
de rediriger via l'interface du registrar sur la nouvelle IP je suppose ?
Autant de fois que je le désire...

Et le dernier point tarifaire, si possible pour quelques billes seulement :)
Le choix du .truc final n'est pas important, ce qui est apparemment la base
pour établir un prix.

Merci pour vos lumières, vos conseils de connaisseurs et d'utilisateurs de
ces registrars,
les points à rechercher / à éviter... bref que cette première rencontre se
passe pour le mieux :) (surtout si le mariage est signé pour 1an direct au
minimum!)

  1   2   3   4   5   6   7   >