JJD a écrit 516 commentaires

Salut,

Et bien tu n'as pas vraiment le choix : il faut que tu utilises ton IP publique puisque c'est la seule qui sera joignable.
Pour cela, et en fonction de l'équipement qui te sert de routeur (tu n'as pas indiqué ton FAI), la démarche varie un peu mais le principe est le même : il faut que tu routes un flux TCP depuis ta BOX vers ta machine en interne en faisant de la translation d'adresse et de port (NAT et PAT).
En clair, il faut paramétrer le fait que les connexions arrivant sur ta box sur un port donné (port TCP 22 ou, mieux, un port quelconque que tu peux choisir) doivent être routées sur l'IP de ta machine en interne sur le port TCP 22.

Ensuite, pour ouvrir une session SSH, tu indiques l'adresse IP publique et le port externe que tu as choisi.

Quelques précautions/vérifications à faire :
- l'adresse IP publique est-elle fixe ?
- il faut que l'adresse interne de ta machine soit fixe également (en fonction de ton FAI, tu mets une adresse IP fixe sur cette machine ou tu fais une réservation DHCP liée à l'adresse MAC)

Mais indique qui est ton FAI te je suis sûr que des personnes ici pourront te fournir une procédure plus détaillée.

A+

Seulement, sous mon Chrome/Windows le drag & drop ne fait qu'ouvrir simplement le pdf avec la visionneuse embarqué

clique sur l'emplacement : tu auras le sélecteur de fichiers pour choisir le PDF à uploader.

Et bien je ne vois rien de surprenant dans la conf de 10.149.85.21 (si ce n'est que l'interface réseau semble s'appeler p3p1 mais que dans la log DHCP on voit apparaître eth1) mais j'utilise peu de systèmes RedHat/fedora.

Jusqu'à présent, le seul test sortant que tu nous a présenté est un ping depuis 10.149.85.21 vers la machine servant de routeur (10.149.85.30). Es-ce que tu as validé que ce routeur fonctionnait correctement ? (routage activé, firewall correctement paramétré, …)
Il y a-t-il d'autres machines sur ce réseau local (10.149.85.*) ? Si c'est le cas, ces autres machines utilisent-elle la même passerelle ? Arrivent-elle à la pinger et à accéder aux réseaux externes ? Que donne un ping depuis 10.149.85.21 vers ces autres machines ? En clair, il s'agit d'identifier si le soucis est réellement sur cette machine (10.149.85.21) ou bien ailleurs.

Salut,

D'après les infos, je ne vois pas vraiment ce qui peut clocher mais pour avancer, voici quand même quelques pistes :
- vérifie que tu n'as pas un firewall mal configuré (résultat de la commande "iptables -n -L")
- es-tu sûr qu'il n'y a pas une autre machine sur ton réseau local avec la même adresse IP (10.149.85.21) ?
- regarde s'il y a des informations pertinentes dans les logs (fichiers syslog et/ou messages dans /var/log/)

Pour avancer, il faudra que tu fournisses plus d'infos : résultat des commandes ci-dessus, ainsi que ta distribution (avec sa version) et le mode de configuration du réseau (statique/DHCP, network-manager/fichiers de conf, …)

Dans l'économie « réélle » 85 personnes détiendraient la moitié de la richesse mondiale.

On n'a pas dû lire le même article…
Ce qui est écrit, c'est que 85 personnes possèdent autant de richesses que la moitié de l'humanité la plus pauvre, ce qui est loin de représenter (malheureusement) la moitié de la richesse mondiale (puisque dans ce cas, on aurait un beau cas d'égalité dans la répartition de cette richesse)

Afin que ton postfix accepte de relayer tes mails, il faut que ton client (smartphone) s'identifie auprès du serveur SMTP (il me semble que c'est la configuration par défaut sous Debian).
Comme tu as un serveur IMAP dovecot, tu peux l'utiliser pour cela : cherche un peu et tu trouveras pleins de tutos t'expliquant le paramétrage. Au final, dans le fichier main.cf tu devrais avoir quelque chose dans ce genre :

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions = permit_mynetworks   permit_sasl_authenticated   reject_unauth_destination

Comme ça postfix va utiliser une socket publiée par dovecot (/var/spool/postfix/private/auth) pour vérifier le mot de passe. Dans la conf de dovecot, il faudra déclarer cette socket :

unix_listener /var/spool/postfix/private/auth {
    mode = 0666
  }

Et bien évidemment, comme tu va devoir envoyer un mot de passe, pense à faire du TSL pour que ce mot de passe ne transite pas en clair (mais tu dois déjà avoir un certificat pour chiffrer la connexion IMAP)

Put… tu t'est planté :
Ton commentaire est en ISO-8859-15 alors que le site est en UTF-8 !!

À ce niveau-là, je pense carrément qu'on installe non seulement les dépendances mais aussi les suggestions (paramètre APT::Install-Suggests positionné à 1 ou true) puisque cscope n'est qu'une suggestion du paquet vim-gtk
Ça peut valoir le coup de vérifier et de supprimer cette option : les recommandations peuvent être utiles pour garder un ensemble cohérent mais je pense qu'il faut plus regarder les suggestions comme une information.

Quand on voit qu'il faut un article aussi long pour décrire le fonctionnement d'un FS. Cela me fait très peur :)

