postgresql para almacenar documentos.

[Rodrigo Fuentealba]

El 8/03/07, Alvaro Herrera <[EMAIL PROTECTED]> escribió:
> Cristian Rodriguez escribió:
> > El 8/03/07, Alvaro Herrera <[EMAIL PROTECTED]> escribió:
> > > Lo
> > >que yo estaba diciendo era que PQexecParams permite evitarse el proceso
> > >de escapar el dato antes de enviarlo a la BD.
> >
> > Entonces el cristiano necesita usar la funcion  pg_query_params()  ;-P
>
> Por ahi si!  Gracias por el dato ...

Buena!

(Alvaro sigue odiando a PHP... cosas que no cambian)

En definitiva, gracias por los comentarios y antecedentes; Después de
haaarto Google con respecto a esto (y algunas otras ideas que vienen
del lado comercial de la fuerza), creo que de todas maneras guardaré
un archivo como bytea (como dijo Alvaro), guardando las diferencias
hacia atrás como RCS (como dijo el Doc, que era la solución "obvia
pero igual no la vi" para las inconsistencias entre documentos...) y
todavía no tengo claro lo que es xdelta; pero eso de "compresion", me
parece bueno. Cuando lo termine, si alguien quiere auditar el
resultado, todo OK.

Sobre KnowledgeTree, nosotros manejamos actualmente un software que es
más completo y complejo, llamado AM-Meridian, que es para Windows, y
que da opciones interesantes como comparar planos (CAD) entre muchas
otras cosas... pero no es OpenSource y es un parto escribir
aplicaciones que aprovechen la metadata que guarda sobre los
documentos.

-- 
Rodrigo Fuentealba Cartes
Desarrollador de Sistemas Web
Registered User 387639 - http://counter.li.org

postgresql para almacenar documentos.

[Alvaro Herrera]

Cristian Rodriguez escribió:
> El 8/03/07, Alvaro Herrera <[EMAIL PROTECTED]> escribió:
> > Lo
> >que yo estaba diciendo era que PQexecParams permite evitarse el proceso
> >de escapar el dato antes de enviarlo a la BD.
> 
> Entonces el cristiano necesita usar la funcion  pg_query_params()  ;-P

Por ahi si!  Gracias por el dato ...

-- 
Alvaro Herrera   Valdivia, Chile   ICBM: S 39º 49' 18.1", W 73º 13' 56.4"
Bob [Floyd] used to say that he was planning to get a Ph.D. by the "green
stamp method," namely by saving envelopes addressed to him as 'Dr. Floyd'.
After collecting 500 such letters, he mused, a university somewhere in
Arizona would probably grant him a degree.  (Don Knuth)
From [EMAIL PROTECTED]  Thu Mar  8 17:19:47 2007
From: [EMAIL PROTECTED] (Horst H. von Brand)
Date: Thu Mar  8 17:20:53 2007
Subject: Consulta VirtualHost+Centos 4.4
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

Ismael Cantieri <[EMAIL PROTECTED]> wrote:
> Renato Covarrubias dijo:

[...]

> > Que permisos tiene /home/ismael?
> > (ejecucion debe estar activado para otros en tu $HOME)
> >
> > Que permisos tiene /home/ismael/public_html?
> > (lectura y ejecucion deben estar activados para public_html)

> /home/ismael/public_html tiene permiso de lectura y ejecucion

Para quienes?

Permisos de /home, /home/ismael?

> ademas probe poniendo al usuario en el grupo apache y tampoco funciono.

Obvio. Que el usuario pertenezca al grupo (mala idea, en todo caso) no
hace que el grupo tenga permiso de hacer nada con los recursos del
usuario.

> por el mensaje se que es algo de permisos pero no doy en la tacla de que
> puede ser

Siga participando.

[Date una vueltita por todo el tema "permisos" en Unix, no es
 precisamente auto-intuitivo y me late que una vez que entiendas como
 funciona eso este problema se resolvera solo (y mas adelante te
 resultaran triviales de resolver cosas que hoy no sabrias por donde
 comenzar). Seguro en Wikipedia (o en ) hay
 discusiones detalladas al respecto.]
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de InformaticaFono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile   Fax:  +56 32 2797513
From [EMAIL PROTECTED]  Thu Mar  8 17:34:13 2007
From: [EMAIL PROTECTED] (Pablo Figueroa Alvarez)
Date: Thu Mar  8 17:35:16 2007
Subject: Cacti no grafica?
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

pero grafico alguna vez?
cuando configuras algun dispositivo o host te muestra algun error el SMTP?

On 3/8/07, Marco Bravo <[EMAIL PROTECTED]> wrote:
> En realidad no se ha modificado nada...
>
> En esa maquina tengo nagios funcionando sin problema y cacti solo no
> grafica, el resto muestra todo...
>
>
>
> El día 8/03/07, Pablo Figueroa Alvarez <[EMAIL PROTECTED]> escribió:
> >
> > has realizado alguna instalacion que pueda haber modificado el PHP de
> > tu maquina? el snmp-net esta corriendo? dejo de graficar o simplemente
> > desaparecieron todos los graficos? muestra mas el log de cacti ya que
> > con lo que has publicado no das mucha informacion quisas el error esta
> > antes que pasara 03/07/2007 06:58:33 AM - CMDPHP: Poller[0] ERROR: SQL
> > Exec Failed bla bla bla
> > fijate que el usuario que estas usando tenga ALL PRIVILEGES a la DB de
> > cacti.
> >
> > On 3/7/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > > Marco Bravo escribió:
> > > > El día 7/03/07, Alvaro Herrera <[EMAIL PROTECTED]> escribió:
> > > > >
> > > > >Marco Bravo escribió:
> > > > >> Estimados,
> > > > >>
> > > > >> Tenia un FC6 con Cacti y de repente me dejo de graficar..
> > > > >> Haciendo un tail a cacti.log aparece lo siguiente:
> > > > >>
> > > > >> 03/07/2007 06:58:33 AM - CMDPHP: Poller[0] ERROR: SQL Exec Failed
> > > > >"insert
> > > > >> into poller_output (local_data_id,rrd_name,time,output) values
> > > > >> (1268,'traffic_in','2007-03-07 06:55:03','706414059')"
> > > > >
> > > > >Prueba ejecutando eso mismo en la base de datos directamente, a ver
> > que
> > > > >error te da.  Quizas se lleno el disco o el archivo tiene permisos
> > > > >equivocados, etc.
> > >
> > > > Segundo, me queda harto espacio en el disco y desgraciadamente no me
> > manejo
> > > > bien en las Bdatos. Tendrias por ahi algun link donde poder obtener
> > > > informacion para realizar lo que me señalas.
> > >
> > > Primero habria que saber que base de datos esta usando Cacti :-)  Yo no
> > > lo conozco.  Imagino que debe ser SQLite, en cuyo caso puedes instalar
> > > el paquete "sqlite" con el cual puedes mandarle comandos manualmente,
> > > con algo del estilo
> > >
> > > sqlite  "insert into pol

