Drupal: Error 403 Forbidden cuando se instala un módulo

Al querer instalar o actualizar un módulo en Drupal 8 despues de ingresar la información del FTP aparece el error:

403 Forbidden
nginx/1.10.0 (Ubuntu)

El problema es que la URL no existe, si nos fijamos en la barra de direcciones veremos algo así:
http://sitio.com/core/authorize.php/core/authorize.php?batch=1&id=17&op=start

Si observan core/authorize.php se repite 2 veces, la solución es crear un Rewrite en la configuración de nuestro servidor web, en este caso estoy utilizando Nginx.

Editamos el archivo /etc/nginx/sites-enabled/default (o el de su sitio) y agregamos la siguiente línea

rewrite ^/core/authorize.php/core/authorize.php(.*)$ /core/authorize.php$1;

En mi caso quedo así (es una parte de la configuración):

server {
server_name example.com;
root /var/www/drupal;

client_max_body_size 20M;

location = /favicon.ico {
log_not_found off;
access_log off;
}

location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}

# Very rarely should these ever be accessed outside of your lan
location ~* \.(txt|log)$ {
allow 192.168.0.0/16;
deny all;
}

location ~ \..*/.*\.php$ {
return 403;
}

rewrite ^/core/authorize.php/core/authorize.php(.*)$ /core/authorize.php$1;

location ~ ^/sites/.*/private/ {
return 403;
}

# Allow “Well-Known URIs” as per RFC 5785
location ~* ^/.well-known/ {
allow all;
}

Reiniciamos el servidor web y listo:

/etc/init.d/nginx restart

Instalar extensión OpCache en XAMPP

La manera de instalar una extensión en PHP es editar el archivo PHP.ini y agregar extension=php_EXTENSION.dll o php_EXTENSION.so (sí no utilizas windows) pero al querer agregar la extensión de OpCache lo tradicional sería:

extension=php_opcache.dll

Pero el archivo de error.log arroja lo siguiente:

PHP Warning: PHP Startup: Invalid library (appears to be a Zend Extension, try loading using zend_extension=php_opcache.dll from php.ini) in Unknown on line 0

Aquí la solución es agregar la extensión pero de Zend, quedando así:

zend_extension=php_opcache.dll

Reinicias el servicio de Apache y listo!,

Gparted: Error al iniciar, undefined symbol

Al ejecutar el comando gparted o gparted-pkexec arroja el siguiente error (también el programa gnome-system-monitor):

/usr/sbin/gpartedbin: symbol lookup error: /usr/lib/x86_64-linux-gnu/libgiomm-2.4.so.1: undefined symbol: _ZN4Glib11VariantTypeD1Ev

Al parecer el problema lo genera VMWare, pero para solucionar el error, seguir los siguientes pasos, todo como root.

Mover el archivo LD_LIBRARY_PATH.conf

sudo mv /etc/ld.so.conf.d/LD_LIBRARY_PATH.conf /etc/ld.so.conf.d/LD_LIBRARY_PATH.conf.bak

Después ejecutar:
sudo ldconfig

Y listo!!, asunto arreglado.

Problema con VMware y Ubuntu 16.10 (GCC 6)

Despues de actualizar Ubuntu a la versión 16.10 Yakkety con el Kernel 4.4.0 y al iniciar VMware, me encuentro con un error de que no puede encontrar la librería GCC versión 5.3.1 ya que la actualización la cambio a GCC version 6.1.1 20160724 (Ubuntu 6.1.1-10ubuntu11)

vmware-gcc-problem

La solución es compilar los módulos de vmmon y vmnet con la última versión GCC y el nuevo Kernel.
Lo primero es descargar una versión del VMware Workstation Player 12.0 (esa es la que yo tengo actualmente) para descomprimir y compilar los módulos.

En esta página lo descargamos: https://my.vmware.com/en/web/vmware/free#desktop_end_user_computing/vmware_workstation_player/12_0

Después ejecutar los siguientes pasos (todo como Root)

