Hace poco tuve un problema con un servidor: se quedó sin espacio en disco. Al limpiarlo, empezó la base de datos a dar errores. Fuí al log de MySQL y me encontré con muchas líneas de error, pero el que me llamó la atención me decía que “Incorrect key file for table ‘/tmp/#sql_3c51_0.MYI’; try to repair it”. Básicamente era que no podía ejecutar SQL grandes porque el espacio en /tmp no era suficiente.

Las soluciones al error pasaban por hacer backup de todas las BD, descargártelas, borrar ciertos archivos y volver a restaurarlas, pero yo dudaba de que ese trabajo sirviera de algo. Entonces encontré esta explicación:

Por defecto, MySQL tiene asignado el directorio /tmp del raíz para hacer sus tareas. Cuando la partición raíz está llena, Debian (o Ubuntu en mi caso), crea en RAM una partición /tmp de 1 mega para que MySQL siga funcionando para las funciones básicas, pero no para traerse datos de uan web, por ejemplo. Si hacemos df -h, veremos una línea parecida a esta:

La solución consiste simplemente en borrar esa partición, y volverá a coger el directorio /tmp del raíz. Es decir, hacemos

Y para estar más seguros reiniciaremos el servicio de MySQL. Y todo arreglado.

 

A veces nos ha ocurrido que aunque la plataforma Magento (versión 1.9) funciona perfectamente y las URLs van bien, cuando hemos querido instalar desde el Downlader una extensión con la URL del Marketplace de Magento, nos ha dado el error:

Leer más

Cuando la función on_sent_ok os de el error de ajuste obsoleto (o is Deprecated), habrá que cambiar la función que tenemos por código JavaScript.

En nuestro caso, el cliente tenía una redirección a una URL, con lo que cambiamos el código a

[crayon-5adb57e789b77467549191/]

 

 

Si tenemos un WordPress y estamos trabajando con JQuery, puede que no se ejecute debido al siguiente error:

[crayon-5adb57e789db3566617890/]

Para solucionar esto, simplemente envolveremos nuestro código JQuery con

[crayon-5adb57e789dba889712712/]

¿Por qué ocurre esto?. Sencillo, estamos ejecutando JQuery en modo “noConflicto”

[crayon-5adb57e789dbc139826696/]

por lo que la notación $ no la reconoce, así que necesitamos envolver nuestra función de forma que pueda ejecutarse correctamente.

A veces puede ocurrirte que tu cámara integrada de tu MacBook Pro no funcione, y el sistema te diga que no reconoce ninguna cámara en tu equipo. No te desesperes en ese caso, abre una ventana de Terminal y escribe

[crayon-5adb57e78a023587144596/]

Te pedirá tu contraseña de usuario administrador del equipo, se la escribes, y volverás a tener tu cámara disponible.

Puede que al configurar vuestro servidor Ubuntu 14.04 os hayáis encontrado con un mensaje como este al reiniciar Apache.Error al reiniciar Apache

 

No dejéis que la línea final, “The Apache error log may have more information”, os despiste. El log de error de Apache probablemente no tenga información útil sobre el “incidente”, puesto que el servicio no está activo debido a este error. Si editamos el archivo (000-ispconfig.vhost) y la línea (17) indicada en el error sintáctico, nos encontraremos con algo parecido a esto (no tiene por qué ser igual):

 Options Indexes FollowSymLinks MultiViews +ExecCGI

Lo que nos viene a decir el error es que todos los elementos que siguen a “Options” deben llevar un signo +  -, o bien (la otra opción) es que ninguno lo lleve. Puede que comparéis esta línea con la de otras configuraciones y os llevéis la sorpresa de que no da problemas siendo exactamente igual.

Esto se debe a la versión de Apache que se esté utilizando. Esta sintaxis sería perfectamente válida en Apache 2.2.22, por ejemplo, pero daría este error a partir de la versión 2.4.

La solución es sencilla: Hacer lo que nos dicen: Si tenemos alguna opción con signo, entonces todas deben llevarlo. O bien, que ninguna lleve signo. No vamos a entrar en detalle sobre dónde colocar los + y los -, pues eso va más allá de nuestro objetivo en esta nota. Simplemente reseñar que con eliminar el signo + que precede a ExecCGI, el error desaparecería, pero si queremos dejar la configuración tal y como está, lo correcto sería quitar todas las opciones que no llevan signo, pues al no llevarlo es como si no estuvieran. De este modo, dicha línea quedaría como Options +ExecCGI.

