Desarrollo Linux y software libre

Revisión técnica (octubre de 2026): El error del ejemplo aparece al conectar con el canal de PEAR de una instalación histórica. No elimines repositorios ni rebajes la seguridad TLS sin comprobar la configuración del canal y la versión de PHP/PEAR. Comprueba si el paquete sigue mantenido y si existe una alternativa actual antes de reutilizar instrucciones antiguas.

Se conserva debajo el artículo original como referencia histórica.

Instalando módulos de Pear puede ocurrir, sobre todo en versiones inestables de Ubuntu, el siguiente error:

root@prueba-egroupware:/usr/share/egroupware/# sudo pear install Auth_SASL
pear.php.net is using a unsupported protocal - This should never happen.
install failed

Se soluciona borrando los repositorios extras que vienen por defecto añadidos:

root@prueba-egroupware:# rm /usr/share/php/.channels/*
root@prueba-egroupware:# pear update-channels
Updating channel "doc.php.net"
Update of Channel "doc.php.net" succeeded
Updating channel "pear.php.net"
Update of Channel "pear.php.net" succeeded
Updating channel "pecl.php.net"
Update of Channel "pecl.php.net" succeeded

Y ya quedaría listo el sistema para instalar módulos, por ejemplo:
root@prueba-egroupware:/# pear install Auth_SASL
downloading Auth_SASL-1.0.3.tgz ...
Starting to download Auth_SASL-1.0.3.tgz (5,724 bytes)
.....done: 5,724 bytes

En la instalación de eGroupware 1.6 en Debian/Ubuntu puede ocurrir el siguiente mensaje de error:

Comprobando si .././sitemgr-doc no tiene permiso de escritura para todo el mundo:
¡¡.././sitemgr-doc no existe!!

La ruta indicada parece ser equívoca, al no existir en el directorio previo un directorio llamado «sitemgr» conteniendo a otro llamado «doc». En realidad se refiere a ./sitemgr/doc. Por tanto se soluciona adecuando los permisos de este directorio:

$ cd /usr/share/egroupware
$ sudo chmod -R 755 sitemgr
$ rm -Rf sitemgr/doc
$ mkdir sitemgr/doc
$ chmod 777 sitemgr/doc


Revisión técnica (octubre de 2026): El ejemplo original se basa en Python 2.6 y una utilidad Web-Shell antigua. Python 2 está fuera de soporte; no publiques esa consola en redes accesibles desde Internet. Para diagnosticar, revisa la excepción completa y los registros, identifica el origen del fallo y migra a software soportado en lugar de instalar sin más bibliotecas antiguas.

Se conserva debajo el artículo original como referencia histórica.

Si al ejecutar la utilidad Web-Shell se producen trazas similares a éstas:

Exception happened during processing of request from ('172.26.0.4', 35859)
Traceback (most recent call last):
File "/usr/lib/python2.6/SocketServer.py", line 281, in _handle_request_noblock
self.process_request(request, client_address)
File "/usr/lib/python2.6/SocketServer.py", line 307, in process_request
self.finish_request(request, client_address)
File "/usr/lib/python2.6/SocketServer.py", line 320, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/lib/python2.6/SocketServer.py", line 615, in __init__
self.handle()
File "/usr/lib/python2.6/BaseHTTPServer.py", line 329, in handle
self.handle_one_request()
File "/usr/lib/python2.6/BaseHTTPServer.py", line 312, in handle_one_request
self.raw_requestline = self.rfile.readline()
File "/usr/lib/python2.6/socket.py", line 404, in readline
data = self._sock.recv(self._rbufsize)
Error: [('SSL routines', 'SSL23_GET_CLIENT_HELLO', 'http request')]
----------------------------------------
----------------------------------------
Exception happened during processing of request from ('172.26.0.4', 35860)
Traceback (most recent call last):
File "/usr/lib/python2.6/SocketServer.py", line 281, in _handle_request_noblock
self.process_request(request, client_address)
File "/usr/lib/python2.6/SocketServer.py", line 307, in process_request
self.finish_request(request, client_address)
File "/usr/lib/python2.6/SocketServer.py", line 320, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/lib/python2.6/SocketServer.py", line 615, in __init__
self.handle()
File "/usr/lib/python2.6/BaseHTTPServer.py", line 329, in handle
self.handle_one_request()
File "/usr/lib/python2.6/BaseHTTPServer.py", line 312, in handle_one_request
self.raw_requestline = self.rfile.readline()
File "/usr/lib/python2.6/socket.py", line 404, in readline
data = self._sock.recv(self._rbufsize)
Error: [('SSL routines', 'SSL23_GET_CLIENT_HELLO', 'http request')]
----------------------------------------
----------------------------------------
Exception happened during processing of request from ('172.26.0.4', 35861)
Traceback (most recent call last):
File "/usr/lib/python2.6/SocketServer.py", line 281, in _handle_request_noblock
self.process_request(request, client_address)
File "/usr/lib/python2.6/SocketServer.py", line 307, in process_request
self.finish_request(request, client_address)
File "/usr/lib/python2.6/SocketServer.py", line 320, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/lib/python2.6/SocketServer.py", line 615, in __init__
self.handle()
File "/usr/lib/python2.6/BaseHTTPServer.py", line 329, in handle
self.handle_one_request()
File "/usr/lib/python2.6/BaseHTTPServer.py", line 312, in handle_one_request
self.raw_requestline = self.rfile.readline()
File "/usr/lib/python2.6/socket.py", line 404, in readline
data = self._sock.recv(self._rbufsize)
Error: [('SSL routines', 'SSL23_GET_CLIENT_HELLO', 'http request')]
----------------------------------------

