El Mon, 06 Aug 2012 13:30:20 -0300, Federico Alberto Sayd escribió: > On 06/08/12 13:03, Camaleón wrote:
>> Bueno, una simple búsqueda por "beta" en los paquetes para Squeeze nos >> devuelve algunos están marcados como "versión de desarrollo": >> >> http://packages.debian.org/search? suite=squeeze&arch=any&searchon=all&keywords=beta >> >> Lo cual es normal, de otra forma no se podrían ir probando y depurando >> las nuevas versiones de las aplicaciones porque la gente sería muy >> reticente a tener que instalar paquetes de fuera de los repos oficiales >> o a tener que compilarse ellos mismos las aplicaciones (e intuyo que >> compilar samba4 no debe ser tarea amena y sencilla :-P) > > Debo decir que me he perdido un poco leyendo las políticas de Debian y > no he encontrado alguna sección que hable sobre qué paquetes deberían > entrar a Stable, más allá de todo el sistema de selección automático > desde testing. Pues se deben aplicar las directrices estándar que se aplican a cualquier paquete que quieras incorporar en la distribución y eso está documento seguro en alguna parte (¿debian-policy?). > En el caso de samba 4 me llama la atención porque es un peso pesado, no > recuerdo otros casos donde en estable entrara una versión beta de > paquetes como Apache, PHP, Bind o MySQL, etc. Porque no se habrá dado el caso (kde 4.0 podría haberse catalogado como beta, perfectamente :-P) y no habrán concurrido en el tiempo como es el caso de samba4. > Además, no sé hasta que punto además se puede dar soporte de seguridad a > un software que está en beta. Que una aplicación sea beta no quiere decir que tenga más o menos problemas de seguridad (como ejemplo perfecto de esto tienes a Chromium, en perpetuo desarrollo) y se incluye en squeeze. Los problemas de seguridad que se vayan descubriendo en samba4 se irán aplicando a través del canal de actualizaciones habitual de la versión estable, no veo el problema :-? >>> Creo que a veces es una cuestión de costo beneficio. Como el hecho de >>> usar paquetes de backports en estable. Pero claro que por razones de >>> seguridad deberían contemplarse todos los detalles y primero montar un >>> entorno de pruebas. De cualquier forma una vuelta por la lista de >>> Samba quizás sirva para despejar más errores. >> Los paquetes de backports al menos incluyen versiones estables. > En realidad a lo que me refería es que backports no tiene soporte de > seguridad oficial de Debian. No sé si será oficial o no pero parches de seguridad sí sacan: http://backports-master.debian.org/News/ (y ojo, que hay paquetes de la versión estable oficialmente soportados y mantenidos con agujeros de seguridad sin parchear...) >> El único problema que le veo a samba4 es que si la metes en producción >> directamente sin tener una segunda opción como alternativa y te casca >> (por el motivo que sea), ya la has liado. No puedes permitirte el lujo >> de tener a todos los usuarios de tu red sin acceso a los recursos o sin >> poder iniciar sesión. Sería interesante poder configurar un equipo >> dedicado con samba4, usarlo como servidor predeterminado pero tener un >> equipo disponible y listo para entrar en acción con samba3 para que >> entre en juego si falla el principal. > Eso es muy cierto. Pero me parece necesario empezar a jugar un poco con > Samba 4 porque va a cambiar todo el panorama de Samba hasta el momento. > Entran en juego Kerberos, un Active Directory embebido y muchos comandos > hasta ahora desconocidos. Incluso proyectos como Openchange que proveen > acceso nativo al protocolo MAPI de Outlook/Exchange dependen de Samba 4. > Si se plantea la migración a futuro, mejor conocer todo el entorno. Por eso, aunque es conveniente tener una máquina con samba4 operativa, dando servicio a la red no hay que olvidar que puede fallarte en cualquier momento y debes de tener un sustituto (aunque sea proporcionando los servicios mínimos) para no quedarte parado en caso de problemas. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
