Habilitar modo de autenticación mixto en Sql Server
enero 17, 2012 Publicado en Admin-tips, Configuración, InfraEstructura, Windows con 5 Comentarios
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
5 cosas que perjudican la Escalabilidad
septiembre 29, 2011 Publicado en Admin-tips, Escalabilidad, InfraEstructura con 23 Comentarios
Mapeadores de Objetos Relacionales (ORM)
Los ORM permiten a los desarrolladores ser más productivos, evitando las dificultades de la interacción con la Base de Datos, y permitiendoles concentrarse en las funcionalidades y las caracteristicas de las aplicaciones.
Desde el lado de Rendimiento la imagen es bien diferente, al permitir que un ORM sea quien construya las consultas que se ejecutan, tendremos consultas bien complejas que la Base de Datos no podra optimizar de la mejor manera.
Procesos sincronos, seriales, acoplados o bloqueantes
Se deben evitar al maximo posible los procesos que generan bloqueos a nivel de Base de Datos, si definitivamente lo necesitamos lo mejor es usar tablas de tipo InnoDB, las cuales generan bloqueos a nivel de registro, y no bloqueos a nivel de tabla como trabaja MyIsam.
Evite procesos sincronos o semi-sincronos, los cuales esperan la respuesta de otro servicio para continuar y detienen la ejecución de codigo. En una aplicacion altamente transaccional estas esperas pueden resultar en miles de sesiones simultaneas o concurrentes.
Unica copia de la Base de Datos
Sin replicación, dependemos de una unica Base de Datos. Con esta configuración limitamos a nuestros WebServers a usar una unica Base de Datos, lo cual obviamente resultara en un cuello de Botella para nuestra aplicación.
Lo mejor es tener varias Bases de Datos, y dar la opcion a nuestros WebServers de utilizar la que ellos consideren adecuada, o mejor la que nuestro algoritmo dictamina debemos usar.
No tener Metricas
Sin metricas no podremos tener un panorama de lo que sucede en nuestra infraestructura cada vez que tenemos una nueva funcionalidad al aire, o cuando estamos teniendo problemas en nuestra aplicacion, sin este tipo de informacion nuestro equipo de Ingenieros no podran estar sensibilizados sobre lo que esto supone y sera mas dificil que trabajemos en pos de mejorar.
Existen muchas soluciones que trabajan con SNMP y que no son invasivas, para citar algunas Cacti, Munin, OpenNMS, Ganglia y Zabbix.
Las metricas deben incluir metricas de negocio como Cantidad de usuarios registrados, Numero de comentarios por hora, Numero de articulos vendidos; asi como las metricas tecnicas de infraestructura como Espacio en disco, Memoria disponible, Numero de procesos ejecutandose, consultas por segundo.
Banderas de funcionalidades
En las aplicaciones que son construidas sin banderas de funcionalidades es mucho mas dificil degradar correctamente.
Cuando un sitio esta teniendo un pico de trafico o de request y no es posible escalar o expander la capacidad, las banderas permitiran bajar funcionalidades mientras la carga baja en los servidores sin tener que bajar el sitio por completo. Esto le dara tiempo para poder realizar los ajustes necesarios.
Sin estas recomendaciones limitara la Escalabilidad y la Disponibilidad de las aplicaciones.
Tags: bases de datos, bloqueo, disponibilidad, escalabilidad, metricas, MySql, ORM, procesos, sincrono
Nginx Virtual Hosts – Multiples sitios
diciembre 2, 2010 Publicado en Configuración, Escalabilidad, InfraEstructura con 2 Comentarios
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
Como extraer un paquete RPM sin instalarlo (rpm extract command)
noviembre 23, 2010 Publicado en Admin-tips, InfraEstructura con Comentarios desactivados
No existe una opción directa en el comando rpm para extraer los archivos contenidos en un RPM, pero existe una utilidad disponible llamada rpm2cpio. Esta utilidad extrae el archivo cpio de un paquete RPM, el cual es una secuencia de archivos y directorios en un unico archivo, es similar a un archivo .tar.
rpm2cpio convierte un archivo .rpm en un unico argumento para un archivo cpio en la salida estandar. Si un argumento “-” es definido, se tomara el rpm de la entrada estandar. La sintaxis es la siguiente:
rpm2cpio myrpmfile.rpm
rpm2cpio – < myrpmfile.rpm
rpm2cpio myrpmfile.rpm | cpio -idmv
Ejemplos – Extrayendo archivos de un RPM
Descargue un archivo RPM:
$ mkdir test
$ cd test
$ wget http://www.somehost.com/files/lighttpd/rhel4-php5-fastcgi/php-5.1.4-1.esp1.x86_64.rpm
Extraiga los archivos usando el comando rpm2cpio y el comando cpio:
$ rpm2cpio php-5.1.4-1.esp1.x86_64.rpm | cpio -idmv
Salida:
/etc/httpd/conf.d/php.conf
./etc/php.d
./etc/php.ini
./usr/bin/php
./usr/bin/php-cgi
./usr/lib64/httpd/modules/libphp5.so
./usr/lib64/php
./usr/lib64/php/modules
….
…..
..
./var/lib/php/session
./var/www/icons/php.gif
19188 blocks
Opciones del comando cpio:
-i: Restaura el archivo
-d: Crea los directorios destino si es necesario
-m: Mantiene las fechas de modificación de los archivos
-v: muestra el progreso del comando
Verifique que ha extraido el archivo RPM en el directorio actual:
$ ls
Output:
etc php-5.1.4-1.esp1.x86_64.rpm usr var
Esto es muy util cuando se quieren extraer archivos de configuración o otro archivo contenido por RPM sin instalar todo el paquete
Tags: cpio, extract, extraer, rpm, rpm command, rpm2cpio
Compilación modulos compartidos apache – Dynamic Shared Object (DSO)
noviembre 19, 2010 Publicado en Admin-tips, Configuración, InfraEstructura con 1 Comentario
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
