Archives de la liste de diffusion ptafflist

FS sécure

FS sécure

stefan michalowski <mitch (à)

(à)

ptaff.ca>

2004-11-29 09:37:06 EST

Bonjour,

Un article sur freshmeat.net qui décrit comment faire un fs encrypté
avec acl. En français, ça veut dire qu'on créer une partition qui est
encrypté, donc à moins d'avoir le mot de passe on ne peut la lire, et
qui permet un contrôl plus fin des permissions avec acl (pas besoin de
passer par les groups de Unix pour ajouter de la visibilté à certains
usagers).

http://freshmeat.net/articles/view/1387/

Ce que je trouve intéressant dans tout ça, c'est qu'il est possible de
créer un fichier pour contenir la partition. Comme l'auteur le mentionne
à la fin de son article, c'est un excellent moyen de garder des fichiers
confidentiels.

Bien à vous,

--
Stefan "Mitch" Michalowski
a.k.a. DjDelovsky
Email: mitch (à)

(à)

ptaff.ca

Re: FS sécure

Patrice Levesque <wayne (à)

(à)

ptaff.ca>

http://ptaff.ca/

2004-11-29 09:51:17 EST

> Ce que je trouve intéressant dans tout ça, c'est qu'il est possible de
> créer un fichier pour contenir la partition. Comme l'auteur le mentionne
> à la fin de son article, c'est un excellent moyen de garder des fichiers
> confidentiels.

C'est beaucoup de trouble, il faut souvent de bonnes permissions pour
monter/démonter ce genre de partitions, s'assurer que le kernel supporte
les routines de chiffrement aussi. Bien que pratique quand il y a
beaucoup de fichiers, pour un seul fichier OpenSSL fait bien le travail:

$ # Cree 'crypt_file' à partir de 'clear_file'
$ openssl enc -e -rc4 -in clear_file -out crypt_file

$ # Retrouve 'clear_file' à partir de 'crypt_file'
$ openssl enc -d -rc4 -out clear_file -in crypt_file

Cet exemple utilise 'RC4', il existe un char et une barge de méthodes de
chiffrement que je ne saurais classer.

--
--====|====--
--------================|================--------
Patrice Levesque
http://ptaff.ca/
wayne (à)

(à)

ptaff.ca
--------================|================--------
--====|====-- GPG: http://ptaff.ca/k.asc ID 9212A432
--

Pièces jointes

Signature PGP

Re: FS sécure

stefan michalowski <mitch (à)

(à)

ptaff.ca>

2004-11-29 09:55:22 EST

Patrice Levesque wrote:

>>Ce que je trouve intéressant dans tout ça, c'est qu'il est possible de
>>créer un fichier pour contenir la partition. Comme l'auteur le mentionne
>>à la fin de son article, c'est un excellent moyen de garder des fichiers
>>confidentiels.
>
>
> C'est beaucoup de trouble, il faut souvent de bonnes permissions pour
> monter/démonter ce genre de partitions, s'assurer que le kernel supporte
> les routines de chiffrement aussi. Bien que pratique quand il y a
> beaucoup de fichiers, pour un seul fichier OpenSSL fait bien le travail:
>
> $ # Cree 'crypt_file' à partir de 'clear_file'
> $ openssl enc -e -rc4 -in clear_file -out crypt_file
>
> $ # Retrouve 'clear_file' à partir de 'crypt_file'
> $ openssl enc -d -rc4 -out clear_file -in crypt_file
>
> Cet exemple utilise 'RC4', il existe un char et une barge de méthodes de
> chiffrement que je ne saurais classer.

Ou encore, il est possible d'utiliser gpg pour encrypter un fichier.

Le but que je voyais c'est d'avoir plusieurs documents encryptés de
manière transparente. De plus, il est possible de les editer directement
du fs crypté, sans avoir à faire des commandes de
décryptions/encryptions. Évidemment, ça demande tous les cosins dans le
kernel, et ça risque de ne pas fonctionner ailleurs que sous Linux..

Bien à vous,

--
Stefan "Mitch" Michalowski
a.k.a. DjDelovsky
Email: mitch (à)

(à)

ptaff.ca

Re: FS sécure

Sebastien Berube <berube (à)

(à)

ca.ibm.com>

2004-11-29 11:06:35 EST