postgresql para almacenar documentos.

[Cristian Rodriguez]

El 8/03/07, Alvaro Herrera <[EMAIL PROTECTED]> escribió:
>  Lo
> que yo estaba diciendo era que PQexecParams permite evitarse el proceso
> de escapar el dato antes de enviarlo a la BD.
>

Entonces el cristiano necesita usar la funcion  pg_query_params()  ;-P

postgresql para almacenar documentos.

[Rodrigo Fuentealba]

El 7/03/07, Horst H. von Brand <[EMAIL PROTECTED]> escribió:
> Rodrigo Fuentealba <[EMAIL PROTECTED]> wrote:
> > Quiero implementar un software de administración de archivos al estilo
> > CVS/Subversion pero este es para planos en CAD, documentos de
> > OpenOffice (y Office, lamentable decirlo), y hartas cosas varias.
>
> Hum... alli no sirve de mucho lo de "control de versiones", andas
> buscando mas bien alguna clase de repositorio de documentos.

Se hace necesario guardar varios cambios del documento de acuerdo al
avance del proyecto (en etapa 1, este plano estaba así... en etapa 2,
así...).

> [... Ojo, esas cosas /tienen/ su propio sistema de control
>  de versiones integrado (por algo el archivo que solo dice "Nos vemos
>  man~ana" pesa 357KiB... tiene todos los mensajitos anteriormente
>  enviados empotrados en "versiones previas" para "undo") ...]

