Tronk.Net … Tu portal útil

Servidor

Para comenzar, debemos tener una partición a la que queremos asignar cuotas, es este mini how-to usare de ejemplo la partición de mi sistema /mnt/Server (/dev/hde1).
Primero añadimos al "fstab" (/etc/fstab) los valores "usrquota" y "grpquota" de modo que:
/dev/hde1 /mnt/Server ext3 acl,user_xattr 0 0
Quedaría así:
/dev/hde1 /mnt/Server ext3 acl,user_xattr,usrquota,grpquota 0 0

Como deberíamos de saber, si no lo sabéis, os lo recuerdo, para que los cambios en el fstab tengan efecto, se ha de remontar la partición, como en nuestro caso es /mnt/Server no hara falta, pero si fuese /home nos dira que esta usada. Uso SuSE 9.1 Profesional y en caso de que estuviésemos con /home deberíamos hacer lo siguiente:

Primero cerramos sesión de KDE u otro entorno grafico y quede en la pantalla de login, escribimos "root" y debajo ponemos la contraseña, en el menú desplegable de "tipo de sesión" escogemos "A prueba de fallos".
Bien, estamos logeados como root y no estamos usando /home, pos procedamos a remontar la unidad. Yo use:
# mount -o remount /mnt/Server –> Cambiad /mnt/Server aplicado a vuestro caso.

Una vez remontado, podemos volver a iniciar sesión por ejemplo.

Para que el sistemas de quota funcione, hay que crear 4 archivos en el directorio raíz de la partición. En mi caso hde1 est montado en /mnt/Server, por lo tanto el directorio raiz es /mnt/Server. Los archivos a crear son los siguientes:
–> aquota.user aquota.group quota.user quota.group
Para crearlos, iremos al directorio raiz de nuestra partición:
# cd /mnt/Server
# touch aquota.user aquota.group

Para añadir seguridad a esto, cambiaremos los permisos de dichos archivos, de modo que root pueda leer y escribir, y denegado a los demás usuarios.
# chmod 600 aquota.user aquota.group

Weno, arrancamos el servicio "quota"
# rcquota start –> Cambiando "start" por "stop" y "restart" podemos parra o reiniciar el servicio.

Ahora hay que comprobar que sistemas tienen la quota activada y el uso que se le esta dando con el comando:
# quotacheck -avug
En el comando anterior, si da error de que no se ha encontrado el archivo para configurar la cuota, si estamos configurando la cuota en "/" lo ignoramos porque ahí solo escribe root y daria igual. En caso de que sea "/home" y de el error mencionado antes, cerramos todas las aplicaciones que estén corriendo y dejamos abierta una consola y tipeamos:
# telinit 1
Esto nos llevara a el modo monousuario, solo como root, nos pedirá la contraseña de este, la introducimos. Ahora ejecutamos:
# quotacheck -avug –> Si el error persigue:
# quotacheck -avugf –> Y ahora una comprobación forzada, pero tranquilos que a mis datos no les paso nada. A mi entender puede estropear los archivos "aquota.user" y "aquota.group" (Lo dejo bajo la responsabilidad de cada uno)
Esto debiera dar una salida como esta:
quotacheck: Scanning /dev/hde1 [/mnt/Server] done
quotacheck: Checked 69 directories and 381 files

Ahora debemos activar las cuotas para /mnt/Server
# quotaon /mnt/Server –> Esto activara las cuotas
# quotaoff /mnt/Server –> Esto desactivara las cuotas

Ahora llega la parte mas difícil del tema, configurar cuotas. El usuario que voy a limitar va a ser "guest". Al tipear el comando de abajo, nos abrirá el editor de texto "vi", para evitar eso, podemos hacer:
# export EDITOR=/usr/bin/mcedit –> Si no usais ni "Vi" ni "mcedit" cambiáis la ruta.

1. CUOTA DE USUARIOS:

A continuación:
# edquota -u guest
Acto seguido se nos abrera mcedit. Lo mas apropiado creo que será poner un ejemplo:

Disk quotas for user guest (uid 1003):
Filesystem blocks soft hard inodes soft hard
/dev/hde1 0 5120 6144 0 0 0

Suponiendo que se quiere asignar una cuota de disco de 5 MB con una tolerancia de hasta 6 MB. Las unidades se escriben en KiloBytes. "soft" es el limite de advertencia, "hard" el limite máximo, "blocks" es el espacio usado en KiloBytes e "inodes" es el numero de archivos. 0 significa ilimitado.
Cuando superemos el limite de advertencia (soft) de 5 MB nos dará este error:
–> hde1: warning, user block quota exceeded

Cuando estemos sobrepasando el limite (hard) de 6 MB, obtendremos esta salida:
–> cp: escribiendo «SSH10242345678.bmp»: Se ha excedido la cuota de disco
En este caso se crara un archivo con ese nombre, pero de 0 Bytes.

PD: Si no se te aplican los cambios, revisa que has guardado el archivo de configuracion que se abrio con mcedit y prueba a hacer:
# quotaoff /mnt/Server
# quotaon /mnt/Server

Con esto, ya tenemos las cuotas activadas para un usuario, para un grupo:

CUOTA DE GRUPOS:

Seguiremos el procedimiento anterior, si ya lo tenemos hecho no hará falta repetirlo.
Para los grupos usaremos:
# edquota -g shell –> Cambiando "shell" por el grupo correspondiente en tu sistema.

Un ejemplo:

Disk quotas for group shell (gid 1001):
Filesystem blocks soft hard inodes soft
/dev/hda1 0 1 1 0 0
/dev/hde2 0 1 1 0 0
/dev/hde1 0 1 1 0 0
/dev/hdg1 188 102400 204800 37 0

Bien, el grupo "shell" no tiene permiso de escritura nada mas que en su home, que "hdg1" esta montado en (/home). Por defecto, las otras particiones tendrán un "0", osea, ilimitado. Por precaución yo establecí un KiloByte. No tiene mayor misterio, se configura al igual que en los usuarios.

Con esto doy por terminado el How-To.

Elaborado por GuraDXPU del canal #SuSE del IRC-Hispano bajo SuSE 9.1 Professional Kernel 2.6.8. Siempre que se modifique pediría por favor que se me comunicase por el bien de todos.

by mladmin
Bueno, pues en Mandrake Linux, a partir de la versión 8.x viene de serie su propio sistema de actualización del sistema, urpmi.

Con este artículo lo que pretendo es más o menos explicar cómo pasar de una versión anterior de Mandrake a la última versión 9.2, esto es extrapolable a cualquier versión de Mandrake realizando unas pequeñas modificaciones en las direcciones de los medios.
Pues manos a la obra. Lo suyo es empezar por eliminar cualquier medio que existiera anteriormente, esto es lo recomendable, aunque también se pueden mantener algunos medios y luego seleccionar los que se desea para actualizar el sistema. Para eliminar todos los medios ejecutamos como root:

urpmi.removemedia -a

Y ahora tocaría ir añadiendo los medios que corresponden a la versión en cuestión, en nuestro caso, Mandrake 9.2. Se puede hacer de dos formas, o bien añadimos los medios mediante urls HTTP o FTP, o bien nos descargamos las ISOs de la distribución y las usamos como fuente. Lo suyo es usar las URLs, así se puede añadir también los medios de contrib y el nuevo jpackage (multitud de paquetes relacionados con Java).

Se puede utilizar el Easy Urpmi, para generar todos los medios disponibles a partir de varios mirrors FTP o HTTP, pero yo prefiero seleccionar un mirror FTP cercano y buscar las urls a manita, cuestión de manías y costumbres, porque ya lo hacía así desde antes que existiera el Easy Urpmi.

Primero toca añadir el medio principal de Mandrake 9.2:

urpmi.addmedia mdk92.main ftp://ftp.rediris.es/mirror/mandrake/9.2/i586/Mandrake/RPMS with ../base/hdlist.cz

Ahora el respectivo del contrib que tiene los paquetes que no se incluyeron en la distribución de 3 CDs de la Download Edition principalmente por motivos de espacio.

urpmi.addmedia mdk92.contrib ftp://ftp.rediris.es/mirror/mandrake/9.2/contrib/i586 with ../../i586/Mandrake/base/hdlist2.cz

Y por último el contrib jpackage, si es que nos interesa.

urpmi.addmedia mdk92.jpackage ftp://ftp.rediris.es/mirror/mandrake/9.2/contrib/jpackage/i586 with ./hdlist.cz

Una cosa a tener en cuenta, es que podemos usar los synthesis.hdlist*.cz, que suelen ocupar bastante menos, porque lleva menos información sobre los paquetes (descripciones y demás cosas irrelevantes).

En el caso de que se haya optado por usar las ISOs, se puede montar en modo loop y añadirlas como si fueran repositorios locales:

mkdir /mnt/mdk1 /mnt/mdk2 /mnt/mdk3
mount -o loop -t iso9660 Mandrake-9.2-CD1.i586.iso /mnt/mdk1
mount -o loop -t iso9660 Mandrake-9.2-CD2.i586.iso /mnt/mdk2
mount -o loop -t iso9660 Mandrake-9.2-CD3.i586.iso /mnt/mdk3

urpmi.addmedia mdk92.cd1 file:///mnt/mdk1/Mandrake/RPMS with ../base/hdlist1.cz
urpmi.addmedia mdk92.cd1 file:///mnt/mdk2/Mandrake/RPMS2 with /mnt/mdk1/Mandrake/base/hdlist2.cz
urpmi.addmedia mdk92.cd1 file:///mnt/mdk3/Mandrake/RPMS3 with /mnt/mdk1/Mandrake/base/hdlist3.cz

Ahora toca la llamada maestra de actualización global del sistema, primero lo ejecutamos en modo test para asegurarnos que no van a existir problemas y luego a darle caña:

urpmi –test –auto-select –media mdk92.main mdk92.contrib mdk92.jpackage

Los media pueden cambiar en caso de que se haya elegido usar el repositorio local.

Y si es posible la instalación:

urpmi –auto-select –media mdk92.main mdk92.contrib mdk92.jpackage

Después de un tiempo descargando (en el –test) y actualizando el sistema, solo bastará con reiniciar y comprobar que todo funciona perfectamente.

Un problema que yo me he encontrado ha sido al pasar de Mandrake 9.1 a 9.2, con los paquetes de KDE 3.1.3, que ahora están mucho mejor estructurados y separados por programas, mientras que antes era más por paquetes de programas relacionados, así que me encontré con que me faltaban cosas como el konsole o kmail, pero nada que no se pudiera solucionar con un urpmi konsole

Sobre el archivo /etc/passwd
Por Rafael Martinez, "El rincon de Linux"

Problemas de seguridad en el archivo de claves de acceso /etc/passwd

El contenido del fichero /etc/passwd determina quien puede acceder al sistema de manera legitima y que se puede hacer una vez dentro del sistema. Este fichero es la primera linea de defensa del sistema contra accesos no deseados. Debe de mantenerse escrupulosamente y libre de errores y fallos de seguridad. En el tenemos registrados las cuentas de usuarios, asi como las claves de accesos y privilegios.

Una linea ejemplo en este fichero:

usuario1:FXWUuZ.vwXttg:500:501:usuario pepito:/home/usuario1:/bin/bash

Los diferentes campos(7) estan separados por dos puntos (:) y el significado de los mismos es el siguiente:

usuario1:	Nombre de la cuenta (Login)
FXWUuZ.vwXttg:	Clave de acceso encriptada (password)
500:	UID de esta cuenta
501:	GID del grupo principal al que pertenece la cuenta
usuario pepito:	Nombre del usuario
/home/usuario1:	Directorio de trabajo de usuario1
/bin/bash:	Interprete de comando (shell) de usuario pepito

Una serie de reglas a tener en cuenta sobre el contenido de este fichero:

