Probablemente se deba a que no estas definiendo en tu settings.py una pagina de error 404 o 503 o bien en el .htaccess y en caso de no haber definido ninguna se carga por defecto la página 404 de quijost.

Django estará lanzando alguna excepción de 404 o 503 y no encuentra el template o vista. Puedes ver más información en la documentación oficial de Django:
https://docs.djangoproject.com/en/1.3/topics/http/views/#the-404-page-not-found-view

Hola masajeet,

He separado el tema del inicial que posteaste ya cada problema debe tratarse separadamente.

En tu caso aunque has establecido inicialmente el LOGGING de django, estás teniendo un error antes de que pueda inicializarse.

Se declara un if de la variable settings que no ha sido previamente definida y ocasiona un error 500 del tipo:

mod_wsgi (pid=8873): Exception occurred processing WSGI script '/home/masajeet/public_html/django.wsgi'.
 Traceback (most recent call last):
   File "/home/masajeet/public_html/django.wsgi", line 24, in <module>
     if settings.SESSION_FILE_PATH:
 NameError: name 'settings' is not define
Puedes omitir esas lineas del settings o bien definirlas como:

import emotionaltraining.settings as settings

Hola Zant,

Las reglas mod_rewrite con expresiones regulares siempre han sido un poco complicadas. En principio nginx aunque cachee los resultados, lo hace primero consultando resultados previos en Apache o copia en cache generada. Antes de ello, debe pasar por el módulo mod_rewrite de apache a más bajo nivel. En nuestro modo de servidor compartido por lo tanto nginx sólo actúa como capa proxy y no como capa principal (ya que servimos con apache + nginx para dar posibilidad a otros módulos como mod_wsgi (para python), mod_passenger (para ruby), mod_php, etc).

Podemos ayudarte a resolver el problema proponiendote dos soluciones:

1) Habilitar de forma temporal en tu virtualhost la directiva RewriteLog de apache con un nivel apropiado que te permita entender mejor que es lo que esta sucediendo con las redirecciones.
Esta solución es la más apropiada, pero sólo puede activarse en el VirtualHost y no mediante .htaccess ya que es una directiva relativa al VirtualHost y necesita permisos root para editar la configuración de Apache. No la activamos ni la ofrecemos por defecto, porque requiere muchas escrituras adicionales de apache en cada petición y por lo general degrada el rendimiento.

Podríamos habilitarla durante algún tiempo para que puedas solucionar el problema o entender donde está fallando alguna regla de mod_rewrite. Una vez solucionado o si no es posible la desactivaríamos.

2) Aplicar un modo de depuración en las propias reglas de mod_rewrite desde el .htaccess.

Puede realizarse con reglas como:

RewriteCond %{QUERY_STRING} !vardump
RewriteRule (.*) http://www.midominio.com/$1?vardump&request=%{THE_REQUEST}&reqhost=%{HTTP_HOST} [R=301,L,QSA]
Esto te permite mediante FireBug o observando las cabeceras http visualizar que valores esta tomando la redirección. Es un método más laborioso, pero tiene la ventaja de poder usarse desde un simple .htaccess sin necesidad de permisos adicionales.

Cuando Moodle tiene un error interno o no puede realizar alguna operación lanza una excepción con el nombre "dmlwriteexception". Por lo general al hacer operaciones con archivos (borrado de archivos o creación), en respaldos o eliminación de usuarios.

Para obtener más información del error, ya que puede ser ocasionado por varias causas, es conveniente activar el modo depuración de Moodle.

Para ello deben seguirse los pasos detallado en http://docs.moodle.org/23/en/Debugging

Este error también puede darse por algún problema al realizar consultas MySQL (por alguna tabla o campo). Cuanto active el modo depuración se puede observar con más trazas y detalle el problema y diagnosticar alguna solución o incluso reportar el fallo a los desarrolladores de Moodle.

Otras soluciones si es referente al cambio de tablas de MyISAM a InnoDB es cambiar la directiva de configuración de mysql de:

BINLOG_FORMAT = STATEMENT
a:

BINLOG_FORMAT = MIXED

Sí, es posible actualizar/cambiar el plan. Cuando se dispone de una cuenta en quijost, el cliente puede actualizar a el plan que desee en cualquier momento desde su panel de clientes Quijost (por ejemplo de epremium a edeluxe). También puede contratar más alojamientos si lo desea. Nuestro sistema es muy escalable en ese aspecto para cubrir todas las necesidades del cliente.

Actualmente no soportamos sistemas windows, ni basados en ASP y .NET ya que no se basan en estándares y sistemas de software libre.