En fait cryptFS est super intéressant du fait que tu peux encrypter ton
root fs. Ce qui veux dire que lorsque tu boot, tu dois entrer ton
passphrase pour decrypter ton / avant meme de commencer a booter :) C'est
surtout intéressant pour des laptop ou des systèmes dans des endroits
ouverts... Parce-que tu veux probablement avoir tes cookies encryptées et
aussi tes fichiers de config (c'est facile de mettre un HD dans une machine
et juste monter le filesystem et tu as accès a tout les fichiers du disque
étant donné que tu es déjà root localement)

Bah, certains croient que c'est un peu trop parano.

--
Sébastien Bérubé
(514) 964-1828
berube (à)

(à)

ca.ibm.com

Search engines

Eric Maziade <maze (à)

(à)

novisoft.com>

2004-12-03 18:44:10 EST

J'ai retrouvé l'article dont je parlais plus tôt..

19 common mistakes that prevent your Web site from showing up on search
engines
http://www.axandra.com/news/search-engine-ranking.htm

Les points plus en particulier: #8 et #9

Reason #8: You have moved your site to a new server.

[...]

Every time you move a Web site to a Web hosting company, or when you change
the domain name, the IP/DNS address of your domain name changes. While
people see URLs (www.yourdomain.com), search engines often only see IP
addresses.

This means that you need to re-submit your Web site to all search engines
and directories when you move your Web site to a new Web hosting company or
when you change your domain name. In time, search engines will realize that
your IP/DNS address has changed and will remove the old IP address from
their index.

[...]

Reason #9: Your Web page does not have unique IP address.

[...]

There are 3 reasons why you need a unique IP address:

If you're sharing an IP address with 50 other sites, you're trusting them
not to over-submit or spam the search engines. When a search engine blocks
an IP address, all the sites that are sharing that IP address are blocked.
You could wind up being banned from the search engine.

If the server or the search engine spider software is misconfigured, the
search engine spider may end up obtaining a Web page from another domain
with the same IP address. This may mean that the other Web site gets indexed
instead of yours, or your Web site will be found for the keywords which are
applicable to the other site.

Rumor has it that having your own unique IP address may help your search
engine ranking.
So when you select a Web hosting service, make sure that your domain name
has a unique IP address, even if it means that you have to pay a bit more
for your hosting.

[...]

Je suis pas très convaincu par #8 - messemble que ça serait curieux de
cataloguer seulement par ip ... malgré que l'économie en storage... hmmm...

Re: Search engines

Patrice Levesque <wayne (à)

(à)

ptaff.ca>

http://ptaff.ca/

2004-12-03 20:06:31 EST

> Je suis pas très convaincu par #8 - messemble que ça serait curieux de
> cataloguer seulement par ip ... malgré que l'économie en storage... hmmm...

Rares sont les sites qui sont seuls sur un IP. A part les betes comme
slashdot, quand t'as 50 visiteurs par jour, ca donne rien d'avoir.

--
--====|====--
--------================|================--------
Patrice Levesque
http://ptaff.ca/
wayne (à)

(à)

ptaff.ca
--------================|================--------
--====|====-- GPG: http://ptaff.ca/k.asc ID 9212A432
--

Pièces jointes

Signature PGP

Re: Search engines

Sebastien Berube <berube (à)

(à)

ca.ibm.com>

2004-12-03 23:13:41 EST

Pas rienque ca mais ca va à l'encontre de l'implantation de la version 1.1
du protocol HTTP qui permet (et encourage) dans ta requete HTTP de
spécifier un HOST: www.xyz.net pour spécifier quel site sur une addresse IP
tu veux accéder. Cette implantation à été faite pour palier avec le
problème de "address space depletion". Ce qui me fait douter des deux
points mentionner ci-bas...

--
Sébastien Bérubé
(514) 964-1828
berube (à)

(à)

ca.ibm.com

Pièces jointes

attr5oqy.dat

RE: Search engines

Eric Maziade <maze (à)

(à)

novisoft.com>

2004-12-04 10:42:55 EST

Après réflexion, je suis capable d'imaginer plein d'avantages à une
indexation par IP au lieu de par nom de domaine...

Mais comme je me souviens plus très très bien de comment un request
fonctionne...

Q: Si tu accède à un URL par IP, est-ce que t'as besoin de passer par un
DNS?