• El UID de cuenta 0, pertenece al administrador (root), por debajo de UID 500 esta reservado para el sistema y por encima de UID 500 para los usuarios del sistema (Nota: la frontera del 500 puede variar dependiendo del sistema).

  El GID del grupo principal esta definido en el archivo /etc/group y este sera el grupo por defecto cuando un usuario crea un fichero.

  No hace falta decir que solo el administrador del sistema tiene que tener ID's 0 en estos dos campos. Lo contrario significaria estar dando permisos de administracion (root) a la cuenta en cuestion.

  Lo unico que identifica a una cuenta root del resto es una identificacion UID igual a 0. Podemos tener por ejemplo una cuenta llamada "pepito" pero con UID igual a 0, esta cuenta tendria permisos de administrador (root) y muchos programas que hacen referencia al nombre de la cuenta (ej: who, w, etc) no nos darian informacion sobre que la cuenta "pepito" tiene permisos de root.

  Esto es lo primero que un hacker suele hacer para instalar una puerta trasera en un sistema. Para averiguar cuentas con nombre diferente de root, pero permisos de root existen programas, pero a falta de uno podemos utilizar el siguiente comando:

  awk -F: '{if ($3==0) print $1}' /etc/passwd

  Lo mismo (con un pequeno cambio) se puede utilizar para ver cuentas con GID igual a 0:

  awk -F: '{if ($4==0) print $1}' /etc/passwd

   

• Es muy importante verificar asiduamente que toda cuenta (login) tiene asignada una clave valida. Existen programas para comprobar que no existen problemas de seguridad en /etc/passwd, pero a falta de uno se puede utilizar el siguiente comando para averiguar si existen cuentas sin claves:

  awk -F: '{if ($2=="") print $1}' /etc/passwd

  Nunca dejar una cuenta con el campo de clave vacio, esto significa que no es necesario una clave para entrar en el sistema. Las cuentas de pseudo-usuarios (ej: daemon, lp, etc) y cuentas de usuarios cerradas temporalmente, tienen que tener un asterisco (*) en el campo de la clave.

  Otro punto a tener en cuenta es la eleccion de una buena clave. No se deberian utilizar claves que sean palabras de diccionario, nombres, datos personales, matriculas, etc, existen programas que son capaces de descifrar este tipo de claves. Utilizar al menos 7 caracteres (8 recomendable) e interpolar numeros y letras, mayusculas y minusculas. Existen programas que sustituyen el clasico "passwd" para crear/cambiar claves, que comprueban que la clave es suficientemente buena.

  La explicacion de porque no se deberian utilizar palabras de diccionario, nombres, etc como claves de acceso, es la siguiente:

  Cuando una clave es generada, esta, es codificada con la funcion "crypt", esta funcion se puede definir como una funcion "hash" de una sola direccion, esto es, un algoritmo que es facil de computar en una direccion pero muy dificil de calcular en direccion opuesta. La funcion crypt utiliza un valor aleatorio llamado "salt" el cual esta formado por una cadena de dos caracteres [a-z A-Z 0-9 ./]. Este valor aleatorio permite codificar una misma clave de 4096 maneras distintas (Los dos primeros caracteres de una clave codificada, son los valores de "salt", el resto hasta un total de 13 caracteres ASCII es la clave codificada segun el valor de "salt").

  Una vez que sabemos un poco de teoria de como las claves son codificadas, nos podemos imaginar como se podria descifrar un clave de cuenta que es un palabra de diccionario, nombre, matricula, etc. Existen programas que codifican sistematicamente diccionarios de palabras de las 4096 maneras posibles (segun el valor "salt") y comparan cada codificacion con los valores encriptados en /etc/passwd, si algun valor coincide, significaria que una clave ha sido descifrada. Este es uno de los metodos utilizados por hackers para descifrar claves y la razon de porque no se deben utilizar claves que sean palabras de diccionarios, nombres, etc.

   

• Nunca usar scripts/programas como interprete de comandos en cuentas sin clave. Un ejemplo que lei una vez en un grupo de noticias, hablaba sobre como apagar el ordenador sin necesidad de ser root. Una de las soluciones que daban era el tener la siguiente linea en el fichero /etc/passwd:

  shutdown::0:0:shutdown:/sbin:/sbin/shutdown

  Podeis ver que el campo de clave esta vacio, con esta linea en tu /etc/passwd cualquier usuario, local o no local, puede apagar tu ordenador haciendo un simple telnet a la maquina en cuestion y escribiendo shutdown como login. No hace falta explicar las consecuencias que esto puede tener para tu sistema.

   

• Los ficheros /etc/passwd y /etc/group deben tener permisos de lectura para todos para que muchos programas puedan funcionar y permisos de escritura solo para root. -rw-r–r– 1 root root 11594 Nov 9 12:53 /etc/passwd -rw-r–r– 1 root root 1024 Nov 9 12:53 /etc/group

  Con estos permisos, cualquiera que tenga acceso al sistema puede leer el contenido de estos ficheros e intentar descifrar la clave encriptada de las cuentas. En pequenos sistemas, donde todos los usuarios se conocen y existe confianza entre ellos, esto no es un gran problema, pero en sistemas con un gran numero de usuarios, no es recomendable tener el sistema configurado de esta manera.

  Para evitar esto se puede instalar "Shadow passwords". Con shadow passwords el fichero /etc/passwd puede ser leido por cualquier usuario con acceso, pero la informacion con las claves del sistema queda guardada en un fichero que solo puede ser leido por el administrador (root). Mas informacion sobre Shadow Password en el Howto correspondiente Shadow password HOWTO (ingles)

  Esto es todo sobre este fichero tan especial en nuestro sistema. Comentarios y sugerencias al autor.

El demonio autofs es capaz de montar y desmontar automáticamente sistemas de archivos locales y remotos, liberándonos de hacerlo manualmente mediante la orden mount y umount.

Autofs se comporta de cara al usuario de la siguiente manera:

Existen directorios que están asociados con sistemas de archivos. Cuando el usuario ejecuta una orden que hace referencia al contenido de dicho directorio, autofs montará automágicamente el sistema de archivos correspondiente en ese punto de montaje.

Una vez concluya la operación, espera un tiempo antes de desmontarlo de forma automática.

Autofs es una solución que se compone de una parte que se incluye en el núcleo del sistema (La que se encarga de detectar que estamos entrando en uno de los directorios de automontaje) y de otra en espacio de usuario (un demonio) que se encarga del montaje en sí.

Con esto quiero decir que el kernel debe haber sido compilado con soporte para ello si queremos usarlo. La buena noticia es que autofs es completamente modular y en el caso (improbable) de que nuestro kernel no lo soporte, no tendremos que reconstruirlo entero, sino sólo compilar el autofs como módulo (ahorrando tiempo y un reinicio).

Si tenemos un kernel antiguo (anterior a 2.0.X) o no nos interesa andar recompilando, podemos echar mano a soluciones como amd (automounter daemon), menos eficientes pero que operan solamente en espacio de usuario. Este demonio es obsoleto en Linux, aunque creo que con los BSD hay gente que lo usa aún .

Para comprobar si disponemos de soporte para él incluido en el kernel podemos hacer:

$ cat /proc/filesystems
Esto muestra una lista de los sistemas de archivos soportados por nuestro kernel. Si aparece una línea tal qué:

nodev autofs
Es que nuestro kernel es válido.

Una vez comprobado esto, debemos instalar el demonio. En RedHat y similares, el demonio así como una configuración básica de ejemplo y el script que define el servicio de automontaje se encuentran en el paquete autofs-*.i386.rpm.

Para instalarlo:

# rpm -ivh autofs-*.i386.rpm
Rpm automáticamente añade el servicio al nivel de ejecución actual pero no se arranca aún (y no es deseable que lo hagamos ahora, pues todavía no lo hemos configurado).

Importante: los paquetes de instalación que incluyen las distribuciones son seguros (o deberían serlos), pero si optáis por bajaros versiones actualizadas de Internet, deberías siempre comprobar qué archivos se incluyen, la firma de los paquetes (al menos que el resumen MD5 cuadre con lo esperado) y los scripts que lanzará rpm durante la instalación.

Recordad que cuando instalamos paquetes, lo hacemos como root con todos los peligros que ello implica.

Para chequear la firma (pgp/gpg y MD5):

$ rpm –checksig autofs-*.i386.rpm
Para chequear los scripts de instalación y de desinstalación, en busca de operaciones malignas:

$ rpm -q –scripts autofs-*.i386.rpm
Otras medidas como hacer simulaciones de instalación en entornos chrooted pueden ser excesivas, aunque según dicho popular: "un buen administrador, es el administrador paranoico". Así que allá cada cual con su conciencia .

Una vez instalado, pasamos a la configuración. Vamos a suponer, por simplicidad, que el usuario sólo tiene una unidad de discos flexibles y un cdrom. Nos saltaremos unidades zip, jaz, volúmenes nfs, netbios, etc.

El paquete autofs de RedHat, en las versiones que yo manejo, crea un directorio:

/misc

Trae los archivos de configuración:

/etc/auto.master
/etc/auto.misc

Y el servicio de automontaje:

/etc/rc.d/init.d/autofs

Para la configuración que vamos a hacer, el directorio misc< nos sobra, así que:

# rm -r /misc
Editamos /etc/auto.master para dejarlo de esta forma:

# auto.master $Id$
/mnt/auto.floppy /etc/auto.montaje.floppy –timeout 3
/mnt/auto.cdrom /etc/auto.montaje.cdrom –timeout 15
###
El "timeout" es el tiempo en segundos que dejará pasar demonio después de que hayamos terminado de trabajar con el floppy o con el cdrom antes de desmontarlos. Podeis ajustarlo a vuestro gusto si veis que es demasiado grande o pequeño

Los archivos auto.montaje.cdrom y auto.montaje.floppy no existen, así que los crearemos tomando como plantilla los ejemplos que nos muestran en /etc/auto.misc o en la página man de autofs(5):

# auto.montaje.cdrom $Id$
cdrom -fstype=iso9660,user,noexec,ro :/dev/cdrom
### # auto.montaje.floppy $Id$ floppy -fstype=auto,user,noexec,rw,uid=0,gid=19 :/dev/fd0 ###
Las opciones "fstype" son las que serán pasadas a la orden mount por el demonio.

Podemos fijar opciones específicas de ciertos sistemas de archivos (En el ejemplo del floppy uid=0 y gid=19 son propias de los sistemas fat, vfat, msdos, etc) que serán ignoradas de forma transparente si el sistema de archivos es distinto (Si el floppy es ext2, mount no se quejará porque el demonio de automontaje le pase uid y gid).

Esta configuración no es precisamente la más segura del mundo, pero es bastante cómoda. El gid=19 debería corresponder al grupo "floppy", al que deberían pertenecer los usuarios que deseen escribir en los discos flexibles.

En muchos ambientes, permitir montaje de unidades (Y la escritura en ellas el caso el floppy) a los usuarios se considera un problema de seguridad, pero si sólo nosotros tenemos acceso físico a la máquina esto no debería preocuparnos demasiado.

Escritos los archivos de configuración, ahora iremos al directorio /mnt y procederemos de la siguiente forma:

Borramos los directorios cdrom y floppy si existiesen:

# rm -r floppy cdrom
Creamos los directorios auto.cdrom y auto.floppy.

# mkdir auto.floppy auto.cdrom
Creamos dos enlaces blandos, a través de los cuales accederemos a los sistemas de archivos de automontaje:

# ln -s /mnt/auto.cdrom/cdrom /mnt/cdrom
# ln -s /mnt/auto.floppy/floppy /mnt/floppy
Nótese que ni /mnt/auto.cdrom/cdrom ni /mnt/auto.floppy/floppy existen, y no debemos en ningún caso crearlos.

El demonio de automontaje se encargará de construir esos directorios cada vez que necesitemos acceder a un disco y de destruirlos cuando dejemos de utilizarlo.

No deberíamos tocar nada de lo que haya dentro de /mnt/auto.cdrom/ y /mnt/auto.floppy/.

Llegado a este punto, nos queda comentar (añadir un "#" al principio) las líneas correspondientes al floppy y al cdrom en el archivo /etc/fstab y arrancar el servicio para que podamos disfrutar del automontaje:

# /etc/rc.d/init.d/autofs start

El mejor sistema para instalar/actualizar programas

Voy a explicar de forma práctica y sin entrar en detalles técnicos cómo poder utilizar el comando apt-get en SuSE 9.1 de igual forma que lo hace la distribución Debian.

Empecemos:

1.- BAJAR ARCHIVOS NECESARIOS:

Aqui : ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/9.1-i386/RPMS.suser-rbos/

tenemos todos los archivos necesarios para llevar esta tarea a buen puerto. Los archivos a bajar son los siguientes:

TODOS – EXCEPTO ESTOS:

MPlayer-suite-1.0-rb3.i586.rpm , (luego podremos bajarle cómodamente y con sus dependencias resultas cuando tengamos apt instalado)

