Amazon EC2 is among the more potent items in Amazon’s web services arsenal. You’ve probably heard of many of the other services such as S3 for storage and FPS for payments. EC2 is all about the “elastic compute cloud.” In layman’s terms, it’s a server. In slightly less layman’s terms, EC2 lets you easily run and manage many instances (like servers) and given the proper software and configurations, have a scalable platform for your web application, outsource resource-intensive tasks to EC2 or for whatever you would use a server farm.

There are three different sizes of EC2 instances you can summon and they’re all probably more powerful than the server currently running your blog. Unless you’re offloading video processing or something intense to EC2, the default small instance with its 1.7GB of RAM and 160GB disk should be more than fine. It’s just nice to know that if for any reason I need a farm of machines each with 15GB of RAM, I can get that easily.

EC2 has been around for a while but has gained interest in the last few weeks as Amazon released an elastic IP feature. One of the larger EC2 issues deals with data persistence on instances. There are many limitations with EC2 that make it difficult to use unless you carefully build around the EC2 architecture and don’t just assume that you can move your app to EC2 flawlessly. If an instance crashes and you run it again, you’ll loose data and when the instance comes back up it will have a new IP, adding another hurdle with DNS issues. Fortunately, the elastic IP feature lets you assign a static IP address to your instances.

As the title of this article implies, this article is meant to be a beginner’s look into tinkering with EC2. Just because you will be able to host a page on EC2 at the end of this article does not mean you should start using it as your only server. Many considerations need to be made when using EC2 to get around the data persistence issue. If your startup is looking to use EC2 as a scalable platform, fortunately there are many services that have already built stable systems on top of EC2, ready for your consumption: WeoCeo, Scalr and RightScale. Enough talk, shall we jump right in?

Note: Most of the information below (and more) is available in the EC2 API doc if you enjoy reading those things.

Getting Started

In order to interact with any EC2 instances, you’ll need to install Amazon’s command line tools and download your X.509 certificate from Amazon. Let’s start with the certificate. Login to your Amazon account and visit the AWS Access Identifiers page. In the X.509 certificate section near the bottom, click Create New. You’ll be greeted with a page allowing you to download both the private key file and X.509 certificate. Both of these are very important, download them to your desktop so you don’t lose them.

Next up, grab the EC2 command line tools. Extract them and you should be left with a folder named something like ec2-api-tools-1.3-19403. We’ll move those to a directory where we will also store the private and public keys.

The commands below assume you are working on an OS X machine in the Terminal.

mkdir ~/.ec2
cd ~/Desktop
mv *.pem ~/.ec2
cd ~/Desktop/ec2-api-tools-1.3-19403/  #depends on ec2 tools folder name
mv * ~/.ec2

This is what your .ec2 folder should have now.

Next up, we’ll set some paths in your bash profile so the OS knows where the EC2 tools are located.

sudo vi ~/.bash_profile

Add these lines, replacing “YOURKEYNAME” with the actual file name of your private and public keys, then save.

export EC2_HOME=~/.ec2
export PATH=$PATH:$EC2_HOME/bin
export EC2_PRIVATE_KEY=pk-YOURKEYNAME.pem
export EC2_CERT=cert-YOURKEYNAME.pem
export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home/

To get the changes noticed by the OS immediately, run source.

source ~/.bash_profile

Now we can actually use those helpful EC2 command line tools.

AMIs, Keypairs and Instances, Oh My!

Before proceeding, you’ll need to grok the concept of AMIs. They are Amazon Machine Images and whenever you create an EC2 instance, an AMI is quickly loaded on the machine. They’re essentially images of the OS. If you terminate an instance and bring it up again, your machine will only have the data initially included in the image. That’s why lots of work goes into making (“bundling”) a good image you will always use that has the configurations and software you need so you don’t have to do much whenever you load the image. This article won’t delve into creating your own AMIs but fortunately there are many great, public AMIs available for use.

To SSH into the instance we’ll create from an AMI we find, we’ll need to create a keypair. This is a different key from the one provided to us by Amazon. That was for using the EC2 tools and interacting with the instances in terms of creation and management. To actually SSH into an instance, a separate keypair is required as there are no passwords by default.

cd ~/.ec2 #we pretty much always need to be here
ec2-add-keypair pstam-keypair

That will print out the private key, which you’ll need to copy and paste into a file manually.

vi ~/.ec2/id_rsa-pstam-keypair
#now paste the private key and save
sudo chmod 600 id_rsa-pstam-keypair

Now we can find which AMI we want to toss on our yet-to-be-created EC2 instance.

cd ~/.ec2
ec2-describe-images -a

Using the -a option will list all of the AMIs you have access to, and there are a lot. Alternatively you can list just the images Amazon has:

ec2-describe-images -o amazon

I found an AMI that I’ll try out.

ami.yyang.info/gentoo-nginx-php-mysql-06feb2008.manifest.xml

It’s a Gentoo Linux install with PHP, MySQL and nginx. When looking at AMIs, you need to find the AMI ID. In this case, it’s ami-6138dd08.

