DISTRIBUCIÓN SOTO LINUX CON SISTEMA DE VIRTUALIZACIÓN

Transcripción

1 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA PROYECTO FIN DE CARRERA DISTRIBUCIÓN SOTO LINUX CON SISTEMA DE VIRTUALIZACIÓN AUTOR: JOSÉ RAMÓN DE SOTO GARCÍA MADRID, JUNIO 2007

2 Autoriza la entrega del proyecto del alumno: LOS DIRECTORES DE PROYECTO Mario Castro Ponce y Rafael Vida Delgado Fdo.: Fecha: / / Vº Bº del Coordinador de Proyectos David Contreras Bárcena Fdo.: Fecha: / /

3 AGRADECIMIENTOS (I) En primer lugar querría dedicar este proyecto a los que sin ellos, esto y estos años no habrían sido posibles, gracias PAPA y MAMA. También a mis directores de proyecto D. Mario Castro Ponce y Rafael Vida Delgado, y a mi coordinador D. David Contreras Bárcena. Tampoco puedo olvidarme de mis dos hermanas Elisa y Machicha, y de mi tía Livia, por su apoyo y sus consejos. Y como no, de mis dos abuelas Elisa y Pepita, gracias por rezar!. A todos y cada una de estas personas expreso mi profunda gratitud. José de Soto I

4 RESUMEN (II) El objetivo inicial de este proyecto fue crear una distribución basada en Linux en modo LiveCd (traducido en ocasiones como CDvivo o CD autónomo). Lo que se pretendía alvergar en este LiveCb era una arquitectura AMP (Apache, Mysql y Php). Para así poder programar con todo movilidad en Php y MySql sin necesidad de hacer la instalación de esta arquitectura. La peculiaridad de estos LiveCd es que no se guarda lo creado o modificado en el sistema operativo LiveCD por lo que hubo que modificarla para que el /home de la distribución estuviese en un penjosedesoto@gmail.comdrive (llavero USB) y en este, atuvieran: los usuarios, configuraciones de Apache, Mysql, Php, archivos generados por los propios usuarios, etc. Así se consigue una mayor portabilidad y comodidad al no tener que preocuparse de almacenar en dispositivos externos los datos, configuraciones creadas, etc. La distribución fue evolucionando y se estudio la posibilidad de hacer esto mismo pero en un pendrive, por lo que se saltaría a la siguiente generación de Live, los llamados LivePen. Así se creo una nueva distribución que permite instalar la distribución LiveCd en un pendrive haciéndola LivePen. Es decir una instalación de una distribución en un pendrive como si fuese en un disco local pero funcionado en distintos ordenadores reconociendo de forma automática el hardware y permitiendo que la información creada, modificada, etc no fuese volátil. Para añadirle mas características diferenciadoras a la distribución se empezó hacer estudios con los sistemas virtuales. Se estudio la posibilidad de añadirle este tipo de herramientas a la LivePen para que se permitiera arrancar en caliente desde Linux o Windows. Así no se necesitaba reiniciar el equipo cada vez que se quisiera iniciar con este. Este estudio dio como resultado la integración de esta tecnológica en las dos distribuciones creadas, la LiveCd y la LivePen generando otras dos que fueron el producto final del proyecto: dsotox LiveCd: Esta distribución tiene la arquitectura AMP en su interior y los cambios se guardan en el pendrive. Gracias a los sistemas virtuales es posible arrancar esta distribución sin necesidad de reiniciar el ordenador. II

5 dsotox LivePen: Esta distribución esta almacenada en un cd permitiéndose arrancar desde ella con la propiedad de LiveCd tradicional y en modo virtual como dsotox LiveCd. Esta posee un instalador que permite la instalación en un pendrive, tanto en modo LiveCd tradicional como en modo LiveCd virtualizado, es decir, se puede hacer la instalación en un pendrive sin necesidad de reiniciar el ordenador. El producto de esta instalación es una distribución en un pendrive que se permite su arranque desde distintos ordenadores, tanto arrancándolos desde la Bios o en modo virtual desde Linux y/o Windows sin necesidad de reiniciar el equipo. III

6 ABSTRACT (III) The initial goal of this project was to create a Linux based distribution in LiveCd mode (also translated like CDvivo or independent CD). What it was tried to host in this LiveCD was an AMP (Apache, Mysql and PhP) architecture that allow to program in PhP and MySQL without need to install this architecture and with independency of the system platform. The peculiarity of these LiveCd is that the changes in the operating system are not saved so the /home directory of this distribution has been placed in a pendrive (key ring USB), storing the system users, configurations of Apache, Mysql and Php, the files generated by these users, etc. Therefore we get a greater portability without having to store them in external devices. This new software distribution become the new generation of LiveCD, named Li vepen. So a new version of this distribution was created which allows to install the LiveCD distribution on a PenDrive. This installation of the distribution using a PenDrive is like if it was in a local hard disk but able to work in different computers, with auto discovery of the hardware and with an easy mechanism to provide persistency of the data created or modified. In order to add more value added features to the distribution we started to analyze the use of virtual systems. We studied the possibility to add this type of tools to the LivePen, to permit hot start up from Linux or Windows systems without the need to restart the computer. As a result of this study, we integrate this technology in the two distributions, (LiveCD and LivePen), generating another two that become the final result of this project: dsotox LiveCD: This distribution has the AMP architecture and the changes are saved in the pendrive. With the use of Virtual Systems is possible to start it up without restart the computer. dsotox LivePen: This distribution is stored in a CD and permits to start it up with the traditional LiveCD features and in virtual mode like dsotox LiveCD. It has an install application that enables the installation in a pendrive, in traditional LiveCD and in virtualized LiveCD, so it is possible to perform the installation in a pendrive without IV

7 restart the computer. The final result of this installation is a pendrive distribution that allows to start up from different computers, either using the BIOS or in virtual mode from the Linux/Windows systems, without the need to restart the computer. V

8 ÍNDICE I. INTRODUCCIÓN QUE ES LINUX? QUE ES UNA DISTRIBUCIÓN? QUE ES UN LIVECD? QUE ES UN SISTEMA DE VIRTUALIZACIÓN?...6 II. IDENTIFICACIÓN DE NECESIDADES...9 DOCUMENTO DE CONCEPTO DEL SISTEMA...10 OBJETIVOS DEL SISTEMA TIPOLOGÍA DE USUARIO...11 ANTECEDENTES III. METODOLOGÍA Y DESARROLLO DESARROLLO DE dsotox LIVECD Personalizar la distribución (Xubuntu )...18 Realización de cambios Se instala apache Se instala Php Se instalan herramientas Modificaciones Sobre el sistema de ficheros Modificaciones sobre apache Modificaciones sobre Mysql PRIMERA BETA SEGUNDA BETA TERCERA BETA CUARTA BETA, RC DESARROLLO DE dsotox PEN...41 Estudio de posibilidades PROBLEMAS, SOLUCIONES Y BETAS...48 Primera versión del Instalador...57 Problemas primera versión beta dsotox...58 IV. ESFUERZO Y ANÁLISIS PRESUPUESTARIO...62 V. GESTIÓN DE LA CONFIGURACIÓN VI. CONCLUSIÓN VII. ANEXO A INSTALACIÓN DE QEMU VIII. ANEXO B MANUAL DE USUARIO dsotox LiveCd dsotox Pen IX. ANEXO C X. GLOSARIO XI. BIBLIOGRAFÍA VI

9 I NTRODUCCIÓN 1

10 QUE ES LINUX? La historia de Linux está fuertemente vinculada a la del proyecto GNU. El proyecto GNU, iniciado en 1983, tiene como objetivo el desarrollo de un sistema Unix completo compuesto enteramente de software libre. Hacia 1991, cuando la primera versió del núcleo Linux fue liberada, el proyecto GNU habrá producido varios de los componentes del sistema operativo, incluyendo un intérprete de comandos, una biblioteca C y un compilador, pero aún no contaba con el núcleo que permitiera completar el sistema operativo. Entonces, el núcleo creado por Linus Torvalds, quien se encontraba por entonces estudiando en la Universidad de Helsinki, llenó el hueco final que el sistema operativo GNU exigía. Subsecuentemente, miles de programadores voluntarios alrededor del mundo han participado en el proyecto, mejorándolo continuamente. Torvalds y otros desarrolladores de los primeros días de Linux adaptaron los componentes de GNU y de BSD, así como de otros muchos proyectos como Perl, Apache, Python, etc. para trabajar con el núcleo Linux, creando un sistema operativo completamente funcional procedente de muchísimas fuentes diferentes, la mayoría libres. 2

11 QUE ES UNA DISTRIBUCIÓN? Una distribución es un conjunto de aplicaciones reunidas por un grupo, empresa o persona para permitir instalar fácilmente un sistema Linux. Es un sabor de Linux. En general se destacan por las herramientas para configuración y sistemas de paquetes de software a instalar. Existen numerosas distribuciones Linux (también conocidas como "distros"), ensambladas por individuos, empresas y otros organismos. Cada distribución puede incluir cualquier número de software adicional, incluyendo software que facilite la instalación del sistema. La base del software incluido con cada distribución incluye el núcleo Linux y las herramientas GNU, al que suelen adicionarse también varios paquetes de software. Las herramientas que suelen incluirse en la distribución de este sistema operativo se obtienen de diversas fuentes, incluyendo de manera importante proyectos de código abierto o libre, como el GNU y el BSD o el KDE. Debido a que las herramientas de software libre que en primera instancia volvieron funcional al núcleo de Linux provienen del proyecto GNU que desde 1983 habrá liberado software que pudo ser usado en el proyecto de Linux de 1991, Richard Stallman (fundador del proyecto GNU) pide a los usuarios que se refieran a dicho sistema como GNU/Linux. A pesar de esto, la mayoría de los usuarios continúan llamando al sistema simplemente "Linux" y las razones expuestas por Richard Stallman son eterno motivo de controversia. La mayoría de los sistemas "Linux" incluyen también herramientas procedentes de BSD y de muchos otros proyectos como Mozilla, Perl, Ruby, Python, PostgreSQL, MySQL, Xorg, casi todas con licencia GPL o compatibles con ésta (LGPL, MPL) otro aporte fundamental del proyecto GNU. Usualmente se utiliza la plataforma XFree86 o la X.Org para sostener interfaces gráficas. 3

12 QUE ES UN LIVECD? Un LiveCD o LiveDVD (traducido en ocasiones como CDvivo o CD autónomo) es un sistema operativo (normalmente acompañado de un conjunto de aplicaciones) almacenado en un medio extraíble, tradicionalmente un CD o un DVD (de ahí su nombre), que puede ejecutarse desde este sin necesidad de instalarlo en el disco duro del ordenador, para lo cual usa la memoria RAM como disco duro virtual y el propio medio como sistema de ficheros. Algunos LiveCD incluyen una herramienta que permite instalarlos en el disco duro. Otra característica es que por lo general no se efectúan cambios en la computadora utilizada, aunque algunos pueden almacenar preferencias si así se desea. Para usar un LiveCD es necesario obtener uno (muchos de ellos distribuyen libremente una imagen ISO que puede bajarse de Internet y grabarse en disco) y configurar el ordenador para que arranque desde la unidad lectora, reiniciando luego el ordenador con el disco en la lectora, con lo que el LiveCD se iniciará automáticamente. La mayoría usa un sistema operativo basado en el núcleo Linux, pero también se usan otros sistemas como BeOS, FreeBSD, Minix, Solaris, OS/2 o incluso Microsoft Windows (sin embargo, distribuir un LiveCD de éste último es ilegal). El primer LiveCD Linux fue Yggdrasil Linux en 1995, aunque fue poco exitosa. Posteriormente surgiría DemoLinux (año 2000). El auge de esta modalidad de Linux se inicia alrededor del año 2003 con la distribución alemana de Knoppix, basada, a su vez, en la distribución de software Debian. Una de las mejoras de este método fue la compresión cloop, esto permitía sobrepasar los MB del CD (se usaba el driver loop) y lograr introducir hasta 2 GB. La asociación española de Hispalinux ha popularizado un sistema propio, denominado Metadistros fundamental en las distribuciones Linex y Guadalinex. 4

13 Uno de los mayores inconvenientes de este sistema es el requerimiento de una gran cantidad de memoria RAM (256 son más que suficientes y hay distribuciones que funcionan perfectamente en 128), una parte para su uso habitual y otra para funcionar como el disco virtual del sistema. En el arranque, se le pueden dar distintos parámetros para adaptar el sistema al computador, como la resolución de pantalla o para activar o desactivar la búsqueda automática de determinado hardware. 5

