Oui elle a le droit de faire du SSH vers ton poste pro. S'il ne t'appartient pas il est en plus probablement infogéré et peut-être que dans ton cas cela se fait par SSH. De plus je ne suis pas certain que toi tu aies le droit de bloquer ces connexions et cela pourrait se retourner contre toi, surtout si cela est utilisé pour déployer des mises à jour sur le poste.
Par contre elle doit respecter les lois, notamment elle ne peut pas accéder aux données identifiées comme personnelles sur le poste de son initiative. Concernant l'espionnage de l'utilisateur je ne sais pas ce que dit la loi. Si elle n'a pas le droit tu peux te retourner contre la société. Si elle a le droit et que cela est contraire à ton éthique malheureusement la seule solution ça va être de changer de boîte, pour une qui n'espionne pas ses utilisateurs.
Ce n'est pas une histoire que la DSI soit bienveillante ou pas. Évidemment qu'elle est "bienveillante" (dans le sens où elle n'ira pas à l'encontre des lois) sinon elle va se faire défoncer.
Dans le cas du télétravail c'est une histoire que "je met une machine qui ne m'appartient pas sur mon réseau", what could possibly go wrong? Bah deux choses, ton réseau local peut être pourri et va peut-être essayer d'attaquer ta machine de travail (mais ça c'est la responsabilité de l'entreprise de sécuriser sa machine).
Également la DSI, avec ses responsables SI consciencieux et très prudents, n'est pas infaillible. Ton réseau local peut être attaqué par la machine sur laquelle tu n'a pas la main et donc il faut protéger ton réseau contre les potentielles tentatives d'intrusions de la part ces machines qui se connectent chez toi. C'est des règles cyber de base (là où je travaille en tout cas) et il y a des artifices simples pour le faire (réseaux séparés/réseau invité, isolation WiFi, firewall, etc).
Mettre une machine qu'on ne contrôle pas sur son réseau, c'est un cheval de troie potentiel. J'ai surement confiance en ma DSI pour qu'elle prenne toutes les précautions nécessaires pour qu'une intrusion n'arrive jamais, le risque est toujours là. Le jour où cela arrivera, je n'aurai plus confiance en ma DSI mais au moins mon réseau local personnel aura été protégé contre l'intrusion. C'est préventif.
À moduler avec la version de la freebox bien entendu, la dernière freebox que j'ai connu c'est la v5 ;)
Le réseau invité de la freebox je ne sais pas comment il fonctionne. Sinon pour le premier point il faudra de toute façon un routeur car la freebox ne gère pas les VLANs sur le LAN (du moins ne permet pas de gérer les VLANs sur le LAN client).
Si tu n'as pas de matériel le plus simple et le moins cher c'est de te procurer un petit routeur avec port WAN et LAN ethernet (qui en sus peut aussi faire AP wifi).
Il suffira de connecter le port WAN sur ton LAN et de t'assurer que le nouveau routeur fait du NAT.
C'est sale car c'est du NAT derrière du NAT mais c'est vraiment le plus simple et rapide à réaliser. Ton poste pro sera dans son LAN à lui avec son plan IP isolé du LAN.
Normalement le poste pro n'aura pas connaissance du réseau entre les 2 NATs (ton réseau local perso) mais le routeur n'interdira pas forcément le poste pro d'aller taper sur une IP du réseau perso. Comment il connaîtrait les IP du réseau perso ? Potentiellement il pourrait y avoir des fuites entre les 2 réseaux lié à des protocole de signalisation (dns multicast, etc).
Donc si le routeur possède un pare-feu (qui permettrait de n'autoriser l'accès qu'à l'IP de la freebox) c'est quand même un plus.
Pour faire un peu moins sale il faudrait de toute façon un routeur (car la freebox ne permet pas de gérer plusieurs réseaux locaux) et configurer la freebox pour que l'"IP DMZ" pointe vers ce routeur. Ensuite mettre les 2 LANs pro et perso sur deux VLANs derrière le routeur (avec du coup un peu plus de matériel, potentiellement). Mais il y a toujours le double NAT.
Pour s'affranchir du double NAT la solution c'est de remplacer la freebox par un autre routeur qui sait faire des VLANs, ou de configurer la freebox en bridge et mettre le routeur derrière, avec toutes les contraintes que cela implique sur la partie TV.
% host -t MX deloitte.com 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
deloitte.com mail is handled by 100 mx2.deloitte.iphmx.com.
deloitte.com mail is handled by 100 mx1.deloitte.iphmx.com.
% host mx1.deloitte.iphmx.com. 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
mx1.deloitte.iphmx.com has address (une longue liste d'ip)
% host mx2.deloitte.iphmx.com. 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
mx2.deloitte.iphmx.com has address (une longue liste d'ip)
D'ailleurs tu as fais une coquille dans ce que tu as tapé, tu as oublié un "t" dans le nom du domaine.
Mais depuis 8.8.8.8 les résultats sont cohérents techniquement, donc je ne vois pas pourquoi ton postfix aurait des difficultés à trouver le record du MX sachant qu'il existe.
Il serait intéressant de regarder ces pistes de manière pas forcément exclusive :
- log debug de postfix (mais pas certain qu'on y trouve quelque chose puisque postfix doit surement faire appel à la libc pour résoudre les noms)
- toucher au resolv.conf et ne mettre que le 8.8.8.8 (nameserver 8.8.8.8), c'est pas bien mais c'est pour le test, redémarrer postfix et retenter d'envoyer un mail
- plus bourrin, : écouter le trafic réseau (avec par ex tcpdump) et voir ce qui se passe au moment où postfix reçoit le mail à envoyer (est-ce qu'il essaye de résoudre le nom, vers quel serveur, c'est quoi le résultat ; DNS n'est pas chiffré), il y aura surement du tri à faire dans la capture avant de trouver le moment intéressant (et ce qui concerne postfix)
;; ANSWER SECTION:
main.linuxfr.org. 671 IN A 213.36.253.175
Ici on voit qu'il y a un type A.
Vérifie que dans ton cas c'est bien un record de type A et pas CNAME.
La RFC 2181 est très claire :
10.3. MX and NS records
The domain name used as the value of a NS resource record, or part of
the value of a MX resource record must not be an alias. Not only is
the specification clear on this point, but using an alias in either
of these positions neither works as well as might be hoped, nor well
fulfills the ambition that may have led to this approach. This
domain name must have as its value one or more address records.
Currently those will be A records, however in the future other record
types giving addressing information may be acceptable. It can also
have other RRs, but never a CNAME RR.
Un MX ne peut pas pointer vers un record CNAME. Seulement A et AAAA.
Si c'est un CNAME qui est retourné, c'est que le domaine que tu essaye de joindre est mal configuré, il ne respecte pas la RFC. Ne t'attends pas à ce que ça marche avec Postfix. Si ça marche avec gmail c'est qu'ils ne respectent pas la RFC non plus.
avril 15 10:30:32 systemd[1]: ssh.service: Main process exited, code=killed, status=9/KILL
avril 15 10:30:32 systemd[1]: ssh.service: Failed with result 'signal'.
avril 15 10:30:32 systemd[1]: ssh.service: Service RestartSec=100ms expired, scheduling restart.
avril 15 10:30:32 systemd[1]: ssh.service: Scheduled restart job, restart counter is at 1.
Le premier truc bizarre, c'est que sshd est tué violemment (SIGKILL). Cela ne devrait pas arriver naturellement. Peut-être un problème de pas assez de mémoire ?
Je te suggère d'aller vérifier dans le journal ce qui se passe autour de 10:30:32.
Le second truc bizarre c'est que tu sembles arriver à démarrer ssh à la main, mais avec l'unit de systemd cela ne fonctionne pas. C'est la même configuration utilisée entre le démarrage à la main et le démarrage via systemd (tu peux aller voir le fichier unit ssh.service ce qu'il y a dedans et lancer la même commande, normalement tu devrais avoir le même résultat). Cela pourrait potentiellement venir d'un problème de droit sur tes clefs.
Ce que tu vois c'est l'invite de commande (prompt). Il peut ressembler à ce que l'on veut. Par défaut il est souvent de la forme "utilisateur_courant@nom_de_l'ordinateur:dossier_courant$".
Le "Kali" correspond à priori au nom de ton système (hostname), je suppose que tu as installé Kali Linux et laissé la valeur par défaut. On peut changer cela sans réinstaller le système.
Si tu vois l'invite c'est bon signe car tu peux entrer des commandes (tu peux essayer des commandes basiques inoffensives comme ls ou pwd).
Si j'ai bien compris (parce que je fais autre chose en même temps)…
Tu consomme les ressources d'une machine hébergeant un site, qui seront en moins pour les utilisateurs dudit site.
Le "problème" peut être vu par certains : "pourquoi moi propriétaire du site A je payerais de la bande passante, du CPU et du disque pour les utilisateurs d'un site B qui affichent mon contenu ?"
Effectivement, si le site A n'a pas beaucoup de ressources et que le site B est très fréquenté, tu peux utiliser toutes les ressources du serveur du site A et pénaliser les utilisateurs du site A.
Le phénomène n'est pas nouveau, je dirais que ça a toujours existé, ça s'appelle du hotlinking.
J'ai vu les premières contremesures apparaître avec les gros sites pour héberger des images (à l'époque un des plus connus était ImageShack). Elle consistait à afficher une image différente (avec écrit en gros "hotlinking forbidden" dessus) si on procédait au hotlink de l'image. C'était facilement fait en contrôlant le champ Referer du navigateur effectuant la requête. Si le Referer présentait un domaine d'ImageShack, l'image originale était montrée, sinon l'autre.
Cela obligeait les utilisateurs à effectuer un lien hypertexte vers l'image (et donc à passer par le site d'ImageShack avec plein de pub).
Aujourd'hui je crois que j'ai l'impression d'en voir beaucoup moins (de prévention de hotlinking).
Il faut utiliser les fonctions d'acl et de vues (views) de BIND, et créer un fichier de zone par vue (lan et wan) pour déclarer le domaine et l'ip idoine. Ensuite discriminer avec les acl le réseau qui interroge et rediriger vers la bonne vue.
Le serveur DNS doit voir les 2 réseaux.
Et l'adresse IPv6 liée à l'adresse MAC est link local, c'est-à-dire qu'elle n'est pas routée sur Internet, donc pour la sécurité / vie privée on peut l'oublier.
Ce n'est pas la seule qui peut contenir la MAC. L'adresse générée par le nœud dans le cas de l'auto configuration (Stateless Address Autoconfiguration) contient le préfixe annoncé par le routeur et le host identifier peut dériver de l'adresse MAC. Et cette adresse est une adresse routée sur Internet (global unicast).
Il est possible de construire une seconde adresse "global unicast" (qui peut être temporaire) avec un host id aléatoire qui sera taguée "préférée" (et donc qui sera utilisée pour faire sortir les paquets des processus locaux qui ne précisent pas laquelle des deux IP global unicast utiliser).
Quand j'ai affaire à du Seagate j'évite de me fier aux valeurs brutes des Error Rate car elles ne sont pas représentatives et de tous les Seagate que j'ai pu voir passer, j'ai toujours vu des valeurs brutes très élevées sur ces attributs (pour eux je regarde plutôt les valeurs des colonnes du milieu). Pour le Raw_Read_Error_Rate, ça ne semble pas plus inquiétant que ça.
Pour le Seek_Error_Rate la valeur semble assez proche du Thresh et il conviendrait de la surveiller de plus près.
Ce qui me choque plus c'est le nombre de Start_Stop_Count et Power_Cycle_Count comparé au Power_On_Hours, ça ferait en moyenne 28 démarragesdu disque par jour (et démarrage à froid, pas juste la sortie de veille du disque), ça me semble énorme.
Quant au Hardware_ECC_Recovered, ça m'a l'air trop comparé au Power_On_Hours…
J'ai fait une install sans X de debian/sid (c'était il y a un peu plus d'an) sur ma machine pour la même raison que toi (SSD) :-)
J'ai fait le 'apt-get install mate-desktop-environment', qui s'est bien passé.
Par contre, si je me souviens bien, il n'y a pas de DM qui est installé, et comme j'en voulais un j'ai installé xdm. Mais sinon tout a très bien fonctionné, excepté toute la partie de gestion de volumes en utilisateur (montage/démontage de clefs à partir de Caja, gestion des LVM existants depuis Palimpsest, utilisation de LUKS). Ça pourrit un peu le truc. J'ai trouvé des astuces pour y arriver à peu près en éditant le 'org.freedesktop.udisks.policy', mais c'est un peu cochon et ça ne résiste pas à un upgrade.
C'est le seul vrai point noir je trouve.
À présent, ça marche toujours très bien, mais les interfaces gtk3 (leur barre de titre immense) commencent à faire leur arrivée dans certaines applis. C'est toujours utilisable mais c'est pas hyper bien intégré graphiquement (après j'utilise un thème pas forcément des plus récents).
Ce que tu pourrais faire, c'est acheter chez Gandi ton .eu ou .fr et faire héberger ton serveur DNS par quelqu'un qui a une IP fixe.
Si c'est possible, tu pourrais mettre à jour toi-même ta zone sur le serveur DNS du coupain (et en mettant un TTL petit).
Si c'est pas possible, il faudrait voir si Dyndns/no-ip ne pourraient pas reprendre la gestion de ta zone (en gros t'achètes le domaine chez Gandi et tu demande à Dyndns/no-ip de gérer ta zone), mais ça fait des lustres que je n'ai pas utilisé leurs services donc je ne sais pas s'ils permettent de faire ça.
D'ailleurs il semble que je ne suis pas le seul à m'apercevoir du Load_Cycle_Count très élevé/fréquent (d'après Google).
Pour la petite histoire, le disque a fait ses premiers Emask 0x409 (media error) et autres Buffer I/O error aujourd'hui.
Après je ne sais pas si c'est dû au parquage (il n'y a pas de raison que ça le soit), où au fait qu'il ait malencontreusement pris quelques G… :p
Ça je veux bien le croire. Surtout quand la valeur est très supérieure à la moyenne.
Mais si je colle l'oreille, j'entends bien un petit "tac" toutes les cinq secondes, et la valeur SMART est incrémentée de un à chaque fois…
Soit le disque est vraiment hyper costaud, soit je ne sais pas. En tout cas je m'attends à ce qu'il lâche d'un moment à l'autre. J'ai l'impression qu'il a perdu un peu de ses performances d'antan.
Ce qui m'en fait à peu près un toutes les 5 secondes (et on l'entend bien).
Au début j'avais essayé de jouer avec les paramètres du hdparm, mais sans effet.
Depuis j'ai laissé couler, et j'ai jamais eu de problèmes (pour l'instant…)
Pour ceux que ça intéresse, c'est un SAMSUNG HM500JI.
Non tu ne pourras pas utiliser LVM sur une partition qui contient déjà des données. Il va falloir typer ta partition comme LVM (mais ça, c'est pas critique), et ensuite effectuer la création de ton volume physique LVM. Ça par contre, ça va tout effacer.
En revanche tu peux tenter un truc : défragmenter et réduire ta partition au max et créer une partition/volume LVM juste à côté. Quand tu auras créé ton lecteur logique tu pourras aller transvaser les données de ta première partition vers ton LVM. Suivant la place qu'il te reste sur le LVM, tu vas devoir soit :
- espace libre < occupé : redéfragmenter/réduire ta partition de backup, recréer un LVM dessus et augmenter ton LVM déjà créé, et recommencer le transvasage. Ok c'est un peu crade ;)
- espace libre > occupé : supprimer ta partition initiale (qui doit être vide) et en faire un LVM, augmenter ton LM déjà existant.
À mon avis, ça ne posera pas de problème (du moins directement), d'après la doc d'Apache en tout cas (cf. la doc sur la directive Allow)
Allow from example.org
Allow from .net example.edu
Hosts whose names match, or end in, this string are allowed access. Only complete components are matched, so the above example will match foo.example.org but it will not match fooexample.org. This configuration will cause Apache httpd to perform a double DNS lookup on the client IP address, regardless of the setting of the HostnameLookups directive. It will do a reverse DNS lookup on the IP address to find the associated hostname, and then do a forward lookup on the hostname to assure that it matches the original IP address. Only if the forward and reverse DNS are consistent and the hostname matches will access be allowed.
Ça veut dire que pour un
Allow from localhost
Apache va faire un lookup sur l'ip qui arrive (qui va donner localhost dans ton cas) et va ensuite faire un lookup sur localhost (ils précisent DNS, mais je ne sais pas si c'est via la libc) qui devrait donner 127.0.0.1 d'après hosts. Vu que 127.0.0.1 ne matche pas l'ip source, il ne devrait pas autoriser l'accès.
Par contre il reste un problème je pense si le hosts est tout pourri (mais bon là faut chercher les coups :P) ou si le DNS en face est tout pourri et qu'il répond que localhost est l'ip entrante et que nsswitch donne la priorité au DNS…
[^] # Re: Firefox a eu sa chance par le public
Posté par Thibault (site web personnel) . En réponse au journal Hégémonie et navigateurs. Évalué à 0.
Il y a eu Firebird entre Phoenix et Firefox :(
[^] # Re: Dans le doute...
Posté par Thibault (site web personnel) . En réponse au message Cadre légal d'accès à un poste en Télétravail. Évalué à 4. Dernière modification le 20 juin 2020 à 20:10.
Oui elle a le droit de faire du SSH vers ton poste pro. S'il ne t'appartient pas il est en plus probablement infogéré et peut-être que dans ton cas cela se fait par SSH. De plus je ne suis pas certain que toi tu aies le droit de bloquer ces connexions et cela pourrait se retourner contre toi, surtout si cela est utilisé pour déployer des mises à jour sur le poste.
Par contre elle doit respecter les lois, notamment elle ne peut pas accéder aux données identifiées comme personnelles sur le poste de son initiative. Concernant l'espionnage de l'utilisateur je ne sais pas ce que dit la loi. Si elle n'a pas le droit tu peux te retourner contre la société. Si elle a le droit et que cela est contraire à ton éthique malheureusement la seule solution ça va être de changer de boîte, pour une qui n'espionne pas ses utilisateurs.
[^] # Re: Dans le doute...
Posté par Thibault (site web personnel) . En réponse au message Cadre légal d'accès à un poste en Télétravail. Évalué à 5. Dernière modification le 20 juin 2020 à 20:01.
Ce n'est pas une histoire que la DSI soit bienveillante ou pas. Évidemment qu'elle est "bienveillante" (dans le sens où elle n'ira pas à l'encontre des lois) sinon elle va se faire défoncer.
Dans le cas du télétravail c'est une histoire que "je met une machine qui ne m'appartient pas sur mon réseau", what could possibly go wrong? Bah deux choses, ton réseau local peut être pourri et va peut-être essayer d'attaquer ta machine de travail (mais ça c'est la responsabilité de l'entreprise de sécuriser sa machine).
Également la DSI, avec ses responsables SI consciencieux et très prudents, n'est pas infaillible. Ton réseau local peut être attaqué par la machine sur laquelle tu n'a pas la main et donc il faut protéger ton réseau contre les potentielles tentatives d'intrusions de la part ces machines qui se connectent chez toi. C'est des règles cyber de base (là où je travaille en tout cas) et il y a des artifices simples pour le faire (réseaux séparés/réseau invité, isolation WiFi, firewall, etc).
Mettre une machine qu'on ne contrôle pas sur son réseau, c'est un cheval de troie potentiel. J'ai surement confiance en ma DSI pour qu'elle prenne toutes les précautions nécessaires pour qu'une intrusion n'arrive jamais, le risque est toujours là. Le jour où cela arrivera, je n'aurai plus confiance en ma DSI mais au moins mon réseau local personnel aura été protégé contre l'intrusion. C'est préventif.
[^] # Re: Séparation réseau ?
Posté par Thibault (site web personnel) . En réponse au message Cadre légal d'accès à un poste en Télétravail. Évalué à 3.
À moduler avec la version de la freebox bien entendu, la dernière freebox que j'ai connu c'est la v5 ;)
Le réseau invité de la freebox je ne sais pas comment il fonctionne. Sinon pour le premier point il faudra de toute façon un routeur car la freebox ne gère pas les VLANs sur le LAN (du moins ne permet pas de gérer les VLANs sur le LAN client).
Si tu n'as pas de matériel le plus simple et le moins cher c'est de te procurer un petit routeur avec port WAN et LAN ethernet (qui en sus peut aussi faire AP wifi).
Il suffira de connecter le port WAN sur ton LAN et de t'assurer que le nouveau routeur fait du NAT.
C'est sale car c'est du NAT derrière du NAT mais c'est vraiment le plus simple et rapide à réaliser. Ton poste pro sera dans son LAN à lui avec son plan IP isolé du LAN.
Normalement le poste pro n'aura pas connaissance du réseau entre les 2 NATs (ton réseau local perso) mais le routeur n'interdira pas forcément le poste pro d'aller taper sur une IP du réseau perso. Comment il connaîtrait les IP du réseau perso ? Potentiellement il pourrait y avoir des fuites entre les 2 réseaux lié à des protocole de signalisation (dns multicast, etc).
Donc si le routeur possède un pare-feu (qui permettrait de n'autoriser l'accès qu'à l'IP de la freebox) c'est quand même un plus.
Pour faire un peu moins sale il faudrait de toute façon un routeur (car la freebox ne permet pas de gérer plusieurs réseaux locaux) et configurer la freebox pour que l'"IP DMZ" pointe vers ce routeur. Ensuite mettre les 2 LANs pro et perso sur deux VLANs derrière le routeur (avec du coup un peu plus de matériel, potentiellement). Mais il y a toujours le double NAT.
Pour s'affranchir du double NAT la solution c'est de remplacer la freebox par un autre routeur qui sait faire des VLANs, ou de configurer la freebox en bridge et mettre le routeur derrière, avec toutes les contraintes que cela implique sur la partie TV.
[^] # Re: Config DNS
Posté par Thibault (site web personnel) . En réponse au message Soucis avec un seul domaine de destination sur postfix. Évalué à 1.
"Chez moi ça marche"™
D'ailleurs tu as fais une coquille dans ce que tu as tapé, tu as oublié un "t" dans le nom du domaine.
Mais depuis 8.8.8.8 les résultats sont cohérents techniquement, donc je ne vois pas pourquoi ton postfix aurait des difficultés à trouver le record du MX sachant qu'il existe.
Il serait intéressant de regarder ces pistes de manière pas forcément exclusive :
- log debug de postfix (mais pas certain qu'on y trouve quelque chose puisque postfix doit surement faire appel à la libc pour résoudre les noms)
- toucher au resolv.conf et ne mettre que le 8.8.8.8 (nameserver 8.8.8.8), c'est pas bien mais c'est pour le test, redémarrer postfix et retenter d'envoyer un mail
- plus bourrin, : écouter le trafic réseau (avec par ex tcpdump) et voir ce qui se passe au moment où postfix reçoit le mail à envoyer (est-ce qu'il essaye de résoudre le nom, vers quel serveur, c'est quoi le résultat ; DNS n'est pas chiffré), il y aura surement du tri à faire dans la capture avant de trouver le moment intéressant (et ce qui concerne postfix)
Bon chance
# Config DNS
Posté par Thibault (site web personnel) . En réponse au message Soucis avec un seul domaine de destination sur postfix. Évalué à 1.
Vérifie les choses suivantes :
- la valeur du record MX du domaine (par ex pour linuxfr.org)
Ici on voit qu'il y a un type A.
Vérifie que dans ton cas c'est bien un record de type A et pas CNAME.
La RFC 2181 est très claire :
10.3. MX and NS records
The domain name used as the value of a NS resource record, or part of
the value of a MX resource record must not be an alias. Not only is
the specification clear on this point, but using an alias in either
of these positions neither works as well as might be hoped, nor well
fulfills the ambition that may have led to this approach. This
domain name must have as its value one or more address records.
Currently those will be A records, however in the future other record
types giving addressing information may be acceptable. It can also
have other RRs, but never a CNAME RR.
Un MX ne peut pas pointer vers un record CNAME. Seulement A et AAAA.
Si c'est un CNAME qui est retourné, c'est que le domaine que tu essaye de joindre est mal configuré, il ne respecte pas la RFC. Ne t'attends pas à ce que ça marche avec Postfix. Si ça marche avec gmail c'est qu'ils ne respectent pas la RFC non plus.
[^] # Re: Logs?
Posté par Thibault (site web personnel) . En réponse au message Le serveur ssh plante après 20 minutes (debian). Évalué à 1.
Salut,
Le premier truc bizarre, c'est que sshd est tué violemment (SIGKILL). Cela ne devrait pas arriver naturellement. Peut-être un problème de pas assez de mémoire ?
Je te suggère d'aller vérifier dans le journal ce qui se passe autour de 10:30:32.
Le second truc bizarre c'est que tu sembles arriver à démarrer ssh à la main, mais avec l'unit de systemd cela ne fonctionne pas. C'est la même configuration utilisée entre le démarrage à la main et le démarrage via systemd (tu peux aller voir le fichier unit ssh.service ce qu'il y a dedans et lancer la même commande, normalement tu devrais avoir le même résultat). Cela pourrait potentiellement venir d'un problème de droit sur tes clefs.
Bon courage.
# C'est facile
Posté par Thibault (site web personnel) . En réponse au message information sur le terminal. Évalué à 4.
Ce que tu vois c'est l'invite de commande (prompt). Il peut ressembler à ce que l'on veut. Par défaut il est souvent de la forme "utilisateur_courant@nom_de_l'ordinateur:dossier_courant$".
Le "Kali" correspond à priori au nom de ton système (hostname), je suppose que tu as installé Kali Linux et laissé la valeur par défaut. On peut changer cela sans réinstaller le système.
Si tu vois l'invite c'est bon signe car tu peux entrer des commandes (tu peux essayer des commandes basiques inoffensives comme ls ou pwd).
[^] # Re: Auto-hébergement
Posté par Thibault (site web personnel) . En réponse au journal Bye bye définitif au fameux 29,99 €/mois. Évalué à 0.
Pas que : sur l'infra IPv6 native Free, du coup fibre + les nouveaux dslam avec abonnés adsl "1/4 de ports"
[^] # Re: toi meme
Posté par Thibault (site web personnel) . En réponse au message hébergeur image gratuit sans tracking. Évalué à 2.
Si j'ai bien compris (parce que je fais autre chose en même temps)…
Tu consomme les ressources d'une machine hébergeant un site, qui seront en moins pour les utilisateurs dudit site.
Le "problème" peut être vu par certains : "pourquoi moi propriétaire du site A je payerais de la bande passante, du CPU et du disque pour les utilisateurs d'un site B qui affichent mon contenu ?"
Effectivement, si le site A n'a pas beaucoup de ressources et que le site B est très fréquenté, tu peux utiliser toutes les ressources du serveur du site A et pénaliser les utilisateurs du site A.
Le phénomène n'est pas nouveau, je dirais que ça a toujours existé, ça s'appelle du hotlinking.
J'ai vu les premières contremesures apparaître avec les gros sites pour héberger des images (à l'époque un des plus connus était ImageShack). Elle consistait à afficher une image différente (avec écrit en gros "hotlinking forbidden" dessus) si on procédait au hotlink de l'image. C'était facilement fait en contrôlant le champ Referer du navigateur effectuant la requête. Si le Referer présentait un domaine d'ImageShack, l'image originale était montrée, sinon l'autre.
Cela obligeait les utilisateurs à effectuer un lien hypertexte vers l'image (et donc à passer par le site d'ImageShack avec plein de pub).
Aujourd'hui je crois que j'ai l'impression d'en voir beaucoup moins (de prévention de hotlinking).
# acl, views
Posté par Thibault (site web personnel) . En réponse au message Dns, ajouter un domaine avec un point. Évalué à 8.
Il faut utiliser les fonctions d'acl et de vues (views) de BIND, et créer un fichier de zone par vue (lan et wan) pour déclarer le domaine et l'ip idoine. Ensuite discriminer avec les acl le réseau qui interroge et rediriger vers la bonne vue.
Le serveur DNS doit voir les 2 réseaux.
# TapTempo
Posté par Thibault (site web personnel) . En réponse au message Logiciel pour calculer le nombre de frappe par minute.. Évalué à -10.
Genre.. Ça ? https://linuxfr.org/users/mzf/journaux/un-tap-tempo-en-ligne-de-commande
[^] # Re: Tu as l'air à jour
Posté par Thibault (site web personnel) . En réponse au message [Question] Update Debian. Évalué à 2.
Oups je m'ai trompé. J'avais lu un peu vite et pas vu le 30 != 65…
# Tu as l'air à jour
Posté par Thibault (site web personnel) . En réponse au message [Question] Update Debian. Évalué à 1.
Si tu es en 4.9.30-2+deb9u3, tu as la dernière version (cf. https://packages.debian.org/stretch/linux-image-amd64)
Meltdown est mitigé dans Stretch uniquement pour l'instant, apporté par 4.9.30-2+deb9u2.
Spectre n'est pas encore mitigé, cf. https://security-tracker.debian.org/tracker/source-package/linux
[^] # Re: Contrôle des IPs internes
Posté par Thibault (site web personnel) . En réponse au sondage Utilisez-vous IPv6 ?. Évalué à 2.
Ce n'est pas la seule qui peut contenir la MAC. L'adresse générée par le nœud dans le cas de l'auto configuration (Stateless Address Autoconfiguration) contient le préfixe annoncé par le routeur et le host identifier peut dériver de l'adresse MAC. Et cette adresse est une adresse routée sur Internet (global unicast).
Il est possible de construire une seconde adresse "global unicast" (qui peut être temporaire) avec un host id aléatoire qui sera taguée "préférée" (et donc qui sera utilisée pour faire sortir les paquets des processus locaux qui ne précisent pas laquelle des deux IP global unicast utiliser).
[^] # Re: Command not found
Posté par Thibault (site web personnel) . En réponse au journal S'amuser avec sl (si si). Évalué à 2.
Très probablement : https://packages.debian.org/sid/command-not-found
[^] # Re: Par habitude
Posté par Thibault (site web personnel) . En réponse au message Dans la série des disques qui semblent rendre l'ame .... Évalué à 3.
Quand j'ai affaire à du Seagate j'évite de me fier aux valeurs brutes des Error Rate car elles ne sont pas représentatives et de tous les Seagate que j'ai pu voir passer, j'ai toujours vu des valeurs brutes très élevées sur ces attributs (pour eux je regarde plutôt les valeurs des colonnes du milieu). Pour le Raw_Read_Error_Rate, ça ne semble pas plus inquiétant que ça.
Pour le Seek_Error_Rate la valeur semble assez proche du Thresh et il conviendrait de la surveiller de plus près.
Ce qui me choque plus c'est le nombre de Start_Stop_Count et Power_Cycle_Count comparé au Power_On_Hours, ça ferait en moyenne 28 démarragesdu disque par jour (et démarrage à froid, pas juste la sortie de veille du disque), ça me semble énorme.
Quant au Hardware_ECC_Recovered, ça m'a l'air trop comparé au Power_On_Hours…
Je dirais que ton disque est en train de mourir.
# Plutôt bien
Posté par Thibault (site web personnel) . En réponse au message Question sur MATE. Évalué à 2.
J'ai fait une install sans X de debian/sid (c'était il y a un peu plus d'an) sur ma machine pour la même raison que toi (SSD) :-)
J'ai fait le 'apt-get install mate-desktop-environment', qui s'est bien passé.
Par contre, si je me souviens bien, il n'y a pas de DM qui est installé, et comme j'en voulais un j'ai installé xdm. Mais sinon tout a très bien fonctionné, excepté toute la partie de gestion de volumes en utilisateur (montage/démontage de clefs à partir de Caja, gestion des LVM existants depuis Palimpsest, utilisation de LUKS). Ça pourrit un peu le truc. J'ai trouvé des astuces pour y arriver à peu près en éditant le 'org.freedesktop.udisks.policy', mais c'est un peu cochon et ça ne résiste pas à un upgrade.
C'est le seul vrai point noir je trouve.
À présent, ça marche toujours très bien, mais les interfaces gtk3 (leur barre de titre immense) commencent à faire leur arrivée dans certaines applis. C'est toujours utilisable mais c'est pas hyper bien intégré graphiquement (après j'utilise un thème pas forcément des plus récents).
[^] # Re: une idée
Posté par Thibault (site web personnel) . En réponse au message Les hard links. Évalué à 4.
Et dans les ténèbres les lier.
Désolé :]
# Serveur DNS perso
Posté par Thibault (site web personnel) . En réponse au message Register .eu/.fr avec IP dynamique. Évalué à 2.
Salut,
Ce que tu pourrais faire, c'est acheter chez Gandi ton .eu ou .fr et faire héberger ton serveur DNS par quelqu'un qui a une IP fixe.
Si c'est possible, tu pourrais mettre à jour toi-même ta zone sur le serveur DNS du coupain (et en mettant un TTL petit).
Si c'est pas possible, il faudrait voir si Dyndns/no-ip ne pourraient pas reprendre la gestion de ta zone (en gros t'achètes le domaine chez Gandi et tu demande à Dyndns/no-ip de gérer ta zone), mais ça fait des lustres que je n'ai pas utilisé leurs services donc je ne sais pas s'ils permettent de faire ça.
[^] # Re: Moi aussi je peux jouer ?
Posté par Thibault (site web personnel) . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 2.
Non, c'est un Samsung HM500JI.
D'ailleurs il semble que je ne suis pas le seul à m'apercevoir du
Load_Cycle_Counttrès élevé/fréquent (d'après Google).Pour la petite histoire, le disque a fait ses premiers
Emask 0x409 (media error)et autresBuffer I/O erroraujourd'hui.Après je ne sais pas si c'est dû au parquage (il n'y a pas de raison que ça le soit), où au fait qu'il ait malencontreusement pris quelques G… :p
[^] # Re: Moi aussi je peux jouer ?
Posté par Thibault (site web personnel) . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 1.
Ça je veux bien le croire. Surtout quand la valeur est très supérieure à la moyenne.
Mais si je colle l'oreille, j'entends bien un petit "tac" toutes les cinq secondes, et la valeur SMART est incrémentée de un à chaque fois…
Soit le disque est vraiment hyper costaud, soit je ne sais pas. En tout cas je m'attends à ce qu'il lâche d'un moment à l'autre. J'ai l'impression qu'il a perdu un peu de ses performances d'antan.
# Moi aussi je peux jouer ?
Posté par Thibault (site web personnel) . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 4.
On gagne quoi ? :)
Ce qui m'en fait à peu près un toutes les 5 secondes (et on l'entend bien).
Au début j'avais essayé de jouer avec les paramètres du hdparm, mais sans effet.
Depuis j'ai laissé couler, et j'ai jamais eu de problèmes (pour l'instant…)
Pour ceux que ça intéresse, c'est un SAMSUNG HM500JI.
# Non
Posté par Thibault (site web personnel) . En réponse au message Une partition sur deux disques ?. Évalué à 2.
Salut,
Non tu ne pourras pas utiliser LVM sur une partition qui contient déjà des données. Il va falloir typer ta partition comme LVM (mais ça, c'est pas critique), et ensuite effectuer la création de ton volume physique LVM. Ça par contre, ça va tout effacer.
En revanche tu peux tenter un truc : défragmenter et réduire ta partition au max et créer une partition/volume LVM juste à côté. Quand tu auras créé ton lecteur logique tu pourras aller transvaser les données de ta première partition vers ton LVM. Suivant la place qu'il te reste sur le LVM, tu vas devoir soit :
- espace libre < occupé : redéfragmenter/réduire ta partition de backup, recréer un LVM dessus et augmenter ton LVM déjà créé, et recommencer le transvasage. Ok c'est un peu crade ;)
- espace libre > occupé : supprimer ta partition initiale (qui doit être vide) et en faire un LVM, augmenter ton LM déjà existant.
# Je pense pas
Posté par Thibault (site web personnel) . En réponse au message Etranges résolutions DNS venant du Vietnam. Évalué à 3.
À mon avis, ça ne posera pas de problème (du moins directement), d'après la doc d'Apache en tout cas (cf. la doc sur la directive Allow)
Ça veut dire que pour un
Apache va faire un lookup sur l'ip qui arrive (qui va donner localhost dans ton cas) et va ensuite faire un lookup sur localhost (ils précisent DNS, mais je ne sais pas si c'est via la libc) qui devrait donner 127.0.0.1 d'après hosts. Vu que 127.0.0.1 ne matche pas l'ip source, il ne devrait pas autoriser l'accès.
Par contre il reste un problème je pense si le hosts est tout pourri (mais bon là faut chercher les coups :P) ou si le DNS en face est tout pourri et qu'il répond que localhost est l'ip entrante et que nsswitch donne la priorité au DNS…