ec2-run-instances ami-6138dd08 -k pstam-keypair

The instance is now being loaded with the AMI I selected and booting up. It should output some text with “RESERVATION” and “INSTANCE” rows. On the instance row, it will say something like pending pstam-keypair until it has fully booted up. When an instance is ready to go, its URL and internal address will be supplied with the ec2din command below.

ec2-describe-instances

If you try to access the URL in a browser, nothing will happen just yet as the firewall blocks all ports by default. You’ll have to open up the ones you need. We’ll do port 80 for HTTP and 22 for SSH. If the AMI you are running doesn’t have a web server installed, accessing the EC2 URL in a browser won’t bring up anything regardless.

ec2-authorize default -p 22
ec2-authorize default -p 80

If you want to undo any port authorizations you’ve made, you can use ec2-revoke. Now if you access your EC2 URL in a browser you’ll get something like a default Apache page, or in the case of the AMI I’m using, a phpinfo() page.

The next step to actually using your new EC2 instance is SSHing into it to get full root access. Run the line below and replace the EC2 URL with the one provided to you by the ec2-describe-images command earlier.

ssh -i id_rsa-pstam-keypair root@ec2-XXX-XXX-XXX-XXX.z-2.compute-1.amazonaws.com

If you run into the problem I did, this won’t work and you’ll be asked for an EC2 instance password that doesn’t exist. I found out this was because I initially created the id_rsa-pstam-keypair file as the root user but ran the ssh command as a regular user which was not able to access that keypair. That was easily fixed with sudo chown Paul id_rsa-pstam-keypair but you won’t have this issue if you followed this guide.

Otherwise, you should be logged into your EC2 instance as root over SSH. Now that we’re in, we can tinker with the system however we like and even see what kind of hardware we’re running on, setup FTP and drop a web app into /var/www/localhost/htdocs or whatever. Having full root access in any OS you wish is one of the boons of using Amazon EC2.

Static IP Time

If you plan on running your instance for good, you’ll want a static IP. Let’s get one for you.

ec2-allocate-address

Now we just need to tie that IP address to the instance ID of the instance you wish to give a static IP. You can grab the instance ID (not to be confused with the ami-* AMI ID) by running ec2-describe-instances.

In the line below, replace XXX.XXX.XXX.XXX with the IP address you were given above and replace i-yourinstance with your actual instance ID.

ec2-associate-address -i i-yourinstance XXX.XXX.XXX.XXX

Give it a few minutes and your instance will be accessible through that new IP in addition to the longer EC2 URL we were previously using. Please note that if you terminate the instance, the IP does not remain tied to the instance, to the best of my knowledge. Terminating an instance seems to be a nuclear option compared to simply rebooting an instance via regular unix commands over SSH.

Now that the instance has an IP you can setup a domain name with it if you want. The easiest way I’ve found of doing this is through a DNS service like EveryDNS. Just provide your domain name registrar with EveryDNS’s domain name servers, create an EveryDNS account, add your domain and create an A record with your newly associated EC2 instance IP address.

The TTL on EveryDNS seems to be fixed at 3600 so it might take a while for propagation, especially if you’re used to pushing down TTL to 300 when doing DNS work.

Terminating Your EC2 Instance

Killing your instance for good can be done, like every other action, through an EC2 command line tool. This time, it’s the appropriately named ec2-terminate-instances (ec2kill). Just provide it with the instance ID of your instance (get it from running ec2din).

ec2-terminate-instances i-yourinstance

It should return with a “shutting-down” status but you’ll definitely want to check back in a few minutes with ec2-describe-instances to make sure it shutdown successfully and comes up as “terminated”. There are a few cases where instances will hang on shutdown and you will continue to be charged for instance hours.

The Next Step

Now that you’ve successfully launched your first Amazon EC2 instance, you’re ready to begin exploring the endless EC2 possibilities. I’m still learning about taking the next step but overall, EC2 really isn’t something to mess with unless you have quite a bit of sysadmin and development experience. Actually using EC2 as an elastic compute cloud usually involves setting up an instance as a load balancer and giving that instance access to an array of active EC2 instances which it can hand work to. Other hurdles include providing multiple instances access to the same database, using Amazon S3 as a persistent filesystem and employing highly redundant backup systems given the relatively volatile nature of instances.

The Wikipedia entry for grep states:

grep is a command line utility originally written for use with the Unix operating system.

The name comes from a command in the Unix text editor ed that takes the form:

g/re/p

This means “search globally for matches to the regular expression re, and print lines where they are found”.

Simple como deben ser las utilidades …

# sudo vi /etc/sudoers

Situarnos en la línea que comienza por Defaults, y añadir el flag insults al final:

Defaults     !lecture,tty_tickets,!fqdn,insults

A continuación limpiamos con la opcion -k (kill) la sesión abierta de sudo (si existe), para que nos solicite escribir la contraseña la próxima vez que ejecutemos sudo:

# sudo -k

Ahora cada vez que introduzcamos mal la contraseña al ejecutar sudo nos insultará.