kynaptic-0.5-58357cl.1.i586.rpm , apt4rpm-0.68.2-2.noarch.rpm

Si te fijas hay dos versiones distintas de estos dos archivos (a fecha 1-noviembre-2004) , lo que luego nos dará error cuando carguemos los rpm,s, ya que no sabrá cual de los dos instalar.

Repito estos tres archivos no hay que bajárselos.

2.- COMPROBANDO DEPENDENCIAS.

Una vez guardados estos archivos que hemos bajado, tenemos que entrar al directorio donde los tengamos, por ejemplo yo los he guardado en /home/apt-suse-rpms/ con lo que como root entro a dicho directorio:

# cd /home/apt-suse-rpms/

Luego hacemos una comprobación de dependencias con el siguiente comando:

# rpm –test -Uvh *.rpm

con lo que nos muestra una lista con las dependencias existentes para poder instalar los rpm,s bajados. Ejemplo:

error: Failed dependencies:

perl-XML-LibXML is needed by apt4rpm-0. 68.2-2

python-gnome >= 2.0 is needed by gramps-1.0.7-0.suse091.rb.1

etc ……

Tenemos que resolver estas dependencias, bien insertando el cd o dvd de suse 9.1 o bien buscándolos por la red.

Con Yast esta tarea no es nada complicada. Simplemente se va a Yast -> Software-> instalar/desinstalar software – y en Buscar: con las opciones de Buscar en: [x] Nombre [x] Resumen [x] Descripción y [x] Proporciona ACTIVADAS, vamos escribiendo todos y cada uno de los nombre de los paquetes que nos han dado error: Failed dependencies:

ejemplo Buscar: perl-XML-LibXML y pinchamos en el botón Buscar.

En la parte derecha nos aparece el paquete a instalar, le marcamos para instalar, y así sucesivamente con todos los paquetes dependientes.

Una vez marcados para instalar todos los paquetes dependientes pulsamos el botón Aceptar. Yast en este momento se dispondrá a su instalación en nuestro sistema sin más problemas.

Volvemos a utilizar el comando # rpm –test -Uvh *.rpm

para asegurarnos que no sale ninguna dependencia incumplida. Si no sale ninguna dependencia, ya estamos listos para instalar.

Si vemos alguna dependencia incumplida procedemos a instalar el paquete con Yast como ya se ha explicado.

3.- INSTALAR PAQUETES RPM

Con el comando

# rpm -Uvh *.rpm

se instalarán todos los paquetes rpm de nuestro directorio /home/apt-suse-rpms/

Enhorabuena, ya tenemos instalado apt en nuestra distribución SuSE 9.1 favorita.

4.- CONFIGURACIÓN DE SOURCES.LIST

Por defecto tenemos un sources.list creado en /etc/apt/sources.list

Este es el archivo que le servirá al comando apt-get de base para buscar los paquetes que queramos instalar.

Pero vamos a mejorar este sources.list y sus repositorios. Si le dejamos con los repositorios que nos trae por defecto funcionaría correctamente. No es estrictamente necesario hacerlo pero es recomendable ya que a la hora de instalar programas y aplicaciones con el apt-get tendrá muchas más opciones de bajada.

Para ello tendremos que editar el archivo sources.list con el editor que tu quieras, borramos totalmente lo que tenga y pegamos los siguientes repositorios (yo tengo estos):

# inicio de Source.list

rpm ftp://ftp.gwdg.de/pub/linux/suse/apt SuSE/9.1-i386 update-prpm update suse-projects security-prpm security base kde gnome xfree86 mozilla samba3 suser-rbos suser-gbv usr-local-bin suser-tcousin suser-scorot suser-ollakka labplot funktronics packman packman-i686 kernel-of-the-day wine suse-people kde3-stable suser-guru

rpm-src ftp://ftp.gwdg.de/pub/linux/suse/apt SuSE/9.1-i386 update-prpm update suse-projects security-prpm security base kde gnome xfree86 mozilla samba3 suser-rbos suser-gbv usr-local-bin suser-tcousin suser-scorot suser-ollakka labplot funktronics packman packman-i686 kernel-of-the-day wine suse-people kde3-stable suser-guru

# final de Source.list

 

Una vez pegado, guardamos los cambios en el archivo soruce.list, y cerramos.

5. UTILIZACIÓN DE APT-GET

Antes que nada hay que teclear lo siguiente:

# apt-get update

Esto actualizará las fuentes de los paquetes bajando las cabeceras de archivos. No instalamos nada con ello, simplemente preparamos el archivo apt-get para que sepa donde buscar y bajar los paquetes que le peticionemos.

NOTA: Se recomienda hacer # apt-get update habitualmente antes de instalar cualquier programa. Como he dicho actualizará las cabeceras de paquetes y siempre tendremos la última versión del paquete seleccionado.

Ahora estamos listos para instalar el o los paquetes que queramos con:
# apt-get install nombre_paquete
Este comando instala el paquete que le peticionemos.

Ejemplo: # apt-get install MPlayer divx4linux w32codec-all
nos instala el reproductor de Mplayer así como los codec para reproducir archivos con divx xvid etc … en nuestra SuSE.

6. OTROS COMANDOS APT-GET

#apt-cache search programa_que_buscas
Nos dirá el nombre del programa en caso de que no sepas exactamente su nombre

#apt-cache show nombre_paquete
Nos muestra información sobre el nombre del paquete que indiquemos.

#apt-get -s upgrade
Nos actualiza todo el sistema y paquetes que tengas instalados en ese momento. Utilízalo con moderación.

————————————————————————————————————————
AUTOR: tronk de portal.tronk.net … tu portal útil. Con la colaboración de abs #suse
Puedes copiar este mini-manual siempre respetando esta autoría. Si modificas algo de este contenido, o lo copias a otra web, házmelo saber a webmaster @ tronk . net.
————————————————————————————————————————

Y hasta aquí este manual que a más de uno le vendrá de perlas.

Si tienes algún comentario que hacer, o quieres mejorar este manual, hazlo en Comentarios de esta noticia.

Un saludo a todos.

Postfix + Mysql + Teapop HOWTO

1. Introducción

Cuando comence a trabajar como administrador de redes en una pequeña red, me di cuenta que la manera de administrar correos vía Sendmail y usuarios reales era un martirio. No sabía configurar Sendmail ni tampoco tenía tiempo de aprender.

Probando con los distintos MTAs disponibles en Internet, el que finalmente use (y actualmente uso) es Postfix. No es por desmerecer a Sendmail, ni Qmail ni ningún otro. Todos tienen su fortaleza y sus deficiencias. Pero hasta el momento no soy un usuario experto, sino un aprendiz de sysadmin, y algunas veces, la simplicidad da paso al poder, y no al revés.

Cuando comencé a trabajar, aún seguía estudiando. Dentro de los ramos que tenía, uno de ellos era Bases de Datos. Así que empecé a pensar de que forma los servicios gratuitos como Yahoo o Hotmail podían agregar usuarios en tiempo real, casi sin haber intervención humana. Es de allí que comence a pensar que usaban bases de datos para la administración.

Así que me puse manos a la obra en el peor momento de todos, y la solución salió mas por perseverancia que por propia suerte.

1.1 Aclaraciones # comando

Comando que debe ejecutarse como root

$ comando

Comando que debe ejecutarse como un usuario normal

mysql>

Linea de comando de mysql

1.2 Pasos previos

Primero, hay que conseguir el software necesario. Segundo, asumo que se instala desde la consola. Prioritario.

• Un compilador (preferentemente gcc)
• El paquete Make
• Software RPM:
  Mysql (mysql, mysqlclient, mysql-server, mysql-devel) : Estos paquetes estan incluidos en la distribucion minima de Red Hat. Para instalarlo, se necesitan las dependencias de estos paquetes. Fuera del contexto de este HOWTO esta la forma de compilar, configurar y hacer funcionar MySQL, pero igualmente se incluye una pequeña guia de supervivencia practica.

  Disponible en http://www.mysql.org

  Postfix (postfix-XXX-src.rpm) : Paquete incluido dentro de las herramientas de RedHat (PowerTools). Recalco esto ya que el ultimo snapshot no contenia el soporte para entregas virtuales. Preferible instalar los fuentes, parchar, compilar e instalar.

  En todo caso, Postfix esta disponible en http://www.postfix.org

• Fuentes:
  Teapop : Como dije, cuando comence a buscar servidores de POP/IMAP me encontre con este juguete. Soporta los RFCXXXX y RFCXXXX, dominios y usuarios virtuales, autentifica sobre htpasswd, pam, mysql, postgresql, etc.

  Disponible desde http://www.toontown.org/teapop

2.0 Configuraciones previas antes de instalar

Lo primero es crear el usuario y el grupo Postfix, necesarios para la entrega de correos. Desde la consola ejecutar:

# groupadd postfix # adduser -g postfix postfix

Esto creara el directorio /home/postfix que precisamente se volvera la raiz del "spool" de correo, alla "/var/mail".

Instalar los paquetes relacionados con mysql:

# rpm -ihv mysqlXXXXXX.rpm

En caso de necesitar dependencias (Perl), instalarlas. Se debe tener mysql configurado e instalado antes de seguir.

No olvidar el paquete mysql-devel, necesario para compilar Teapop y Postfix.

2.1 Postfix

Instalar los fuentes de Postfix. Esto NO hara que el paquete .src.rpm aparezca en la base de datos RPM, solo descomprime los archivos (parches, scripts y el snapshot)

# rpm -ihv postfix-XXXX.src.rpm

En caso que Linux reclame, verificar que /usr/src/redhat este previamente creado.

Si estuviese creado, "por el amor de dios", sacar cualquier archivo presente alli, para evitar confusiones con otros paquetes. Es super entretenido no saber que parche aplicar, sobre todo por la falta de sueño y el exceso de cafeina…=)

En /usr/src/redhat/SOURCES estara el archivo snapshot-XXXXX.tar.bz2. Este archivo, primero descomprimirlo con bunzip2. Luego, ojala moverlo a un directorio con permisos de lectura para cualquier usuario para configurar y compilar. En este caso, al /tmp

# bunzip2 snapshot-XXXXXX.tar.bz2 # mv snapshot-XXXXXX.tar /tmp

Ahora, como un usuario normal (no root) descomprimimos el snapshot. Por conveniencia use el mismo usuario Postfix.

# su postfix $ cd /tmp $ tar xfv snapshot-XXXXX.tar

(paso opcional) Parchar Postfix. No se cubre aqui, aunque la misma distribucion del postfix-XXXX.src.rpm viene con algunos parches incluidos.

Sigue configurar (dentro del directorio extraido) Postfix para compilar. Para eso usamos:

$ cd snapshot-XXXXXX $ make -f Makefile.init makefiles ' CCARGS=-DHAS_MYSQL -I/usr/include/mysql' ' AUXLIBS=-L/usr/lib -lmysqlclient -lm'

Si se desea incluir soporte SSL, incluir

…. -DHAS_SSL -I/usr/include/openssl -lssl -lcrypto

(Hay mas opciones, como soporte para Pcre, que no voy a cubrir aqui)

Luego,

$ make

De haber compilado, como root,

# make install

Postfix va a a preguntar ciertas cosas. Estas son las respuestas (en mi caso):

[install_root] / [tempdir] /tmp [config_directory] /etc/postfix [daemon_directory] /usr/libexec/postfix [command_directory] /usr/sbin [sendmail_path] /usr/sbin/sendmail [new_aliases_path] /usr/bin/newaliases [mailq_path] /usr/bin/mailq [mail_owner] postfix [setgid] no [manpages] /usr/local/man

Dentro de /usr/src/redhat/SOURCES hay un archivo llamado postfix-init_script.sh. Hay que copiarlo a /etc/rc.d/init.d

# cp postfix-init_script.sh /etc/rc.d/init.d/postfix

Luego, permitirle a Postfix iniciar en momento de reiniciar la maquina con

# chkconfig postfix on

Postfix esta instalado!

3. Mysql

Mysql es un potente pero humilde RDBMS. No aguanta el 100% de la sintaxis de otros RDBMS, pero para nuestro caso, es suficiente.

Antes de comenzar, verificar que la database mysql esta creada. No esta demas ejecutar

# mysql_install_db

para crearla.

OJO!
La distribucion de RPM de mysql viene con una pequeña 'rana': los archivos de mysql no le pertenecen a mysql. Para ello no esta demas devolverles la pertenencia respectiva.