14 QUE ES UN SISTEMA DE VIRTUALIZACIÓN? El sentido original del término virtualización, nacido en 1960, es el de la creación de una máquina virtual utilizando una combinación de hardware y software. Para nuestra conveniencia vamos a llamar a esto virtualización de plataforma. El término máquina virtual aparentemente tiene su origen en el experimento del sistema de paginación (paging system) de IBM M44/44X. La creación y administración de las máquinas virtuales también se refiere a la creación de seudo máquinas, en los primeros días de la CP 40, y de virtualización de servidores más recientemente. Los términos virtualización y máquina virtual han adquirido, a través de los años, significados adicionales. La virtualización de plataforma es llevada a cabo en una plataforma de hardware mediante un software host (un programa de control) que simula un entorno computacional (máquina virtual) para su software guest. Este software guest, que generalmente es un sistema operativo completo, corre como si estuviera instalado en una plataforma de hardware autónoma. Típicamente muchas máquinas virtuales son simuladas en una máquina física dada. Para que el sistema operativo guest funcione, la simulación debe ser lo suficientemente robusta como para soportar todas las interfaces externas de los sistemas guest, las cuales pueden incluir (dependiendo del tipo de virtualización) los drivers de hardware. Existen muchos enfoques a la virtualización de plataformas, aquí se los listamos basándonos en cuán completa es implementada una simulación de hardware (estos términos no son reconocidos universalmente como tales, sin embargo todos los conceptos pueden ser encontrados en los libros). Emulación o simulación: la máquina virtual simula un hardware completo, admitiendo un sistema operativo sin modificar para una CPU completamente diferente. Este enfoque fue muy utilizado para permitir la creación de software para nuevos procesadores antes de que estuvieran físicamente disponibles. Por ejemplo Bochs, PearPC, Qemu sin aceleración, y el emulador Hercules. La emulación es puesta en 6

