Having a great bandwidth connection is really useful when you need to retrieve different pieces from the Internet, but having a local mirror can really improve your build times.
As an example, building and deploying a full TripleO stack (seed, undercloud and overcloud vms) without any local mirrors and proxy takes (in my server) about 73 minutes, while using a local pypy mirror, apt mirror and a squid proxy takes only 41 minutes. That is roughly a 40% improvement! (Although a lot of this time is spent in booting and configuring the OpenStack vm's ad services.
In a smaller case, just to build the seed vm (no vm ever booted), the times are the following:
Obviously, the worst your bandwidth if, the most time you will save!
You can also use the pypi mirror for other tasks, like updating your venv of your project for testing. Let's take for example, ironic . Keeping in mind that the test suite takes ~ 25s, the times are:
With the last update in Debian of qemu-kvm to version 1.6, booting vms via pxe with the e1000 (and ne2k_pci) network cards is no working anymore. I didn't take a deep look of the issue yet, but there is an easy solution (actually 2) for that.
Now that openvswitch-brcompat is not officially supported with recent kernels (Ubuntu 12.10 with kernel 3.5), the alternative to configure the bridges directly in the interfaces file has change a bit... but is still pretty forward!
Simple case with 1 bridge and 1 attached interface:
Now that openvswitch-brcompat is not officially supported with recent kernels (Ubuntu 12.10 with kernel 3.5), the alternative to configure the bridges directly in the interfaces file has change a bit... but is still pretty forward!
Simple case with 1 bridge and 1 attached interface:
allow-ovs br99
iface br99 inet dhcp
ovs_type OVSBridge
ovs_ports eth0
allow-br99 eth0
iface eth0 inet manual
ovs_bridge br0
ovs_type OVSPort
And to bring it up and down:
ifup --allow=ovs $list_of_bridges
ifdown --allow=ovs $list_of_bridges
Et voilà!
More info at: openvswitch-switch.README.Debian
We test the following: ... > /home/ghe/github/openstack/glance/glance/tests/functional/v1/test_api.py(1170)test_delete_not_existing() -> self.cleanup() (Pdb)
"The major problem of Debian and OpenStack, is Debian itself. In a so fast moving project like OpenStack, having an "EveryThing-Ready-and-Included" release every two years is not viable for this scenario. In the case of OpenStack, Squeeze is too old to handle it the way it is right now (Too many things not directly related with OpenStack, like qemu-xen, python-modules, etc., should be backported to make it functional, and with just volunteer packagers, make it a not so viable option). In the other hand, the next release, is planned to 1Q 2013 (Wheezy being frozen in later June), so Essex release will be outdated and Folsom we be the stable release by then, and with G release knocking on the door (Essex is supposed to be a LTS release, supported by Canonical/Ubuntu until around April 2017so is not that bad). Solutions? Forget about Squeeze, focus in Wheezy + Essex as an official release , and Folsom (or G release) as a back-ported option. The other option (not viable in a short term), is change the way Debian makes it releases, and try to have something more "componentized" (like Progeny tried to do some years ago) or "rolling-releases", so trending-topic these days. Neither GNOME, OpenStack, LibreOffice, linux-kernel (just to name some) has a similar release cycle or core necessities to run in a system, so why try to release, prepare, stabilized everything at the same time no matter what's the status the upstream project is? (Just int he case of OpenStack, and supposing everything thing is going according the schedule, with a 6 month release cycle vs. 2 years in Debian + frozen period, when Wheezy is released, we are going to release an outdated version -essex (but LTS thanks to Canonical)- when Folsom is 4 months old! and the new release coming in less than two months!) I agree this needs a lot of more development, but i think it's something that Debian should have to think about."
Re-reading it, the situation is not that bad actually. We were lucky enough that the new Ubuntu LTS was released, and we can use the excuse of Essex being supported until 2017. But the key point is the same: "Debian is huge and slow, while OpenStack (and so many other projects) are really fast-moving"
"The major problem of Debian and OpenStack, is Debian itself. In a so fast moving project like OpenStack, having an "EveryThing-Ready-and-Included" release every two years is not viable for this scenario. In the case of OpenStack, Squeeze is too old to handle it the way it is right now (Too many things not directly related with OpenStack, like qemu-xen, python-modules, etc., should be backported to make it functional, and with just volunteer packagers, make it a not so viable option). In the other hand, the next release, is planned to 1Q 2013 (Wheezy being frozen in later June), so Essex release will be outdated and Folsom we be the stable release by then, and with G release knocking on the door (Essex is supposed to be a LTS release, supported by Canonical/Ubuntu until around April 2017so is not that bad). Solutions? Forget about Squeeze, focus in Wheezy + Essex as an official release , and Folsom (or G release) as a back-ported option. The other option (not viable in a short term), is change the way Debian makes it releases, and try to have something more "componentized" (like Progeny tried to do some years ago) or "rolling-releases", so trending-topic these days. Neither GNOME, OpenStack, LibreOffice, linux-kernel (just to name some) has a similar release cycle or core necessities to run in a system, so why try to release, prepare, stabilized everything at the same time no matter what's the status the upstream project is? (Just int he case of OpenStack, and supposing everything thing is going according the schedule, with a 6 month release cycle vs. 2 years in Debian + frozen period, when Wheezy is released, we are going to release an outdated version -essex (but LTS thanks to Canonical)- when Folsom is 4 months old! and the new release coming in less than two months!) I agree this needs a lot of more development, but i think it's something that Debian should have to think about."
Re-reading it, the situation is not that bad actually. We were lucky enough that the new Ubuntu LTS was released, and we can use the excuse of Essex being supported until 2017. But the key point is the same: "Debian is huge and slow, while OpenStack (and so many other projects) are really fast-moving"
The partition can be a whole disk (a pendrive per example), a partition or even a lvm volume. In this case, we are going to use a lvm volume using a hard disk
Once opened, we can access it as a non-encrypted partition available under /dev/mapper/crypt (all the names can be changed to something more suitable for you), so we can format and access it like a normal partition.
root@squeeze:~# mkfs.ext4 /dev/mapper/crypt
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
51000 inodes, 203772 blocks
10188 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
25 block groups
8192 blocks per group, 8192 fragments per group
2040 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 36 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
root@squeeze:~# mount /dev/mapper/crypt /media/crypt/
If you are using a graphical desktop, like GNOME, it can manage it automatically with Nautilus, asking you the pass-phrase and root password.
You can avoid to work in the command line using the /etc/crypttab file, to open this filesystem during system boot. The systax of this file is pretty simple:
Using the disk UUID we can avoid future problems of the disk not being in the same path (like a pendrive)
At boot time, the system will ask for the passphare to open the encrypted disk
We can also especify a file with the key, to avoid this question. We can have a external usb drive with this file, or we can have this key files locally, to open external usb drives.
The partition can be a whole disk (a pendrive per example), a partition or even a lvm volume. In this case, we are going to use a lvm volume using a hard disk
After this, the best thing to do is to write random data in the partition to generate noise.
root@squeeze:~# dd if=/dev/urandom of=/dev/mapper/vol0-lv_crypt dd: writing to `/dev/mapper/vol0-lv_crypt': No space left on device 409601+0 records in 409600+0 records out 209715200 bytes (210 MB) copied, 60.7331 s, 3.5 MB/s
Finally, we create/format the encrypted partition, and open it to have it available to the system
WARNING! ======== This will overwrite data on /dev/mapper/vol0-lv_crypt irrevocably.
Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: Verify passphrase: root@squeeze:~# cryptsetup luksOpen /dev/mapper/vol0-lv_crypt crypt Enter passphrase for /dev/mapper/vol0-lv_crypt:
Once opened, we can access it as a non-encrypted partition available under /dev/mapper/crypt (all the names can be changed to something more suitable for you), so we can format and access it like a normal partition.
root@squeeze:~# mkfs.ext4 /dev/mapper/crypt mke2fs 1.41.12 (17-May-2010) Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) Stride=0 blocks, Stripe width=0 blocks 51000 inodes, 203772 blocks 10188 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=67371008 25 block groups 8192 blocks per group, 8192 fragments per group 2040 inodes per group Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729
This filesystem will be automatically checked every 36 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override.
root@squeeze:~# mount /dev/mapper/crypt /media/crypt/
If you are using a graphical desktop, like GNOME, it can manage it automatically with Nautilus, asking you the pass-phrase and root password.
You can avoid to work in the command line using the /etc/crypttab file, to open this filesystem during system boot. The systax of this file is pretty simple:
Using the disk UUID we can avoid future problems of the disk not being in the same path (like a pendrive)
At boot time, the system will ask for the passphare to open the encrypted disk
We can also especify a file with the key, to avoid this question. We can have a external usb drive with this file, or we can have this key files locally, to open external usb drives.
When you have a lot of servers to manage from a single keyboard/monitor, sometimes is easy to reboot a Linux system when trying to login into a Windows one using the crtl+alt+del keys. To solve this, just comment this line in the /etc/inittab file:
Cuando se maneja un gran número de servidores desde un único monitor/teclado, más de una vez se corre el peligro de que por querer hacer las cosas rápidas, pulsamos crtl+alt+sup para iniciar sesión en Windows... pero si es un Linux, eso supone un reinicio del servidor. Para evitarlo, en el fichero /etc/inittab, buscaremos algo parecido a esta línea y la comentamos:
Las recomendaciones para un equipo de escritorio suelen ser útiles, pero cuando se trata de un servidor, cuanta menos mierda mejor. Para evitar tener que acordarse de ésto siempre que instalemos algo, basta con:
Aunque no soy muy aficionado a la lectura, he de reconocer que cuando un libro me engancha, no suelo dormir mucho en esa semana hasta que lo acabo. Ésto mismo me ha pasado hace poco con La Saga de Ender, una "octología" (vamos, 8 libros) escrita por Orson Scott Card. Los 8 libros se dividen en dos sagas, la primera de ellas, siguiendo al personaje principal, Ender Wiggin, y la segunda saga, conocida como la Saga de las Sombras, se centra en personajes secundarios. De los 8 libros ya he devorado 3, en apenas un par de semanas:
- El Juego de Ender (1er libro de la Saga de Ender) y La Sombra de Ender (1er libro de la Saga de las Sombras). Ambos tratan sobre la preparación militar que reciben los niños en la Escuela de batalla desde dos puntos de vista distintos, aunque complementarios: Ender, protagonista indiscutible, y Bean, lugarteniente de Ender, y el único capaz de hacerle sombra.
- La voz de los muertos. Continuación de El juego de Ender y como éste se lanza a la colonización de nuevos planetas para cumplir su misión.
El resto de libros de la saga están en camino ya que me ha sido imposible encontrarlos en librerías de toda la vida.
Sin duda alguna, lectura muy recomendada para todo el mundo, includo niños, ya que se identificarán con los protagonistas de los libros: adolescentes desde los 5 años, cuando entran en la escuela de batalla hasta los 14 que llegan a tener al final de los libros. (El primer libro de cada saga, luego se hacen un poco espesos y filosóficos, aunque igual de interesantes)
A la hora de probar y desarrollar nuevo software, el usar software actualizado es casi un requerimiento para poder acceder a aquellas funcionalidades. Ya vimos como tener distintas versiones instaladas, a la vez que para el día a día usamos algo más estable. Sin embargo, tras pruebas y compilaciones/recompilaciones, nuestros entornos de pruebas, puede llegar a "ensuciarse" o deteriorarse. Siempre podemos optar por borrar la instalación y reinstalarlo desde 0, pero hay sistemas más rápidos y más flexibles: Snapshots de LVM.
Una de las características que tiene LVM, es el de poder hacer snapshots (o copias exactas) de un dispositivo en un momento dado. Con LVM2, dichas copias, ya son de lectura/escritura, es decir, podemos modificar la copia... sin llegar a alterar el original. ¿Qué conseguimos con ésto? Tener un sistema recién instalado sobre el que trabajar... dejándolo totalmente limpio, una vez que hemos finalizado.
Para conseguir ésto, obviamente necesitamos tener una partición LVM, sobre la que instalaremos los sistemas, y espacio libre suficiente en LVM para poder hacer las copias. (Cómo crear particiones LVM y manejarlas quedan fuera del ámbito de este tutorial... pero no del siguiente)
Así pues, tenemos una partición LVM (/dev/Volume_00/schroot), que hemos montado en /schroot (por ejemplo) y hemos "instalado" una versión de sid (debootstrap sid /schroot/sid). Una vez que tenemos todo instalado y configurado a nuestro gusto, no es necesario tener la partición montada para nada.
Una vez preparado, sólo queda editar el fichero de configuración /etc/schroot/schroot.conf en el cual le especificamos que es una partición LVM y que cuando la ejecutemos, queremos que nos haga snapshots de ella:
Carpeta dentro de la partición de LVM donde se encuentra el sistema instalado (Se pueden tener varios sistemas en distintas carpetas colgando todos de la misma partición)
lvm-snapshot-options=--size 1G
Opciones a pasar al snapshots. En este caso, le decimos que el espacio libre en el snapshot será de 1 GB (para esto era necesario tener espacio libre sin particionar en el Volume LVM)
device=/dev/Volume_00/schroot
Partición donde tenemos instalados los sistemas.
type=lvm-snapshot
Tipo de partición.
Así pues, una vez configurado todo, podemos acceder a Sid, simplemente con el comando schroot -c sid
Cuando creamos una configuración de tipo lvm-snapshot (sid en nuestro caso), automáticamente, también se crea una del tipo name-source (sid-source). Dicha configuración nos permite acceder a sid, pero sin crear un snapshot. Es decir, todos los cambios que hacemos, quedaran grabados. Ésto es útil, ya que Sid en una versión muy cambiante, y no está mal, ir actualizandola de vez en cuando.