D'un autre côté, je ne suis pas sûr que l'on aurait fait plus court pour présenter ext4 + lvm + dm_raid + dm_cache + …

Il faut en effet bien noter que zfs gère toute la pile de stockage : ce n'est pas juste un système de fichiers.

Ici, ça risque de na pas suffire…
Le serveur kimsufi n'est apparemment pas un serveur de messagerie gérant un domaine. L'envoi des mails passe par le sendmail local et le serveur SMTP local qui essaie de transférer vers le destinataire mais l'adresse d'émission est simplement construite à partir du nom et du domaine locaux, ce qui donne quelque chose comme www-data@xxxxx.kimsufi.com.
Ce mail est directement balancé sur le MX de wanadoo.fr (smtp-in.orange.fr) qui le refuse de façon assez légitime à mon avis.

La solution pourrait être de relayer le mail par un serveur de messagerie du domaine de l'adresse d'émission :
- soit OVH en fournit un et il faut utiliser ce relais
- soit on utilise une adresse d'émission valide du type mon_serveur@example.com et il faut soumettre le mail à un serveur gérant ce domaine (et si les choses sont faites correctement, cela peut impliquer de s'authentifier sur ce serveur).
Je ne sais pas si la fonction mail standard de PHP permet tout cela (spécifier une adresse d'émission et un serveur de messagerie, dans php.ini, ne semble être possible que sous Windows et il ne paraît pas possible de gérer l'authentification SMTP). Il faudra donc jouer sur la configuration du serveur de messagerie local (sendmail ?), ce qui peut être assez complexe, ou utiliser des fonctions d'envoi de mail un peu plus évoluées/configurables que la fonction standard (tu peux regarder du côté de PHPMailer par exemple).

Salut,

je souffre également de ces problèmes de stabilité avec une Dedibox SC sous Wheezy 64 bits.
J'ai un ticket ouvert depuis quelques mois et lors du dernier contact (au mois d'octobre), le support m'a indiqué une entrée de forum (http://forum.online.net/index.php?/topic/2344-dedibox-via-nano-et-debian) et a déclaré «Pour le moment nos techniciens matériels sont entrain de travailler sur ce défaut mais je n'ai pas de solutions " de secours" à vous apporter.»

J'ai également tester de désactiver la régulation en fréquence du processeur (en blacklistant les modules acpi_cpufreq, mperf et processor) sans résultat tangible : l'uptime du serveur n'a jamais dépassé les 3 à 4 jours.

