NeoX a écrit 18201 commentaires

alors que le serveur ne swap pas ! J'ai pu constater que c'était le CPU qui limitait certaines (grosses) requêtes : ces dernières prenaient 2s avant "optimisation", elles prennent maintenant quasiment 1 minute.

Ce sont des serveurs dédiés. J'ai changé de serveur en fait,

donc tu as changé de hardware, de disque dur, de CPU…
le CPU precedent etait peut-etre plus veloce, ou ton disque dur plus rapide

quand tu fais un top
et que tu affiches le detail (shift+1) tu voit des %wai ?

j'ai pensé lui proposé, mais j'ai pas souvenir d'une gestion de stock, plutot une gestion de parc.

genre la machine XYZ est attribuée à telle personne.

mais pas que la machine XYZ est composé du clavier numero de serieA, de la carte mere B, de la carte graphique C, etc

Mon CPU c'est un INTEL, je peux quand même prendre AMD64?

oui, les processeurs INTEL et AMD sont de la meme famille (x86)
dispo en 32bits (i686) ou en 64bits (x86_64)

mais comme c'est AMD qui avait demarré le 64bits avant Intel, les variantes linux portent le nom historique AMD64

Sinon c'est quoi la différence entre CD1 et la version "toute faite"?

CD1 de demandera ce que tu veux installer
la version toute faite ne te demandera pas et installera XFCE ou MATE par defaut

Moi ce qui me tente surtout c'est d'installer tout d'un coup.

alors prend une "toute faite"

Sinon une clé USB de 8Go, c'est suffisant?

suffisant pour installer et utiliser debian ?
ou suffisant pour faire une clef qui servira à l'installation de debian sur le disque dur (plutot que de graver un CD).

dans le second cas, c'est un CD/DVD donc au pire ca prend 4.5Go

Nous avons testé des solutions comme Dolibarr mais on devait créer une commande pour pouvoir faire une sortie… C'est trop compliqué comme processus.

meme si c'est pour un service interne à ta société (donc commande avec montant =0 ) de savoir quand a été faite la demande (la commande), quand la machine a été mise en service (livrée/installée) me semble une bonne chose.

et plus tard, ta boitte aura grossi et voudra faire de la refacturation, et tu sera content d'avoir une gestion de commande et de pouvoir chiffrer le cout d'un service qui change de PC tous les ans pour la société, contre un service qui ne change que tous les 3 ans.

En escrime ou tennis le français est courant dans les grandes compétitions par exemple.

probablement comme l'anglais est courant quand on parle "technique" en informatique
c'est un vocabulaire specifique, dans une discipline particuliere.

ton probleme

If your LDAP server does not support the member-of-overlay in LDAP filters, the input field is disabled. Please contact your LDAP administrator.

ta solution

If your LDAP server does not support the member-of-overlay in LDAP filters, the input field is disabled. Please contact your LDAP administrator.

pas de souci avec le tunnel ssh,
puisque ton serveur nextcloud se connecte à ton ldap en ssh, puis fait du localhost:389 (nextcloud) => tunnel ssh => localhost:389 (serveur ldap)

pas besoin d'ouvrir le firewall car de memoire localhost (127.0.0.1) ne passe pas sur INPUT puisque local sur local

Si ce n'est déjà fait, ouvrez le port 389 TCP sur votre serveur Yunohost

en fait il faut l'ouvrir mais pas sur l'exterieur sinon tout le monde peut se connecter à ton port 389

il faut en fait ouvrir le port 389 sur l'IP VPN (client ou serveur tout depend dans quel sens tu montes ton tunnel)

MAIS
perso je ferais juste un tunnel ssh entre les deux machines, lancé automatiquement via autossh,
et faire pointer ton nextcloud sur localhost:389

iptables -A PREROUTING -t raw -p tcp --dport 21 -j CT --helper ftp
iptables -A PREROUTING -t raw -p tcp --dport 1999 -j CT --helper ftp

sur ces meme regles tu dis de passer le paquet à une table CT
mais elle n'est pas definie dans l'iptables que tu nous sors ?

sinon on est bien d'accord que tu as le reseau suivant ?

