En ocasiones cuando instalamos una instancia de Sql Server no podemos conectarnos con usuarios de SqlServer y solo es posible hacerlo con el usuario de windows. En estos casos el servidor nos arroja un mensaje como el siguiente:
“Error de inicio de sesión del usuario ‘
‘. (Proveedor de datos .Net SqlClient)”
para solucionarlo lo que debemos hacer es habilitar el modo de autenticación mixto, aca les dejo los pasos para realizarlo:
1. Abrimos SQL Server Management Studio Express o SQL Server Management Studio, dependiendo de su versión de SQL.
2. Ingrese la información solicitada:
1. Server Type: selecciones el motor de la Base de datos
2. Server Name: este campo debe ser completado con el nombre del servidor
3. Authentication: seleccione autenticación de Windows
3. Clic en “Conectar”
4. Clic derecho en el nombre del servidor de base de datos y luego en “Propiedades”.
5. Clic en “Seguridad”.
6. Sobre la solapa “Autenticación del Servidor” Seleccione SQL y Modo de Autenticación de Windows
7. Clic en OK.
8. Clic derecho sobre el nombre del servidor, y seleccione “Reiniciar”. Espere unos momentos para que se reinicie el servicio y los cambios surtan efecto.
Espero sea de utilidad para todos.
Tags: .net, autenticacion, error, inicio de sesion, mixto, sesion, sql, sql server, SqlServer, SqlServer Management Studio, usuario, windows
El servicio de Telnet no se encuentra Instalado por defecto en el Windows Server 2008, por tal razon es necesario instalarlo desde la linea de comandos.
Para instalarlo solo tenemos que ejecutar la siguiente linea:
servermanagercmd -install telnet-client
Y listo, ya podremos acceder al cliente de telnet desde el cmd de windows.
Si adicionalmente queremos saber que otras utilidades se pueden instalar, lo podemos hacer con el siguiente comando:
servermanagercmd -query
Tags: 2008, client, instalar, install, server, servermanagercmd, telnet, telnet client, windows, windows server 2008
En Apache es posible hacer que una unica instancia de la aplicación sirva, aloje, o responda por varios sitios web gracias a la directiva VirtualHost, en nginx es tambien posible hacer esto gracias a la directiva Server. En una entrada anterior, Instalación de nginx como servidor estático, les hable sobre el servidor estático nginx y como se instalaba, a continuación voy a mostrarles como configurarlo para que aloje varios sitios web a la vez de una manera ordenada al mejor estilo de apache.
Lo primero que debemos hacer es crear la carpeta donde almacenaramos los archivos de configuración para cada uno de nuestros sitios:
$ mkdir /etc/nginx/conf.d
creamos el archivo de configuración para nuestro primer sitio
$ vi /etc/nginx/conf.d/sitio1.conf
y lo editamos
server {
listen 192.168.1.1:80;
server_name www.dominio1.com;
access_log /var/log/dominio1/access.log main;
error_log /var/log/dominio1/error.log warn;
#SECCION PRINCIPAL
location / {
root /path/to/document/root/domain1;
index index.html index.htm;
}
error_page 404 /error.html;
}creamos el archivo de configuración para nuestro segundo2sitio
$ vi /etc/nginx/conf.d/sitio2.conf
y lo editamos
server {
listen 192.168.1.1:80;
server_name www.dominio2.com;
access_log /var/log/dominio2/access.log main;
error_log /var/log/dominio2/error.log warn;
#SECCION PRINCIPAL
location / {
root /path/to/document/root/domain2;
index index.html index.htm;
}
error_page 404 /error.html;
}En los archivos de configuración de los sitios la directiva Server es quien nos permite definir los diferentes sitios que queremos alojar en nginx, y el serverName es quien permitira distinguir a nginx a cual sitio el usuario quiere ingresar.
Ahora modificamos el archivo principal de configuración de nginx para indicarle donde debe buscar los archivos .conf que acabamos de crear, asi deberia verse el archivo principal
user nginxuser nginxgroup; worker_processes 4; worker_rlimit_nofile 10240; events { worker_connections 2048; } http { include mime.types; default_type application/octet-stream; server_name_in_redirect off; server_tokens off; include /etc/nginx/conf.d/*.conf; }
Ahora lo unico que necesitamos es crear un archivo index dentro de cada una de las carpetas de los dos sitios, reiniciar el servidor nginx y acceder por browser a nuestros dos sitios según lo definido en la directiva ServerName, si son sitios locales necesitaremos modificar nuestro archivos hosts
Tags: host, Http, nginx, server, ServerName, virtualhost, web, webserver
Cuando instalamos el webserver de apache en un servidor o maquina casi siempre le decimos con que modulos adicionales queremos que este sea instalado, pero hay casos en que se nos olvida uno que otro modulo y en ocasiones es necesario reinstalar apache, php y otras aplicaciones relacionadas, lo cual nos quita bastante tiempo y hasta puede dejar por fuera del aire los sitios que tengamos allí alojados.
Ayer, tuve que reinstalar un apache y uno de los sitios era muy importante para todo el equipo de desarrolladores, por tal razón instale y copnfigure de manera rápida apache (httpd-2.2.17) y php (php-5.2.14), con tan mala suerte que necesitaba algunos modulos adicionales que no especifique … lo primero que pense fue en recompilar el apache especificando los modulos y recompilar nuevamente php, pero por fortuna en la primer compilación le habia especificado a apache que en el futuro queria poder compilar modulos compartidos, esto se hace de la siguiente manera:
./configure –prefix=/path/to/apache/apache –enable-so
Ahora si a lo que vinimos, para compilar el modulo mod_foo es necesario tener los fuentes de apache y buscar el archivo mod_foo.c, la ruta puede ser
/path/to/source/httpd-2.2.17/modules/mappers/mod_foo.c
y gracias a apxs, herramienta para compilar e instalar modulos para apache que se encuentra en el directorio bin donde instalemos apache, podemos hacerlo mediante dos instrucciones sencillas.
En la primera le decimos a apxs que compile el modulo deseado
/path/to/apache/apache/bin/apxs -c mod_foo.c
si todo sale bien, en la misma carpeta encontraremos unos archivos como los siguientes
mod_foo.slo
mod_foo.o
mod_foo.lo
mod_foo.la
ya con estos archivos generados, y nuevamente gracias a apxs podremos instalar el modulo en php, asi
/path/to/apache/apache/bin/apxs -i -a -n fooname mod_foo.la
la opción -n nos permite definir el nombre con el cual quedara habilitado el modulo en el httpd.conf .
Solo nos resta revisar que todo este OK, revisamos que el archivo mod_foo.so este en la carpeta de los modulos de apache,
[root@myhost]# ls /local/aplicaciones/apache2.2.17/modules/
httpd.exp libphp5.so mod_foo.so
[root@myhost]#
y que la directiva de LoadModule exista en el httpd.conf
LoadModule fooname_module modules/mod_foo.so
y listo, despues de reiniciar el apache ya podemos hacer uso del modulo en nuestros sitios
Tags: --enable-so, apache, apxs, compilar, compile, dso, dynamic shared objects, modules, mod_foo.so, mod_proxy.so, mod_rewrite.so
En este momento como proyecto personal me encuentro pasando una aplicación a ZendFramework, todo funciona 1A en mi maquina virtual, pero en el momento de subirlo a mi proveedor de hosting compartido se presentaron varios inconvenientes, a continuación les cuento como logre solucionarlos para instalar la app.
La estructura de mi aplicación en mi maquina local era la siguiente:
/projectname
/application
/controllers
/views
/models
/public
/ZendFramework
y tenia definido en mi virtualHost de apache el ambiente en el cual me encontraba, y el include del framework de Zend asi:
php_value include_path /home/ubuntu/ZendFramework/ZF-1.10.8/library:/home/ubuntu/projectname
SetEnv APPLICATION_ENV “development”
Claramente y como muchos de ustedes deben saber, no es posible hacer esto en un hosting compartido, no tenemos acceso al virtualHost del apache, por tal razon tuve que crear una carpeta “library” , copiar el framework de zend dentro de ella y modificar el archivo index.php dentro de public para que me tomara la carpeta library en el include asi:
set_include_path(implode(PATH_SEPARATOR, array(
realpath(APPLICATION_PATH . ‘/../library’),
realpath(APPLICATION_PATH . ‘/modules/admin/models’),
get_include_path(),
)));
Perfecto, asi ya funciona la aplicación, nuestro DocumentRoot apunta a nuestra cuenta y no a la carpeta /public como lo hariamos en una maquina local, entonces tendremos que acceder a nuestra aplicación especificando /public en la URl, lo cual no es muy elegante:
http://projectname/public
para solucionar esto, creamos un archivo .htaccess con las siguientes reglas y lo ubicaremos en el DocumentRoot :
#Definimos el ambiente de la APP para aplicar la configuracion de el application.ini
SetEnv APPLICATION_ENV production
#Habilitamos el mod_rewrite
RewriteEngine On
#Ignoramos este archivo, no aplicamos ninguna regla
RewriteRule ^\.htaccess$ – [F]
#Si el URI no tiene nada es decir si accedemos a /, hacemos un rewrite a /public/index.php
RewriteCond %{REQUEST_URI} =”"
RewriteRule ^.*$ /public/index.php [NC,L]
#Si el URI no empieza con /public, le adicionamos /public y hacemos el rewrite, de esta manera no necesitamos escribirlo
RewriteCond %{REQUEST_URI} !^/public/.*$
RewriteRule ^(.*)$ /public/$1
#Si el archivo existe fisicamente en el servidor no hacemos nada
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^.*$ – [NC,L]
#Todo lo que venga /public/cualquiercosa lo redireccionamos al index.php para que el bootstrap haga su trabajo
RewriteRule ^public/.*$ /public/index.php [NC,L]
La estructura final es la siguiente:
/projectname
/application
/controllers
/views
/models
/public
/library
/ZendFramework
.htaccess
Y de esa manera queda completamente funcional nuestra aplicacion en un hosting compartido
Tags: app, application, godaddy, hosting, hosting compartido, htaccess, mod_rewrite, shared, shared hosting, web, webserver, ZendFramework