Instalación y configuración DNS en Ubuntu

El DNS es una base de datos distribuida y jerárquica que almacena información asociada a nombres de dominio en redes como Internet. Aunque como base de datos el DNS es capaz de asociar diferentes tipos de información a cada nombre, los usos más comunes son la asignación de nombres de dominio a direcciones IP y la localización de los servidores de correo electrónico de cada dominio.

Estos son un resumen de los pasos para instalar un servidor DNS en un servidor Ubuntu:

1.-Instalar software

Tenemos que instalar el paquete bind9. Si utilizamos apt-get ejecutamos la siguiente instrucción:

sudo apt-get install bind9

En el caso de que no tengamos disponible la utilidad apt-get tendremos que instalar el paquete y TODAS sus dependencias por el método tradicional:

sudo dpkg -i bind9_9.3.2-2ubuntu1.12_i386.deb

2.- Creación del fichero named.conf.local

Tenemos que editar el siguiente fichero para definir las zonas (nombres de dominio) que queramos configurar:

sudo vi /etc/bind/named.conf.local

E introducimos lo siguiente, reemplazando 2 variables:

– Reemplazamos server.com por el dominio que nosotros deseemos:
– Reemplazamos 0.168.192 por la dirección de la red al revés, por ejemplo, si estuvieramos en una red 10.228.20.x, introduciríamos 0.20.228.10

# This is the zone definition. replace example.com with your domain name
zone "server.com" {
        type master;
        file "/etc/bind/zones/server.com.db";
        };

# This is the zone definition for reverse DNS. replace 0.168.192 with your network address in reverse notation - e.g my network address is 192.168.0
zone "0.168.192.in-addr.arpa" {
     type master;
     file "/etc/bind/zones/rev.0.168.192.in-addr.arpa";
};

3.- Editar el fichero de opciones named.conf.options

sudo vi /etc/bind/named.conf.options

En este fichero sólo tenemos que establecer la dirección IP de nuestros DNS de la red. En el caso de que el servidor DNS que estamos montando no sepa resolver el dominio, reenviará la petición a estos DNS

forwarders {
      # Replace the address below with the address of your provider's DNS server
      123.123.123.123;
	  123.123.123.124;
};

4.- Crear los ficheros de configuración de nuestra zona:

sudo mkdir /etc/bind/zones

Miramos el nombre del fichero que habíamos definido en el fichero /etc/bind/named.conf.local, en nuestro caso es /etc/bind/zones/server.com.db
y cremos el fichero:

sudo vi /etc/bind/zones/server.com.db

En este fichero ya es donde tenemos que definir la equivalencia entre ips y dominios:

;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     server.com. root.server. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@ IN NS  server.com.
server.com IN A 1.1.1.1
server1 IN A 1.1.1.2

IMPORTANTE: Eliminar todos los comentarios de la forma //, A mí me dio problemas. Y ojo también con los “.” después del nombre del dominio, no se pueden eliminar.

El siguiente punto de configuración es crear el fichero de reverse DNS zone, que a partir de una ip nos dirá el dominio.

Nos fijamos en el fichero que habíamos definido en el fichero /etc/bind/named.conf.local, en nuestro caso teníamos: file “/etc/bind/zones/rev.0.168.192.in-addr.arpa”;
Por lo que el fichero sería:

sudo vi /etc/bind/zones/rev.0.168.192.in-addr.arpa
//replace server.com with yoour domain name, ns1 with your DNS server name.
// The number before IN PTR server.com is the machine address of the DNS server. in my case, it's 1, as my IP address is 192.168.0.1.
@ IN SOA ns1.example.com. admin.example.com. (
                        2006081401;
                        28800;
                        604800;
                        604800;
                        86400
)

                     IN    NS     ns1.server.com.
1                    IN    PTR    server.com
120					 IN    PTR    server2

IMPORTANTE: El número “1” que tenemos en la última fila es la dirección de la máquina de la red, por ejemplo, si tenemos un servidor con ip 192.168.0.120, el número que tenemos que poner es 120.

