Lo que en principio se nos antoja como una buena práctica, en la mayoría de las ocasiones, debido a una utilización mal estructurada del fichero de configuración, se convierte en una lista incontrolable y sin organización alguna de entradas en el nodo appSettings.

Para evitar esto existe una solución alternativa, más elegante, más clara y, más optima. Las clases ConfigurationSection, ConfigurationElement y ConfigurationElementCollection permiten definir secciones, elementos y colecciones de elementos en el fichero de configuración y utilizarlas como cualquier otro objeto en nuestro aplicativo.

Vamos a definir una pequeña sección en el fichero de configuración y comentamos un poquito cómo realizarla.

La clase EjemploData heredará de ConfigurationElement y tendrá dos propiedades Name y PropiedadBooleana, de tipo string y bool respectivamente. Las propiedades de ambas deberán tener el atributo ConfigurationProperty con el nombre que tomará en el fichero de configuración, su valor por defecto (si queremos especificarlo) y si es obligatoria.

public class EjemploData : ConfigurationElement
    {
        #region Public Properties
 
        private const string NamePropertyName = "name";
 
        [ConfigurationProperty(NamePropertyName, IsRequired = true)]
        public string Name
        {
            get { return this[NamePropertyName].ToString(); }
            set { this[NamePropertyName] = value; }
        }
 
        private const string PropiedadBooleanaPropertyName = "propiedadBooleana";
        [ConfigurationProperty(PropiedadBooleanaPropertyName, DefaultValue = "true", IsRequired = false)]
        public bool PropiedadBooleana
        {
            get { return (bool)this[PropiedadBooleanaPropertyName]; }
            set { this[PropiedadBooleanaPropertyName] = value; }
        }
 
        #endregion
    }

Crearemos una clase EjemploDataCollection que herede de ConfigurationElementCollection, tal y como se muestra, no requiere mucha explicación

public class EjemploDataCollection : ConfigurationElementCollection
{
#region ConfigurationElementCollection Members
 
protected override ConfigurationElement CreateNewElement()
{
return new EjemploData();
}
 
protected override object GetElementKey(ConfigurationElement element)
{
return ((EjemploData)element).Name;
}
 
public EjemploData this[int index]
{
get
{
return (EjemploData)BaseGet(index);
}
set
{
if (BaseGet(index) != null)
{
BaseRemoveAt(index);
}
BaseAdd(index, value);
}
}
 
#endregion
}

Finalmente, crearemos la clase que nos permita manejar este tipo de objetos. Esta clase debe heredar de ConfigurationSection, la cual nos servirá para marcar el ámbito en el cual obtendremos los valores dentro del fichero de configuración. Debe tener:

• Una constante pública que nos indique cómo llegar a la sección adecuada del fichero de configuración.
• Constantes privadas que nos marquen cómo se llamarán los atributos.
• Nodos hijos que podremos definir en el fichero de configuración
• Sus respectivas propiedades públicas que nos permitirán utilizarlas en cualquier parte de nuestro aplicativo.

En nuestro ejemplo definiremos la seccion como “oxxigeno/ejemploSettings”, lo que significa que en el fichero de configuración tendremos que definir un nodo oxxigeno y dentro uno ejemploSettings.

Queremos que exista una atributo en el nodo ejemploSettings, para lo cual crearemos una constante privada que nos diga como debe llamarse, “nuevaPropiedad”, y una propiedad pública que nos permita recuperarlo del fichero de configuración y utilizarlo en el aplicativo. Para ello crearemos una propiedad normal que nos devolverá un objeto de tipo string y le establecemos un atributo a la propiedad de tipo ConfigurationProperty, que indique cómo se va a llamar ese atributo en el fichero de configuración y si es obligatorio o no que exista.

Además nos interesa que bajo el nodo ejemploSettings exista una colección de nodos del mismo tipo (en nuestro caso EjemploData). Para ello procederemos igual que para la propiedad actual, pero definiremos su salida como EjemploDataCollection, y le agregaremos el atributo ConfigurationCollection pasándole como parámetro el tipo de objetos que se coleccionarán.

public sealed class EjemploSettings : ConfigurationSection
{
 
public const string SectionName = "oxxigeno/ejemploSettings";
 
#region Public Properties
 
private const string NuevaPropiedadPropertyName = "nuevaPropiedad";
 
[ConfigurationProperty(NuevaPropiedadPropertyName, IsRequired = true)]
public string NuevaPropiedad
{
get { return this[NuevaPropiedadPropertyName].ToString(); }
set { this[NuevaPropiedadPropertyName] = value; }
}
 
private const string ColeccionDeEjemploPropertyName = "coleccionDeEjemplo";
 
[ConfigurationProperty(ColeccionDeEjemploPropertyName, IsRequired = true, IsDefaultCollection = true)]
[ConfigurationCollection(typeof(EjemploData))]
public EjemploDataCollection ColeccionDeEjemplo
{
get { return (EjemploDataCollection)this[ColeccionDeEjemploPropertyName]; }
}
 
#endregion
}

Así pues, para cargar datos en el fichero de configuración, debemos cargar la clase controladora (EjemploSettings) y montar el árbol de nodos que hemos definido en las clases.