Internet <-> 192.168.4.254 [192.168.1.254] <-> LAN <-> [192.168.1.1] serveur FTP

parce qu'il veut faire son propre cloud (autohebergement) à base de RPI et autre machine qu'ils montent en "cluster"

les fichiers/dossiers commencant par un . sont des dossiers/fichiers cachés.

ceux qui sont dans ton dossier personnel contiendront les preferences, les reglages de chaque logiciel.

dans ton exemple
.mozilla contiendra surement ton profil firefox, tes marques pages
.config contient lui plusieurs sous dossier, pour d'autres logiciels

etc

comment ne pas etre pollué ?
en demandant au gestionnaire de fichier de masquer ce fichier,
ou en allant jamais dans /home/tonuser
et en preferant ranger tes affaires dans Documents, Musiques, Photos, Telechargements, Bureau :D

tu fais un OPEN avant de lancer le serveur ?

ne faudrait-il pas :
- lancer le serveur avant de lui passer des commandes
- faire l'init du depot avant de l'ouvrir
- puis ouvrir le depot ?

la documentation ici

https://www.fossil-scm.org/xfer/doc/trunk/www/quickstart.wiki

dit
fossil init nouveauprojet

gestionnaire décentralisé et open source

je pensais plus à git qui est decentralisé,
et c'est quand meme utilisé dans beaucoup de projet, donc on est sur de trouver de la documentation et des astuces pour faire ce que l'on veut.

Une idée de ce qu’il conviendrait de faire ?

arreter d'utiliser un "fossile" et utiliser un gestionnaire de depot "moderne" ? :D

+1

l'ouverture de plusieurs SSH, directement dans les Panes de tmux, c'est cool
je n'en ai pas l'utilité personnelle (je dois passer par une machine de rebond), mais le concept est enorme.

bravo

(je n'arrive pas à mettre le shebang #!/bin/sh dans le codeblock :().

il faut simplement taper ```sh au debut de ton code
et ``` à la fin

ex : beaucoup de lecture (large publique) et peu d'ecriture
tu fais ton CMS pour ecrire toujours sur 1 ou 2 noeuds,
puis tu utilises de la replication au niveau systeme de fichier pour les autres noeuds, qui ne seront alors qu'en lecture seule.

si tu dois avoir aussi beaucoup d'ecriture (phpBB avec un large public dans ton exemple) il faut regarder les mecanismes de replications fournis directement par la base de donnée et qui demandent parfois un peu de tuning sur les IDs des insertions par exemple
ex : noeud 1, insertion des IDs xxxxxx1
noeud 2, insertion des IDs yyyyy2
noeud 3, insertion des IDs zzzzz3
etc

bref, avant de reinventer la poudre,
bien lire les manuels des solutions pour comprendre que c'est deja prevu, et que cela a deja été testé

faire un ctrl+b+:
et demander "set synchronize-panes"

tous les tmux de la fenetre sont alors synchroniser,
cela marche meme en dehors du ssh :D

ou pas

ps faux | grep -E 'firefox'
moi 2345 31.6 11.3 2937988 898476 ? Sl 15:42 3:04 _ /usr/lib/firefox/firefox
moi 2771 0.0 0.0 14260 932 pts/1 S+ 15:52 0:00 _ grep --color=auto -E firefox

ou bien si

ps aux | grep '[f]irefox'
moi 2345 27.1 11.3 2937988 902972 ? Sl 15:42 3:10 /usr/lib/firefox/firefox

c'est donc le faite d'utiliser les [ ] qui force grep à faire une regex et donc à ne prendre que cela et surtout à s'ignorer lui meme

C'est ingénieux, j'aime beaucoup ton idée NeoX ;)

ce n'est pas "ingenieux"
c'est comme ca qu'on fait quand on est dans le metier,

tout comme on ne reinvente pas la securité par des tunnels ssh pour monter un VPN dedans, alors qu'on est dans un LAN

La communication entre les clients et le serveur DNS est-elle chiffrée

non, mais c'est pas grave car ce sera DANS le VPN
donc client <=> service VPN <=> Serveur VPN <=> Service DNS

tu verras avec ton DNS ce sera tout simple