5.- Configurar este DNS en nuestra máquina (/etc/resolv.conf)

Introducimos el nuevo servidor DNS y dejamos también por si acaso el servidor DNS original de nuestra red.

search server.com
nameserver 192.168.0.1
nameserver 1.1.1.1

6.- Reiniciar el servicio bind y probar el servidor DNS

Por último reiniciamos el servicio bind y probamos que funciona.

sudo /etc/init.d/bind9 restart

Hay varias utilizades para saber si funciona: dig, nslookup y ping:

dig server.com
dig server1.server.com
nslookup 192.168.0.1
ping server1.server.com

Referencia:

https://help.ubuntu.com/6.06/ubuntu/serverguide/C/dns.html

https://help.ubuntu.com/community/BIND9ServerHowto

http://es.wikipedia.org/wiki/Domain_Name_System

Publicado en mini-tutorial | Etiquetado | Deja un comentario

Instalación y configuración NFS

El sistema NFS (Network File System) fue desarrollado para permitir montar una partición perteneciente a una máquina remota como si fuese una partición local. Nos proporciona, por tanto, un método rápido y eficaz de compartir archivos y espacio de disco entre distintos ordenadores de una red que soporten este sistema.

1.- Instalación servidor NFS Server Support

Tenemos que instalar esta serie de paquetes: nfs-kernel-server, nfs-common y portmap.
Ejecutamos:
$ sudo apt-get install nfs-kernel-server nfs-common portmap
Si no está disponible apt-get podemos ir instalando los paquetes manualmente. Ejemplo:
sudo dpkg -i portmap_6.0.0-2ubuntu1_i386.deb
Para conocer si está instalado:
dpkg -s nfs-kernel-server
Si no está disponible apt-get podemos ir instalando los paquetes manualmente. Ejemplo:

sudo dpkg -i portmap_6.0.0-2ubuntu1_i386.deb
Para conocer si está instalado:
dpkg -s nfs-kernel-server

2.-Ejecutar el servicio portmap

Tendremos que tener habilitado el servicio portmap. Ejecutamos:

sudo dpkg-reconfigure portmap

Al configurar portmap seleccionar la opción =not= bind loopback.

sudo /etc/init.d/portmap restart

3.- Editar el fichero /etc/exports

El fichero /etc/exports es el fichero que hay que crear para definir los directorios compartidos en el servidor NFS. Lo editamos:

sudo vi /etc/exports

Algunos ejemplos de configuraciones:

For Full Read Write Permissions allowing any computer from 
192.168.1.1 through 192.168.1.255

/files 192.168.1.0/24(rw,no_root_squash,async)

Or for Read Only from a single machine

/files 192.168.1.2 (ro,async)

4.- Arrancar el servicio nfs-kernel-server

sudo /etc/init.d/nfs-kernel-server restart

Después de hacer cambios en el fichero /etc/exports se deben de exportar estos cambios al servidor

sudo exportfs -a

5.- Instalar el cliente de NFS

sudo apt-get install portmap nfs-common

sudo dpkg-reconfigure portmap

Al configurar portmap seleccionar la opción =not= bind loopback.

sudo /etc/init.d/portmap restart

6.- Montar la partición

Para conocer los directorios que podemos montar:

showmount -e "ip-nfs-server"
sudo mount  hostRemoto:/SharedDirectoio /mountDirectory

Posibles problemas

Puede haber algún problema en la comunicación debido al firewall del cliente o servidor.

Se puede comprobar el status del firewall con la orden:

sudo ufw status numbered

El puerto por defecto suele ser el 111

sudo ufw allow 111

Documentación:

http://ubuntuforums.org/showthread.php?t=249889


http://packages.ubuntu.com

Publicado en mini-tutorial | Etiquetado | 1 Comentario

Liferay Developer Training

La última semana de septiembre tuve la suerte de poder asistir a un curso oficial de Liferay en Madrid. El curso en concreto fue el que está más orientado a los desarrolladores: Liferay Developer Training. Fueron 3 días muy intensos pero muy fructíferos, no tenía casi ni idea de liferay y en 3 días sólo te hablan de portlets, hooks, temas, templates, plugins, extensiones, comunidades, etc… Parece un poco lioso y son muchos conceptos los vas asimilando poco a poco.

