En concreto, queremos ver gráficamente qué ficheros incluyen a qué otros (con include, require o require_once). Para ello, haremos uso de la extensión “inclued” (sí, al parecer es un juego con las letras de include).

$ sudo pear install inclued-beta

Configuramos a continuación el fichero php.ini para activar la extensión, añadiendo esta línea

extension=inclued.so

y en la parte inferior del mismo fichero, una variable de configuración:

[inclued]
inclued.enabled = On

Ahora reiniciamos Apache para que coja los cambios:

$ sudo /etc/init.d/apache2 restart

Editamos la página inicial (index.php o similar) de la aplicación de la queremos obtener el grafo, y añadimos al final lo siguiente:

// File to store the inclued information
$fp = fopen('/tmp/wp.ser', 'w');
if ($fp) {
    $clue = inclued_get_data();
    if ($clue) {
        fwrite($fp, serialize($clue));
    }
    fclose($fp);
}

Esto generará un fichero /tmp/wp.ser con información serializada de los includes y requires que carga index.php y sus ficheros dependientes (es decir, el análisis se hace de forma recursiva)

Sólo falta un paso: usar graphviz para generar un fichero .dot que luego podremos convertir a .png con la utilidad dot.

# creamos el dot
$ php graphviz.php -i /tmp/wp.ser -o wp.dot
# lo convertimos a png
$ dot -Tpng -o inclued.png wp.dot

1) Instalar Connect Bot (para la parte SSH que explicaré a continuación) y MySQL Connect (de Javier Romero).

2) Generar un túnel SSH que permita conectar el puerto 3306 del dispositivo Android al puerto 3306 de la máquina remota (vía túnel SSH, porque el puerto 3306 remoto, recuerda, está filtrado por el firewall)

Para ello, en Connect Bot mantenemos pulsada la conexión SSH que queremos tunelizar y en el menú contextual elegimos “Editar redirección de puertos”. Ahí configuramos una nueva redirección así: (la traducción del primer campo está mal, debería poner ‘nombre del túnel’ o algo similar, no nombre del usuario)

Conectamos ahora normalmente con Connect Bot (como si de una conexión SSH normal se tratara). Internamente estará abriendo el túnel.

3) Abrir una conexión con protocolo MySQL desde el cliente Android (la aplicación que haga esto en principio no sabe que el puerto 3306 local es realmente un extremo del túnel SSH. Para la aplicación Android ese puerto corresponde a una BD MySQL local!) En la imagen adjunta, “tester” es el nombre de usuario MySQL que tengas configurado en la DB remota.

