15/9/08

Copiar y crackear no es la solución...

Muchos creen que realizando copias no autorizadas de programas privativos de alguna manera están aportando a una buena causa. No importa cuánto ni por qué detesten a Microsoft u otros, ayudar a la difusión de sus programas es ayudarlos a consolidar su posición y, peor aún, poner a más usuarios bajo su control.

Muchos programas privativos actúan como verdaderos “candados” que se cierran sobre quienes los usan. Esto se logra por diversos medios:

  • Formatos cerrados: Cuando un programa almacena la información del usuario bajo un formato desconocido, está capturándola. De esta manera el usuario dependerá del programa para acceder a la información que le pertenece, pudiendo serle muy difícil y costoso optar por alguna alternativa futura.
  • Funciones restringidas, ocultas e indeseables: A veces algunas funciones son arbitrariamente restringidas, en favor de los intereses del productor. Las funciones de “exportación” son un buen ejemplo, en relación con el punto anterior. También es común encontrar funciones “ocultas“, que se ejecutan sin el conocimiento del usuario (muchas veces, invadiendo su privacidad).
  • Control de la evolución: El desarrollador del sistema privativo es el único que puede realizar modificaciones sobre el mismo. Esto incluye el añadir nuevas funciones o reparar errores. Muchas veces se incorpora una mejora útil en una nueva versión para imponer nuevas restricciones (condiciones de licenciamiento abusivas, funciones ocultas, etc.) a los usuarios.

Nótese que el factor económico (el precio de la licencia del programa) no es relevante en ninguno de estos puntos, aunque en algunos casos puede ser un factor más a considerar.

Distribuir copias no autorizadas de programas privativos es como hacer copias de candados. El espejismo es creer que la cerradura del candado es la débil protección anti-copia del programa y que la llave es el “crack“. Nada más errado: la llave es el control del programa, que sigue estando en poder quien posee su código fuente. Se haya pagado o no por una licencia de uso.


Fuente: El blog de Javier Smaldone

8/9/08

La mascota de PHP

Por que un elefante es la mascota de PHP ?

A lo mejor sabes mucho o poco de PHP, pero a lo mejor no saben por que escogieron un elefante como mascota, bueno pues aquí les dejo esta imagen que lo explica muy fácil...

Log-in en Fedora Directory Server para Clientes Linux


Fedora Directory Server nació en 1999 como Netscape Directory Server. En 2004, Red Hat compró Nestcape Directory Server con un compromiso: mantenerlo como proyecto Open Source. En la actualidad existen Red Hat Directory Server como versión empresarial y Fedora Directory Server como versión libre.

Algunas carácteristicas clave del FDS(Fedora Directory Server) son:
-Usa el Manejador de Bases de Datos Berkeley para almacenar sus datos.
-Replicación Multimaestro (MMR), dando una alta disponibilidad al Servicio de Directorio.
-Escalabilidad: Miles de operaciones por segundo, miles de clientes concurrentes, millones de entradas y cientos de gygabytes de datos.
-Autentificación de usuarios y transporte de datos de forma segura(SSL v3, TLS y SASL).
-Sincronización de usuarios y grupos con el Microsoft Active Directory.

Para instalar el Fedora Directory Server siga este corto manual
Despúes de tener instalado el Servicio de Directorio, ingresemos a la consola de Administración ejecutando:

cd /opt/fedora-ds;
./startconsole -u admin -a http://siona.localhost.localdomain:26492/

En la consola se pueden ver 2 pestañas, una denominanada Servers and Applications y la otra Users and Groups. La primera provee funciones de gestión para los Servidores de Directorio y Administración, y la segunda para Usuarios y Grupos.

Empezemos por crear un usuario ingresando sus datos y prestando especial atención a los atributos NT User y Posix User, pues ambos permiten que FDS actúe como un Servidor de login centralizado para entornos Windows y Linux.

Ahora, creemos un usuario llamado Pepe Perez cuyo nombre de usuario sea peperez, despúes de hacer esto, vamos al atributo Posix User y definimos el user ID, el group ID, el home Directory y el shell del usuario con los valores 333, 333, /home/peperez y /bin/bash respectivamente. Antes de configurar estos valores, aseguremonos de que user ID y group ID no estén ya en uso.

Esta es toda la configuración necesaria para que FDS actúe como un Servidor de login centralizado.

El siguiente paso es configurar el Cliente para acceder al Servidor, para ello necesitamos hacer 4 cosas:

1- Instalar los modulos nss_ldap y pam_ldap.
2- Modificar el NS cambiando el archivo de configuración /etc/nsswitch.conf para permitir LDAP.
3- Modificar /etc/ldap.conf para adaptar el entorno.
4- Modificar la configuración de PAM para permitir autentificación en LDAP con SSH.

Probablemente los modulos nss y pam ya estén instalados, visualizemos los sus archivos de configuración /lib/libnss_ldap.so.2 y /lib/security/pam_ldap.so; en caso de que no los encontremos, entonces habrá que instalar los paquetes.

El cliente que vamos a usar para hacer el logín es Ubuntu 8.0.4 , el cuál tiene instalados los paquetes por defecto. En caso de no encontrarlos, hay que instalarlos con el manejador de paquetes, que en el caso de debian sería apt-get.

Modifiquemos el archivo /etc/nsswitch.conf para permitir LDAP como opción. Cambiar las directivas password, group y shadow:

passwd: files ldap
group: files ldap
shadow: files ldap

Luego, editemos el archivo /etc/ldap.conf incluyendo lo siguiente:

base dc=localhost, dc=localdomain
host IP del host

Donde la directiva localhost es el nombre del servidor FDS, localdomain es el dominio LDAP seleccionado durante la instalación y host es la dirección IP del servidor.

Finalmente, configuramos SSH para permitir autenticación desde la fuente LDAP. Para ello agregamos 3 líneas al archivo /etc/pam.d/sshd

auth sufficient /lib/security/pam_ldap.so
account sufficient /lib/security/pam_ldap.so
password sufficient /lib/security/pam_ldap.so

Eso es todo lo necesario para una configuración básica.

Por
Raul Chavarría
Samir Cespedes
Estudiantes de Administración de Redes
SENA - Regional Antioquia
2008
©