CoolRaoul

C'est bien ça

Je pense avoir réparé, vu que le rapport avec syslog me semblait bien probable, j'ai investigué de ce coté. Il me restait un (très) vieux reste de "hack" perso que j'avais documenté ici: https://www.nas-forum.com/forum/topic/42140-comment-parer-durablement-lattaque-chine-teste-r/?do=findComment&comment=1319237860 Apres avoir supprimé mon fichier "/usr/local/etc/syslog-ng/patterndb.d/local.conf", au reboot il semble que ce soit rétabli. (je vais refaire un reboot supplémentaire pour en avoir le coeur net)

Hélas c'est revenu Avec un peu de reverse engineering , je constate que le process apache ouvre un socket unix en écriture: openat(AT_FDCWD, "/run/apache24-error_log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE|O_CLOEXEC, 0666 mais aucun process n'est en lecture à l'autre bout, et ca bloque. Le premier message d'erreur, au reboot à été celui-ci: Accompagné de Bien etendy "repair" ne marche pas plus qu'un désinstall/install. J'ai ouvert un ticket au support Syno, mais je ne la sens pas trop cette affaire..

Dans le cas de @Nouch je déduis qu'il était déjà configuré de cette façon et qu'il souhaite continuer à iso fonctionnalité. En plus j'imagine qu'il n'a pas rendu le port 445 de son NAS visible sur internet. Le risque se limite donc aux attaques par rebond interne, quand même plus restreint

Il reste toujours possible de l'autoriser sur DSM7 en cas de besoin:

Tiens, pas chez moi! La barre des taches est toujours visible, meme avec les fenêtres maximisées. Testé sur Chrome et edge. **EDIT** A pardon, bien entendu en les déplaçant à la souris, rien n'interdit de les mettre au dessus, mais faut le faire exprès.

Oui, @Einsteinium l'a déjà indiqué plus haut.

Pas si simple: le bootstrap ("curl -k https://bootstrap.pypa.io/get-pip.py | python3") ne se contente pas de déposer les scripts en /usr/bin/pip*, ca installe des modules et j'ai pas encore vu ou. Le mieux je pense serait que je me configure un virtual env basé sur la version actuelle et comme ça je maitrise mieux.

Merci, ça a fonctionné! $ which pip3 /bin/pip3 Par contre, j'imagine que j'aurais à refaire ça à chaque mise à jour du python DSM ? (Je n'espère pas vraiment de réponse à cette question. Vu que c'est un peu "frais" ça m'étonnerait que beaucoup aient du recul la dessus.) Il semble que ce ne soit plus le cas (du moins dans la mesure ou aucun python2 n'est installé je suppose). Après install, pip est installé aussi et pip3 et pip3.8 sont exactement le même fichier: $ sum /bin/pip* 03891 1 /bin/pip 03891 1 /bin/pip3 03891 1 /bin/pip3.8 $ file /bin/pip* /bin/pip: a /bin/python3 script text executable /bin/pip3: a /bin/python3 script text executable /bin/pip3.8: a /bin/python3 script text executable

Je sais bien, mais comme je l'ai écrit, il manque pip dans le python officiel et ça ne répond pas à ma question du coup.

Je reformule: Aujourd'hui je reçois une notification qui m'annonce une mise à jour du contenu de l'accord du programme de préversion. Le texte de la page ou aboutit le lien qu'on m'invite à activer n'a pas été modifié depuis l'année dernière. Pourquoi cette notification alors?

Exactement la même erreur pour moi aussi. Autre chose, je viens de recevoir cette notification: quand je clique sur le lien j'aboutit à ceci: j'ai loupé un épisode ? **EDIT** pas mieux avec la version en-us de la page https://www.synology.com/en-us/company/legal/Pre_Release_Program_Agreement

Salut à tous, je viens d'installer le python 3.8 synocommunity (histoire d'avoir pip & co) les binaires sont bien dans /var/packages/python38/target/bin mais je ne les ai retrouvé symlinkés nulle part dans /usr/local/... C'est normal ou un oubli?

