NeoX a écrit 18155 commentaires

le truc qui me vient à l'esprit c'est l'autologin

c'est un réglage qui permet de se logeur automatiquement sur le compte d'un utilisateur
hélas quand on change de mot de passe, l'autologin ne se met pas à jour, et ca plante la machine.

je doute que ce soit ca, mais ca se tente.

une autre piste, c'est de démarrer en mode rescue,
en gros au démarrage quand il te demande de choisir sur quoi démarrer, il faut éditer la ligne de grub, virer les "splash quiet" et mettre "single"

ca permet souvent de démarrer en mode texte, pour revenir en arrière sur une modification, sauvegarder un truc.

et au pire, une fois sauvegarder (depuis un système sur clef USB)
tu pourras reinstaller.

c'est formateur aussi ;)

ne le prend pas mal, mais tu veux utiliser KALI, une distribution pour faire des tests de penetrations reseaux (hacking reseau)

et tu ne sais pas lire un fichier en ligne de commande ?

quand le système te dis que le fichier contenant les résultats se trouve dans /boot.log
il faut ouvrir ce fichier pour voir son contenu.

par exemple avec vi ou nano ou emacs selon ce qui est dispo dans la distribution ou dans le busybox sur lequel tu viens d'arriver.

vi /boot.log

te permettra de voir le contenu, de le photographier si besoin.

Autre piste, plutôt que liveUSB, pourquoi ne pas d'abord tester et se roder avec une machine virtuelle.

ainsi tu gardes ton OS de depart, sur lequel tu as tes habitudes, et tu peux installer autant d'OS que tu veux pour apprendre dans des PCs virtuels, que tu peux planter sans perdre l'usage de ta machine.

Virtualbox : https://www.virtualbox.org est un bon debut

parfois c'est l'outil qui convertit mal l'ISO vers l'USB
tu peux essayer avec un autre outil que Rufus

• balenaetcher : https://www.balena.io/etcher/?ref=etcher_menu
• unetbootin : https://unetbootin.github.io

par contre je ne sais pas s'ils permettent d'activer la persistence

C'est ce que j'avais compris quand tu disais :
si tu vas en ligne de commande, tu devrais voir vers quoi ca pointe
chez moi c'est dans /etc/systemd/

oui, sauf que j'étais dans /etc/systemd

pour le dossier /run/systemd/units
a priori j'ai un comportement similaire à chez toi

root@machine:/run/systemd/units# find -type l -iname '*.service' -exec ls -l {} \;
[...]
lrwxrwxrwx 1 root root 32 Mar 30 15:50 invocation:watchdog-mux.service -> 7c18329706af4265a18ccde93d808818

root@machine:/run/systemd/units# ls -l 7c18329*
ls: cannot access '7c18329*': No such file or directory

root@machine:/run/systemd/units# ls -l 7c18329706af4265a18ccde93d808818
ls: cannot access '7c18329706af4265a18ccde93d808818': No such file or directory

et pourtant ma machine fonctionne parfaitement.

c'est un serveur, je n'ai pas d'interface graphique pour tester l'affichage de ces units

dd if=/dev/sdXYlacarte of=tonfichiersauvegarde.raw

ca va te faire un backup complet de la carte

tu peux alors agir sur celle-ci
et si besoin, revenir à l'état de depart en faisant l'inverse

dd if=tonfichiersauvegarde.raw of=/dev/sdXYlacarte

ben regarde les correcteurs aspell, gramalect, etc
ca m'étonnerait que tout se fasse en ligne.

ca veut dire qu'il y a bien le système d'amorce (GRUB/isolinux)
mais que ce dernier ne semble pas trouver le reste du système.

• ta machine est bien 64bits ?
• ta clef USB est bien suffisante pour mettre l'ISO ET la persistence ?

En résumé :
les liens brisés sont dans /run/systemd/units
ls -la montre qu'ils pointent des des iD numériques en rouge
Ces cibles n'existent pas, vérification est faite ci-dessus.

NON