Vía: http://www.alfonsojimenez.com/2007/09/09-insultos-de-sudo

http://bhami.com/rosetta.html

Gracias, Mercé Tena

# ssh root@asuncion df
# ssh root@asuncion uptime

… que nos lanza un df o un uptime en la maquina indicada con el usuario indicado y autenticandonos.
o mejor aun

# ssh root@asuncion “df;uptime”

que lo hace todo de una vez.

De momento no puedo lanzar sesiones interactivas, solo lo que es orden y respuesta al estilo del ls, df, mount, … aunque seguiremos investigando.

Via: Andros

4. Modelo de desarrollo de los sistemas *BSD

5. Ports y packages

6. Igualdades y diferencias en los *BSD

7. Conclusión

1. Introducción

Hola a todos. Esta noche hablaremos un poco sobre los diferentes sistemas operativos libres que estan basados en BSD, mas concretamente en 4.4BSD-Lite. Variaciones las hay muchas, y seria imposible tratar

todas las variantes *BSD que se encuentran disponibles, por lo tanto nos centraremos basicamente en las tres mas comunes y las que posiblemente conoce mas gente: NetBSD, FreeBSD y OpenBSD. No vamos a tratar ningun *BSD en profundidad. Esta charla estará enfocada mas bien a los “elementos” caracteristicos que tienen estos *BSD que hemos nombrado anteriormente y que son los mas conocidos por todo el mundo. Estos elementos comunes pueden ser por ejemplo el tipo de licencia, el sistema de paquetes, el sistema de arranque etc. es decir, elementos que encontrareis casi identicos tanto si usais NetBSD, FreeBSD o OpenBSD. Tambien comentaremos algunas de las diferencias existentes en estas tres vertientes y los propositos de cada una.

Antes de continuar comentar que usaremos el termino “*BSD” para referirnos en conjunto a NetBSD, FreeBSD y OpenBSD.

La charla empezará con una breve historia del sistema BSD, que esta muy ligada a la historia de Unix (como no). Posteriormente comentaremos los objetivos y caracterisitcas que hacen de estos tres BSD’s, sistemas diferentes que estan enfocados cada uno a un objetivo distinto

El cuarto punto tratara sobre el modelo de desarrollo que siguen los sistemas *BSD, veremos la organizacion de desarrollo y que significan las palabras -release, -stable y -current.

En el quinto punto explicaremos el sistema de paquetes usado por *BSD con ejemplos practicos para una expicación mas entretenida.

Y en el ultimo punto (el numero seis) comentaremos tanto las igualdades que tienen en comun los diferentes *BSD como las diferencias entre ellos.

Vamos allá

2. Del AT&T Unix a 4.4BSD – Historia de BSD -

La primera versión de Unix fuea desarrollada por Ken Thompson para los laboratorios Bell en 1969, poco tiempo después se unió al proyecto Dennis Ritchie, quien a parte de colaborar en el diseño y la implementación del sistema operativo, creó el lenguaje C, en el que se reescribiría Unix completamente.

Muchas de las ideas de unix, fueron tomadas de otros sistemas operativos. Multics, un sistema operativo también de Bell en el que habían trabajo estos dos desarrolladores, tuvo una gran influencia en Unix; donde en Multics se intentaba hacer algo muy complejo para resolver un problema, en Unix se buscaba el remedio más sencillo. Ideas tomadas directamente de Multics son el sistema de archivos y su interfaz etc… La idea de la operación ‘fork’ fue tomada de GENIE (Berkeley).

La sexta edición de Unix (V6) fue ampliamente distribuida, fuera de los laboratorios Bell. Las diferencias más destacadas respecto a otros sistemas operativos fueron que Unix estuviera escrito en un lenguaje de alto nivel, se distribuyera el código fuente y la posibilidad de correr procesos concurrentemente.

La primera versión de Unix proveniente de Berkeley, fue una modificación al 32V (predecesora de la V7), añadiéndole memoria virtual y otras características, a la cual se llamó 3BSD (1979). Este trabajo convenció a DARPA para que Berkeley desarrollara un sistema operativo con soporte para TCP/IP, así se creo el estandar 4BSD. Con el lanzamiento de 4.2BSD (1983) terminó el proyecto ‘Berkeley DARPA UNIX’. Apartir de aquí se lanzaron diferentes versiones, 4.3BSD (1986), 4.3BSD Net1 y Net2 (1989,1991) estas versiones ya se podían distribuir libremente sin ninguna ligadura con la ‘UNIX source license’. 4.4BSD (1993) y la 4.4BSD-Lite (1994), en la que se basan todos los *BSD de hoy en día.

En la versión 4.4 se arreglaron bastante deficiencias de su antecesora (4.3BSD) se incluyeron nuevos algoritmos que mejoraban la gestión de memoria, se mejoró la implementación de la suite IP, se añadió compatibilidad con el estandar POSIX. En esta versión se añadió una abstracción en la implementación de la interfaz de sistemas de archivos, de esta manera se permitía el soporte de varios fs.

3-Principales caracteristicas y objetivos de cada uno de los sistemas *BSD

