perl apache mod-perl

¿Cómo utilizo un proveedor Apache con un Perl auto compilado y mod_perl?



mod-perl (3)

  1. Cree su versión de Perl 5.10 siguiendo las instrucciones especiales de la documentación de mod_perl. Dile al configurador de Perl que se instale en algún lugar no estándar, como /usr/local/perl/5.10.0

  2. Use las instrucciones para compilar una biblioteca compartida (o dinámica, o .so) mod_perl contra el Apache de su distribución, pero asegúrese de ejecutar Makefile.PL usando su versión de perl:

    /usr/local/perl/5.10.0/bin/perl Makefile.PL APXS = / usr / bin / apxs

  3. Instala y configura mod_perl como es normal.

Puede ser útil, después del primer paso, cambiar su ruta para que no se confunda accidentalmente con la versión de Perl que está utilizando:

export PATH=/usr/local/perl/5.10.0/bin:$PATH

Quiero usar el Apache incorporado de Apple o RedHat, pero quiero usar Perl 5.10 y mod_perl. ¿Cuál es la forma menos intrusiva de lograr esto? Quiero la ventaja de parches de seguridad gratuitos para Apache, dav, php, etc. del proveedor, pero me preocupo mucho por la versión de Perl que uso y lo que está en mi ruta @INC. No me importa compilar mi propio mod_perl.


He hecho esto antes. No fue bonito, pero funcionó, especialmente porque los proveedores de Perl suelen tener entre 2 y 3 años.

Empecé haciendo mi propio RPM de perl que instaló perl en una ubicación diferente, como /opt/ . Esto fue bastante directo. Comencé principalmente con esto porque no quería que las utilidades del sistema que usaban Perl se rompieran cuando actualicé / instalé nuevos módulos. Tuve que modificar todos mis scripts para especificar #!/opt/bin/perl en la parte superior y, a veces, incluso jugué con la ruta para asegurarme de que mi perl fuera el primero.

Luego, agarré un RPM fuente mod_perl y lo modifiqué para usar mi /opt/bin/perl lugar de /usr/bin/perl . No tengo acceso a los cambios que hice, ya que estaba en un concierto diferente. Me costó un poco jugar para conseguirlo.

Funcionó, pero no soy un asistente de RPM, por lo que la comprobación de la dependencia no funcionó tan bien. Por ejemplo, podría desinstalar mi RPM personalizado y romper todo. No fue un gran problema para mí, así que seguí adelante.

También estaba mezclando RPM con las instalaciones de módulos de CPAN (¿mencioné que construimos nuestro propio espejo CPAN personalizado con nuestro propio código?). Esto fue un poco frágil también. Una vez más, no tenía los recursos (es decir, el tiempo) para averiguar cómo doblar cpan2rpm para usar mi perl y no causar conflictos de RPM.

Si tuviera que hacer todo de nuevo, haría un RPM personalizado de 5.10 perl y simplemente reemplazaría el perl del sistema. Luego usaría cpan2rpm para crear los paquetes RPM que necesitaba para mi software y compilar mi propio RPM mod_perl.