tu as regardé dans le dossier /run/systemd/units pour savoir ou vont les liens

mais avec la commande

mia@mia-PC5:~$ ls -l 51decb4502cd4092a0a39913687eb20b

tu as fait le ls -l dans TON dossier (~), pas dans le /runt/systemd/units

donc il faut verifier si 51dec…. existe DANS le dossier /run/systemd/units

soit en faisant ls -l /run/systemd/units/51decb4502cd4092a0a39913687eb20b
soit en faisant

cd /run/systemd/units
ls -l 51decb4502cd4092a0a39913687eb20b

Tandis que chez toi ils pointent vers /etc/systemd, ce qui est confirmé avec la commande find /etc/systemd/ -iname *.service -exec ls -l {} \;

non il ne pointe pas vers /etc/systemd
ma commande cherche les fichiers services dans le dossier /etc/systemd
et il en trouve, mais qui pointe vers /lib/systemd…

suffit de tester,

la recursion sur OFF, ca ne fonctionnait, pas.
tu l'as mise sur ON et ca marche

commente la partie forwarder, tu verras bien si ca fonctionne toujours ou s'il faut les 2 :p

tu melanges tout.

tu regardes dans /etc/systemd/
qui te dis que le service se trouve dans /lib/systemd/…

puis tu vas lire dans /run/systemd…

ca n'a aucun sens.

tu as les fichiers de config dans /etc/systemd qui sont des liens vers /lib/systemd
et sont OK

tu as ensuite des fichiers d'executions dans /run/systemd
c'est là que tes liens apparaissent comme brisés.

c'est là qu'il faut investiguer.

mia@mia-PC5:/run/systemd/units$

lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:wpa_supplicant.service -> 51decb4502cd4092a0a39913687eb20b

le ls -l invocation:wpa_supplicant.service te dis que c'est un lien vers ** 51decb4502cd4092a0a39913687eb20b**

c'est en rouge parfois clignotant, ce que veut dire que 51decb4502cd4092a0a39913687eb20b n'existe pas

ls -l 51decb4502cd4092a0a39913687eb20b permettra de savoir s'il existe réellement ou non ou si ca renvoie encore ailleurs.

Désolée pour les balises code, ça ne se met pas comme je veux :/

il faut preciser le langage

exemple

```sh
ton collage ici
```

dans run/systemd/units les liens ont l'air de pointé dans le meme dossier.

prends en un (wpa_supplicant) et regarde si sa cible est bien dans ce dossier ?

lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:wpa_supplicant.service -> 51decb4502cd4092a0a39913687eb20b

donc là tu me montres le /etc/system
mais ton problème serait dans le /run/systemd

il faut donc faire la meme commande dans le /run/systemd

si tu le fait à la main, les couleurs peuvent avoir une importance
exemple la partie droite de la flèche sera rouge si la destination n'existe pas

comme c'est dans le dossier /run, c'est ce qui est actuellement actif
c'est alors etrange que les liens soient "brisés"

Peut-être ce message d'erreur (le seul) au démarrage :
"Raise network interface Failed"

il n'arrive pas à activer la carte reseau
à tout hasard, tes liens pointeraient pas sur le reseau ?

sinon c'est louche tes liens vers des IDs totalement numeriques

comme si tu avais chiffrés les fichiers

pour que l'isolation des bruits extérieurs fonctionne, il faut au moins 2 micros
1 pour capter ta voix (celui de devant, en bas)
1 (les autres, souvent derriere ou éloignés du principale) pour capter les bruits environnants, et les annuler par traitement numériques/electroniques.

regarde dans les specs du Fairphone combien il a de micros
essaie aussi avec d'autres logiciels voir si tu as les memes symptômes

l'echo vient généralement du fait que ton micro capte et renvoi le contenu de la reunion,
ca peut meme partir en Larsen (sifflement)

ca disparait si tu coupes le micro, si tu baisses le son,
ou simplement si tu écoutes avec les écouteurs

Je n'ai pas le souvenir qu'on m'est demandé d'installer GRUB, mais je dois avouer que je me souviens pas de tout, ca fait des jours que je suis dessus!!