Cependant, depuis le passage au dernier noyau dans les backports (3.12-0.bpo.1-amd64 en remplacement du 3.11-0.bpo.2-amd64 ou du 3.2.0-4-amd64), je n'ai plus de soucis : plus de 14 jours d'uptime ! C'est un record !

Il faut noter que les modules indiqués plus haut sont toujours blacklistés et que je n'ai rien trouvé dans les changelogs du noyau qui pourrait expliquer le problème.

Il me semblait que la question de l'accès en lecture pour tous était posée au moment de l'installation mais je peux me tromper (et ça peut varier en fonction du niveau de détail sur lequel est paramétré debconf).
Quoi qu'il en soit, ça ce règle comme dit précédemment en modifiant login.defs si on utilise directement useradd, mais ce n'est pas la méthode préconisée (useradd est considéré comme un utilitaire bas niveau et on passera plutôt par adduser, voire par un application graphique).

Je pense qu'il est préférable de modifier le fichier /etc/adduser.conf (pour avoir un maximum de contrôle sur la façon dont les nouveaux utilisateurs sont créés) ou de reconfigurer le paquet adduser (en appelant "dpkg-reconfigure adduser" ou en passant par synaptic) : il suffit de répondre non à la question posée (le répertoire reste lisible au groupe mais, par défaut, il est créé un groupe par utilisateur).

Salut,

Est-ce que tu as essayé les drivers (propriétaires) que semble fournir Panasonic là ?
http://panasonic.net/pcc/support/fax/common/table/linuxdriver.html

cron exécute quotidiennement mandb afin de créer ou de mettre à jour les index des pages de manuels. Ces index sont utiles pour accélérer certaines opérations et pour permettre à des commandes comme apropos de fonctionner.

Sous Debian stable (wheezy) on a effectivement la version 0.6.18 qui devait être la version courante au moment du freeze. Les versions sous testing et sid sont un peu plus récentes (0.6.21, sortie en janvier, disponible dans sid). Mais bon, quels sont ces bugs, corrigés dans les versions les plus récentes, qui t'empêche d'utiliser la version de wheezy ? Je t'avoue que je n'utilise duplicity que sur quelques serveurs perso mais que je n'ai pas encore rencontré de problème…

Bon, vu le chemin du fichier de manuel (/usr/local/share/man/man1/duplicity.1), je pense que le duplicity installé ne faisait pas partie des paquets officiels. Je ne sais pas comment tout cela a été installé puis supprimé, mais apparemment il reste un fichier (un lien symbolique cassé ?) dans /usr/local/share/man/man1.
Je pense que la solution est simplement de supprimer ce fichier (/usr/local/share/man/man1/duplicity.1), après avoir vérifié à quoi il ressemble…

Effectivement, les valeurs obtenues avec ps sont surprenantes. J'ai testé sur quelques machines et j'ai bien des valeurs supérieures en additionnant les rss de ps par rapport à ce que donne free.

J'ai routé de même été dérouté par la syntaxe que tu utilises avec ps (mélange de syntaxe BSD et de syntaxe standard). Ça ne semble pas gênant, mais j'aurais plutôt mis
ps axo rss
ou
ps -eo rss

J'ai aussi pensé à une différence due au swap, mais celui-ci ne semble pas du tout utilisé (mais, près de 10GO de swap, ça me semble énôrme !)

Sinon, est-il possible que des modules noyaux utilisent cette RAM manquante ? Je n'ai pas de méthode précise pour mesurer ça, mais lsmod ou slabtop peuvent peut-être donner des éléments de réponse. En particulier, dans le cas de machines virtuelles, le mécanisme de memory ballooning peut être très gourmand en RAM, surtout s'il y a saturation des ressources physiques.

Bonsoir,

Ben tu peux utiliser xlock ou un des utilitaires issus de différents projet de WM ou de desktop qui fournissent le même service : slock, i3lock, …
Il est aussi possible de faire ça avec un "économiseur" d'écran comme xscreensaver.

