Pas besoin d'ajouter des utilisateurs. Tu as juste à ajouter une ligne avec login:mdp dans le fichier qui va bien. Si tu veux gérer le fichier par une interface web, Pear est ton ami. C'est pas plus compliqué que de s'amuser à écrire un système d'authentification potentiellement foireux.
Par ailleurs maintenant que tu as dit comment tu trouvais tes mdp, il est bcp plus facile (moins difficile en tout cas) de les cracker :op
Pour éviter d'avoir plusieurs fois le même script qui tourne en parrallèle, on utilise des verrous: tu bloques un verrou au début du script et tu le libéres à la fin. Après tu vérifies si le verrou est bloqué, si c'est le cas le script est en train de tourner. En pratique tu peux utiliser flock() ou une entrée dans une base de données (MySQL sur un P133 avec 48Mo de RAM c'est pas top cependant). Le truc à _ne_ _pas_ faire est d'utiliser un bête fichier genre
while (file_exists($lock)) sleep(0.1);
create_file($lock);
/* do stuff */
delete_file($lock);
Parce que tu n'est pas certains que le fichier n'aura pas été verrouillé par un autre process entre la fin du while et le début du create_file(). Enfin dans 99% des cas sur une machine mono processeur ça ne devrait pas poser de problème mais de toute façon il vaut mieux utiliser flock() qui est fait pour ça (mais c'est pas super portable). Dans ton cas tu peux écrire la date (temps epoch) de la dernière tentative d'authentification dans une db ou un fichier (mais dans ce cas tu dois quand même utiliser flock()) et vérifier que le délais est respecté.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
J'ai eu exactement le même problème il y a deux jours en installant Sarge (mais sur i386): concernant X j'ai juste installé les packages x-window-system-core, xdm et ion2 et AltGr agissait exactement comme Alt donc pas de |@#¼½^[{}\]`·~ (clavier belge).
apt-get install xlibs && /etc/init.d/xdm restart
Ca marche. Ca doit avoir un rapport avec XKB mais j'ai pas cherché plus loin.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Je crois que tu peux limiter le nombre de requètes en // dans la configuration d'Apache (RTFM) mais ça risque d'être assez embétant pour les visiteurs. C'est pas parce que c'est un P133 qu'il ne peut pas répondre à plusieurs requètes en même temps. Si tu mets un mdp suffisament "compliqué" (un mdp long mais "facile" à deviner c'est pas mieux qu'un mdp de 4 caractères aléatoires), c'est l'url qui va être plus facile à deviner. Le problème c'est qu'au mieux ton système de mdp ne sert à rien et au pire ça permet de cracker plus facilement.
Si le but c'est juste de faire croire que c'est sécurisé au premier neuneu venu alors je sais pas pourquoi tu as demandé de l'aide ici.
Je comprends pas pourquoi tu veux pas utiliser les htaccess.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Oui apparement current c'est la version "snapshot" (j'avais pas fait attention à la version que tu utilisais). Si c'est pas encore fait, essai la beta 4. Peut-être que le bug n'existait pas dans cette version et qu'il a été introduit plus tard.
Par ailleurs ya un passage sur les disque SATA dans la FAQ de l'installateur.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Juste avant de booter sur le CD, appuie sur F1/F2/... pour avoir les options de boot disponibles. Parmis celle-là il y en a peut-être une qui voudra bien fonctionner avec ton HD. Vérifie aussi que le CD que tu as gravé n'est pas corrompu (ya le md5 dans le même répertoire que l'iso normalement). Si ça marche toujours pas, essai la dernière snapshot de netinst et si ça marche toujours pas, fait quand même un bug report en décrivant au mieux ton problème.
J'ai installé une Sarge il y a encore 2 jours sans problème (mais j'ai jamais essayé le 2.6 non plus en fait).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
J'utilise uniquement Jabber et les transports. Pour autant que je sache, il n'existe pas encore de moyen de transférer des fichiers avec les clients MSN/ICQ/... en utilisant les transports donc voilà. L'avantage c'est que je peux utiliser une seule connexion SSL pour me connecter à toutes mes adresses d'IM. Vu que je passe la moitié de mon temps sur un réseau non switché où tout le monde peut sniffer ce qu'il veut, je trouve ça assez pratique (bon ça serait switché ça serait presque pareil).
Pour en revenir à cette histoire de mdp, si tu as gardé le même fonctionnement, pas besoin d'utiliser de mdp. Le seul "secret" à connaitre est l'url. Pour protéger les répertoires, le htaccess est probablement la meilleure solution. Je pense que ça le fait même récursivement.
Le délais de 3 secondes empéche rien: qqun peut brute-forcer tranquillement avec X connexions en paralléle, il aura juste les résultat de chacune 3 secondes plus tard mais rien ne l'empèche de refaire une requète avant que le délais se soit écoulé. Et en fait il a même pas besoin de faire ça, il a juste à "brute-forcer" l'url.
Un truc plus "sécurisé" serait de faire une page PHP qui prend 2 paramètres: le mdp et le fichier à accéder. Si le mdp est correct mais que le fichier à accéder n'existe pas, tu "fournis" un listing des fichiers. Si le mdp est correct et le fichier existe, tu renvois directement le fichier. De cette manière tu peux interdire complétement l'accés aux fichiers directement via Apache: on ne peut y accéder que par l'interface web. Mais il faut faire très attention aux fichiers accessibles (gaffe aux trucs genre .. et liens symboliques). Idéalement tu devrais avoir le listing des fichiers accessibles défini explicitement dans un fichier de configuration par exemple.
Ce genre de script existe déjà, suffit de chercher un peu. Enfin pour le mdp je suis pas sur mais ça tu peux le rajouter au niveau d'Apache et comme ça tu n'as qu'une seule page à protéger.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Si j'ai bien compris, tu veux vérifier le mdp et rediriger la personne vers une page à l'url "impossible à deviner" s'il est correct. C'est pas la bonne manière de faire. Si tu penses vraiment que ton url peut rester "secret", autant donner l'url comme mdp, pas besoin de te casser la tête avec PHP et ça sera pas moins sécurisé. Ca le sera même plus si la "difficulté" du mdp est moindre que celle de l'url. Si elle l'est plus, c'est le mdp qui sert à rien.
Maintenant si tu veux un "vrai" accés par mdp, tu vas devoir soit tout mettre dans la même page PHP protégée par elle même (affichage de la page uniquement si le mdp est correct, pas moyen de contourner comme c'est le cas dans ton exemple), soit utiliser les sessions et les cookies pour protéger les autres pages (accès que si le cookie est bon et le cookie ne peut être mis que par la page de login, ou un truc comme ça, j'ai jamais touché à ça), soit utiliser une protection au niveau d'Apache comme suggéré plus haut, qui va te permettre de protéger tout le répertoire du même coup.
A mon avis, la solution la plus facile/rapide à mettre en place est celle des htaccess. C'est pas plus compliqué que ta solution, ça l'est même moins: t'as pas à faire de PHP, t'as juste à maintenir un fichiers d'utilisateurs/mdp. Si tu veux tu peux t'amuser à faire une interface PHP pour gérer le fichier. Si tu veux vraiment pas avoir à taper un login mais juste un mdp, alors amuse toi avec les sessions/cookies ou intégre tout dans la même page si c'est possible.
Pour le problème du brute-force. Avec le système actuel, le méchant n'a qu'à brute-forcer un URL ou un mdp, le plus faible des deux. Avec le htaccess, il doit brute-forcer un login+mdp (en admettant que le login reste "secret" aussi). De toute façon toute application de ce genre est "brute-forçable". Si tu penses que ça en vaut la peine, tu as plusieurs solutions pour limiter les risques. Le plus simple est probablement de bien choisir le mdp, après tu peux t'arranger pour qu'on ne puisse pas faire plus de X tentatives de login par heure (mais pas avec des cookies, du JS ou autre truc "client-side", dans ce cas ça sert à rien et ça fait chier les visiteurs) ou commencer à chercher un système d'authentification plus correct (à coups de PGP/SSL/TLS/... par exemples) mais ça devient tout de suite plus lourd. Yavait un article sur l'authentification par mdp dans le Linux Magazine France du mois dernier je pense (si qqun avec le magazine sous la main peut confirmer...). Ca peut peut-être t'intéresser.
Personnellement, j'ai un serveur FTP avec un compte "invité" qui me sert de temps en temps ("hé pq je peux pas t'envoyer de fichiers par MSN?"). Le mdp change aléatoirement toutes les X heures et il est enregistré dans un fichier auquel moi seul ai accés. Avec ça, bonne chance pour le brute-force. Faut voir si ça peut être applicable à ton cas. Dans le même genre, voir http://slashdot.org/comments.pl?sid=111503&cid=9469343(...)
Le mdp est généré par exemple par un md5 de la somme de l'heure actuelle et du "vrai" mdp (une truc plus correct serait genre md5(md5(time).md5(passwd)), le "." pour la concaténation). Comme ça, toute personne qui a le "vrai" mdp peut reconstituer le mdp actuel mais il change toutes les X heures/minutes. Tu peux aussi t'arranger pour que le mdp change après que qqun se soit loggué, comme ça si la connexion est sniffée, l'attaquant ne sait quand même pas obtenir le mdp puisqu'il a déjà changé (mais bon dans ce cas tu as d'autres problèmes).
Par ailleurs je recommande la lecture de cet article-ci à tous ceux qui débutent dans les applications web (et ça peut surement pas faire de mal à ceux qui en font déjà depuis un moment): http://www.linux-mag.com/2002-09/security_01.html(...)
Ba la tour Montparnasse Infernale entre potes en fin de soirée après une cuite ça passe encore. Mais c'est vrai qu'à jeun c'est assez lourd (même apès 12h de LAN).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Pour info ext3 c'est "juste" ext2+journalisation. Donc ça veut dire que si tu sais accéder à du ext2, tu sais accéder à du ext3 (ça sera juste un peu moins fiable puisque la journalisation ne sera pas activée).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
perso je n'ai pas envie de partager des fichiers a contenu ethiquement inacceptable. De plus legalement, je pense que tu es tout de meme responsable du contenu de ton disque dur, bref ca ne me tente pas.
C'est pas parce que eDonkey ne te tente pas que c'est pas utilisé non plus :)
et puis tout se casse :)
C'est pour ça que j'ai mis "impossible" entre guillemets. Je suis pas cryptologiste (logue?graphe?) mais pour ce que j'en ai compris, pour savoir qui partage quoi sur Freenet, c'est vraiment pas facile. Même avec des moyens conséquents..
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Soit tu livres tes cles dans la minute soit tu es tres mal barré.
Il est possible de faire un système de fichiers avec plusieurs niveaux de clés de telle manière qui soit "impossible" de savoir si tout a été décrypté ou s'il reste des données cryptées. Enfin si je me souviens bien de ce que j'ai lu là: http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf(...)
(oui je sais il parait qu'on doit dire chiffrer et pas crypter)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
J'utilise le même 17'' depuis plusieurs années et j'ai fait qq dizaines de LAN avec sans problème. Et pour une LAN tu laisses pas le moniteur s'acclimater 24h avant de l'allumer.
Si c'est parce que j'ai eu de la chance faut croire que (presque) tous ceux avec qui j'ai fait des LAN ont de la chance aussi alors. J'ai jamais vu qu'un seul cramage de moniteur (et c'était pas juste le moniteur, à mon avis c'était plutôt un problème d'alimentation).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Pour autant que je sache, la db de journaux/commentaires de DLFP ne contient pas une table juste pour les liens donc tu devrais quand même faire du parsing même avec un accès à la base. A moins de commencer à mettre une table pour les liens+description+mots clés qui serait complétée à chaque ajout d'un commentaire/journal, ce qui nécessite encore plus de travail mais c'est vrai que c'est surement la solution la plus "propre". Si ça t'intéresse, je pense que rien ne t'empèche de contacter les admins pour leur proposer l'idée et voir si ça peut être intégré si tu codes le patch. Ca sera aussi plus propre et efficace qu'un cron qui collecte tous les liens une fois par semaine :)
Pour la recherche par mots clés le pauvre serveur va peut être pas supporter mais pour le listing de liens ça ne devrait pas poser de problème.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
franchement le jour ou l'on voudra arreter le "piratage", tu peux me croire ce sera tres vite fait. les problemes sont juridiques, pas techniques, et la legislation est en train de s'adapter au piratage massif.
Ben y parait quand même qu'avec Freenet (yen a d'autres mais j'ai pas les noms sous la main), il est "impossible" de déterminer ce que tu upload/download. La solution technique ça serait de bloquer tout le traffic Freenet (en admettant qu'il soit reconnaissable) mais bon...
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Quand tu veux porter plainte contre quelqu'un dont tu connais uniquement l'IP, je pense que tu es censé porter plainte contre X et l'IP est "juste" un indice. Après si la justice juge que c'est nécessaire, elle va demander à l'ISP de lui donner l'identité de la personne qui utilisait l'IP au moment des faits. Mais faut quand même prouver que cette personne a bien fait qq chose d'illégal. Des logs c'est pas des preuves pour autant que je sache. Pas plus qu'une photo ou une vidéo.
Mais bon JNSPJ :op
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: non
Posté par Krunch (site web personnel) . En réponse au message pages perso attente pour force brute. Évalué à 2.
http://pear.php.net/package/File_Passwd/docs/0.9.2a/File_Passwd/Fil(...)
Par ailleurs maintenant que tu as dit comment tu trouvais tes mdp, il est bcp plus facile (moins difficile en tout cas) de les cracker :op
Pour éviter d'avoir plusieurs fois le même script qui tourne en parrallèle, on utilise des verrous: tu bloques un verrou au début du script et tu le libéres à la fin. Après tu vérifies si le verrou est bloqué, si c'est le cas le script est en train de tourner. En pratique tu peux utiliser flock() ou une entrée dans une base de données (MySQL sur un P133 avec 48Mo de RAM c'est pas top cependant). Le truc à _ne_ _pas_ faire est d'utiliser un bête fichier genre
Parce que tu n'est pas certains que le fichier n'aura pas été verrouillé par un autre process entre la fin du while et le début du create_file(). Enfin dans 99% des cas sur une machine mono processeur ça ne devrait pas poser de problème mais de toute façon il vaut mieux utiliser flock() qui est fait pour ça (mais c'est pas super portable). Dans ton cas tu peux écrire la date (temps epoch) de la dernière tentative d'authentification dans une db ou un fichier (mais dans ce cas tu dois quand même utiliser flock()) et vérifier que le délais est respecté.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# pareil
Posté par Krunch (site web personnel) . En réponse au journal sarge sur ppc. Évalué à 3.
apt-get install xlibs && /etc/init.d/xdm restart
Ca marche. Ca doit avoir un rapport avec XKB mais j'ai pas cherché plus loin.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: non
Posté par Krunch (site web personnel) . En réponse au message pages perso attente pour force brute. Évalué à 2.
Si le but c'est juste de faire croire que c'est sécurisé au premier neuneu venu alors je sais pas pourquoi tu as demandé de l'aide ici.
Je comprends pas pourquoi tu veux pas utiliser les htaccess.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Netinst current.
Posté par Krunch (site web personnel) . En réponse au message La planete Debian gravite autour d'un noir soleil. Évalué à 3.
Par ailleurs ya un passage sur les disque SATA dans la FAQ de l'installateur.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Netinst current.
Posté par Krunch (site web personnel) . En réponse au message La planete Debian gravite autour d'un noir soleil. Évalué à 3.
J'ai installé une Sarge il y a encore 2 jours sans problème (mais j'ai jamais essayé le 2.6 non plus en fait).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: non
Posté par Krunch (site web personnel) . En réponse au message pages perso attente pour force brute. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: non
Posté par Krunch (site web personnel) . En réponse au message pages perso attente pour force brute. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: non
Posté par Krunch (site web personnel) . En réponse au message pages perso attente pour force brute. Évalué à 2.
Sinon pour le transfert de fichiers sans FTP/MSN/... -> http://linuxfr.org/tips/296.html(...)
Pour en revenir à cette histoire de mdp, si tu as gardé le même fonctionnement, pas besoin d'utiliser de mdp. Le seul "secret" à connaitre est l'url. Pour protéger les répertoires, le htaccess est probablement la meilleure solution. Je pense que ça le fait même récursivement.
Le délais de 3 secondes empéche rien: qqun peut brute-forcer tranquillement avec X connexions en paralléle, il aura juste les résultat de chacune 3 secondes plus tard mais rien ne l'empèche de refaire une requète avant que le délais se soit écoulé. Et en fait il a même pas besoin de faire ça, il a juste à "brute-forcer" l'url.
Un truc plus "sécurisé" serait de faire une page PHP qui prend 2 paramètres: le mdp et le fichier à accéder. Si le mdp est correct mais que le fichier à accéder n'existe pas, tu "fournis" un listing des fichiers. Si le mdp est correct et le fichier existe, tu renvois directement le fichier. De cette manière tu peux interdire complétement l'accés aux fichiers directement via Apache: on ne peut y accéder que par l'interface web. Mais il faut faire très attention aux fichiers accessibles (gaffe aux trucs genre .. et liens symboliques). Idéalement tu devrais avoir le listing des fichiers accessibles défini explicitement dans un fichier de configuration par exemple.
Ce genre de script existe déjà, suffit de chercher un peu. Enfin pour le mdp je suis pas sur mais ça tu peux le rajouter au niveau d'Apache et comme ça tu n'as qu'une seule page à protéger.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# non
Posté par Krunch (site web personnel) . En réponse au message pages perso attente pour force brute. Évalué à 3.
Maintenant si tu veux un "vrai" accés par mdp, tu vas devoir soit tout mettre dans la même page PHP protégée par elle même (affichage de la page uniquement si le mdp est correct, pas moyen de contourner comme c'est le cas dans ton exemple), soit utiliser les sessions et les cookies pour protéger les autres pages (accès que si le cookie est bon et le cookie ne peut être mis que par la page de login, ou un truc comme ça, j'ai jamais touché à ça), soit utiliser une protection au niveau d'Apache comme suggéré plus haut, qui va te permettre de protéger tout le répertoire du même coup.
A mon avis, la solution la plus facile/rapide à mettre en place est celle des htaccess. C'est pas plus compliqué que ta solution, ça l'est même moins: t'as pas à faire de PHP, t'as juste à maintenir un fichiers d'utilisateurs/mdp. Si tu veux tu peux t'amuser à faire une interface PHP pour gérer le fichier. Si tu veux vraiment pas avoir à taper un login mais juste un mdp, alors amuse toi avec les sessions/cookies ou intégre tout dans la même page si c'est possible.
Pour le problème du brute-force. Avec le système actuel, le méchant n'a qu'à brute-forcer un URL ou un mdp, le plus faible des deux. Avec le htaccess, il doit brute-forcer un login+mdp (en admettant que le login reste "secret" aussi). De toute façon toute application de ce genre est "brute-forçable". Si tu penses que ça en vaut la peine, tu as plusieurs solutions pour limiter les risques. Le plus simple est probablement de bien choisir le mdp, après tu peux t'arranger pour qu'on ne puisse pas faire plus de X tentatives de login par heure (mais pas avec des cookies, du JS ou autre truc "client-side", dans ce cas ça sert à rien et ça fait chier les visiteurs) ou commencer à chercher un système d'authentification plus correct (à coups de PGP/SSL/TLS/... par exemples) mais ça devient tout de suite plus lourd. Yavait un article sur l'authentification par mdp dans le Linux Magazine France du mois dernier je pense (si qqun avec le magazine sous la main peut confirmer...). Ca peut peut-être t'intéresser.
Personnellement, j'ai un serveur FTP avec un compte "invité" qui me sert de temps en temps ("hé pq je peux pas t'envoyer de fichiers par MSN?"). Le mdp change aléatoirement toutes les X heures et il est enregistré dans un fichier auquel moi seul ai accés. Avec ça, bonne chance pour le brute-force. Faut voir si ça peut être applicable à ton cas. Dans le même genre, voir http://slashdot.org/comments.pl?sid=111503&cid=9469343(...)
Le mdp est généré par exemple par un md5 de la somme de l'heure actuelle et du "vrai" mdp (une truc plus correct serait genre md5(md5(time).md5(passwd)), le "." pour la concaténation). Comme ça, toute personne qui a le "vrai" mdp peut reconstituer le mdp actuel mais il change toutes les X heures/minutes. Tu peux aussi t'arranger pour que le mdp change après que qqun se soit loggué, comme ça si la connexion est sniffée, l'attaquant ne sait quand même pas obtenir le mdp puisqu'il a déjà changé (mais bon dans ce cas tu as d'autres problèmes).
Par ailleurs je recommande la lecture de cet article-ci à tous ceux qui débutent dans les applications web (et ça peut surement pas faire de mal à ceux qui en font déjà depuis un moment): http://www.linux-mag.com/2002-09/security_01.html(...)
Pour le coup des md5, vaut mieux comprendre ce qu'on fait avant de l'implémenter. Voir par exemple dans le même magazine: http://www.linux-mag.com/2002-09/cryptography_01.html(...)
-- Krunch le parano
PS: désolé pour les anglicismes et fautes d'orthographes/grammaire mais il est 3h30 passé là
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: je m'insurge
Posté par Krunch (site web personnel) . En réponse au sondage Parmi ces films, le plus naze est. Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# supair
Posté par Krunch (site web personnel) . En réponse au journal Le village d'Apt. Évalué à 2.
Quelle vie trépidante nous avons nous les debianeux/euses/istes/ien/iennes.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Woody?
Posté par Krunch (site web personnel) . En réponse au journal Sarge décision. Évalué à 0.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# FreeDNS
Posté par Krunch (site web personnel) . En réponse au message Héberger son site chez soi. Évalué à 3.
http://freedns.afraid.org/(...)
http://www.no-ip.com/(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: peut-être...
Posté par Krunch (site web personnel) . En réponse au message smp. Évalué à 2.
3.0
$ dmesg | grep ^Processors:
Processors: 2
$ uname -r
2.4.18-1-686-smp
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mais encore?
Posté par Krunch (site web personnel) . En réponse au message live cd perso. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Heu
Posté par Krunch (site web personnel) . En réponse au message logiciel de caisse. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# mais encore?
Posté par Krunch (site web personnel) . En réponse au message live cd perso. Évalué à 2.
Au fait tu n'as besoin d'être root que pour utiliser mount et losetup.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: X3 ?
Posté par Krunch (site web personnel) . En réponse au message Partition X3 sous Windows. Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: oui mais non
Posté par Krunch (site web personnel) . En réponse au journal Casier judiciaire privé. Évalué à 2.
C'est pour ça que j'ai mis "impossible" entre guillemets. Je suis pas cryptologiste (logue?graphe?) mais pour ce que j'en ai compris, pour savoir qui partage quoi sur Freenet, c'est vraiment pas facile. Même avec des moyens conséquents..
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: oui mais non
Posté par Krunch (site web personnel) . En réponse au journal Casier judiciaire privé. Évalué à 2.
(oui je sais il parait qu'on doit dire chiffrer et pas crypter)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # hu?
Posté par Krunch (site web personnel) . En réponse au journal cramage de moniteur. Évalué à 2.
Si c'est parce que j'ai eu de la chance faut croire que (presque) tous ceux avec qui j'ai fait des LAN ont de la chance aussi alors. J'ai jamais vu qu'un seul cramage de moniteur (et c'était pas juste le moniteur, à mon avis c'était plutôt un problème d'alimentation).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: shut up and code
Posté par Krunch (site web personnel) . En réponse au journal Lister les liens dans les journaux. Évalué à 2.
Pour la recherche par mots clés le pauvre serveur va peut être pas supporter mais pour le listing de liens ça ne devrait pas poser de problème.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: oui mais non
Posté par Krunch (site web personnel) . En réponse au journal Casier judiciaire privé. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Petite information au passage
Posté par Krunch (site web personnel) . En réponse au journal Casier judiciaire privé. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: oui mais non
Posté par Krunch (site web personnel) . En réponse au journal Casier judiciaire privé. Évalué à 3.
Mais bon JNSPJ :op
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.