suffit de relancer l'installation et de faire attention à ce que dit la machine avant de cliquer sur "suivant"

c'est vers la fin en general

les liens pointent quelques part

si tu vas en ligne de commande, tu devrais voir vers quoi ca pointe

chez moi c'est dans /etc/systemd/
il y a des sous dossier, et dedans des fichiers xxxx.service

ainsi avec la commande
find /etc/systemd/ -iname *.service -exec ls -l {} \;

on y voit par exemple

[...]
lrwxrwxrwx 1 root root 39 Jan  6  2019 ./system/multi-user.target.wants/openvswitch.service -> /lib/systemd/system/openvswitch.service
lrwxrwxrwx 1 root root 34 Nov 10  2018 ./system/multi-user.target.wants/smartd.service -> /lib/systemd/system/smartd.service
[...]
lrwxrwxrwx 1 root root 32 Nov 10  2018 ./system/multi-user.target.wants/cron.service -> /lib/systemd/system/cron.service

que le dernier lien /etc/systemd/system/multi-user.target.wants/cron.service
est en réalité /lib/systemd/system/cron.service

donc si cet destination n'existe plus, le lien est brisé

Y aurait pas un moyen avec juste un .htaccess

vu que ca reste un accès web, je dirais que oui

Je ne vois pas pourquoi Jayce a été moinsé

il semble qu'il faille ajouté une surcouche pour qu'il y ait une interface d'authentification, et c'est documenter dans le lien.

j'ai eu un souci du meme genre une fois, c'était une clef trop petit (de pas grand chose) genre clef de 4Go pour une image de 4.1Go

le Rufus/dd/windd/balena me disait que c'était OK
mais les partitions étaient pas toutes là

le système boot alors (le GRUB), puis se plante car il ne trouve pas le système.

le navigateur devrait te dire que le certificat présenté n'est pas celui pour le domaine demandé

enfin firefox le fait après avoir cliquer sur "en savoir plus" ou afficher le detail
sinon en effet, il te dit juste que c'est pas "sécurisé"

cpuid me donne des résultats peut convaincant qui ratissent large :

processor type = primary processor (0)
family = Intel Pentium Pro/II/III/Celeron/Core/Core 2/Atom, AMD Athlon/Duron, Cyrix M2, VIA C3 (6)
model = 0xd (13)
stepping id = 0x2 (2)
extended family = 0x0 (0)
extended model = 0x2 (2)
(simple synth) = Intel Core i7-3800/3900 (Sandy Bridge-E) / Xeon E5-1600/2600/4600 (Sandy Bridge-E), 32nm

le model ne semble plus être 45 mais 13 :/

bref on tourne autour, mais on n'avance pas :p

ton certificat est mis où ?

est-il complet ?
dans la documentation il est bien dit qu'après obtention par letsencrypt, il faut concatènera la clef, le certificat et la CA dans un SEUL fichier.

c'est ensuite ce fichier que tu donnes à haproxy dans le fichier de configuration

alors, tu parles de NGINX mais tu veux mettre en place ton letsencrypt sur un haproxy

ton problème pourrait venir de là.

dans la logique des choses, tu devrais avoir

                                     | -> machine privée A, IP A, nginx
IP publique -> haproxy + letsencrypt |--> machine privée B, IP B, nginx
                                     |-> machine privée A, IP A, nginx

le paquet arrive sur le haproxy, decode le debut du ssl (SNI), puis selon le domaine, sélectionne le bon certificat, puis envoie le reste de la requête au bon serveur sur le réseau privé

et dans tes precedents posts, tu sembles vouloir mettre haproxy ET nginx sur la meme machine.

tu sais que nginx sait gérer le multidomaine et le ssl tout seul ?

tu as definit un bloc allow-recursion

mais si tu n'as rien changé d'autre ta recursion était à OFF dans la config précédente

// disable recursion on authoritative DNS server.
recursion no;

il faut évidemment la mettre à ON (yes)