# chown mysql.mysql /var/lib/mysql -R

Hay que arrancar y configurar para partir a mysql.

# /etc/rc.d/init.d/mysql start # chkconfig mysql on

Ahora, ejecutar

# mysql mysql>

Ahora se debe crear el usuario Postfix (u otro, es para hacer mas facil el ejemplo). Hay dos maneras. Una es a traves de mysqladmin, la otra es agregarlo 'a mano' a user.mysql. Prefiero la segunda.

mysql> use mysql; mysql> insert into user (host, user, password) values mysql> ('localhost', 'postfix', password('postfix'));

Se ingresa en la tabla el usuario Postfix con la password "postfix" o con cualquier password que se quiera. Para eso solamente cambiar password('postfix') por password('la_password_que_yo_quiera').

Ahora se debe crear la database 'mail'. Como dije, hay dos maneras. La manera facil, permitiendole al usuario Postfix acceder a ella es :

mysql> insert into db (host, db, user, select_priv) values mysql> ('localhost', 'mail', 'postfix', 'Y'); mysql> create database mail;

Salir de mysql.

mysql> quit;

Verificar que el usuario Postfix pueda ejecutar mysql y acceder a la db 'mail':

# mysql -u postfix -p mail Enter Password:

Ingresar la contraseña de Postfix. Deberia devolver la linea de comando mysql:

mysql>

Si no lo hace, verificar :

1. la contraseña del usuario postfix

   Si se olvido la contraseña del usuario postfix, es facil cambiarla. Entrar a mysql como root.

   # mysql mysql> use mysql; mysql> update user set password=password('nueva_password') where user='postfix'; mysql> quit; # mysqladmin reload

2. verificar que mysql este corriendo (pero no en modo seguro!)
3. verificar que los archivos en /var/lib/mysql pertenezcan a mysql.mysql.

Si todo funciona bien hasta aqui, hay que crear las siguientes tablas (como root):

transport: Transporte, el mismo transporte de Postfix.

aliases : los 'alias' locales de la maquina. Necesario para entrega en dominios virtuales y donde van a caer los mensajes (en un spool truculento en /home/postfix). remote_aliases : 'alias' remotos, que pertenezcan a la maquina o a otra externa.

# mysql mysql> use mail; mysql> create table transport(domain varchar(255) Primary Key, transport char(8)); mysql> create table aliases (id int(6), alias varchar(255) Primary key, mysql> maildir varchar(255) not null); mysql> create table remote_aliases (alias varchar(255) Primary key, mysql> rcpt varchar(255) not null);

Estas tablas son necesarias para Postfix. Ahora agreguemos la tabla necesaria para autentificar a nuestros usuarios:

mysql> create table midominio (user varchar(255) primary key, mysql> pass varchar(255) not null, maildir varchar(255) not null, mysql> active int(8) default 1); mysql> quit;

Luego

# mysqladmin reload

OJO!
Ahora hay que cambiar la contraseña de acceso de root para mysql. Esto es para evitar intrusiones desde la consola (o desde la misma maquina)

# mysql mysql> update user set password=password('nueva_pass_root') where user='root'; mysql> delete from user where user=''; mysql> quit; # mysqladmin reload

Mysql esta corriendo perfecto!

4. Postfix+Mysql

Aqui comienza la configuracion y los pasos mas faciles.

En /etc/postfix se encuentran (un monton!) los archivos de configuracion de postfix. Solo se necesita el principal, main.cf

Necesitamos configurar un par de cosas a este archivo:

myhostname = mydomain = inet_interfaces = all (o las que se quiera escuchar correo)

Ahora, agregar las tablas de 'diccionario' (como las llama Postfix) con soporte de mysql. Todo esto en /etc/postfix/main.cf

transport_maps=mysql:/etc/postfix/transport.cf virtual_mailbox_base=mysql:/home/postfix virtual_uid_maps=mysql:/etc/postfix/ids.cf virtual_gid_maps=mysql:/etc/postfix/ids.cf virtual_mailbox_maps=mysql:/etc/postfix/aliases.cf virtual_maps=mysql:/etc/postfix/remote_aliases.cf

Ahora hay que crear los siguientes archivos en /etc/postfix:

———–transport.cf user=postfix password= dbname=mail table=transport select_field=transport where_field=domain hosts=localhost ———–aliases.cf user=postfix password= dbname=mail table=aliases select_field=maildir where_field=alias hosts=localhost ———–ids.cf user=postfix password= dbname=mail table=aliases select_field=id where_field=alias hosts=localhost

Todavía NO iniciar postfix (si está esta corriendo, echarlo abajo).

Con este sistema, se puede hacer la entrega de varios dominios virtuales sin sudar mucho. Todo es gracias a la tabla transport. Se explica esto mas tarde.

Iniciar mysql:

# mysql -u root -p Enter Password: <—esto solo sale si le cambiamos la password de mysql a root mysql> use mail; mysql> insert into transport values ('midominio', 'virtual:'); mysql> quit;

Con el usuario Postfix, hagamos el "spool":

# su postfix $ cd /home/postfix $ mkdir midominio $ exit

Ahora agreguemos un usuario "virtual":

OJO!OJO!OJO!
Para hacer que funcione bien el truco, hay que indicar en el campo id de la tabla aliases…

EL MISMO USERID DE POSTFIX!

De lo contrario, el maillog se va a llenar de "enforcing file restriction"!

# cat /etc/passwd | grep postfix postfix:x:500:500::/home/postfix:/bin/bash

En este caso, el userid es 500. Tratar que el UID/GID sea el mismo.

# mysql -u root -p mail Enter Password: mysql> insert into aliases values (500, 'yo@midominio', 'midominio/yo'); mysql> quit;

Reiniciar mysql

# mysqladmin reload

Y…

# /etc/rc.d/init.d/postfix start

Ahora viene verificar el log de mail y el de mensajes, en caso de encontrar mensajes raros.

En otra consola (alt-F(algo)), iniciar un simple rastreo del maillog:

# tail -f /var/log/maillog

Y en otra iniciar una sesion smtp:

# telnet localhost 25

Si todo fue bien, mensajes de este tipo NO se veran en el maillog:

postfix/smtpd [3435]: fatal: unsupported dictionary type: mysql

(no se compilo Postfix con soporte mysql)

Si todo salio bien…

# telnet localhost 25 Trying 127.0.0.1… Connected to localhost.localdomain. Escape character is '^]' 220 midominio ESMTP Postfix

Lo cual indica que todo salio bien!

Ahora probemos una entrega local, usando comandos SMTP minimos. Voy a colocar los mensajes del servidor y los mios:

svr>220 midominio ESMTP Postfix yo >mail from: yo@midominio svr>250 ok yo >rcpt to: yo@midominio svr>250 ok yo >data svr>354 End data with . yo >Subject: Estoy probando yo >Hola mundo! este es mi primer mensaje yo >. svr>250 Ok: queued as 06DD618415 yo >quit

Ahora revisar el log:

postfix/smtpd[4147]: connect from localhost.localdomain[127.0.0.1] postfix/smtpd[4147]: 06DD618415: client=localhost.localdomain[127.0.0.1] postfix/cleanup[4148]: 06DD618415: message-id=<20011106031630.06DD618415@fugees> postfix/qmgr[4145]: 06DD618415: from= , size=356, nrcpt=1 (queue active) postfix/smtp[4150]: 06DD618415: to= , relay=none, delay=85, status=bounced (Name service error for midominio (Host not found) while looking up the A record.)

No hay de que preocuparse, solamente no encuentra al servidor para midominio. Por tanto, queda configurar a midominio en un servidor DNS.

Si todo salio bien:

postfix/qmgr[2372]: 6D56718029: from= , size=341, nrcpt=1 (queue active) postfix/virtual[2442]: 6D56718029: to= , relay=virtual, delay=12, status=sent (mailbox)

Todo esta OK! Ahora verificar que haya llegado a nuestro 'spool':

# ls /home/postfix/midominio/ 4 -rw——- 1 postfix postfix 341 Nov 5 02:03 yo

Todo Ok! Creado con los permisos de postfix.postfix! Ahora solo queda crear mas usuarios! Mas dominios! Mas spools truculentos!

Para crear mas dominios 'virtuales': (* mas adelante, dominios y usuarios virtuales)

# mysql -u root -p mail Enter Password: <–como dije, solo si se cambio la password de mysql a root mysql> insert into transport values ('otro', 'virtual:');

(No olvidar que los dominios que se crean tambien deben estar configurados en un servidor de nombre)

Para agregar mas usuarios virtuales:

# mysql -u root -p mail Enter Password: mysql> insert into aliases values (500, 'yo@otro', 'otro/yo'); mysql> quit; # su postfix $ cd /home/postfix $ mkdir otro

Asi creamos un spool distinto para el dominio 'otro'

Todo termino con Postfix aqui.

5. Teapop

Deje esto para el final porque este paso toma 10 minutos en todo. Aparte de ser mecanico.

Primero, desempacar los fuentes de teapop en algun directorio COMO UN USUARIO NORMAL. En mi caso, el fiel usuario Postfix

# su postfix $ cd /tmp $ tar xfv teapop-latest.tar

Configurar

$ cd teapop-XXXXX $ ./configure –prefix=/usr –with-mysql=/usr –sysconfdir=/etc/teapop $ make

Como root, instalar

# make install

El único problema es que el ejecutable 'teapop' lo instala en /usr/libexec. Asi que movamoslo a /usr/sbin

# mv /usr/libexec/teapop /usr/sbin

Verificar que en /etc/services la linea que diga pop3 no este comentada:

# cat /etc/services | grep pop3 pop3 110/tcp pop-3 # POP version 3 pop3 110/udp pop-3

Si esta comentada, descomentarla.

Agregar el siguiente archivo (pop3) en /etc/xinetd.d/ (si todavia tienes inetd, lo siento).

service teapop_xinetd { disable = no type = UNLISTED socket_type = stream protocol = tcp wait = no user = postfix # si se quiere : user = root server = /usr/sbin/teapop log_on_success += USERID log_on_failure += USERID port = 110 }

Y crear el archivo teapop en /etc/rc.d/init.d (tambien se encuentra en la carpeta contrib/rpm en los fuentes de teapop). Gracias, Ivan F. Martinez !

—————-cut here——————– #!/bin/sh . /etc/init.d/functions RETVAL=0 start() { echo -n "Iniciando servicio Teapop: " daemon teapop -s RETVAL=$? echo [ $RETVAL = 0 ] && touch /var/lock/subsys/teapop return $RETVAL } stop() { echo -n "Cerrando Teapop: " killproc teapop echo [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/teapop return $RETVAL } case "$1" in start) start ;; stop) stop ;; status) status teapop ;; restart|reload) stop start ;; *) echo "Uso: teapop {start|stop|status|restart}" exit 1 esac exit $? —————–cut here——————-

Ahora viene el cuento de agregar un usuario para autentificar. Las passwords se guardan en texto plano, de ahi que es necesario que nadie externo pueda acceder a nuestra base de datos. Ademas, el usuario Postfix en mysql solo puede leer y seleccionar.

Usemos el usuario "yo" que creamos hace poco, en la tabla 'midominio' (como root, de nuevo):

mysql> insert into midominio(user, pass, maild) values mysql> ('yo', 'mipassword', 'midominio/yo');

(El mismo lugar donde esta el spool truculento de Postfix).

Ahora, comentar las ultimas lineas de /etc/teapop/teapop.passwd y colocar lo siguiente:

empty: :mysql:/home/postfix:0:postfix:postfix:localhost:3306:mail:postfix : :midominio:user:pass:maild:

Que significa?

El primer campo indica el dominio contra el que se va a autentificar via pop3.
(* explicacion usuarios virtuales y dominios virtuales mas adelante). La palabra 'empty' indica nada despues del @.
El segundo campo es el numero IP del dominio.
El tercero, el tipo de autentificacion, mysql =)
El cuarto, la raiz donde esta el spool. (ven que facil?)
El quinto es el numero hash. Debe ser distinto por dominio.
El sexto y el septimo, es el UID/GID del usuario que lea el spool. (mas facil)
El octavo, el noveno y el decimo indica el host con mysql (y las tablas), el puerto donde conectarse a mysql y la database.
El undecimo y duodecimo indica el usuario/contraseña para leer/seleccionar la db/tabla
El 13avo indica la tabla donde se encuentran las combinaciones usuarios/contraseñas
Los siguientes valores indican los campos de usuario(user), pass(contraseña) y maildir (maild).