Dentro del nodo configurationSections debemos crear un nodo SectionGroup como se muestra, y dentro un nodo section. Pueden existir múltiples nodos sectionGroup pero no con el mismo nombre. Cada nodo sectionGroup puede tener en su interior multiples nodos section.

   <sectionGroup name="oxxigeno">
      <section name="ejemploSettings" type="Oxxigeno.Ejemplo.Configuration.EjemploSettings, Oxxigeno.Ejemplo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=96df930e30970c00">
   </sectionGroup>

Y despues creamos el árbol de nodos tal como lo hemos definido, quedaría algo así:

   <oxxigeno> 
      <ejemploSettings nuevaPropiedad="valorDeLaPropiedad"&gt; 
         <coleccionDeEjemplo&gt; <clear/&gt;
            <add name="nombreDeLaEntrada1" propiedadBooleana="false" /&gt; 
            <add name="nombreDeLaEntrada2" propiedadBooleana="true" /&gt; 
         </coleccionDeEjemplo>
      </ejemploSettings>
   </oxxigeno&gt;

La forma de recuperar estos valores sería la siguiente:

EjemploSettings ejemploSettings = ConfigurationManager.GetSection(EjemploSettings.SectionName) as EjemploSettings;
string nuevaPropiedad = ejemploSettings.NuevaPropiedad;
foreach (EjemploData obj in ejemploSettings.ColeccionDeEjemplo)
{
string nombre = obj.Name;
bool propiedadBooleana = obj.PropiedadBooleana;
}

Considero que este método de utilización del fichero de configuración es:

• Más útil: Los valores se encuentran parseados al tipo necesario, no se obtienen unicamente valores de tipo string como pasa si utilizamos AppSettings, lo cual facilita el trabajo del desarrollador.
• Más estructurado: Los valores dentro del fichero de configuración son facilmente localizables y, por lo tanto, modificables.

Esta tecnología integra en una única metodología de programación las hasta ahora incompatibles COM+ (Serviced Components), .NET Remoting y Servicios Web. Para ello, un servicio WCF debe definir una serie de puntos de acceso (denominados EndPoints) que representan una puerta de entrada al servicio publicado, permitiendo así que un mismo servicio sea consultado mediante distintos tipos de comunicación.
Los EndPoints deben presentar:

• Dirección: representada por la clase EndPointAddress, indica dónde está la aplicación
• Enlace: representada por la clase Binding, indica cómo se puede accesar esa aplicación: Protocolo del transporte, Codificación y Seguridad.
• Contrato: representada por una clase con atributos de tipo ServiceContractAttribute, se trata de una definición de los datos que van a ser comunicados por el aplicativo.

WCF utiliza mensajes SOAP para la comunicación de estos datos, siguiendo así un estándar de comunicación. Sin embargo, cuando se realiza una comunicación entre dos procesos WCF se optimiza esta comunicación, aplicando una codificación en formato binario para los mensajes SOAP. De esto podemos olvidarnos totalmente, ya que al fin podemos crear un servicio sin preocuparnos de cómo ni quién va a acceder a él.

Vayamos con un ejemplo y veamos si es realmente lo que nos venden. Creamos una interfaz y una entidad que serán las que utilizaremos para dar vida al servicio.

[ServiceContract]
    public interface IExample
    {
        [OperationContract]
        string GetData(int value);
 
        [OperationContract]
        ExampleType GetDataUsingDataContract(ExampleType composite);
 
        [OperationContract]
        string[] GetNames();
    }
 
    [DataContract]
    public class ExampleType
    {
        bool _delete = false;
        string _name = "Name";
 
        [DataMember]
        public bool Delete
        {
            get { return _delete; }
            set { _delete = value; }
        }
 
        [DataMember]
        public string Name
        {
            get { return _name; }
            set { _name = value; }
        }
    }

Los atributos DataContract y OperationContract son, para entendernos, los atributos que sustituyen a WebService y WebMethod. Mientras que los atributos DataContract y DataMember son los atributos que servirán para serializar las entidades que se publicarán a través del servicio.

Ahora, una vez creada la interfaz que publicará el servicio y la entidad, procedemos a implementar la funcionalidad del servicio.

public class ExampleService : IExample
    {
        public string GetData(int value)
        {
            return string.Format("You entered: {0}", value);
        }
 
        public ExampleType GetDataUsingDataContract(ExampleType composite)
        {
            if (!composite.Delete)
            {
                composite.Name += " y Apellido";
            }
            return composite;
        }
 
        public string[] GetNames()
        {
            List<string> lista = new List<string>();
            for (int i = 0; i < 5; i++)
            {
                lista.Add("nombre" + i.ToString());
            }
            return lista.ToArray();
        }
    }

Con esto ya tenemos el código necesario para crear un servicio con WCF. Nos falta darle posibles puntos de entrada, para poder publicarlo. Lo hacemos a través del web.config del servicio.

<system.serviceModel>
    <services>
      <service name="Namespace.ExampleService" behaviorConfiguration="Namespace.ExampleServiceBehavior">
        <!-- Service Endpoints -->
        <endpoint address="" binding="wsHttpBinding" contract="Namespace.IExample">
          <identity>
            <dns value="localhost"/>
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="Namespace.ExampleServiceBehavior">
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="false"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