quand tu es dehors ton service.eaufroide.com pointe sur ton IP publique (DNS externe)
quand tu es dedans (LAN) service.eaufroide.com pointe sur l'IP LAN de ton serveur (ou sur l'IP LAN du reverse proxy)

et tu n'as alors plus de probleme de hairpinning

plutot que de toucher au fichier /etc/hosts,

tant qu'à monter une usine à gaz,
installe un DNS sur ton serveur openvpn,
dit lui d'ecouter sur l'IP qui sert de passerelle aux clients VPN
et demande à openvpn de mettre à jour le DNS

ce sera plus propre
plus perenne,
plus utile

-le LAN n'est pas un espace sécurisé (surtout quand je passerai en IPv6)

le VPN entre 2 machines d'un LAN ne securise rien
tu chiffres la communication entre ces 2 machines, comme avec SSL, TLS etc

mais le LAN c'est generalement TON reseau, donc TA securité,
hormis s'embeter à ajouter des couches de protocole (tunnel VPN(tunnel SSH(contenu)))
je ne vois toujours pas l'utilité

-en finir avec les tunnel SSH qui partent dans tout les sens et qui nécessitent leur lot de configuration

parce que "monter un tunnel SSH qui te permet de monter un tunnel VPN" juste pour simplifier ton usage des tunnels SSH c'est se simplifier la vie ?

tu vas donc faire plusieurs tunnels VPN vers chacun de tes serveurs, donc autant de fichier de config à gerer, sans compter le tunnel SSH pour ouvrir le "serveur VPN" à ta machine local ?

-rediriger les flux du reverse proxy plus proprement (par exemple là j'avais une redirection vers un prestashop, qui transitait par un tunnel SSH et prestashop râlait car pour lui hostname:8443 != hostname)

pourquoi tu passes par un tunnel SSH pour acceder à un serveur local ?

-faciliter l'accès à mes services (exemple dans firfox je devais taper 127.0.0.1:8080/ pour acceder au service sur server A, 127.0.0.1:8081 pour accéder au service sur server B, maintenant je peux utiliser direct les IP statique dans le VPN que j'ai ajouté en marque page)

tu peux aussi utiliser les IPs virtuelles 127.0.0.1, 127.0.0.2 127.0.0.3, etc etc

et sur une machine distance tu peux aussi avoir plusieur IP virtuelle/secondaire (192.168.x.1, 192.168.x.2, 192.168.x.3…)

-fixer les IP indépendamment du routeur/DHCP

là aussi tu peux avoir une machine avec un reseau 192.168.1.0/24 fournit par le routeur/dhcp et acceder à internet par celui là

mais utiliser le reseau 192.168.2.0/24 pour tes maquettes

donc NON le VPN n'est pas la solution aux problemes que tu te crees

le VPN pourra par contre te servir quand tu voudras, depuis l'exterieur, te connecter à ton datacenter (serveur VPN1), ou à la maison (serveur VPN2)

une fois les VPNs ouverts, la magie s'opere, et tes flux transitent comme si tu etais sur ton LAN, pas besoin de tunnel ssh, de redirection de port, de reverseproxy…

j'ai beau relire, je ne comprend toujours pas pourquoi tu veux te connecter au service OpenVPN quand tu es sur le meme LAN que le serveur qui heberge l'OpenVPN

un serveur VPN, c'est fait pour connecter deux reseaux disjoints (chez toi, chez tes parents ou ton bureau) et laisser croire à ta machine que les deux reseaux sont les memes (pour acceder à l'imprimante des parents, au serveur NAS du bureau

si tu es sur le meme LAN, cela n'a aucun interet,

si tu montes un labo, autant mettre une machine entre les 2 reseaux qui fera du routage et laissera croire que ce sont 2 reseaux disjoints

alors le coup de monter un tunnel SSH
pour ensuite monter un tunnel VPN dedans

je le redis, si tu arrives à faire un tunnel SSH dans le sens Client -> Serveur
c'est que tu as deja des ports ouverts de l'exterieur vers le serveur,
autant s'en servir pour directement faire le tunnel VPN (reconfigurer openvpn pour ecouter sur le bon PORT.