Siempre se debe terminar con un dos puntos final.

Ahora, la prueba final.

# mysqladmin reload # postfix reload # /etc/rc.d/init.d/xinetd restart # chkconfig teapop on # /etc/rc.d/init.d/teapop start

Y listo! Probemos: ( y en otra consola, tail -f /var/log/messages)

# telnet localhost 110 Trying 127.0.0.1 blablablabla…. srv–>+OK Teapop [v0.3.3] – Teaspoon stirs around again <1005018897.CFE43C1@Llywellyn> yo—>user yo srv–>+OK Welcome, do you have any type of ID? yo—>pass mipassword srv–>+OK I'm ready to serve you, Master.

Ok!
Todo funciona bien!

Si no funciono, lo mas seguro es que en /etc/teapop/teapop.passwd hayas colocado :

… midominio: :mysql:….

Si es asi, prueba autentificar el usuario como:

usuario@midominio

Todo esto y más es gracias a la siguiente explicacion:

6. Usuarios y Dominios Virtuales: Un pequeño digest (jci)

Paquetes como IMAP de la Universidad de Washington autentifican contra PAM. O sea, revisan la tabla de passwords en /etc/passwd o cualquier metodo PAM como pam_mysql. El mas conocido es /etc/passwd.

Para IMAP y POP3, autentificar contra PAM solamente permite usuarios que hayan sido definidos como "reales". Es decir, que tengan su propio uid/gid en la maquina. Si no se quiere usar el PAM tipico, es un via crucis adaptar (p.ej. pam_mysql) para que tome la tabla de passwords. Y eso sin contar el infame /var/mail.

Para los sistemas Unix, todas las maquinas pertenecen a un dominio 'real' (gracias, oh TCP-IP). El problema comienza cuando maquinas con el mismo numero IP responden ante distintos nombres. Es decir, si midominio y miotrodominio poseen el mismo IP, prima el numero IP reverso (TCP-IP ve numeros, no nombres).

IMAP de la UdeWasington (el que viene con RedHat), el infame IMAP y su infame compañero, POP3, no permiten tener mas de un dominio por maquina. El truco se logro despues cuando aparecio vpop3d (con linuxconf), pero aun asi, autentificaba via PAM! Con una truculenta tabla de passwords pirateada /etc/vmail/passwd.algo. Aj!

Esto significaba que cada dominio, virtual o no, debia tener su propio numero IP. De ahi que NO recomiendo para nada IMAP de UdeWashington. Y no todo el mundo que sirve 40000 dominios tiene 40000 numeros IP para gastar en 3 usuarios por dominio.

Ahora, lo que permite Qmail+Vmailmgr+CourierImap (otro juguete mas) y este sistema es tener mas de un "dominio" inserto dentro del mismo numero IP. Pero la autentificacion no la hace contra PAM, sino con un metodo propio, haciendolo mas flexible para agregar 40000 dominios contra un solo IP.

Pero como diferenciar los usuarios de un dominio y otro? Gracias, oh, arroba. @.

Usando teapop permite el cuento. Usar el mismo numero IP para autentificar usuarios de varios dominios. Lo unico que los separa es la arroba (@).

Por eso, en la configuracion de teapop (teapop.passwd), el primer campo debe quedar en 'empty' si los usuarios se autentifican con

USER usuario

Y agregar un dominio cuando se quiera que el usuario se autentifique con

USER usuario@dominio

Asi evitamos archivos de texto plano innecesarios y configuraciones adicionales. Este cuento resulto gracias a que todo el movimiento con Postfix se hacia con un solo usuario (no root como ocurre con IMAP) y no con una ensalada, como en Sendmail e IMAP.

7. Dato Anecdótico y ¿Que siguie después?

Compilar todo desde cero, Postfix, Mysql, Teapop, configuraciones y demases toma como tiempo record 1 hora y 30 minutos.

¿Que sigue despues?
Bueno, la pregunta del millon. Queda:

• configurar Postfix para que no sea un open-relay y así evitar SPAM
• agregar header_checks y body_checks a Postfix para rechazar contenidos y direcciones. Gracias Ricardo por los body_checks!
• una interfaz web para agregar/modificar/borrar usuarios via PHP.
• no se, quizas un servicio de mail gratuito…=)

8. Agradecimientos

- Ricardo Muñoz por revisar la version preliminar del HOWTO y tener la pacienciapara leerlo, revisarlo, corregirlo y quizas probarlo.
– a los listeros de linux@inf.utfsm.cl por la paciencia. esta es la retribucion. Grax a todos!
– a Christoph Kowalczyk por su Postfix+Cyrus HOWTO.
– a DMZ (www.dmzs.com) por su HOWTO de Postfix+MySQL+Cyrus+Apache+WebMail
– A ??? (kummefryser.dk) por su Postfix+Mysql HOWTO, que fue el comienzo del proyecto.
– A Teaspoon (ToonTown) por un juguete tan inocente, liviano y simple como Teapop.
– A Nick Phillips por su Exim+Teapop MiniHOWTO
– A Ivan

Juan C. Inostroza O. jci@infoser.cl
Probando en Red Hat 7.x

Revisado por
Ricardo Muñoz rmunoz@tux.cl

{mospagebreak title=1ª ENTREGA – Control de tiempo del cliente en el Ciber&heading=Primera Página} 

En esta primera entrega nos centramos en la instalación del Servidor que controlará el tiempo utilizado por nuestros clientes.

INSTALANDO UN GESTOR DE CIBER-CAFÉ BAJO SuSE 9.2:
CybOrg, el Organizador de Cybercafés, es un sistema de punto de venta y administración para cybercafés distribuido bajo la GPL. Tiene una interfaz basada en web y está escrito en Perl usando Template Toolkit y un RDBMS (manejador de bases de datos relacionales). CybOrg usa un cliente Win32/Linux para bloquear las estaciones de trabajo.
El sistema está diseñado para ser usado en un servidor (posiblemente corriendo Linux) y clientes Windows o Linux. Para bloquear las estaciones de trabajo, actualmente usa el cliente de Zeiberbude. Más información en: http://cyborg.sourceforge.net/ (web del proyecto).

PREÁMBULO:
Ya doy por sentado que tienes instalada la versión de Linux SUSE 9.2 en su configuración básica, es decir:
[v] Sistema gráfico básico
[v] Escritorio KDE (o Sistema GNOME) a tu elección.
[v] Documentación de ayuda y soporte
[v] Aplicaciones ofimáticas
[vv] Y lo que quieras también –> nmap, gkrellm, superkaramba, apt para suse …

Y que va tu sistema SuSE a las míl maravillas (gráfica, sonido, ethernet, internet, etc…)

1.- PAQUETES NECESARIOS y no tan necesarios QUE HAY QUE TENER INSTALADOS (todos ellos están en el DVD de SuSE 9.2)::

Con nuestro querido YAST y dentro de Software->Instalar/Desinstalar software, y teniendo como filtro:Buscar , y en Buscar: con las opciones de Buscar en:
[x] Nombre [x] Resumen [x] Descripción y [x] Proporciona ACTIVADAS, vamos escribiendo todos y cada uno de los nombre de los paquetes que vemos más abajo:
ejemplo Buscar: apache2 y pinchamos en el botón Buscar.
En la parte derecha nos aparece el paquete a instalar, le marcamos para instalar, y así sucesivamente con todos los paquetes. Notarás que al hacer la búsqueda del ejemplo ahí están otros paquetes que también deberás de señalar, por lo que no tendrás que buscarles nuevamente.
Una vez marcados para instalar todos los paquetes que nombro más abajo, pulsamos el botón Aceptar. Yast, en este momento, se dispondrá a su instalación en nuestro sistema sin más problemas, resolviendo las dependencias de los paquetes seleccionados si las hubiere.

SERVIDOR APACHE (UTILIZO APACHE2):
apache2
apache2-devel
apache2-example-pages
apache2-mod_fastcgi
apache2-mod_perl
apache2-mod_php4
apache2_prefork

POSTGRES (servidor y cliente de base de datos):
postgresql
postgresql-contrib
postgresql-devel
postgresql-libs
postgresql-server

PERL (Practical Extraction and Report Language – intérprete versión 5.8.5-3)
pcre
perl
perl-Apache-AuthCookieDBI
perl-Apache-Session
pgaccess (Herramienta Gráfica para manejar bases de datos de PostgreSQL)

CGI.pm (módulo cgi)
perl-CGI-Application

Template Toolkit
perl-Template-Toolkit

DBI
perl-DBI
perl-Apache-DBI

DBI driver dbi:pg
perl-DBD-CSV
perl-DBD-Pg
pgperl

DEPENDENCIAS:
perl-Apache-AuthCookie
perl-SQL-Statement
perl-Test-CSV_XS
pgTcl
tcllib

NOTA: Si te hiciera falta algún paquete más, deberás seguir el mismo proceso, pero creo que no te hará falta para este proyecto.

2.- Elementos que hay que bajar de la red:

Tenemos que bajar un módulo que utiliza perl que no está incluido en el dvd de SuSE, o por lo menos yo no he dado con el;
String::Random (módulo de perl)
Bajarlo de: http://search.cpan.org/~steve/String-Random-0.20/Random.pm
* El módulo en concreto se llama Random.pm
– Más adelante sabremos lo que hacer con el.

Así mismo tenemos que bajar el organizador de CYBER-CAFÉS CybOrg que es el elegido para confeccionar este tutorial.

SERVIDOR CYBORG (utilizamos cyborg-0.1.19)
bajar de http://sourceforge.net/projects/cyborg/:
cyborg-0.1.19.tgz (SERVIDOR a fecha August 8, 2004)

cyborg-client-(zbdesk) 2.0.4 (CLIENTES a fecha December 5, 2003) que son:
Download zbdesk-linux-2.0.4.tgz (para linux)
Download zbdesk-win-bin-2.0.4.tgz (.exe 32-bit windows) ejecutable.
Download zbdesk-win-dev-2.0.4.tgz (código fuente 32-bit windows)

3.- Instalación del módulo Random.pm:
La instalación de este módulo no tiene mayor problema y tendremos que crear un directorio llamado String en: /usr/lib/perl5/5.8.5/i586-linux-thread-multi/ y dejando en el directorio creado nuestro módulo Random.pm.

mkdir /usr/lib/perl5/5.8.5/i586-linux-thread-multi/String
cp /tu_ruta_a_Random/Random.pm /usr/lib/perl5/5.8.5/i586-linux-thread-multi/String

Quedando pues de la siguiente manera:
/usr/lib/perl5/5.8.5/i586-linux-thread-multi/String/Random.pm

Si este no es tu path o dirección perl, búsca el tuyo y déjalo en /String/Random.pm. No creo que haya mucha diferencia.

4.- Instalando el servidor CybOrg.:
Auque dentro del paquete cyborg-0.1.19.tgz ya existe un texto para su instalación, y en varios idiomas, aquí ponemos los pasos a seguir. No tiene mayor misterio que descomprimir el archivo e introducir lo que tenemos dentro del directorio: cgi-bin/cyborg en nuestra carpeta de cgi,s ; y en el servidor web apache, meter lo que tengamos en: /htdocs/cyborg en nuestro directorio /htdocs. Pero vamos por partes, como dijo JACK EL DESTRIPADOR :p.

– Descomprimir:
tar zxvf cyborg-0.1.19.tgz
– Luego, nos movemos al directorio cyborg-0.1.19:
cd cyborg-0.1.19
– Y vemos lo que hay en ese directorio /cyborg-0.1.19:
ls -R

* El directorio "/cyborg-0.1.19" contiene los archivos de texto de los Autores, los bugs encontrados, los cambios producidos con respecto a otras versiones, el copying, los de instalación, etc… (no hay que copiarlo, siemplemente LEERLOS)

* El directorio "cgi-bin/cyborg/" contiene todos los scripts (ejecutables) y archivos de configuración.
Copiamos su contenido en su directorio correspondiente:
cp -R /tu_ruta_a_cyborg/cyborg-0.1.19/cgi-bin/cyborg/. /srv/www/cgi-bin
(ojo que es . (punto) y espacio entre el origen y el destino)