J'imaginerais facilement un gain de performance au niveau des crawlers... je
sais pas à quelle fréquence Google reindexe (j'imagine qu'il fait ça à temps
plein...)

Probablement un gain de vitesse à indexer des digits au lieu de strings...
Même si y'a le même IP pour plusieurs site, ça aiderait pareille, tant qu'il
est statique. Si le bon site répond pas à l'IP, faudrait retrouver l'IP
avant de crawler. Enfin, pures spéculations...

RE: Search engines

Sebastien Berube <berube (à)

(à)

ca.ibm.com>

2004-12-04 10:52:17 EST

Si tu parles d'un avantage à faire un lookup DNS versus se connecter à un
IP directement (induction d'un delais moyens de 20 à 30 ms pour un query
DNS à partir d'un lien haute vitesse), l'avantage est inexistant. Si tu
induit une latence supplémentaire au niveau reseau pour chacun de tes
crawlers, ca te permet simplement de partir plus de crawler à la fois sans
plus surcharger le système qui manage tes crawlers...

Si tu parles de la quantité de bits passées pour l'excedant d'information
du header http pour inclure une directive host, c'est négligeable versus la
taille de la page transférée.

J'y vois pas vraiment d'avantage à part comme tu dis pour manager des
indexes plus petits pour les search engines, mais je crois qu'au point ou
ils sont rendu (8 milliard de pages indexés pour google) ils s'en tappent
probablement :D

--
Sébastien Bérubé
(514) 964-1828
berube (à)

(à)

ca.ibm.com

RE: Search engines

Eric Maziade <maze (à)

(à)

novisoft.com>

2004-12-04 12:32:16 EST

C'est quoi comme différence de taille? Il me semble que quand t'as 8
milliards de pages (ou je sais pas combien de petabytes de trucs), chaque
petit bit ou microseconde a un poid important, non?

RE: Search engines

Sebastien Berube <berube (à)

(à)

ca.ibm.com>

2004-12-04 12:34:41 EST

Oui et non, ca peux sembler beaucoup si tu compte la différence en fait de
bytes, mais en pourcentage, ca représente presque rien. On parles du
statement "Host: " et du nom de domaine demandé, donc en moyenne peut-être
32 bytes (pour prendre un chiffre rond). Lorsque tu download l'HTML d'une
page (j'ai aucune idée c'est quoi la moyenne de taille d'une page html,
mais mettons 32K de tags et de texte en average - encore une fois pour
prendre un chiffre rond). Donc on parles de 32 bytes sur 32768 bytes total
de ta requête... soit 0.09%

Bon, tu vois l'idée meme si mes chiffres ne sont peut-être pas exacts...
C'est vraiement rien. Et oublie pas, dans le design du protocol HTTP, tu
as un pannel d'experts qui ont révisé le RFC quelques fois avant de le
publier... :) Je pense qu'ils savent ce qu'ils font (plus que moi en tout
cas - malgré presque 10 ans d'expérience).

--
Sébastien Bérubé
(514) 964-1828
berube (à)

(à)

ca.ibm.com

RE: Search engines

Eric Maziade <maze (à)

(à)

novisoft.com>

2004-12-05 11:52:14 EST

Tu peux pas juste regarder les pourcentages... avec un tel volume, même les
pourcentages minimes deviennent significatifs.

Y'avait un bel exemple de ça dans l'article que Patrice nous a shooté plus
tôt cette semaine... je me souviens plus des chiffres, malheureusement :(
Je pense que ça parlais des minimes pourcentages de failiures (comment on
dis-ca en français, encore?) sur les disques durs qu'ils utilisent qui
deviennent tout à coup très significatifs en relation avec les volumes de
données qu'ils ont à traiter...

J'ai l'impression que les staff de développement des engins de recherche
doivent avoir "optimisation" de tatoué à l'envers sur le front et qu'un
side-mirror viens standard avec les postes de travail...

Je parles pas du côté requête, je parles plutôt du côté indexation... Je
penses pas que HTTP a été designé avec des engines qui s'amusent à réindexer
continuellement le monde en tête :)

RE: Search engines

Sebastien Berube <berube (à)

(à)

ca.ibm.com>

2004-12-05 11:58:57 EST

En re-pensant a notre thread, je crois qu'on est TOUS dans le champ... Je
serais TRES surpris que les search engines indexent par URL. Après tout,
c'est le contenu qu'on cherche, pas l'URL ni l'addresse IP. Et tu indexes
sur ton champ de recherche non?

--
Sébastien Bérubé
(514) 964-1828
berube (à)

(à)

ca.ibm.com

Re: Search engines

Patrice Levesque <wayne (à)

(à)

ptaff.ca>

http://ptaff.ca/

2004-12-05 12:09:34 EST

> En re-pensant a notre thread, je crois qu'on est TOUS dans le champ... Je
> serais TRES surpris que les search engines indexent par URL. Après tout,
> c'est le contenu qu'on cherche, pas l'URL ni l'addresse IP. Et tu indexes
> sur ton champ de recherche non?

Et Google ne fait que dire qu'il a trouvé ce que tu cherches, il ne te
donne pas d'URI ensuite?

Et puisque tu parles de google, comment expliquer des requêtes comme:

http://www.google.com/search?q=site%3Afoobar.com
http://www.google.com/search?q=related%3Afoobar.com

S'il n'y a pas d'index sur les URI?

Faut pas oublier que ce qui donne un PageRank dans Google c'est le
nombre de pages Q qui pointent vers une page P. Le PageRank de P est
aussi calculé en fonction du PageRank des pages Q. Le contenu des pages
P et Q pourrait ne pas être lié (sauf par hyperliens) et ça ne
changerait pas grand chose à la recette.

--
--====|====--
--------================|================--------
Patrice Levesque
http://ptaff.ca/
wayne (à)

(à)

ptaff.ca
--------================|================--------
--====|====-- GPG: http://ptaff.ca/k.asc ID 9212A432
--

Pièces jointes

Signature PGP

RE: Search engines

Eric Maziade <maze (à)

(à)

novisoft.com>

2004-12-05 16:19:50 EST

Y'a un index par URL, pas vraiment le choix - difficile autrement de scorer
en regardant qui pointe vers qui...

Re: Search engines

stefan michalowski <mitch (à)

(à)

ptaff.ca>

2004-12-04 11:06:36 EST

Eric Maziade wrote:

> Après réflexion, je suis capable d'imaginer plein d'avantages à une
> indexation par IP au lieu de par nom de domaine...
>
> Mais comme je me souviens plus très très bien de comment un request
> fonctionne...
>
> Q: Si tu accède à un URL par IP, est-ce que t'as besoin de passer par un
> DNS?
>
> J'imaginerais facilement un gain de performance au niveau des crawlers... je
> sais pas à quelle fréquence Google reindexe (j'imagine qu'il fait ça à temps
> plein...)
>
> Probablement un gain de vitesse à indexer des digits au lieu de strings...
> Même si y'a le même IP pour plusieurs site, ça aiderait pareille, tant qu'il
> est statique. Si le bon site répond pas à l'IP, faudrait retrouver l'IP
> avant de crawler. Enfin, pures spéculations...

C'est bien beau, mais Apache et autres serveurs web, permettent d'avoir
différent sites sur le même IP par Virtual hosting. C'est parce que tu
accède http://www.gaga.com que Apache va te retourner le index.html dans
/var/www/gaga_site et non pas le index.html dans /var/www/foobar_site.
Et comme la majorité des sites sont sur ce genre de config, les moteurs
de recherche se couperaient d'une énorme quantité de sites s'il ne
faisait que du IP crawling.

Après-tout l'espace IP disponible est relativement petit comparé à la
quantité de sites web. Je ne parle de l'espace IP théorique, mais de
l'espace qui est pratiquement disponible. N'oublions pas que les IP
classe A enlèvent des énormes quantités d'IP et qu'elles sont réservés à
une seule compagnie pour chaque set (comme 47.x.x.x qui est pris par
Nortel Networks).

Bien à vous,

--
Stefan "Mitch" Michalowski
a.k.a. DjDelovsky
Email: mitch (à)

(à)

ptaff.ca

RE: Search engines

Eric Maziade <maze (à)

(à)

novisoft.com>

2004-12-04 12:34:42 EST

Nan, je pensais pas à prendre l'ip pour faire le crawling, mais juste pour
rejoindre le dns du host plus directement... (Mais comme je me souviens plus
exactement de comment la dance du domain name resolution fonctionne... :P)

RE: Search engines

Sebastien Berube <berube (à)

(à)

ca.ibm.com>

2004-12-04 13:06:38 EST

Tres simple. Tu parles à TON DNS server, si il connais pas (pas dans son
cache ou authoritaire), il est habituellement configuré pour forwarder vers
des DNS top level domain ou passer par d'autres qui vont les forwarder en
bout de ligne vers les top level dns server (les grands manitous du DNS) et
si un des grands manitous n'as pas pas la zone ou le record caché, il
retrouve le name server authoritaire du domaine et lui forward la requête.
Le serveur authoritaire est le "propriétaire" de la zone DNS, alors il est
obligatoire qu'il connaisse la réponse à la requête demandée (même si la
réponse est que ca existe pas ce que tu cherches).