Lo mejor de todo, sin duda los profesores. Es un lujo poder asistir a un curso en el que las personas que te están enseñando son los ingenieros del core de liferay, que trabajan día a día desarrollando sobre el producto y se conocen la implementación de las clases, cualquier duda, en 5 segundos miran el código fuente y la resuelven. Otra ventaja de que los profesores tengan tan buen conocimiento del producto es que según se avanza en el curso van dando consejos sobre la mejor manera de orientar algún problema típico del desarrollo de portales.

Lo peor, la duración, en 3 días sólo da tiempo a verlo casi todo por encima pero sin profundizar en nada, hubiera sido un lujo seguir 2 días más con algún ejercicio un poco más completo donde se englobaran todos los conceptos explicados en los 3 días anteriores.

La conclusión es que es un curso que a la larga sale muy rentable, y la diferencia con respecto a otros cursos no oficiales es que los profesores trabajan día a día desarrollando el core de Liferay y esto se nota.

Los profesores:

http://www.liferay.com/es/web/julio.camarero

http://www.liferay.com/es/web/juan.fernandez

Publicado en Uncategorized | Etiquetado | 3 comentarios

Backups de repositorios subversion

Si queremos hacer un backup de un repositorio subversion o también por ejemplo exportarlo para importarlo en otro servidor podemos hacerlo fácilmente ejecutando unos simples comandos:

1.- Backup repositorio

$ svnadmin dump /var/svn/repository/  > /var/svn/repository.dump

2.- Mover el repositorio entre máquinas

scp ficheroOrigen userHostRemoto@host:ficheroDestino

3.- Creación del nuevo repositorio

svnadmin create /var/svn/repository

4.- Importar el dump del repositorio en el nuevo servidor svn

svnadmin load /var/svn/repository < repository.dump

Si teníamos también una instancia de Trac asociada a ese repositorio también es posible realizar un backup o hacer una migración al nuevo servidor Trac

1.- Backup de trac

trac-admin /pathToTracEnvironment hotcopy <backupdir>

2.- Mover el backup entre máquinas

Si hay que mover el directorio entre máquina usamos la orden rsync o scp como antes

 rsync -avz /directory userHostRemoto@host:directory

3.- Restaurar el entorno de trac:

1.- Inicializar el entorno

a) trac-admin /pathToEnvironment initenv

b) Copiar los directorios del backup a este nuevo directorio

c) Ejecutar el comando upgrade trac-admin /pathToEnvironment upgrade

d) Cambiar los permisos para que el usuario del apache pueda leer y escribir sobre este directorio
Publicado en mini-tutorial | Etiquetado , | 1 Comentario

Convertir una aplicación web spring-web flow en portlet JSR-168

Crear el archivo portlet.xml

<portlet>
	<portlet-name>sample</portlet-name>
	<portlet-class>org.springframework.web.portlet.DispatcherPortlet</portlet-class>
	<supports>
		<mime-type>text/html</mime-type>
		<portlet-mode>view</portlet-mode>
	</supports>
	<portlet-info>
		<title>Sample Portlet</title>
	</portlet-info>
</portlet>

Modificar archivo web.xml

<servlet>
    <servlet-name>ViewRendererServlet</servlet-name>
    <servlet-class>org.springframework.web.servlet.ViewRendererServlet</servlet-class>
</servlet>

<servlet-mapping>
    <servlet-name>ViewRendererServlet</servlet-name>
    <url-pattern>/WEB-INF/servlet/view</url-pattern>
</servlet-mapping>

Añadir los beans controladores de spring web-flow

<bean id="portletModeControllerMapping" class="org.springframework.web.portlet.handler.PortletModeHandlerMapping">
<property name="portletModeMap">
<map>
<entry key="view" value-ref="flowController" />
</map>
</property>