* El directorio "htdocs/cyborg/" contiene todos los archivos estáticos (html, imágenes y css).
Copiamos ese directorio a su directorio correspondiente de nuestro servidor web:
cp -R /tu_ruta_a_cyborg/cyborg-0.1.19/htdocs/cyborg /srv/www/htdocs

* El archivo "database/cyborg.sql" contiene un script SQL para crear las tablas de la base de datos de CybOrg y el administrador por defecto. Este script es específico de PostgreSQL.
Veremos más tarde: CREACIÓN DE LA BASE DE DATOS "cyborg". Pero hay que seguir paso a paso la explicación. Demos un paso más ).

CAMBIOS EN LA CONFIGURACIÓN DE CIBORG:
Tenemos que realizar algunos cambios en la configuración de nuestro CybOrg, siguiendo la ruta especificada en los siguientes archivos:
/srv/www/cgi-bin/config/cyborg.conf
/srv/www/cgi-bin/config/options.conf
/srv/www/cgi-bin/config/database.conf
Esto lo hacemos con cualquier editor de texto (kwrite por ejemplo). Realizados los cambios guardamos el archivo.

1* Vamos con cyborg.conf (los cambios realizados están en negrita)
# cyborg.conf
#
# CybOrg main configuration file
#

# System name
system = CybOrg – Cyber Café Tronk

# Base HTTP URL
base_url = http://localhost/cyborg/

# Base HTTP CGI path
cgi_path = /cgi-bin

# HTTP server hostname
http_host = localhost

# Timeout for connecting clients (in seconds)
station_timeout = 0

# Enable/disable debug messages to log
debug = yes

# Station update time (in seconds)
station_update = 60

2* Ahora con options.conf (los cambios realizados están en negrita)
# options.conf
#
# Default options
#

# System language
language = es

# System locale
locale = es_ES

# System charset
# Must be listed in "charsets.conf"
charset = iso-8859-15

# Default listing
# Values: long | short
list_view = long

3* Por último cambiamos database.conf (los cambios realizados están en negrita)
# database.conf
#
# CybOrg database configuration file
#

# DBI database driver (man DBI)
# Pg is for PostgreSQL access
driver = Pg

# Database server name
host = localhost

# Database TCP port
port = 5432

# Database name
dbname = cyborg

# Database user
user = cyborg

# User password
password = pass_de_cyborg (aqui tenemos que poner la contraseña del usuario cyborg que crearemos más adelante)

Ya hemos terminado la configuración de CybOrg.

5.- CAMBIOS EN PostgreSQL
Seguimos con los cambios, ahora le toca el turno al archivo de configuración de nuestro servidor de base de datos PostgreSQL. Básicamente los archivos a modificar son 2.
Vamos con el primero que es :
/var/lib/pgsql/data/postgresql.conf

Aquí añadimos o descomentamos (quitamos la almohadilla #) las siguientes líneas:
listen_addresses = 'localhost'
port = 5432

Ahora vamos con el segundo archivo a configurar:
/var/lib/pgsql/data/pg_hba.conf
Al final de este archivo debe aparecer algo como esto:
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all ident sameuser
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 ident sameuser
host all all localhost crypt

Con estos cambios es más que suficiente en un principio. Después podremos conectar con la herramienta gráfica para el manejo de base de datos en PostgreSQL llamada "pgaccess", a mi me gusta un huevo O_o.

6.- LEVANTANDO LOS SERVICIOS POSTGRESQL, y APACHE2:
Hay que poner en marcha los servicios tanto de la base de datos postgreslq y el servidor web apache2. Esto lo hacemos de la siguiente manera (como root y en consola):
/etc/init.d/postgresql start
Initializing the PostgreSQL database at location /var/lib/pgsql/data done
Starting PostgreSQL done

/etc/init.d/apache2 start
Starting httpd2 (prefork) done

Así ya tendremos postgresql y apache2 corriendo en nuestro servidor.
– A título informativo, si quieremos reiniciar o parar cualquiera de los dos servicios en vez de start pondremos:
– restart (reiniciar el servicio)
– stop (parar completamente el servicio)

7.- CREANDO EL USUARIO cyborg:
Creamos el usuario cyborg como un usuario del sistema. Voy a lo fácil con YAST
YAST->Seguridad y usuarios->Editar y crear usuarios.

Nos muestra esta pantalla Yast. Rellenamos los campos como se indica, y tendremos creado ya el usuario en el sistema.

*- Ahora creamos el usuario cyborg como miembro de PostgreSQL.

1.- Entramos como usuario postgres, ya creado cuando instalamos PostgreSQL con YAST:
su postgres
2.- Creamos cyborg como usuario de postgreSQL:
createuser -U postgres -d -A cyborg

– A título informativo, para borrar el usuario cyborg como usuario de postgreSQL sería : dropuser cyborg

8.- CREACION DE LA BASE DE DATOS "cyborg" :

1.- Creamos la base de datos cyborg y como propietario el usuario cyborg
createdb -U postgres -O cyborg cyborg
-A título informativo, para ver la ayuda del comando createdb seria: createdb –help
2.- Añadir tablas "llenar" la base de datos cyborg con el scritp cyborg.sql
psql -U postgres -d cyborg -f /tu_ruta_a_cyborg/cyborg-0.1.19/database/cyborg.sql
– A título informativo, para listar las bases de datos que tenemos seria : psql -l

3.- Existe un error en la base de datos cyborg que hay que corregir con lo siguiente:
Debemos estar como usuario postgres. Seguramente estemos ya con este usuario en consola. Unicamente si no lo estabamos debemos teclear: su postgres
Llamamos a la base de datos a modificar:
psql cyborg
Saldrá un mensaje como el siguiente:
Welcome to psql 7.4.5. the PostgreSQL interactive terminal.
Type: copyright for distribution terms
h for help with SQL comands
? for help on internal slash commands
g or terminate with semicolon to execute query
q to quit
cyborg=#_
En este punto tendremos que poner lo siguiente:
alter table options add column CHARSET varchar(20);
ALTER TABLE
Luego teclear para salir q:
cyborg=#q

Así estaría modificada la base de datos cyborg sin errores.

9.- POR FIN ….. ENTRANDO EN EL ADMINISTRADOR CybOrg.

En nuestro navegador web tecleamos:

http://localhost/cyborg

Ya podremos ver la siguiente pantalla en nuestro navegador :

Para acceder como administrador tendremos que teclear
Usuario: admin
Contraseña: secret

Son por defecto el usuario y contraseña para poder acceder la primera vez que entremos. Luego podremos cambiar por seguridad este usuario y contraseña en el panel de administración.

Así accederemos a nuestro servidor viendo la pantalla de administración, donde podemos crear usuarios, grupos, ip,s clientes, etc….

———————————————————————————————————————

Hasta aquí esta primera entrega.

En la 2ª Entrega instalaremos el programa clientes, tanto en windows (no tiene nada de especial) como en linux (aquí tendremos algo más de complejidad, pero nada que no se solucione con alguna modificación puntual) xDD.

Si quieres dejar comentarios, sugerencias o aportar algo de ayuda puedes hacerlo aquí : COMENTARIOS.

 

 

{mospagebreak title=2ª Entrega Montando el cliente zbdesk en S.O. Windows&heading=Segunda Página} 

INSTALACION DEL CLIENTE ZBDESK EN WINDOWS XX

Vamos a instalar el cliente zbdesk para nuestro proyecto CybOrg, empezando por los PC,s que tengas con el S.O. Windows.

1.- Bajar, si no lo hemos hecho ya, el cliente zbdesk en binario .exe (32-bit Windows)

Download zbdesk-win-bin-2.0.4.tgz

2.- Descomprimir con winrar o winace, no tiene misterio.

3.- Al descomprimir nos quedará un directorio -> disk1, y el README.txt

4.- Dentro del directorio disk1 pinchamos para ejecutar el SETUP.exe (aplicación)

5.- La configuración por defecto es la correcta, así que, como en casi todos los programas que queremos cargar en el disco duro, le damos a siguiente, en este caso Weiter>

Figura 1.- Primera pantalla de ejecución de zbdesk

6.- Seguimos con la instalación, y únicamente debemos decirle si el cliente tiene Windows 95 o 98, o si por el contrario tiene Windows NT, 2000 o XP, como se muestra en la Figura 2.

Figura 2.- Elección del cliente según el S.O.

Como puedes observar puedes elegir entre Wn9.x based (para windows 95 o 98) y Win NT based (válido para Windows NT, 2000 o XP). La elección dependerá del Sistema Operativo que tenga el PC cliente en cuestión.

7.- Una vez elegido pinchar en Weiter > para seguir la instalación.

8.- Al completar la instalación, verás en el menú de Inicio -> Todos los Programas -> un icono que pinchando sobre el nos lanzará el cliente zbdesk cuyo fin es el de responder a las peticiones de "Pausa" o "Bloqueo" que hagamos en el Servidor CybOrg, bloqueando así la pantalla del PC cliente.

Aquí es donde se coloca el archivo ejecutable: "C:Archivos de programa eiberbudezbdeskzbdesk_nt.exe"

———————————————————

9.- Ahora vamos a autoarrancar el programa cliente zbdesk_nt.exe al entrar en windows.

Esto lo hacemos de la siguiente manera: Ir a Inicio -> Ejecutar …

En este ventana ponemos en Abrir: regedit

Ahora nos muestra la venta del editor de registros de Windows, pues bien, pinchando en cada una de los directorios, ir a la siguiente ruta:

HKEY_LOCAL_MACHINE""Software""Microsoft""Windows""CurrentVersion""Run

Aquí tenemos que introducir una nueva entrada ir al Menú – Edición – Nuevo – Valor alfanumérico, tal y como indica la imagen:

Aparece la siguiente ventana, donde debemos de introducir la cadena, en nuestro caso:

Nombre de valor: zbdesk 2.0

Información del valor: "C:Archivos de programas eiberbudezbdeskzbdesk_nt.exe"

Pinchamos en el botón Aceptar, y podemos cerrar el editor de registros.

Esto es suficiente para que cuando arranquemos el PC cliente se inicie el programa cliente solito.

Una cuestión más, si estamos ejecutando el Firewall bloqueará las características del cliente zbdesk. En este caso pinchamos en el botón Desbloquear para que acepte conexiones de nuestra red local.

Y hasta aquí la instalación del cliente zbdesk para las máquinas clientes que tengan el S.O. windows en nuestro Ciber. Por descontado este proceso hay que seguirle en cada uno de los PC,s que tengas montado con este sistema operativo.

La tercera entrega será: Instalación del cliente zbdesk en el S.O. LINUX. )

Si quieres dejar comentarios, sugerencias o aportar algo de ayuda puedes hacerlo aquí : COMENTARIOS.

 

 

{mospagebreak title=3ª ENTREGA – Montaje del Cliente zbdesk en Linux -&heading=Tercera Página} 

Cliente para X11 (linux) version 3.0

En esta 3ª Entrega vamos a instalar el cliente para linux llamado zbdesk que nos sirve para controlar el tiempo de uso de terminales en nuestro ciber, igual que hicimos con el archivo ejecutable zbdesk en el S.O. Windows en la segunda entrega.

Como Sistema Operativo cliente voy a utilizar Linux en su distribución Debian Sid . También lo he probado en Mandrake y en SuSE 9.2.

Manos a la obra. o_O

1.- DEPENDENCIAS.

Antes de hacer nada, vamos a "cubrir" en los puestos cliente linux, las dependencias que serán requeridas por el programa zbdesk 3.0.

XFree86-devel (que en debian son las xlibs-dev)
ibxml2-devel (en debian es llamado libxml2-dev)

a)Dependencias en Mandrake
XFree86-devel
ibxml2-devel

Lo podemos hacer con el comando : urpmi XFree86-devel ibxml2-devel

b)Dependencias en SuSE 9.2
XFree86-devel
ibxml2-devel

Para hacer esto buscamos con nuestro querido YaST –>Software–>Agregar Software, y en Buscar introducimos esos dos paquetes. Una vez localizado y marcados los dos paquetes con [v] para su instalación, pinchamos en el botón Aceptar.

c)Dependencias en Debian
xlibs-dev
libxml2-dev

Esto es tan sencillo como poner en consola : apt-get install zlibs-dev libxml2-dev

Una vez instaladas las dependencias del cliente (tambien disponible en la documentación del paquete y en la web oficial), pasamos a bajar el paquete.

2.- BAJAMOS EL PAQUETE zbdesk-3.0.tar.gz