Oui, le protocol permet l'induction de délais potentiellement élevés (c'est
pour ca que le protocol implémente beaucoup de caching) mais comme
mentionner au paravant, pour palier avec la latence, on compense souvent
par le parallelisme des processus. Aussi, il est a noter que pour crawlé
un site de 500 pages, cette "danse" est exécuter une seule fois.

--
Sébastien Bérubé
(514) 964-1828
berube (à)

(à)

ca.ibm.com

Re: Search engines

Patrice Levesque <wayne (à)

(à)

ptaff.ca>

http://ptaff.ca/

2004-12-04 11:07:12 EST

> Q: Si tu accède à un URL par IP, est-ce que t'as besoin de passer par un
> DNS?

Non. Cependant, comme le faisait remarquer Seb, depuis HTTP/1.1, c'est
très recommandé de passer le nom du host en header pour permettre
d'avoir du virtual hosting. Démonstration:

$ telnet 213.186.41.103 80
Connected to 213.186.41.103.
Escape character is '^]'.
GET / HTTP/1.1
Host: foobar.ca

<html>.....</html>

Alors, si le search engine sait que foobar.ca est à l'adresse IP
213.186.41.103, effectivement il n'y a pas de besoin de résoudre quelque
DNS que ce soit. Même idée si fredbarney.ca est au même IP aussi.