Voy a intentar explicarlo de forma esquemática. Dentro de la etiqueta “services” creamos cada uno de los servicios que queramos publicar, mientras que dentro de la etiqueta “behaviors” definiremos diferentes comportamientos que podrán utilizarse en los servicios publicados.

Pero volvamos a la etiqueta “services”. Dentro de ella crearemos tantas etiquetas “service” como servicios queramos publicar. Cada una se define mediante nombre y comportamiento (“name” y “behaviorConfiguration”). Además debemos definir una serie de puntos de entrada (“endpoint”) con las propiedades “address”, “binding” y “contract”, y un nodo interno de tipo “identity” (como se ve en el código). Vamos con ellos:

• Etiqueta Service:
  • Address: Especificamos la URI, que puede estar como cadena vacía.
  • Binding: Especificamos el binding a utilizar, lo cual define el tipo de transporte, la seguridad y el encoding utilizado. Podemos utilizar un binding definido por nosotros.
  • Contract: Especifica la interfaz que define se publicará con el servicio.
• Etiqueta Behavior:
  • Name: Nombre del behavior, único en el web.config
  • ServiceMetadata: Especifica la publicación de los metadatos del servicio y de la información asociada.
  • ServiceDebug: Especifica las características de la información de depuración y de la ayuda para un servicio de la WCF.

Para una descripción más detallada podemos recurrir a la siguiente url de Microsoft: http://msdn.microsoft.com/en-us/library/ms733932.aspx

Respecto al cliente, su uso es tan sencillo como agregar la referencia al servicio a la solucion e invocarlo desde el código.

Al agregar la referencia al servicio podemos ver que el web.config ha sido modificado, añadiendo la configuracion necesaria para accesar dicho servicio. Veamos qué ha añadido:

<system.serviceModel>
        <bindings>
            <wsHttpBinding>
                <binding name="WSHttpBinding_IExample" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                    bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
                    maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
                    allowCookies="false">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                        maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                    <reliableSession ordered="true" inactivityTimeout="00:10:00"
                        enabled="false" />
                    <security mode="Message">
                        <transport clientCredentialType="Windows" proxyCredentialType="None"
                            realm="" />
                        <message clientCredentialType="Windows" negotiateServiceCredential="true"
                            algorithmSuite="Default" establishSecurityContext="true" />
                    </security>
                </binding>
            </wsHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:3153/ExampleService.svc"
                binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IExample"
                contract="ExampleServiceReference.IExample" name="WSHttpBinding_IExample">
                <identity>
                    <dns value="localhost" />
                </identity>
            </endpoint>
        </client>
    </system.serviceModel>

Él solo ha creado todo el arbol de etiquetas de configuracion necesario para acceder al servicio mediante el endpoint que deseemos. Si nos fijamos en la etiqueta “endpoint” dentro de “client” podemos ver cómo ha agregado la direccion del servicio, el tipo de binding, la configuracion del mismo, la interfaz que presenta y el nombre (que es lo que utilizaremos para crear el objeto client en código):

ExampleClient clientDefault = new ExampleClient("WSHttpBinding_IExample");
            string[] namesDefault = clientDefault.GetNames();

Vamos a crear otro endpoint en el web.config del servicio y vamos a refrescar la referencia en el cliente para ver cómo cambia el web.config, añadiendo el nuevo endpoint y veremos cómo referenciarlo. Agregamos dos endpoints:

 <endpoint address="Soap11" contract="Namespace.IExample" binding="basicHttpBinding"/>
            <endpoint address="Soap12" contract="Namespace.IExample" binding="wsHttpBinding"/>

Y refrescamos la referencia al servicio en el cliente. Miramos el web.config y descubrimos que tenemos nuevas formas de acceder al servicio:

 <endpoint address="http://localhost:3153/ExampleService.svc/Soap11"
                binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IExample"
                contract="ExampleServiceReference.IExample" name="BasicHttpBinding_IExample" />
            <endpoint address="http://localhost:3153/ExampleService.svc/Soap12"
                binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IExample"
                contract="ExampleServiceReference.IExample" name="WSHttpBinding_IExample1">
                <identity>
                    <userPrincipalName value="ivinuales@oxxigeno-networks.spain" />
                </identity>
            </endpoint>

Además, nos ha creado una nueva entrada dentro de bindings:

<basicHttpBinding>
                <binding name="BasicHttpBinding_IExample" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                    allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
                    maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
                    useDefaultWebProxy="true">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                        maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                    <security mode="None">
                        <transport clientCredentialType="None" proxyCredentialType="None"
                            realm="" />
                        <message clientCredentialType="UserName" algorithmSuite="Default" />
                    </security>
                </binding>
            </basicHttpBinding>

De tal forma que ahora en el código fuente podemos instanciarlo de 3 formas distintas:

            ExampleClient clientDefault = new ExampleClient("WSHttpBinding_IExample");
            string[] namesDefault = clientDefault.GetNames();
 
            ExampleClient clientSOAP11 = new ExampleClient("BasicHttpBinding_IExample");
            string[] namesSOAP11 = clientSOAP11.GetNames();
 
            ExampleClient clientSOAP12 = new ExampleClient("WSHttpBinding_IExample1");
            string[] namesSOAP12 = clientSOAP12.GetNames();