Para bajar el paquete vamos a la web oficial de zeiberburge http://zeiberbude.sourceforge.net/ y su sección de news aparece lo siguiente:

11.05.2004
A new X11 client for zeiberbude is available. it is easie to use. you can download the source from Aquí.

De ahí se puede bajar el archivo comprimido llamado zbdesk-3.0.tar.gz

3.- INSTALANDO EL PAQUETE zbdesk-3.0.tar.gz

Para descomprimirlo y desempaquetarlo abrimos consola y ponemos:

#tar -xvfz zbdesk-3.0.tar.gz

Para compilarlo e instalarlo (como root obviamente), sería :

#cd zbdesk-3.0
#./configure
#make
#make install

Y si todo sale bien, el binario que lanza esta aplicación tendría que estar ubicado en /usr/local/bin/zbdesk, el cual deberá ser invocado para que el cliente arranque.

4.- Configurando el cliente para el arranque

4.a) Arranque desde las X usando GDM

Simplemente hay que crear el archivo /etc/X11/gdm/Sessions/zbdesk que contenga las siguientes líneas.

#!/bin/sh
/usr/bin/zbdesk [tu_gestor_de_ventanas_favorito]

donde "[tu_gestor_de_ventanas_favorito]" vendría a ser nada mas ni nada menos que el nombre o mejor dicho el comando que arranca tu gestor favorito de ventanas, como por ejemplo:

wmaker (para el WindowMaker)
fluxbox (para el Fluxbox)
gnome-session (para el GNOME)
startkde (para el KDE)

Luego modificamos los permisos del archivo a 0711, usando el siguiente comando:

# chmod 0711 /etc/X11/gdm/Sessions/zbdesk

bueno y con esto, entre la lista de sesiones del GDM, podremos elegir la que acabamos de crear y hemos llamado "zbdesk" la cual arranca el cliente zbdesk y nuestro gestor de ventanas favorito.

(tenemos que tener en cuenta que debemos tener como gestor de arranque del entorno grafico al GDM. Para esto en debian basta con un simple apt-get install gdm si es que no lo tienen instalado. En mandake y similares ya se instala durante la primera instalación)

4.b) Arrancando el cliente desde la consola

Para los que prefieran arrancar las X desde una consola en modo texto por lo general en debian el runlever por defecto es el 2, el cual si uno lo configura y lo desea al terminar de cargar la mayoría de los scripts de inicio este puede iniciar el gdm, pero hay gente que prefiere (como yo, por ejemplo) arrancar las X desde la consola y elegir como gestor de ventanas al bello archivo ".xinitrc"

También podemos configurar para que el cliente arranque al ejecutar los comandos "xinit" y/o "startx" para lo cual debemos crear el archivo ".xinitrc" en el /home del usuario que usaremos para los clientes, vamos a suponer que el user se llama "cliente" por lo cual tendríamos que hacer lo siguiente:

#adduser cliente
#su cliente
#touch /home/cliente/.xinitrc
#vi /home/cliente/.xinitrc (o ábrelo con otro editor)

Entonces ahí se abre el editor y escribimos lo siguiente dentro del archivo ".xinitrc" el cual estamos editando.

Presionamos la tecla "INSERT" para habilitar el modo de edición, y escribimos los siguiente:

/usr/bin/zbdesk [tu_gestor_de_ventanas_favorito]

(supongo que no hace falta explicar lo que es [tu_gestor_de_ventanas_favorito])

Luego presionamos la tecla "ESC" para salir de modo edición y el editor "vi" se encontrara en modo de comando y le indicaremos que guarde los cambios que hemos realizado con la siguiente combinación :wq!
(este comando ":wq!" (los dos puntos incluidos le dice a "vi" que guarde los cambios y que se cierre el programa, con lo que los cambios que hemos realizado dentro del archivo han quedado guardados). Para comprobar que se ha guardado correctamente podemos verificar con la siguiente línea:
#cat /home/pepe/.xinitrc
/usr/local/bin/zbdesk startkde
#
de esta manera tendría que ser la salida del comando "cat" si elegimos el KDE como gestor de ventanas para trabajar en nuestra sesión en los clientes.

Al ejecutar "xinit" o "startx" debería arrancar el cliente y el KDE, (el cliente es un pequeño cuadrito azul con el tiempo y el costo).

4.c) Arranque de las X automático con un usuario predeterminado

En la vida real supongamos que tenemos unas 20 computadoras en nuestra red del cyber café, y al momento de abrir se nos vuelve algo tedioso ir equipo por equipo tecleando un username y un password. Esto se puede evitar, y lo ideal seria apretar el botón del encendido del PC y que el equipo ya arrancase con el usuario que nosotros hemos elegido o creado para que sea el que por defecto se use en los terminales.
Es decir, que encendamos el PC y que cargue el gestor de ventanas elegido y el cliente zbdesk sin tener que poner un nombre de usuario y contraseña.

Supongamos que acabamos de instalar de cero el zbdesk-3.0, sin haber configurado el GDM ni el .xinitrc

Para llevar a buen puerto nuestro objetivo, haremos lo siguiente en todas las terminales clientes:

Supongamos que elegimos como gestor de ventana el "KDE", y el usuario para tener en las terminales que usan nuestros clientes del ciber lo llamaremos "invitado", para comenzar haremos esto:

#adduser invitado
#cd /home/invitado/
#su invitado

Editamos el archivo /home/invitado/.xinitrc , e introducimos la siguiente línea:

/usr/local/bin/zbdesk startkde

con esto hacemos que el user invitado tenga como gestor de ventanas favorito, mejor dicho por defecto, el KDE.

Luego tenemos que hacer el paso de crear la sesión del GDM, como anteriormente hemos comentado arriba en la sección 4.a) Arranque desde las X usando GDM

——————————————————————————————————————————————————–
Nota para Mandrake: En la distribución mandrake por razones que desconozco (no investigue al respecto todavía) al rebootear la session que creamos en "/etc/X11/gdm/Sessions/zbdesk" pierde los permisos correspondientes que son los que le asignamos "0711" quizas esto se debe a una re-asignacion de ellos cuando bootea. lo cual lo solucione por el momento con un script en /etc/init.d/ que es iniciado cuando el equipo arranca en el run-level correspondiente en el caso de la prueba el mandrake se iniciaba en el run-level "5" (modo grafico), por lo que hay que hacer lo siguiente:

#touch /etc/init.d/zbsessperm
#chmod 750 /etc/init.d/zbsessperm
#vi /etc/init.d/zbsessperm

(suponemos que ya tenemos experiencia con el vi)

el archivo debera contener las siguientes lineas:

#!/bin/sh
echo -n "seteando permisos a la session zbdesk…"
chmod 0711 /etc/X11/gdm/Sessions/zbdesk
echo "Ok."

salvamos presionando "ESC" y escribiendo `:wq!`y presionamos "ENTER" y quedara guardado, luego nos resta hacer un link simbólico para que esto se ejecute cuando arranca el ordenador o PC, o computadora como mas os guste.

ln -s /etc/init.d/zbsessperm /etc/rc5.d/S27zbsessperm

y con eso debería ser suficiente. FIN DE LA Nota para Mandrake
——————————————————————————————————————————————————–

En debian con crear el archivo zbdesk en el directorio de sesiones del GDM es suficiente, como siempre debian funcionando como corresponde .

Solo faltaría hacer que el GDM sea nuestro gestor de sesines por defecto y setear que la sesión del user invitado sea la que arranque por defecto.

ARRANQUE AUTOMÁTICO CON EL GESTOR GDM Y CON USER INVITADO SIN PASS NI CONTRASEÑA.

Para empezar haremos que la sesión del user invitado arranque nada más encender el PC sin pedir pass ni contraseña (testeado en el mandrake 9.1). **ya falta menos**

Seteando el GDM como gestor de escritorios y/o sesiones por defecto
————————————–Esto se puede hacer de varias maneras :

En mandrake la mas fácil y amigable es correr la aplicación llamada "centro de control de mandrake" a la cual se accede por el menú, con lo cual se abrirá una ventana con varios items el que debemos seleccionar es "hardware" y luego una vez dentro debemos dirigirnos a la opción "pantallas" y elegir como gestor de sesiones a el GDM. En resumen:

"inicio de KDE" > "configuracion" > "centro de control de mandrake" (se abre ventana de menu) | "hardware" > "pantallas" (elegir GDM)

O si bien esto se puede establecer manualmente editando un archivo que reside en la siguiente localización:

/etc/X11/default-display-manager

el cual contiene lo siguiente:

#lnxdeb:/etc/X11# cat default-display-manager
/usr/bin/gdm

como podemos observar este archivo contiene una sola línea la cual apunta al binario correspondiente al GDM que se encuentra ubicado en el path:
"/usr/bin/gdm" (en debian), en mandrake se encuentra en "(pronto lo averiguare).

En debian a veces también es necesario correr el siguiente comando para configurar que se cargue el GDM en tiempos de arranque:

dpkg-reconfigure gdm

(damos por hecho que esta el gdm instalado, de no ser asi este se instala con "apt-get install gdm")

Seteando que arranque automaticamente con una sesion de KDE del _user_ "invitado"

Con esto lograremos que la pc directamente cargue el gestor de ventanas KDE bajo la sesion del user invitado, para esto haremos lo siguiente:

"abrir control center de KDE", ir a la rama "Administracion del sistema", luego "Administrador de Acceso", y elegir tab de "Comodidad"

Una ves dentro de este menú debemos marcar el check box llamado "Activar acceso automático" ahí tenemos que elegir un usuario. Elegimos al que hemos creado para que sea usado en las terminales, en nuestro caso lo hemos llamado "invitado" y con esto ya seria suficiente.
Damos por hecho que este usuario tiene en su home el archivo ".xinitrc" con las líneas pertinentes para que arranque el gestor de ventanas y el cliente zbdesk.
El gdm configurado como lo hemos hecho nos será de utilidad si el usuario del equipo reinicia la sesion sin querer, por lo cual nos aparecerá una pantalla de login en la cual podremos elegir la sesion "zbdesk" que es la indicada para el caso.

(en debian no pude lograr que arranque el KDE automáticamente con la sesion de X usuario, cosa que no debe ser tan complicada, debe ser algún archivo que hay que modificar aparte de hacerlo en el entorno grafico)

– Falta pulir alguna cosilla como podeis comprobar, pero seguro que en próximas actualizaciones de este documentos quedará niquelado. xDD

——————————————————————————————————————————–

Hasta aquí esta tercera entrega.

La 4ª Entrega está aún por determinar, ya que no tengo muy claro si dedicarla al tema de configuración del SERVIDOR DE IMPRESIÓN para llevar un control de las impresiones de cada PC cliente, o sobre cómo controlar el ancho de banda "recursos" de internet, o bien dedicarla al tema de SEGURIDAD mediante algún firewall o cortafuegos utilizando iptables a pelo o bien utilizar algo tan sencillo como firestarter…. SEGUIMOS TRABAJANDO.

Si quieres dejar comentarios, sugerencias o aportar algo de ayuda puedes hacerlo en añadir comentarios.

Saludos.
En breve vamos a crear desde cero y paso a paso un tutorial de cómo crear y administrar un ciber-café utilizando para ello un PC como servidor y el sistema operativo linux SuSE 9.2.
De aquí partiremos, independientemente que los clientes sean linux o windows.
La primera entrega será montar el Servidor, utilizando para la administración del CIBER el programa "CybOrg" escrito en perl y montando postgreSQL como base de datos.

Estamos trabajando en ello. Cualquier sujerencia o ayuda será bien recibida. Puedes dejarlas en Comentarios, al final del Artículo .

(25-03-2005) Preparada la 1ª Entrega : Instalación del servidor CybOrg (control de tiempo de usuarios).
(27-03-2005) Preparada la 2ª Entrega Montando el cliente zbdesk en S.O. Windows.
(28-03-2005) Preparada la 3ª Entrega : Montando el cliente zbdesk en S.O. Linux. Dale a Siguiente …

Tenemos una tarjeta inalámbricas que no está soportada nativamente por nuestro sistema operativo linux. Una solución para su funcionamiento es utilizar los drivers de windows junto con la herramienta ndiswrapper. Aquí explico los pasos a seguir basándome en la distribución SuSE 9.3 . Hasta la fecha solo nos va a funcionar en modo managed y en modo Ad-hoc, hasta que otros proyectos como prism54, que están haciendo un gran esfuerzo, incluyan el firmware para los chipset que no son soportados.