Las principales características y objetivos del proyecto NetBSD son:

*Sistema operativo tipo UNIX, basado en 4.4BSD, multiplataforma y de libre disposición

*Posee un sistema TCP/IP completo (SLIP, PPP, NFS, NIS, FTP, TELNET,MAIL etc.)

*Amplia portabilidad: esto se realiza dividiendo el diseño en dos partes,

• MD (Máquina dependiente) y
• MI (Máquina independiente).

*Distribución del código fuente.

*Permite NAT, Ipv6, Wireless Networking, soporta hardware y sofware RAID, SCSI, sistemas de archivos de 64-bit, DVD ROM y RAM, USB, UVM, Cardbus, etc.

*Emulación de binarios: Linux, OSF/1, SCO UNIX, SunOS, System V release 4, Solaris y Ultrix.

*Desarrollar un S.O totalmente portable, que pueda correr en multitud de arquitecturas

Caracteristicas de FreeBSD

* FreeBSD es un sistema desarrollado totalmente en 32 bits.

* Posee un sistema TCP/IP completo (SLIP, PPP, NFS, NIS, FTP, TELNET,MAIL etc.)

* Sistema multiusuario/multitarea. FreeBSD como todo UNIX ofrece un sistema con posibilidad de ejecutar mas de una aplicación al mismo tiempo y trabajar con mas de un usuario a la vez

* Versatilidad en cuanto a su uso como Pc personal: Estación de trabajo, servidor de ficheros y aplicaciones, bases de datos, comunicaciones e internet, router, gateway, firewall, etc.

* Módulos de compatibilidad que permiten la ejecución de programas de otros sistemas operativos en FreeBSD, incluyendo programas para Linux, SCO, NetBSD, BSDI, etc.

* Módulos de kernel de carga dinámica que permiten tener acceso a nuevos sistemas de ficheros, protocolos de red o emuladores de binarios en tiempo de ejecución sin necesidad de generar un nuevo kernel.

* Disposición de todo el codigo fuente tanto del kernel como de las aplicaciones en la instalación base.

* FreeBSD soporta SMP y actualmente corre en arquitecturas i386 y alpha

* FreeBSD dispone de un grandisimo repertorio de aplicaciones y programas que corren perfectamente en él

Cuales son los objetivos de FreeBSD?

*Proveer software que pueda ser usado para cualquier causa sin que esto sea una carga. Es decir, desarrollar aplicaciones bajo licencia BSD para que despues se haga lo que quiera con este software.

*Optimización del codigo para plataformas i386 y alpha para que el sistema y las aplicaciones corran a gran velocidad bajo este S.O

*Dar disponibilidad del codigo fuente para que todo el mundo tenga acceso a el

*Seguir desarrollando un S.O estable, rapido y libre con abundantes aplicaciones, que sea efectivo y que responda bien ante grandes cargas de información

Caracteristicas OpenBSD

*Sistema operativo tipo UNIX, basado en 4.4BSD, multiplataforma y de libre disposición

* Posee un sistema TCP/IP completo (SLIP, PPP, NFS, NIS, FTP, TELNET,MAIL etc.)

*Soporte para la emulación de la mayor parte del código binario de los sistemas SVR4 (Solaris), FreeBSD, Linux, BSDI, SunOS, y HP-UX.

*OpenBSD actualmente soporta las plataformas siguientes: i386, sparc, hp300, amiga, mac68k, powerpc, sun3, mvme68k, alpha y vax

* OpenBSD está reconocido por muchos profesionales de la seguridad informática como el sistema operativo tipo UNIX más seguro; esto es el resultado de una intensa auditoría de seguridad sobre el código fuente, llevada a cabo durante un año y medio por un grupo de diez personas.

*OpenBSD es un sistema operativo con todas las funcionalidades de UNIX, que se puede adquirir de forma gratuita.

Cuales son los objetivos de OpenBSD?

*Proveer la mejor plataforma de desarrollo posible

*Dar acceso al codigo fuente a todo el mundo

*Integracion de código de calidad de cualquier fuente (preferiblemente del estilo de Berkeley -BSD-)

*Intentar ser el sistema operativo mas seguro. “Seguro por defecto”, es decir intentar hacer un S.O libre de bugs y errores en su instalacion por defecto, auditando constantemente el codigo en busca de posibles fallas.

*Mas integración de software criptografico. OpenBSD se desarrolla en canadá y esto permite toda clase de exportación de software criptografico. Gracias a este detalle OpenBSD ha integrado en muchas partes del sistema operativo toda clase de sistemas criptograficos.

* Sacar aproximadamente cada seis meses una nueva version de OpenBSD, sobre todo para recoger fondos para el proyecto.

4. Modelo de desarrollo de los sistemas *BSD

Asi en terminos generales podriamos decir que los sistemas *BSD se componen de tres ramas bien diferenciadas cumpliendo cada una de ellas un proposito diferente. El nombre que reciben cada una de estas ramas es: La rama -release, la rama -stable y la rama -current.

Nosotros en cualquier momento podemos usar una u otra, todo dependerá de lo que queramos o busquemos.