No es malo saber esto, pero como es algo "genérico" (no importa si
guarda fotos o no)... no podría hacer un software por cada tipo de
datos... termino el 11 de septiembre en la noche.

> > ...de tal manera que yo pueda hacer una suerte de
> > "diff" para archivos binarios y guardar el archivo una sola vez y
> > luego poder ir viendo progresivamente los cambios,
>
> Te conviene pensar en algo como xdelta(1) (el algoritmo es la base de
> muchos de los esquemas de "manejo compacto" de diferencias entre
> archivos arbitrarios que usan los SCM de a deveras)

Checking (si no digo que el Google será provechoso!)

> Mi idea, a rasgos aun mayores, seria ver si alguno de los tantos
> sistemas de administracion de documentos hace algo como lo que quieres,
> y usar eso.

Estoy copiando la funcionalidad de un administrador de documentos
llamado Meridian, que hace lo que se requiere pero no como se requiere
(y eso que lo unico requerido es que lo haga bien; toda la empresa
cometió el error de adaptarse al software, cuando lo correcto es al
revés...), modificar alguna cosa en su behavior es un parto (podría
hacerse perfectamente a través de vistas de PostgreSQL... ya hice esa
parte) y es demasiado caro (US$ 50.000, si utilizamos la base de datos
integrada de AM-Meridian... US$ 50.000 + la licencia de SQL Server
2000, que se rehusa a usar SQL Server 2005 o MSDE si queremos otras
cosillas más).

> Si, no sera 100% lo que buscas/quieres, pero te costara a lo
> mas un 5% de lo que es desarrollar el cuento por ti mismo

De hecho, es más barato desarrollar el cuento por mí mismo y poder
ofrecer la solución a otras empresas.

> lo tendras en
> funciones en 0,5% del tiempo, y el costo de mantencion se reduce a un 1%
> de lo que significa hacerlo todo tu (suponiendo que elegiste bien, y es
> un proyecto activo).

Eso sí.

> Y olvidate de "interfases hacia el lenguaje X du jour", mete todo el
> cuento tras /una/ interfaz web, programada en lo que este de moda hoy.

Uhmmm.

> > [ oid v/s bytea ] ¿cuál será mejor, y por qué? sé cómo manipular ambos
> > tipos de datos, pero desconozco los detalles de las diferencias como
> > para discriminar, ¿qué me aconsejarían ustedes?
>
> Usar la base de datos para simplemente guardar el nombre del archivo en
> un repositorio ad hoc no es mas simple?

Puede serlo, pero habrá referencias sin archivos y archivos sin
referencias. Quería aprovechar la integridad referenciada de las bases
de datos, para tener un control más fino por departamento, por perfil
de usuario, por especialidad, etc...

> (Si, ocupa mas espacio; pero has
> preguntado ultimamente cuanto cuesta un disco de taman~o decente?).

Si... ocupa espacio.

>  y obtener
> la "ultima version" (la unica que normalmente interesa) es mucho mas
> eficiente (por algo ya el venerable RCS guardaba no diferencias desde el
> comienzo incrementalmente hasta el final, sino la ultima version y
> diferencias hacia atras).

Interesante detalle.

-- 
Rodrigo Fuentealba Cartes
Desarrollador de Sistemas Web
Registered User 387639 - http://counter.li.org

postgresql para almacenar documentos.

[Rodrigo Fuentealba]