S'il n'y a qu'un site sur l'IP, le "Host: " peut être bypassé. Mais au
pif c'est < 1% du 'namespace web'.

> J'imaginerais facilement un gain de performance au niveau des crawlers... je
> sais pas à quelle fréquence Google reindexe (j'imagine qu'il fait ça à temps
> plein...)

On gagne de la performance, mais dans la vraie vie, un site web même sur
une IP statique a beaucoup de chances de changer de fournisseur (ou le
fournisseur changer de fournisseur), ne serait-ce qu'une fois. Un engin
de recherche ne peut pas se permettre d'ignorer tout ce qui a déménagé
une fois. De plus, je ne sais pas comment pourraient être gérés les IP
multiples (le contraire du virtual hosting, plusieurs IP pour un seul
nom de domaine) avec un hashtable statique; typiquement ces IP sont
"jetables", pour permettre un failover s'il y a un des serveurs qui
crash.

Google vient visiter ptaff.ca régulièrement (à peu près tous les jours),
cependant rumeur veut que tous les mois il y ait un "GoogleDance" qui
semble être plus majeur comme reconstruction d'index.

> Probablement un gain de vitesse à indexer des digits au lieu de strings...
> Même si y'a le même IP pour plusieurs site, ça aiderait pareille, tant qu'il
> est statique. Si le bon site répond pas à l'IP, faudrait retrouver l'IP
> avant de crawler. Enfin, pures spéculations...

Le trouble qu'étant donné HTTP/1.1, la plupart des serveurs vont
renvoyer une page générique si le virtualhost "Host: " fourni n'existe
pas. Alors si j'essaie de bypasser les DNS et que je force une requête
(Host:) sur le mauvais serveur, je vais me retrouver souvent avec une
page valide, juste pas la bonne page. Alors c'est difficile de savoir
si c'est le bon contenu qui est reçu.

--
--====|====--
--------================|================--------
Patrice Levesque
http://ptaff.ca/
wayne (à)

(à)

ptaff.ca
--------================|================--------
--====|====-- GPG: http://ptaff.ca/k.asc ID 9212A432
--

Pièces jointes

Signature PGP

RE: Search engines

