Montar un servidor de correo con Postfix

Lo primero que tenemos que hacer es descargar el paquete postfix.
apt-get install postfix


Como siempre esta es la forma de descargarlo en debian, Que es la distribución que uso habitualmente.
Después de que apt descargue el paquete comenzara a instalarlo y salda una pantalla azul (no os preocupeis...no son como las de Microsoft) y os preguntara como configurarlo, elegís internet site.


Después una serie de preguntas como el nombre del servidor postfix y cosas así que podremos dejar todo según esta, y que si queremos cambiar algo lo podremos hacer en el archivo de configuracion.
Y justo es hay don de vamos a ir ahora, al archivo de configuracion que se encuentra en /etc/postfix/main.cf
Aquí como casi todos los archivos de configuracion, tienen muchas cosas aunque las importantes sean 3, para una configuracion básica como es este caso (ya iré preparando configuraciones avanzadas de los servicios que hemos ido instalando)
pues bueno una de las primeras cosas es fijarnos en la linea donde ponga, relayhost, y a de estar vacía.
relayhost =

Otra parte importante es mynetworks que van a ser las redes o host que podrán usar nuestro servidor postfix, generalmente quien lo use sera el servidor, aquí se marcara quienes podrán usarlo, que lo configuremos para nuestra maquina o nuestra red, no evitara que los correos no vayan a salir a internet, una configuracion típica seria la siguiente.
mynetworks = 127.0.0.0/8, 192.168.1.0/24

El main.cf asi podria funcionar bien. aqui os pongo una imagen de el aspecto aproximado del archivo.


Si ahora queremos que postfix nos envié a nuestro correo personal lo que va sucediendo en nuestro servidor tendríamos que tocar el archivo aliases que se encuentra en /etc/aliases, así que con un nano /etc/aliases y tiene una pinta mas o menos así:


Hay vemos que todos los servicios envían sus alertas a root y todo lo que va a root va a tu correo (puede ser un correo gmail, hotmail, o de tu propio dominio, vamos a cualquier correo electrónico que quieras), Algo que también es importante es que después de poner tu emal a root y guardar el archivo ejecutes el comando newaliases , con esto se refrescara y nuestro postfix nos enviara las alertas, esto es importante ya que si no ejecutas el comando aunque hayas guardados los cambios, nuestro servidor de correo(postfix en este caso) no nos enviara los emails.
Luego podemos probar si esto funciono enviando un email a cualquier usuario con el comando mail seguido de un nombre de usuario( mail usuario) y si lo que habéis puesto es una dirección de email os llegara el correo a vuestro email( mirar en spam por que a mi en gmal me los enviaba a spam y tuve que crear una regla para que dejara de hacerlo) y si lo que habeis puesto en root es root pues estando en el usuario root escribís mail y os dira si hay mails para el usuario root o no (comprobe que en algunos casos para que el comando mail funcione hay que instalar el paquete mailx, apt-get install mailx )

Y con esto tendríamos una configuracion básica de posfix y haríamos que nuestro sistema nos enviara las alertas a nuestro email, Espero que os haya gustado.
Un saludo

MONTAR UN SERVIDOR PROXY CON SQUID

Software necesario:
1- squid
2- apache (no es necesario obligatoriamente pero acelerara la cache y trae un paquete que necesitaremos para encriptar las contraseñas de los usuarios en caso de que queramos que el proxy sea con autentificacion de usuarios)

Lo 1º tenemos que descargar el squid si quedemos compilarlo a mano lo descargaríamos de www.squid-cache.org aunque en muchas de las distribuciones ya esta en los repositorios, Yo como uso Debian usare apt y es tan sencillo como apt-get install squid3 y lo mismo con apache2.
Después tenemos que ir al archivo de configuracion de squid ( /etc/squid/squid.conf ) y editarlo cambiando unos parámetros que a continuación pondré.

Puerto de escucha
El primero es buscar la linea " # Squid normally listens to port 3128 " esta dentro de la sección NETWORK OPTIONS, (Este archivo parece un autentico caos por la cantidad de lineas que tiene pero luego no lo es tanto y no hay que cambiar tantas cosas...yo diría que el 90% del archivo son esplicaciones.)
Bueno buscamos esa linea (si usáis nano se busca con ctrl+W ) y justo debajo añadís (sin la almoadilla que eso es para comentarios)

http_port 3128
http_port 8080




memoria cache y cache en disco

Que sera el puerto por el que escuchara squid.
Luego buscamos la parte donde pone " cache_mem " y lo desmarcamos de comentario y lo dejamos así:

cache_mem 32 MB


Después buscamos esta linea: " cache_dir ufs /var/spool/squid 100 16 256 "


Donde aquí podríamos cambiar el 100 que puse en negrita que es cuantos megas de disco vamos a dejar para que guarde las paginas en la cache y se pueda acceder a ellas mas rápido, Yo creo que con el volumen de discos que manejamos hoy en dia se pueden dejar sin problemas 500 que aun así 500 megas para almacenar paginas no creo que este mal, pero eso ya es al gusto del consumidor, necesidades de la red y demás.

lista de control de acceso

Luego nos encontramos la parte de control de accesos, Aquí tenemos que saber sobre que red vamos a trabajar, 192.168.1.0 o 192.168.2.0 y la mascara de subred que salvo casos excepcionales, En ambientes de hogar claro ya que una gran empresa dudo que consulte este blog para montar su proxy, pues salvo esos casos suele ser 255.255.255.0.
Lo que tendríamos que cambiar aquí en principio seria poner esta linea " acl miredlocal src 192.168.1.0/255.255.255.0 " pero digo en principio porque luego veremos que depende como lo hagamos esta linea puede ser muy importante, y apartir de ahora los acl donde pongamos miredlocal se refreirá a 192.168.1.0/255.255.255.0, También podemos crear una lista de maquinas que queramos que accedan al proxy con lo siguiente " acl permitidos src "/etc/squid/permitidos" " y en /etc/squid/permitidos una lista con las ips internas que queramos que accedan, la sintaxis seria la siguiente:

acl (nombre) src (red o dir archivo)

un ejemplos:

acl miredlocal src 192.168.1.0/255.255.255.0
acl miredlocal src 192.168.1.0/255.255.255.0 192.168.2.0/255.255.255.0
acl permitidos src "/etc/squid/permitidos

Lo anterior es una lista de control de acceso, lo siguiente que vamos a ver son las reglas de control de acceso

Tenemos que buscar el texto " INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS "
La sintaxis seria " http_access (deny o allow) (lista) " y usando el archivo anterior podíamos crear la siguiente regla:

http_access allow permitidos

Pero esta parte tiene mucho juego ya que en una misma regla podemos poner varias listas y dejar acceso a unas y otra denegarlas, poniendo ! delante de la lista la deniegas el acceso, un ejemplo en el que la lista1 va a tener acceso y la lista2 no:

http_access allow lista1 !lista2

Aquí investigando mas en profundidad podemos hacer mucho, restringir dominios, Que no se descarguen ficheros con mp3,avi.., por contenidos, Cuando investigue mas en profundidad las reglas igual hago un post sobre ello. pero vamos que es una de las partes donde mas se puede hacer.
Y las lineas de esta parte tendrían que quedar mas o menos así con una configuracion simple, Por debajo de " # Recommended minimum configuration " :

Así podría ser la configuracion de la lista de control de acceso

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl miredlocal src 192.168.1.0/255.255.255.0



y así la de las reglas de control de acceso

http_access allow localhost
http_access allow miredlocal
http_access deny all

Como dije esto es una configuracion simple para que funcione el squid

Podemos poner también los mensajes de error en español si lo deseamos con eliminar el directorio actual " rm -f /etc/squid/errors " y cambiar el enlace simbólico " ln -s /usr/share/squid/errors/Spanish /etc/squid/errors "

AUTENTIFICACION DE USUARIOS

Ahora vamos con otra parte importante que es el acceso con autentificacion, Hay 2 formas con LDAP y con módulo NCSA,que es una forma de atentificacion por un texto simple que ademas ya viene incluido en squid,obviamente es mas seguro por LDAP pero es esta segunda la que yo voy a utilizar yo, la de por modulo NCSA.

Bueno este método es muy sencillo de usar, Solo tenemos que crear un fichero que el usuario squid pueda leer (en esto mirar bien si el usuario que arranca es squid o proxy que a mi me dio algún problemilla esto) para crear el archivo nada mas que:

touch /etc/squid/usuarios

y despues solo hacer que tenga squid (o proxy) los permisos y que sea el propietario

chmod 600 /etc/squid/usuarios
chown squid:squid /etc/squid/usuarios

Después solo tenemos que usar el comando htpasswd que dicho paquete viene incluido en apache, Un ejemplo:

htpasswd /etc/squid/usuarios david