El 7/03/07, Alvaro Herrera <[EMAIL PROTECTED]> escribió:
> Rodrigo Fuentealba escribió:
>
> > Ahora, para esto tengo dos posibilidades: OID's y byte arrays.
>
> Yo te recomendaria usar bytea.
>
> Los "large objects" (LO) tienen la desventaja de que no tienen control
> de acceso y tienen una API que es totalmente diferente de lo que uno
> acostumbra a usar en SQL (lo_open, lo_read etc).  Cuando quieres hacer
> alguna cosa en "relacional" quedas muy amarrado de manos.

Ya me ha pasado con oids

> Por otro lado, en Postgres el uso de bytea esta bastante optimizado por
> el mecanismo conocido como TOAST.  Te recomiendo usar
> ALTER TABLE tabla ALTER COLUMN columna SET STORAGE EXTERNAL
> en la columna bytea, de manera que el sistema no trate de comprimir los
> datos almacenados (generalmente la compresibilidad de esos documentos no
> es mucha, y es mas rapido el acceso si no tiene que estar
> comprimiendo/descomprimiendo).

Dato interesante.

> (*) la alternativa a escapar/des-escapar es usar una API como
> PQexecParams, pero si vas a usar PHP creo que eso no esta disponible.
> En lenguajes razonables puedes hacerlo y es mucho mas eficiente porque
> los datos binarios pasan directo a la base de datos y no se tiene que
> gastar memoria en el proceso de escape.

(-_-) si... me rindo con php...

> Con respecto a la alternativa de almancenar los datos en el sistema de
> archivos y guardar solo una referencia en la BD, te recomiendo que no lo
> hagas a menos que el volumen de datos sea muy grande (hablo de decenas
> de GB).  Es muy dificil hacerlo correctamente, sobre todo si nunca lo
> has hecho, y no hacerlo correctamente lleva a documentos sin referencia
> y referencias a documentos inexistentes, que son muy incomodos de
> manejar.



>> de tal manera que yo pueda hacer una suerte de
>> "diff" para archivos binarios y guardar el archivo una sola vez y
>> luego poder ir viendo progresivamente los cambios,

> Lo que estas proponiendo es un mecanismo muy fragil e
> ineficiente.  Almacenarlo todo tiene un costo mayor en espacio de
> almacenamiento, pero es mucho mas simple de manejar en codigo y mas
> resistente a fallas.

Muchas gracias Alvaro.

La solución que se planteó fue precisamente para intentar ahorrar
"algo" de espacio en disco y emular el comportamiento de otra
aplicación como esta, que guarda sus datos en disco y ha funcionado
como... bueno, mal.

No había visto esa cara de la moneda.

-- 
Rodrigo Fuentealba Cartes
Desarrollador de Sistemas Web
Registered User 387639 - http://counter.li.org

postgresql para almacenar documentos.

[Horst H. von Brand]

Rodrigo Fuentealba <[EMAIL PROTECTED]> wrote:
> Quiero implementar un software de administración de archivos al estilo
> CVS/Subversion pero este es para planos en CAD, documentos de
> OpenOffice (y Office, lamentable decirlo), y hartas cosas varias.

Hum... alli no sirve de mucho lo de "control de versiones", andas
buscando mas bien alguna clase de repositorio de documentos.

[Los formatos OASIS son basicamente un .zip lleno de XMLses y otros
 cachivaches; al comprimir se pierde lo que hace que "solo guardar las
 diferencias con el anterior" permite ganar. No tengo idea de los CAD,
 etc. La estructura de los Hasefroch no se que tanto mantenga "comun"
 con el anterior. Ojo, esas cosas /tienen/ su propio sistema de control
 de versiones integrado (por algo el archivo que solo dice "Nos vemos
 man~ana" pesa 357KiB... tiene todos los mensajitos anteriormente
 enviados empotrados en "versiones previas" para "undo"), hay gente que
 ha pagado caro el no considerar esto (y de cuyos archivos publicados se
 extrajeron borradores conteniendo datos suculentos)]