Manos a la obra:

• Lo primero que debemos hacer es mirar si nuestra tarjeta wireless está soportada por ndiswrapper. Para ello podemos hacerlo en esta LISTA. Alguna de las tarjetas soportadas son las siguientes:
  * 3Com 3CRSHPW796
  * Admtek (8211)
  * Atheros (AR5004)
  * Atheros (AR5004)
  * Broadcom (4301, 94306)
  * D-Link DWL-AG650 802.11a/b/g
  * Intel Centrino (2100)
  * SMC2802 V2
  * TI AC111
• Para poder saber que tarjeta pci tenemos podemos teclear el siguiente comando: # lspci -v

o también si se trata de una tarjeta para un portátil la vemos con pcmcia o bien si es una tarjeta usb podremos verla con lsusb.


• Si está soportada nuestra wireless, debemos bajarnos los drivers correspondientes de windows. Se pueden conseguir desde los links añadidos en la propia LISTA que hemos mencionado. Esos links nos llevarán a los drivers de windows de nuestra tarjeta wireless.
• Luego bajamos el proyecto ndiswrapper .
• Si tienes SuSE 9.3 tenemos en el dvd el ndiswrapper, así que con YaST -> software -> instalar/desinstalar software, será fácil.
• Para los que tiene debian deben de añadir en su /etc/apt/sources.list la siguiente línea :
  deb http://ndiswrapper.sourceforge.net/debian ./
• Si hemos decidido compilar nosotros mismos el ndiswrapper, lo que hacemos es descomprimir el proyecto ndiswrapper y compilamos. —

tar zxvf ndiswrapper-1.1.tar.gz (o la versión ndiswrapper que te hayas bajado).
Antes leemos el ficheros README e INSTALL por si ha habido alguna modificación en su compilación.
Entramos al directorio donde hayamos descomprimido
cd /home/pepe/ndiswrapper-1.1
Ahora como root ponemos lo siguiente:
# make install
Así ya estaría instalado y compilado la herramienta ndiswrapper. Independientemente que el ndiswrapper lo hayamos compilado como se ha explicado o bien hemos instalado su rpm en SuSE o bajado en Debian con apt-get install ndiswrapper.

• Después debemos de ejecutarlo, añadiendo los drivers de windows y haciendo la "mezcla" así:
  # ndiswrapper -i
  Por ejemplo, si hemos descomprimido el .zip o .rar de nuestros drivers windows en /home/pepe/tarjetawifi-win/drivers/ pondremos esta línea:
  # ndiswrapper -i /home/pepe/tarjetawifi-win/drivers/smc2802w.inf
  Esto nos creará un directorio /etc/ndiswrapper/ con otros archivos y directorios más dentro de él.-

Lógicamente aquí trato con una tarjeta wireless SMC2802w V2, pero lo importante es apuntar al archivo.inf de tus drivers.


• Verificamos que se ha instalado correctamente con :

# ndiswrapper -l
Nos debe aparecer algo como : smc2802w present (recordad que yo tengo una tarjeta SMC2802w V2) con lo que aquí aparecerá tu modelo.


• Después hay que cargar el módulo:
  # modprobe ndiswrapper
• Vemos lo que nos dice el comando # dmesg

y en la última línea aparecerá algo como :
wlan0: ndiswrapper ethernet device X (donde X corresponde a la MAC de nuestra tarjeta).

• Si queremos que se cargue automáticamente el módulo para que pueda ser utilizado por wlan0, debmos poner lo siguiente

ndiswrapper -m
—————————————–

En este punto ya estaría nuestra tarjeta configurada y lista para recibir los parámetros para su correcto funcionamiento. Pero …. en SuSE hay que hacer alguna cosilla más que explico a continuación:

Nos vamos a : /etc/sysconfig/network
En este directorio vemos un archivo que tiene el nombre de nuestra tarjeta inalámbrica, más o menos así:

ifcfg-wlan-bus-pci-0000:00:0c.0 (o algo parecido, la tuya seguro que es ifcfg-wlan-bus-pci-loquesea). Esta es la forma que tiene SuSE de ver la tarjeta inalámbrica por defecto.

bien pues ese archivo le renombramos de la siguiente manera:

ifcfg-wlan0

y en el interior de este archivo cambiar la siguiente constante: _nm_name='bus-pci-0000:00:0c.0'
por esta : _nm_name='wlan0'

Guardamos los cambios y cerramos. Así cambiaremos nuestra configuración para que aparezca nuestra tarjeta identificada con wlan0.

———————-

Luego en el siguiente archivo : /etc/sysconfig/network/wireless
Debemos cambiar o añadir la constante:

WIRELESS="ifcfg-wlan0"

y lo demás lo dejamos como está. Guardamos los cambios y cerramos el archivo.

————————

Debemos reiniciar el equipo para que estos cambios surtan su efecto. Ahora sí que identificamos wlan0 con nuestra tarjeta inalámbrica en SuSE.

Lo comprobamos : # iwconfig

Y ahora vamos a la configuración de nuestra tarjeta wlan0

Vamos a escanear los puntos de acceso o conexiones wifi que tengamos a nuestro alcance :

# iwlist wlan0 scan

Configuramos el nombre de nuestro ap así: # iwconfig wlan0 essid NOMBREAP

Configuramos el modo : # iwconfig wlan0 mode Ad-hoc , o también # iwconfig wlan0 mode Managed

Configuramos al encriptación WEP de nuestras comunicaciones así : # iwconfig wlan0 key restricted XXXXXXXX

Configuramos el canal : # iwconfig wlan0 channel 10 (o el canal donde esté emitiendo tu ap)

Y ahora levantamos nuestra tarjeta para la red así : # ifconfig wlan0 up

De esta forma hemos terminado con la configuración de la emisión "radio", e iría vuestra tarjeta a las mil maravillas, pudiendo observar que los lend de la tarjeta están encendidos.

Ahora configuramos por dhcp "ya sabes para la ip, mascara, puerta de enlace, gateway … automáticos si nuestro ap está configurado de esa manera) así: # dhclient wlan0 … o bien asi … # dhcpcd wlan0

O metiéndolo manualmente si por ejemplo tenemos dos ordenadores que tengan tarjeta inalámbrica y queremos que se vean, o nuestro punto de acceso no le tenemos configurado con dhcp.

Primero dejamos sin servicio de red a la tarjeta wireless, para ello haremos lo siguiente: # ifconfig wlan0 down

Y le indicamos con las dos líneas siguientes la ip , el broadcast, la máscara de subred, y la puerta de enlace.

# ifconfig wlan0 10.0.0.102 broadcast 10.255.255.255 netmask 255.0.0.0 up
# route add default gw 10.0.0.1

Con esto ya tendremos nuestra tarjeta inalámbrica configurada con ndiswrapper .

——————————————————————————————————-

CONSEJO : Una buena herramienta es el programa wavemon para que puedas ver como trabaja tu tarjeta inalámbrica desde consola.

Hay un programa que puede guardar todas las configuraciones de tus conexiones wifi. Ideal si tienes un portatil o bien varias conexiones a tu alrededor en sobremesa. El programa para SuSE se llama wifi-radar_1.9.4-1.guru.suse93_noarch.rpm (esta es su versión), y este es un screen del mismo. Gracias a abs canal #suse irc-hispano por su aportación :
NOTA: Para instalar este programa deberás tener instalado estos dos paquetes : python-numeric , y python-gtk

 

LINKS:

Lista de tarjetas y chipsets wireless soportados en Linux (RECOMENDADA) : http://linux_wless.passys.nl/

Wireless Lan, recursos para linux : http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/

Página oficial del proyecto ndiswrapper : http://ndiswrapper.sourceforge.net/
Instalación de ndiswrapper en la página del proyecto : http://ndiswrapper.sourceforge.net/phpwiki/index.php/Installation
DriverLoader para tarjetas wireless en Linux : http://www.linuxant.com/driverloader/
Proyecto prism54 : http://prism54.org/
ATMEL Linux PCI PCMCIA USB Drivers : http://sourceforge.net/project/showfiles.php?group_id=59001&release_id=128821
Drivers ORINOCO (antes nombrado Wavelan) para Linux : http://www.nongnu.org/orinoco/
Compañia Linux-wlan. Soluciones embebidas para wlan : http://www.linux-wlan.com/download.html#WLAN
Linux ZyDAS zd1201 Driver : http://linux-lc100020.sourceforge.net/
Proyecto Mad WiFi : http://madwifi.sourceforge.net/
Realtek RTL8181 para Linux : http://rtl8181.sourceforge.net/

———————————————————————————————————

Este mini manual está realizado por tronk.net . Puedes copiarlo y/o modificarlo, agradeciéndote que me comunicaras su copia, así como las modificaciones que hagas en el, o bien dejando un comentario.

———————————————————————————————————

Crear en SuSE nuestro propio CERTIFICADO SSL Certificado SSL para Apache2.

Cómo crear nuestro propio CERTIFICADO SSL firmado por nosotros.

Lo primero que necesitamos es tener instalado el paquete OpenSSL. Si no lo tenemos instalado, lo podemos instalar sin complicaciones con YaST.

Luego desde consola tecleamos lo siguiente:

#cd /etc/apache2
#rm ssl.key/server.key (borra anterior server.key)
#rm ssl.crt/server.crt (borra anterior server.crt)

Creamos la clave del servidor

#/usr/bin/openssl genrsa -des3 -rand /etc/services:/etc/passwd -out server.key 1024

-> ahora nos pide password phrase

Enter PEM pass phrase: MiContraSeña

#/usr/bin/openssl rsa -in server.key -out server.pem

-> nos sirver para que no nos pida el password.

Creamos el certificado

#/usr/bin/openssl req -new -key server.pem -out server.csr

—-> Después de esto nos saldrá un formulario que deberemos cumplimentar. Pongo algún dato de ejemplo, debiendo poner los tuyos.

Country Name : ES
Población
Provincia
Tronk.Net Tu Portal Útil
Tronk.Net
ssl.tronk.net
admin@tronk.net
intro <-|
intro <-|

Firmamos el certificado

#/usr/bin/openssl x509 -req -days 365 -in server.csr -signkey server.pem -out server.crt

el 365 seria el tiempo de duración en días de duración de nuestro certificado y equivale a 1 año.

Un certificado sirve para una sola IP, y una IP solo puede tener un certificado. Es decir, que si tenemos dos dominios que apuntan a una misma IP y creamos un certificado para cada dominio, no nos sirve. Solo valdría el primer certificado. El segundo se ignoraría. Para tener un certificado en cada dominio, deben apuntar a IP's diferentes.

Copiamos los ficheros al directorio correspondiente

#cp server.crt /etc/apache2/ssl.crt/

#cp server.key /etc/apache2/ssl.key/

#cp server.pem /etc/apache2/ssl.key/

Una vez hecho esto tenemos que añadir unas líneas en 2 ficheros de configuración de nuestro Apache2.

Entramos en : /etc/apache2/listen.conf

Y añadimos esta línea : NameVirtualHost _default_:80

Donde_default_ puede ser, bien un nombre de host : ejemplo.com o bien tu ip si es que la tienes fija.

 

Luego añadimos o descomentamos las siguientes líneas : /etc/apache2/vhosts.d/vhost-ssl.conf

<VirtualHost _default_:443>
    # General setup for the virtual host
    DocumentRoot "/srv/www/htdocs"
    ServerName new.ejemplo.com:443
    ServerAdmin webmaster@ejemplo.com
    ErrorLog /var/log/apache2/error_log
    TransferLog /var/log/apache2/access_log

 

*** Y reiniciar el servidor apache

#/usr/sbin/apache2ctl stop

#/usr/sbin/apache2ctl startssl

Entramos en el servidor mediante un navegador web, pero esta vez no usaremos http, sino https. Con una 's' al final. Por ejemplo: https://ssl.tronk.net

Si todo ha ido bien nos informará de que el certificado ha fallado. Esto es normal, ya que lo hemos firmado nosotros mismos y no una autoridad certificadora. Aceptamos el certificado y nos fijamos en la parte inferior del navegador. Deberíamos ver un candado. Si pinchamos en él podremos ver la información del certificado.

Recordar después mapear el puerto 443, que usamos para la conexión SSL, en vuestro router y permitir el acceso desde el exterior configurando vuestro firewall/cortafuegos.