A+
JJD

Bonjour,

Tu utilises quelle version de top ? De mon côté (sous Debian sid), j'ai une version prcps-ng 3.3.4 et je n'arrive pas à reproduire le comportement que tu indiques :
- soit j'ai la commande complète, éventuellement tronquée (mais la ligne se termine avec un +) ;
- soit j'ai uniquement le nom de la commande (mais j'ai alors python2.5 et non pas /usr/bin/python2.5)
De ton côté, tu sembles avoir des lignes de longueur variable… Est-ce que tu rediriges la sortie de top directement dans un fichier ou bien est-ce que tu fais d'autres traitements avant ?

Pour avoir les lignes de commande complètes (dans la plupart des cas), j'utilise l'option -w 512 ou bien je définis la variable COLUMNS à 512 avant d'exécuter top (512 est la valeur max)

COLUMNS=512  /usr/bin/top -bc -n 1 >>/tmp/top.txt
/usr/bin/top -bc -n 1 -w 512 >>/tmp/top.txt

A+
JJD

Dans le premier lien, on parle de VP8 et de la génération suivante : VP9 semble donc bien couvert par l'accord.

En revanche, on ne connaît pas le montant de l'accord…

On n'est pas payé en fonction de l'effort que nécessite notre travail, mais on est payé en fonction ce qu'on rapporte

Même ça n'est pas complètement vrai. On est dans un système d'offre et de demande. Ça explique que les salaires augmentent en période de forte activité (ce qui est plutôt rare en ce moment) et stagnent, voire diminuent, en période de chômage. C'est aussi ce qui fait, en grande partie, qu'une femme ou un homme (j'en ai fait partie) de ménage soit moins payé qu'un ingénieur spécialiste dans son secteur : il est généralement plus facile de recruter ou remplacer un employé sur un poste avec une faible qualification (qualification que je ne lie pas directement à la durée des études).

Moi j'aime pas les journaux avec un contenu qui n'est là que pour rendre un peu moins visible de la publicité pour des chaudières !

Là on pousse même le vice à utiliser des comptes créés il y a 11 ans…

Salut,

Une possibilité pourrait consister à mettre tes directives d'authentification dans un fichier séparé et à inclure ce fichier avec la directive "Include fichier_auth" dans chacun de tes VirtualHosts. Ça oblige encore à modifier tous tes VirtualHosts mais en ajoutant uniquement une ligne à chaque fois. De plus, en cas de modification de la configuration, tu n'auras à faire tes changements qu'une fois dans un emplacement unique.

A+
JJD

Tu peux aussi forcer le protocole à utiliser avec l'option --protocol=TCP

Salut,

Sur tes lignes de commandes tu ne précises pas de serveur sur lequel te connecter. La connexion se fait donc en local, via une socket unix, même si tu précises un port TCP à utiliser.

Ça devrait donc fonctionner comme tu le veux si tu indiques l'option --host=127.0.0.1 (il ne faut pas mettre localhost, sinon on utilise, encore, une socket unix).

A+
JJD

Au final, le code indiqué ne fait que vérifier que le répertoire /proc/PID existe et est accessible.
Les différentes solutions indiquées sur stackoverflow fonctionnent aussi et il n'y a pas lieu de s'inquiéter du code non maintenu : il n'y a jamais qu'une ligne ou deux !

Pour la peine, je vais y aller de ma contribution en déclarant ma propre fonction bash (shell) waitproc :

function waitproc { while [ -e /proc/$1 ] ; do sleep 1 ; done ; }

Bon, ça ne teste pas si le process existe bien (sortie immédiate), mais ça devrait faire ce qui est demandé. Pour une sortie plus rapide en fin de process, on peut remplacer le sleep 1 par une valeur inférieure, voire simplement par : (deux points superposés : commande shell qui ne fait rien).

A+
JJD