También en los últimos años su decadencia en servidores ha llevado a su retirada en muchos alojamientos ya que otros hosting con .Net que si lo ofrecen seguramente suelen ser más caros por tener que pagar licencias windows en servidores y esto ha llevado prácticamente a un uso marginal o extinto.

Recomendamos mejores herramientas y lenguajes de desarrollo como PHP, Python(Django) o Ruby que si están disponibles en nuestros servidores.

Por otro lado, para usuarios .Net resulta muy sencillo aprender PHP o lenguajes similares en su lugar. Prácticamente en unas horas puede realizar su web.

Tenemos también manuales y tutoriales en el foro que puede ayudar en la migración o aprendizaje. Además es posible escribir en el foro o correo de soporte para preguntar dudas o si se necesita ayuda.

El .htaccess básico que puede configurarse para Django tiene el siguiente aspecto:

SetHandler wsgi-script

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} !(django.wsgi)
RewriteRule ^(.*)$ django.wsgi/$1 [L]
Supongamos que se desea instalar un blog wordpress en public_html bajo el directorio "wordpress" y se desea escribir http://midominio.com/wordpress/

Para evitar que Django ejecute el directorio wordpress como una aplicación wsgi y produzca un error 500 se podría pensar en una solución del tipo:

SetHandler wsgi-script

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} !(django.wsgi|wordpress)
RewriteRule ^(.*)$ django.wsgi/$1 [L]
O quizás:

SetHandler wsgi-script

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} !(\/wordpress\/(.*))
RewriteCond %{REQUEST_URI} !(django.wsgi)
RewriteRule ^(.*)$ django.wsgi/$1 [L]

Sin embargo, esto no funcionará correctamente ya que se esta estableciendo el handler SetHandler wsgi-script para todos los archivos y directorios. Para corregir esto podemos probar:

<Files *.php>
SetHandler application/x-httpd-php
</Files>

<Files wordpress/*>
SetHandler application/x-httpd-php
</Files>

<Files />
SetHandler wsgi-script
</Files>

<Files *.wsgi>
SetHandler wsgi-script
</Files>

<Files django.wsgi>
SetHandler wsgi-script
</Files>

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} !(\/wordpress\/(.*))
RewriteCond %{REQUEST_URI} !(django.wsgi)
RewriteRule ^(.*)$ django.wsgi/$1 [L]

También es posible añadir si se desea evitar el index.php (en caso de estar presente)

RewriteCond %{REQUEST_URI} !(index.php)
Quedando como:

<Files *.php>
SetHandler application/x-httpd-php
</Files>

<Files wordpress/*>
SetHandler application/x-httpd-php
</Files>

<Files />
SetHandler wsgi-script
</Files>

<Files *.wsgi>
SetHandler wsgi-script
</Files>

<Files django.wsgi>
SetHandler wsgi-script
</Files>

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} !(\/wordpress\/(.*))
RewriteCond %{REQUEST_URI} !(django.wsgi)
RewriteRule ^(.*)$ django.wsgi/$1 [L]

De esta forma entrando a http://midominio.com/wordpress/ se cargará wordpress y entrando a http://midominio.com aparecerá Django o en cualquier url http://midominio.com/algo

Nota: es importante borrar la caché del navegador por completo, ya que de otra forma seguirá cargando el acceso previo y parecerá que no esta funcionando correctamente. Con Ctrl+F5 a veces no se borra todo, por lo que se recomienda en las opciones del navegador borrar la caché por completo si se ha accedido previamente.

A veces los clientes/usuarios de Quijost introducen sus credenciales incorrectamente para acceder a cPanel.

Cpanel dispone de una utilidad llamada "cphulkd" que bloquea una IP durante 24/48 horas cuando se realizan más de 3 intentos fallidos por seguridad (como los cajeros automáticos).

En los registros de cpanel aparecerá:
cpaneld: brute force attempt (user USUARIOFALLIDO) has locked out IP IPUSUARIO

Siempre podrá intentar el acceso de nuevo desde otro ordenador con diferente IP o si le es posible cambiando su IP.

Esta medida se toma para evitar accesos por fuerza bruta y evitar bots de autenticación.

Tenga en cuenta que su usuario cPanel siempre estará escrito en minúsculas y tendrá como máximo 8 caracteres.

Como caso excepcional, se pueden añadir IPs a una lista blanca de cPanel o eliminar el bloqueo de una IP ya bloqueada bajo petición privada al correo de soporte, pero se ruega al usuario que compruebe que su acceso y credenciales son correctos y espere al menos una vez el tiempo estipulado para desbloqueo.