[Ayuda] Re: [Ayuda] Re: [Ayuda] Re: [Ayuda] Re: [Ayuda] Cambio de distribución

[Sandino Araico Sanchez]

Leonel Nunez wrote:

>
>>>>>lo mismo con php si estoy
>>>>>desarrollando para php 4.2.2  no me obliguen a brincar a la 5.0 
>>>>>
>>>>>          
>>>>>
>>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.
>>
>>    
>>
>
>de plano
>
>  
>
>>>>>con
>>>>>todos sus cambios que obligan a modificar codigo y probar la estabilidad
>>>>>de los paquetes nuevos. 
>>>>>
>>>>>          
>>>>>
>>los 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.
>>
>>    
>>
>
>claro !  pero que tan seguro es ?
>  
>
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.

>no seria recomendable  cambiar de global a  $_GLOBALS ?  y que implica ?
>  
>
Siempre es mejor estar al día y CVS es tu amigo.

>cambios en tu sistema desarrollado
>
>Cuanto cuesta ese cambio ? 
>  
>
Depende de qué tan modular sea tu sistema unos cuentos de dólares o 
decenas de miles

>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.

>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.
>
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.

>  
>
>>>veamos :
>>>
>>>tengo muchas versiones de perl  a que padre a que chido.   Inutil
>>>totalmente PARA MIS PROPOSITOS.
>>> 
>>>
>>>      
>>>
>>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.
>>    
>>
>
>
>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 debian
>trae 5.6 asi que solo 
>
>Instalo en mis servers y no tengo que reinstalar y reinstalar y
>reinstalar por estar "on the edge"  
>
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....

>
>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 volar
    1.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 anterior
    2.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.3
    3.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

>  
>
>>>Mi aplicacion necesita las caracteristicas de PERL 5.6.1 no de  5.8.3
>>> 
>>>
>>>      
>>>
>>Tu 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.
>
Entonces contradices eso de que necesita las características de Perl 
5.6.1 y no de 5.8.3 porque ambos te sirven.

>
>>Porque eres un irresponsable que ya no quiere mantener sus propias 
>>aplicaciones.
>>
>>    
>>
>
>
>Entiende !  POR CAMBIOS DE VERSIONES EN LOS PAQUETES 
>
>Porque trabajar en algo que no es necesario ?  No me pagan por eso.
>
>Es mas irresponsable poner en produccion cosas que no han sido probadas
>
>Por ejemplo 
>
>YO No recomiendo AUN  el kernel 2.6  porque ? no por flojera ni
>irresponsabilidad
>
¿Y conoces alguna distro que lo recomiende para producción?

>
>Es un kernel muy muy nuevo y si en mi  casa jala bien  no lo recomiendo
>para produccion
>
>presisamente por RESPONSABILIDAD.
>
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.

>>>Los que han desarrollado  aplicaciones  criticas saben a lo que me
>>>refiero.
>>>
>>> 
>>>
>>>      
>>>
>>Para eso existen dos inventos:
>>1. Prestaging
>>y
>>2. Protocolo de validación
>>
>>Y 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/