Después no pide la contraseña para el usuario y se guarda cifrada en /etc/squid/usuarios.
Después buscar la linea " auth_param basic program " y añadirle" /usr/lib/squid/ncsa_auth /etc/squid/usuarios " y desmarcarla como comentario, vamos que tiene que quedar así:

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/claves

Con esto le decimos donde esta el archivo de los usuarios y las contraseñas.

Y en la lista de control de accesos que vimos antes añadir esta linea:

acl password proxy_auth REQUIRED
y la parte lista de control de accesos anterior quedaria asi:

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl miredlocal src 192.168.1.0/255.255.255.0
acl password proxy_auth REQUIRED

Ya solo queda añadir la palabra password donde definimos las reglas y que quede así:

http_access allow localhost
http_access allow miredlocal password
http_access deny all


Y con esto quedaría squid listo, sin olvidarnos de parar y arrancar el servicio para que coja la configuracion claro, el comando es fácil:

/etc/init.d/squid stop
/etc/init.d/squid start
o
/etc/init.d/squid restar para reiniciarlo

Ahora vamos a tocar un poco la parte física y como debe ir la red.

Bien vamos a tener un router, 2 ordenadores, uno sera el servidor y otro el cliente, clientes podemos tener mas de uno pero entonces necesitariamos también un switch, pero para este caso sera solo un cliente, aunque para mas no habrá mas que hacer lo mismo en los demas clientes.

bien el router sera un router normalito, esto en principio no tiene misterio.
El servidor va a tener que tener 2 targetas de red, una para conectarla al router y otra para que el cliente se conecte a el (en el caso de varios clientes, en esta segunda targeta iria conectado el switch y a el los clientes)
y el cliente pues un ordenador normal, sin nada especial.

Las tarjetas del servidor han de estar en redes diferentes la 1º en la red del router, por ejemplo la 192.168.1.x y la segunda en otra red, por ejemplo la 192.168.2.x y el equipo ha de estar en la red de la segunda tarjetas (192.168.2.x) para que así ningún equipo de la red pueda ver el router y todos tengan que pasar por el servidor proxy y autentificarse para poder salir a internet, ni que decir que las ips fijas, y claro las " acl miredlocal src 192.168.1.0/255.255.255.0 "de la lista de control de accesos (y de las reglas y de cualquier sitio donde vaya la dirección de nuestra red) han de cambiar a la red 192.168.2.x

No os olvidéis tampoco de añadir estas lineas en los ficheros /etc/bash.bashrc y /etc/environment para poder acceder por el proxy a Internet desde concosa, Sin esto apt,wget y demás aplicaciones de consola que acceden a internet no podrán acceder.

export http_proxy="http://usuario:password@proxy:puerto"
export https_proxy="http://usuario:password@proxy:puerto"
export ftp_proxy="http://usuario:password@proxy:puerto"


Y bueno, con esto creo que el post (que este fue un poco mas largo) queda terminado,cualquier duda, sugerencia o lo que sea...ya sabéis, ponerlo en los comentarios o mandarme un email y os responderé con mucho gusto.
Un saludo

Instalar Flash para Firefox en Debian

Bueno esta no sera una entrada muy larga ni estrictamente de administración de servidores pero también creo que puede ser util para mucha gente y en esta vida no todo son servidores, no? bueno vamos con ello.

1º añadimos esta linea: deb http://www.backports.org/debian lenny-backports main contrib non-free a /etc/apt/sources.list
con esto añadimos los repositorios backports , que son unos repositorios de Debian también pero con paquetes de de otras versiones como testing o unstable, no te da la estabilidad que te da Debian estable pero te da paquetes que puedes necesitar como en este caso el flashplugin que en este caso mas que por inestable esta aquí por no ser libre (como sucede con java si no mal no recuerdo)

después hacemos update (apt-get update) pero nos dará error con de puclic key ( o firmas o llaves publicas si se tiene el sistema en español) así que ejecutamos lo siguiente:
wget -O - http://backports.org/debian/archive.key | apt-key add - (también esta el paquete debian-backports-keyring aunque este no lo probé ya que lo vi después)
para que nos descargue las claves publicas y con esto ya podremos hacer update sin que nos de errores

después se instala flashplugin-nonfree ( apt-get install flashplugin-nonfree ) en caso de problemas o que no lo vea intentamos forzarle a que lo busque en los repositorios backports con lo siguiente: apt-get -t lenny-backports install flashplugin-nonfree y con esto ya tendremos el flash en nuestro navegador de Debian (Iceweasel) que aun no tengo muy claro porque Debian tiene esa manía de cambiar el nombre a las cosas, bueno serán cosas de su política de libertad extrema, pero ese es otro tema que tratare otro dia.