Lo primero que debemos hacer es identificar esa entidad y crear una clase para guardar esos datos. Después debemos tener algun mecanismo para rellenar esta clase con los valores de cada una de las filas (cada fila del fichero supondrá un objeto de ésta clase).

Pongamos un ejemplo.  Supongamos un fichero csv como el siguiente:

Edad; Nombre; Apellido
15; Pepito; Perez
57; Ernesto; Román
RowCount = 2

En ocasiones los csv traen una cabecera y/o un pie de fichero y en otras no, por lo que no podemos tratar de procesarlas siempre.

Vamos a empezar creando una clase entidad como la siguiente:

public class Edades
{
    private int _edad;
    private string _nombre;
    private string _apellido;
    public int Edad
    {
        get { return _edad; }
        set { _edad = value; }
    }
    public string Nombre
    {
        get { return _nombre; }
        set { _nombre = value; }
    }
    public string Apellido
    {
        get { return _apellido; }
        set { _apellido = value; }
    }
}

Como vemos, se trata de una clase tonta con 3 atributos y sus 3 correspondientes propiedades publicas. En este ejemplo sería muy sencillo por cada fila crearnos un objeto y asignar a Edad el primer valor de la fila, a Nombre la segunda y a Apellido la tercera, serían 3 simples líneas. Sin embargo, a medida que el csv (y la clase) contengan más campos esto se haría más complejo, y sería muy complejo de modificar si algún día deciden introducir un campo nuevo en mitad del csv.

Claro este punto, debemos tener alguna forma de relacionar cada propiedad de la clase con la posicion que ocupa ese valor en el csv. Para esto tenemos dos opciones:

• Si la posición de cada campo es susceptible de ser modificada periódicamente deberíamos determinar esta relación en el web.config (si es una aplicación web) o en app.config (si es una aplicación de escritorio)
• Si la posición de cada campo no es susceptible de ser modificada, es preferible agregar atributos a la clase que indique donde debemos buscar el valor de cada propiedad.

Voy a centrarme en este segundo supuesto, el primero posiblemente lo trataremos en otro artículo. Vamos a generar una clase que herede de Attribute para poder indicar en la clase que acabamos de crear donde buscaremos cada valor.

public class CSVFieldAttribute : Attribute
{
    private int _order;
    public int Order
    {
        get { return _order; }
        set { _order = value; }
    }
    public CSVFieldAttribute(int order)
    {
        _order = order;
    }
}

Ahora modificamos la clase de la entidad, añadiéndole a cada propiedad un atributo indicando su posición en el csv. La clase quedaría como sigue:

public class Edades
{
    private int _edad;
    private string _nombre;
    private string _apellido;
 
    [CSVField(0)]
    public int Edad
    {
        get { return _edad; }
        set { _edad = value; }
    }
    [CSVField(1)]
    public string Nombre
    {
        get { return _nombre; }
        set { _nombre = value; }
    }
    [CSVField(2)]
    public string Apellido
    {
        get { return _apellido; }
        set { _apellido = value; }
    }
}

En este punto podemos elegir partir de una base en 0 o una base en 1. Yo he preferido partir de base 0 porque es la utilizada en los arrays por C#.
Ya tenemos relacionada la clase de entidad con los valores del csv, ahora falta buscarnos la vida para rellenar un objeto a partir de una fila del csv. Propongo utilizar Reflexion y las Templated classes para generalizar este proceso, creando una clase que trasforme un array de valores en un objeto del tipo que le indiquemos. A las propiedades de ese objeto les asignaremos el valor (mediante reflexion) que haya en el array de valores en la posición indicada. Vayamos al tema:

public class CSVConverter<T>
{
    public T Convert(string[] values)
    {
        Type type = typeof(T);
        T obj = Activator.CreateInstance<T>();
        try
        {
            CSVFieldAttribute att = null;
            object[] attributes = null;
            foreach (PropertyInfo prop in type.GetProperties())
            {
                attributes = prop.GetCustomAttributes(typeof(CSVFieldAttribute), false);
                if (attributes.Length &gt; 0)
                {
                    att = attributes[0] as CSVFieldAttribute;
                    /* Si hemos optado por usar base 1 debemos poner:
                        values[att.Order - 1]
                    */
                    if (!(values[att.Order].Trim().Equals(string.Empty)))
                    {
                        prop.SetValue(obj,
                           Convert.ChangeType(values[att.Order], prop.PropertyType),
                           null
                        );
                    }
                }
            }
        }
        catch (Exception ex)
        {
            throw new Exception("Error al intentar hacer la conversión de tipos.\r\n" + ex.Message, ex);
        }
        return obj;
    }
}

Ya solo queda procesar el fichero para ir creando los objetos y hacer lo que tengamos que hacer con ellos. Para ello, nos crearemos una clase base a partir de la cual heredaremos las clases de negocio que creamos oportunas para procesar distintos modelos de csv.