Installé hier sur mon vieux tromblon de DS213j. Même pas constaté ça. Au contraire ça me semble plus fluide qu'avant (en particulier le package center qui ramait grave en DSM 6 et est revenu à une utilisation bien plus supportable). J'ai eu quelques frayeurs avec Apache (qui ne démarrait plus) et le log center. Un peu de bidouille et de "reverse engineering" plus tard ca me semble OK. Ne me demandez pas comment j'ai réparé, c'est parti tout azimuth et je ne sais même pas ce qui à décoincé le bousin.

Dans ce cas on peut utiliser cette approche aussi (au passage je ne suis pas sur de comprendre le "plus secure" ) find <bla bla> -print -delete le "-print" aura pour effet d'ajouter la verbosité souhaitée en traçant les fichiers destinés à être supprimés par la clause suivante, "-delete". Et, si on insiste à utiliser "rm", plutôt privilégier ceci alors: find <bla bla> -print0 | xargs -0 rm -v au moins il n'y aura pas un process forké pour chaque fichier supprimé (meme si je reconnais qu'on est loin d'un possible problème de perf, j'ai juste tendance à être parfois inutilement perfectionniste)

Le plus proche de ça est Synology Drive

Non, pas de "{} \;" apres "-delete" (c'est aussi pourquoi j'ai dis que c'était plus concis) Je n'ai jamais eu à faire ça et la preuve est que ça échoue Ci dessous résultat d'une tache avec pour contenu "bash find <arguments non destructifs ici>": Cher utilisateur, Le planificateur de tâches à terminé une tâche planifiée. Tâche : testusertask Heure de début : Fri, 21 May 2021 17:28:09 GMT Heure d’arrêt : Fri, 21 May 2021 17:28:10 GMT État actuel : 126 (Interrompu) Sortie standard/erreur : /bin/find: /bin/find: cannot execute binary file

J'avais meme pas fais gaffe!

Je ne vois pas de quoi tu parles là 🤨

le "bash" en début est à supprimer il manque un espace avant "-type" -delete serait quand meme plus lisible et concis que -exec .... \; (mais ça ne change rien fonctionnellement)

Je ne comprends pas ce qui fait dire que "-exec /usr/bin/rm -f {} \;" serait plus efficace que "-delete." Au contraire la première forme lance un process pour chaque suppression alors que l'autre n'en lance aucun (c'est built-in dans find). Même si j'imagine que l'impact reste minime bien entendu.

Mon explication date de 2013 et à l'époque je ne pouvais me baser que sur les informations dont on disposait à ce moment-là. Le white paper est daté de du 18/12/2019 selon les métadonnées PdF

Pas dans la mesure ou mon hypothèse (selon laquelle avoir préalablement configuré un reverse DNS protègereait d'un passage en IPV4 partagé inopiné et du changement d'IP qui en découle) est valide: il n'y aurait alors *pas* de changement d'IP. Saufs si ils s'assoient dessus, d'où ma remarque précédente:

Je suis exactement dans la même configuration (je dispose de tout le range de ports entrants) Par contre, j'imagine qu'être réellement en "full stack" suppose en plus une sorte de garantie de la part de Free que ça ne changera pas.

Ca me semble avoir du sens. Sinon mon reverse s'applique aussi aux autres clients Free qui partagent mon IP, pas glop je trouve. A moins qu'ils fassent sauter le reverse en même temps que le compte est basculé en IP partagée (ca serait un peu gros quand même) **EDIT** A partir du moment ou le reverse DNS est configuré, c'est le FQDN associé qui est retourné en reverse lookup (essayer ici: http://www.kloth.net/services/nslookup.php) Imaginez avoir positionné en reverse ceci-est-ma-box.mon-domaine.com (ou vous êtres propriétaire de "mon-domaine.com" , c'est obligatoire) C'est ce FQDN qui sera associé à cette IP, pour vous et vos "voisins d'IP"