chmod +x VMware-Player-12.1.1-3770994.x86_64.bin
./VMware-Player-12.1.1-3770994.x86_64.bin -x temp
tar xf ./temp/vmware-vmx/lib/modules/source/vmmon.tar
tar xf ./temp/vmware-vmx/lib/modules/source/vmnet.tar

Lo que hacemos con el -x temp, es descomprimir el .BIN, para despues, descomprimir los módulos vmmon y vmnet, lo siguiente es iniciar la compilación (asegurate de tener las librerias de compilación: sudo apt-get install build-essential linux-headers-generic )

cd vmmon-only
make
cd ..

cd vmnet-only
make
cd ..

Y por último copiamos lo compilado a la carpeta de módulos del Kernel actual

mkdir /lib/modules/`uname -r`/misc
cp vmmon.o /lib/modules/`uname -r`/misc/vmmon.ko
cp vmnet.o /lib/modules/`uname -r`/misc/vmnet.ko
depmod -a
/etc/init.d/vmware restart

vmware-restart

Y listo! ya debe de funcionar, ahora, si actualizamos el Kernel, debemos de seguir estos pasos, hasta que se tenga una solución automatizada.

Error 500 con Nginx+Chroot+PHP5-FPM+PhpMyadmin

Despues de hacer la instalación de Nginx y PHP5-FPM con Chroot (Jail) e instalar MySQL PhpMyAdmin la página me daba un error 500.

Investigando veo que el problema esta en la siguiente línea del archivo library/common.inc.php de PhpMyAdmin.

date_default_timezone_set(@date_default_timezone_get());

El problema está en que la función date_default_timezone_get() y todo se debe a que no se tienen los archivos necesarios para buscar la timezone del servidor, como lo muestra el log de nginx

[error] 12058#0: *13 FastCGI sent in stderr: “PHP message: PHP Fatal error: date_default_timezone_get(): Timezone database is corrupt – this should *never* happen! in /var/www/phpmyadmin/libraries/common.inc.php on line 276” while reading response header from upstream, client: 111.111.111.111, server: miservidor.com, request: “GET /phpmyadmin/ HTTP/1.1”, upstream: “fastcgi://127.0.0.1:9000”, host: “miservidor.com”

La solución es instalar la timezonedb con PHP-PEAR ( pecl ), procedemos con el siguiente código:

apt-get install php-pear php5-dev
pecl install timezonedb
echo ‘extension=timezonedb.so’> /etc/php5/mods-available/timezonedb.ini
ln -sf /etc/php5/mods-available/timezonedb.ini /etc/php5/fpm/conf.d/30-timezonedb.ini
service php5-fpm restart

Y listo!!.. ya debe de funcionar correctamente la página de PhpMyAdmin

Linux: Reactivar Control+ALT+Retroceso para reiniciar servidor X en Linux

Por si no sabias, puedes reiniciar tu servidor X presionando las teclas “Ctrl+Alt+Retroceso”, de que sirve, pues cuando esta trabado todo todo, al reiniciar el servidor X puedes casi siempre volver a la normalidad y volver a iniciar sesión.

Ahora, si por alguna razón no funciona esta combinación de teclas (en las ultimas versiones de Ubuntu por ejemplo, no sirve), aquí esta la forma de volver a activar esta opción.

En la terminal escribir:

sudo dpkg-reconfigure keyboard-configuration

Te van a aparecer muchas opciones, puedes ignorar todas.., excepto cuando llegue a la parte que te dice:

Por omisión la combinación Control+Alt+Retroceso no hace nada. Si lo desea, puede utilizarse para terminar el servidor X.

¿Desea utilizar Control+Alt+Retroceso para terminar el servidor X?

Despúes, activar la opción de SI, y listo!…, a probar el comando (todo lo que tengas abierto se cerrara en automático)

WordPress: Como actualizar wordpress y plugins sin necesidad de contar con FTP o SFTP

Si en tu servidor web donde tienes instalado worpress no cuentas con una conexión FTP o no la quieres agregar en la configuración de wordpress, pero al momento de quere actualizar cualquier plugin o versión de wordpress te solicita información de tu conexión FTP y te marca el error:

Ha sido imposible conectar con el servidor FTP localhost:21