public class ProcessCSV<T>
{
    protected StreamReader _streamReader;
    protected string _line;
    public void Process(string filename)
    {
        try
        {
            _streamReader = new StreamReader(filename);
            this.ProcessHeader();
            this.ProcessBody();
            this.ProcessFooter();
        }
        catch (Exception ex)
        {
            throw ex;
        }
        finally
        {
            if (_streamReader != null)
                _streamReader.Close();
        }
    }
    protected virtual void ProcessHeader()
    {
        throw new Exception("No implementado");
    }
    protected virtual void ProcessFooter()
    {
        throw new Exception("No implementado");
    }
    protected virtual void ProcessOneObject(T obj)
    {
        throw new Exception("No implementado");
    }
    protected void ProcessBody()
    {
        T obj = Activator.CreateInstance<T>();
        _line = _streamReader.ReadLine();
        while (!_streamReader.EndOfStream && _line != null && _line.Trim() != string.Empty)
        {
            try
            {
                string[] values = _line.Split(';');
                CSVConverter<T> converter = new CSVConverter<T>();
                obj = converter.Convert(values);
                this.ProcessOneObject(obj);
            }
            catch (Exception ex)
            {
                // Aquí escribiríamos algo en el log indicando qué fila ha fallado
            }
        }
    }
}

Ya tenemos nuestra clase genérica. Pero claro, con esto no hacemos nada, si intentas parsear algo llamando a esta clase te van a saltar excepciones porque no está implementados algunos métodos necesarios. Generemos la clase que realmente usaremos.

Partimos de varios supuestos: el csv es el que he puesto arriba (con cabecera y pie), no vamos a usar para nada ni la cabecera ni el pie y queremos agregar a una lista para luego procesarlos (esto no lo voy a contemplar en el articulo).
Al tema:

public class EdadesBL : ProcessCSV<Edades>
{
    private List<Edades> _list;
    public EdadesBL()
    {
        _list = new List<Edades>();
    }
    protected override void ProcessHeader()
    {
        // Solo leemos porque no queremos conservar la cabecera
        _streamReader.ReadLine();
    }
    protected override void ProcessFooter()
    {
        // Solo leemos porque no queremos conservar la cabecera
        _streamReader.ReadLine();
    }
    protected override void ProcessOneObject(Edades obj)
    {
        // Solo queremos agregarlo a la lista.
        _list.Add(obj);
    }
    public List<Edades> Edades
    {
        get { return _list; }
    }
}

Ahora solo tenemos que procesar el fichero con dos simples líneas (en nuestro pequeño ejemplo 3 para recoger tambien la lista de Edades):

EdadesBL business = new EdadesBL();
business.Process(filename);
List todos = business.Edades;

Instalaciones en red

La mayoría de los sistemas Linux se instalan desde los CD-ROM (o DVD) de distribución. Este método es cómodo si sólo necesita instalar uno o pocos sistemas, pero puede ser muy tedioso si necesita instalar 10 o más sistemas, especialmente si cada uno tiene que ser instalado con los mismos parámetros.

Existen métodos de instalación más avanzados que son adecuados para estas situaciones, y en la mayoría de los casos, involucran instalaciones de red, donde los RPMs a instalar son descargados de la red.

Existen varios protocolos de red para recuperar los RPMs de instalación, y los protocolos soportados dependen de la distribución. Puede que se incluya soporte para NFS, FTP, HTTP y SMB.

Un requisito obvio para una instalación basada en red es que necesitará configurar un servidor de instalación en red en algún lugar de ésta, el cual contendrá todos los RPMs de su distribución.

Otro requisito es que los sistemas que se van a instalar estén equipados con un adaptador de red, que esté soportado por el disquete de arranque de red. Si su adaptador de red no está soportado en el disquete de arranque, puede necesitar un disquete adicional que contenga el soporte de dispositivo en forma de módulos de kernel de Linux.

Servidor de instalación de red

Un servidor de instalación en red es normalmente un servidor Linux/UNIX, aunque a veces también se pueden utilizar servidores Windows. El contenido de todos los CDs importantes se copia en disco y se deja disponible. Es una buena idea usar un esquema de denominación que permita copiar en disco múltiples versiones de múltiples distribuciones.

Casi todos los servidores de instalación en red exportan los CDs a través de NFS, sin embargo, también puede utilizarse FTP (anónimo), HTTP y SMB.

Si decide usar NFS, tenga presente que las distribuciones más nuevas utilizan normalmente NFS versión 3, mientras que las más antiguas suelen utilizar NFS versión 2. Esto puede generar problemas de compatibilidad, que pueden ser fácilmente solucionados forzando al servidor NFS a utilizar siempre la versión 2.

Si decide ofrecer instalaciones de FTP anónimo, necesitará crear la estructura de directorios en algún lugar bajo el directorio /var/ftp, ya que el demonio ftp realizará el chroot en este directorio cuando se solicite FTP anónimo.

Si decide ofrecer instalaciones HTTP, simplemente puede crear un enlace simbólico desde el directorio document_root al directorio donde se copian los CDs, siempre que se establezca “FollowSymLinks” en la configuración del servidor web.

Después de crear el directorio de instalación, necesitará copiar el contenido de los CDs importantes en dicho directorio. Esta acción tiene que llevarse a cabo preservando intactos todos los permisos, los usuarios, etc. y la mejor forma de realizarlo puede ser mediante la utilización del parámetro cp -a

Para una distribución Red Hat o fedora, asegúrese de copiar al menos el fichero .discinfo y los directorios RedHat/ e images/.