¡Listo! Ya puedes ver y editar tuplas y esquemas de tus tablas cómodamente desde tu tablet Android (desde tu móvil también, pero no tan cómodamente

La creación de ramas y su completa gestión en VIM la podemos estudiar en el manual online de este potente editor. Aparte del hecho de que desconocía esta creación automática de ramas de versiones del mismo texto, también desconocía que se pueden hacer cosas como éstas:

Por ejemplo, quieres recuperar el estado del texto tal y como estaba hace 45 minutos:

Por mi parte, dejo aquí otro enlace con mi aportación: un Diagrama de Secuencia hecho en OOo Draw. Como lo que el resto de colegas aprovechará serán los elementos gráficos y no el texto, seguro que no os importa que el texto del diagrama esté en Euskera y que el propio diagrama sea un borrador Estoy seguro de que aquel que busque una plantilla para comenzar a crear diagramas UML en OOo Draw, agradecerá lo que ofrezco.

$ export DEBUG_DONT_SPAWN_FETCHES=1
$ mysql-admin

Sin embargo, si lanzaba el comando dmesg | grep ipw sí que me aparecía la tarjeta :

root@morton:~# dmesg | grep ipw
[17179584.112000] ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.0.5m
[17179584.112000] ipw3945: Copyright(c) 2003-2006 Intel Corporation
[17179584.112000] ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection
[17179585.572000] ipw3945: Detected geography ABG (13 802.11bg channels, 23 802.11a channels)

También veía que los módulos necesarios estaban cargados:

root@morton:~# lsmod | grep ipw
ipw3945 126620 1
ieee80211 37064 1 ipw3945

Pero tras instalar network-manager-gnome con apt-get, en el icono del mismo, sólo veía la red cableada, sin ninguna posibilidad de usar la wireless.

Indagando por distintos foros, y tras unas cuantas pruebas, parece ser que sólo me faltaba una cosa por instalar para que la Intel 3945ABG funcionara: el paquete linux-resticted-modules.

# apt-get install linux-restricted-modules-$(uname -r)

Ahora escribo este mensaje desde el sillón de mi casa, conectado por wifi!

Información:

Sistema Operativo Libre. Entre las novedades que se introducen en Ubuntu 10.10, con respecto a versiones anteriores, tenemos a Shotwell (que reemplaza a F-Spot como gestor de imágenes), un nuevo applet de sonido (ya introducido en Ubuntu 10.10 Alpha 3), soporte para tecnología OpenCL (que aprovecha mejor el potencial de la GPU), un nuevo instalador, un nuevo fondo de escritorio, una nueva fuente Ubuntu, etc.

Ubuntu es fácil de utilizar, viene con miles de aplicaciones libres. Ubuntu tiene todo lo que necesite. Trabaja con los archivos existentes para PC, impresoras, cámaras y reproductores de MP3.

Ubuntu incluye Mozilla Firefox – para una rápida, navegación web segura. También puede optar por navegadores alternativos como Google cromo del Centro de Software de Ubuntu.

El Centro de Software de Ubuntu le da acceso instantáneo a miles de código abierto y selecta aplicaciones gratuitas. Y ahora usted puede comprar aplicaciones también que incluyen: educación, juegos, sonido y video, gráficos, de programación y la oficina.. Todas las aplicaciones son fáciles de encontrar, fácil de instalar.

Puedes descargar Ubuntu 10.10 desde el sitio web de Ubuntu, en formato ISO, BitTorrent, comprar los CDs desde su tienda online, reservarlos de forma gratuita, etc.

Requisitos:

ues veras con el único requisito que es digno de mención es que si necesita una buena tarjeta de vídeo integrado o una NVidia (con su controlador propietario) desconozco desde que modelo ya que nunca e tenido una NVidia, ATI (a partir del modelo Radeon HD 2000 puede ser necesario el controlador propietario)

y un monitor que soporte una resolución de 1024×768.
bueno como algunos esto es algo nuevo el espacio que en hd es el que tu le quieras dar mínimo 4gb
RAM 1gb y se preguntaran y luego como entro a windows los técnicos de linux tienen todo solucionado por eso crearon lo que llamamos grub que te permite seleccionar entre los sistemas que tenemos instalados con cual queremos iniciar

Les presento OpenSuse un Sistema Operativo LINUX de gran estabilidad y superioridad a Windows, ya que los troyanos y otros virus no lo infectan para nada, a demás viene con una gran variedad de herramientas para convertirse en todos unos hackers o crackers, además de la gran variedad de herramientas multimedia, para oficina, internet y servicios empresariales como bases de Datos, servidores Web, Proxy, en fin no puedo decir todo lo que este sistema tiene, y pueden configurarlo de tal manera que parezca un sistema MAC o mejor que eso.

Lo Mejor es que no requiere ningún crack ni pagar alguna licencia, ya que este sistema esta bajo las licencias GNU que son de software libre.

la imagen es pesada pero crean me vale la pena.

Para Descargar Linux OpenSuse Gratis clic aquí.

¿Qué es LDAP?
El significado de las siglas LDAP, es Lightweight Directory Access Protocol y su traducción al español, es Protocolo de acceso a Directorios Ligeros. Es un servicio de directorios y viene a ser una especie de base de datos, cuya estructuración se realiza en directorios. Dicha base de datos está optimizada para hacer búsquedas o lecturas, por lo que es un buen candidato a la hora de poner en marcha una agenda, un sistema de autenticación, un DNS o cualquier otro servicio dónde se van a hacer muchísimas más consultas que nuevas escrituras o modificaciones.
En Linux, poseemos una versión libre de un servicio de directorio como es OpenLDAP, por lo que será la que utilizaremos en este articulo.

Instalación de OpenLDAP
Una vez hemos explicado (mínimamente), en que consiste un servicio de directorio LDAP, vamos a instalar el que nosotros utilizaremos en este artículo, OpenLDAP.
Dado que en este misma web, ya existe documentación sobre este aspecto, nosotros solo nos ceñiremos a la instalación de OpenLDAP en la distribución debian. Solo recordar, que si queremos hacer uso de características especiales en nuestro servidor LDAP, como por ejemplo compatibilidad con OpenSSL, deberemos instalar desde fuentes, compilándolo con soporte para dicha característica.
Para instalar el servidor LDAP en debian, teclearemos en una consola el siguiente comando (instalaremos de paso el cliente también):

apt-get install slapd ldap-utils

Al hacer esto, nos preguntará si queremos poner en marcha nuestra base de datos automáticamente con la información que nosotros le pasemos o mediante un fichero ldif existente.

Le indicamos que lo queremos hacer de forma automática y entonces nos preguntará que tipo de base de datos LDAP vamos a configurar: domain or host, location o custom. seleccionaremos “domain or host” y entonces nos preguntará el dominio que deseamos configurar (A modo de ejemplo, seleccionaremos redes-linux.com, dc=redes-linux, dc=com).

Seguidamente, nos preguntará (dos veces, para verificar que no nos hemos equivocado) por el password de nuestro administrador, en nuestro caso prueba.
Una vez le hemos introducido el password, nos preguntará si queremos que se repliquen los posibles cambios a otro servidor, a lo que responderemos No.
Y ya esta, ya tenemos una configuración mínima de nuestro servidor LDAP. Si quisiéramos cambiar dicha configuración, solo debemos editar el fichero /etc/ldap/slapd.conf y reiniciar dicho servidor:

/etc/init.d/slapd restart

Migración de los usuarios del sistema
Para migrar los usuarios de nuestro sistema, haremos uso de una serie de scripts en Perl desarrollados por PDAL Software Pty Ltd.
Una vez nos hemos descargado el fichero que contiene estos scripts, lo descomprimimos mediante el comando:

tar zxvf MigrationTools.tgz

Entramos en el directorio MigrationTools-45 que nos ha creado y editamos el fichero migrate_common.ph. De dicho fichero, debemos editar las variables (los valores que cito, son los que deberían ir si estamos configurando el dominio “redes-linux-com”):

$DEFAULT_MAIL_DOMAIN="redes-linux.com";
$DEFAULT_BASE = "dc=redes-linux, dc=com";

Una vez hemos editado estos dos parámetros, ya podemos migrar los usuarios de nuestro sistema con el comando:

./migrate_passwd.pl /etc/passwd passwd.ldif

Esto, nos generará un fichero passwd.ldif, que contendrá todos los usuarios que teníamos en el fichero /etc/passwd, por lo que antes de añadirlo a nuestro servidor LDAP, deberemos eliminar aquellos que no sean usuarios locales (ya que son los únicos que utilizaremos para autenticarnos en el proxy).
Una vez hayamos eliminado todas las entradas que hagan referencia a aquellos usuarios que no necesitamos, añadiremos las demás entradas a nuestra base de datos LDAP, mediante el comando:

ldapadd -x -D "cn=admin,dc=redes-linux,dc=com" -W -f passwd.ldif

Al teclear dicho comando, nos pedirá el password del Administrador de la base de datos LDAP. Lo introducimos y ya estarán migrados nuestros usuarios.

Creamos el script de autenticación
Una vez tenemos lista nuestra base de datos de usuarios, deberemos crear en el servidor Squid (puede ser el mismo ordenador donde esta también el servidor LDAP u otro diferente), un script /usr/lib/squid/autenticacion_ldap que contenga:

#!/bin/bash
#Imaginemos que la IP del servidor LDAP es la 192.168.1.2
#Va todo en una linea, se ha recortado por estética
/usr/lib/squid/ldap_auth -R -b dc=redes-linux,dc=com
-D cn=admin,dc=redes-linux,dc=com -w prueba -f uid=%s 192.168.1.2

Y después de esto, le damos permisos de ejecución:

chmod a+x /usr/lib/squid/autenticacion_ldap

Configuramos Squid
Después de haber migrado los usuarios y de haber editado nuestro script de autenticación, solo nos faltará configurar Squid, para que coja dicho script como método de autenticación. Para ello, deberemos añadir en el fichero de configuración de Squid (/etc/squid.conf), los parámetros:

authenticate_program /usr/lib/squid/autenticacion_ldap

#Añadimos una acl de tipo password que luego tendremos que aplicar a nuestra red
#Por ejemplo, si hemos creado una acl para definir nuestra red de esta forma:
#acl mired src 192.168.1.0, deberemos aplicarla asi:
#http_access allow mired password

acl password proxy_auth REQUIRED

Después de añadir estas opciones, reiniciaremos el servidor Proxy:

/etc/init.d/squid restart

Y ya está, ya nos debería pedir la autorización cada vez que intentemos navegar por Internet, desde cualquiera de los clientes que salgan a través del Proxy.

Antes de nada, para hacerlo todo más sencillo, vamos a imaginarnos que poseemos una maquina con dos interfaces, eth0 y eth1. Dichas interfaces tienen asociada una dirección IP cada una:

eth0 -> 192.168.1.1
eth1 -> 192.168.2.1
En esta maquina queremos meter dos rutas estáticas:

1. Hacia la red 192.168.3.0, para lo cual tenemos que pasar por la maquina 192.168.1.2. (será el gateway hacia esta ruta).
2. Hacia la maquina 192.168.4.23, para lo cual hay que pasar por el host 192.168.2.2 (este será la puerta de enlace a la maquina destino

Estas rutas, si las tuviéramos que meter a mano, bastaría con que tecleásemos los comandos:

1. route add -net 192.168.3.0 netmask 255.255.255.0 gw 192.168.1.2
2. route add -host 192.168.4.23 gw 192.168.2.2

Con esto, las rutas que deseábamos poner en marcha, ya estarían funcionando perfectamente, pero si apagásemos la maquina o simplemente si reiniciasemos el demonio de red (por ejemplo porque estamos haciendo algún tipo de mantenimiento local que requiere que echemos abajo la interfaz y la volvamos a levantar), estas rutas se perderían, debiendo de teclear los comandos “route” de nuevo (si hay alguna vez que reiniciamos varias veces, puede llegar a ser desesperante).
Por lo tanto, debemos de encontrar una forma de poner estas rutas permanentes en nuestra maquina.
Una forma de hacer que estas rutas no se pierdan cada vez que reiniciemos nuestro ordenador, sería poniendo estos comandos “route”, en algún script de inicio de nuestra maquina. Pero de esta forma, no evitaríamos que si reiniciamos solo el demonio de red o simplemente si echamos abajo la interfaz para luego volverla a levantar, perdiésemos irremediablemente estas rutas.
Por lo tanto, debemos encontrar una forma que estas rutas, si la red de nuestro computador esta funcionando, estén en marcha y sean permanentes. Pues bien, en este artículo vamos a poner la manera correcta de como se debería hacer (vamos a contar como dicen los desarrolladores de estas distribuciones que se debería hacer).

Red Hat/Fedora
En Red Hat, tradicionalmente las rutas se debían especificar en un fichero de texto, situado en el directorio “/etc/sysconfig”, llamado “static-routes”. En este fichero, debíamos especificar las rutas de esta forma (implementaremos las rutas de nuestros ejemplos):

1. eth0 net 192.168.3.0 netmask 255.255.255.0 gw 192.168.1.2
2. eth1 host 192.168.4.23 gw netmask 255.255.255.255 192.168.2.2

De manera que especificábamos una ruta por linea, las cuales estaban formadas por:
Interfaz a la que se aplicaba la ruta – tipo de ruta, ya sea hacia una red (net), hacia una maquina (host)… – IP del destino de la ruta (la red o el host al que se quiere acceder) – Mascara de red de este destino (precedido de la palabra “netmask”) – IP del gateway o puerta de enlace para esta ruta, precedido de la palabra “gw” (esta maquina, actúa como puente o paso intermedio por el que se tiene que pasar para llegar a nuestro destino).

Esto era así hasta que apareció la versión Red Hat 8.0. A partir de esta versión, las rutas estáticas, se deben poner por separado, dependiendo de la interfaz. Es decir, cada ruta irá en un fichero diferente, dependiendo de la interfaz a la que vaya asociada. Estos ficheros se llamarán de la forma interfaz.route (eth0.route, eth1.route, eth2.route, …) e irán situados en el directorio “/etc/sysconfig/networking/devices/”. El formato de estos ficheros deberá ser:

• ADDRESS0 = IP del destino de la ruta 0
• NETMASK0 = Mascara de la subred del destino de la ruta 0
• GATEWAY0 = IP del gateway intermedio para la ruta 0
• ADDRESS1 = IP del destino de la ruta 1
• NETMASK1 = Mascara de la subred del destino de la ruta 1
• GATEWAY1 = IP del gateway intermedio para la ruta 1
• ADDRESS2 = IP del destino de la ruta 2
• etc, etc…

Por lo tanto, en nuestro ejemplo, tendríamos dos ficheros: “/etc/sysconfig/networking/devices/eth0.route” y “/etc/sysconfig/networking/devices/eth1.route”, los cuales contendrían respectivamente:

/etc/sysconfig/networking/devices/eth0.route

• ADDRESS0 = 192.168.3.0
• NETMASK0 = 255.255.255.0
• GATEWAY0 = 192.168.1.2

/etc/sysconfig/networking/devices/eth1.route

• ADDRESS0 = 192.168.4.23
• NETMASK0 = 255.255.255.255
• GATEWAY0 = 192.168.2.2

Si hubiésemos tenido más de una ruta en alguna de las interfaces, bastaría con haberlas metido en el fichero asociado como ADDRESS1, ….

Con esto, ya no se nos perderían las rutas estáticas en nuestro Red Hat/Fedora, aunque solo reiniciasemos el demonio de red.

Actualización: Aparentemente, a partir de la versión 9.0, se deberían utilizar otros ficheros de configuración (aunque con los que he descrito, también funciona perfectamente), ya que los explicados anteriormente son utilizados por las herramientas de configuración de red “redhat-config-network”. Los ficheros que deberíamos utilizar son: “/etc/sysconfig/network-scripts/route-eth0″ y “/etc/sysconfig/network-scripts/route-eth1″, teniendo este formato respectivamente:

/etc/sysconfig/network-scripts/route-eth1

• to 192.168.3.0/24 via 192.168.1.2

/etc/sysconfig/network-scripts/route-eth1

• to 192.168.4.23/32 via 192.168.2.2

Estos ficheros serán pasados como argumentos al comando “/sbin/ip route add”
Si estuviéramos hablando de rutas IPv6, los nombres de ficheros serían: “/etc/sysconfig/network-scripts/route6-eth0″ y “/etc/sysconfig/network-scripts/route6-eth1″.

SuSE 8.x/SuSE 9.0
A partir de la versión 8.0 de la distribución antes alemana (ahora pertenece a Novell), la administración de las rutas estáticas cambió, empezando a manejarse mediante el fichero de texto “/etc/sysconfig/network/routes”. Además, al igual que en Red Hat, también se podía tener un fichero de rutas por cada una de las interfaces, pasando a administrarlas mediante los ficheros “/etc/sysconfig/network/ifroute-eth0″, “/etc/sysconfig/network/ifroute-eth1″, …, dependiendo de la interfaz.
Todos estos ficheros, tienen el mismo formato:

• IP del destino de la ruta 0 – IP del gateway intermedio – Mascara de red – Interfaz que interviene en la ruta 0
• IP del destino de la ruta 1 – IP del gateway intermedio – Mascara de red – Interfaz que interviene en la ruta 1
• IP del destino de la ruta 2 – IP del gateway intermedio – Mascara de red – Interfaz que interviene en la ruta 2

Si alguno de estos parámetros (menos el destino, que no puede omitirse) no lo especificamos, deberemos poner en su lugar el signo “-”.
Por lo tanto, nosotros tendríamos un fichero “/etc/sysconfig/network/routes”:
192.168.3.0 192.168.1.2 255.255.255.0 eth0
192.168.4.23 192.168.2.2 255.255.255.255 eth1

Debian
En Debian es otra historia un poco diferente al resto de las distribuciones, ya que la configuración de rutas estáticas, se debe realizar en el mismo fichero donde se configuran las interfaces de red: “/etc/network/interfaces”.
En este fichero, se puede especificar, que se ejecute un cierto comando antes de levantar la interfaz, un comando una vez ha sido levantada, un comando antes de echarla abajo y/o un comando una vez echada abajo.
Para llevar a cabo esto, haremos uso de las palabras clave:

• pre-up
• up
• down
• post-down

Por lo tanto, nuestro fichero “/etc/network/interfaces”, quedaría de la siguiente manera:

auto lo eth0 eth1
iface eth0 inet static
	address 192.168.1.1
	netmask 255.255.255.0
	network 192.168.1.0
	broadcast 192.168.1.255
	up route add -net 192.168.3.0 netmask 255.255.255.0 gw 192.168.1.2

iface eth1 inet static
	address 192.168.2.1
	netmask 255.255.255.0
	network 192.168.2.0
	broadcast 192.168.2.255
	up route -host 192.168.4.23 gw 192.168.2.2

Slackware
En Slackware, la cosa también es diferente al resto de distribuciones, pareciéndose un poco a la configuración de Debian.
En esta distribución, como en el caso de Debian, hay un único fichero, donde se configuran los parámetros de red de nuestras interfaces y las rutas estáticas de nuestra red. El fichero en cuestión, es “/etc/rc.d/rc.inet1″.
En este fichero, bastará con insertar las rutas directamente con el comando “route” de esta manera:

/sbin/route add -net 192.168.3.0 netmask 255.255.255.0 gw 192.168.1.2 eth0
/sbin/route add -host 192.168.4.23 gw 192.168.2.2 eth1

Creo, que no hace falta decir, que estas rutas, deberían ir (en el fichero /etc/rc.d/rc.inet1) después de haber configurado las respectivas interfaces.

Y con esto ya hemos llegado al final del artículo, habiendo explicado como especificar rutas estáticas en nuestro sistema, sea cual sea la distribución que gastamos (si es Red Hat/Fedora, SuSE, Slackware o Debian).