Para empezar, la rama -release es la rama que se quema en los CD’s de venta o distribucion, es decir, es la version “de corte”. Asi pues si instalamos un *BSD desde el CD de distribucion, ISO oficial que hemos quemado etc, estaremos usando la rama -release.

Continuando con nuestra explicación, la rama -stable, no es mas que la rama -release con los bugs o fallas (que han salido despues de liberar la version -release) corregidos. A esta version normalmente solo se podra actualizar via internet a traves de CVS o CVSUP, y es una rama que se considera estable ya que se van aplicando a ella todos los parches necesarios para corregir los bugs descubiertos.

Por ultimo la rama -current, es la rama mas “inestable” y que mas cambia. Es la rama con los ultimos soportes y ultimas caracteristicas agregadas al S.O. Esta rama la suele usar gente que no necesita para nada una version estable del S.O y gente que sabe que en cualquier momento el sistema operativo puede dejar de funcionar correctamente. Es una version de pruebas por decirlo de alguna manera para ir probando y testeando las nuevas caracteristicas que poseeran en un futuro las ramas -stable y -release. A esta rama al igual que la -stable, lo mas normal es que solo se pueda actualizar por internet via CVS o CVSUP, aunque dependiendo del *BSD tambien puede estar disponible algun snapshot o imagen ISO.

A todas estas ramas se puede acceder facilmente a traves del depósito CVS (Concurrent Version System), que es una herramienta destinada para el control de codigo fuente. Gracias a esta herramienta nosotros podemos “sincronizar” nuestro codigo fuente con cualquiera de las ramas disponibles para posteriormente compilar todas las fuentes.

Despues de comentar un poco acerca de las versiones y herramientas proporcionadas para acceder a estas ramas nos podemos preguntar quien esta detras del proyecto *BSD.

La respuesta es: mucha gente, pero basicamente podriamos dividir a toda esta gente en tres grandes grupos, teniendo cada grupo su importancia y prioridad.

Si tuvieramos que comentar estos grupos en orden jerarquico, empezariamos sin duda por el llamado “core-team”.

El core-team podria ser lo equivalente al conjunto de directores si *BSD fuese una compañia. La tarea del core-team es asegurar el buen camino del proyecto *BSD. Cada mienbro del core team puede tener alguna que otra tarea especifica como por ejemplo la de asegurar que partes importantes del sistema funcionen como se espera. Dependiendo del *BSD este grupo puede constar de mas o menos mienbros y la manera de llegar a ser un mienbro del core team tambien puede variar segun del *BSD del que hablemos. Sin ir mas lejos el core-team de FreeBSD consta de nueve personas, y las ultimas “elecciones” se han llevado a cabo mediante votos democraticos a traves de internet.

En nuestro segundo grupo jerarquico podriamos poner a los llamados “committers” que son ni mas ni menos que las personas que tienen accesso de escritura al codigo fuente albergado en el CVS. Estas personas estan autorizadas para realizar modificaciones en el codigo.

Por ultimo clasificariamos a los contribuyentes externos que son los propios usuarios, y sin duda el grupo mas importante ya que ofrecen sus ideas, aportaciones, parches, codigo etc.

5. Ports y Packages

En esta sección hablaremos sobre una caracteristica que poseen los BSD’s mas destacados, hablaremos de los ports y de los packages.

Que son los ports?

Los ports son unica y exclusivamente los scripts y parches necesarios que se han de aplicar a un programa fuente en concreto (el archivo.tar.gz de toda la vida) para que pueda ejecutarse satisfactoriamente en nuestro sistema.

Que ganamos con todo esto?

Pues bastante, aqui va lo mas destacado:

* Gracias a los ports nos ahorramos el tener que buscar el tar.gz en cuestion por todos los FTP’s ya que el sistema de ports contiene una lista de FTP’s de donde puede descargar automaticamente el programa o la aplicacion.

* Tambien nos ahorramos el tener que controlar las dependencias entre aplicaciones, esto es, si queremos instalar el paquete X pero éste no puede funcionar sin el paquete Y, el sistema de ports descargará y instalará el paquete Y y posteriormente instalara el paquete X.

* Nos proporciona un “esqueleto” de directorios clasificados por secciones, en las cuales podemos encontrar todos los programas ordenados por temas o secciones que estan disponibles para nuestro S.O

* “Nos ahorra” el tener que leer la larga documentación de instalacion que explica la manera en que se ha de instalar el programa. Los ports instalaran la aplicación por nosotros con un solo comando, eso si, con las opciones por defecto y mas comunes si nosotros no le indicamos lo contrario.

* Nos asegura una forma limpia y ordenada en la ubicación de los ejecutables del programa a la hora de copiarlos. Generalmente bajo /usr/local si no le indicamos lo contrario.

* A la hora de posibles actualizaciones o desinstalaciones no tenemos que preocuparnos por borrar todos los archivos y directorios creados en la instalacion, ya que se mantiene una base de datos con todas las aplicaciones instaladas y cada BSD posee los comandos necesarios para borrar limpiamente ports instalados.

