benja a écrit 1211 commentaires

Bonne idée ça que de l'envoyer dans un domaine encore plus dégeux que la gestion des signaux, à savoir la gestion des tty :-)

By the way, c'est uniquement de SIGINT dont tu as besoin pour intercepter le ctrl-c… Tout spécifier "en espérant que ça marche" démontre simplement que tu n'as pas compris l'utilisation des signaux. Ceux-ci ne sont uniquement qu'un mécanisme de notification asynchrone et préemptif (si tu comprends pourquoi ces deux mots sont importants, alors c'est que tu comprends comment fonctionnent les signaux) du noyau à l'attention des processus. Il va de soit que chaque signal a son utilité spécifique et doit être traité comme il se doit.

1) il peut-être intéressant de vérifier le retour de sigprocmask (hum…)
2) " A signal may be blocked, which means that it will not be delivered
until it is later unblocked. Between the time when it is generated and
when it is delivered a signal is said to be pending."
(de man 7 signal) : es-tu sur que ton programme est bien intérompu entre tes 2 appels à sigprocmask ?
3) pour ignorer un signal tu es du coup obligé d'écrire ton handler…
À partir de ce moment, je te conseille d'ouvrir un bouquin de programmation unix, car entre les threads, le polling d'évenements, l'éxéuctions de sous-processus, etc, il y a pas mal de subtilités (de la à dire que les programmes qui les gère correctement ne font pas légions, il n'y a qu'un pas…) Les signaux sont souvent considérés comme une moins bonne invention d'UNIX, à mon avis, à juste titre :-)

C'est une bonne illustration de l'effet "mise-en-bulle" de Google que duckduckgo, par définition, ne veut pas faire… Évidemment Google utilise sa connaissance sur toi pour te soumettre des résultats qui te sont pertinnents. Essaye maintenant la même requête à partir de l'ordinateur d'un biologiste (qui ne fait pas de java… :p), je ne suis pas sûr que tu puisses encore en dire autant sur la précision de Google. D'ailleurs cela a même un côté agaçant lorsque tu veux t'intéresser à un tout autre sujets, en restant pragmatique (d'autres considérations, plus "filosophiques", sont documentées sur le site de ddg).
Du coup la réflexion d'utiliser des mots clefs moins ambigus porte tout son sens. Il me semble que pendant la préhistoire d'avant google on enseignait comment construire une requête sur un moteur de recherche, à l'école ou autres occasions d'initiations à Internet.

Bref, google c'est un peu comme les calculettes, ça empêche de faire fonctionner ses méninges… :P

Sans parler du fait que windows ne va pas aimer devoir s'installer sur une partition étendue, donc peut rajouter une étape "bidouiller avec fdisk afin d'avoir une numérotation des partitions qui soit acceptable pour windows" et du coup "réinstaller une fois de plus grub". Ensuite (enfin.. endébut… en fait…) ce qui risque de coincer c'est le shrink du FS, par sûr que son FS ne le supporte, en tout cas XFS ne le fait pas. Fin bref perso je ferais soit un backup/restauration, soit installer windows dans une vm, soit achetter un autre disque dur, enfin non je ne ferais rien de tout ça en fait… :-)

Au sujet de la sécurité sans vouloir trop m'avancer je penses qu'il s'agît d'un message "historique" qui veut dire en gros "les ports et tous les logiciels tiers ne sont pas supporté officiellement et vous n'êtes pas à l'abris d'une recette de compilation qui installerait une backdoor dans votre système". S'il est vrai qu'il est impossible d'auditer toutes les sources, la vérification par leur somme de contrôle/hash des sources téléchargée empêche déja les problèmes les plus évidents, par exemple un serveur qui fournirait une archive vérolée. Pour le reste (i.e. l'audit de tous les logiciels tiers), pkg n'est pas mieux placé. Pour info, pkg c'est "juste" la distribution de paquets précompilés, qui sont au demeurant issus du même arbre de ports. By the way, la fabrication des ses propres dépôts pkg est devenue assez simple avec l'utilisation de l'outil "poudrière" qui remplace avantagement la plupart des cas d'utilisation de portsnap.

