parce que hier j'ai fait tout le test
creer un utilisateur1
fait un dossier dans /home/utilisateur1 (donc /home/utilisateur1/dossier)
donner les droits sur ce dossier à utilisateur1 en plus de son home
creer le nouvel utilisateur2 avec son chroot sur /home/utilisateur1 et son home en /dossier
par defaut il pouvait l'ouvrir mais pas écrire dedans,
d'ou ma suggestions de regarder les problèmes de droits,
que j'ai réglé avec un chown utilisateur1:sftpusers /home/utilisateur1/dossier
et un chmod 775 /home/utilisateur1/dossier
à partir de là mon utilisateur2 pouvait écrire dans /home/utilisateur1/dossier
c'est exactement le sens du toto faire arriver l'utilisateur dans un dossier qui lui appartient.
ensuite il faut adapter à TON besoin
1°) dans la config ssh, régler le chroot (racine du "système" sur /home/toto
et le dossier home de l'utilisateur visiteurs sur /dossier (pour qu'il arrive à la fin dans /home/toto/dossier
2°) donner les droits à cet utilisateur sur le dossier /home/toto/dossier
en comprenant la gestion des droits linux chown monuser:sftpusers /home/toto/dossier
va donner la propriété à tonuser et au groupe sftpusers sur le /dossier dans /home/toto
si tu adaptes cela en chown toto:sftpusers pour que toto garde la main, et que les gens du groupe sftpusers puisse intervenir dessus
il ne te reste plus qu'à autoriser l'écriture (si nécessaire) au gens du groupe chmod 775 /home/toto/dossier
Posté par NeoX .
En réponse au message Question SFTP.
Évalué à 4.
Dernière modification le 22 mars 2021 à 19:02.
J'arrive à créer un utilisateur SFTP et à le confiner dans son chroot (par exemple "/mnt") mais ensuite la création d'un lien symbolique vers "/home/toto/dossier" ne marche pas : sftp refuse de suivre le lien :-(
heu, c'est normal non ?
tu veux le bloquer dans le dossier /mnt (c'est le but du chroot)
et puis tu lui demandes de suivre le lien qui va vers /home/toto/dossier (donc qui SORT du dossier /mnt)
Même chose si je créé l'utilisateur SFTP avec son chroot directement dans "/home/toto/dossier".
il faut là, que le dossier /home/toto/dossier ait les bons droits pour l'utilisateur sftpuser
NB : je viens de faire la procedure car elle m'intéresse aussi pour remplacer mon vieux FTP qui traine dans un coin, et ca fonctionne comme prévu.
j'arrive bien dans le dossier /sftp/monuser/incoming
(il veut juste que sur un cas d'usage qu'il envisage ses concurrents ne puissent pas utiliser les développements qu'il a financés - mais il est ok que ses concurrents exploitent les dév qu'il a financés si c'est pour une autre utilisation).
ben les devs interdits aux concurrents => branche spéciale ou licence case à cocher X
et les devs autorisés aux concurrents => branche normale de dev/release
on trouve ce modele régulièrement maintenant dans l'open source
la v10 est payée par les contributeurs/clients => toutes leurs fonctionnalités
la v9 est gratuite, dispo pour tous => certaines fonctionnalités sont manquantes
apres si tu veux limiter des fonctionnalités en fonction du client (droit d'usage pendant 2 ans, etc), c'est une question de licence logicielle, tu actives ou pas certains bout de ton logiciel selon la licence que tu délivres à l'utilisateur final
et là, ben tu fais bien ce que tu veux.
Gratuit => pas de licence => fonctionnalité A+B+C+D
Payant tel client => fichier de licence X => A+B+C+D + pack de fonctionnalité X
payant un autre client => fichier de licence Y => A+B+C+D + pack de fonctionnalité Y
etc
et pour le développement, tu as ta branche dev/master
tu peux avoir un branche "clientX" avec ses développements
et tu t'engages pendant 2ans à ce que les elements de la branche "clientX" n'intègrent pas master/dev
Windows considere son disque comme non propre (car il n'était pas vraiment arrêté et linux a fait des acces dessus) => démarrage en mode sans échec, puis analyse du disque
si tu montes le disque windows dans le linux, l'ancien Linux considerait le disque windows comme non propre aussi, et bloquait le demarrage et/ou remplissait les logs d'erreurs
en reinstallant le linux, il n'accede plus au disque windows par defaut, donc demarre sans souci, sans remplir les logs d'erreurs
Au final mon instance marchait bien. Je voulais passer sur une version plus récente, celle-ci me réclame php 7. J’ai mis à jour ma distribution, mais nginx continue à utiliser la version 5 installée à base de dpkg.
au dela de mettre à jour ton PHP et la distribution par la meme occasion pour passer de jessie (debian8) à stretch (debian9) puis à buster (debian10)
il faut aussi mettre à jour nextcloud pour que le code écrit dedans soit compatible avec php7, sinon ca plante.
j'ai eu le cas hier, en voulant migrer un site web avec des modules fait main chez un client.
ben le code marche plus en passant de debian8/php5 à debian9/php7 car certains bouts de codes doivent etre réécrit.
si nextcloud ne se lance plus, le Nginx ne le trouve pas, et te répond bad gateway
pour diagnostiquer, tu peux essayer de te connecter directement à ton nextcloud plutot que de passer par le Nginx
supprimer mingw et utiliser les WSL qui te fournissent tous les outils Linux sous Windows, fournit par microsoft donc assurant une compatibilité plus grande (en principe)
et tu n'arrives pas à écrire dedans depuis quelle machine ?
une machine du reseau ? windows ? linux ?
à une époque il fallait modifier une clef de registre sur le windows pour autoriser l'accès à un partage samba avec utilisateur guest sans mot de passe
ton idée de TTL sur le DNS me fait penser que je peux scripter la mise à jour du DNS
je pourrais alors simplement avoir un reseau privé
et quand la VM devient dispo sur ce reseau privé le reverse proxy execute un script qui met à jour le DNS pour signaler que la VM est derriere son IP publique et plus à l'ancien emplacement.
les disques durs achetés dans le commerce sont generalements deja formatés dans un format pour windows (NTFS)
certains linux ne savent pas encore écrire sur un disque NTFS, tu peux donc voir le contenu, mais ne rien en faire.
il faut installer certains modules pour autoriser l'écriture.
si tu ne te sers du disque que pour des machines linux, tu peux le repartitionner/reformater dans un format dispo pour linux uniquement (ext4 par exemple)
pour l'instant 2 serveurs physiques et 3Vms avec tout le monde en IP publique sans NAT (firewall sur les machines directement)
l"idée finale dans ma tete, c'est vraiment
2 serveurs physiques (IP publique pour le management)
2 nouvelles VMs, reverse proxy qui porteront les IPs publiques et qui vont envoyer vers les 3VMs existantes qui seront passées en IPs privées
Helas oui, je sais que y a du routage à faire,
et c'était là ma question, savoir si un VPN qui fait du L2 existait, pour n'avoir qu'un seul range reseau privé,et donc une seule interface sur les VMs
mais si ca n'existe pas, je peux mettre 2 reseaux privés sur les VMs 192.168.1.x et 192.168.2.x
sur le physique 1 le reverse 1 tente de joindre la VM sur 192.168.1.x et sur 192.168.2.x (et ne trouvera jamais 2.x), et sur l'infra 2 le reverse renvoie sur 192.168.2.x et ne trouvera jamais 192.168.1.x
Le reverse aura donc besoin d'un lien vers l'autre reverse pour trouver la VM quand elle a bougée, et permettre que le RR DNS fonctionne tout le temps.
et ca peut etre un VPN qui route entre les 2 emplacements physiques, comme on a 2 reseaux, ca peut fonctionner.
je me rend compte que mon schema n'est pas toutafais ma pensée.
le VPN ne servirait que pour joindre la VM quand elle est de l'autre coté.
en mode normal
Client -> IP publique1 -> Reverse -> IP Privée ->VM/Serveur1
en mode "panne ou VM déplacée pour nécessité de ressources"
Client -> IP publique1 -> Reverse -> IP Privée -> VPN -> VM/Serveur2
mais j'aime bien ton idée que ce soit les reverse proxy qui gèrent entre eux la redondance
si je comprend bien
IP publique -> Reverse proxy -> Backend1/IP privée locale + Backend2/Ip publique de l'autre reverse
quand la VM locale disparait, le reverse proxy/load balancer, balance le flux sur l'autre IP publique, qui proxyfie sur sa VM Locale (en fait la VM qui a été déplacée)
on evite la couche VPN, la VM garde la meme IP privée entre les elements du cluster de serveur physique et peut donc facilement migrer d'un serveur à l'autre
bon ben y a plus qu'à faire une maquette de tout ca ;)
[^] # Re: une piste
Posté par NeoX . En réponse au message Question SFTP. Évalué à 3.
un bug avec ta version de SSH alors ?
parce que hier j'ai fait tout le test
creer un utilisateur1
fait un dossier dans /home/utilisateur1 (donc /home/utilisateur1/dossier)
donner les droits sur ce dossier à utilisateur1 en plus de son home
creer le nouvel utilisateur2 avec son chroot sur /home/utilisateur1 et son home en /dossier
par defaut il pouvait l'ouvrir mais pas écrire dedans,
d'ou ma suggestions de regarder les problèmes de droits,
que j'ai réglé avec un chown utilisateur1:sftpusers /home/utilisateur1/dossier
et un chmod 775 /home/utilisateur1/dossier
à partir de là mon utilisateur2 pouvait écrire dans /home/utilisateur1/dossier
[^] # Re: une piste
Posté par NeoX . En réponse au message Question SFTP. Évalué à 3.
c'est exactement le sens du toto faire arriver l'utilisateur dans un dossier qui lui appartient.
ensuite il faut adapter à TON besoin
1°) dans la config ssh, régler le chroot (racine du "système" sur /home/toto
et le dossier home de l'utilisateur visiteurs sur /dossier (pour qu'il arrive à la fin dans /home/toto/dossier
2°) donner les droits à cet utilisateur sur le dossier /home/toto/dossier
en comprenant la gestion des droits linux
chown monuser:sftpusers /home/toto/dossierva donner la propriété à tonuser et au groupe sftpusers sur le /dossier dans /home/toto
si tu adaptes cela en chown toto:sftpusers pour que toto garde la main, et que les gens du groupe sftpusers puisse intervenir dessus
il ne te reste plus qu'à autoriser l'écriture (si nécessaire) au gens du groupe
chmod 775 /home/toto/dossier[^] # Re: une piste
Posté par NeoX . En réponse au message Question SFTP. Évalué à 4. Dernière modification le 22 mars 2021 à 19:02.
heu, c'est normal non ?
tu veux le bloquer dans le dossier /mnt (c'est le but du chroot)
et puis tu lui demandes de suivre le lien qui va vers /home/toto/dossier (donc qui SORT du dossier /mnt)
il faut là, que le dossier /home/toto/dossier ait les bons droits pour l'utilisateur sftpuser
NB : je viens de faire la procedure car elle m'intéresse aussi pour remplacer mon vieux FTP qui traine dans un coin, et ca fonctionne comme prévu.
j'arrive bien dans le dossier /sftp/monuser/incoming
sur debian10, ssh/sftp-server 7.9p1-10+deb10u2
[^] # Re: n'est pas la technique habituelle de l'openCore
Posté par NeoX . En réponse au message Droits d'utilisation réservés et licence libre. Évalué à 3.
ben les devs interdits aux concurrents => branche spéciale ou licence case à cocher X
et les devs autorisés aux concurrents => branche normale de dev/release
# une piste
Posté par NeoX . En réponse au message Question SFTP. Évalué à 2.
# n'est pas la technique habituelle de l'openCore
Posté par NeoX . En réponse au message Droits d'utilisation réservés et licence libre. Évalué à 5.
on trouve ce modele régulièrement maintenant dans l'open source
la v10 est payée par les contributeurs/clients => toutes leurs fonctionnalités
la v9 est gratuite, dispo pour tous => certaines fonctionnalités sont manquantes
apres si tu veux limiter des fonctionnalités en fonction du client (droit d'usage pendant 2 ans, etc), c'est une question de licence logicielle, tu actives ou pas certains bout de ton logiciel selon la licence que tu délivres à l'utilisateur final
et là, ben tu fais bien ce que tu veux.
Gratuit => pas de licence => fonctionnalité A+B+C+D
Payant tel client => fichier de licence X => A+B+C+D + pack de fonctionnalité X
payant un autre client => fichier de licence Y => A+B+C+D + pack de fonctionnalité Y
etc
et pour le développement, tu as ta branche dev/master
tu peux avoir un branche "clientX" avec ses développements
et tu t'engages pendant 2ans à ce que les elements de la branche "clientX" n'intègrent pas master/dev
[^] # Re: Ouf !
Posté par NeoX . En réponse au message Gros soucis de démarrage. Évalué à 2.
si tu peux, mais il faut etre sur que windows a bien arrété le disque, et pas qu'il s'est mis en veille profonde
y a un truc ou deux a régler sur le windows pour que l'action d'arrêter fasse un veritable arrêt et pas une mise en veille.
idem dans l'autre sens, il faut bien libérer le disque avant de couper le linux (mise en veille ou arrêt complet)
[^] # Re: Ouf !
Posté par NeoX . En réponse au message Gros soucis de démarrage. Évalué à 2.
Windows considere son disque comme non propre (car il n'était pas vraiment arrêté et linux a fait des acces dessus) => démarrage en mode sans échec, puis analyse du disque
si tu montes le disque windows dans le linux, l'ancien Linux considerait le disque windows comme non propre aussi, et bloquait le demarrage et/ou remplissait les logs d'erreurs
en reinstallant le linux, il n'accede plus au disque windows par defaut, donc demarre sans souci, sans remplir les logs d'erreurs
# c'est deja un beau résultat
Posté par NeoX . En réponse au journal Zébulon. Évalué à 6.
piste d'ajout :
;)
[^] # Re: Nginx/nextcloud/php
Posté par NeoX . En réponse au message [Résolu] Problème NextCloud nginx. Évalué à 2.
aujourd'hui on en est à nextcloud 21
et il y a des procédures de mises à jour
https://docs.nextcloud.com/server/21/admin_manual/maintenance/upgrade.html
# Nginx/nextcloud/php
Posté par NeoX . En réponse au message [Résolu] Problème NextCloud nginx. Évalué à 5.
au dela de mettre à jour ton PHP et la distribution par la meme occasion pour passer de jessie (debian8) à stretch (debian9) puis à buster (debian10)
il faut aussi mettre à jour nextcloud pour que le code écrit dedans soit compatible avec php7, sinon ca plante.
j'ai eu le cas hier, en voulant migrer un site web avec des modules fait main chez un client.
ben le code marche plus en passant de debian8/php5 à debian9/php7 car certains bouts de codes doivent etre réécrit.
si nextcloud ne se lance plus, le Nginx ne le trouve pas, et te répond bad gateway
pour diagnostiquer, tu peux essayer de te connecter directement à ton nextcloud plutot que de passer par le Nginx
# le papier
Posté par NeoX . En réponse au journal Question : Ai-je le droit de refuser d'exécuter un logiciel ?. Évalué à 8.
non mais l'agence doit pouvoir te fournir un exemplaire papier, quitte à te l'envoyer par la poste
car heureusement le gouvernement te laisse sortir jusqu'a 10km de chez toi, sans limite de temps
tu devrais donc pouvoir au moins descendre relever ton courrier
[^] # Re: tuple
Posté par NeoX . En réponse au message Retourner deux valeurs. Évalué à 3. Dernière modification le 19 mars 2021 à 08:30.
revoir l'algorithme pour virer la condition qui fait qu'elle s'arrête de remplir le tuple/liste
[^] # Re: Ignore-les
Posté par NeoX . En réponse au message git + meld = GLib-GIO-CRITICAL. Évalué à 3.
supprimer mingw et utiliser les WSL qui te fournissent tous les outils Linux sous Windows, fournit par microsoft donc assurant une compatibilité plus grande (en principe)
[^] # Re: des contradictions ?
Posté par NeoX . En réponse au message Samba partage sans mot de passe je n'y arrive pas. Évalué à 2.
et tu n'arrives pas à écrire dedans depuis quelle machine ?
une machine du reseau ? windows ? linux ?
à une époque il fallait modifier une clef de registre sur le windows pour autoriser l'accès à un partage samba avec utilisateur guest sans mot de passe
# des contradictions ?
Posté par NeoX . En réponse au message Samba partage sans mot de passe je n'y arrive pas. Évalué à 5. Dernière modification le 16 mars 2021 à 17:19.
ici tu veux utiliser la sécurité en mode utilisateur
là tu dis que les utilisateurs mauvais (en gros qui n'ont pas réussi à s'identifier sont envoyé en tant que GUEST (invité) sur la machine
là tu dit que l'invité sera nobody, que l'invité est OK
plus loin tu définis un dossier /mnt/thierry
ou tout le monde doit pouvoir écrire sans mot de passe (writable, droit 666 et 777)
mais quels sont les droits sur le serveur de ce dossier Thierry ?
ls -ld /mnt/thierry[^] # Re: formatage ?
Posté par NeoX . En réponse au message pas de droits sur disque dur usb. Évalué à 3.
ou alors ton disque dur à 2 partitions, dont une est vue comme un CDROM (pour les pilotes ou le logiciel de chiffrement prévu par le fournisseur)
que dit la commande
lsblkou bien la commandefdisk -l?[^] # Re: il faut dessiner sur un calque transparent
Posté par NeoX . En réponse au message [résolu] Gimp : Dessiner au pixel avec de la transparence. Évalué à 3.
bien vu, en cochant le hard edge, ca résoud aussi mon souci
[^] # Re: il faut dessiner sur un calque transparent
Posté par NeoX . En réponse au message [résolu] Gimp : Dessiner au pixel avec de la transparence. Évalué à 3.
hmmm
j'avais du temps j'ai essayé
1°) à gauche, sur le haut, tu choisis le "crayon" plutot que le pinceau (clic droit dessus, ou simplement la touche N pour peNcil en anglais)
2°) tu choisis la brosse carrée dans le bloc en haut à droite, icône 3 sur la premiere ligne
par defaut c'est une brosse de 3x3pixel
3°) à gauche tu as la taille du la "pointe" réglée sur 3, tu descend à 1
ah mince, ca a marché sur quelques clics et le temps de refaire les manips pour te l'expliquer ca ne le fait plus :(
# il faut dessiner sur un calque transparent
Posté par NeoX . En réponse au message [résolu] Gimp : Dessiner au pixel avec de la transparence. Évalué à 3.
et normalement quand tu gommes, l'arrière plan est repris, comme il est transparent, ca match
évidemment si le calque en dessous est "plein", alors tu gommes le calque du dessus et tu vois celui du dessous.
pour avoir un calque transparent, c'est quand tu le crees, comme pour l'image tu as "remplir avec" (Fill With)
# betement
Posté par NeoX . En réponse au message problème rebond moteur Python 3 COO. Évalué à 2.
je dirais que tu "lisses" le depart du moteur,
mais tu fais un arrêt brutal.
pourquoi ne pas lisser aussi l'arrêt ?
[^] # Re: Emplacement du VPN, routage
Posté par NeoX . En réponse au message idée de redondance de VMs, est-ce faisable. Évalué à 2.
ton idée de TTL sur le DNS me fait penser que je peux scripter la mise à jour du DNS
je pourrais alors simplement avoir un reseau privé
et quand la VM devient dispo sur ce reseau privé le reverse proxy execute un script qui met à jour le DNS pour signaler que la VM est derriere son IP publique et plus à l'ancien emplacement.
# formatage ?
Posté par NeoX . En réponse au message pas de droits sur disque dur usb. Évalué à 2.
les disques durs achetés dans le commerce sont generalements deja formatés dans un format pour windows (NTFS)
certains linux ne savent pas encore écrire sur un disque NTFS, tu peux donc voir le contenu, mais ne rien en faire.
il faut installer certains modules pour autoriser l'écriture.
si tu ne te sers du disque que pour des machines linux, tu peux le repartitionner/reformater dans un format dispo pour linux uniquement (ext4 par exemple)
[^] # Re: Emplacement du VPN, routage
Posté par NeoX . En réponse au message idée de redondance de VMs, est-ce faisable. Évalué à 2.
pour l'instant 2 serveurs physiques et 3Vms avec tout le monde en IP publique sans NAT (firewall sur les machines directement)
l"idée finale dans ma tete, c'est vraiment
2 serveurs physiques (IP publique pour le management)
2 nouvelles VMs, reverse proxy qui porteront les IPs publiques et qui vont envoyer vers les 3VMs existantes qui seront passées en IPs privées
Helas oui, je sais que y a du routage à faire,
et c'était là ma question, savoir si un VPN qui fait du L2 existait, pour n'avoir qu'un seul range reseau privé,et donc une seule interface sur les VMs
mais si ca n'existe pas, je peux mettre 2 reseaux privés sur les VMs 192.168.1.x et 192.168.2.x
sur le physique 1 le reverse 1 tente de joindre la VM sur 192.168.1.x et sur 192.168.2.x (et ne trouvera jamais 2.x), et sur l'infra 2 le reverse renvoie sur 192.168.2.x et ne trouvera jamais 192.168.1.x
Le reverse aura donc besoin d'un lien vers l'autre reverse pour trouver la VM quand elle a bougée, et permettre que le RR DNS fonctionne tout le temps.
et ca peut etre un VPN qui route entre les 2 emplacements physiques, comme on a 2 reseaux, ca peut fonctionner.
[^] # Re: faisable mais peut se faire plus simplement
Posté par NeoX . En réponse au message idée de redondance de VMs, est-ce faisable. Évalué à 2.
je me rend compte que mon schema n'est pas toutafais ma pensée.
le VPN ne servirait que pour joindre la VM quand elle est de l'autre coté.
en mode normal
Client -> IP publique1 -> Reverse -> IP Privée ->VM/Serveur1
en mode "panne ou VM déplacée pour nécessité de ressources"
Client -> IP publique1 -> Reverse -> IP Privée -> VPN -> VM/Serveur2
mais j'aime bien ton idée que ce soit les reverse proxy qui gèrent entre eux la redondance
si je comprend bien
IP publique -> Reverse proxy -> Backend1/IP privée locale + Backend2/Ip publique de l'autre reverse
quand la VM locale disparait, le reverse proxy/load balancer, balance le flux sur l'autre IP publique, qui proxyfie sur sa VM Locale (en fait la VM qui a été déplacée)
on evite la couche VPN, la VM garde la meme IP privée entre les elements du cluster de serveur physique et peut donc facilement migrer d'un serveur à l'autre
bon ben y a plus qu'à faire une maquette de tout ca ;)