Eric Maziade <maze (à)

(à)

novisoft.com>

2004-12-04 12:36:07 EST

Ouaip. Mais est-ce que c'est possible, si on a l'ip d'aller direct sur le
dns du host (j'assume que le host doit avoir son propre dns) pour poster la
requête et se sauver du processing?

Re: Search engines

Patrice Levesque <wayne (à)

(à)

ptaff.ca>

http://ptaff.ca/

2004-12-04 13:07:15 EST

> Ouaip. Mais est-ce que c'est possible, si on a l'ip d'aller direct sur le
> dns du host (j'assume que le host doit avoir son propre dns) pour poster la
> requête et se sauver du processing?

Je ne comprends pas ce que tu impliques par "DNS du host". Si je sais
que "foobar.com" est sur un IP en particulier, on a pas besoin d'achaler
un serveur DNS c.f. Le premier point de mon reply (remis plus bas).

Si par "DNS du host" tu veux dire "Adresser un site web en particulier
sur une adresse IP", il ne s'agit pas de DNS puisqu'il n'est pas
question de trouver un IP - on le sait d'avance pour se rendre sur ce
serveur.

> > Q: Si tu accède à un URL par IP, est-ce que t'as besoin de passer par un
> > DNS?
>
> Non. Cependant, comme le faisait remarquer Seb, depuis HTTP/1.1, c'est
> très recommandé de passer le nom du host en header pour permettre
> d'avoir du virtual hosting. Démonstration:
>
> $ telnet 213.186.41.103 80
> Connected to 213.186.41.103.
> Escape character is '^]'.
> GET / HTTP/1.1
> Host: foobar.ca
>
> <html>.....</html>
>
>
> Alors, si le search engine sait que foobar.ca est à l'adresse IP
> 213.186.41.103, effectivement il n'y a pas de besoin de résoudre quelque
> DNS que ce soit. Même idée si fredbarney.ca est au même IP aussi.
>
> S'il n'y a qu'un site sur l'IP, le "Host: " peut être bypassé. Mais au
> pif c'est < 1% du 'namespace web'.

--
--====|====--
--------================|================--------
Patrice Levesque
http://ptaff.ca/
wayne (à)

(à)

ptaff.ca
--------================|================--------
--====|====-- GPG: http://ptaff.ca/k.asc ID 9212A432
--

Pièces jointes

Signature PGP

Re: Search engines

stefan michalowski <mitch (à)

(à)

ptaff.ca>

2004-12-04 15:35:16 EST

Un peu de théorie, ce que je comprends, corrigez-moi s'il y a lieu.

*Les paquets*

Un paquet de http ressemble à ça:

[ IP ( TCP { HTTP } ) ]

Dans le header de l'IP, on peut juste avoir l'adresse IP de la machine
où on envoit notre request. Dans le header TCP, on a de l'information de
redondance et de tracking si on a besoin de découper notre message en
sous-paquet. Finalement, dans le header/data de HTTP on aura le nom de
domaine du serveur que l'on crawle, si on utilise HTTP 1.1.

Pour avoir l'IP de notre machine, dont on connaît initialemment
seulement le nom, il faut faire une requête DNS:
[ IP ( TCP { DNS } ) ]

Une fois que le nom est résolu, notre stack TCP/IP (ou est-ce une app
resolver) va le garder en cache , donc plus besoin de faire de
résolution future (évidemment, ça dépend de la grosseur de la cache et
du temps de vie qu'on donne aux données dans la cache).

Comme la fonctionnalité d'une cache est de résoudre ce qui est connu,
lorsque un domain name inconnu est demandé, le système fait une requête
DNS et remplis la cache avec le résultat.

On peut aussi utilise UDP au lieu de TCP pour les 2 protocoles, mais je
pense que TCP est le plus commun.

Une fois ceci pris en compte est-ce qu'un moteur de recherche qui ne
fonctionne que par ip serait plus rapide? Je ne sais pas. Si on se
configure un crawler avec une grosse cache de dns avec une vie de 3
mois, le premier scan sera lent, mais les prochains seront très rapides.

Mais la qualité d'un moteur de recherche n'est pas la rapidité avec
laquelle il crawl l'Internet mais bien les résultats qu'il donne, donc
il devrait saisir le plus de sites possibles.

Probablement on peut trouver sur netcraft une stat qui donne le nombre
de sites avec ip unique et le nombre de sites avec ip partagés.

ciao,

--
Stefan "Mitch" Michalowski
a.k.a. DjDelovsky
Email: mitch (à)

(à)

ptaff.ca

Re: Search engines

Patrice Levesque <wayne (à)

(à)

ptaff.ca>

http://ptaff.ca/

2004-12-04 15:41:28 EST

> Pour avoir l'IP de notre machine, dont on connaît initialemment
> seulement le nom, il faut faire une requête DNS:
> [ IP ( TCP { DNS } ) ]

DNS est UDP (précision, mais ça change rien au mécanisme)

> Une fois ceci pris en compte est-ce qu'un moteur de recherche qui ne
> fonctionne que par ip serait plus rapide? Je ne sais pas. Si on se
> configure un crawler avec une grosse cache de dns avec une vie de 3
> mois, le premier scan sera lent, mais les prochains seront très rapides.

Doit y avoir une grosse cache d'IP chez Google en effet; tant que c'est
une 'cache' et non pas des valeurs IP hardcodées dans leurs index, c'est
le même concept.

Pour le moteur PageRank de Google, puisqu'il est question du nombre de
liens qui pointent vers une page (domaine + path) et non vers une
adresse IP, à tout le moins s'ils gardent l'IP ils gardent aussi le nom
de domaine original; sinon comment savoir ensuite vers quelle page
"interne" pointe http://foobar.com/ sinon en transformant ça en IP?

--
--====|====--
--------================|================--------
Patrice Levesque
http://ptaff.ca/
wayne (à)

(à)

ptaff.ca
--------================|================--------
--====|====-- GPG: http://ptaff.ca/k.asc ID 9212A432
--

Pièces jointes

Signature PGP

RE: Search engines

Eric Maziade <maze (à)

(à)

novisoft.com>

2004-12-05 16:15:28 EST

>Mais la qualité d'un moteur de recherche n'est pas la rapidité avec
>laquelle il crawl l'Internet mais bien les résultats qu'il donne, donc
>il devrait saisir le plus de sites possibles.

Je dirais que la qualité d'un engin de recherche est une combinaison des
deux.

Je pourrais te faire l'engin de recherche le plus merveilleux au monde en
trente minutes... Mais ta réponse te viendrais dans les 48 heures (si y'a
pas trop de traffic)... pense pas que je scorerais très fort :)

Re: Search engines

Stefan Michalowski <illmnec (à)

(à)

sympatico.ca>

2004-12-05 20:39:12 EST

Eric Maziade wrote:

>>Mais la qualité d'un moteur de recherche n'est pas la rapidité avec
>>laquelle il crawl l'Internet mais bien les résultats qu'il donne, donc
>>il devrait saisir le plus de sites possibles.
>
>
> Je dirais que la qualité d'un engin de recherche est une combinaison des
> deux.
>
> Je pourrais te faire l'engin de recherche le plus merveilleux au monde en
> trente minutes... Mais ta réponse te viendrais dans les 48 heures (si y'a
> pas trop de traffic)... pense pas que je scorerais très fort :)

Attention! Tu melanges 2 choses! Il y a le crawler qui indexes les
sites, donc qui se promenent et rajoutent les nouveaux sites et le
nouveau contenu des sites dans la db, et il y a le moteur de recherche,
qui lui cherche dans la db ce que les gens soumettent. Le crawler doit
etre relativement lent, car ca prend pas mal de jus scanner et indexer
toutes les pages. De toute facon c'est pas grave si ca prend une semaine
pour generer la db, ce qui est important, comme tu le dis, c'est
l'interface usager, je soumets une requete et je veux une reponse
rapidement.

Ciao,

--
+-------------------------------------------------------+
| |
| Stefan Michalowski, M. Sc. |
| ------------------ |
| Email: illmnec (à)

(à)

sympatico.ca |
| GPG Key: http://screamerone.zapto.org/k.asc |
| ---------------------------------- |
| "Provider of Open Paradigm Shifts" |
| |
+-------------------------------------------------------+

Pièces jointes

signature.asc

RE: Search engines

Eric Maziade <maze (à)

(à)

novisoft.com>

2004-12-05 22:35:38 EST

Ouaip, je mélange indeed... Désolé :)