<property name="interceptors">
<list>
<ref bean="authenticationPortletInterceptor"/>
</list>
</property>
</bean>

<bean id="flowController" class="org.springframework.webflow.executor.mvc.PortletFlowController">
<property name="flowExecutor" ref="flowExecutor" />
<property name="defaultFlowId" value="fwLogin" />
</bean>

<!-- Default View Resolver -->

<bean id="viewResolver" 
class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="cache" value="true"/>
<property name="viewClass" value="org.springframework.web.servlet.view.JstlView"/>
<property name="prefix" value="/WEB-INF/view/"/>
<property name="suffix" value=".jsp"/>
<property name="contentType" value="text/html; charset=UTF-8"/>
</bean>

<!-- Creates the registry of flow definitions for this application -->
<flow:registry id="flowRegistry">
<flow:location path="/WEB-INF/context/flows/**/fw*.xml"/>
</flow:registry>

<!-- Launches new flow executions and resumes existing executions -->
<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="singlekey">
<flow:execution-attributes>
<!-- execution redirects don't apply in a Portlet environment -->

<flow:alwaysRedirectOnPause value="false"/>
</flow:execution-attributes>
</flow:executor>

Modificar las jsps

Cada enlace tendrá que construirse de la forma:

<portlet:renderURL var="mainUrl">
 <portlet:param name="_flowId" value="fwMain" /> 
</portlet:renderURL>

<a href="${mainUrl}">Texto del enlace </a>

Formularios:

<portlet:actionURL var="userSubmitUrl">
 <portlet:param name="_flowId" value="fwUserUpdate" />
 <portlet:param name="_flowExecutionKey" value="${flowExecutionKey}" />
</portlet:actionURL>

<form:form commandName="userUpdate" action="${userSubmitUrl}" method="post" acceptCharset="ISO-8859-1">
 <p>
  <label for="login"><spring:message code="user.update.form.field.login" /></label>
   <form:input cssClass="text" path="login" disabled="true"/>
 </p>
<input class="button" name="_eventId_insert" value="Value" />" type="submit"/>

Para más información consultar la documentación oficial de Spring MVC:

http://static.springsource.org/spring/docs/2.0.x/reference/portlet.html

Publicado en mini-tutorial | Etiquetado , , | Deja un comentario

¿Por qué fracasan los proyectos? Fase I: Captura de requisitos

En este post quería analizar los principales puntos que a mi entender son claves en el fracaso de un proyecto. En esta primera entrada quería centrarme en los fallos que se cometen en la primera fase del proyecto: La captura de requisitos y el análisis.  Los fallos cometidos durante esta fase serán los fallos más graves porque serán arrastrados hasta el último día del proyecto y durante toda la vida útil del software por eso es la fase más importante del proyecto.

Desde mi punto de vista estos son los fallos más comunes:

1.- Análisis de requisitos insuficientes.

Para poder terminar un proyecto es necesario recopilar los requisitos funcionales de éste, si esta captura no se realiza formalmente durante esta primera fase tendrá que hacerse durante la fase de diseño o peor aún durante la fase de desarrollo. Ya hay un término que describe esto: IKIWISI (I’ll know it when i see it). El cliente no sabe lo que quiere o no se le involucró lo suficiente durante la captura de requisitos, y las consecuencias son que el cliente querrá cambiar o añadir nuevos requisitos cuando vea el trabajo ya finalizado, es decir, al final de la fase de desarrollo.

Si la gestión del proyecto se basa en esta anti-metodología IKIWISI del prueba-error será imposible que el proyecto no se retrase y se multipliquen los costes. Si comparamos este proyecto software con un proyecto más simple, por ejemplo, pintar una habitación, en esta anti-metodología el pintor empezaría a pintar la habitación sin que el cliente se involucrase en la decisión de elegir el color. Cuando el pintor haya terminado de pintar 3 paredes en azul se las enseñaría al cliente, y este opinará que el color es muy frío,  preferiría uno más cálido, ahora el pintor si quiere contentar al cliente tendrá que lijar las 3 paredes y decide pintarlas de rojo, cuando ya están terminadas se las enseña de nuevo al cliente, pero por desgracia el rojo le parece demasiado cálido. Después de varios días de tensión porque se multiplican los costes y se retrasa el proyecto, acuerdan pintar la habitación en naranja y cerrar el proyecto. Después de una semana de retraso,  el pintor termina las cuatro paredes en naranja y el cliente por fin está medio contento. Es lo que al final quería, pero tras un retraso considerable, y unos costes que se multiplicaron por 3. Si se hubiese realizado adecuadamente la captura de requisitos, ambos se hubieran ahorrado los retrasos y los sobrecostes.