Despues de ver las caracteristicas mas significativas de los ports, pondremos a modo de ejemplo los logs de la instalación de un port para que se entienda el funcionamiento de un port.

A modo de ejemplo hemos decidido instalar el conocido navegador en modo texto links. Antes de nada comentamos que la el analisis de este port en concreto a sido llevado en FreeBSD, y que en otros BSD’s puede variar ligeramente algun archivo de configuración o simplemente la ruta del directorio links, pero estos cambios no son importantes para entender la filosofia de los ports.

Todos los ports son instalados bajo el directorio /usr/ports (comumente). Dependiendo del BSD ya los tendremos instalados o se nos preguntara si se desean instalar en la instalacion del BSD. Por otro lado tambien es posible que tengamos que instalarlos nosotros a mano una vez finalizada la instalacion del sistema.

Asi pues nos situamos bajo el directorio /usr/ports y hacemos un ls para que podais ver las diferentes categorias que engloban los ports:

sayaka# cd /usr/ports && ls

.cvsignore benchmarks french math sysutils

INDEX biology ftp mbone textproc

LEGAL cad games misc ukrainian

Makefile chinese german net vietnamese

Mk comms graphics news www

README converters hebrew palm x11

README.html databases irc picobsd x11-clocks

Templates deskutils japanese print x11-fm

Tools devel java russian x11-fonts

archivers distfiles korean science x11-servers

astro editors lang security x11-toolkits

audio emulators mail shells x11-wm

Como podemos ver son muchas las secciones que engloban los ports. Una vez mas comento que en estos directorios no se encuentran los fuentes ni los programas de cada categoria, sino simplemente makefiles, parches y scripts que se encargaran de bajar el port y instalarlo.

Nos situamos en el directorio /usr/ports/www/links que es donde se encuentra el port que queremos instalar y hacemos un ls para ver de que se compone:

sayaka# cd /usr/ports/www/links && ls

Makefile distinfo pkg-comment pkg-plist

README.html files pkg-descr

Nos centraremos en los archivos mas importantes, que en este caso son el Makefile y el directorio files.

El archivo Makefile contiene varias cosas:

*Nombre y version del port

*Nombrte y email de la persona encargada del port

*Categoria en la que se situa el port (en este caso www)

*FTP’s disponibles en los que puede probar el sistema para conectar y descargar el port en cuestion

*etc.

Por otro lado el directorio files contiene los diferentes patchs (parches) que seran aplicados durante la compilación y instalacion del port.

Asi pues, una vez vistos por encima los contenidos del port links vayamos a instalarlo. Para instalarlo unicamente tenemos que teclear “make install” en el directorio /usr/ports/www/links

sayaka# make install

>> links-0.95.tar.gz doesn’t seem to exist in /usr/ports/distfiles/.

>> Attempting to fetch from http://artax.karlin.mff.cuni.cz/~mikulas/vyplody/links/download/.

fetch: links-0.95.tar.gz: size of remote file is not known

Receiving links-0.95.tar.gz: 45056 bytes

449795 bytes transferred in 16.7 seconds (26.25 kBps)

===> Extracting for links-0.95_2

>> Checksum OK for links-0.95.tar.gz.

===> Patching for links-0.95_2

===> Applying FreeBSD patches for links-0.95_2

===> Configuring for links-0.95_2

creating cache ./config.cache

checking for a BSD compatible install… /usr/bin/install -c -o root -g wheel

checking whether build environment is sane… yes

[...] configuracion y compilacion [...]

===> Generating temporary packing list

===> Compressing manual pages for links-0.95_2

===> Registering installation for links-0.95_2

Hemos resumido el log para hacerlo mas corto. Aqui basicamente podemos ver los siguientes pasos para la correcta instalación del port links:

1. Comprobar si el archivo links-0.95.tar.gz (en este caso) se encuentra en el disco duro en local

2. En este caso no se encuentra, por lo tanto se empieza la descarga del archivo en alguno de los FTP’s definidos en el Makefile que vimos anteriormente.

3. Una vez descargado y aunque el log no lo indique, se comprueban las dependencias sobre links. Al no requerir otro paquete adicional para su correcto funcionamiento se pasa a la extracción del links-0.95.tar.gz.

4. Una vez descomprimido se comprueba el cheksum para verificar la integridad del archivo

5. Si todo ha ido bien, se pasa al parcheado del fichero y/o ficheros para la correcta compilacion y instalacion del port (parches que comentabamos antes)

6.En este punto nuestro BSD ya comienza la fase de configuracion (./configure), compilacion (make), y instalacion del programa en cuestion (make install)

7. Finalmente se registra el port en la base de datos para futuras deinstalaciones limpias.

y eso es todo.

Los ports son diariamente modificados, actualizados y parcheados por multitut de personas que se encargan de eso, de tener “al dia” los ports. Nosotros podemos actualizar nuestro arbol de ports (/usr/ports) por CVS o CVSUP.

Pasemos ahora pues a hablar de los packages.