Existe una solución para que todo este proceso lo haga directamente en los archivos de wordpress, solo se necesita agregar la siguiente linea en el archivo de configuración wp-config.php , lo pueden agregar hasta el final del archivo.

define(‘FS_METHOD’,’direct’);

Y listo!, cuando actualicen, ya no solicitará información de la conexión

rkhunter: Warnings y más warnings

Estoy escaneando en busca de troyanos y rootkit mi servidor Debian con la aplicación rkhunter, y en el log veo que tengo diferentes warnings en archivos del sistema como por ejemplo:

/usr/sbin/adduser [ Warning ]
/usr/bin/lwp-request [ Warning ]
/bin/which [ Warning ]

Y por ejemplo el adduser el warning indicaba que apuntaba a un archivo de perl , entonces para no ponerme paranoico investigue sobre lo sucedido y veo que falta agregar un parametro en el archivo de configuración de rkhunter: /etc/rkhunter.conf, como estoy utilizando debian (ubuntu) falta agregar esta línea:

PKGMGR=DPKG

Eso indica que las validaciones se harán con dpkg y entonces vualaa! ya no más warnings en estos archivos.

Sudo no funciona, error en el archivo sudoers

Al querer ingresar como root con el comando sudo me marca un error de que la sintaxis es incorrecta en el archivo sudoers, y probando con su root no deja entrar entonces, ¿como puedo tener acceso como root?

[email protected]:/home$ sudo su –
sudo: >>> /etc/sudoers: syntax error near line 22 < << sudo: parse error in /etc/sudoers near line 22 sudo: no valid sudoers sources found, quitting sudo: unable to initialize policy plugin

[email protected]:/home$ su –
Password:
su: Authentication failure

1.- Tener acceso fisico y arrancar el GRUB y montar la partición como un solo usuario y despues poder modificar el archivo sudoers, en mi caso no tengo acceso fisico ni forma de ver el GRUB remotamente.

2.- Utilizar este truco, con este comando: pkexec visudo y poner la clave de root

[email protected]:~$ pkexec visudo
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ===
Authentication is needed to run `/usr/sbin/visudo’ as the super user
Authenticating as: ubuntu-prueba,,, (usuario)
Password:

Y vualaaaa!, aparece el archivo de configuración, buscamos la línea 22 y vemos la error de sintaxis, lo arreglamos y listo 🙂

Postfix: temporary failure. Command output: /usr/bin/maildrop: Unable to create a dot-lock

De repente el servidor de correos que se configuro con ISPConfig 3, no enviaba correos cuando se trata de mails configurados con “reenvío de correo.” (Email forward)

Me daba el siguiente error en /var/log/mail.log

Feb 12 15:25:17 oviedo.mx postfix/pipe[30549]: DDE86158187: to=, relay=maildrop, delay=4356, delays=4356/0.05/0/0.1, dsn=4.3.0, status=deferred (temporary failure. Command output: /usr/bin/maildrop: Unable to create a dot-lock at /var/vmail/oviedo.mx/usuario/3055320.0.oviedo.mx. )

Ademas anteriormente me daba problemas con el puerto 10024, me decia que conexion rechazada:

Feb 10 16:13:28 oviedo.mx postfix/smtp[14558]: connect to 127.0.0.1[127.0.0.1]:10024: Connection refused

Entonces para solucionar el problema del puerto 10024, era desactivar el antivirus amavis, entonces en el archivo de configuración de postfix main.cf /etc/postfix/main.cf procedemos a comentar la línea donde aparezca algo así:

#content_filter = amavis:[127.0.0.1]:10024

Reiniciamos postfix /etc/init.d/postfix restart y tratamos de enviar un email de los configurados para forward y pues me sigue dando el error inicial del maildrop.

Investigando un poco me doy cuenta que al comentar la línea de content_filter del anti-virus amavis, tambien se debe de comentar la línea donde dice: receive_override_options entonces el archivo main.cf nos quedará de la siguiente manera:

#content_filter = amavis:[127.0.0.1]:10024
#receive_override_options = no_address_mappings

Y listo!, reiniciamos otra vez postfix y a probar. Por lo menos a mi me funciono así como les he dicho.