> Para esto (ya que va integrado con un montón de aplicaciones más como
> control de horarios, control y asignación de trabajadores a un
> proyecto, Intranet y cosas varias, que están corriendo en PostgreSQL)
> modelé algunas tablas, de tal manera que yo pueda hacer una suerte de
> "diff" para archivos binarios y guardar el archivo una sola vez y
> luego poder ir viendo progresivamente los cambios,

Te conviene pensar en algo como xdelta(1) (el algoritmo es la base de
muchos de los esquemas de "manejo compacto" de diferencias entre
archivos arbitrarios que usan los SCM de a deveras)

>   y recuperar en el
> lenguaje que sea (Java, PHP, Python o alguno de los de hasefroch) el
> documento (poder ver la lista de documentos con algo programado con
> fuse). Esa es mi idea, a grandes rasgos.

Mi idea, a rasgos aun mayores, seria ver si alguno de los tantos
sistemas de administracion de documentos hace algo como lo que quieres,
y usar eso. Si, no sera 100% lo que buscas/quieres, pero te costara a lo
mas un 5% de lo que es desarrollar el cuento por ti mismo, lo tendras en
funciones en 0,5% del tiempo, y el costo de mantencion se reduce a un 1%
de lo que significa hacerlo todo tu (suponiendo que elegiste bien, y es
un proyecto activo).

Y olvidate de "interfases hacia el lenguaje X du jour", mete todo el
cuento tras /una/ interfaz web, programada en lo que este de moda hoy.

> Ahora, para esto tengo dos posibilidades: OID's y byte arrays. En
> experiencias como ésta... por tonta que sea la idea de meter un
> documento en una base de datos para compartirlo entre varias
> aplicaciones (la experiencia me dice que en el sistema de archivos la
> cosa no siempre funciona bien porque no existe un fine tunning como el
> que se requiere), ¿cuál será mejor, y por qué? sé cómo manipular ambos
> tipos de datos, pero desconozco los detalles de las diferencias como
> para discriminar, ¿qué me aconsejarían ustedes?

Usar la base de datos para simplemente guardar el nombre del archivo en
un repositorio ad hoc no es mas simple? (Si, ocupa mas espacio; pero has
preguntado ultimamente cuanto cuesta un disco de taman~o decente?).
Tiene la ventaja que no porque se rompio la cadena desde la version 0 a
la 137 cuando se corrompio el 9o parche se pierde casi todo... y obtener
la "ultima version" (la unica que normalmente interesa) es mucho mas
eficiente (por algo ya el venerable RCS guardaba no diferencias desde el
comienzo incrementalmente hasta el final, sino la ultima version y
diferencias hacia atras).
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de InformaticaFono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile   Fax:  +56 32 2797513

postgresql para almacenar documentos.

[Enrique Herrera Noya]

El 7/03/07, Rodrigo Fuentealba <[EMAIL PROTECTED]> escribió:
> Estimados:
>
> Quiero implementar un software de administración de archivos al estilo
> CVS/Subversion pero este es para planos en CAD, documentos de
> OpenOffice (y Office, lamentable decirlo), y hartas cosas varias.
>

viste "know_nosecuanto tree"  (arbol del conocimiento)



> Para esto (ya que va integrado con un montón de aplicaciones más como
> control de horarios, control y asignación de trabajadores a un
> proyecto, Intranet y cosas varias, que están corriendo en PostgreSQL)
> modelé algunas tablas, de tal manera que yo pueda hacer una suerte de
> "diff" para archivos binarios y guardar el archivo una sola vez y
> luego poder ir viendo progresivamente los cambios, y recuperar en el
> lenguaje que sea (Java, PHP, Python o alguno de los de hasefroch) el
> documento (poder ver la lista de documentos con algo programado con
> fuse). Esa es mi idea, a grandes rasgos.
>
> Ahora, para esto tengo dos posibilidades: OID's y byte arrays. En
> experiencias como ésta... por tonta que sea la idea de meter un
> documento en una base de datos para compartirlo entre varias
> aplicaciones (la experiencia me dice que en el sistema de archivos la
> cosa no siempre funciona bien porque no existe un fine tunning como el
> que se requiere), ¿cuál será mejor, y por qué? sé cómo manipular ambos
> tipos de datos, pero desconozco los detalles de las diferencias como
> para discriminar, ¿qué me aconsejarían ustedes?
>
> Atentamente,
>
> --
> Rodrigo Fuentealba Cartes
> Desarrollador de Sistemas Web
> Registered User 387639 - http://counter.li.org
>
>