Se debe sencillamente a un uso incorrecto de la aplicación. La web se ha accedido por http cuando debe ser por https.
http://172.26.0.5:8022/
https://172.26.0.5:8022/

Además, si se desea monitorizar con Monit, es necesario añadir las siguientes líneas al fichero de configuración

#sudo nano /etc/monit/monitrc
(...)
check host WebShell_8022 with address 127.0.0.1
start program = "/usr/bin/python /etc/WebShell/webshell.py &"
stop program = "/usr/bin/killall -9 python /etc/WebShell/webshell.py"
if failed port 8022 then restart
(...)

adaptando las rutas, y reiniciar Monit

#sudo /etc/init.d/monit restart

Nota de vigencia (octubre de 2026): el procedimiento se publicó en 2009 y utiliza una estructura de copia de Plesk que no tiene por qué coincidir con los formatos de versiones modernas. Comprueba primero el tipo real de fichero con file y consulta las herramientas oficiales de restauración de la versión de Plesk que generó la copia.

No extraigas archivos de procedencia desconocida con privilegios de administrador y no asumas que todos los elementos recuperados son archivos tar.gz. Conserva una copia íntegra de la copia original antes de probar herramientas de extracción.

Relacionado: copias de seguridad con Linux.

El formato de backups de Plesk es distinto al habitual tar.gz, por lo que hay que utilizar una herramienta específica para, posteriormente si, conseguir un tar.gz

1º) Bajar, descomprimir e instalar ripmime

2º) Procesar el fichero con ripmine:
# ripmime -i backup-20090908-mi-dominio.com -d directorioBackupRestaurada

3º) Descomprimir el contenido:
# tar -ztvf directorioBackupRestaurada/*

Fuente: http://forums.deftechgroup.com/showthread.php?t=1087

Actualización de octubre de 2026. Este artículo muestra un caso antiguo de rutas no encontradas al usar reglas de reescritura en Apache. El error no demuestra por sí solo que falte mod_rewrite: comprueba primero que la ruta existe, que las reglas son correctas y que Apache permite su aplicación.

Diagnóstico previo

En Debian/Ubuntu, puedes comprobar si el módulo está habilitado mediante apache2ctl -M y, cuando proceda, activarlo con sudo a2enmod rewrite. Verifica la sintaxis con sudo apache2ctl configtest antes de recargar el servicio. Limita AllowOverride al directorio y a las directivas estrictamente necesarios. Las opciones PHP magic_quotes_gpc y register_globals que figuran en el ejemplo histórico fueron eliminadas de PHP: no copies esa configuración sin revisarla.

Relacionado: recarga gradual de Apache y ajustes PHP en Joomla.

Al ejecutar una aplicación php en un Apache, puede suceder el siguiente error:

The requested URL /var/www/aplicacion1/mysite/public/index.php/auth/login was not found on this server.

Esto probablemente se deba a una directiva especificada en el archivo .htaccess, que solicita al servidor web un determinado comportamiento.

RewriteEngine on
RewriteCond %{REQUEST_URI} !/public/.*
RewriteCond %{REQUEST_URI} !/images/.*
RewriteCond %{REQUEST_URI} !/layout/.*
RewriteRule .* index.php
php_flag magic_quotes_gpc off
php_flag register_globals off
php_value max_execution_time 120

Generalmente el problema es debido a la ausencia del módulo rewrite en la configuración de Apache. Para ello es necesario realizar tres pasos:

1º) Activar el módulo rewrite en Apache2.

ubuntu@ubuntu:/$ sudo a2enmod rewrite
Enabling module rewrite.
Run '/etc/init.d/apache2 restart' to activate new configuration!

2º) Modificar la configuración de Apache para indicar a qué sites alojados debe aplicarse el módulo «rewrite», sustituyendo «AllowOverride none» por AllowOverride All«.
ubuntu@ubuntu:/$ sudo nano /etc/apache2/sites-enabled/000-default

<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/
<Directory />
Options FollowSymLinks
AllowOverride All
</Directory>
(…)

Realizar este cambio por tanto en las entradas en las que se quiera aplicar el módulo rewrite, generalmente en todas.

3º) Reiniciar Apache

root@ubuntu:/etc/apache2/sites-enabled# /etc/init.d/apache2 restart
* Restarting web server htcacheclean                                                                                                               ...not running
apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
[ OK ]

Y de esta manera se consigue activar y configurar el módulo mod_rewrite en Apache2.