Deuxio pour corriger un problème de pkg, et à défaut d'avoir un message d'erreur factuel de ta part, je ne peux que te suggère d'utiliser le programme pkg_static qui comme sont nom l'indique est pkg compilé de telle sorte à n'utiliser aucune librairie partagée. Selon http://www.freebsd.org/cgi/man.cgi?query=pkg&sektion= tu peux essayer d'utiliser "pkg_static -f bootstrap" pour forcer une réinstallation… Au besoin, tu pourras extraire toi même pkg_static depuis un paquet (cd /tmp; fetch http://mirroir/pkg\*tar.xz, tar xf pkg*tar.xz; usr/bin/pkg_static … enfin un truc du genre ;-))

Tersio, freebsd avec zfs permet de faire des "boot environments" (*) et de rebooter sur un "snapshot" au cas où une mise à jour ferait tout foiré… Oui bon c'est un peu tard, mais bon voilà de quoi te faire avancer dans ta quête de connaissances ;-) (n'utilisant pas actuellement freebsd, je ne peux t'en dire plus… courage)

*: http://blather.michaelwlucas.com/archives/2363
http://www.freebsd.org/cgi/man.cgi?query=beadm&apropos=0&sektion=0&manpath=FreeBSD+10.2-RELEASE+and+Ports&arch=default&format=html

BTW est-ce que quelqu'un a réussi a partager un lecteur smartcard via spice/celt ? J'avais essayé en recompilant les paquets qui vont bien sur une debian (en gros tout ce qui a à voir avec la libcelt iirc), mais ça n'a jamais foncionné plus loin que la détection du lecteur par windows. Le lecteur sur l'hôte étant un ACR38.

Encore une autre solution assez efficace est d'utiliser rdesktop. Il y a pas mal de client libre dont certains qui permettent de partager un dossier local. Du coup le choix de la solution de virtualisation n'est plus limitée à kvm/qemu (qui est la seule à proposer spice). Pas sûr que l'on puisse partager de l'usb avec rdesktop, mais bon si c'est pour faire du mass-storage, autant partager un dossier via rdesktop…

note: spice permet aussi de partager le copier/coller, pour cela il faut aussi installer les pilotes windows.

Une autre solution, qui à mon avis est plus pratique et plus performante, c'est d'utiliser libvirt (kvm) avec spice.

Rapidement en passant sur de nombreux détails, il suffit:
- de lancer libvirtd sur le serveur
- sur un client linux, se connecter au serveur avec virt-manager en ajoutant une connection ssh
- créer la machine virtuelle à partir de virt-manager, il conviendra à priori de copier le média d'installation sur le serveur
- éventuellement d'installer les drivers spices/virt-io pour windows
- ensuite il est possible d'utiliser un client spice directement sans passer par virt-manager, i.e. il existe aussi un client windows et android (je crois).

note: il est possible d'installer windows, du moins au temps de xp ça marchait, sur un périphérique disque de type "virtio" en attachant une disquette qui contient le pilote ad-hoc au moment de l'installation
note: les pilotes windows spice (pour une meilleur accélération graphique) et virtio sont trouvable via le site de spice.
note: il est conseillé d'attribuer toute une partition (ou un "logical volume" lvm) en tant que disque virtuel, c'est plus performant que d'utiliser un fichier d'image. Au moment de la création avec virt-manager, il suffit de choisir "parcourir localement" et tapper soit même /dev/sdaXX ou /dev/MonVolumeGroup/MonLV…)
spice donne un résultat bien plus satisfaisant que vnc et/ou forward X. De plus cela supporte la redirection du son et de certains périphériques USB, entre autre…

Aie mes yeux x_x… Je présente mes excuses aux amateurs de la langue et, à vrai dire, gêné par cette expression qui pourrait être perçue pour un manque d'aptitude indispensable afin d'élever notre débat—plus que par de quelconques pressions extérieures—je me vois contraint de démissionner de ce débat.
En ce faisant, j'espère tout de même avoir infirmé l'antithèse de ma première question; reste à savoir si suis-je en mesure de prouver savoir orthographier "philosophie" correctement du premier coup… ?

Fylosophons un petit peu tiens… :)
1) Est-ce possible de prouver l'absence de quelque chose ?
2) Est-il acceptable de rompre un contrat moral (divulger un secret dans le cas qui nous occupe) pour montrer sa bonne fois ?