-- 
http://www.chilelinks.cl/
http://www.decurauma.cl/wendyx  Wendyx 1.0

postgresql para almacenar documentos.

[Alvaro Herrera]

Rodrigo Fuentealba escribió:

> Ahora, para esto tengo dos posibilidades: OID's y byte arrays. En
> experiencias como ésta... por tonta que sea la idea de meter un
> documento en una base de datos para compartirlo entre varias
> aplicaciones (la experiencia me dice que en el sistema de archivos la
> cosa no siempre funciona bien porque no existe un fine tunning como el
> que se requiere), ¿cuál será mejor, y por qué? sé cómo manipular ambos
> tipos de datos, pero desconozco los detalles de las diferencias como
> para discriminar, ¿qué me aconsejarían ustedes?

Yo te recomendaria usar bytea.

Los "large objects" (LO) tienen la desventaja de que no tienen control
de acceso y tienen una API que es totalmente diferente de lo que uno
acostumbra a usar en SQL (lo_open, lo_read etc).  Cuando quieres hacer
alguna cosa en "relacional" quedas muy amarrado de manos.

Los bytea tienen la desventaja de que no puedes operar sobre el objeto
porcionadamente; por ej. no puedes hacer seek y reemplazar un pedazo.
Pero creo que cuando almacenas documentos (PDF, Word, etc), rara vez
(lease nunca) haces eso; mas bien lo que haces es crear un objeto
totalmente nuevo.  La otra desventaja principal es que tienes que
escapar los bytes que vayas a insertar y des-escapar cuando los
extraigas(*); pero a cambio recibes el beneficio de poder operarlo
normalmente con INSERT, SELECT, etc, y construir un mecanismo de
"auditoria" puede ser mas sencillo.

Por otro lado, en Postgres el uso de bytea esta bastante optimizado por
el mecanismo conocido como TOAST.  Te recomiendo usar
ALTER TABLE tabla ALTER COLUMN columna SET STORAGE EXTERNAL
en la columna bytea, de manera que el sistema no trate de comprimir los
datos almacenados (generalmente la compresibilidad de esos documentos no
es mucha, y es mas rapido el acceso si no tiene que estar
comprimiendo/descomprimiendo).

(*) la alternativa a escapar/des-escapar es usar una API como
PQexecParams, pero si vas a usar PHP creo que eso no esta disponible.
En lenguajes razonables puedes hacerlo y es mucho mas eficiente porque
los datos binarios pasan directo a la base de datos y no se tiene que
gastar memoria en el proceso de escape.


Con respecto a la alternativa de almancenar los datos en el sistema de
archivos y guardar solo una referencia en la BD, te recomiendo que no lo
hagas a menos que el volumen de datos sea muy grande (hablo de decenas
de GB).  Es muy dificil hacerlo correctamente, sobre todo si nunca lo
has hecho, y no hacerlo correctamente lleva a documentos sin referencia
y referencias a documentos inexistentes, que son muy incomodos de
manejar.

-- 
Alvaro Herrerahttp://www.advogato.org/person/alvherre
"Changing the world ... one keyboard at a time!"
 (www.DVzine.org)
From [EMAIL PROTECTED]  Wed Mar  7 14:14:04 2007
From: [EMAIL PROTECTED] (Enrique Herrera Noya)
Date: Wed Mar  7 14:15:13 2007
Subject: algunos problemas con postfix
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

