Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
1
Spanish / Instalación de SOGo sobre Zentyal
« on: April 13, 2011, 02:27:52 pm »
Aquí os dejo una guía para instalar y configurar SOGo sobre Zentyal. Ya se que actualmente Zentyal se ha decantado por integrar Zarafa como solución groupware pero merece la pena que le echéis un vistazo a esta alternativa.
Esta guía es el resultado de la implantación de SOGo en una pyme en la que básicamente se requería lo siguiente:
- Calendario compartido.
- Directorio de empresa compartido.
- Acceso a estos recursos a través de IPhone y Thunderbird.
Como os digo está en formato de guía, no pretende ser un manual detallado sobre el funcionamiento de SOGo sobre Zentyal, sólo recoger los pasos para tener el sistema funcionando de forma rápida y sencilla. Las explicaciones las encontraréis tanto en la documentación de SOGo como en la de Zentyal.
( He visto que en el foro existe otro post en inglés que aborda el mismo tema pero creo que éste es más completo y así lo tenéis en español, espero que os resulte útil )
Datos básicos:
Para instalar los paquetes .deb de SOGo es necesario añadir la siguiente línea al sources.list:
SOGo permite el uso de distintas bases de datos, en este caso hemos usado PostgreSQL. Instalamos con apt:
Configuración general.
El archivo de configuración general es de tipo GNUstep y se encuentra en: /home/sogo/GNUstep/Defaults/.GNUstepDefaults
Todos los parámetros se introducen como el usuario "sogo"
defaults write sogod SOGoTimeZone "Europe/Madrid"
defaults write sogod SOGoMailDomain "midominio.com"
defaults write sogod SOGoLanguage Spanish
defaults write sogod SOGoAppointmentSendEMailNotifications YES
defaults write sogod SOGoFoldersSendEMailNotifications YES
defaults write sogod SOGoACLsSendEMailNotifications YES
Configuración LDAP para autenticación:
defaults write sogod SOGoUserSources '( {type = ldap;CNFieldName = cn;IDFieldName = uid; UIDFieldName = uid; bindFields = uid; baseDN = "ou=Users,dc=zenserver,dc=midominio,dc=com";bindDN = "cn=ebox,dc=zenserver,dc=midominio,dc=com";bindPassword = (la_contraseña_ebox); canAuthenticate = YES; displayName ="Contactos"; hostname = "localhost"; id = public;isAddressBook = NO; port=389})'
IMPORTANTE:
"hostname" es el nombre del servidor LDAP maestro contra el que vamos a autenticar los usuarios. Si se instala en un zentyal esclavo hay que cambiar el puerto a "port=1390"
Configuración SMTP
defaults write sogod SOGoMailingMechanism smtp
defaults write sogod SOGoSMTPServer zenserver.midomino.com
Configuración IMAP
defaults write sogod SOGoDraftsFolderName Drafts
defaults write sogod SOGoSentFolderName Sent
defaults write sogod SOGoTrashFolderName Trash
defaults write sogod SOGoIMAPServer localhost
defaults write sogod SOGoForceIMAPLoginWithEmail YES
Filtros SIEVE
defaults write sogod SOGoSieveServer sieve://localhost:10024
defaults write sogod SOGoSieveScriptsEnabled YES
Interfaz
defaults write sogod SOGoMailComposeMessageType html
Ajustes generales
defaults write sogod SOGoFirstDayOfWeek 1
defaults write sogod SOGoDayEndTime 20
defaults write sogod SOGoEnableEMailAlarms yes
APACHE
Es necesario habilitar los módulos siguientes: proxy proxy_http headers rewrite
a2enmod proxy
a2enmod proxy_http
a2enmod headers
a2enmod rewrite
SOGo genera un archivo de configuración para apache en: /etc/apache2/conf.d/SOGo.conf
Modificamos /etc/apache2/conf/SOGo.conf para adaptarlo a nuestras necesidades:
ProxyPass /SOGo http://127.0.0.1:20000/SOGo retry=0
<Proxy http://127.0.0.1:20000/SOGo>
## adjust the following to your configuration
RequestHeader set "x-webobjects-server-port" "443"
RequestHeader set "x-webobjects-server-name" "zenserver.midominio.com"
RequestHeader set "x-webobjects-server-url" "https://webmail.midomino.com"
ProxyPass /SOGo http://127.0.0.1:20000/SOGo retry=0
Creamos un dominio virtual en el servidor web a través de la interfaz Zentyal: webmail.midominio.com
Para que este dominio tome su configuración desde el archivo "SOGo.conf" creamos el siguiente enlace:
POSTGRESQL
Base de datos.
su – postgres
createuser --no-superuser --no-createdb --no-createrole --encrypted --pwprompt sogo (especifica “sogo” como password)
createdb -O sogo sogo
Permisos de acceso.
Añadimos la línea:
en el siguiente archivo /etc/postgresql/8.4/main/pg_hba.conf
Configuración.
defaults write sogod SOGoProfileURL 'postgresql://sogo:sogo@localhost:5432/sogo/sogo_user_profile'
defaults write sogod OCSFolderInfoURL 'postgresql://sogo:sogo@localhost:5432/sogo/sogo_folder_info'
defaults write sogod OCSSessionsFolderURL 'postgresql://sogo:sogo@localhost:5432/sogo/sogo_sessions_folder'
defaults write sogod OCSEMailAlarmsFolderURL 'postgresql://sogo:sogo@localhost:5432/sogo/sogo_a larms_folder'
Integración con Thunderbird.
SOGo mantiene tres plungins para thunderbird que nos van a permitir compartir calendarios y contactos. Y además de compartirlos podremos sincronizarlos de forma centralizada con nuestro servidor.
Estos plugins se pueden encontrar en la sección de descargas de SOGo y son los siguientes:
Antes de instalarlos es necesario adaptarlos a nuestro servidor:
SOGo-integrator.
Modificar archivo chrome/content/extensions.rdf para configurar dónde se encuentra el servidor
SOGo<Seq about="http://inverse.ca/sogo-integrator/extensions"
isi:updateURL="https://webmail.midominio.com/plugins/updates.php?plugin=%ITEM_ID%&version=%ITEM_VERSION%&platform=%PLATFORM%">
<li>
Procedimiento para exportar libreta de direcciones a SOGo.
El complemento "SOGo Integrator" copia todos los contactos de la "Libreta personal de direcciones" a la libreta remota en formato DAV y luego ELIMINA la libreta local, dejando únicamente una libreta con conexión al servidor SOGo.
Si queremos mantener los contactos del TB, antes de instalar el complemento SOGo-integrator hay que conectar la libreta personal del usuario como una "Remote Address Book" y copiarle todos los contactos de la " Libreta de direcciones personal".
La URL tiene que ser de la forma:
https://webmail.midominio.com/SOGo/dav/usuario/Contacts/personal/
Algunos problemas.
El complemento para Thunderbird "SOGo Integrator" está configurado por defecto para consultar las direcciones en un directorio de sistema de nombre "public" . Este directorio sería de tipo LDAP y tendría que estar definido en SOGo en el archivo " GNUstep/Defaults/.GNUstepDefaults" . No he podido verificar si esto funcionaría en el caso de crear esa fuente LDAP en la configuración de SOGo, de todas formas no interesa para esta guía porque se trataría de un directorio de "SOLO LECTURA" gestionado vía LDAP por un usuario administrador.
En nuestro caso nosotros queremos un "directorio de empresa" que almacene todos los contactos de la oficina y que sea plenamente accesible (lectura,escritura) por todos los usuarios (se podría limitar a unos concretos) . Esto se consigue creando un "usuario administrativo" que va a tener su "libreta de direcciones" y "calendario" compartido con el resto.
Para ELIMINAR ese directorio "public" que crea este complemento hacemos lo siguiente:
Abrimos el archivo "sogo-integrator-3.104-sogo-demo.xpi" y editamos lo siguiente:
..\defaults\preferences\site.js
BORRAMOS la línea : pref("sogo-integrator.autocomplete.server.urlid", "public");
..\defaults\preferences\sogo-integrator.js
Cambiamos la línea : pref("ldap_2.autoComplete.useDirectory", true);
por pref("ldap_2.autoComplete.useDirectory", false);
Login automático desde TB.
SOGo integrator sincroniza las libretas de direcciones, los contactos y las tareas con el servidor SOGo , para eso tiene que hacer conexiones periódicas a este servidor y eso implica iniciar una sesión.
Debido a la configuración del servidor IMAP en Zentyal ese inicio de sesión fallará tal como está por defecto en el plugin de SOGo. Para solucionarlo es necesario que el login se haga usando el nombre del usuario (variable username ) y no su dirección de correo. Esto se consigue modificando el código del complemento:
Abrimos el archivo "sogo-integrator-3.105-sogo-demo.xpi" y editamos lo siguiente:
../chrome/content/sogo-config.js
if (useEmail)
sogoConfig'username' = mgr.defaultAccount.defaultIdentity.email;
else
sogoConfig'username' = mgr.defaultAccount.incomingServer.realUsername;
Lo cambiamos por esto :
if (useEmail)
sogoConfig['username'|'username'] = mgr.defaultAccount.defaultIdentity.email;
else
sogoConfig'username' = mgr.defaultAccount.incomingServer.username;
Así obligamos a que use la variable "username" en lugar de las otras dos tanto si estábamos usando el correo como nombre de usuario como si no. |
Después de esto deberíamos poder acceder a nuestro servidor Zentyal+SOGo tanto desde el cliente Thunderbird como desde el cliente web en la URL:
https://webmail.midominio.com/SOGo
Saludos.
Esta guía es el resultado de la implantación de SOGo en una pyme en la que básicamente se requería lo siguiente:
- Calendario compartido.
- Directorio de empresa compartido.
- Acceso a estos recursos a través de IPhone y Thunderbird.
Como os digo está en formato de guía, no pretende ser un manual detallado sobre el funcionamiento de SOGo sobre Zentyal, sólo recoger los pasos para tener el sistema funcionando de forma rápida y sencilla. Las explicaciones las encontraréis tanto en la documentación de SOGo como en la de Zentyal.
( He visto que en el foro existe otro post en inglés que aborda el mismo tema pero creo que éste es más completo y así lo tenéis en español, espero que os resulte útil )
Datos básicos:
- Versión SOGo: 1.3.5
- Versión Zentyal: 2.0.17
- Servidor: zenserver.midominio.com
- Dominio: midominio.com
- Dominio virtual (APACHE): webmail.midominio.com
Para instalar los paquetes .deb de SOGo es necesario añadir la siguiente línea al sources.list:
- deb http://inverse.ca/ubuntu lucid main
SOGo permite el uso de distintas bases de datos, en este caso hemos usado PostgreSQL. Instalamos con apt:
- apt-get install sogo sope4.9-gdl1-postgresql
Configuración general.
El archivo de configuración general es de tipo GNUstep y se encuentra en: /home/sogo/GNUstep/Defaults/.GNUstepDefaults
Todos los parámetros se introducen como el usuario "sogo"
- su - sogo
defaults write sogod SOGoTimeZone "Europe/Madrid"
defaults write sogod SOGoMailDomain "midominio.com"
defaults write sogod SOGoLanguage Spanish
defaults write sogod SOGoAppointmentSendEMailNotifications YES
defaults write sogod SOGoFoldersSendEMailNotifications YES
defaults write sogod SOGoACLsSendEMailNotifications YES
Configuración LDAP para autenticación:
defaults write sogod SOGoUserSources '( {type = ldap;CNFieldName = cn;IDFieldName = uid; UIDFieldName = uid; bindFields = uid; baseDN = "ou=Users,dc=zenserver,dc=midominio,dc=com";bindDN = "cn=ebox,dc=zenserver,dc=midominio,dc=com";bindPassword = (la_contraseña_ebox); canAuthenticate = YES; displayName ="Contactos"; hostname = "localhost"; id = public;isAddressBook = NO; port=389})'
IMPORTANTE:
"hostname" es el nombre del servidor LDAP maestro contra el que vamos a autenticar los usuarios. Si se instala en un zentyal esclavo hay que cambiar el puerto a "port=1390"
Configuración SMTP
defaults write sogod SOGoMailingMechanism smtp
defaults write sogod SOGoSMTPServer zenserver.midomino.com
Configuración IMAP
defaults write sogod SOGoDraftsFolderName Drafts
defaults write sogod SOGoSentFolderName Sent
defaults write sogod SOGoTrashFolderName Trash
defaults write sogod SOGoIMAPServer localhost
defaults write sogod SOGoForceIMAPLoginWithEmail YES
Filtros SIEVE
defaults write sogod SOGoSieveServer sieve://localhost:10024
defaults write sogod SOGoSieveScriptsEnabled YES
Interfaz
defaults write sogod SOGoMailComposeMessageType html
Ajustes generales
defaults write sogod SOGoFirstDayOfWeek 1
defaults write sogod SOGoDayEndTime 20
defaults write sogod SOGoEnableEMailAlarms yes
APACHE
Es necesario habilitar los módulos siguientes: proxy proxy_http headers rewrite
a2enmod proxy
a2enmod proxy_http
a2enmod headers
a2enmod rewrite
SOGo genera un archivo de configuración para apache en: /etc/apache2/conf.d/SOGo.conf
Modificamos /etc/apache2/conf/SOGo.conf para adaptarlo a nuestras necesidades:
ProxyPass /SOGo http://127.0.0.1:20000/SOGo retry=0
<Proxy http://127.0.0.1:20000/SOGo>
## adjust the following to your configuration
RequestHeader set "x-webobjects-server-port" "443"
RequestHeader set "x-webobjects-server-name" "zenserver.midominio.com"
RequestHeader set "x-webobjects-server-url" "https://webmail.midomino.com"
ProxyPass /SOGo http://127.0.0.1:20000/SOGo retry=0
Creamos un dominio virtual en el servidor web a través de la interfaz Zentyal: webmail.midominio.com
Para que este dominio tome su configuración desde el archivo "SOGo.conf" creamos el siguiente enlace:
- ln -s /etc/apache2/conf.d/SOGo.conf /etc/apache2/sites-available/user-ebox-webmail.midominio.com/
POSTGRESQL
Base de datos.
su – postgres
createuser --no-superuser --no-createdb --no-createrole --encrypted --pwprompt sogo (especifica “sogo” como password)
createdb -O sogo sogo
Permisos de acceso.
Añadimos la línea:
- host sogo sogo 127.0.0.1/32 md5
en el siguiente archivo /etc/postgresql/8.4/main/pg_hba.conf
Configuración.
defaults write sogod SOGoProfileURL 'postgresql://sogo:sogo@localhost:5432/sogo/sogo_user_profile'
defaults write sogod OCSFolderInfoURL 'postgresql://sogo:sogo@localhost:5432/sogo/sogo_folder_info'
defaults write sogod OCSSessionsFolderURL 'postgresql://sogo:sogo@localhost:5432/sogo/sogo_sessions_folder'
defaults write sogod OCSEMailAlarmsFolderURL 'postgresql://sogo:sogo@localhost:5432/sogo/sogo_a larms_folder'
Integración con Thunderbird.
SOGo mantiene tres plungins para thunderbird que nos van a permitir compartir calendarios y contactos. Y además de compartirlos podremos sincronizarlos de forma centralizada con nuestro servidor.
Estos plugins se pueden encontrar en la sección de descargas de SOGo y son los siguientes:
- Mozilla Lightning - Inverse Edition
- SOGo Connector Thunderbird extension
- SOGo Integrator Thunderbird extension
Antes de instalarlos es necesario adaptarlos a nuestro servidor:
SOGo-integrator.
Modificar archivo chrome/content/extensions.rdf para configurar dónde se encuentra el servidor
SOGo<Seq about="http://inverse.ca/sogo-integrator/extensions"
isi:updateURL="https://webmail.midominio.com/plugins/updates.php?plugin=%ITEM_ID%&version=%ITEM_VERSION%&platform=%PLATFORM%">
<li>
Procedimiento para exportar libreta de direcciones a SOGo.
El complemento "SOGo Integrator" copia todos los contactos de la "Libreta personal de direcciones" a la libreta remota en formato DAV y luego ELIMINA la libreta local, dejando únicamente una libreta con conexión al servidor SOGo.
Si queremos mantener los contactos del TB, antes de instalar el complemento SOGo-integrator hay que conectar la libreta personal del usuario como una "Remote Address Book" y copiarle todos los contactos de la " Libreta de direcciones personal".
La URL tiene que ser de la forma:
https://webmail.midominio.com/SOGo/dav/usuario/Contacts/personal/
Algunos problemas.
El complemento para Thunderbird "SOGo Integrator" está configurado por defecto para consultar las direcciones en un directorio de sistema de nombre "public" . Este directorio sería de tipo LDAP y tendría que estar definido en SOGo en el archivo " GNUstep/Defaults/.GNUstepDefaults" . No he podido verificar si esto funcionaría en el caso de crear esa fuente LDAP en la configuración de SOGo, de todas formas no interesa para esta guía porque se trataría de un directorio de "SOLO LECTURA" gestionado vía LDAP por un usuario administrador.
En nuestro caso nosotros queremos un "directorio de empresa" que almacene todos los contactos de la oficina y que sea plenamente accesible (lectura,escritura) por todos los usuarios (se podría limitar a unos concretos) . Esto se consigue creando un "usuario administrativo" que va a tener su "libreta de direcciones" y "calendario" compartido con el resto.
Para ELIMINAR ese directorio "public" que crea este complemento hacemos lo siguiente:
Abrimos el archivo "sogo-integrator-3.104-sogo-demo.xpi" y editamos lo siguiente:
..\defaults\preferences\site.js
BORRAMOS la línea : pref("sogo-integrator.autocomplete.server.urlid", "public");
..\defaults\preferences\sogo-integrator.js
Cambiamos la línea : pref("ldap_2.autoComplete.useDirectory", true);
por pref("ldap_2.autoComplete.useDirectory", false);
Login automático desde TB.
SOGo integrator sincroniza las libretas de direcciones, los contactos y las tareas con el servidor SOGo , para eso tiene que hacer conexiones periódicas a este servidor y eso implica iniciar una sesión.
Debido a la configuración del servidor IMAP en Zentyal ese inicio de sesión fallará tal como está por defecto en el plugin de SOGo. Para solucionarlo es necesario que el login se haga usando el nombre del usuario (variable username ) y no su dirección de correo. Esto se consigue modificando el código del complemento:
Abrimos el archivo "sogo-integrator-3.105-sogo-demo.xpi" y editamos lo siguiente:
../chrome/content/sogo-config.js
if (useEmail)
sogoConfig'username' = mgr.defaultAccount.defaultIdentity.email;
else
sogoConfig'username' = mgr.defaultAccount.incomingServer.realUsername;
Lo cambiamos por esto :
if (useEmail)
sogoConfig['username'|'username'] = mgr.defaultAccount.defaultIdentity.email;
else
sogoConfig'username' = mgr.defaultAccount.incomingServer.username;
Así obligamos a que use la variable "username" en lugar de las otras dos tanto si estábamos usando el correo como nombre de usuario como si no. |
Después de esto deberíamos poder acceder a nuestro servidor Zentyal+SOGo tanto desde el cliente Thunderbird como desde el cliente web en la URL:
https://webmail.midominio.com/SOGo
Saludos.
2
Spanish / Un Active Directory para 2 Zentyal
« on: February 09, 2011, 04:00:50 pm »
Hola a todos,
Una pregunta, ¿ sabe alguien si existe la posibilidad de sincronizar un Active Directory contra 2 Zentyal ?
Tenemos una oficina con varios PDC con Active Directory y hemos instalado dos equipos con zentyal cada uno sincronizado contra un AD distinto, cuando los usuarios cambian sus contraseñas el cambio lo registra un único Active Directory, aunque después se propague al otro, y se lo envía sólo a su zentyal esclavo con el resultado de que los 2 zentyal tienen contraseñas distintas para ese usuario.
¿Se le ocurre a alguien una forma de solucionarlo?
Gracias
Una pregunta, ¿ sabe alguien si existe la posibilidad de sincronizar un Active Directory contra 2 Zentyal ?
Tenemos una oficina con varios PDC con Active Directory y hemos instalado dos equipos con zentyal cada uno sincronizado contra un AD distinto, cuando los usuarios cambian sus contraseñas el cambio lo registra un único Active Directory, aunque después se propague al otro, y se lo envía sólo a su zentyal esclavo con el resultado de que los 2 zentyal tienen contraseñas distintas para ese usuario.
¿Se le ocurre a alguien una forma de solucionarlo?
Gracias
3
Installation and Upgrades / Trying to add a static route using hooks
« on: January 08, 2011, 01:04:43 am »
Hi,
I have two offices connected with a Zentyal to Zentyal VPN, I would like that my external clients could reach the whole network connecting to any site. To do this I need to add a static route everytime the openvpn is up an running.
This is the route:
route add -net 192.168.170.0 netmask 255.255.255.0 gw 192.168.150.1
If a run the command manually the route is added to the routing table and I get what I want, but it doesn't work if i put it in a hook file.
This is my hook:
openvpn.postservice
if [ "$1" -eq "1" ]
then
/sbin/route add -net 192.168.170.0 netmask 255.255.255.0 gw 192.168.150.1
fi
exit 0
And this is what i get in the ebox.log when the openvpn service restart
2011/01/08 00:28:00 INFO> Base.pm:151 EBox::Module::Base::save - Restarting service for module: openvpn
2011/01/08 00:28:02 INFO> Base.pm:756 EBox::Module::Base::_hook - Running hook: /etc/ebox/hooks/openvpn.postservice 1
It seems like everything works fine but the new route is not being added to the routing table.
Am i missing something ? Any clue?
Thanks.
I have two offices connected with a Zentyal to Zentyal VPN, I would like that my external clients could reach the whole network connecting to any site. To do this I need to add a static route everytime the openvpn is up an running.
This is the route:
route add -net 192.168.170.0 netmask 255.255.255.0 gw 192.168.150.1
If a run the command manually the route is added to the routing table and I get what I want, but it doesn't work if i put it in a hook file.
This is my hook:
openvpn.postservice
if [ "$1" -eq "1" ]
then
/sbin/route add -net 192.168.170.0 netmask 255.255.255.0 gw 192.168.150.1
fi
exit 0
And this is what i get in the ebox.log when the openvpn service restart
2011/01/08 00:28:00 INFO> Base.pm:151 EBox::Module::Base::save - Restarting service for module: openvpn
2011/01/08 00:28:02 INFO> Base.pm:756 EBox::Module::Base::_hook - Running hook: /etc/ebox/hooks/openvpn.postservice 1
It seems like everything works fine but the new route is not being added to the routing table.
Am i missing something ? Any clue?
Thanks.
4
Spanish / Dudas sobre una configuración maestro - esclavo
« on: December 09, 2010, 05:08:59 pm »
Hola,
He estado testeando la versión 2.0-2 de Zentyal con la idea de migrar una configuración basada en Ubuntu a una basada en Zentyal, pero me surgen un par de dudas importantes que quizás alguien pueda resolverme.
Actualmente tenemos dos oficinas conectadas vía OpenVPN usando 2 servidores con Ubuntu Hardy. Uno de los servidores está configurado como PDC y el otro como BDC, los usuarios con sus clientes windows se autetican contra el servidor correspodiente en cada oficina. La base de datos de usuarios está en LDAP usando una configuración multi-maestro de forma que se puede actualizar tanto en una oficina como en la otra porque los cambios se transmiten desde un maestro al otro. Así los usuarios comparten archivos en los dos servidores indistintamente y se pueden autenticar en cualquiera de los equipos de las 2 oficinas.
Si no he entendido mal, en Zentyal sólo se puede crear una configuración maestro-esclavo y los usuarios sólo pueden autenticarse contra el maestro. Y aquí es dónde surge el problema. Para compartir la base de datos de usuarios supongo que en una de ellas tendría que haber un maestro ldap y un esclavo y en la otra sólo un esclavo, además cada esclavo sería el PDC de su oficina. Pero qué pasaría en el caso de tener un fallo en la línea que hiciese caer la VPN. Los clientes windows se podrían seguir logueando siempre que ya tuvieran el perfil del usuario pero ahora vamos a tener también clientes linux, entiendo que éstos no podrían entrar en la red con los usuarios LDAP , ¿ alguien me lo puede confirmar ?.
Y otra cosa, los clientes linux, como sólo pueden autenticar contra el zentyal maestro, no pueden usar el paquete "zentyal-desktop" para configurar los recursos compartidos con samba ya que los servicios que dependen de "usersandgroups" no pueden existir en un servidor LDAP maestro. Por lo que he visto , si configuramos "zentyal-desktop" contra el maestro (que no tiene SAMBA) lo único que puede hacer es crear un enlace en el escritorio al recurso del usuario en el servidor, pero cuando picas en él te pregunta siempre todos los datos de conexión ( usuario, contraseña y dominio ) ya que no los ha podido obtener del LDAP. ¿Es ese el funcionamiento correcto? ¿Alguien más lo ha probado?
(Ya he consultado el foro y el trac pero no encuentro una respuesta, lo más cercano lo tenéis en http://trac.zentyal.org/ticket/1872 que es la base de mis suposiciones )
Gracias y un saludo.
He estado testeando la versión 2.0-2 de Zentyal con la idea de migrar una configuración basada en Ubuntu a una basada en Zentyal, pero me surgen un par de dudas importantes que quizás alguien pueda resolverme.
Actualmente tenemos dos oficinas conectadas vía OpenVPN usando 2 servidores con Ubuntu Hardy. Uno de los servidores está configurado como PDC y el otro como BDC, los usuarios con sus clientes windows se autetican contra el servidor correspodiente en cada oficina. La base de datos de usuarios está en LDAP usando una configuración multi-maestro de forma que se puede actualizar tanto en una oficina como en la otra porque los cambios se transmiten desde un maestro al otro. Así los usuarios comparten archivos en los dos servidores indistintamente y se pueden autenticar en cualquiera de los equipos de las 2 oficinas.
Si no he entendido mal, en Zentyal sólo se puede crear una configuración maestro-esclavo y los usuarios sólo pueden autenticarse contra el maestro. Y aquí es dónde surge el problema. Para compartir la base de datos de usuarios supongo que en una de ellas tendría que haber un maestro ldap y un esclavo y en la otra sólo un esclavo, además cada esclavo sería el PDC de su oficina. Pero qué pasaría en el caso de tener un fallo en la línea que hiciese caer la VPN. Los clientes windows se podrían seguir logueando siempre que ya tuvieran el perfil del usuario pero ahora vamos a tener también clientes linux, entiendo que éstos no podrían entrar en la red con los usuarios LDAP , ¿ alguien me lo puede confirmar ?.
Y otra cosa, los clientes linux, como sólo pueden autenticar contra el zentyal maestro, no pueden usar el paquete "zentyal-desktop" para configurar los recursos compartidos con samba ya que los servicios que dependen de "usersandgroups" no pueden existir en un servidor LDAP maestro. Por lo que he visto , si configuramos "zentyal-desktop" contra el maestro (que no tiene SAMBA) lo único que puede hacer es crear un enlace en el escritorio al recurso del usuario en el servidor, pero cuando picas en él te pregunta siempre todos los datos de conexión ( usuario, contraseña y dominio ) ya que no los ha podido obtener del LDAP. ¿Es ese el funcionamiento correcto? ¿Alguien más lo ha probado?
(Ya he consultado el foro y el trac pero no encuentro una respuesta, lo más cercano lo tenéis en http://trac.zentyal.org/ticket/1872 que es la base de mis suposiciones )
Gracias y un saludo.
5
Installation and Upgrades / slapd[]: connection_read( ): no connection!
« on: March 09, 2010, 07:34:33 pm »
Hola ,
Estoy testeando la versión 1.4 de ebox antes de ponerla en producción y me he encontrado con que el LDAP me está saturando los logs con mensajes como esté:
slapd[4743]: connection_read(38): no connection!
Estos mensajes aparecen cada vez que se ejecuta alguna tarea programada del sistema ebox. P.ej:
/usr/share/ebox-usersandgroups/slave-sync
/usr/share/ebox/ebox-cronjob-runner
/usr/share/ebox-mail/fetchmail-update
"Googleando" un poco el tema parece que uno de los motivos de este mensaje podría ser que el cliente que hace la consulta a LDAP no la termina correctamente ("clients not unbinding before closing").
He visto que existe otro post en el foro sobre el mismo tema pero sin respuesta. ¿ No le pasa esto a nadie más ? Mi instalación esta hecha con la iso bajada de EBOX ( Ubuntu 8.04 si me equivoco + EBOX) y no le he añadido nada simplemente he actualizado los paquetes.
Alguna idea
Gracias.
Estoy testeando la versión 1.4 de ebox antes de ponerla en producción y me he encontrado con que el LDAP me está saturando los logs con mensajes como esté:
slapd[4743]: connection_read(38): no connection!
Estos mensajes aparecen cada vez que se ejecuta alguna tarea programada del sistema ebox. P.ej:
/usr/share/ebox-usersandgroups/slave-sync
/usr/share/ebox/ebox-cronjob-runner
/usr/share/ebox-mail/fetchmail-update
"Googleando" un poco el tema parece que uno de los motivos de este mensaje podría ser que el cliente que hace la consulta a LDAP no la termina correctamente ("clients not unbinding before closing").
He visto que existe otro post en el foro sobre el mismo tema pero sin respuesta. ¿ No le pasa esto a nadie más ? Mi instalación esta hecha con la iso bajada de EBOX ( Ubuntu 8.04 si me equivoco + EBOX) y no le he añadido nada simplemente he actualizado los paquetes.
Alguna idea
Gracias.
Pages: [1]