Si los ports eran parches aplicados a programas .tar.gz (sources) de toda la vida, los packages son algo asi como los .rpm o .deb de linux, es decir, los archivos binarios (archivos ya compilados)

Su funcionamiento es parecido al de los ports. Comentemos algunas caracteristicas de ellos:

*Los packages son archivos .tar.gz que engloban archivos binarios + pequeños scripts que definen donde y como se instalaran los ejecutables

*Los packages estan situados en multitut de FTP’s, a diferencia de los ports con los packages “tenemos que ir a los diversos FTP’s a buscarlos”, y pongo esto entre comillas ya que algun BSD dispone de herramientas que no te hacen necesaria la pesada busqueda de un package por el FTP.

*Igual que en los ports, los packages garantizan un buen mecanismo de instalacion/desinstalacion de aplicaciones o programas ya que se hace de una forma controlada y ordenada

*Los packages tambien controlan el tema de las dependencias a la hora de instalar un programa en concreto.

Al igual como en los ports, instalaremos un package para que podais ver lo sencillo y rapido que resulta. Para no pderder la costumbre, instalaremos el package links (esta vez los binarios).

Asi pues una vez bajado el package teclearemos la orden de instalacion de un package:

sayaka# pkg_add links-0.95_2.tgz

El comando pkg_add es usado para instalar packages.

De igual forma sus compañeros pkg_delete borra packages y pkg_info proporciona informacion sobre packages. Podemos teclear la orden pkg_info para que nos muestre una lista de los packages instalados:

sayaka# pkg_info

apache-1.3.17 The extremely popular Apache http server. Very fast, very c

autoconf-2.13 Automatically configure source code on many Un*x platforms

cvsup-bin-16.1 A general network file distribution system optimized for CVS

gettext-0.10.35 GNU gettext package

gmake-3.79.1 GNU version of ‘make’ utility

libtool-1.3.4_2 Generic shared library support script

links-0.95_2 Lynx-like text WWW browser

Efectivamente podemos ver que el links esta instalado correctamente, tambien bajo /usr/local (normalmente) como hacian los ports

Para ver el funcionamiento algo mas interno de un package, cogeremos el archivo de antes links-0.95_2.tgz y en vez de utilizar los comandos pkg* desarrolados para el tratamiento de packages lo descomprimiremos “a mano” para ver de que se compone. Asi que tecleamos:

sayaka# tar -zxvf links-0.95_2.tgz

+CONTENTS

+COMMENT

+DESC

+MTREE_DIRS

man/man1/links.1.gz

bin/links

Como vemos, lo que llama mas la atencion son los archivos que empizan por “+”. El archivo links.1.gz y links son los archivos que compondrian un .tar.gz normal

A modo de resumen, los archivos “+” definen la descripcion del package (de que trata el programa), donde se instalará y de que esta compuesto. No entraremos mas en detalle porque se alargaria demasiado esto.

Para acabar con esta larga sección, me gustaria comentar una ultima nota sobre los ports y los packages.

Cuando nosotros instalamos un port, lo que estamos instalando realmente es un package, es decir, despues de todo el proceso de configuracion y compilacion del port, el BSD en cuestion empaqueta los binarios que ha compilado de los fuentes del port en forma de package de forma temporal, para posteriormente instalar el package que no es otra cosa que un package transformado a partir del port. Con esto deducimos, que tan solo hay una base de datos que controla lo que tenemos y no tenemos instalado, y esta base de datos es controlada por los comandos genericos pkg* (pkg_add, pkg_delete etc.) disponibles para trabajar con packages.

6. Igualdades y diferencias en los *BSD

En este ultimo punto que abarcaremos de la charla, explicaremos de forma general las cosas en comun y las cosas que los hacen diferentes a estos tres *BSD’s

A parte de gran parte de las caracteristicas que hemos comentado anteriormente y del sistema de paquetes, podemos encontrar otras caracteristicas comunes a los *BSD. Pasemos a comentarlas:

Lo mas caracteristico y lo primero que se puede ver tan solo leyendo su nombre es su tipo de licencia. Los *BSD’s tienen gran parte de codigo regido por la licencia BSD. Que dice esta licencia? no me extenderé hablando de las clausulas sobre la BSD, pero para aquellos interesados pueden consultar la web http://www.eldemonio.org donde hay un doc que habla sobre las diferencias entre la BSD y GPL. No obstante si que comentare que la licencia BSD no obliga a adjuntar el codigo fuente junto al programa. Esto mucha gente lo ve bien ya que hace de ella una licencia menos restrictiva, y muchos otros lo ven mal.

Continuando con las igualdades, los sistemas operativos *BSD’s se caracterizan por la manera que tienen de arrancar. En el mundo UNIX hay 2 variantes a la hora de arrancar un S.O, una llamada system V y otra llamada BSD. La mayoria de distribuciones linux usan la system V, pero logicamente los sistemas *BSD usan el metodo BSD.

La principal diferencia entre estas dos maneras de arrancar radica en el lugar donde se situan los scripts de inicializacion. En el estilo System V los podemos encontrar en /etc/rc.d y en BSD estaran en /etc. Todos los scripts de arranque del metodo BSD son llamados rc*