Instalaciones “Kickstart” de Red Hat/Fedora

“Kickstart” es el método de Red Hat y Fedora para la automatización de instalaciones. Implica la creación de un archivo ks.cfg, que contiene tres secciones:

• La primera sección, que empieza en la parte superior del archivo, contiene la respuestas a todas las preguntas del proceso de instalación. Por ejemplo, si existe la declaración lang en_US en el archivo de kickstart, la pregunta “¿Qué idioma desea utilizar durante el proceso de instalación? no será formulada, sino que se utilizará el inglés de EEUU.
• La segunda sección empieza con el identificador %packages. Contiene una lista con todos los paquetes (RPMs) que se van a instalar. Al igual que en el propio proceso de instalación, también puede utilizar los grupos de paquetes que están definidos en el archivo [RedHat|Fedora]/base/comps.xml. Estos grupos de paquetes están identificados con un símbolo arroba, por ejemplo “@ Printing Support”.
• La tercera sección empieza con el identificador %post. Contiene una serie de manadatos de shell que se ejecutan en el sistema recién instalado, con todas las rutas de acceso, redes, etc, intactas. Esto significa que es posible realizar prácticamente cualquier acción, incluido montar sistemas de archivos remotos, crear cuentas de usuario, etc.

También es posible crear una sección %pre, que se ejecuta antes de que se inicie la instalación. Esto suele utilizarse para implementar esquemas de partición personalizados.

Los archivos kickstart pueden hacerse a mano (veáse anexo), pero Red Hat ha creado una herramienta que le ayudará a generar ficheros kickstart: redhat-config-kickstart (anteriormente conocida como ksconfig). Esta herramienta está disponible en los CDs de distribución en el paquete RPM ksconfig. Como un extra añadido, el instalador de Red Hat/Fedora, Anaconda, genera un fichero kickstart basado en las elecciones determinadas durante el propio proceso de instalación. Este fichero se llama /root/anaconda-ks.cfg.

Ejemplos son ks=floppy y ks=http://192.168.0.1/kickstat/ks.cfg, si no suministra una URL (“linux ks”), entonces la localización del fichero kickstat se tomará del siguiente servidor DHCP y las respuestas de las opciones “next server” y “filenam” desde el servidor DHCP.

El fichero de configuración kickstart puede guardarse en un disquete de arranque o en un servidor de la red. La instalación de Kickstart comienza entonces tecleando linux ks=<URL>, donde <URL> es la localización en donde se guarda el fichero ks.cfg.

Para instalaciones kickstart completamente automatizadas, modifique el fichero syslinux.cfg en su disco bootdisk.img, y defina kickstart por defecto. Debería desactivar la opción de delay. La cabecera del fichero se verá de la siguiente manera:

default linux ks
prompt 0

<!--more-->

Conclusiones

Se ha visto como los servidores de instalación en red son mecanismos apropiados para la distribución de software, con objeto de actualizar e instalar. Así como un servidor de instalación en red, normalmente, exporta varias versiones de distintas distribuciones vía NFS, FTP o HTTP. Habitualmente para realizar una instalación en red, necesitará un disquete y, en ciertas ocasiones, discos de módulos adicionales.

Por último, se ha visto como “Kickstart” de Red Hat/Fedora es un método de instalación que le permite automatizar las instalaciones.

Anexo

Un archivo de kickstart de ejemplo tendrá este aspecto:

<!--more-->install
nfs --server 192.168.0.1 --dir /export/rh80
lang en_US
langsupport --default en_US.iso885915 en_US.iso885915
keyboard es
mouse generic3ps/2 --device psaux
skipx
network --device eth0 --bootproto dhcp
rootpw oxxigeno
firewall --disabled
authconfig --enableshadow --wnablemd5
timezone Europe/Madrid
bootloader
clearpart --all
part /boot --fstype ext3 --size=100
part / --fstype ext3 --size=3000
part swap --size=1024
 
%packages
@ Printing Support
@ X Window System
@ GNOME Desktop Environment
@ KDE Desktop Environment
@ Development Tools
@ Kernel Development
@ Network Servers
 
%post
adduser oxx1
echo oxx1 | passwd --stdin oxx1

Durante la planificación de la instalación física, deben ser consideradas varias cuestiones y elementos:

• Peso
• Superficie del suelo
• Accesibilidad
• Alimentación eléctrica
• Temperatura
• Humedad
• Electricidad estática
• Limpieza.

Alojamiento del sistema

En la mayoría de los casos, los servidores se sitúan en salas de sistemas dedicadas.

Las ventajas son muchas. Los suelos técnicos facilitan mantener el orden y facilitan la regulación de aire acondicionado por separado, permitiendo conseguir un entorno ambiental óptimo. Además, los sistemas de control de acceso impiden el acceso no autorizado a la consola. La mayor desventaja es la dificultad de accesibilidad si se precisara acceder a la consola.

Montaje en bastidor

Los bastidores de fabricación estándar (19”) pueden almacenar una gran variedad de equipamiento informático, como servidores, bandejas de servidores blade, equipos de red, monitores, teclados, conmutadores KVM, UPS, etc.

