En la configuración de pdns.conf debes tener los parametros slave=yes y allow-axfr-ips= con las redes a las que aceptas hacer de secundario.

Debes “bautizar a cada primario” esto es condición sine qua no.

En pdns debes crear un SUPERZONA que referencia al primario en cuestión.

y listo, en tu plesk debes preocuparte que el en el SOA aparezca como primario el propio plesk, con la ip/FDQN con que lo bautizaste y el pdns debe aparecer en uno de los NS que hay en la zona.

Con esto ya lo tienes en marcha.

mysql> select domains.name dominio,data_bases.name databasename,login,password from data_bases left join db_users on data_bases.default_user_id=db_users.id left join domains on data_bases.dom_id=domains.id left join accounts on account_id=accounts.id ;
+————————-+———————————-+—————–+—————-+
| dominio                 | databasename                     | login           | password       |

sitebuilder.nombredelamaquina.tld

Si se quiere cambiar hay que hacer lo siguiente, cambiando lo que se quiere de la parte de sitebuilder:

/usr/local/bin/sb_config –sb_hostname sitebuilder.domain.tld –force_update_wscfg

Para cambiar la máquina donde está el engine de SB corriendo con licencia multi-ip en un plek diferente:

/usr/local/psa/bin/sitebuilder –set http://sitebuilder.domain.tld/ServiceFacade/

El cambio no se aplica a los clientes y dominios que ya existan en la máquina, por lo que hay que ir a cada cliente y a cada dominio de esos clientes para activar que puedan usar el sitebuilder central multi-ip.

Antes habremos de haber ido a esa máquina y haber habilitado la ip para que pueda validarse:

Sitebuiler / Escritorio / Hosts

Aportación de Javier Montalvo

/var/log/psa-horde/psa-horde.log
el error.
Si es:

Aug 05 11:22:22 HORDE [error] [imp] FAILED LOGIN 84.77.246.221 to localhost:143[imap/notls] as disvir@teatres.org [on line 258 of "/usr/share/psa-horde/imp/lib/Auth/imp.php"]
Ir a /etc/hosts

y añadir, sino está:

127.0.0.1 localhost localhost.localdomain

Info aportada por Javier Montalvo

Sin embargo en la plantilla standar que genera de DNS genera un *.webmail.tudominio por lo que podras acceder poniendo por ejemplo el famoso “hipopotamo.webmail.tudominio”

La cuestión es que a parte de lo que hayas configurado si quieres puede sir directo a las diecciones:

http://atmail.webmail.tudominio

http://horde.webmail.tudominio

y veras el webmail con los diferentes interfaces, asi que si unos usuarios prefieren horde y otros atmail siempre podemos enseñarles las 2 direcciones y que ellos elijan

Tambien es una pena que cuando abres un tiquet con prioridad critica, tarden lo insufrible en responder y encima respondan cosas de niños, como si no te hubieses mirado nada, como si no supiesemos usar un buscador.

Tambien es bastante lamentable que cuando les preguntas cosas como estas la respuesta sea si tienes la ultima versión de todo y como has copia los contianers, en vez de decirte la verdad y atajar por el camino recto.

Realmente si valorais vuestro tiempo es preferible que os busqueis gente que se pelee todos los dias con los productos en cuestión que no tener que pedir soporte a la gente de parallels.

Realmente los productos funcionan razonablemente bien y debe haber autenticos “gurus” en los niveles mas altos de la piramide, pero como pasa en general con casi todo ni con un “gold partner” “platinium leches” ni nada que se le parezca vas a tener acceso a esos niveles.

Ciertamente, creo no me creo que los errores que veo cada dia solo me salgan a mi y sea el unico que se los encuentra. SImplemente no me lo creo y lo peor viene cuando acredito al resolución.

Debo dar las gracias a Parallels por obligarme a aprender tanto y sinceramente, estas cosas son las que hacen que el trabajo que realizo entre en la categoria de “VOCACIÓN”.

También debo agradecerle a Parallels que apoyen el de GNU, aunque se salten algunos aspectos.

Tambien debo dar las gracias a la gente de mi entorno (tecnicos,administrativos etc) que no se alteran cuando hablo un poco mas fuerte de lo habitual y los pongo a todos a parir. Debo admitir que en general suelo tener razón en lo que digo aunque lo exprese de forma un poco mas beemente de lo estrictamente necesario.

“Access for administrator from address xx.xx.xx.xx is restricted in accordance with IP Access restriction policy currently applied.”

Para solucionarlo deberemos corregir directamente en las tablas del panel de control dicho detalle.

Para ver como esta configurado podemos hacer:

# mysql -uadmin -p`cat /etc/psa/.psa.shadow ` psa
mysql> select * from cp_access;
mysql> select * from misc where param='access_policy';

Para corregirlo:

# mysql -uadmin -p`cat /etc/psa/.psa.shadow ` psa
mysql> delete * from cp_access;
mysql> update misc set val=”allow” where param=’access_policy’;

http://kb.parallels.com/en/954

Concretamente lo que suele ocurrir es que en una migración nadie presta atención a las listas, aparte del hecho que son un engorro, es por ello que, semanas despues de haber hecho la migración el cliente reclama su lista. El problema es que tenemos la lista en un servidor viejo y en el nuevo la información a variado sustancialmente, ¿como fusionar las 2 cosas? facil:

