Estimados Listeros,
Estoy tratando de montar un servidor de correo con postfix y cyrus2.2
sobre debian testing casi sagradamente al dia excluyendo un par de cosas.
cyrus 2.2
cyrus-admin-2.2_2.2.13-10
cyrus-clients-2.2_2.2.13-10
cyrus-common-2.2_2.2.13-10
cyrus-doc-2.2_2.2.13-10
cyrus-imapd-2.2_2.2.13-10
libcyrus-imap-perl22_2.2.13-10
Al arrancar cyrus2.2 me sale el siguiente error
/var/lib/cyrus/db# /etc/init.d/cyrus2.2 start
/etc/init.d/cyrus2.2: Database backends mismatch! You must manually
/etc/init.d/cyrus2.2: verify and update the Cyrus databases to the
/etc/init.d/cyrus2.2: new backends.
/etc/init.d/cyrus2.2: Please refer to
/usr/share/doc/cyrus-common-2.2/README.Debian
/etc/init.d/cyrus2.2: for instructions.
/etc/init.d/cyrus2.2: Cyrmaster not started.
Revisando un diff me agrega esto :
--- cyrus-db-types.active 2007-02-13 04:28:29.0 -0300
+++ cyrus-db-types.txt 2006-12-09 13:07:20.0 -0300
@@ -1,6 +1,9 @@
-DBENGINE BerkeleyDB3.2
-DUPLICATE db3_nosync
+ANNOTATION skiplist
+DBENGINE BerkeleyDB4.2
+DUPLICATE berkeley-nosync
MBOX skiplist
+PTS berkeley
+QUOTA quotalegacy
SEEN skiplist
SUBS flat
-TLS db3_nosync
+TLS berkeley-nosync
Busque las db
var/lib/cyrus/db# locate *.db
/var/lib/cyrus/db.backup1/mailboxes.db
/var/lib/cyrus/db.backup2/mailboxes.db
/var/lib/cyrus/deliver.db
/var/lib/cyrus/mailboxes.db
/var/lib/cyrus/tls_sessions.db
Aplique lo que dice
http://lists.alioth.debian.org/pipermail/pkg-cyrus-imapd-debian-devel/2006-May/000988.html
# db4.2_upgrade /var/lib/cyrus/mailboxes.db
db_upgrade: /var/lib/cyrus/mailboxes.db: unrecognized file type
db_upgrade: DB-upgrade: /var/lib/cyrus/mailboxes.db: Invalid argument
Lo extraño es que cuando hago lo mismo con el archivo
/var/lib/cyrus/deliver.db lo hace sin chistar.
Ya no se donde mas buscar. Al final segun lo que lei estos bichos
cambian formato regularmente pero ahora no se por donde va la solucion.
Agradecere cualquier idea.
--
Atentamente,
Simon Iribarren Monroy
From [EMAIL PROTECTED] Fri Mar 9 15:11:26 2007
From: [EMAIL PROTECTED] (Horst H. von Brand)
Date: Fri Mar 9 15:12:30 2007
Subject: postgresql para almacenar documentos.
In-Reply-To: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
Rodrigo Fuentealba [EMAIL PROTECTED] wrote:
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í...).
Si quieres poder comparar versiones diferentes del documento (Digame
que cambio entre la etapa 1 y la 2, digame cuando pusieron esto, ...)
/tienes/ que hacerlo para ese formato especifico, no hay caso de evitar
eso. No, no es para nada divertido. diff(1) se las arregla para texto
plano, pero en cuanto te enredas con algun formato de texto un
poquitito mas estructurado (como XML) te enteras de que es /verdadero/
dolor.
Si quieres tener a mano todas las versiones, la manera mas simple es
tener todas las versiones a mano ;-)
[... 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.
No terminas alli, te lo doy firmado.
[...]
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).
Porque crees que la gente de Meridian se las arregla para lograr que le
paguen eso por su paquete? Seguro que no es porque cualquier pajarraco
es capaz de replicar la funcionalidad el solo en dos o tres meses