Hace poco estaba trabajando sobre un Ubuntu 14.04 LTS Desktop cuando empezó a darme errores icomprensibles: MySQL dejó de funcionarme, no podía levantarlo de nuevo, y otros servicios de la máquina fueron cayendo poco a poco. Decidí reiniciarlo y al hacerlo, empezó mi calvario. Me mostraba la pantalla de logado, era capaz de reconocer si la contraseña era o no correcta, pero no terminaba de arrancar. Después de chequear sistema, HD, arrancar modificando el Grub y todo lo que se me ocurrió y no encontrar nada reseñable, logré arreglarlo y recuperar el sistema intacto haciendo lo siguiente:
Reiniciamos el sistema y mantenemos pulsadas Ctrl + Alt + F3 hasta que podemos logarnos en la shell.
Hacemos un ls -ld /tmp. Así obtenemos los permisos del directorio /tmp.Si todo es correcto, debe salir algo parecido a esto:
drwxrwxrwt 15 root root 4096 Aug 22 09:17 /tmp.

En mi caso lo que realmente tenía era:
d——–T 15 root root 4096 Nov 30 04:17 /tmp

Así que lo que tuve que hacer es darle permisos a /tmp (con un chmod tenemos de sobra) y reiniciar. Y todo volvió a la normalidad. El por qué del error, probablemente fueron las actualizaciones, o algún error puntual en la copia de seguridad que dejó el directorio /tmp con permisos cambiados.

Si en un Moodle recién instalado, cuando intentamos añadirle un módulo, plugin o plantilla:

  1. se nos queda en blanco la pantalla,
  2. nos da un error de permisos no válidos,
  3. en el error.log de nuestros logs nos encontramos con este error:

[error]  FastCGI: server “/var/www/XXX/cgi-bin/php5-fcgi-*-80-dominio.com” stderr: PHP message: PHP Fatal error:  Uncaught exception ‘invalid_dataroot_permissions’ with message ‘Invalid permissions detected in $CFG->dataroot directory, administrator has to fix permissions.’ in /var/www/XXX/lib/setuplib.php:1278

Lo único que tenemos que hacer es irnos a la carpeta moodledata, y mirar los permisos de las carpetas que están dentro de ésta. Los permisos de estas subcarpetas y sus archivos deben ser de 777 (según recomiendan en Moodle.org).

Si los permisos son los correctos, o no nos da ese error de permisos no válidos, podemos hacer lo siguiente:

  1. quitamos el plugin, plantilla o módulo.
  2. nos logamos y activamos el modo debug en Moodle
  3. volvemos a colocar el plugin, plantilla o módulo a instalar
  4. volvemos a cargar la web. Nos devolverá un error. Lo más probable es que haya un error de tiempo de ejecución demasiado corto.

Para corregir ese error, lo mejor es ir a php.ini y ampliar el parámetro

[crayon-5adb57e78a40b391151680/]

 

Seguro que más de una vez habeis tenido una web con su certificado SSL, y os ha dado el error de que hay elementos no seguros en ella.

Este error es muy sencillo de corregir y se da cuando en una página que va sobre HTTPS, tiene referencias a elementos HTTP.

Para no tener que revisar cada una de las líneas de nuestro código buscando las referencias erróneas, podemos ir a la web http://www.whynopadlock.com y darle la URL de la página que nos devuelve ese error de elementos no seguros, y nos dará un informe de cada elemento no seguro, incluidas imágenes de la hoja de estilo, enlaces no seguros, etc.

Instalas un Moodle 2.3.4, importas algunos cursos y los modificas ligeramente, adaptándolos a las nuevas necesidades. Y de repente, al borrar un elemento del curso (etiqueta, chat o cualquier recurso o actividad), nos devuelve el siguiente error:
Detectado un error de codificación, debe ser corregido por un programador: PHP catchable fatal error
Y no nos deja acceder al curso, ni ver nada de él. ¿Cómo lo arreglamos?.
Bueno, está la opción rápida que te saca del apuro: irte a la base de datos de Moodle y localizar la tabla _course. En ella vereis vuestros cursos. Localizais el que os da el error y editais el registro. Sólo tendreis que borrar el contenido del campo sectioncache y lo habreis arreglado.
La opción “para que no de más problemas” es irse al archivo lib/modinfolib.php y sobre la línea 1096, localizar el código


if ((!$this->visible or !$this->available) and
!has_capability('moodle/course:viewhiddenactivities', $modcontext, $userid)) {

$this->uservisible = false;

y sustituirlo por

if ($modcontext != "") {
if ((!$this->visible or !$this->available) and !has_capability('moodle/course:viewhiddenactivities', $modcontext, $userid))
{ $this->uservisible = false; }
}
else
{ $this->uservisible = false; }