Las particiones en los sistemas *BSD tambien es algo que tienen en comun y que deberiamos comentar. A diferencia de otros sistemas operativos los sistemas *BSD usan una sola particion con su correspondiente sistema de archivos. Dentro de esta particion estan lo llamado ‘slices’ que son algo asi como subparticiones dentro de una particion. Por poner un ejemplo, si quisieramos instalar un sistema BSD con las particiones /var /usr, / y swap tan solo tendriamos que crear una particion con el sistema de archivos correspondiente, y dentro de esta particion BSD creariamos cuatro slices estableciendo sus puntos de montaje /var, /usr , / y el swap. Esto es una gran ventaja respecto a otros SSOO ya que ahorramos entradas de particiones en nuestra tabla.

Como tambien comentabamos antes, los sistemas *BSD albergan todo su codigo fuente en servidores CVS, para que todo aquel que quiera pueda actualizar su S.O

Una vez comentadas algunas de las caracteristicas mas significativas, explicaremos algunas de las cosas que hacen a estos tres SSOO sistemas diferentes.

Como ya habreis podido observar, los dos BSD’s con soporte para mas plataformas son OpenBSD y NetBSD. Este ultimo soporta gran variedad de plataformas (muchas mas que OpenBSD), llegando a poder correr incluso en una consola DreamCast.

FreeBSD por otro lado, es el unico *BSD de estos tres que tiene un soporte estable para trabajar en SMP. Tambien incorpora un boot manager (este ultimo) simple, comodo y eficaz que nos permitirá arrancar cualquier otro S.O que tengamos instalado en nuestro sistema.

Sin duda el *BSD que posee mas aplicaciones y/o programas disponibles es FreeBSD, con una inmensa coleccion de ports y packages. FreeBSD tambien tiene un buen soporte de hardware, a modo de ejemplo, podemos comentar, que es el unico BSD que tiene drivers para la targeta sb live.

OpenBSD por otro lado dispone de drivers para poder usar targetas aceleradoras criptograficas.

Las igualdades y diferencias entre estos tres *BSD son muchas, y nos abarcaria demasiado tiempo y espacio el poder comentarlas todas de forma exhaustiva. Si tuvieramos que diferenciar a estos tres sistemas operativos de forma escueta podriamos decir que:

*FreeBSD es un s.o que se caracteriza por su gran variedad de aplicaciones y su gran optimizacion del codigo para correr a gran velocidad en plataformas i386 y alpha

*NetBSD es sin duda el S.O que mas plataformas soporta, y su objetivo es ser lo mas portable posible

*OpenBSD es un s.o con la idea de ser el s.o mas seguro (si no lo es ya) y la de incorporar todo tipo de criptografia.

7. Conclusión

Como se suele decir siempre, pruebalo y opina. Creo que los objetivos de cada uno de estos tres *BSD son diferentes, y dependiendo de tus necesidades puedes querer instalar uno u otro.

Yo posiblemente si tuviera un servidor sencillo sin demasiadas cargas y sin necesitar aplicaciones extras (server sencillo de mail, ftp etc.) seguramente me quedaria con OpenBSD, ya que me proporciona una seguridad por defecto que posiblemente otros SSOO no me la dan.

Si tuviera que tener algun servidor con abundante trafico y necesitase instalar una gran variedad de aplicaciones o programas extras sin duda me quedaria con FreeBSD. Es raro encontrar programas habituales en linux que no esten disponibles para FreeBSD. FreeBSD me proporciona una gran velocidad y un abundante repertorio de aplicaciones de toda clase.

Finalmente si tuviera que correr algun server con hardware antiguo o poco habitual me quedaria con NetBSD. NetBSD me proporciona soporte para cantidad de plataformas y es raro el tener un ordenador que no pueda ser usado con NetBSD.

Con esto acabo, gracias por la atención y espero que hayan aprendido algo sobre estos sistemas que aun estan algo desconocidos para mucha gente

un saludo

koji@jet.es

Documento original en: http://www.eldemonio.org/documentos/lectura/bsd/charla.html

Podemos encontrarnos el caso de que al instalar desde los ports el programa ‘vim’ éste nos explote en las manos con un fabuloso mensaje error como este:

/usr/libexec/binutils212/elf/ld: cannot find -lXThrStub *** Error code 1 Stop in /usr/ports/x11/XFree86-4-libraries/work/xc/lib/X11. *** Error code 1 Stop in /usr/ports/x11/XFree86-4-libraries/work/xc/lib. *** Error code 1 Stop in /usr/ports/x11/XFree86-4-libraries. *** Error code 1 Stop in /usr/ports/x11-toolkits/gtk12. *** Error code 1 Stop in /usr/ports/editors/vim.978

Para paliar esto deberemos instalar sin el soporte X11 de la siguiente manera:

# cd /usr/ports/editors/vim && make install clean WITHOUT_X11="YES"

En todos los paquetes podemos ver según que opciones tenemos rastreando en el Makefile del mismo.