Repositorios oficiales de php y apache

Dejé centos por lo mismo, me aburrí de que cada vez que saliera una vulnerabilidad crítica, el parche en los repos oficiales salieran el día de la corneta y perdíamos muchísimo tiempo actualizando los paquetes manualmente.

Enviado desde mi JKM-LX3 mediante Tapatalk

ranamaldita dijo:

Remi's RPM repository

rpms.remirepo.net

Haz clic para expandir...

Ese mismo encontré pero p'ta, no me parece muy oficial.

ocupa remi noma, no pasa naá

es el repo para ocupar php actualizado en centos

galansinchance dijo:

Dejé centos por lo mismo, me aburrí de que cada vez que saliera una vulnerabilidad crítica, el parche en los repos oficiales salieran el día de la corneta y perdíamos muchísimo tiempo actualizando los paquetes manualmente.

Enviado desde mi JKM-LX3 mediante Tapatalk

Haz clic para expandir...

opino lo mismo

haciendo magias para tener php actualizado, tengo uno con webs corriendo varias versiones de php , la wea viene base 5.4 y php ya va en 7.4 ?

Epel+REMI es la única más "oficial" que existe

Vale, vamos por remi sin temor.

es bastante seguro , no te rompe el ecosistema de php base

eso si , es simple si solo quieres actualizar la version base , pero si debes mantener el php antiguo y ocupar un php mas actualizado al mismo tiempo debes configurar algo como php-fpm

Eliezar dijo:

es bastante seguro , no te rompe el ecosistema de php base

eso si , es simple si solo quieres actualizar la version base , pero si debes mantener el php antiguo y ocupar un php mas actualizado al mismo tiempo debes configurar algo como php-fpm

Haz clic para expandir...

Ese servidor tiene un código del año de la corneta y por esa razón no puedo subir de rompe y raja a PHP 7. Mi idea es subir del php 5.4 que trae Centos 7 a php 5.6 y probar que no me haya deprecado funciones.

Remi Collet fue RM (release manager) de php 7.2 y además es core colaborator de fedora y php mismo. En su trabajo se basan los repos oficiales de red hat y debian, así que más cerca de oficial no puedes llegar. Ten en cuenta eso si que Red Hat hace bundles de algunos paquetes que php opina que deben de ser instalados de manera separada, pero con el método actual de instalación no deberías tener problemas.

Ud dele no más con remi que es lo más estable que hay. Capa9 de hecho corre a través de su repo pq las distros introducen bugs que la fuente oficial no tiene.

Saludos.

Ah y Apache ya quedó en el olvido. Con el foco en php-fpm y la deprecada de mod_php para Apache no existe ninguna razón para seguir ocupando Apache, nginx hace la misma pega pero mil veces más rápido y eficiente. Lamentablemente si dices que el código no funciona en php7 debe de ser un bodrio de código fuente (sin ofender) así que en ese caso tampoco podría asegurar que vaya a funcionar.

Saludos.

Zuljin dijo:

Ese servidor tiene un código del año de la corneta y por esa razón no puedo subir de rompe y raja a PHP 7. Mi idea es subir del php 5.4 que trae Centos 7 a php 5.6 y probar que no me haya deprecado funciones.

Haz clic para expandir...

A revisar los logs entonces pq la única finalidad de 5.6 era tener un php7 pero sólo en logs manteniendo eso si los quirks de php5.

Si ya no tienes notices en 5.6 el cambio a php7.4 debería ser fácil de hacer ya que hace mucho tiempo ya que han implementado tests para evitar regresiones.

Saludos.

Y que paquetes serian los que no parchan?, porque Red Hat (y a la vez lo que toma Centos) con lo que es vulnerabilidades hace backports. Es cosa de leer los changelogs de los rpm. Nunca suben de version Major un programa para evitar romper la instalación.

Mas info acá:

Como opción para tener versiones más actualizadas te da de usar los RHSCL / Centos SCL y en RHEL8/Centos8, además tienes los appstream.

unreal4u dijo:

Ah y Apache ya quedó en el olvido. Con el foco en php-fpm y la deprecada de mod_php para Apache no existe ninguna razón para seguir ocupando Apache, nginx hace la misma pega pero mil veces más rápido y eficiente. Lamentablemente si dices que el código no funciona en php7 debe de ser un bodrio de código fuente (sin ofender) así que en ese caso tampoco podría asegurar que vaya a funcionar.

Saludos.

Haz clic para expandir...

Es un código más viejo que la cresta, de antes de que creáramos CHW con Avena.
Cuando lo estuve portando de Redhat 3 a Centos 7 para pasarlo a una máquina virtual y depurar la conexión a Oracle que tenía vulnerabilidades, tuve cualquier problema con los string de conexión y otras hueas chicas de php.

Con lo que me he encontrado últimamente (se ve cada bodrio...) el código legacy tiene algunas piedras de tope recurrentes:

1. uso de extensiones obsoletas sobretodo en conexión a BBDD (mysql en vez de mysqli, Mongo en vez de MongoDB). Esto no tiene más arreglo que dentrar a picar pero, de existir, es menos terrible meter un conector que funcione en ambas versiones (ej PDO)
2. de la mano con lo anterior, usa métodos criptográficos obsoletos por ejemplo para hashear (e.g. mcrypt) en vez de password_hash y password_verify, y en general todo lo que se hace con la extensión openssl (que es un tremendo aporte). Acá la solución es meter una librería que haga el polyfill para poder usar los password antiguos que ya están hasheados obsoletamente en la BBDD
3. usa constructores deprecados o son puras funciones (para lo primero es cosa de reemplazar. Lo segundo es rehacer todo)
4. pasa variables por referencia al invocar y no en la declaración del método (revisar caso a caso. A veces basta con redefinir el método, otras veces ni siquiera se usa la referencia)
5. accede a variables que se llenan via register globals (esto es lo peor, me he querido matar)
6. fija variables mágicamente pasando por ejemplo extract como callback (lo ideal es refactorizar pero si no se puede el primer paso es modificar el string callback a un closure... que es una solucion provisoria de esas que después son permanentes)
7. no se me ocurre nada más

@Zuljin dale una mirada a RectorPHP, tiene algoritmos de refactorización automática. Funciona igual que un corrector de estilo como PHPCS-Fixer pero en vez de estilo corrige sintaxis obsoleta.

Amenadiel dijo:

@Zuljin dale una mirada a RectorPHP, tiene algoritmos de refactorización automática. Funciona igual que un corrector de estilo como PHPCS-Fixer pero en vez de estilo corrige sintaxis obsoleta.

Haz clic para expandir...

Está buenísimo. Lo voy a sugerir en la pega porque tenemos un par de sistemas basados en php con código viejo que nos dan dolores de cabeza cuando tenemos que corregir vulnerabilidades.