• Creamos un dominio ficticio en el servidor viejo: pruebas.priv
• Movemos las listas
• Migramos el dominio ficticio
• En el servidor nuevo volvemos a mover las listas al dominio bueno
• Movemos los archivos que redirijen los mensjaes de qmail a mailman
• borramos en dominio ficticio en el servidor nuevo (que estara vacio)
• Regeneramos todos los permisos y archivos de config del correo

Bueno lo primero que haremos es entrar en la BBDD y hacer algo asi:

-bash-3.1# mysql -u admin -p`cat /etc/psa/.psa.shadow ` psa

mysql> select * from MailLists;
+—-+——–+——————+——–+
| id | dom_id | name             | status |
+—-+——–+——————+——–+
|  1 |     51 | boletin          |      2 |
|  2 |     51 | comunicados      |      2 |
|  3 |     51 | WTM              |      3 |
|  4 |     51 | zbxxxx         |      3 |
|  5 |     42 | empresa          |      2 |
|  6 |    293 | Comunicados_xxxx |      2 |
+—-+——–+——————+——–+
6 rows in set (0.00 sec)

mysql> update MailLists set dom_id=327 where dom_id=51;
Query OK, 4 rows affected (0.93 sec)
Rows matched: 4  Changed: 4  Warnings: 0

mysql> select * from MailLists;
+—-+——–+——————+——–+
| id | dom_id | name             | status |
+—-+——–+——————+——–+
|  1 |    327 | boletin          |      2 |
|  2 |    327 | comunicados      |      2 |
|  3 |    327 | WTM              |      3 |
|  4 |    327 | zbxxx         |      3 |
|  5 |     42 | empresa          |      2 |
|  6 |    293 | Comunicados_xxxx |      2 |
+—-+——–+——————+——–+
6 rows in set (0.00 sec)

mysql> quit

Que decir tiene que el 51 es el ID del dominio donde originalmente estaban los dominios y el 327 el id del dominio fantasma.

Despues migramos, y repetimos la acción asegurandonos de tener claro los nuevos id.

Aqui movemos los archivos /var/qmail/mailnames//.qmail-NOMBRELISTA-* /var/qmail//.

Una vez vaciado el dominio fantasma en el servidor de destino, simplemente nos lo cargamos.

Y regeneramos todos los archivos del correo tal y como comente en el post anterior:

http://david.toribio.eu/2008/10/04/regenerar-configuracion-qmail-en-plesk/

Servicios para recoger email:

• 110: pop3 : Servicio típico de recogida de correo
• 143: imap : Servicio de consulta del correo sin descargarlo
• 993* imap seguro, imap s/SSL
• 995* pop3 seguro, pop3 s/SSL

Servicios para enviar email:

• 25: smtp : Por aquí podemos entregar el correo a nuestro servidor y terceros le entregan al servidor el correo destinado a nosotros
• 465* smtps seguro, smtp s/ssl, podemos entrega rel correo a nuestro servidor a través de un canal securizado, por lo que al autentificarnos no podran cazarnos el password.
• 587: smtp submision, canal exclusivo para entregar correo a nuestro servidor, es una buena opción, aunque mejor usar el servicio smtps conseguiremos el mismo efecto con un poco mas de privacidad. Yo lo activo si  algún usuario me lo pide, no lo hago sistematicamente.

Servicios de gestión:

• 22* ssh
• 8443* https panel de control s/SSL
• 8880: http panel de control sin SSL, generalmente usado en entornos mas controlados
• 106: poppassd, lo mantenemos para pdoer cambiar el password desde el webmail. Tiene dudosa utilidad hoy en día, es una herencia del pasado
• 3306: mysql, rara vez podrás llegar a hacer algo, en alguna ocasión s ehabilita algún acceso externo, generalmente el acceso alas BBDD se hace desde webs ubicadas en la propia maquina.
• 21 (y 20): ftp

Servicios a terceros:

• 53: DNS, resuelve nombres
• 80: http, muestra nuestras webs
• 443: https, muestra nuestras webs con certificado s/SSL

En general cuando configureis el correo, os encontrareis que os da la opción de usar protocolos seguros, cuando esto suceda, os encontrareis que necesitas identificar el puerto en cuestión, aquí los tenéis.

# /usr/local/psa/admin/bin/mchk
Synopsis:
mchk [OPTION]
–without-spam – restore all settings except for SpamAssassin configuration
–with-spam – restore all settings
–spam-only – restore only SpamAssassin settings

Esta utilidad regenera los ficheros de los directorios /var/qmail/control, /var/qmail/users y ademas retoca los propietarios y permisos de todos los archivos de /var/qmail/mailnames. Esto resulta interesante despues de copiar a “pelo” archivos de correo, practica poco recomendable pero que en ocasiones puedes verte obligado a realizar, sobretodo cuando hay alguna catastrofe y estamos reconstruyendo a partir de deshechos.

Hay que tener en cuenta que si el volumen es alto puede tomarse su tiempo, asi que si lo ejecutas en un servidor en producción tomatelo con calma.