15 práctica utilizando una variedad de técnicas, desde state machines hasta el uso de la recopilación dinámica en una completa plataforma virtual. Virtualización nativa y virtualización completa: la máquina virtual simula un hardware suficiente para permitir un sistema operativo guest sin modificar (uno diseñado para la misma CPU) para correr de forma aislada. Típicamente, muchas instancias pueden correr al mismo tiempo. Este enfoque fue el pionero en 1966 con CP 40 y CP[ 67]/CMS, predecesores de la familia de máquinas virtuales de IBM. Algunos ejemplos: VMware Workstation, VMware Server, Parallels Desktop, Adeos, Mac on Linux, Win4BSD, Win4Lin Pro y z/vm. Virtualización parcial (y aquí incluimos el llamado address space virtualization la máquina virtual simula múltiples instancias de mucho (pero no de todo) del entorno subyacente del hardware, particularmente address spaces. Este entorno admite compartir recursos y aislar procesos, pero no permite instancias separadas de sistemas operativos guest Aunque no es vista como dentro de la categoría de máquina virtual, históricamente éste fue un importante acercamiento, y fue usado en sistemas como CTSS, el experimental IBM M44/44X, y podrá decirse que en sistemas como OS/VS1, OS/VS2 y MVS. Paravirtualización: la máquina virtual no necesariamente simula un hardware, en cambio ofrece una API especial que solo puede usarse mediante la modificación del sistema operativo guest. La llamada del sistema al hypervisor tiene el nombre de hypercall en Xen y Parallels Workstation; está implementada vía el hardware instruction DIAG ( diagnose ) en el CMS de VM en el caso de IBM (este fue el origen del término hypervisor). Ejemplo: VMware ESX Server, Win4Lin 9x y z/vm. Virtualización a nivel del sistema operativo: virtualizar un servidor físico a nivel del sistema operativo permitiendo múltiples servidores virtuales aislados y seguros correr en un solo servidor físico. El entorno del sistema operativo guest comparte el mismo sistema operativo que el del sistema host (el mismo kernel del sistema operativo es 7

16 usado para implementar el entorno del guest ). Las aplicaciones que corren en un entorno guest dado lo ven como un sistema autónomo. Ejemplos: Linux VServer, Virtuozzo, OpenVZ, Solaris Containers y FreeBSD Jails. Virtualización de aplicaciones: consiste en el hecho de correr una desktop o una aplicación de server localmente, usando los recursos locales, en una máquina virtual apropiada. Esto contrasta con correr la aplicación como un software local convencional (software que fueron instalados en el sistema). Semejantes aplicaciones virtuales corren en un pequeño entorno virtual que contienen los componentes necesarios para ejecutar, como entradas de registros, archivos, entornos variables, elementos de uso de interfaces y objetos globales. Este entorno virtual actúa como una capa entre la aplicación y el sistema operativo, y elimina los conflictos entre aplicaciones y entre las aplicaciones y el sistema operativo. Los ejemplos incluyen el Java Virtual Machine de Sun, Softricity, Thinstall, Altiris y Trigence (esta metodología de virtualización el claramente diferente a las anteriores; solo una pequeña línea divisoria los separa de entornos de máquinas virtuales como Smalltalk, FORTH, Tel, P code). 8

17 IDENTIFICACIÓN DE NECESIDADES 9

18 DOCUMENTO DE CONCEPTO DEL SISTEMA 1. OBJETIVOS DEL SISTEMA Se pretende desarrollar una distribución basada en Linux en modo LiveCd (traducido en ocasiones como CDvivo o CD autónomo). Es un sistema operativo (normalmente acompañado de un conjunto de aplicaciones) almacenado en un medio extraíble, tradicionalmente un CD (de ahí su nombre), que puede ejecutarse desde éste sin necesidad de instalarlo en el disco duro del ordenador, para lo cual usa la memoria RAM como disco duro virtual y el propio medio como sistema de ficheros. Algunos LiveCD incluyen una herramienta que permite instalarlos en el disco duro. Otra característica es que por lo general no se efectúan cambios en la computadora utilizada (no se guarda lo creado o modificado en el sistema operativo LiveCD). La distribución a crear pretende romper con esta ultima generalidad y crear una arquitectura LAMP (Linux, Apache, Mysql y Php). Para ello se trasladará el /home de la distribución a un pendrive (llavero USB) y en este, atarán: los usuarios, configuraciones de Apache, Mysql, Php, archivos generados por los propios usuarios, etc. Así se consigue una mayor portabilidad y comodidad al no tener que preocuparse de almacenar en dispositivos externos los datos, configuraciones creadas, etc. Dado que los sistemas e arranque de los ordenadores actuales han evolucionado hasta el punto de permitir arrancar desde los dispositivos USB. Se ha planteado crear una distribución completamente almacenada en un Pendrive y que este fuese totalmente portable y configurable (como una estalación local) entre las distintas arquitecturas 386. Para añadir mas características a esta distribución se ha pensado en añadirle sistemas de virtualización para permitir arrancarla e instalarla sin necesidad de reiniciar el ordenador y desde distintos sistemas operativos (Linux y Windows). 10

19 2. TIPOLOGÍA DE USUARIO La primera distribución (dsotox LiveCd) esta pensado para estudiantes de la asignatura de PHP de la Universidad de Comillas. Necesitan desarrollar aplicaciones en una arquitecturas AMP (Apache, Mysql y Ph). Cada año necesitan crearse y configurarse este sistema. Esta distribución facilita el desarrollo, ya que AMP ya esta montado sobre Linux y permite una flexibilidad en el desarrollo entre casa y universidad. La segunda distribución (dsotox Pen) no se ha pensado para ningún usuario ni arquitectura en concreto. Pero el interés por esta ha dado que evolucionara pensado para Auditorías de Seguridad, lo que implico la instalación en ella de dichas herramientas. 3. ANTECEDENTES La idea de distribución esta mas que difundida, por lo que no es nada nuevo lo que en un principio se pretende desarrollar. Por este motivo la distribución creada va a estar basada en otras. Se ahorra tiempo en desarrollo y se garantiza una estabilidad y seguridad dada la experiencia de otros usuarios o empresas sobre este sistema operativo (Linux) y la creación de distribuciones. 11

20 METODOLOGÍA Y DESARROLLO 12

21 El desarrollo de este tipo de sistemas requiere mucha investigación y sobre todo pruebas. Cada cambio o modificación sobre algún Script, paquete, etc requiere la generación de una nueva distribución (imagen Iso, en nuestro caso) y el testeo del mismo. Este tipo de desarrollo es muy lento dado que: Crear una Iso (distribución) 20 y 90 minutos. Arrancar la distribución: 2 minutos. Por este motivo la forma de desarrollo va a ser a base de prototipos. Se programan los Scripts (un número elevado), se modifica la distribución (lo mas posible) sobre un ordenador anfitrión, así se ve de forma rápida los cambios. Después se genera la beta. Así de esta manera se genera un número pequeños de betas pero con un número alto de errores, que en versiones posteriores se subsanan. La metodología empleada será un modelo en espiral donde se utilizan 4 etapas (Figura 1): 1. Planificación: determinación de objetivos, alternativas y restricciones. 2. Análisis de riesgo: análisis de alternativas e identificación/resolución de riesgos. 3. Ingeniería: desarrollo del producto del "siguiente nivel", 4. Evaluación del cliente: Valorización de los resultados de la ingeniería. Figura 1 13

22 Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y las restricciones, y se analizan e identifican los riesgos. Si el análisis de riesgo indica que hay una incertidumbre en los requisitos, se puede usar la creación de prototipos en el cuadrante de ingeniería para dar asistencia tanto al encargado de desarrollo como al cliente. El cliente evalúa el trabajo de ingeniería (cuadrante de evaluación de cliente) y sugiere modificaciones. Sobre la base de los comentarios del cliente se produce la siguiente fase de planificación y de análisis de riesgo. En cada bucle alrededor de la espiral, la culminación del análisis de riesgo resulta en una decisión de "seguir o no seguir". Con cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se construyen sucesivas versiones del software, cada vez más completa y, al final, al propio sistema operacional. 14

23 DESARROLLO DE dsotox LIVECD Primero se hizo un estudio sobre las diferentes distribuciones del mercado existentes. La experiencia sobre este sistema operativo y el mercado del mismo hace el descarte de todas a excepción de dos: Knoppix Ubuntu Hay dos grandes ramas de distribuciones en el mercado: las basadas en RedHat (paquetes.rpm) y las basadas en Debian (paquetes.deb). En la rama de RedHat hay cuatro destacables: Mandriva. OpenSuse. Fedora (RedHat gratuita). Knoppix. En la rama de Debian hay dos destacables: Debian. Ubuntu. Lo que se busca es una distribución con alto reconocimiento de Hardware, cercana al usuario. Ya que esta será usada en ocasiones por estudiantes primerizos en este sistema operativo. 15

24 Mandriva: Mandriva tiene un alto reconocimiento de Hardware y su acercamiento hacia el usuario es altísimo, pero su continua inclinación hacia las actualizaciones de pago, la tardanza en sacar nuevas versiones y la poca documentación sobre ella, hizo descartarla. OpenSuse: La poca familiarización sobre esta distribución quizá hizo que se descartara. También debido a que esta está en DVD, lo que pone una restricción al proyecto pudiéndola evitar. Fedora: No posee versión en LiveCd. Knoppix: Es una distribución muy difundida gracias a su alto reconocimiento de Hardware y al ser una de las distribuciones que mas han evolucionado con respecto a las versiones LiveCd. Se decanto por la serie Ubuntu. Debian: Una distribución muy orientada a usuarios expertos, la instalación es algo compleja aunque ha evolucionado gracias al desarrollo de Ubuntu. Este tipo de distribución merece especial atención por el gran crecimiento que esta teniendo en España gracias a proyectos como Ubuntu, LinEx, etc. Ubuntu: Es una distribución basada en Debian, es un Debian orientado 100% al usuario. En estos últimos años han creado unas distribuciones con un reconocimiento de Hardware muy parecido e incluso en ocasiones superior a la toda poderosa Knoppix. Es 100% gratuita, con un numero elevado de repositorios (software), se presenta en tres escritorios: Genome, Kde y Xfce y la documentación sobre esta crece por horas. Tras el nacimiento de Ubuntu, nacieron los proyectos Kubuntu y Xubuntu entre otros: Kubuntu: con escritorio Kde. Xubuntu: con escritorio Xfce. 16

25 En una primera instancia se opto por empezar el desarrollo con Kubuntu Es un escrito muy versátil, fácil de usar e intuitivo pero con un alto coste de consumo de recursos Hardware. Lo que hizo que se estudiara la alternativa de Xubuntu Xubuntu esta basado en el escritorio Xfce. Es un escritorio muy liviano con un coste en consumo de recursos hardware medio. Esta entre la utilidad y la sencillez. Perfecto para ser usado desde un CD ya que este sistema es considerablemente mas lento que una instalación en un disco local. 17

26 Personalizar la distribución (Xubuntu ) Requerimientos del sistema 3 o 5 gigas bytes de espacio en el disco duro. En mi caso 1GB de memoria Ram. squashfs utils. mkisofs. Un kernel Ubuntu con soporte squashfs Qemu para las pruebas. Cd Desktop oficial de Xubuntu ( Añadir, que para un rápida creación de imágenes Iso, se requiere un procesador de ultima generación. Un portátil con procesador Pentiun IV y 1GB de Ram, tarda en generar la Iso final una media de 90 minutos. Un portátil con procesador Sempron Movile 1600 y 1GB de Ram, Tarda en generar esa misma Iso unos 20 minutos. Esta situación hizo adquirir los siguientes componentes hardware: Portátil con procesador de ultima generación. Pendrive de 2 GB de almacenamiento (dsotox Pen). 18

27 Instalación de los componentes: Se Instalan las herramientas necesarias: $ sudo apt get install squashfs tools mkisofs Nota: Para la instalción de qemu se ha preferido hacerlo desde los fuentes con el modulo kqemu para un mayor rendimiento. La explicación de la instalación esta en el ANEXO A. Se Carga el modulo squashfs $ sudo modprobe squashfs Se crea una carpeta donde se hará el desarrollo $ mkdir ~/live Se mueve Xubuntu a al direcctorio creado $ mv xubuntu desktop i386.iso ~/live $ cd ~/live Extracción del contenido del CD: Se monta la.iso $ mkdir mnt $ sudo mount o loop xubuntu desktop i386.iso mnt Se copian los componentes de la mnt al directorio extract cd $ mkdir extract cd $ rsync exclude=/casper/filesystem.squashfs a mnt/ extract cd Hasta aquí se ha extraído lo que se vería en el livecd. Es decir lo que se ve para el usuario cuando monta el sistema de ficheros del Cd. 19

28 Extracción del sistema: Se monta el sistema de ficheros squashfs $ mkdir squashfs $ sudo mount t squashfs o loop mnt/casper/filesystem.squashfs squashfs Copiamos el contenido de squashfs a la capeta 'edit' $ mkdir edit $ sudo cp a squashfs/* edit/ Notas: edit: carpeta donde se realizarán todos los cambios sobre la distribución. extract c: carpeta donde se realizaran los cambios sobre el contenido del CD. Preparamos el chroot: $ sudo chroot edit $ sudo mount t proc proc proc $ sudo mount t sysfs sys sys De esta manera entramos en la carpeta edit como si fuese nuestro propio sistema. Desde el prompt que se ha realizado chroot no se puede acceder al sistema anfitrión, es decir el sistema desde el cual se ha realizado el chroot. Todo cambio realizado aquí, se vera afectado en la futura distribución a crear. Se realizan los cambios: Los cambios realizados en la distribución son diversos: Instalaciones de paquetes. Eliminaciones de paquetes. 20

29 Modificación de Scripts. Programación de Scripts. Modificaciones en el arranque del sistema. Modificaciones el apagado del sistema, etc. Por este motivo se describen mas adelante (apartado de realización de cambios, página 20) paso a paso las distintas modificaciones que dan lugar la primera versión beta de dsotox LiveCd. Tras los cambios realizados arriba se realizan los siguientes pasos: Se limpia el temporal, se desmonta los sistemas de ficheros especiales y se sale de chroot $ sudo umount proc $ sudo umount sys $ sudo rm rf /tmp/* $ exit Se pone el CD junto y se crea la.iso Se regenera manifest chmod +w extract cd/casper/filesystem.manifest sudo chroot edit dpkg query W showformat='${package} ${Version}\n' > extract cd/casper/filesystem.manifest Se comprime el sistema de ficheros $ sudo rm extract cd/casper/filesystem.squashfs $ sudo mksquashfs edit extract cd/casper/filesystem.squashfs Se cambia el nombre de la imagen en extract cd/readme.diskdefines $ sudo vim extract cd/readme.diskdefines Se cacula la suma de md5 $ (cd extract cd && find. type f print0 xargs 0 md5sum > md5sum.txt) 21

30 Se crae la Iso $ cd extract cd $ mkisofs r V "$IMAGE_NAME" cache inodes J l b isolinux/isolinux.bin c isolinux/boot.cat no emul boot boot load size 4 boot info table o../cdname.iso. Se pruebe el Cd Se prueba la imagen creada con el emulador qemu $ qemu cdrom cdname.iso boot d 22

31 Realización de cambios Se instalan los siguientes paquetes: Actualizamos los repositorios sudo apt get update Se instala apache2: sudo apt get install apache2 apache2 doc lynx ca certificates Ejemplo, bajo Konsole (terminal del escritorio Kde) Se instala MySql: sudo apt get install mysql server 5.0 libcompress zlib perl sudo apt get install mailx 23

32 Se instala Php: sudo apt get install php5 php5 mysql php pear php5 cgi php5 gd php5 ldap php5 mhash php5 odbc sudo apt get install php5 xmlrpc php5 xsl sudo apt get install phpmyadmin apt get install php fpdf Suggested packages: ttf2pt1 The following NEW packages will be installed: php fpdf apt get install libmyodbc The following NEW packages will be installed: libmyodbc 24

33 Se instalan herramientas: apt get install phpmyadmin Se desinstalan paquetes: sudo apt get remove mozilla thunderbird sudo apt get remove gnumeric gtk sudo apt get hotkey setup (Auto configuracion de teclas especuales en portatiles) sudo apt get hplip(sistema de impresion HP) sudo apt get hplip data sudo apt get hpijs driver gs IJS para impresoras y o escaners HP Se purga todo lo desinstalado: dpkg l awk '/^rc/ {print $2}' xargs sudo dpkg purge 25

34 Modificaciones Sobre el sistema de ficheros : Lo primero fue trasladar el directorio /home del sistema de ficheros Linux al pendrive. Así de esta manera los usuarios, los archivos creados por estos, las configuraciones particulares sobre el entorno gráfico, etc se mantuvieran guardados y no se volatizaran en el apagado del Sistema de operativo. Para solucionar esto se creo un Script que en primera instancia lo que hace es una detección de los dispositivos Usb (pendirve) conectados al ordenador. Esto se consiguió gracias a un bucle While, undev y grep: #Buscamos y mostramos los Pendrive conectados al ordenador udevinfo e egrep '/block/sd ID_SERIAL' while IFS=" " read nombreaux do 26

35 El usuario selecciona el Usb que quiere arrancar. Como el sistema de ficheros de Linux ya esta montado, y el usuario por defecto de Ubuntu esta creado. Lo que se hace es mover ese /home al pendrive y hacer un enlace en el sistema de ficheros de sistema Live cargado en memoria al dispositivo donde se ha copiado ese /home. # $puntomontaje es el directororio raiz del Pendrive seleccionado. mv /home $puntomontaje cd / sudo ln s $puntomontaje/home home Dentro de este home se crea una carpeta llamada config que tiene la siguiente estructura de directorios: apache2: Archivos relacionados con Apache. mysql: Archivos relacionados con MySQL..sistema: Archivos relacionados con el sistema: usuarios, grupos, etc. Modificaciones sobre apache : La instalación principal por defecto de Apache es la siguiente: /etc/apache2: configuración del servidor. /var/www: ubicación de los archivos del servidor. /usr/sbin/apache2ctl: binario de ejecución de apache. /etc/init.d/apache2: servicio de apache. /usr/sbin/apache2 ssl certificate: ssl para apache2. Para que dsotox funcione en modo LiveCd sin pendrive (sin guardar modificaciones) y en modo LiveCd con prendrive (guardando las modificaciones en el Usb). Los archivos arriba citados deben ser modificados y almacenados en algún lugar del LiveCd. Estos archivos 27

36 modificados sustituirán a los originales en caso que el arranque del sistema sea con Pendrive. Con las modificaciones que se describirán a continuación se pretende crear en una carpeta (dsotox) en /etc que almacenará todos estos archivos modificados. Este directorio contendrá la siguiente estructura: apache2: Contiene las configuraciones, módulos, ssl, etc de apache. sistema: Contendrá archivos modificados del arranque de apache2. Lo primero fue modificar el archivo de ejecución de arranque para poder cambiar la configuración por defecto. Apache por defecto crea una carpeta /etc/apache2 donde se guarda toda la configuración del servidor. Cambios sombre el fichero de arranque apache2 que se encuentra en /etc/init.d Este Script de arranque llama a /usr/sbin/apache2ctl que este a su vez ejecuta el binario, /usr/sbin/apache2. Este ultimo no se puede modificar al ser un archivo binario y cuya configuración por defecto hace referencia al fichero configuración ubicado en /etc/apache2. Para solucionar esto y hacer que /usr/sbin/apache2 mire la configuraron en /home/config/apache2/apache2 se ha modificado el Script /usr/sbin/apache2ctl: # the path to your httpd binary, including options if necessary HTTPD='/usr/sbin/apache2' 28

37 Se ha modificado por esta otra: # the path to your httpd binary, including options if necessary HTTPD='/usr/sbin/apache2 f /home/config/apache2/apache2/apache2.conf' En este fichero /usr/sbin/apache2ctl también se han modificado las diferentes lineas que hacían referencia al fichero de configuración situado en /etc: # pick up any necessary environment variables if test f /etc/apache2/envvars; then. /etc/apache2/envvars fi Se ha modificado por esta otra: # pick up any necessary environment variables if test f /home/config/apache2/apache2/envvars; then. /home/config/apache2/apache2/envvars fi En los archivos de configuración del servidor apache hubo que adaptarlos a la nueva configuración: 1. Cambiar las rutas de la ubicación de los módulos en el fichero apache2.conf ServerRoot "/home/config/apache2/apache2" # Include module configuration: Include /home/config/apache2/apache2/mods enabled/*.load Include /home/config/apache2/apache2/mods enabled/*.conf # Include all the user configurations: Include /home/config/apache2/apache2/httpd.conf # Include ports listing Include /home/config/apache2/apache2/ports.conf # Include generic snippets of statements Include /home/config/apache2/apache2/conf.d/[^.#]* 29

38 # Include the virtual host configurations: Include /home/config/apache2/apache2/sites enabled/[^.#]* 2. Cambiar los enlaces truncados en la carpeta de los módulos activados, en este caso en la carpeta mods enabled. Estos enlaces apuntaban a la ubicación donde se encontraban los módulos anteriormente. 3. Cambiar el enlace de la configuración por defecto de apache. Estaba roto como en el caso anterior. Apuntaba a una dirección ya no existente (/etc/apache2/sites avaliable). 4. Cambiar la ubicación de DocumentRoot, es decir donde se ubicaran la paginas web. Estas estaban en /var/www. Ahora se ubicaran en /home/config/apache2/www. Para la modificación de este, se ha tenido que modificar el fichero /home/config/pache2/apache2/sites avalible/default. La lineas modificadas son: DocumentRoot /home/config/apache2/www <Directory /home/config/apache2/www> Para la incorporación del modulo SSL en apache se ha tenido que realizar lo siguiente: Generar un certificado SSL Modificar el fichero /usr/sbin/apache2 ssl certificate para adaptarlo a la configuración descrita anteriormente. Se loguea como root y se ejecuta el script /usr/sbin/apache2 ssl certificate. Hacemos una copia del siguiente archivo /etc/apache2/sites available/default y lo llamamos por ejemplo ssl dejando en la carpeta de sites avaible Hacemos un link simbólico al nuevo archivo desde la carpeta de sitios activados. ln s /etc/apache2/sites available/ssl /etc/apache2/sites enabled/000 ssl 30

39 Como el ssl escucha por el puerto 443 añadimos este parametro en el archivo: /etc/apache2/ports.conf con la instrucción: Listen 443 Editamos el archivo creado ssl en /etc/apache2/sites available/ssl con los siguientes cambios. Cambiamos el puerto 80 por el 443. Añadimos las siguientes lineas a la sección VirtualHost que ahora deberia parecerse a esto: NameVirtualHost *:443 <VirtualHost *:443> ServerAdmin webmaster@localhost DocumentRoot /home/config/apache2/www <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /home/config/apache2/www> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all # Uncomment this directive is you want to see apache2's # default start page (in /apache2 default) when you go to / #RedirectMatch ^/$ /apache2 default/ </Directory> ScriptAlias /cgi bin/ /usr/lib/cgi bin/ <Directory "/usr/lib/cgi bin"> AllowOverride None Options +ExecCGI MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> 31

40 ErrorLog /var/log/apache2/error.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn CustomLog /var/log/apache2/access.log combined ServerSignature On SSLEngine On#Nueva linea SSLCertificateFile /home/config/apache2/apache2/ssl/apache.pem #Nueva linea Alias /doc/ "/usr/share/doc/" <Directory "/usr/share/doc/"> Options Indexes MultiViews FollowSymLinks AllowOverride None Order deny,allow Deny from all Allow from / ::1/128 </Directory> </VirtualHost> Reiniciamos apache2 con /etc/init.d/apache2 restart En el caso de que el sistema se arranque en modo LiveCd normal. Los archivos de configuración de apache por defecto se mantienen intactos. En caso contrario, con los archivos de configuración almacenados en la estructura de ficheros anteriormente descrita se realizan las siguientes operaciones sobre el enlace simbólico /home que apunta al directorio home situado en el Pendrive: #Creando los archivos de configuración de apache y el lugar del servidor mkdir apache2 cp r /etc/dsotox/apache2 /home/config/apache2/ 32

41 cp r /var/www /home/config/apache2/ #Eliminando antiguos archivos de configuracion e apache y el lugar del servidor rm r /etc/apache2 rm r /var/www #Actulizando archivos de arranque de apache cd /etc/dsotox/sistema/apache2 cp apache2ctl /usr/sbin/apache2ctl cp apache2 /etc/init.d/apache2 cp apache2 ssl certificate /usr/sbin/apache2 ssl certificate Si la configuración ya fue creada en alguna sesión anterior solamente hace falta cambiar los archivos de arranque de apache. Así hace referencia a /home, que ya contiene los archivos de configuración, el lugar del servidor, etc. if test d "/home/config/apache2"; then #Actulizando archivos de arranque de apache cd /etc/dsotox/sistema/apache2 cp apache2ctl /usr/sbin/apache2ctl cp apache2 /etc/init.d/apache2 cp apache2 ssl certificate /usr/sbin/apache2 ssl certificate Después de migrar apache y probar que este funcionaba sobre el ordenador anfitrión hubo que juntar todas las piezas, antes descritas en un Script que se arrancara al inicio y modificara y creara de forma automática toda la estructura de ficheros descrita. Para ello se creo un Script (dsotox) ubicado en /etc/dsotox. Este Scritp había que arrancarlo después de la detección del hardware, para que permitiera la detección de los dispositivos Usb y después de haberse montado todo el sistema de fichero originales del sistema operativo Linux, para permitir realizar las modificaciones pertinentes sobre este. Este Script se llamo en el servicio: mountall (exec /etc/dsotox/dsotox.sh). Este Script solo es lanzado en caso de que haya pendrive conectados al ordenador. 33

42 Después de solucionar esto se planteo otro problema. Mantener actualizado ciertos ficheros: /etc/passwd: Contiene el mapa de nombres de usuarios, identificaciones de usuarios y la ID del grupo primario al que pertenece esa persona. También puede contener el fichero real, aunque es más probable (y mucho más seguro) que utilice contraseñas con shadow para mantener las contraseñas en /etc/shadow. /etc/group: El fichero de grupos contiene toda la información de pertenencia a grupos, y opcionalmente elementos como la contraseña del grupo. /etc/shadow: Alberga pares de nombres de usuario y contraseñas, así como información contable, como la fecha de expiración, y otros campos especiales. Esto se solucionó creando un Script que se ejecuta y copia dichos archivos en el apagado del sistema, justo antes de desmontar los sistemas de ficheros. Este Script es ejecutado en /etc/init.d/umountroot: if test h /home; #Si es un enlace se ejecuta el Script then exec /etc/dsotox/dsotoxsalir fi Modificaciones sobre Mysql : Lo que primero se hizo con mysql fue trasladar las tablas a /home. Para ello se modificó el fichero de configuración my.cnf situado en /etc/mysql modificando parámetros de mysqld: [mysqld] user = mysql pid file= /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql Se modifico por: datadir= /home/config/mysql/mysql tmpdir = /tmp language = /usr/share/mysql/english 34

43 Para que esto funcionara tanto en versión Pen como en versión LiveCd, se creo este archivo de configuración modificado y se guardo en /etc/dsotox/mysql. Cuando se arranca en modo LiveCd con Pen se sustituye por el original. Lo que se pretendió realizar después, fue trasladar este archivo de configuración a /home. Tal como se hizo con Apache2. Esto presentó muchos problemas con la estabilidad de Mysql. Por motivos de seguridad no permite realizar estos cambios de forma tan flexible como en Apache. Dada la dificultad de esta y la posibilidad de otras configuraciones de mysql, se optó por otra opción. Mysql permite guardar las configuraciones de su fichero my.cnf y que este sea reconocido en el arranque del servicio de tres formas: 1. "/etc/mysql/my.cnf": Para configuraciones globales. Esta por defecto. Como esta en LiveCd no permite modificaciones permanentes. 2. "/var/lib/mysql/my.cnf": Para configuraciones especificas del servidor. Al estar las tablas situadas en /home este tipo de opción permite guardar las configuraciones de forma permanente. 3. ~/.my.cnf": Para configuraciones especificas de cada usuario. Haciendo una copia de my.cnf en el /home de cada usuario. Con las dos ultimas opciones se subsana de una forma mas estable y fiable el problema de hacer permanentes las modificaciones del servidor de Base de datos Mysql. 35

44 PRIMERA BETA La primera Beta de dsotox Live se hizo con la instalación de APACHE, PHP y los Scripts correspondientes para la configuración de la distribución para el Pendrive. En esta primera beta se encontró con el problema de los permisos sobe la partición creada en el Pendrive en Fat32. El formato FAT32 no permite establecer permisos de usuarios y grupos como los formatos de linux: ext2, ext3, etc. Cuando se monta un partición FAT32 lo que hace por defecto Linux es montarla y asignarle a todos los archivos y directorios un usuario y un grupo. Este usuario y grupo es el del usuario y grupo que lo ha montado y con los típicos permisos 755, es decir que solo el usuario puede escribir sobre estos directorios. En nuestro caso al ser la partición montada en el arranque se le asigna: usuario: root grupo: root Esto planteaba una serie de problemas para la escritura de archivos sobre el directorio /home para el resto de usuarios. Para subsanar esto hubo que crear otra beta modificando la linea de montado del Script de arranque: mount a $dispositivo $puntomontaje o umask=000 mount a: con esta opción se monta el sistema de ficheros de forma automatica. Puedo ser esa cualquier tipo de sistema de ficheros que este reconocida por el kernel de Linux. En esta versión son las siguientes: adfs, affs, autofs, coda, coherent, cramfs, devpts, efs, ext, ext2, ext3, hfs, hpfs, iso9660, jfs, minix, msdos, ncpfs, nfs, nfs4, ntfs, proc, qnx4, ramfs, reiserfs, romfs, smbfs, sysv, tmpfs, udf, ufs, umsdos, usbfs, vfat, xenix, xfs, xiafs. 36

45 Nota: También es reconocida el sistema de ficheros ntfs. Este sistema de ficheros solo se permite su acceso como lectura. Para poder permitirse el acceso como escritura se debe instalar: ntfs 3g: Es un driver que permite el completo acceso a particiones ntfs como escritura lectura. Se puede encontrar en los repositorios de Automatix, que estan especialmente preparados para las distribuciones UBUNTU y sus derivados. $dispositivo: variable donde se almacena el dispositivo a montar. $puntomontaje: variable donde se almacena el lugar de montaje del dispositivo. El lugar de montaje es /media y el nombre de la carpeta el nombre del dispositivo a montar. o umask=000: Con umask asignas permisos para las carpetas y directorios de la partición a montar. En este caso los directorios y ficheros creados en la FAT quedarían de la siguiente manera: archivos: rw directorios: rwx De esta manera subsanamos el problema arriba citado, pudiendo hacer que cualquier usuario pueda escribir sobre los directorios creados en el arranque. De esta manera se creo la segunda Beta. 37

46 TERCERA BETA Dadas las dificultades planteadas por Mysql, se dejo esta migración para el final. En esta Beta se modificaron ciertos aspectos de presentación como el splash de icicio y un presentación mas limpia de los dispositivos conectados al ordenador. CUARTA BETA, RC1 En la tercera Beta se daba prácticamente por concluido el proyecto y se planteaba llamarla RC1 (realise candidate 1). Pero nuevas pruebas dieron como cambios lineas en los Scripts de inicio: #Las configuraciones estan en la carpeta /etc/dsotox de la sitribucion mv /home $puntomontaje Esta linea se modifico por estas otras: #Las configuraciones estan en la carpeta /etc/dsotox de la distribucion cp r /home $puntomontaje rm fr /home Esto fue debido a que hay enlaces simbólicos que no pueden ser copiados en las particiones FAT, por lo que si el comando mv, no mueve todo el contenido de la carpeta, esta se mantiene en el sistema de ficheros y esto no conviene. Hay que eliminar el /home del sistema de ficheros original para sustituirlo por un enlace al home situado en la partición FAT. 38

47 OTROS PROBLEMAS: Dadas las características del Hardware empleado (pendrive). Hicieron que las betas creadas se probaran con Cds. Estas Betas o imágenes Iso se grababan en Cds y se probaban en otro equipo. Esta forma de hacerlo fue debido a que en comienzos del proyecto se empezó a estudiar el uso de Qemu para comodidad de pruebas. No se consiguió que Qemu reconociera el USB que se utilizaba: Twin Drive CR2AS 64. Por problemas de migración con Mysql, hicieron que el proyecto se alargara, juntándose con la creación de un segundo proyecto, dsotox Pen, la compra de otro pendrive, la salida de Qemu 0.90 y la búsqueda de alternativas de virtualización. Con esta versión de Qemu y con el nuevo pendrive se reconocía bien los Usb, por eso se pensó que el problema de los reconocimientos de Usb radicaba en el Software empleado. Dado que esta tercera Beta se creo con la nueva versión de Qemu se observo el que el fallo radicaba en la utilización del pendrive: Twin Drive CR2AS 64. Con estos nuevos testeos y con la utilización de otro pendrive (numero de serie: USB_DISK_Pro_07551C3D00E1) se observo algo que no se había planteado hasta ahora. Este pendrive tiene la peculiaridad de tener dos discos internos, es decir un sistema de discos distribuido por defecto de la siguiente manera: El primero: En este disco se tiene una partición primaria. El script de ejecución se diseño para que los pendrive no tuviesen particiones por que en este tipo de pendrive da un error, y los archivos de configuración no se guardan en el USB. El segundo: 39

48 Este segundo disco se reconoce y se puede escribir en el, pero los programas como fdisk, parted, Qtparted y gparted son incapaces de reconocer el sistema de ficheros. Se puede observar un ejemplo de salida de dicha partición de fdsik en la imagen de arriba. Dada la situación temporal en la que se ha encontrado este inconveniente se ha decidido ponerlo como una restricción y en futuras actualizaciones actualizar el Script de dsotox Pen que si contempla este tipo de posibilidades. 40

49 DESARROLLO DE dsotox PEN Las distribuciones basadas en Linux han ido evolucionado desde su aparición en Se comenzó con un núcleo, con el cual se interactuaba íntegramente por medio de una consola: Esto fue evolucionado gracias a las licencias basadas en Software Libre. Se le fueron añadiendo mejoras: escritorios, mejoras al kernel, distribuciones LiveCd, etc. Esto fue ocurriendo a medida que los ordenadores fue posibilitando ciertas características gracias a la evolución del Hardware. Como es el caso de los LiveCd. 41

50 Hoy el hardware ha posibilitado hacer que los ordenadores puedan arrancar desde los llaveros Usb, al igual que pasa con los Cds y lo que pasó con las disquetes. Por este motivo se pensó en saltar a la siguiente futura era de las distribuciones. Evolucionar una distribución y meterla en un USB. Esta distribución en un principio debería tener las siguientes características: Basada en Ubuntu o similares: Esto debido a la experiencia en el proyecto anterior. Facilitaría las cosas y haría mucho mas rápida la creación de la misma. Basada en la ultima versión: Así se garantiza un mayor reconocimiento de hardware. Detección automática de hardware: debería reconocer el mismo hardware que una distribución LiveCd de Ubuntu. Almacenamiento en 2GB: Que se pudiese almacenar en un espacio mínimo de 2GB. Requisitos de Hardware: Los mismos que la distribución LiveCd o inferiores. Sistema de virtualización integrado: Un sistema que permitiese arrancar la distribución en caliente (desde un sistema operativo anfitrión) desde los sistemas operativos Windows y Linux, así como la instalación de la distribución en el pendrive sin necesidad de reiniciar el ordenador. Información no volátil: Que la información se mantuviese dentro del pendrive como si fuese una instalación en un disco local. Posibilitando la instalación de software, creación de archivos, usuarios, asignación de grupos, permisos, etc. 42

51 Estudio de posibilidades Lo primero que se hizo fue investigar si alguien había desarrollado algo parecido. Lo único que se encontró fue la nueva distribución de Madriva: Madriva Flash y una serie de apaños por distintas personas para poder crear una versión LivePendrive y almacenar cosas en este. La distribución de Madriva era una de las partes que se pretendía desarrollar. Pero su carácter mas propietario que libre hace que se encuentre muy poca documentación sobre la misma. De todos modos unas de las cosas que chocaba de las distribución era el poco hardware reconocido con respecto a las tarjetas gráficas: NVIDIA, ATI, Intel i8xx y i9xx. La otra opción que se comentaba en distintos foros, era la de meter la versión LiveCd en el pedrive y crearse una partición FAT32 en este. En esta partición se utilizaría para almacenar los distintos documentos de los usuarios. Esta opción no solucionaba nada con respecto a que se pretendía desarrollar. Una de las cosas que sabía era que el Kernel de Linux reconoce gran cantidad de Hardware en tiempo de ejecución, es decir, cambias hardware en el ordenador, enciendes y este ya esta habilitado y funcionando. Esto me paso en mi ordenador con tarjetas de red, monitores y tarjetas gráficas. Otra cosa que se había probado en circunstancias ajenas al proyecto fue la de probar una instalación de Linux de un ordenador en otro con hardware totalmente distinto. Los resultados fueron totalmente satisfactorios sin tener que configurar nada a mano. Esto mismo se había probado en los mismos ordenadores con el sistema operativo Windows y no se consiguió arrancar. 43

52 Sabiendo todo esto se probaron dos situaciones para almacenar meter una distribución en el pendrive y ver si esta arrancaba de forma normal: 1. La primera fue coger todo el sistema de ficheros creado con el comando: # sudo mount t squashfs o loop mnt/casper/filesystem.squashfs squashfs Esto monta el sistema de fichero squashfs del LiveCd: Como se trata simplemente del montaje del sistema de ficheros, archivo como: mtab, fstab, lo relacionado a los usuarios no estaba configurado. Ejemplo de mtab y fstab fstab mtab 44

53 Ejemplo de fstab y mtab de un sistema instalado: fstab mtab Archivo /etc/fstab En ocasiones, cuando se tienen varios dispositivos que se suelen ``montar'', se puede ahorrar tener que escribir continuamente la oportuna orden mount, simplemente incluyendo una línea en el archivo /etc/fstab. El archivo /etc/fstab contiene líneas donde se indica qué dispositivo debe ``montar'', el lugar donde ``montarlo'', así como el sistema de archivos y las opciones (en este archivo, se pueden poner dos opciones más: auto y noauto, que indican si se debe ``montar'' automáticamente al arrancar el sistema o no, respectivamente). Un ejemplo de /etc/fstab puede ser: # /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 # /dev/sda1 UUID=71ddbd8e 317d 49f3 addd 56e9f69649ad / ext3 nouser,defaults,errors=remount ro,atime,auto,rw,dev,exec,suid 0 1 # /dev/sda6 UUID=89613ddc 9a20 464d ad51 1aa606214ab4 /home ext3 45

54 nouser,defaults,atime,auto,rw,dev,exec,suid 0 2 # /dev/sda5 UUID=91421dd0 38c6 4acb abf7 449f6428e5da none swap sw 0 0 /dev/hda /media/cdrom0 udf,iso9660 user,atime,noauto,rw,dev,exec,suid 0 0 Archivo /etc/mtab El archivo /etc/mtab es un archivo normal actualizado por el programa mount cada vez que se montan o desmontan sistemas de archivos. He aquí una muestra de /etc/mtab: /dev/sda1 / ext3 rw,errors=remount ro 0 0 proc /proc proc rw,noexec,nosuid,nodev 0 0 /sys /sys sysfs rw,noexec,nosuid,nodev 0 0 varrun /var/run tmpfs rw,noexec,nosuid,nodev,mode= varlock /var/lock tmpfs rw,noexec,nosuid,nodev,mode= procbususb /proc/bus/usb usbfs rw 0 0 udev /dev tmpfs rw,mode= devshm /dev/shm tmpfs rw 0 0 devpts /dev/pts devpts rw,gid=5,mode= lrm /lib/modules/ generic/volatile tmpfs rw 0 0 /dev/sda6 /home ext3 rw 0 0 /dev/sdb1 /media/usbdisk vfat rw,nosuid,nodev,quiet,shortname=mixed,uid=1000,gid=1000,umask=077,ioc harset=utf8 0 0 El archivo /etc/mtab se utiliza para mostrar el estado de los sistemas de archivos montados actualmente. No se debería modificar manualmente. Esto planteaba una serie de problemas que se citaran en el apartado de sistema de particiones ya que en fstab debería estar actualizado con nuestro sistema de particiones escogido para hacer la distribución. Otro problema que se planteaba era la creación de los usuarios y la configuración de los mismo. Una de soluciones que se planteo era crear un instalador que fuese subsanando cada unas de estas cosas. El temor de escaparse algo que no hubiese sido analizado hizo pensar en otra opción. 46

55 Nota: Citar que este forma de volcar el sistema de ficheros montado con: # sudo mount t squashfs o loop mnt/casper/filesystem.squashfs squashfs y subsanando los distintos errores arriba citados de forma manual hizo que la distribución corriera aparentemente bien. La otra opción por la que se opto fue por la utilización del instalador del Kubuntu por defecto en el usb. De esta manera se ahorraría el esfuerzo de crear un instalador donde hubiera que configurar los parámetros del los usuarios y ciertas configuraciones de los ficheros mtab y fstab. Se probo esta opción instalándola desde un portátil Dell INSPIRON 1501 y se probo en un ordenador de sobre mesa. Se observo que el hardware era reconocido perfectamente mientras arrancaba el ordenador. Los ficheros mtab y fstab se cambiaban de forma automática. Añadiéndose comentarios a lineas de dispositivos que pertenecían a portátil Dell. Lo único que daba problemas a veces era la tarjeta gráfica. Impidiendo arrancar el escritorio. Dado que este sistema ahorraría mucho el tiempo de desarrollo se opto por seguir esta linea y empezar a desarrollar y mejorar la distribución desde aquí. 47

56 PROBLEMAS, SOLUCIONES Y BETAS Como se comentaba arriba se había conseguido instalar en un pendrive de 2GB un distribución de Kubuntu Pero para ello hubo que modificar el instalador por lo siguientes motivos: En un Pendrive de 2GB se necesitaba reservar un espacio para la partición swap. Lo que implicaba que la partición donde estaría instado el sistema operativo se reduciría por debajo de los 2GB. Por defecto el instalador de Kubuntu no permite instalar el sistema en particiones por debajo de este espacio. Hubo que tocar los archivos de configuración del instalador para que nos permitiera hacer pruebas. La solución de arriba planteaba otro problema. El espacio. En ocasiones el instalador daba errores impidiendo la instalación. Es otras ocasiones terminaba satisfactoriamente. Lo que se pretendía en estas fechas era desarrollar alguna beta de forma rápida para comprobar cuanto de fiable era la distribución y hacer pruebas sobre ella. Se plantearon dos soluciones: Eliminar paquetes de la distribuciones Basarse en Xubuntu 6.10 (recién salida). La primera se empezó hacer pero las fuertes dependencias de las aplicaciones entre si, hacia muy complejo liberar el suficiente espacio. Se estaba perdiendo mucho tiempo y sin obtener buenos resultados. 48

57 La segunda opción se probo y se observo que se podía instalar en el pendrive si necesidad de modificar el instalador. La instalación de Xubuntu estaba por debajo de los 1.5GB. Esta opción era perfecta para seguir haciendo pruebas y evolucionando la distribución. Ahora quedaría por solucionar dos cosas: La de arriba mencionada: tarjeta gráfica El arranque, Grub. Solución tarjeta gráfica: No se comprendía muy bien porque fallaba el arranque del escritorio. En experiencias anteriores nunca había sucedido. Pero los errores que nos citaba el servicio gdm nos indicaba que el bus PCI estaba mal configurado. Se analizo el fichero xorg.conf, ubicado en /etc/x11/xorg.conf y se observo que nunca cambiaba la configuración de la tarjeta gráfica con referencia al bus PCI. Section "Device" identifier "Tarjeta de video generica" boardname "ati" busid "PCI:1:5:0" driver "ati" screen 0 option "MergedFB" "off" EndSection Para solucionarlo se creo un Scrip que hiciera esta modificación justo antes de levantar el servicio gdm. Este fichero lo que hace principalmente es extraer el bus donde se encuentra la tarjeta y posteriormente transformarlo al formato que se usa en Xorg (PCI:03:01:00). bus=`lspci m grep VGA cut d " " f 1 cut d "." f 1` busid='"'"pci:"$bus":0"'"' #Estraemos el BUSID y lo combertimos al formato de Xorg: "PCI:1:5:0" De esta manera solucionó el problema del bus pci. 49

58 Posteriormente surgió el problema del driver de la tarjeta que tampoco era actualizado. En una primera instancia se opto por poner una genérica: vesa. Pero se observo que en ciertos ordenadores el rendimiento era pésimo. Para solucionarlo se añadieron en el mismo Script que es llamado en gdm unas lineas para poder configurar el driver de la tarjeta gráfica: lspci m grep VGA awk F'"' '{ print $4 }' grep ATI lspci m grep VGA awk F'"' '{ print $4 }' grep nvidia Con estas lineas se nos permite saber si el driver es Ati o Nvidia. En caso de que no sea ninguna de las dos se opta por poner un driver cirrus. Esta fue probada en tarjetas Intel y Cirrus y ha funcionado perfectamente. Otras preguntas que se plantearon con respecto al Hardware fueron las otras lineas de Xorg: Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" option "CoreKeyboard" option "XkbRules" "xorg" option "XkbModel" "pc105" option "XkbLayout" "es" option "XkbOptions" "lv3:ralt_switch" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" option "CorePointer" option "Device" "/dev/input/mice" option "Protocol" "ExplorerPS/2" option "ZAxisMapping" "4 5" option "Emulate3Buttons" "true" EndSection Section "Monitor" identifier "Generic Monitor" vendorname "Generic" modelname "Flat Panel 1280x800" HorizSync VertRefresh 60 modeline "800x600@60" hsync +vsync modeline "1280x768@60" hsync +vsync modeline "1600x1024@60" hsync +vsync modeline "1680x1050@60" hsync +vsync modeline "1920x1200@60" hsync +vsync 50

59 gamma 1.0 EndSection Section "Screen" Identifier "Default Screen" Device "Tarjeta de v eo gen ica" Monitor "Generic Monitor" DefaultDepth 24 SubSection "Display" depth 24 modes "1280x768@60" "1600x1024@60" "800x600@60" "1680x1050@60" "1920x1200@60" EndSubSection EndSection Estas lineas pertenecen la configuración de: Teclado Ratón Monitor Configuración del pantalla Ninguna de estas dio problemas en los diferentes ordenadores probados. Los ratones, teclados y monitores fueron siempre reconocidos sin problemas. La única excepción fue con un monitor: HL1500S de Hyunday. El sistema operativo fue arrancando de forma virtual convirtiéndose el sistema de pantalla del sistema virtual justo en el arranque del entorno gráfico en un monitor de 17 pulgadas sobre uno de 15. El sistema operativo cargado de forma virtual funcionaba de forma perfecta pero si se quería poner en pantalla completa se cerraba. No se preocupo por esto al ser un caso aislado y al haber dado muchos problemas en su configuración con Kubuntu No pudiendo instalar los drivers propietarios de Nvidia por que no se conseguía configurar el monitor a un tamaño y resolución correctos. 51

60 Problema y solución del arranque: Para iniciar el sistema lo que primero hace la Bios es leer el sector de arranque (MBR). En nuestro caso en el sector de arranque esta instalado Grub. Grub es un gestor de arranque que nos ofrece un menú para arrancar el sistema operativo e incluso pasarle opciones si esta las acepta. Una vez que tiene el control Grub se selecciona el sistema operativo a arrancar para pasarle el control, en nuestro caso al kernel. Como se le pasa el control al kernel? 52

61 A Grub hay que especificarle varias cosas: root: Se especifica el dispositivo para ser montado y acceder al espacio de la partición. kernel: Se especifica el lugar del kernel y se le pasan ciertos parámetros (luego se comentaran). initrtd: Se le especifica el lugar del initrd. Un vez especificado todo esto, Grub le pasa el control al Kernel ya que sabe donde esta. Una vez pasado el control al Kernel Grub ya no hace nada. A partir de aquí el kernel se empieza a descomprimir y a reconocer todo el hardware. A medida que va detectando los dispositivos estos se van activando. El kernel llegara a un punto que tiene que montar el sistema de ficheros y la pregunta es donde? Grub sabia donde se ubicaba el kernel pero esta no sabe donde esta y es posible que mientras detectaba el hardware se haya encontrado mas de un dispositivo de almacenamiento. Para especificarle el lugar al kernel donde tiene que montar el sistema de ficheros existe un parámetro que se le pasa en el gestor de arranque: En el caso de ser un pendrive, dispositivo SATA o SCSI root=/dev/sdx (donde x es el dispositivo, Ej: a, b, c, d, etc) En caso de ser un dispositvo ATA root=/dev/hdx (donde x es el dispositivo, Ej: a, b, c, d, etc) Ahora parece estar solucionado el problema, pero prestemos atención a como reconoce el kernel los dispositivos: Imaginemos que hemos hecho la instalación del sistema operativo en un USB que ha sido reconocido en la instalación de Ubuntu como sdb, ya que había otro dispositivo SATA que fue reconocido como sda. Si ponemos estos parámetros a Grub: root=/dev/sdb Solo podremos arrancar otra vez el sistema operativo siempre que sea reconocido como sdb. Si en posteriores arranques hay un dispositivo SATA y mas de un pendrive conectado como se asegura que el dispositivo USB donde tenemos el sistema operativo Linux va a ser sdb y no sdc? Otro problema mas simple de ver es en sistema virtual. Para Qemu los pendrives conectados al sistema anfitrión los detecta como hda, hdb, hdc, etc. Por lo que aquí directamente no funcionaria. 53

62 Para solucionar estro se plantearon dos soluciones: Cambiarlo a mano. Arrancar un micro Kernel al principio para saber ubicar el dispositivo USB, modificara Grub y asi después lanzar el Kernel de nuestro sistema. Se empezó hacer un estudio de la segunda posibilidad ya que la primera estaba solucionada. Sobre las fechas en las que se estaba trabajando sobre ella, salio la versión 7.04 de Ubuntu. Para basarse en la ultima versión se cogió Xubuntu 7.04 y se empezó hacer el estudio desde esta. Se observo que en el sistema de arranque de Grub algo había cambiado: Donde antes ponía: root=/dev/sdx ó root=/dev/hdx Ahora pone: root=uuid=x (donde x es el identificador del dispositivo) 54

63 Se observó con el comando udevinfo que se añadían unas lineas a la información de los dispositivos: 55

64 Lo que se llego a la conclusión que ahora se hacia referencia a los dispositivos por un identificador no por el nombre que le asignara el Kernel en el tiempo de ejecución y reconocimiento de hardware a éste. Al referirse a los dispositivos por medio de identificadores el problema anteriormente citado estaba solucionado ya que este era único para cada dispositivo y no se cambiaba al ser detectado en otros ordenadores. Con todos estos problemas subsanados ahora quedaría por hacer un instalador que permitiera configurar el pendrive para nuestro propósito, es decir instalar la distribución parcheando los problemas anteriores y que instalara de forma trasparente Qemu para que fuese accesible desde Linux y Windows. 56

65 Primera versión del Instalador El objetivo de este instalador era que creara un sistema de particionamiento de la siguiente manera: En la partición formateada con ext3 estaría el sistema operativo. En la partición formateada con swap estaría el espacio para la memoria de intercambio. En la partición formateada con fat32 estaría Qemu. Este instalador también debería añadir los parches antes citados como el configurador de la tarjeta gráfica. Este instalador lo primero que hacia era llamar a: ubiquity desktop %kgtkui Este es el instalador de Ubuntu. Siguiendo todos los pasos y en el apartado de particionamiento seleccionando el dispositivo USB donde se quería instalar, este hacia una instalación con las siguientes características: Sobre un pendrive de 2GB: Instalación de Xubuntu en una partición de ext3 (1.7 GB aproximadamente) Creación de una partición Swap para intercambio (140 MB aproximadamente) Lo que hacia luego el instalador programado por nosotros era reparticionar la partición Swap y crear una Fat32 de 40MB aproximadamente. Luego se procedía a incorporar el configurador de la tarjeta gráfica y copiar Qemu en la partición Fat32 con sus respectivos Scripts. Así salio la primera beta de dsotox Pen. 57

66 Problemas primera versión beta dsotox Como se tenia dsotox en un pendrive se empezó aprobar en todos los ordenadores que se podía anotando así el funcionamiento del mismo. Se observo a veces en modo virtual no se reconocía la tarjeta y por defeco nuestro configurador de la gráfica ponía un driver cirrus. Esta funcionaba pero no como debía. El sistema arrancaba dentro del virtualizador con un tamaño de pantalla mas grande de lo que debería. El problema antes citado con el monitor Hyundai ya se repetía en otros. Esto dio que pensar e intentar buscar otra solución para nuestro configurador. Haciendo pruebas se observo que si a Xorq le eliminabas el fichero /etc/x11/xorg.conf por si solo casa vez que arrancabas el ordenador hacia el mismo un reconfiguración de hardware, pero no generaba el fichero xorg.conf. Este permanecía en memoria. Esta forma parecía que funcionaba bastante bien pero aun así los drivers de las tarjetas casi siempre las ponia vesa y en ocasiones pasaba lo anterior, pero en menor medida. Se empezó a investigar el funcionamiento de Xorg por este lado y entremezclarlo con el comando: dpkg reconfigure p critical xserver xorg que anteriormente pocos o ningún resultado había dado. Se observo que cuando se ejecutaba esto después de haber hecho Xorg su reconocimiento de hardware sin el fichero xorg en /etc/x11 los resultados era excelentes. Reconocía el hardware muy bien y generaba de forma satisfactoria el fichero xorg.conf. Se empezó a investigar donde colocar este comando y se observo que añadiéndolo al servicio gdm que es el encargado de lanzar el entorno funcionaba muy bien. Se opto por modificar este servicio añadiéndole unos aspectos característicos: A: gdm start Se le añadió: rm f /etc/x11/xorg.conf dpkg reconfigure p critical xserver xorg 58

67 start) rm f /etc/x11/xorg.conf log_begin_msg "Cargando escritorio. Configurando. Espere..." dpkg reconfigure p critical xserver xorg if [ e "$DEFAULT_DISPLAY_MANAGER_FILE" a "$HEED_DEFAULT_DISPLAY_MANAGER" = "true" a "$(cat $DEFAULT_DISPLAY_MANAGER_FILE 2>/dev/null)"!= "$DAEMON" ]; then log_warning_msg "Not starting GNOME Display Manager (gdm); it is not the default display manager." else # if usplash is runing, make sure to stop it now, yes "start" kills it. if pidof usplash > /dev/null; then DO_NOT_SWITCH_VT=yes /etc/init.d/usplash start fi start stop daemon start quiet oknodo pidfile $PIDFILE name gdm $SSD_ARG $CONFIG_FILE >/dev/null 2>&1 log_end_msg 1 log_end_msg 0 fi ;; A : gdm start reload Se le añadió: rm f /etc/x11/xorg.conf dpkg reconfigure p high xserver xorg start reload) rm f /etc/x11/xorg.conf log_begin_msg "Cargando escritorio. Configurando. Espere..." dpkg reconfigure p high xserver xorg if [ e "$DEFAULT_DISPLAY_MANAGER_FILE" a "$HEED_DEFAULT_DISPLAY_MANAGER" = "true" a "$(cat $DEFAULT_DISPLAY_MANAGER_FILE 2>/dev/null)"!= "$DAEMON" ]; then log_warning_msg "Not starting GNOME Display Manager (gdm); it is not the default display manager." else # if usplash is runing, make sure to stop it now, yes "start" kills it. if pidof usplash > /dev/null; then DO_NOT_SWITCH_VT=yes /etc/init.d/usplash start fi start stop daemon start quiet oknodo pidfile $PIDFILE name gdm $SSD_ARG $CONFIG_FILE >/dev/null 2>&1 log_end_msg 1 log_end_msg 0 fi ;; Se añadió esto otro. force reload) $0 stop true $0 start reload ;; 59

68 Al no tener un sistema Windows instalado en los ordenadores donde se hacían las pruebas nunca se habían realizado pruebas sobre este (Qemu). Las primeras pruebas se hicieron con la primera versión ya en el USB instalado. Lo primero que se detecto al enchufar el USB en Windows es que este daba un mensaje de que el Pendrive no tenia formato. Se intento solucionarlo formateando desde Linux la única partición fat32 que había en el usb y meter qemu a mano. Seguía pasando lo mismo. Se pensó que podía ser del comando utilizado para formatear la partición: mkfs.vfat F 32 Así que se probo con otro: mkdosfs F32 v Los resultados eran los mismos. Se pensó que podía ser del reparticionamiento. Que este dejara mal las tablas de particiones. Así que se opto por darle formato desde Windows. El resultado fue que Windows había eliminado todo lo que habia en el Pendrive. Tanto las particiones Ext3, Swap y Fat32. Eliminó todo lo particionado y creo una sola partición FAT32. En teoría debería haber eliminado solo la la partición FAT32 ya que es la que se estaba formateando. Con el pendrive formateado desde cero se reparticionó todo otra vez a mano y se probaron múltiples forma de reparticionado. Se observo que: Partición primaria ext3 Partición extendida: Partición lógica Swap Partición lógica Fat32 ERROR! 60

69 Partición primaria ext3 Partición extendida: partición lógica Swap Partición primaria Fat32 ERROR! Partición primaria ext3 Partición primaria Swap Partición primaria Fat32 ERROR! Partición primaria Fat32 Partición primaria ext3 Partición extendida: partición lógica Swap FUNCIONABA! Se había llegado a la conclusión que para que Windows tuviera acceso a la Partición Fat32 esta debería estar al principio. Esto conllevo a modificar el instalador y a hacer pruebas para ver que esta forma de particionar funcionaba bien con el arranque de Grub. Así salio la segunda versión del instalador y con con ello la segunda beta de dsotox. 61

70 ESFUERZO Y ANÁLISIS PRESUPUESTARIO 62

71 Estimación esfuerzo Tabla de complejidad Factor de Ponderación Parámetros de medición Cuenta Simple Medio Alta Número de entradas EI 4 * 3... * 4 1 * 6 18 Número de salidas EO 2 * 4... * 5... * 7 8 Número de peticiones EQ 7 * 3... * 4 1 * 6 27 Ficheros lógicos internos ILF 2 * 7... * * Número de interfaces ELF... * 5... *7... * 10 Cuenta=total 67 Ajuste de Puntos Función. Leyenda: 0: No tiene influencia 1: Tiene influencia muy baja 2: Influencia moderada 3: Influencia media 4: Influencia significativa 5: Son esenciales 1 Requiere el sistema copias de seguridad y de recuperación fiables? 5 2 Se necesita comunicación datos? 4 3 Existen funciones de procesamiento distribuido? 0 4 Es crítico el rendimiento? 3 5 Se ejecutará el sistema en un entorno operativo existente y altamente utilizado? 5 6 Se requiere entrada de datos interactiva? 4 63

72 7 La entrada de datos interactiva debe hacerse desde múltiples pantallas? 0 8 Se actualizan los datos maestros de forma continua? 4 9 Son complejas las entradas, salidas, los archivos o las peticiones? 2 10 Es complejo el procesamiento interno? 3 11 Se ha diseñado el código para ser reutilizable? 3 12 Están incluidas en el proyecto la conversión e instalación? 0 13 Se ha diseñado el software para instalarlo en diferentes empresas? 4 14 Se ha diseñado el software para facilitar los cambios y ser fácilmente usado por el usuario? 3 Suma total Ajuste = 40 PF = SumaTotalTabla * ( 0,65 + 0,01* SumaTotalAjuste) PF = 67 * ( 0,65 + 0,01 * 40) = 70 Estimación por COCOMO Si para la codificación se utiliza el lenguaje C la líneas de código serán: LDC = PF * 50 LDC = 70 * 50 = 3500 Ahora identificaremos el proyecto: Deducimos que nuestro proyecto es de un Organic Type así que el esfuerzo y el tiempo del proyecto será: 64

73 Por ser un proyecto orgánico : A B C D 2,4 1,05 2,5 0,38 Esfuerzo = A *KLDC(B) = 2,4 * 3.5(1,05) = 8.99 personas mes Tiempo = C * Esfuerzo(D) = 2,5 * 9(0,38) = 5.7 meses. 65

74 Presupuestos 1. Honorarios Responsable del proyecto, sobresueldo, 2,300e/mes/6 meses Técnico, 1,500 /mes/6 meses 9000 SUBTOTAL Equipo Portátil 600 Disco extraíble 40 Pendrive 20 Licencias de Software (Software libre)... Impresora Epson STYLUS 580C (se anexa cotización) 40 SUBTOTAL Otros papel, disquetes y tóner 40 Libros y fotocopias 100 SUBTOTAL 140 GRAN TOTAL PRESUPUESTO GLOBAL Honorarios ,00 Equipo 700,00 Otros 140,00 TOTAL ,00 66

75 GESTIÓN DE LA CONFIGURACIÓN 67

76 Dado que se plantea continuar con el desarrollo del proyecto se resume en tres apartados como se continuará con la identificación de los documentos, futuras versiones y como se gestionara el desarrollo de la distros a través de la comunidad de Software Libre. Identificación de la configuración Se identificar los productos que se obtienen en cada uno de los procesos, asignándoles un nombre, un código de versión, un estado que indicará la situación en que se encuentran dentro de su proceso de elaboración, y su localización en el sistema de gestión de la configuración, de forma que se encuentren identificados de manera única. Documentales (DOC): Para el desarrollo de este proyecto se empleará una metodología en espiral donde se utilizan 4 etapas (Figura 1): 1. Planificación: determinación de objetivos, alternativas y restricciones. 2. Análisis de riesgo: análisis de alternativas e identificación/resolución de riesgos. 3. Ingeniería: desarrollo del producto del "siguiente nivel", 4. Evaluación del cliente: Valorización de los resultados de la ingeniería. 68

77 Evaluación del cliente: EVC Análisis de riesgos: ARI Planificación: PLF Ingeniería: ING Al margen de estas etapas se crearan otro tipo de documentos que se citan a continuación: Informes de seguimiento: IFS Actas de reunión: ACR Actas de reunión : ACT Plan de gestión de la configuración: PGC Informes de seguimiento: ISE Solicitud de cambio no programado: SCP Plan de gestión del proyecto: PGP Formulario: FOR El sistema de identificación de que se empleará será el siguiente: Nombre de Proyecto Número de Prototipo DOC Tipo de documento Secuencia Versión Revisión Nombre de proyecto: Tres caracteres que identifique el tipo de proyecto. Número de prototipo: Al ser una metodología basada en prototipos, se identificara cada uno de ellos con dos caracteres numéricos. Haciendo referencia a cada uno de los prototipos. A menor numero versión de prototipo mas primeriza. DOC: Indican que es de tipo documental. Tipo de documento: Indicará el tipo de documento arriba citado: EVC, PLF, ARI, ING, IFS, ACR. Por lo tanto se identificará a que etapa pertenece ese tipo de documento. 69

78 Secuencia: India la secuencia o numero del tipo de documento. Son dos caracteres numéricos. Empieza por 01. Versión: Indica la versión del documento. Son dos caracteres numéricos. Empieza por 01. Revisión: Indica la revisión de la versión. Son dos caracteres numéricos. Empieza por 00. Ejemplo: SDX.01.DOC.IFS Software (SOF): Das las características del proyecto con los caracteres SOF indicaremos los archivos, Scripts, configuraciones, etc obtenidas en la etapa de ingeniería. Script: SHX Imágenes iso: ISO Archivos de configuración: CON El nombrado de estos archivos es igual que en la parte documental: Nombre de Proyecto Número de Prototipo SOF Tipo de documento Secuencia Versión Revisión 70

79 Herramientas para la gestión de la configuración Dado que el proyecto en una integración de varias herramientas y un sistema operativo GNU, y este se integrara con el proyecto Sourceforge. La herramienta de gestión de la configuración elegida es: Concurrent Versions System (CVS). CVS es una aplicación informática que implementa un sistema de control de versiones: mantiene el registro de todo el trabajo y los cambios en los ficheros (código fuente principalmente) que forman un proyecto (de programa) y permite que distintos desarrolladores (potencialmente situados a gran distancia) colaboren. CVS utiliza una arquitectura cliente servidor: un servidor guarda la(s) versión(es) actual(es) del proyecto y su historial. Los clientes se conectan al servidor para sacar una copia completa del proyecto. Esto se hace para que eventualmente puedan trabajar con esa copia y más tarde ingresar sus cambios con comandos GNU. Varios clientes pueden sacar copias del proyecto al mismo tiempo. Posteriormente, cuando actualizan sus modificaciones, el servidor trata de acoplar las diferentes versiones. Si esto falla, por ejemplo debido a que dos clientes tratan de cambiar la misma línea en un archivo en particular, entonces el servidor deniega la segunda actualización e informa al cliente sobre el conflicto, que el usuario deberá resolver manualmente. Si la operación de ingreso tiene éxito, entonces los números de versión de todos los archivos implicados se incrementan automáticamente, y el servidor CVS almacena información sobre la actualización, que incluye una descripción suministrada por el usuario, la fecha y el nombre del autor y sus archivos log. Los clientes pueden también comparar diferentes versiones de archivos, solicitar una historia completa de los cambios, o sacar una "foto" histórica del proyecto tal como se encontraba en una fecha determinada o en un número de revisión determinado. Muchos proyectos de código abierto permiten el "acceso de lectura anónimo", significando que los clientes pueden sacar y comparar versiones sin necesidad de teclear una contraseña; solamente el ingreso de cambios requiere una contraseña en estos casos. 71

80 Los clientes también pueden utilizar la orden de actualización con el fin de tener sus copias al día con la última versión que se encuentra en el servidor. Esto elimina la necesidad de repetir las descargas del proyecto completo. CVS también puede mantener distintas "ramas" de un proyecto. Por ejemplo, una versión difundida de un proyecto de programa puede formar una rama y ser utilizada para corregir errores. Todo esto se puede llevar a cabo mientras la versión que se encuentra actualmente en desarrollo y posee cambios mayores con nuevas características se encuentre en otra línea formando otra rama separada. 72

81 Control de cambios de la configuración La descripción de las acciones de este proceso es la siguiente: Presentación de la Solicitud de Cambio: La presentación de la solicitud de cambio puede estar motivada por la detección de un falla o error en el Sistema o por variaciones en los requisitos. Alta, Clasificación y Registro: Una vez recibida, la solicitud es dada de alta en un registro de cambios (o base de datos) para su posterior seguimiento, asignándosele un código de clasificación para permitir su rápida ubicación y rastreo. Generación del Informe de Cambio: El Jefe de Proyecto que ha participado en el desarrollo recibe la solicitud, realiza un análisis rápido de su factibilidad y alcances y genera un Informe de Cambio que será elevado a un Responsable del Control de Cambios (RCC). Aprobación o Rechazo de la Solicitud: En función del informe recibido, el RCC aprueba o rechaza la solicitud y le asigna una prioridad de ejecución. Evaluación de la Solicitud: En caso de ser aprobada, el cambio es evaluado nuevamente por el Jefe de Proyecto para estimar el esfuerzo técnico que demandará su implementación, los costos asociados y los posibles efectos secundarios e impacto sobre otras funciones del Sistema. Generación de orden de cambio: En función de la información generada por la acción anterior, el RCC ordena la ejecución del cambio mediante una Orden de Cambio. Esta orden describe en forma detallada: La naturaleza y tipo de cambio a realizar. Las restricciones a tener en cuenta. Los criterios de revisión y auditoría. 73

82 A partir de este momento se inmoviliza el/los ECS sobre el que se realizará el cambio y los ECS relacionados, con el objeto de evitar superposición de cambios. Ejecución del cambio: Durante esta acción se procede a implementar el cambio sobre el Sistema bajo un estricto control y seguimiento. Certificación del cambio: Una vez implementado el cambio, se realiza una auditoría sobre el Sistema con el objeto de certificar que el problema se ha corregido o se han satisfecho los nuevos requisitos. Cumplida la auditoría se procede a liberar el/los ECS modificados. 74

83 75

84 76

85 77

86 ANEXO Nº 4 ABREVIATURAS Abreviatura Significado ACC Archivo Control de Cambios ECS Elemento de Configuración de Software GC Gestión de Configuración GCS Gestión de Configuración de Software IS RCC RHCP SCC Ingeniería de Software Responsable del Control de Cambios Registro histórico de cambios del proyecto Sección Control de Cambios 78

87 CONCLUSIÓN 79

88 Con este proyecto se ha conseguido dos grandes objetivos: 1. El objetivo de un conocimiento más exhaustivo de Linux. 2. El objetivo de cumplir con la teoría de los océanos azules. Como experiencia personal, este proyecto me ha introducido en el mundo del open source o código abierto. Los conocimientos que tenia sobre este campo antes de la realización de este proyecto eran muy escasos. La investigación llevada a cabo para la realización de esta aplicación, es decir la instalación de Linux, PHP, MySQL, Apache, sistemas de virtualización, etc y el manejo de todas estas herramientas, me ha llevado a confiar en este tipo de aplicaciones y ver con mis propios ojos el gran numero de personas, software, manuales, información, etc relacionada con este mundo. Todo ello por el simple hecho de compartir cosas. Para este proyecto apenas se ha utilizado información que no fuese extraída de Internet. Para la obtención de información sobre el uso de estas herramientas, ejemplos programados, ayuda mediante e mails, fotos, etc. Internet conjuntamente con esta comunidad, la que rodea al mundo del código abierto, es la mejor forma de obtener los mejores resultados (aprendiendo unos de los otros). Todo ello sin ofrecer nada a cambio. Lo mejor de todo esto, son los increíbles resultados obtenidos tras la realización de la aplicación, como se ha podido observar. Se ha conseguido un producto que cumple perfectamente con la teoría de W. Chan Kim y Renée Mauborgne. Existen dos tipos de mercado básicos dentro del mercado general, según argumentan Kim y Mauborgne, la prestigiosa profesora especialista en estrategia. Por un lado están los "océanos rojos" y, por otro, los "océanos azules". Océanos rojos son aquellos mercados "caracterizados por tener unos límites definidos y unas reglas competitivas asumidas por las empresas que en ellos operan". Son mercados en los que la competencia es feroz, y el objetivo principal de una empresa es hacerse un hueco en la cota de clientes. Por otra parte, los océanos azules son nuevos espacios de mercado, creados por determinadas empresas, en los que no aparece la competencia, o es ínfima la demanda se crea y se capta, no se lucha por ella. La teoría 80

89 clásica dice que para lograr una buena posición en las ventas de un producto, lo que hay que hacer es, o diferenciarlo de los demás que puedan serle competencia, o reducir el coste del mismo. Para que se cree un océano azul, lo que debe hacerse es conjugar ambos modelos: diferenciación y reducción de precios. A su vez, dentro de la concepción de océano azul, están surgiendo otro tipo de empresas que utilizan lo que Y. Moon denomina "posicionamientos disruptivos". Son esas compañías que son capaces de diferenciarse de los competidores, no en una categoría de producto concreta sino en la propia categoría en su conjunto. Así surgen ejemplos de como determinados productos han logrado crear nuevas clasificaciones de sus productos dentro de las que ya existían, como la serie Los Simpson, Disney, ebay o Dell. Lo que dsotox ha conseguido es hacer un producto a base de software libre por lo que el coste de este es mínimo. Ha conseguido diferenciase de todas las demás distribuciones y en caso de dsotox Pen meterse en un mercado con un solo competidor directo, Madriva Linux añadiéndose la característica diferenciadora del sistema virtual integrado y multiplataforma. Creando así un producto innovador y perfectamente integrable con la teoría de los océanos azules. 81

90 ANEXO A 82

91 INSTALACIÓN DE QEMU En el desarrollo de dsotox Pen se ha pasado por dos versiones de qemu y en dos versiones de Ubuntu. En Protech, basada en Ubuntu 7.04 y Xubuntu Este Anexo describe la instalación de qemu versión 0.82 para la familia Ubuntu 6.06 y la instalación de qemu para familia de Ubuntu Nota: En los repositorios universe: Para la familia 6.06 se puede encontra qemu Para la familia 7.04 se puede encontrar: qemu 0.82: Emulador y virtualizador kqemu: Acelerador para qemu. qemulauncher: Entorno gráfico para qemu. La instalación se realizo a partir de los fuentes, configurándolos y compilándolos. Así se tiene un mayor rendimiento del mismo, dado que el desarrollo se hizo en maquinas poco potentes. Para instalarlo en la familia 6.06, descargar qemu i386.tar.gz y kqemu 1.3.0pre9.tar.gz (ahora kqemu 1.3.0pre11.tar.gz) desde esta pagina: Luego seguir estos pasos: Se necesita instalar antes libsdl1.2 dev, texi2html, CVS,zlib dev y los headers de nuestro kernel. $ sudo aptitude install libsdl1.2 dev $ sudo aptitude install texi2html $ sudo aptitude install cvs $ sudo aptitude install linux headers `uname r` $ sudo aptitude install zlib1g dev 83

92 Se comprueba la versión del gcc $ gcc v Si sale (bash: gcc: command not found) se hace: $ sudo aptitude install gcc 3.4 y si no sale la versión 3.4 ; haremos: $ sudo rm /usr/bin/gcc $ sudo ln s /usr/bin/gcc 3.4 /usr/bin/gcc Se comprueba si esta instalado el paquete make, si no hay que descargarlo: $ sudo aptitude install make Descomprimir el tar del qemu, y dentro de su directorio descomprimir el tar del kqemu (en versiones anteriores era necesario hacerlo para que al hacer el./configure nos ponga kqemu acelerator yes). Nos situamos dentro del directorio del qemu y hacemos: $./configure $ make $ sudo make install Situarnos dentro del directorio del kqemu y hacer $./configure $ make $ sudo make install Ahora se carga el modulo kqemu $ sudo modprobe kqemu 84

93 En esta nueva se tiene acceso a una nueva opción a poner a la hora de lanzar el qemu; esta opción es: kernel kqemu Esta opción hace que las operaciones sean manejadas por el procesador del host y no por el invitado, lo cual aumenta la velocidad de una forma considerable. Esta opción solo funcionara en sistemas invitados windows 2000, windows XP o linux cuyo kernel sea 2.6 Para comprobar que el modulo kqemu esta cargado, lanzaremos alguna imagen de qemu y presionaremos ctrl+alt+2 y escribiremos Info kqemu donde debería poner algo así: kqemu suport: enabled for user mode y si se pasa la opción kernel kqemu deberia poner: kqemu suport: enabled for user and kernel mode Para instalarlo en la familia 7.04, descargar qemu i386.tar.gz y kqemu 1.3.0pre11.tar.gz desde esta pagina: Luego seguir estos pasos: Se necesita instalar libsdl1.2 dev, texi2html, CVS,zlib dev y los headers de nuestro kernel. Nota: Por defecto ya están instalados. $ sudo aptitude install libsdl1.2 dev $ sudo aptitude install texi2html $ sudo aptitude install cvs $ sudo aptitude install linux headers `uname r` $ sudo aptitude install zlib1g dev Ahora se instala gcc. Esta instalación se hizo con gcc 4.1 y funcionó sin problemas. $ sudo aptitude install gcc

94 Se compruebe si esta instalado el paquete make si no, hay que descargarlo: $ sudo aptitude install make Descomprimir el tar del qemu, y dentro de su directorio descomprimir el tar del kqemu (en versiones anteriores era necesario hacerlo para que al hacer el./configure nos ponga kqemu acelerator yes). Nos situamos dentro del directorio del qemu y hacemos: $./configure $ make $ sudo make install Situarnos dentro del directorio del kqemu y hacer $./configure $ make $ sudo make install Ahora se carga el modulo kqemu $ sudo modprobe kqemu En esta nueva versión tendremos acceso a una nueva opción a poner a la hora de lanzar el qemu; esta opción es: kernel kqemu Problema con kqemu Could not open '/dev/kqemu' QEMU acceleration layer not activated Puede ser debido a que no esta cargado el modulo o k el modulo solo puede usarlo root. Para descargar y volver a cargar el modulo 86

95 $ modprobe r kqemu $ /sbin/modprobe kqemu major=0 Si dice operación no permitida, lo se ejecuta como root: $ sudo modprobe r kqemu $ sudo /sbin/modprobe kqemu major=0 Si lanzamos qemu como usuario y no carga el modulo acelerador, probar a lanzarlo como root. Si lo carga como root, entonces para que lo pueda usar el usuario deberíamos darle privilegios al usuario para que pueda usar el modulo. Problema con usb_add o usbdevice Si se intenta cargar un dispositivo y nos sale usb_host: only one interface supported entonces podemos aplicar un patch que se descarga dándole a guardar como, desde aqui: interfaces.patch Para aplicarlo lo copiamos al directorio de los sources del qemu y en una terminal escribimos $ patch p1 < multiple interfaces.patch se reconstruye e instala. Explicación del porque y solución aquí: answers.com/viewtopic.php?p=4516# El problema al añadir este patch es que el sistema invitado se puede volver excesivamente lento. 87

96 Problema con kqemu sudo /sbin/modprobe kqemu major=0 FATAL: Error inserting kqemu (/lib/modules/ k7/misc/kqemu.ko): Invalid module format Para areglarlo solo se tuvo que cambiar el enlace blando del gcc 3.4 al gcc 4.0 y volver a compilar el modulo kqemu. $ sudo rm /usr/bin/gcc $ sudo ln s /usr/bin/gcc 3.4 /usr/bin/gcc Si no deja compilarlo de nuevo, borrar el directorio y volver a descomprimirlo y situarse dentro de el. Es posible que falten librerias, descargar lo siguiente (cambiar k7 por 386, 686, etc depende de el procesador). $ sudo aptitude install linux k7 linux headers k7 linux image k7 linux restricted modules k7 Problema de paredes invisibles con el ratón Para eliminar el error de paredes invisibles con mouse, aplicar el parche win/download/qemu mouse.patch de esta forma $ patch p1 < qemu mouse.patch se reconstruye e instala qemu. 88

97 Manejo de Qemu y sus opciones 1 ) Para crear una imagen que el programa usara como disco duro. Y su capacidad (en este caso 2Gigas). $ qemu img create nombre_de_imagen.img 2G 2 ) Para comprimir una imagen y que solo ocupe el uso real de disco duro. $ qemu img convert nombre_de_imagen.img O qcow nombre_de_imagen.qcow A partir de entonces, ejecuta qemu sobre nombre_de_imagen.qcow, el tamaño del fichero *.qcow irá creciendo a medida que aumente el tamaño de la imagen. 3 ) Para elegir desde donde bootear pasaremos la opcion boot y la opción a,c o d (disketera,disco duro, cd rom). Ejemplo $ qemu hda nombre_de_imagen.img cdrom /dev/cdrom boot d 4 ) montar la imagen con soporte para cdrom ( real o de imagen iso ) $ qemu hda nombre_de_imagen.img cdrom /dev/cdrom $ qemu hda nombre_de_imagen.img cdrom /directorio/imagen.iso *crear imagen iso a partir de directorio: *$ mkisofs J o nombre_que_quieras_darle.iso /directorio/nombre_de_la_carpeta 5 ) Montar la imagen con soporte para disketera; se pasa la opción fda /dev/fda o con una imagen de diskette fda /directorio/imagen_de_boot.img 6 ) La memoria ram por defecto es 128, para cambiar el valor, se pasa la opción m y el numero ejemplo. $ qemu hda nombre_de_imagen.img cdrom /dev/cdrom m ) Montar la imagen dentro de Linux, para poder leer y escribir desde y hacia ella. En este caso es imprescindible que la imagen ya tenga formato FAT. $ sudo mount o loop,offset=32256 /directorio_de_la_imagen/nombre_de_la_imagen /punto de montaje/. 8 ) Para pasar a la imagen la hora del sistema host, pasaremos la opción localtime. 9 ) Para habilitar samba, se pasa la opción smb directorio_que_compartimos Una vez dentro de windowsxp ( solo valido para este, y supongo que para 89

98 anterioresversiones) en una ventana de dos, teclearemos esto para tener acceso al directorio compartido: # net use e: \\IP\directorio_compartido e: pasara a ser la ruta del directorio compartido. 10 ) El acceso a internet viene activado por defecto. 11 ) Con soporte para usb, pasaremos la opción usbdevice o desde la consola del propio qemu usb_add host:numero:numero Si estas usando un kernel anterior al 2.4 hay que asegurarse que no este ningún driver usando el puerto usb. Comprueba asi que /proc/bus/usb funciona : $ ls /proc/bus/usb y debería salir algo así. 001 devices drivers Como acceder directamete al dispositivo host requiere privilegios de root: ejecutaremos qemu como root o podemos cambiar los permisos del usb asi: chown R myuid /proc/bus/usb ejecuta qemu con la opción usb y presiona ctrl+alt+1 y escribe $ info usbhost Device 1.2, speed 480 Mb/s Class 00: USB device 1234:5678, USB DISK En esa misma consola añadir el dispositivo usando usb_add host:numero:numero y el sistema invitado debería notificar el encendido de un nuevo dispositivo. Tambien se puede pasar la opción usbdevice host:numero:numero a la linea de ejecución del qemu. Nota: Esta ultima opción, añadir los dispositivos desde qemu no me funcionaba. Qemu los detecta y parece que los añade al sistema virtual pero el sistema operativo no detecta ningún dispositivo nuevo. 12 ) Para añadir un directorio como un nuevo disco duro (de solo lectura) a un sistema guest windows (el limite es 471MB) pasar la opción hdb fat:/directorio/. ejemplo: qemu hda win98.img hdb fat:/media/descargas/libros/. 13 ) Para emular una sound blaster 16 añadir la opción soundhw sb ) Ejemplos de comandos: a) qemu boot c fda /dev/fda cdrom /dev/cdrom hda hd.img m 256 k es Cargara disquetera, disco duro y cdrom y arranca desde c,además tendrá acceso a 90

99 internet, usara 256 mb de memoria y usara teclado español ( k es ). b) qemu hda win.img cdrom /dev/cdrom m 192 boot d Cargara disco duro y cdrom y arranca desde d (desde el cdrom) y usara 192 mb de memoria. c) qemu hda imagen.img usbdevice host:1234:5678 Cargara la imagen del disco duro y habilitara el puerto usb indicado y tendrá acceso transparente a internet. d) qemu net user net nic usb soundhw sb16 localtime win98games.img hdb fat:/home/usuario 91

100 ANEXO B 92

101 MANUAL DE USUARIO dsotox LiveCd Hay dos formas de ejecutar dsotox LiveCd: 1. De forma normal o tradicional 2. De forma virtual De forma normal o tradicional: Se inserta el Cd en el lector de cdrom y se inicia el ordenador desde este. Una ves iniciado el ordenador aparecerá el siguiente menú: 93

102 Antes de seleccionar las respectivas opciones se inserta el pendrive con el que se quiere trabajar o con el que se ha estado trabajando. Se selecciona la primera opción y se espera a la carga del sistema operativo. Posteriormente aparecerá un listado con los pendrive conectados al ordenador se selecciona uno y se espera a la configuración del pendrive y/o del sistema para iniciar con la configuración respectiva. De forma virtual De forma virtual no es necesario reiniciar el ordenador. En esta versión es posible arrancarlo desde Windows y desde Linux pero con la propiedad del Pendrive solo desde Linux. Para arrancar de forma virtual desde linux inserte el cd, acceda a la carpeta qemu y ejecute el Script qemu linux.sh. Es posible que no con versiones del kernel no permita la ejecución de este desde el cd, ya que no tiene permisos de ejecución. Para solucionar esto, copie la carpeta qemu a su ordenador y ejecútelo desde alli. NOTA: Por problemas con las rutas relativas debe ejecutar los Scripts siempre situándose dentro de la carpeta donde este ubicado dicho Script. 94

103 dsotox Pen En esta versión dsotox Pen solo es instalable de forma virtual y desde Linux. Para la intalación de el se debe insertar el Cd y ejecutar el Script qemu linux.sh situado en la carpeta qemu. Este Script de forma automática integra todo dispositivo usb al sistema virtual. Aparecerá un menú como este: Seleccionamos Start or install dsotox. También se puede seleccionar el idioma pulsando F12: 95

104 Tras el arranque del sistema pulsamos el botón derecho del ratón sobre el escritorio y pulsamos en home: Aparecerá una pantalla como esta. Se hace doble clic sobre Instalar. 96

105 Aparece el siguiente menú: Si se pulsa A, el instalador hará de forma automática el sistema de particionado para poder albergar el sistema Qemu y hará unas modificaciones sobre el sistema en si. Si se selecciona E el instalador no realizara ninguna modificación y simplemente iniciara el instalador por defecto de Ubuntu. Lo que implica que si se quiere instalar el sistema virtual y que el pendrive funcione en distintos ordenadores, esos cambios deberán hacerse a mano. Si se selecciona la opción A, se muestra un listado con los dispositivos USB conectados. Se selecciona el dispositivo sobre el que se quiere hacer la instalación: 97

106 A partir de aquí se inicia el instalador de Ubuntu en que se debe elegir el idioma, tipo de teclado, zona horaria, etc Al llegar al sistema de particionamiento de este instalador se debe seleccionar Manual: 98

107 A continuación haces doble clic sobre el dispositivo /dev/sda2 En el apartado de punto de montaje ponemos: / (shift + 7). Pulsamos Aceptar y proseguimos la instalación. Lo siguiente es introducir los datos del usuario y esperar la instalación. Después de acabar la instalación el instalador de Ubuntu el instalador de dsotox realizara una serie de cosas como sustituir el servicio gdm, instalar gemu y otros. 99

108 Para usar el sistema virtual, basta con introducir el pendrive y abrir la partición primaria Fat32. En sistemas modernos esto se hace de forma automática. En windows simplemente basta con hacer doble clic sobre el fichero bat: qemu win.bat Para un mayor rendimiento en la virtualización es posible instalar Kqemu 1.3.0pre11 install.exe situado en: kqemu 1.3.0pre11 w En linux se debe ejecutar el Script qemu linux.sh. Aparecerá lo siguiente: 100