Ton fichier a l'air d'être au format dos… (les \r avant les \n)

Normalement la command echo … > /fichier va réécrire fichier avec …. Pour une raison curieuse cela ne marche pas (une version de shell exotique ? caractère invisible spécial devant le nom de fichier qui ne devrait pas être là  ? normalement il n'y a pas besoins de guillemets dans ce ci car les mots y sont interprêté comme des arguments de la commande "echo" et se retrouveront ensuite séparés par un espace unique, enfin bref n'entrons pas dans ces détails ici…).

Tu peux arriver au même résultat en 1) ouvrant ce fichier avec un éditeur de texte 2) remplacer son contenu avec la fameuse ligne qui commence par deb.

Pour 1) essaye d'abord avec l'éditeur graphique "gedit", si cela ne marche pas essaye alors avec l'éditeur en mode texte "nano" voir "mcedit". Donc
gedit /etc/apt/sources.lists

(n'oublie pas d'abord un "sudo -i" si tu as réouvert entre-temps une nouvelle fenêtre de commandes)

Pour 2) tu devrais pouvoir te débrouiller en fonction de l'éditeur utilisé, n'oublie juste pas de sauver le fichier ;-). Ensuite tu continues la procédure à partir du "apt-get udpate".

dpkg --purge --force-all dropbox (éventuellement remplacer "dropbox" par le nom de paquet qui échoue en phase de configuration…)
dpkg --configure -a
apt-get update
apt-get install -f
apt-get autoremove

ça devrait te ramener vers une situation plus "stable". au besoin, ensuite réinstaller dropbox dans une version adaptée à ta distribution, n'ayant que peu d'expérience avec mint je ne saurais te conseiller la meilleur voie à suivre, si ce n'est de consulter le support de la firme dropbox ;-)

1) Ouvre un terminal
2) tape pour ouvrir une session "root"
sudo -i
3) donnes ton mot de passe s'il cette commande te le demande
4) entre ces 2 commandes pour faire pointer vers l'url correcte du dépot de ta version (i.e. ce que Francesco et NeoX ont expliqué)
mv /etc/apt/sources.list /etc/apt/sources.list.disabled
echo deb http://old-releases.ubuntu.com/ubuntu/ saucy main universe multiverse > /etc/apt/souces.list
5) retélécharge la dernière version des catalogues du dépot; il ne devrait plus y avoir d'erreur de téléchargement (sauf si tu as des fichiers dans /etc/apt/sources.list.d qui pointent vers des catalogues de dépots supplémentaires, quoi qu'il en soit ces erreures ne devraient pas être bloquantes pour la suite)
apt-get update
6) installe/mets à jour l'outil de mise à jours et valide éventuellement l'opération
apt-get install update-manager-core
7) commande pour lancer l'upgrade.
do-release-upgrade
8) après la procédure d'upgrade qui devraient prendre un certain temps et se dérouler sans erreurs je l'espère pour toi, tu pourras inspecter tes nouvelles urls de dépots: le mot "saucing" devrait avoir été remplacé par "vivid" ou un truc plus ancien qui correspond à la "LTS" et qui devrais être un mot commançant par "t", "trusty" si je ne m'emmèle pas les pinceaux… :p Note que les lignes de ce fichier commançant par '#' sont des commentaires, c.-à-d. non-pertinentes.
cat /etc/apt/sources.list

Bonne chance !

Après, je ne dis pas que c'est mal, mais j'ai l'impression que ça va être surtout utilisé de cette façon.

Enregistre une prédiction ?

Merci pour cette piste, bien qu'ayant un partie swap je suis allé vérifier le disque. La partie swap etait bizarement désactivée.

Attention à ne pas confondre une partition active au niveau de la table des partitions du disque dur tel que visible avec un outil de type gparted/parted/fdisk/…. et l'activation d'un swap au niveau de OS.

La première était utilisé à l'époque pour indique au MBR sur quelle partition démarrer, ça n'a plus vraiment d'utilité lorsque l'on utilise un boot-loader plus évolué tel que grub sous linux (peut-être que bootloader de windows utilise lui encore cette information ?). Cela n'a aucune incidence sur l'utilisation ou non d'une partition swap.

