En este número encontré los siguientes artículos de interés:
Instalar GRUB en una partición y no en el Master Boot Record.
Links de descargas
Consulta aquí para los números anteriores.
Comencé a conocer un poco más sobre este mundo llamado Ruby y me he quedado
bastante sorprendido. Al parecer es un problema recurrente el tema de las gemas y ubuntu. Por lo tanto paso a explicar mi experiencia y cómo lo solucione. Se pueden encontrar muchas explicaciones por Internet,
pero ninguna simple y concisa.
Tengo en cuenta que tienen ya instalado Ruby. Sólo me enfocaré en las Rubygems. Para esto lo primero crear nuestro propio repositorio de gemas. Por ejemplo
$ mkdir -p /home/user/.rubygems/repos
Una vez creada la ubicación de nuestro repositorio bajaremos el código fuente de RubyGems y lo instalaremos en la ubicación creada anteriormente (/home/user/.rubygems). Podemos encontrar las distintas versiones de RubyGems en RubyForge. Utilizo la versión 1.0.1 para ejemplificar la instalación y posterior explicación. Es muy probable que cuando lea este post se encuentre una versión más reciente de RubyGems.
$ wget http://rubyforge.org/frs/download.php/29548/rubygems-1.0.1.tgz
$ tar xzvf rubygems-1.0.1.tgz
$ cd rubygems-1.0.1
$ ruby setup.rb all --prefix=/home/user/.rubygems
El comando anterior instalará RubyGems y creará dentro de .rubygems dos carpetas (bin y lib), la importante aquí es bin, que es donde se encuentra el ejecutable de RubyGem
Nota: la instalación la estamos realizando en /home/user/.rubygems y no en /home/user/.rubygems/repos. Porque sólo estamos instalando RubyGems y no los gems.
Si verifican dentro de la carpeta bin el ejecutable se llama gem1.8, para comodidad he decidido hacer un link simbólico llamado gem
$ ln -s ./gem1.8 ./gem
Felicitaciones tenemos instalado RubyGems, pero ahora falta definir para el resto de las aplicaciones dónde está RubyGems y dónde el repositorio. Se logra definiendo las siguientes variables de entorno GEM_HOME y PATH
Nos valdremos del comando export para definirlas
$ export GEM_HOME=/home/user/.rubygems/repos
$ export PATH=$PATH:/home/user/.rubygems/bin
$ export PATH=$PATH:/home/user/.rubygems/repos/bin
Expliquemos un poco lo que hemos hecho para los más despistados. Aquí hemos definido en dónde esta el repositorio de gemas, por lo tanto, todo programa que utilice gemas sabrá en dónde se encuentran. El segundo export hemos exportado la ejecución del RubyGems (gem) desde cualquier lado. El último export permite ejecutar alguna gema en particular (e.g. rails).
Nota: Para que las nuevas variables sean leídas hay que utilizar el siguiente comando:
$ source ~/.bashrc
Veamos un ejemplo. Si no hubiese definido las variables anteriores y realizo lo siguiente:
$ cd /home/a/un/lugar/lejos
$ gem
El programa «gem» no está instalado actualmente. Puedes instalarlo escribiendo:
sudo apt-get install rubygems
Compruebe que tiene el componente 'universe' activado
bash: gem: orden no encontrada
Aparece como si no estaría instalado; el sistema no sabe en dónde hemos instalado RubyGems (/home/user/.rubygems/bin). Por lo tanto, al “exportar” esta ubicación podemos ejecutar RubyGems desde cualquier lado, sin que sea necesario estar dentro de /home/user/.rubygems/bin
Y por último si no hubiésemos definido el GEM_HOME el sistema no sabría en dónde están las gemas. Entonces por ejemplo si ejecutásemos RubyGems para instalar una gema, éste no sabría en dónde
instalarlo. Y sucedería lo siguiente
$ gem install rails
Bulk updating Gem source index for: http://gems.rubyforge.org
ERROR: While executing gem ... (Gem::FilePermissionError)
You don't have write permissions into the /usr/bin directory.
Una vez definida nuestras variables de entorno podemos hacer lo siguiente
$ gem install rails
Bulk updating Gem source index for: http://gems.rubyforge.org
Successfully installed rake-0.8.1
Successfully installed activesupport-2.0.2
Successfully installed activerecord-2.0.2
Successfully installed actionpack-2.0.2
Successfully installed actionmailer-2.0.2
Successfully installed activeresource-2.0.2
Successfully installed rails-2.0.2
7 gems installed
Installing ri documentation for rake-0.8.1...
Installing ri documentation for activesupport-2.0.2...
Installing ri documentation for activerecord-2.0.2...
Installing ri documentation for actionpack-2.0.2...
Installing ri documentation for actionmailer-2.0.2...
Installing ri documentation for activeresource-2.0.2...
Installing RDoc documentation for rake-0.8.1...
Installing RDoc documentation for activesupport-2.0.2...
Installing RDoc documentation for activerecord-2.0.2...
Installing RDoc documentation for actionpack-2.0.2...
Installing RDoc documentation for actionmailer-2.0.2...
Installing RDoc documentation for activeresource-2.0.2...
Nos crearía dentro de /home/user/.rubygems/repos ($GEM_HOME) los directorios: cache, doc, gems, specifications. Dentro gems, estará la gema rails y sus dependencias.
Nota: Con la variable de entorno GEM_HOME, podemos definir más de un repositorio de gemas, en caso de que tengamos múltiples repositorios, tendríamos que hacer: export GEM_HOME=$GEM_HOME:/hacia/el/otro/repositorio
Las variables establecidas anteriormente no son persistentes, o sea, deberíamos definirlas cada vez que reiniciamos la computadora. Para persistirlas:
$ echo "export GEM_HOME=/home/user/.rubygems/repos" >> /home/user/.bashrc
$ echo "export PATH=$PATH:/home/user/.rubygems/bin" >> /home/user/.bashrc
$ echo "export PATH=$PATH:/home/user/.rubygems/repos/bin" >> /home/user/.bashrc
Otra comprobación de las variables es con el comando
$ gem env
RubyGems Environment:
- RUBYGEMS VERSION: 1.0.1 (1.0.1)
- RUBY VERSION: 1.8.5 (2006-08-25) [i486-linux]
- INSTALLATION DIRECTORY: /home/user/.rubygems
- RUBY EXECUTABLE: /usr/bin/ruby1.8
- RUBYGEMS PLATFORMS:
- ruby
- x86-linux
- GEM PATHS:
- /home/user/.rubygems
- GEM CONFIGURATION:
- :update_sources => true
- :verbose => true
- :benchmark => false
- :backtrace => false
- :bulk_threshold => 1000
- REMOTE SOURCES:
- http://gems.rubyforge.org
Como nota el procedimiento anterior soluciona los siguientes problemas al ejecutar Netbeans 6 en Debian (o Ubuntu)
Trabajando
en un proyecto utilizando las tecnologías JSP y Java, necesitaba
tenerlo en línea , por lo que levanté un Tomcat 5.5 en un Debian Etch,
toda la instalación y configuraciones no tuvieron mayores dificultades.
Pero cuando subía el WAR a través del Manager de Tomcat, no me desplegaba la aplicación, trate copiando directamente el war en /var/lib/tomcat5.5/webapps,
pero seguía con el mismo problema, no me reconocía el war y no me
dejaba ejecutarlo. Después de varios días investigando, encontré la
solución, no es una solución muy ingenieril, pero resuelve el problema
:-D.
WAR: Es un formato de archivo desarrollado por SUN,
que agrupa (agrega) todos los archivos de la aplicación en un único
archivo, bajo una estructura bien definida. Este archivo tiene una
estructura similar al JAR, pero se usa especialmente para archivos JSP, servelets, XML y otros objetos. Más información
El problema parece ser que viene del lado de los privilegios y la
seguridad del Tomcat, por esto al entrar al archivo de configuración (/etc/default/tomcat5.5)
y modificar una de sus variables, para deshabilitar la seguridad, pude
lograr que me desplegara la aplicación sin problemas. Acá dejo la
variable específica con el valor modificado
# Use the Java security manager? (yes/no, default: yes)
# WARNING: Do not disable the security manager unless you understand
# the consequences!
# NOTE: java-gcj-compat-dev currently doesn't support a security
# manager.
TOMCAT5_SECURITY=no
Recordar que una vez modificada, es necesario reiniciar Tomcat, /etc/init.d/tomcat5.5 restart.
Si alguien sabe como solucionar esto de una mejor manera, por favor
contactemé. De todos modos, si la encuentro antes prometo postearla.
La explicación se basará en una versión superior a la 1.5 y teniendo en cuenta que se ha instalado satisfactoriamente.
Tendremos que editar el archivo LocalSettings.php (el cual se debería encontrar en la carpeta donde instalamos MediaWiki) y agregar al final de él la siguiente línea
$wgGroupPermissions['*']['createaccount'] = false;
Ahora si tratamos de registrarnos, nos dirá que no hay un usuario con dicho nombre
Para terminar explicaré como habilitar la extensión para la confirmación de cuentas para esto haceremos
Iremos a la carpeta de extensiones (extensions) y por medio de svn bajaremos la extensión desde el repositorio de wikimedia
cd extensions
svn checkout http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/ConfirmAccount/
Ahora deberemos correr un script (en /extensions/ConfirmAccount)
para crear ciertas tablas en nuestra base de datos, para esto en
función de la base de datos que estemos usando, es el que tendremos que
correr:
Si en la instalación hemos modificado el prefijo de las tablas,
tendremos que indicarlo en el script. Para saber el prefijo y los datos
sobre la base de datos (especificados durante la instalación) podemos
revisar el archivo LocalSettings.php y encontraremos lo siguiente
$wgDBtype = "mysql";
$wgDBserver = "192.168.1.111";
$wgDBname = "wikidb";
$wgDBuser = "wikiuser";
$wgDBpassword = "123";
# MySQL specific settings
$wgDBprefix = "miPrefijo";
Por ejemplo, habría que reemplazar las ocurrencias /*$wgDBprefix*/ por el valor que tiene la variable wgDBprefix en nuestro LocalSettings.php, en mi caso es miPrefijo. Aquí dejo las partes puntuales que habría que modificar del script
-- This stores all of our reviews,
-- the corresponding tags are stored in the tag table
CREATE TABLE /*$wgDBprefix*/account_requests (
acr_id int unsigned NOT NULL auto_increment,
-- This stores all of credential information
-- When accounts are confirmed, the identity info goes here
CREATE TABLE /*$wgDBprefix*/account_credentials (
— Revision ID #
acd_id int unsigned NOT NULL auto_increment,
FInalizada la modificación de los script faltaría sólo correrlos para esto nos posicionaremos en la carpeta de la extensión (extensions/ConfirmAccount) y ejecutamos
mysql -D wikidb -u wikiuser -h 192.168.1.111 < ConfirmAccount.sql
Los valores de los parámetros D, u y h, se encuentran definidos en el archivo LocalSettings.php
include_once('extensions/ConfirmAccount/SpecialConfirmAccount.php');
## For more information on customizing the URLs please see:
## http://www.mediawiki.org/wiki/Manual:Short_URL
$wgEnableEmail = true;
$wgEnableUserEmail = true;
$wgEmergencyContact = “algo@mail.org”;
$wgPasswordSender = “algo@mail.org”;
Aquí dejo como se modifica la página de registración y la nueva página para solicitar una cuenta al wiki
Uno de los datos que se deben llenar en la solicitud de la cuenta, es una bibliografía personal
que conste de 50 palabras. Según la seriedad de nuestro wiki esto puede
ser mínimo, justo o demasiado. Para alterar la cantidad de palabras hay
que editar la variable wgAccountRequestMinWords en el archivo SpecialConfirmAccount.php (en extensions/ConfirmAccount). En este caso lo modifiqué a 25 palabras.
# Minimum biography specs
$wgAccountRequestMinWords = 25;
Luego de varios días con depresiones derivadas de no encontrar una solución. Pude resolverlo, comparto aquí la solución.
Básicamente el problema es que al crear usuarios virtuales y luego tratar de conectarnos al servidor, nos falla el login.
pet@gatsu:/etc/pure-ftpd/conf# ftp localhost
Connected to localhost.
220---------- Welcome to Pure-FTPd [privsep] [TLS] ———-
220-You are user number 1 of 50 allowed.
220-Local time is now 02:58. Server port: 21.
220-This is a private system - No anonymous login
220-IPv6 connections are also welcome on this server.
220 You will be disconnected after 15 minutes of inactivity.
Name (localhost:alejandro): usuarioPedrito
331 User usuarioPredrito OK. Password required
Password:
530 Login authentication failed
Login failed.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
Y por más que cambiemos el password, el problema persiste.
Esto se debe a que Pure-ftp no esta utilizando el sistema de
autentificación para usuarios virtuales. Para solucionarlo, debemos ir
al directorio de autentificaciones /etc/pure-ftpd/auth. Aquí debemos encontrar dos links.
lrwxrwxrwx 1 root root 26 2006-10-25 12:42 65unix -> ../conf/UnixAuthentication
lrwxrwxrwx 1 root root 25 2006-10-25 12:42 70pam -> ../conf/PAMAuthentication
Estos links llevan a archivos de configuración para los diferentes
sistemas de autentificación que utiliza pure-ftp. Como puede verse, no
hay nada referido a nuestros usuarios virtuales, sólo sobre
autentificación de Unix y PAM. Otra cosa relevante de estos link es el
numero que se antepone al nombre. Pure-ftp prueba primero el sistema de autentificación de menor número.
Entonces simplemente tendremos que hacer un link al archivo PureDB
(archivo que maneja los usuarios virtuales) y el número en el nombre
del link, debe ser menor que los anteriores. Para esto, nos situamos en
la carpeta /etc/pure-ftpd/auth y ejecutamos el comando
ln -s ../conf/PureDB 50pure
Finalmente reiniciar el servidor.
/usr/share/doc/pure-ftpd/README.Debian
Para
agregar un calendario similar al de Wikipedia a nuestro wiki, tenemos
que hacer lo siguiente. Cuando editemos un página en la que queremos
agregar el calendario, ponemos lo siguiente:
{calendario}
Ahora cuando veamos la imagen, nos debería salir un link con nombre Plantilla:Calendario,
el cual si lo presionamos nos lleva a una página no existente en
nuestro wiki. Esta página que no tenemos definida es la que maneja el
estilo del calendario. Por lo que simplemente escribimos el estilo para
nuestro calendario:
<div style="border:solid #ccc; background: #fff; border-width: 1px 3px 3px 1px; text-align: center; padding-top:3px; float:left; font-size: smaller; line-height: 1.3; margin-right: 4px; width: 7em">
[[{{CURRENTDAY}} de {{CURRENTMONTHNAME}}|<span style="display: block;">{{CURRENTDAYNAME}}</span>
<span style="font-size: x-large; width: 100%; display: block; padding:6px 0px">{{CURRENTDAY}}</span>
<span style="display: block;"> {{CURRENTMONTHNAME}}</span>]]
<span style=”background: #aaa; color: #000; display: block;”>”’[[{{CURRENTYEAR}}]]”’</span>
</div><noinclude>
Finalmente guardamos la página y volvemos a cargar la anterior, en la que habíamos agregado {calendario}, nos debería aparecer algo similar a la siguiente imagen.
Es la respuesta de KDE a un escritorio semántico. Consiste en un framework para crear y consultar meta datos de cualquier tipo de recurso, por ejemplo un archivo. Dentro de los meta datos podemos encontrar tres tipos.
En los últimos es donde podemos encontrar el verdadero poder del escritorio semántico. Plantemos tres ejemplos:
Nepomuk esta compuesto principalmente por Soprano, Stringi y KMetaData. Soprano es un framework orientado a objetos para datos RDF y Strigi es un pequeño y simple demonio de búsqueda portable.
KMetaData es una librería que facilita el acceso a los metadatos a través de wrapper de los mismos. Por lo tanto, manipulamos objetos de clases de recursos.
El papel que cumple Soprano es poder bajar el acoplamiento entre nuestros datos RDF y Nepmuk. De esta manera podemos tener un enfoque cliente/servidor y colocar nuestros repositorio de datos RDF remotamente. Además cuenta con una interface para comunicaciones TCP (dentro de otras), es posible tener un repositorio en cualquier parte del mundo. Se podría pensar en la idea de conectarse no con uno, sino con varios. Aquí entra mucho en juego, al tener muchos repositorios, podríamos especializarlos, por ejemplo tener un repositorio especial para programadores y proyectos. Entonces el usuario programador al leer el código fuente de su aplicación favorita, tendría información sobre el perfil de los programadores que la desarrollaron.
Strigi es el encargado de indexar y consultar datos disponibles en el disco. Pero la ventaja de Strigi es su sistema JStream, el cual le permite revisar e indexar contenido de los archivos. Por ejemplo podría obtener la duración de un archivo de audio o obtener todos los meta datos disponibles en el contenido de un archivo PDF. JStream esta limitado en estos momentos a un número reducido de tipos de archivos, los más elegante para mi gusto son:
Se podría aumentar ampliamente el potencial de administradores de paquetes, por ejemplo aptitude hace un amplio uso de la rica meta información contenida en los paquetes .deb, el hecho de poder darle un valor semántico, facilitaría las resoluciones de dependencias o conflictos de aptitude. Incluso antes de resolver con determinado conflicto (por lo general pide confirmación al usuario), podría consultar meta información propia del usuario y poder inferir la confirmación del usuario para resolver el conflicto…
Strigi hace uso del subsistema inotify del kernel de Linux. Inotify notifica sobre eventos sobre el sistema de archivos. De esta manera, Strigi puede aprovecharlo para reindexar archivos modificados y ahorrar estar haciendo búsquedas frecuentes por todo el sistema de archivos. Aquí las aplicaciones podrían generar muchos meta datos en relación a log del sistema y como los log son archivos de texto plano se puede aprovechar JStream para obtener más relaciones entre los datos.
En este video se puede ver el potencial de Nepomuk.
Muchas
veces tenemos problemas al olvidarnos la contraseña de root de Mysql o
tomar la administración de un sistema en ejecución, donde el personal
no tiene documentado las usuario y contraseñas de Mysql. Estos
problemas pueden ser solucionados sin reinstalar Mysql, a través de un
modo de ejecución del servidor que salta los privilegios. De esta
manera podemos logearnos como root sin tener su contraseña y poder
modificar la vieja contraseña. Aquí comparto los pasos para lograrlo,
la explicación se basa en Debian y Ubuntu, en otras distribuciones
podría llegar requerir modificar los paths, pero el concepto es el
mismo.
Como primer paso paramos el servidor Mysql.
# /etc/init.d/mysql stop
Ahora levantaremos el servidor sin privilegios. Para esto simplemente ejecutaremos el binario mysqld_safe pasandole como parámetro skip-grant-table. El ampersand al final indica que se ejecute el proceso en segundo plano.
# /usr/bin/mysqld_safe --skip-grant-table &
[1] 14836
mysql -u root
mysql>use mysql;
Para modificar el password, debemos actualizar el registro del
usuario root. Los registros de los usuarios se encuentran en la tabla user. Así que simplemente haremos un update modificando el campo Password.
update user set Password=PASSWORD('Nuevo_Password') where User='root';
Nota: Respetar las mayúsculas.
Finalmente matamos el proceso anterior y volvemos a levantar el servidor.
# kill -9 14836
# /etc/init.d/mysql start
La forma más sencilla es a través de los Template,
para esto sólo tendremos que editar unas propiedades y crear un archivo
con la licencia. La explicación se basa en la versión 6.0.1 de Netbeans.
Antes que nada debemos elegir (o definir) la licencia que utilizaremos, en mi caso utilizaré GPL 2.0. En la página de la GNU podemos encontrar un ejemplo que podremos agregar a nuestro código. Aquí dejo el ejemplo.
Copyright (C) yyyy name of author
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
El texto de la licencia debería estar encerrada entre delimitadores de
comentarios, según el lenguaje de programación que utilicemos en el
proyecto. Por ejemplo en un proyecto Java, tendríamos que encerrarlo
entre /* */.
Una vez elegida nuestra licencia, tenemos que escribirla en un archivo de texto plano (.txt) y guardarla con un nombre que siga a la siguiente sintaxis: license-mylicense.txt, en donde mylicense pueden poner el nombre que les parezca. Este nombre nos servirá luego para identificar a la licencia.
Ahora hay que abrir netbeans, luego nos vamos a Tools->Templates, nos aparecerá una ventana, en la que se administra los Templates, debemos buscar una carpeta/template que diga Licenses, le damos un click y tocamos el botón Add. Ahora tan sólo tendremos que buscar el archivo que creamos anteriormente y listo.
Tenemos que indicar al proyecto qué licencia utilizaremos.
Simplemente hay que agregar una variable en el archivo de propiedades
del proyecto. Nos vamos a la carpeta donde tenemos nuestro proyecto,
dentro hay una carpeta llamada nbproject y dentro de ésta el archivo que tenemos que editar project.properties. Al final del archivo agregamos la siguiente variable project.license y el valor de ésta es el nombre del archivo de la licencia después del license-. Nos quedaría siguiendo con el ejemplo del nombre que le colocamos.
project.license=mylicense
Ahora cada vez que creemos una clase (por ejemplo en un proyecto Java) se nos agregará al comienzo la licencia.
Voy a explicar a través de mi experiencia como podemos compartir un disco en una LAN,
no es nada novedos, pero la información se encuentra a veces dispersa
en internet. Además hay muchas cosas que no son explicadas, por eso
aquí trato de cubrir esos asuntos y hacer un resumen.
Nota: En el post utilizo indebidamente la palabra formatear. La uso en el sentido de crear un sistema de archivos (formateo lógico).
Decidí utilizarla, ya que es la que habitualmente se utiliza para
referirse a la creación de un sistema de archivos, pero en realidad
está definición no es exacta. Formatear es darle formato al disco de
forma física.
Una vez que conectamos el disco y arrancamos el sistema. Abrimos una consola y con superusuario hacemos.
# fdisk -l
Esto nos devolverá una lista de las particiones de cada disco. Con
esto obtendremos cual es el nombre del dispositivo. El disco en
cuestión es de 80 GB.
Disco /dev/sda: 80.0 GB, 80026361856 bytes
255 cabezas, 63 sectores/pista, 9729 cilindros
Unidades = cilindros de 16065 * 512 = 8225280 bytes
El disco /dev/sda no contiene una tabla de particiones válida
Disco /dev/sdb: 300.0 GB, 300069052416 bytes
255 cabezas, 63 sectores/pista, 36481 cilindros
Unidades = cilindros de 16065 * 512 = 8225280 bytes
Disposit. Inicio Comienzo Fin Bloques Id Sistema
/dev/sdb1 * 1 36293 291523491 83 Linux
/dev/sdb2 36294 36481 1510110 5 Extendida
/dev/sdb5 36294 36481 1510078+ 82 Linux swap / Solaris
Disco /dev/sdc: 250.0 GB, 250059350016 bytes
255 cabezas, 63 sectores/pista, 30401 cilindros
Unidades = cilindros de 16065 * 512 = 8225280 bytes
Disposit. Inicio Comienzo Fin Bloques Id Sistema
/dev/sdc1 1 30401 244196001 83 Linux
Una vez identificado el nombre del dispositivo (/dev/sda) procedemos a formatearlo. Utilizaremos el sistema de archivos ext3 y la herramienta mke2fs para el cometido.
Es importante notar que sólo podemos formatear si el dispositivo en cuestión se encuentra desmontado.
# mkfs.ext3 /dev/sda
mke2fs 1.40-WIP (14-Nov-2006)
¡/dev/sda es todo el dispositivo, no sólo una partición!
¿Se continúa de todas formas? (s,n) s
Etiqueta del sistema de ficheros=
Tipo de SO: Linux
Tamaño del bloque=4096 (bitácora=2)
Tamaño del fragmento=4096 (bitácora=2)
9781248 nodos i, 19537686 bloques
976884 bloques (5.00%) reservados para el súper usuario
Primer bloque de datos=0
Número máximo de bloques en el sistema de archivos=0
597 bloque de grupos
32768 bloques por grupo, 32768 fragmentos por grupo
16384 nodos i por grupo
Respaldo del súper bloque guardado en los bloques:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424
Mientras se escribían las tablas de nodos i: terminado
Creando el fichero de transacciones (32768 bloques): hecho
Escribiendo superbloques y la información contable del sistema de ficheros: hecho
Este sistema de ficheros se revisará automáticamente cada 37 meses o
180 dias, lo que suceda primero. Utilice tune2fs -c o -i para cambiarlo.
Nota: podríamos haber utilizado para formatear a ext3 el siguiente comando: mke2fs -j <dispositivo>
Para poder utilizar el disco (con su sistema de archivo) debemos montarlo. Antes que nada y siguiendo el buen dicho: “Prevenir antes que curar”. Vamos a hacer una copia de resguardo de un archivo muy delicado, fstab. Para esto bastará un simple.
# cp /etc/fstab /etc/fstab.backup
Ahora sigamos; debemos crear un punto de montaje para poder colgar
el disco a nuestro sistema de archivos y luego debemos editar la fstab para indicar al sistema que cuelgue el disco al punto de montaje especificado.
$ mkdir /mnt/sda
$ chmod 777 /mnt/sda
# echo "/dev/sda /mnt/sda ext3 defaults 0 0" >> /etc/fstab
# mount -a
Al fstab, le estamos especificando:
Fstab describe los diferentes sistemas de archivos del
equipo. Cada sistema se define en una linea. Una linea está formada por
campos separadados por espacio o tabulador.
Creamos el punto de montaje en /mnt/sda y agregamos al fstab las ordenes para montarlo y luego con la opción a de mount indicamos que se monten todos los sitemas de archivos especificados en fstab.
Ahora instalaremos el servidor NFS
aptitude install portmap nfs-kernel-server nfs-common
Detallemos un poco está instalación, para que no sea un vulgar copy & paste
Nota: El kernel tiene que soportar NFS,
para eso debe estar compilado con esa característica. Podemos verificar
que el núcleo está compilado con soporte para NFS, haciendo cat /proc/filesystems. La salida nos muestra los sistemas de archivos que soporta el núcleo, dentro de estos debe figurar nodev nfs.
Una vez finalizada la instalación, tenemos que indicar al servidor
que carpetas queremos compartir que exporte a nuestros clientes. Para
esto debemos editar el archivo exports. Este archivo es un ACL, por esto tenemos que definir quién puede acceder al recurso y cómo
# echo "/mnt/sda 192.168.2.0/24(rw,sync,no_root_squash)” >> /etc/exports
Expliquemos un poco lo anterior. La sintaxis es sencilla tenemos. <recurso> <cliente>(<opciones>). El recurso es el disco montado, el cliente nuestra LAN y las opciones para esos clientes, donde especificamos:
Ahora debemos hacer notar de estas modificaciones al servidor NFS, para eso lo alertamos con
# exportfs -a
Eso sería suficiente por el lado del servidor, nos pasamos al lado del cliente. El cliente debe tener instalado los paquetes portmap y nfs-common, en caso que no se encuentren instalados:
# aptitude install portmap nfs-common
Ahora tenemos que montar el disco que compartimos desde el servidor. Para esto debemos tener la
siguiente información:
Antes de montarlo, crearemos un punto de montaje e indicaremos el recurso a montar, en este caso el disco sda del servidor, supondremos que la dirección IP del servidor es, 192.168.2.1.
$ mkdir disco_remoto
# echo "192.168.2.1:/mnt/sda /disco_remoto nfs rw,defaults 0 0" >> /etc/fstab
# mount -a
Ahora podemos hacer algunas pruebas para verificar que esté todo correcto. Del lado del servidor ejecutamos el comando exportfs, nos mostrará un listado de los sistemas de archivos exportados.
$ exportfs
/mnt/sda 192.168.2.0/24
La ip 192.168.2.159 es la dirección IP de la máquina cliente en la que acabamos de montar el disco.
Del lado del cliente podemos utilizar el comanto showmount con la opción e, la cual despliega la lista de sistemas de archivos exportados por un determinado servidor.
$ showmount -e 192.168.2.1
Export list for 192.168.2.1:
/mnt/sda 192.168.2.0/24
Nota: Durante toda la explicación se dio a entender implícitamente que la máquina servidor no se encontraba detrás de un firewall. En el caso que se encuentre detrás del firewall, deberemos abrir los siguientes puertos: 2049 TCP/UDP para nfsd y 111 TCP/UDP para portmap. Para el resto de los demonios hay que definir un rango de IP’s, para mayor información consultar aquí.