Conexiones remotas con SSH

SSH (Secure SHell) es un programa, Bueno en realidad es un protocolo ya que programas hay varios para acceder o montar un servidor (cliente/servidor).
En muchas(la mayoria creo yo) de las distribuciones linux viene el cliente por defecto ya instalado,
El servidor es tan fácil como ejecutar el siguiente comando:
apt-get install ssh
ssh podría decirse que es como telnet, Pero la diferencia mas importante es que ssh encripta los datos, Por lo que es mucho mas seguro conectarse remotamente a una maquina por ssh que por telnet.
La sintaxis es la siguiente:

ssh usuario@nombre_de_maquina_o_ip

Ejemplos:
ssh pepe@debian.org
ssh pepe@150.223.50.189

Después de esto nos pedirá la contraseña como muestro en la imagen de abajo.


Y con eso ya estaríamos conectados a la maquina remotamente, pero...Ya esta? Solo eso permite ssh? Pues no, ssh aunque se puede usar de esa manera tan simple tiene mas funciones.
Imaginemos que solo queremos ver la ocupación de otro equipo, Solo queremos ver como están los discos pero no necesitamos entrar a el ejecutariamos:

ssh usuario@maquina comando
Ejemplo:

ssh pruebas@127.0.0.1 df -h
Te pediría la contraseña y sacaría esto:

Esa ip es tu propia maquina (localhost) siempre pero con cualquier ip funcionaria igual (y que exista el usuario y sepas la password claro)
Esto funcionaria con cualquier comando.

Otra cosa muy util es scp que permite copiar archivos o directorios de un equipo a otro con el protocolo ssh, Osea que los archivos viajan encriptados y seguros, vamos a ver la sintaxis:

scp [-r] origen destino
El -r es opcional significa recursive, Osea que copia el directorio y todos los directorios que estén dentro de el, Si solo queremos un archivo no nos hace falta el -r.
Ejemplo:
Si queremos copiar de nuestra maquina a otra remota seria
scp hhhh pruebas@127.0.0.1:/home/pruebas


Si lo que queremos es copiar un archivo de la otra maquina a nuestro equipo seria así:
scp pruebas@127.0.0.1:/home/pruebas/gggg /home/


Tambien tenemos el comando sftp que es un ftp seguro, Por que no olvidemos que ftp no encripta los datos

Asta aqui algunas cosas del cliente ssh, En otra ocasión nos meteremos a configurar el servidor ssh.

INSTALACION Parte 1 (particiones)

Se recomienda instalar un servidor en ingles ya que las traducciones suelen ser bastante malas. ( el idioma del sistema NO condiciona el idioma del usuario )

PARTICIONADO

• estas son las particiones recomendadas en particiones independientes, con independientes me refiero a otro disco duro a ser posible, yo en mi caso como el servidor va a estar en mi casa y no voy a darle una carga excesiva, decido rebajar costes y trabajar con particiones y algún que otro disco duro de mas pero no los que se deberían en un entorno profesional que hay si han de ser siempre discos duros independientes, si no no tendría sentido, Si tu sistema esta en el mismo disco duro que /var y casca ese disco y en /var tienes los log y muchos datos importantes los perderéis, Lo mismo pasa con /home en un servidor de ficheros, Cualquier directorio que creáis importante para el servidor deberá ser montado independientemente.
  

/swap

/tmp

/boot

/home

/var

En un servidor montado en RAID o LVM /boot tiene que estar montado independientemente del raíz(en este caso tiene que ser otra partición y no otro disco duro), por que en /boot se guardan los archivos de arranque y el kernel, y es el kernel quien en un sistema RAID o LVM a de montar los discos duros y demás hardware.

En un servidor también es recomendable que /var este fuera del sistema raíz por ser una partición con varios logs.

En servidor de ficheros es recomendable montar independientemente /home por que es donde los usuarios dejaran los ficheros y en caso de colapso de /home si no están en discos diferentes nos colapsaria todo el sistema, el mismo motivo por el que se recomienda extraer de raíz el /tmp

• estas son los directorios que nunca pueden ser montadas fuera de raíz, Aquí también se almacenan datos importantes, pero la mayor parte del contenido de estos directorios se pueden sacar del cd de instalación, No pasa lo mismo con los archivos contenidos en /var o /home
  

/dev

/etc

/bin

/sbin

/lib

son directorios que han de estar siempre en el raíz por contener archivos necesarios para el arranque