Pour la seconde, il faut bien vérifier le retour de la commande 'swapon', 'free' ou la bonne ligne de la sortie de 'top' (p.e.: KiB Swap: 3903484 total, 124 used, 3903360 free. 2056384 cached Mem -> ici j'ai ~4G de swap activée).

Pour activer automatiquement une partition swap, il faut que celle-ci soit renseignée dans /etc/fstab ou bien le faire à la main de manière non permanente avec la commande 'swapon /dev/PARTITION' où PARTITION correspond au disque et à la partition adéquate (p.e. sda5 ou mapper/vg_sys-lv_swap si utilisation d'un LVM).

Bref pour vous aider plus correctement à déterminer si cette hypothèse est valable, il y aurait besoin que vous copiez verbatim toute la sortie de top et le contenu de votre fichier /etc/fstab.

Il y a-t-il un espace d'échange (p.e. une partition ou un fichier, préférence au premier) configuré sur ton système ?
Son absence pourrait-être une raison de ce fonctionnement qui est anormal. Linux est en effet prévu pour fonctionner avec un "swap".

PS: la plupart du temps le mécanisme de kworker est utilisé par les divers mécanismes de gestion de la mémoire, y est compris la pagination (le "swapping"). Par exemple, il peut être nécessaire de paginer de la mémoire vive afin de la libérer pour ensuite l'allouer à un transfert vers un périphérique. S'il n'y a pas d'espace swap tu forces un fonctionnement dégradé du noyau, et peut-être qu'il va devoir travailler plus pour sélectionner de la mémoire libérable (attention ceci n'est qu'une pure spéculation de ma part).

Il me semble que lorsque tu as l'affichage simple, le symbole provient d'un objet lié statiquement à l'exécutable. La command 'info symbol 0x[adresse]' te donne plus d'info quant à la définition du symbole. Maintenant j'imagine que le nom de l'objet n'est pas toujours disponible non plus. Tu peux aussi regarder du côté des commandes binutils (objdump, nm, readelf, …) sur les exécutable, objet et libraires pour savoir exactement ce qui est défini, comment et où (n'hésite pas à revenir avec une question plus précise par la suite). grep aussi est parfois très utile comme première recherche…

J'oublais, si ça marche toujours pas, donne un coup de iptables -t nat -F; iptables -F pour virer le firewall (tes policy sont en accept donc bon ça ne devrait pas poser de problème… pas très utile non plus :p)

Ok c'est du bon tout ça :p

Par contre, qu'entends-tu par jonction entre eth0 et eth1 ?

Je suppose qu'il entend l'ip forwarding. Dans le cas bridge, on peut dire grosso-modo que tu n'as plus qu'un réseau (plus besoin de NAT ni de routage).

Ton problème c'est que la gateway que tu envoie au PC est la freebox alors que tu devrais envoyer l'IP LAN1 de ton serveur DHCP (cf. mon commentaire plus bàs, cas 1) NAT).
option routers 192.168.0.254; # mauvais

Comme tu le sais probablement, DHCP donne généralement une IP, l'IP de serveurs DNS, une route par défaut et un nom d'hôte. Mais il est possible d'envoyer un peu nimporte quoi comme info, cela va des trucs +/- standardisés (les options citées précedemment, un serveur NFS pour du netboot, NTP, NIS, etc) en passant par des truc complètement custom dont seul toi et le client dhcp connaissent la signification (cf. man dhcp-options, pour info il est possible de scripter le client dhcp ISC pour une flexibilité maximale).

Résumons: PC ------ DHCP ------ FREEBOX -WAN. De deux choses l'une: NAT ou pas-NAT.

1) NAT
Le PC doit recevoir la config suivante:
IP: dans le LAN1
Route par défaut: l'addresse du serveur DHCP, dans LAN1.
Au niveau du serveur DHCP: activer le routage et le masquerading sur l'interface LAN2.

2) sans NAT
Le PC reçoit la config suivante:
IP: dans LAN1
Route par défaut: IP FREEBOX dans LAN2
Route pour accéder au LAN2 (ce qui manque dans ta config, sans cela PC ne sait pas comment joindre FREEBOX): IP DHCP LAN1.
Au niveau de la box DHCP: activer le routage uniquement.