Las principales ventajas son la reducción significatica de la superficie necesaria, la facilidad para limitar el acceso físisco al sistema y la facilidad para mantener el orden, así como un mejor aspecto visual. Como desventajas tendríamos el precio, la mayor dificultad para el acceso físico y la posible necesidad de reforzar el suelo para un bastidor completo.

Consideraciones sobre la alimentación eléctrica

Se debe tener en cuenta el consumo eléctrico de los dispositivos. La cantidad total de vatios no deberá exceder el voltaje multiplicado por el número de amperios del circuito eléctrico. En Europa, habitualmente sería:

240V * 16A = 3840W

Puede considerarse la utilización de disipadores de sobrevoltaje para eliminar los picos producidos por rayos, etc, además de fuentes de alimentación continua (UPS) para los componentes críticos (servidores y segmentos centrales de la red). Estas UPS normalmente funcionan mediante baterías, manteniendo la alimentación entre 10 y 30 minutos.

Aire Acondicionado

Suele ser necesario disponer de aire acondicionado para el mantenimiento: temperatura estable y humedad constante.

La temperatura ideal es entre 17 y 20 ºC. Una temperatura inestable puede provocar daños físicos, como consecuencia de la expansión y contracción de los componentes internos. Y una temperatura alta puede producir un sobrecalentamiento de los componentes internos.

En cuanto a la humedad, la ideal sería entre un 40 y un 60%. Una baja humedad puede provocar un aumento de la electricidad estática. Y una alta humedad puede originar condensación.

Por último, debe tenerse en cuenta que el consumo de un vatio precisa de un enfriamiento de 3,1412 BTU/hr (la capacidad de A/C de una tonelada equivale a 12000 BTU/hr).

Sistema de detección y supresión de incendios

Debemos asegurarnos de detectar el fuego lo antes posible. Los detectores de humo detectan el monóxido de carbono, y deben ponerse bajo el suelo flotante y por encima de los falsos techos. Debemos considerar los métodos de extinción de incendios, ¿agua?, ¿CO2?, ¿gas inerte?.

Por último, podemos considerar la instalación de un conmutador maestro que corte toda la alimentación eléctrica de la sala de sistemas de manera inmediata.

Procedimientos recomendados

Se debe tener cuidado con la electricidad estática al reemplazar componentes:

• Conecte a tierra todos los componentes de manera adecuada.
• Tocar la carcasa externa o un conector con conexión a tierra antes de manipular algún componente interno.
• Guarde componentes no utilizados en bolsas de protección contra la electricidad estática.
• No toque circuitos eléctricos si puede evitarlo.
• Considere el uso de muñequeras y alfombras antiestáticas.

Debemos utilizar únicamente materiales/herramientas/empresas especializadas en la limpieza de equipos informáticos,  comprobar regularmente el buen funcionamiento de los ventiladores y tener a mano una caja de herramientas completa.

Conclusiones

En las instalaciones grandes es beneficioso tener una sala de sistemas dedicada con suelos flotantes y equipos montados en  bastidor.

La cantidad máxima de potencia eléctrica consumida por todos los sistemas no deberá exceder los límites de los circuitos.

El aire acondicionado deberá ser suficientemente potente para enfriar todo el equipo cuando funcione al máximo, y además deberá ser capaz de conservar la humedad dentro de los límites aceptables.

Por último, también puede ser necesario un sistema de detección y extinción del fuego; solicite consejo a su departamento de bomberos local.

Muchas veces tendemos a buscar una solución programada a problemas que pueden ser resueltos fácil y rápidamente sin recurrir al actionscript. Preferimos buscar trozos de código en la web que muchas veces solo entendemos por encima en lugar de desarrollar efectos hechos por animación desde cero. En definitiva nos volvemos un poco ciegos a la alternativa animada y preferimos el engorro del código.

Si bien actionscript te permite realizar efectos espectaculares en tiempo real, esto muchas veces no es necesario y la utilización de código no esta justificada. Ademas siempre es mas fácil que otra persona entienda una linea de tiempo animada que un montón de lineas de código, por lo tanto un proyecto puede ser retomado mas fácilmente por diferentes personas.

Vamos a ver como animar un objeto que desprende una estela, utilizando únicamente las interpolaciones de movimiento, clips de película anidados y algún filtro.

1º Dibujamos el objeto que queremos animar. En mi ejemplo una bolita que dibujare utilizando la herramienta Óvalo.

Seleccionando el objeto y pulsando F8 lo convertimos en un clip de película (no me preguntéis del porque no un gráfico ya que es simplemente una preferencia personal).

2º Seleccionamos el clip y nuevamente lo convertimos en otro clip. Por lo que tendremos un clip anidado en otro. Al que encierra la forma de la bolita lo he llamado bola y al segundo que lo contiene lo he llamado anima bola.

3º Editamos anima bola y creamos la siguiente linea de tiempo

El primer y el ultimo fotograma clave tiene bola en la misma posición inicial y en el del medio desplazo bola. Después interpolo y ya tengo una animación en la que bola se desplaza y vuelve a su posición una y otra vez.

Para adornar un poco le doy aceleración 100 al primer fotograma clave y -100 al segundo. Y una rotación CW x3 en el primer fotograma clave y de CCW x3 en el segundo.

