[Previo por Fecha] [Siguiente por Fecha] [Previo por Hilo] [Siguiente por Hilo]
[Hilos de Discusión] [Fecha] [Tema] [Autor]Leonel Nunez wrote:
Si tu aplicación es crítica tienes servidores de prestaging donde pruebas todo lo que se pueda romper y un protocolo de pruebas que un tercero fue desarrollando en paralelo con tu aplicación, así que cualquier cambi es seguro... Si tu aplicación es normal pues nada más debes tener cuidado con los avisos de actualización de configuraciones que venían en On por default y ahora vienen en Off.4.2.2 y 5 están en diferentes slots. Pero es estúpido estar usando PHP 4.2.2 cuando esa versión ya no es mantenida porque la actual es 4.3.4 y es completamente compatible con todas las anteriores hasta 4.0.lo mismo con php si estoydesarrollando para php 4.2.2 no me obliguen a brincar a la 5.0de planolos cambios de PHP 4.2.2 a 4.3.4 no te obligan de ninguna manera a cambiar tu código, sólamente tienes que tener tu php.ini bién configurado con register_globals activado y no hay ningún problema. Todo programador de PHP que visite www.php.net seguido lo sabría.con todos sus cambios que obligan a modificar codigo y probar la estabilidadde los paquetes nuevos.claro ! pero que tan seguro es ?
no seria recomendable cambiar de global a $_GLOBALS ? y que implica ?
Siempre es mejor estar al día y CVS es tu amigo.
Depende de qué tan modular sea tu sistema unos cuentos de dólares o decenas de milescambios en tu sistema desarrolladoCuanto cuesta ese cambio ?
Cuando digo sistema no es una paginita de 10 scripts son aplicaciones grandes no juguetes. no nukes.Si, unos cientos de dólares, programas tus módulos exprofeso para que sean mantenibles.
Cuando un paquete viejo ya nadie lo mantiene y hay una versión nueva o un paquete distinto con la funcionalidad que necesitas el paquete viejo es obsoleto.Ve el costo beneficio de estar moviendo y moviendo tu aplicacion.Estabilidad si, pero no al costo de la obsolecencia.Define obsolecencia ? y los paquetes VIEJOS no necesariamente son obsoletos.
Yo también he tenido servidores con Linux PPP 6.4 corriendo un liveice última versión las 24 horas pero ese no es un uso general....Para mis propósitos es estúpido tener un Perl 5.6 cuando Perl 5.8 es compatible hacia atrás y me permite usar módulos nuevos que tienen dependencia de 5.8.veamos : tengo muchas versiones de perl a que padre a que chido. Inutil totalmente PARA MIS PROPOSITOS.Aaaa bendita estupides que no tengo que reinstalar perl 5.8 y sus dependencias en todos mis servidores. si con 5.6 funciona , no es obsoleto y esta chido Claro tambien uso perl 5.8 y mis aplicaciones corren desde 5.6 a 5.8 sin modificaciones pero mi plataforma de produccion es Debian y debiantrae 5.6 asi que soloInstalo en mis servers y no tengo que reinstalar y reinstalar yreinstalar por estar "on the edge"
Seria bueno que comentaras tus experiencias con aplicaciones y servidores criticos asi como tu metodo de actualizar tus aplicaciones cuando migras de version de paquete
1. Machupichu y TV con Linux PPP 6.4 1.1 Edité /etc/redhat-release 1.2 Cerré todos los servicios 1.3 Instalé Red Carpet 1 1.4 Actualicé paquetes 1.5 Recompilé OpenSSL y OpenSSH y los instalé en /usr/local 1.6 Desinstalé el OpenSSH y el OpenSSL originales 1.7 Reinstalé el OpenSSH y OpenSSL nuevos 1.8 Instalé Liveice y lo heché a volar1.9 No volví a visitar esas máquina más que para hacer actualizaciones de OpenSSH, OpenSSL o con Red Carpet 1.10 La última vez que las vi llevaban unos 2 años trabajando solitas sin parar
1.11 Siguen con Linux PPP 6.4 2. Huitzilopochtli con Red Hat 7.1 2.1 Recompilé el kernel 2.2 Copié el directorio /usr/local del servidor anterior 2.3 Copié los sitios y las basews de datos del servidor anterior2.4 Desde el DNS moví los sitios al servidor nuevo, nadie se enteró, la operación no se interrumpió
2.5 Lo usé durante varios meses
2.6 Instalé Red Carpet
2.7 Usé Red Carpet variuos meses para instalar paquetes
2.8 Actualicé a Red Hat 7.2 con Red Carpet (Cero downtime)
2.8.1 Instalé el paquete redhat-release de Red Hat 7.2
2.8.2 Suscribí mi Red Carpet al nuevo canal redhat-7.2
2.8.3 Actualicé Glibc
2.8.4 Actualicé el resto de los paquetes en grupos de 20
2.8.5 Reinicié Sendmail y teapop
2.8.6 Todo lo demás siguió corriendo como si nada
2.8.7 Para OpenSSH y OpenSSL instalé los paquetes a pata con rpm
-Uvh --justdb
2.9 Actualicé a Red Hat 7.3 con Red Carpet (cero downtime)2.10 Todo ese tiempo actualicé mis paquetes de /usr/local a pata desde código fuente (última versión estable)
3. Guadalupe Reyes con Red Hat 7.33.1 Parecido a Huitzilopochtli pero usé Red Carpet 2 para actualizar a Red Hat 8.0
3.2 Luego actualicé a Red Hat 9 3.3 Sólamente tuve que reiniciar Sendmail, Teapop, Bind y Samba
Entonces contradices eso de que necesita las características de Perl 5.6.1 y no de 5.8.3 porque ambos te sirven.Mi aplicacion necesita las caracteristicas de PERL 5.6.1 no de 5.8.3Tu aplicación tiene un espantoso problema de portabilidad.No mi chato estas pero mal mal desarrolle para perl 5.6.1 y esta probado que funciona con 5.8.3 asi para que migrar TODOS los servers y no son menos de 5.
Porque eres un irresponsable que ya no quiere mantener sus propias aplicaciones.Entiende ! POR CAMBIOS DE VERSIONES EN LOS PAQUETESPorque trabajar en algo que no es necesario ? No me pagan por eso. Es mas irresponsable poner en produccion cosas que no han sido probadasPor ejemploYO No recomiendo AUN el kernel 2.6 porque ? no por flojera ni irresponsabilidad
¿Y conoces alguna distro que lo recomiende para producción?
Habría algunos casos en que yo podría recomendar Linux 2.6 para producción, pero son muy específicos y los contaría con los dedos de mi mano izquierda.Es un kernel muy muy nuevo y si en mi casa jala bien no lo recomiendo para produccion presisamente por RESPONSABILIDAD.
Los que han desarrollado aplicaciones criticas saben a lo que me refiero.Para eso existen dos inventos: 1. Prestaging y 2. Protocolo de validaciónY los que han desarrollado aplicaciones críticas saben que deben tener contempladoa procedimientos de actualización, de migración y de contingencia.Eso lo tengo previsto y no le saco al jale.
Por fin decídete, ¿actualizas o no actualizas?
-- Sandino Araico Sánchez -- Melón se comió las plumas.... _______________________________________________ Ayuda mailing list Ayuda en linux org mx Para salir de la lista: http://mail.linux.org.mx/mailman/listinfo/ayuda/