Mais pour démêler un peu, je persiste à croire que la rapidité de l'engin
fait aussi partie de sa qualité... on pourrait pas se permettre un engin qui
prend des années à réindexer, quand même! Mais je suis facilement prêt à
mettre la rapidité au second plan :)

Re: Search engines

Patrice Levesque <wayne (à)

(à)

ptaff.ca>

http://ptaff.ca/

2004-12-05 22:49:35 EST

> fait aussi partie de sa qualité... on pourrait pas se permettre un engin qui
> prend des années à réindexer, quand même! --

Google a une approche hybride à cet effet. S'il se rend compte qu'une
page est souvent mise à jour (site de nouvelles, blogues) il va avoir
tendance à y passer souvent (un signe c'est quand il y a une date à côté
du résultat lors d'une recherche dans Google). Il repasse quand même
régulièrement partout (environ 1 fois par mois), c'est ce que les plus
avisés appellent le "Google Dance"

http://dance.efactory.de/

--====|====--
--------================|================--------
Patrice Levesque
http://ptaff.ca/
wayne (à)

(à)

ptaff.ca
--------================|================--------
--====|====-- GPG: http://ptaff.ca/k.asc ID 9212A432

--

Pièces jointes

Signature PGP

RE: Search engines

Eric Maziade <maze (à)

(à)

novisoft.com>

2004-12-05 16:12:45 EST

Ouaip, c'est pas mal ce que voulais dire par là... Comme je disais plus tôt,
je ne me souviens plus précisement de toute l'architecture de la patente...
je la reconstitue comme je le peux...

Ce que je parle c'est du processus qui reçoit le URL une fois rendu chez le
host et qui regarde le domain name et renvoie ça à la bonne machine pour de
vrai - en ce qui me concerne, un rôle très similaire à un DNS...

Re: Search engines

stefan michalowski <mitch (à)

(à)

ptaff.ca>

2004-12-03 20:46:26 EST

Eric Maziade wrote:

> J'ai retrouvé l'article dont je parlais plus tôt..
>
> 19 common mistakes that prevent your Web site from showing up on search
> engines
> http://www.axandra.com/news/search-engine-ranking.htm
>
> Les points plus en particulier: #8 et #9
>
> Reason #8: You have moved your site to a new server.
>
> [...]
>
> Every time you move a Web site to a Web hosting company, or when you change
> the domain name, the IP/DNS address of your domain name changes. While
> people see URLs (www.yourdomain.com), search engines often only see IP
> addresses.
>
> This means that you need to re-submit your Web site to all search engines
> and directories when you move your Web site to a new Web hosting company or
> when you change your domain name. In time, search engines will realize that
> your IP/DNS address has changed and will remove the old IP address from
> their index.

C'est douteux toutes ces explications.. Une des raisons pour un ip fix:

- Rumor has it that having your own unique IP address may help your
search engine ranking.

Il paraît aussi que des scientifiques russes ont découvert une manière
de transformer de l'eau en or.. Devrais-je leur envoyer 10000$ pour
qu'il me transmette la recette? ehum...

Si on prend notre bon sens, on arrive à certaines conclusions:
1) Les crawlers suivent les liens, comme nous le faisons, donc même si
ton site est généré et qu'il a un ip qui change, tes liens ne changeront
pas (http://www.ptaff.ca pointe toujours à la même place pour le
contenu). Donc aucune influence sur ce point.
2) Il est certain que si tu es hosté par le même site qu'un gros
spammer, les crawlers vont éviter ton site à cause de blockage basé sur
l'ip, donc éviter les ips de spammer..
3) Il se peut que les charactère non-alpha dans les url mélange les
crawlers, mais il y a juste à utiliser un mod_rewrite ou l'équivalent
sur un autre server, pas rendre les pages statique..

En plus, la majorité des liens dans l'article n'existent plus.

mes 2 cents.

Ciao,

--
Stefan "Mitch" Michalowski
a.k.a. DjDelovsky
Email: mitch (à)

(à)

ptaff.ca

Propulsé par xhtmail

Copyright © 2005. Tous les messages et commentaires présentés dans ce document sont la propriété de leurs auteurs respectifs. ptaff.ca décline toute responsabilité quant aux propos exprimés dans ce cadre, lesquels n'engagent que leur auteur.