El 7/03/07, Andres Pereira <[EMAIL PROTECTED]> escribió:
> 2007/3/7, Enrique Herrera Noya <[EMAIL PROTECTED]>:
> > 1. en forma aleatoria no llegan algunos mensajes.
> > la configuracion es postfix + spamassassin+mysql+postgrey+sasl+clamav
> >
> > revice todos los log y no veo nada relevante
> > alguna sugerencia?
>
> Puede que los mensajes que no llegan se debe a que son descartados por
> ser spam  o virus, revisa la configuración del amavisd (por los
> encabezados que muestras abajo estás usando esa interfaz).
>
revisare, pero son email no solo de gamil, hotmail, los que se "pierden",
tmabien de empresas...



> > 2. se pretende configurar un nuevo servidor desde cero, con una distro
> > para servidores
> > (esta con ubuntu :-S ), como recupero los email que estan en el
> > servidor antiguo?
> > llegar y tar , scp, hacia el equipo nuevo?
>
> Hay que tener cuidado con los permisos también.
ok, teniendo ese cuidado se hace
o man dd ;-)

>
> > 3. dig al dominio me arrojo
> > correo1..cl 600   10 IP1
> > correo2..cl 600   10 IP2
> > correo3..cl 600   10 IP3
> >
> > donde en correo2 esta ldap que lo usan como libreta de direcciones.
> > y correo3 solo esta de respaldo cuando se cae  correo1
>
>
> Si correo2 lo usan como libreta, para qué tienes definido el MX?
>
perdon en correo2  no esta ldap, esta en otro..

> > no es que deberian estar las prioridades diferentes?
>
> No necesariamente si es que deseas tener un pseudo-esquema de balanceo de 
> carga.

a,
voy entendiendo la configuracion
osea puede que los email esten en correo2 y correo3

por lo que deberia ver como configurar pop3 e imap para que rescate
los email de los tres servidores ?


>
> > 4. esta es la cabecera de un email que si llego,
> > donde encuentro un doc que me permita entender por que tantos Receivered
>
> No veo nada raro...el mensaje pasa por varios servidores internos de
> google, luego sale por un smtp

postgresql para almacenar documentos.

[Mauro A. Morales M.]

On Wed, 7 Mar 2007 10:42:45 -0300
"Rodrigo Fuentealba" <[EMAIL PROTECTED]> wrote:

> Estimados:
> 
> Quiero implementar un software de administración de archivos al estilo
> CVS/Subversion pero este es para planos en CAD, documentos de
> OpenOffice (y Office, lamentable decirlo), y hartas cosas varias.

Te sugiero que revises opciones relacionadas a indexacion & meta-datos,
que es la combinación sana para este tipo de casos. Cuando encuentre lo
que tengo al respecto, te lo hago llegar.

Hay aglunos que integran tecnologia web en su implementacion, por lo
que creo que es factible que realices integracion a otros sistemas.

> Ahora, para esto tengo dos posibilidades: OID's y byte arrays. En
> experiencias como ésta... por tonta que sea la idea de meter un
> documento en una base de datos para compartirlo entre varias
> aplicaciones (la experiencia me dice que en el sistema de archivos la
> cosa no siempre funciona bien porque no existe un fine tunning como el
> que se requiere), ¿cuál será mejor, y por qué? sé cómo manipular ambos
> tipos de datos, pero desconozco los detalles de las diferencias como
> para discriminar, ¿qué me aconsejarían ustedes?

Tambieén tienes que investigar la capacidad de almacenamiento en areas
de memoria de los documentos que pretendes abrir, en especial si son
accesados a una BD.

Recuerdo que para casos bien especificos, Oracle puede asignar areas de
memorias exclusivas para ciertas consultas de forma que no usen memoria
que relanticen otros procesos. La carga de un archivo puede ser
bastante tarea, en especial de forma concurrente (si es que se puede
dar).

Por lo mismo si revisas indexacion y metadatos la solucion la puedes
tener de una forma mas optima (aunque, claro, tambien hace uso de BD,
pero referencial, y XML como propagador de la info)

-- 
Mauro A. Morales M. mailto:[EMAIL PROTECTED]