2.-Cambios frecuentes en los requisitos.

Al no haber un documento  funcional donde se describa lo que se acordó, el cliente tiene total libertad para cambiar los requisitos a su libre albedrío y cuantas veces quiera. Si hubiese un documento formal donde se describan los requisitos sería mucho más fácil para el jefe de proyecto oponerse a estos cambios, si no tiene nada, al final acabará cediendo a todos los cambios y nuevos requisitos porque no tiene a qué agarrarse.

3.-Planificación no realista.

Incluso teniendo en cuenta el mejor de los casos, donde hay un análisis de requisitos bien documentado, no se suelen tener en cuenta muchas series de factores que van a influir seguramente en la planificación. Estos factores pueden ser: vacaciones del personal, fiestas, posibles bajas, posibles inclemencias del tiempo, fallos técnicos, etc…

Para contrarrestar estos imprevistos los jefes de proyecto pueden añadir más presión al equipo de programadores, pero esto será sólo un parche y no conseguirá hacer mejor software mediante esta estrategia, aparte de otros muchos inconvenientes que pueda tener. Los programadores bajo presión trabajan más rápido, pero no trabajan mejor.

“People under time pressure don’t work better; they Just work faster.”

Tom DeMarco & Timothy Lister.

Referencias:

http://www.joelonsoftware.com/articles/fog0000000036.html

http://www.joelonsoftware.com/articles/PickingShipDate.html

https://garciagonzalezdavid.wordpress.com/2008/08/12/the-art-of-project-management/

https://garciagonzalezdavid.wordpress.com/2006/10/31/peopleware-productive-projects-and-teams/

http://es.wikipedia.org/wiki/The_Mythical_Man-Month

Publicado en Gestión | Etiquetado | Deja un comentario

Las oficinas de Fog Creek

¿Cuándo podremos ver en España unas oficinas como las de Joel Spolsky? Si las comparo con la mía me deprimo, (y eso que he según lo que hay por aquí no me puedo quejar).

Resumiendo, todos los puestos en esta oficina tienen las siguientes características:

  • Todas las oficinas son privadas, para que te concentres en el código y no interrumpan todo el tiempo. Aquí en España lo más normal es que haya gente hasta en los pasillos con mesas supletorias. Además, todas tienen ventanas para que te relajes con las buenas vistas de Nueva York.
  • Mesa motorizada ajustable en altura, para trabajar de pie si me da la gana. Aquí te tienes que conformar con lo justo para el portátil.
  • Monitores de 30″, incluso algunos puestos tienen hasta 2 monitores. Y yo pasándome 8 horas con un portátil de 15,4″.
  • Comedor gratuito, bonito y espacioso para comer todo el mundo a la vez. Se acabó eso de llevar tuppers.
  • Coffee bar gratuíto. Fruta en todos los puestos, snacks, una nevera llena de bebidas. Mirar las fotos y comparad.
  • Biblioteca
  • Varias salas de reuniones de diferentes tamaños. Allí no se pelean por resevar la sala.

Bueno, sólo quería demostrar que son diferentes las cosas allí y aquí, y espero que poco a poco aquí vayamos cogiendo todo lo bueno de allá y no al revés.

Oficinas de Fog Creek en Nueva York

Oficinas de Fog Creek en Nueva York

Para más información: el blog de Joel Spolsky y el álbum de Picasa con las fotos de las oficinas.

Publicado en Gestión | Etiquetado | 3 comentarios