4º Volvemos a la escena, seleccionamos  ‘anima bola’ y pulsamos F8 para volver a anidarlo. Yo he llamo a mi nuevo clip estela bola. Así que tenemos el siguiente esquema:

5º Editamos estela bola y creamos la siguiente linea de tiempo:

Las capas llamadas estela son una copia del contenido de la capa llamada bola. Así tenemos el clip de película anima bola en 5 capas diferentes. En la última superior y el último fotograma he puesto un stop(). El único trozo de código de la animación.

En las capas llamadas estela selecciono el clip de película y le doy un Alfa del 30% y un filtro de desenfoque de 5px. en los ejes X e Y. Por lo que cada clip anima bola nos quedaría así:

6º Publicamos y ¡tachán!

Los sitios web desarrollados bajo el .NET framework son publicados con una precompilación del código fuente, sin embargo, las páginas aspx y los controles ascx son interpretados en tiempo de ejecución. Es decir: cada vez que un usuario solicita una página aspx ésta es interpretada por el servidor de aplicaciones y presentada al cliente.

Como puede suponerse, el hecho de que la página aspx contenga código fuente que deba ser compilado ralentizará la carga de la misma, puesto que se pasa de interpretar html y devolverlo a compilar código de servidor con más o menos lógica.

En muchas ocasiones es posible pensar que no nos es posible crear la página aspx tal y como queremos sin incluir código de servidor en la misma, esto es un error muy común, pero facilmente subsanable, siguiendo las siguientes recomendaciones.

• Solo está permitido utilizar código de servidor para cargar elementos dentro de controles de tipo DataBound (GridView, FormView, etc.). Aun así es poco recomendable porque sigue requiriendo compilación. Se recomienda la utilización del control Repeater.

 
                <%# Eval("TipoDePagina.Nombre") %>
 
                Editar Contenidos

• Si necesitamos que un elemento HTML obtenga propiedades (style, href, title, etc.) desde el lado del servidor, porque utilice alguna lógica de negocio debemos identificar a éste elemento con runat=server y asignar dichas propiedades desde el code-behind, que va precompilado cuando se publica.

aspx no recomendado:

<div id="global" class="fondo-menu-&lt;%= ambitoCabecera %&gt;">
<div id="cabecera" class="cabecera-&lt;%= ambitoCabecera%&gt;">
<div id="cabecera-logo">
            <a title="Alt" href="#">
                <img id="imgLogo" src="../images/&lt;%= image%&gt;" alt="Grupo Banco Popular" width="148" height="50" />
            </a></div>
<div id="shortcuts">
<ul class="horizontal">
	<li><a href="#">Atención al cliente</a> |</li>
	<li><a href="#">Sucursales</a> |</li>
	<li><a href="#">Tarifas</a> |</li>
	<li><a href="#">Simuladores</a></li>
</ul>
</div>
<div id="buscador">
            <fieldset>
 
            </fieldset></div>
</div>
</div>

Código no recomendado:

// Imagen por omision para el logo
public string _image = "default.jpg";
// Ambito por omision para la cabecera
public string _ambitoCabecera = "normal";
 
protected void Page_Load(object sender, EventArgs e)
{
 
    #region Dar valores a las variables
    ...
    #endregion
 
}

aspx recomendado:

<div id="global">
<div id="cabecera">
<div id="cabecera-logo">
            <a title="Alt" href="#">
                <img alt="Grupo Banco Popular" width="148" height="50" />
            </a></div>
<div id="shortcuts">
<ul class="horizontal">
	<li><a href="#">Atención al cliente</a> |</li>
	<li><a href="#">Sucursales</a> |</li>
	<li><a href="#">Tarifas</a> |</li>
	<li><a href="#">Simuladores</a></li>
</ul>
</div>
<div id="buscador">
            <fieldset>
 
            </fieldset></div>
</div>
</div>

Código recomendado:

protected void Page_Load(object sender, EventArgs e)
{
    // Imagen por omision para el logo
    string image = "default.jpg";
    // Ambito por omision para la cabecera
    string ambitoCabecera = "normal";
 
    #region Dar valores a las variables
    ...
    #endregion
 
    this.global.Attributes.Add("class", "fondo-menu-" + ambitoCabecera);
    this.cabecera.Attributes.Add("class", "cabecera-" + ambitoCabecera);
    this.imgLogo.Src = "../images/" + image;
 
}

• Si necesitamos que un elemento HTML reciba su identificador, propiedades sensibles o una maquetación compleja dependiente de una lógica de negocio, la solución optima es crear un custom web control para definirlo, éste tipo de controles heredan de la clase WebControl.

namespace Example.Web.UI.Controls
{
    [DefaultProperty("Text"), ToolboxData("&lt;{0}:OnlyText runat=server&gt;<!--{0}:OnlyText-->")]
    public class OnlyText : System.Web.UI.WebControls.WebControl
    {
        #region Attributes
 
        private string _text = "";
 
        #endregion
 
        #region Properties
 
        [Bindable("true"), Category("Data"), DefaultValue("")]
        public string Text
        {
            get { return _text;}
            set { _text = value;}
        }
 
        #endregion
 
        #region Overrides Methods
 
        protected override void  Render(HtmlTextWriter writer)
        {
             writer.Write(Text);
        }
 
        #endregion
    }
}