Si al instalar en Joomla un plugin se produce el siguiente error:
Joomla! • View topic - JFolder::create: Could not create directory
ó

* JFolder::create: No se ha podido crear el directorio
* Unable to create destination

Es necesario tanto asignar permisos de acceso completo (777) al directorio temporal (habitualmente /tmp) como desactivar el modo seguro de ejecución de php:

#nano /etc/php5/apache2/php.ini
(...)
safe_mode = Off
(...)

Si se trabaja con un hosting ajeno, este cambio se puede hacer desde el panel de control del alojamiento o contactando directamente con el soporte técnico del hosting.

Ante esta limitación, es necesario hacer los siguientes cambios en el módulo PHP:
carlos@pilar002:/etc/php5/apache2$ nano php.ini
(...)
memory_limit = 256M
max_execution_time = 300
max_input_time = 600
post_max_size = 64M
upload_max_filesize = 64M
(...)

Configuración de MySQL:
carlos@pilar002:/etc/mysql$ nano my.cnf
(...)
max_allowed_packet: 64MB
(...)

Y reiniciar ambos servicios:
/etc/init.d/apache2 restart
/etc/init.d/mysql restart

fuente: PenoyTechCentral

Nota de seguridad (octubre de 2026): el ejemplo original menciona credenciales predeterminadas y propone cambios de permisos SQL. No utilices credenciales por defecto ni concedas privilegios globales para solucionar un inicio de sesión fallido.

Comprueba la versión instalada, los registros de Eventum y de la base de datos, los parámetros de conexión y los permisos efectivos del usuario de aplicación. Concede solo los privilegios necesarios sobre su base de datos específica. La causa de un fallo de acceso puede ser distinta de los permisos y requiere diagnóstico previo.

Relacionado: servidores y aplicaciones web.

Si tras instalar Eventum no se tiene acceso con el login por defecto (admin@example.com / admin), lo más probable es que el usuario de acceso a la base de datos de Eventum no tenga acceso a la misma, y por tanto no pueda constantar si el usuario introducido existe en la BD.

Para ello es preciso darle permisos:

pilar002:/var/www/eventum/config# mysql -u root -h localhost -p
Enter password:

mysql> GRANT ALL on eventumDB.* TO usuarioEventum@locahost;

una solución más directa es dar permisos a todas las bases de datos, sabiendo lo que se hace en cuestiones de seguridad:
mysql> GRANT SELECT ON *.* TO usuarioEventum

Esta herramienta para manejar y hacer seguimiento de incidencias en cualquier tipo de proyecto de ingeniería actualmente viene en Inglés. En la versión actual (2.1.1) no incorpora el Español, por lo cual si se desea traducir es necesario incorporar los diccionarios españoles.

Para ello se consultará el SVN del proyecto, se copiarán de él las traducciones y se le especificará a Eventum que utilice por defecto este idioma. Para ello:

1º) Bajarse del SVN todo el proyecto:
mkdir svn.eventum
cd svn.eventum
svn checkout svn://eventum.mysql.org/eventum-gpl/

2º) Localizamos los diccionarios
cd /home/carlos/temp/svn.eventum/eventum-gpl/trunk/eventum/misc/localization

y los copiamos en el directorio de Eventum:
cp -R es /var/www/eventum/misc/localization
cp es.po /var/www/eventum/misc/localization

3º) Activar el idioma Español en Eventum: hay dos formas
a) Copiando el class.language.php del SVN a nuestro Eventum:
cp /home/carlos/temp/eventumSVN/eventum-gpl/trunk/eventum/include/class.language.php /var/www/eventum/includes/class.language.php

b) Descomentando en /var/www/eventum/includes/class.language.php el idioma Español.
No obstante es más fiable el primer método.

4º) Indicar a Eventum el idioma predeterminado: viene en Inglés norteamericano, cambiarlo por es_ES.

nano /var/www/eventum/config/config.php
(...)
//define('APP_DEFAULT_LOCALE', 'en_US');
define('APP_DEFAULT_LOCALE', 'es_ES');
(...)

Y probar a conectarse, ya está traducido. En algún caso se puede necesitar reiniciar Apache:
sudo /etc/init.d/apache2 restart

Además, en el caso de que el hosting sea GNU/Linux, las locales deben estar configuradas en el mismo idioma en el que se desee Eventum:

# dpkg-reconfigure locales

aunque también se puede optar por una solución rápida: reemplazar el valor «en_US» de los siguientes ficheros por «es_ES«:

# nano eventum-2.2\config\config.php
# nano eventum-2.2\init.php

Eventum, el gestor de incidencias, tiene una utilidad muy cómoda para enviar un correo a los «afectados» cuando se crea o modifica una incidencia. Para hacerlo funcionar, a parte de tener que configurar sus parámetros, es necesario meter en el cron las siguientes líneas:

* * * * * cd /home/webadmin/htdocs/eventum/misc; /usr/bin/php -q process_mail_queue.php
*/10 * * * * cd /home/webadmin/htdocs/eventum/misc; /usr/bin/php -q check_reminders.php