(Bon de trois chose l'une)
3) Tu pourrais aussi NATer dans l'autre sens: la freebox sur le LAN2 pour faire "comme si" la freebox est dans le LAN1 vis-à-vis des PC… mais bon là c'est un peu de couper les cheveux en 4 (quoique un bon exercice :p)

(Et de 4)
4) BRIDGE. Ben là tout le monde se retrouve dans LAN2, ton DHCP donne des IP dans LAN2 avec comme gateway la freebox. Faire attention à bien couper (ou bloquer au niveau du part-feu) le DHCP de la freebox pour éviter les interférences.

Pour activer le routage de façon non permanente : echo 1 > /proc/sys/net/ipv4/ip_forwarding (éventuellement faire de même pour ipv6). De façon permanente: éditer le fichier /etc/sysctl.conf et/ou se reporter à la documentation de la distribution.

Pour le NAT (2): iptable -t nat -A POSTROUTING -o eth0 --source 192.168.1.0/24 -j MASQUERADE

Pour envoyer la route manquante: google "dhcpd.conf static route" . Faire attention que si tu utilises les "classless static routes", il te faudra aussi ajouter la route par défaut à cette liste. (BTW, tu remarqueras que MS a décidé de faire autrement que tout le monde, tu devrais définir toi même le type et le numéro de l'option dhcp utilisée par MS).

Ensuite sur le PC, les commandes ping et route (ou leurs équivalents dans le monde MS) devraient te permettre d'avancer le diagnostique. Grosso-merdo il faut vérifier que chaque hote est joignable par les autres.

ping DHCP/LAN1
ping DHCP/LAN2
ping FREEBOX/LAN2
route show (vérifie que tu aie une route pour LAN2 et une route par défaut).

Je te conseille aussi d'essayer sans DHCP, en renseignant les IP et les routes manuellement sur le client. Dans ton cas, je suppose que tu n'as juste pas simplement activé le routage au niveau du serveur dhcp (pour router entre le LAN1 et le LAN2) et qu'il te manque une route au niveau des clients pour joindre LAN2 via l'adresse de ton serveur dans LAN1…

(Note: je fais comme si la borne wifi n'existe pas, il se peut que le problème vienne de là… au pire des cas, tester avec un cable réseau pour l'utiliser comme simple "switch")

Désolé d'arriver comme un cheveux dans la soupe, mais c'est une très très mauvaise idée de vouloir faire tourner lightttpd en root (surtout si c'est pour de l'embeded: longue durée de vie, pas de mises-à-jour; surtout si on y rajoute du php aussi…).

Alors pourquoi ne pas définir les permissions sur les fichiers /sys/class correctement en premier lieu ? Ça me parait la solution la plus simple et la plus adaptée.

Seconde possibilité: utiliser sudo ET PASSER par un wrapper, c'est-à-dire php->exec("sudo /usr/local/bin/led_on.sh"), et configure sudoers pour n'autoriser www-data qu'à lancer ce script, et uniquement ce script ! Ne pas faire cela, et en admettant que le code php est troué (ce qu'il est forcément…) on se retrouve dans la même situation où le serveur tourne en root.

PS: Y a-t-il une raison pour laquelle mettre server.username à root ne fonctionne pas (cf. http://redmine.lighttpd.net/projects/lighttpd/wiki/Server_usernameDetails) ? Même si je maintiens que c'est une très mauvaise idée :P

Toutafé, Un Tout Grand Merci pour la Rectification. Heureusement qu'il reste des entreprises^Wemployeurs, responsables et humain(e)s, pour nous nous aider à rester critiques. Merci à eux ! Merci à ton employeur. Merci à tes collègues, savants, qui n'ont que comme seules ambitions, celles de rendre la connaissance universelle et l'épanouissement partagé par tous. Ô qu'ils soient (bah tiens, toi aussi hein) loués, car nous savons comme l'Humanité peut être si ingrate, des fois.

Tant qu'à faire, ajoutons dans la catégorie python avec un nom sympa: «YAYBU, CONFIGURATION MANAGEMENT FOR HAPPY PEOPLE».
http://yaybu.com/