Category Archives: Linux

Linux, Virtualización

Usando imágenes base para clonar rápidamente en KVM

Leave a comment

Esto lo encontré hace tiempo en el sitio de KVM y le probé hace varios meses y funciona de maravilla!

Mira, supón eres docente (podrías ser cualquier otra cosa), y tienes que preparar 20 máquinas virtuales para que tus estudiantes hagan una tarea determinada.  Lógicamente como ya tienes un poco de experiencia sabes que las máquinas deben quedar igualitas, para que todos tengan que realizar las mismas tareas y en el peor escenario tengan los mismos errores/omisiones/tareas por resolver.

Cómo lo haces? con virtualización claro está! Virtualización es maravillosa.. crear la máquina es facilito. Con KVM lógicamente! porque usas Software Libre.

Cómo creas las 20 máquinas virtuales? Ahí está el kid del asunto hoy. Porque además seguramente serán 20 máquinas virtuales que luego de un par de días u horas eliminarás porque habrán hecho su tarea.

Opción 1: Crear las 20 máquinas una a una, estilo: seguir el wizard, el procedimiento de instalación de CentOS, 20 veces.. es difícil eh? Te pasarás al menos unas 4 ó 5 horas instalando las 20 máquinas.

Opción 2: Crear e instalar una máquina virtual, dejarla bien instaladita.. y luego clonarla 19 veces. Es una opción válida, buenaza! Pero igual la clonación toma tiempo, aproximadamente toma 1 minuto clonar 1 GB de disco. Por tanto si creaste una máquina de 20GB, cada máquina clonada te tomará no sé, digamos 20 minutos. Pero claro es más fácil pues ya no hay que pensar mucho, simplemente preparaste la primera máquina y luego clonaste el resto…

Opción 3: Usar disco base.

Esto es lo que quiero ver ahora. Y lo que me facilita durísimo el trabajo:

Imagínate crees una máquina, tal y como la opción 2, y la dejes listita, tuneadita, tal y como quieres que sean todas. Y luego le apagas y no le usas más.

Este será el disco de respaldo. Este disco lo usaremos como base para leer de él todo lo que requiramos.

En base a este disco, creamos ahora 20 discos, uno por cada una de las máquinas virtuales que necesitemos, estos serán utilizados solamente para almacenar los cambios que dentro de esta máquina ocurran! Estos discos estarán enlazados al disco base que no se cambiará para nada. Se usará solamente para leer lo que no haya cambiado.

Por ejemplo digamos que en la máquina 1 requiero leer la lista de usuarios, esta está en /etc/passwd, esta lista será transparentemente leída del disco base, pues no está modificado el archivo.

Si en la máquina 2 requiero leer la lista de usuarios, igual veré /etc/passwd y este lo leeré del disco base pues no ha sido modificado.

Ahora, si en la máquina 1 agrego un usuario , se modificará /etc/passwd y esta modificación será almacenada en el disco de los cambios. Este disco pertenece solamente a máquina 1.

Y si en máquina 2 requiero eliminar un usuario, /etc/passwd aparecerá almacenado en su disco de cambios y solamente maquina 2 le verá.

A ver aqui una imagen feíta de cómo es la cosa, el disco base y dos discos llamados cambiosvm1 y cambiosvm2, ambos discos son los que leen las máquinas VM1 y VM2

VM2<—>CAMBIOSVM2<——-(DISCOBASE)—–>CAMBIOSVM1<—>VM1

En la máquina VM1: Si leo algo, le busco en CAMBIOSVM1, si no está, le busco en DISCOBASE. Si quiero escribir algo, modificarlo, eliminarlo, agregarlo, lo agrego al disco CAMBIOSVM1

Lo mismo para VM2: Si quiero modificar algo, lo hago en CAMBIOSVM2, si quiero leer algo busco en CAMBIOSVM2, si no aparece es que estará en DISCOBASE.

DISCOBASE no se toca. Si le tocas, arruinas todo pues CAMBIOSVM1 y CAMBIOSVM2 dependen de que discobase se mantenga igualito.

El tamaño de CAMBIOSVM1 y CAMBIOSVM2 es simplemente lo que vayan almacenando. Y serán los discos de las máquinas virtuales correspondientes, tendrás 20 disquitos cada uno almacenando cada cambio de cada máquina virtual.

Crear estos discos, es facilito y rápido, toma menos de 5 segundos.. así que crear 20 máquinas virtuales tomará un minuto o dos.. y ya.

Creando los discos:

Supongamos que tengo ya el disco base, que se llama base.qcow2

Ahora quiero crear un disco de cambios llamado estudiante1.qcow2, pongo:

qemu-img create -b base.qcow2 -f  qcow2   estudiante1.qcow2

el disco “estudiante1.qcow2” es el que almacenará los cambios para la máquina virtual de estudiante1.

Ahora hago lo mismo para estudiante2, estudiante3.. y así hasta estudiante20

Luego creo las 20 máquinas virtuales, cada una haciendo uso de su propio disco “estudianteX.qcow2” (1<=X<=20).

Todas quedarán igualitas. Lógicamente al finalizar el rtabajo puedo eliminar estos disquitos y ya… y puedo dejar la base para otros experimentos posteriores.. crear y eliminar máquinas será facilito y consumirá poquísimo disco.

Comandos interesantes:

qemu-img info estudiante1.qcow2

te dará información del disco, verás que usa un backend llamado base.qcow2, mira qué cosa más curiosa y es que el tamaño del disco no es 10G como la base, sino de 56K o así.. porque solamente almacenará los cambios:

image: estudiante1.qcow2
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 56K
cluster_size: 4096
backing file: base.qcow2 (actual path: base.qcow2)
Centos, Linux, Virtualización

Full virtual vs Paravirtual

Leave a comment

En la lista de CentOS en Español, surgió un hilo muy interesante el mes pasado sobre sistemas de virtualización para CentOS, derivó a un tema sin salida de sistemas de virtualización que no son para CentOS, luego regresó al tema.. un usuario de la lista habló muy bien de Xen y a mi me gusta Xen y uso Xen desde fines del 2004! Pero igual he visto y probado que KVM es bueno, y en la lista puse un breve escrito sobre cómo comprender que KVM es igual de bueno pues usa algunas técnicas de paravirtualización en algunos dispositivos, aquí va (le he corregido algunas faltas y aclarado cosas que me quedaron en el aire por el apremio):

Dijo el otro usuario (y luego le respondo yo):

xen me parece mejor, porque soporta paravirtualizacion, si tienes un
micro con soporte V-XM, puedes correr incluso un SO instalado y
funcionando en otro disco duro. Ademas de poder direccionar hardware
para un huesped en particular.
No soy experto ni nada pero lo que he leido acerca de xen dan mas que ganas.
Pero tambien hay que ver que quieres virtualizar, porque una cosa es
un SO completo y otra es virtualizar tu propio SO para hacer como
jaulas clonando tu instalacion para otros servicios.
Es verdad lo que indicas y lo apruebo. La paravirtualización es
maravillosa. Y me encanta Xen y le usé mucho tiempo, y le usaré si es
necesario.
Sin embargo, la brecha entre sistemas full virtualizados y paravirtuales
se ha ido reduciendo a casi nada. Y me explico (con simples palabras):

La full virtualización (kvm por ejemplo, xen también) le asigna un slice
de tiempo de procesador a la máquina virtual, esta máquina le usa
directamente al procesador durante este periodo, y le guste o no, a
través de herramientas incorporadas en el procesador, se le saca a la
máquina del procesador y se le devuelve el control al hospedero.

Ventajas: no hay que emular el procesador, no hay que usar llamadas al
hospedero por parte de los invitados para acceder al procesador. Es
acceso directo al procesador! Maravilloso!!!

Sin embargo la full virtualización tenía algunos inconvenientes que no
tenía la paravirtualización (xen por ejemplo soporta paravirtualización)
y es que para el resto de dispositivos (red, disco, ram) había que 
emular para que las máquinas virtuales full virtualizadas accedieran
a ellos. En pocas palabras: Emulación=lentitud.

Entonces algunos (yo incluído) siempre decíamos que la full
virtualización, tal y como se usaba en principio no traía ventajas, o
mejor aún, digamos que la paravirtualización era más rápida.

Por qué? porque en la paravirtualización el invitado está programado
para ejecutar llamadas pre-establecidas al hospedero para realizar
ciertas labores hacia dispositivos. Por ejemplo, no accede directamente
a la tarjeta de red, sino que invoca a llamadas preestablecidas
(funciones) en el hospedero y este le hace la comunicación de red. Lo
mismo al disco, lo mismo a la ram y a otros dispositivos menos
importantes ahora.

Entonces no había que emular hardware.. simplemente llamadas, y el
hospedero a través de su sistema operativo y drivers específicos,
realizaba la labor de comunicación con la red, disco, etc... esto era
rapidísimo, tan rápido como acceder desde el hospedero mismo.

Lo único que podía ralentizar un poquiiiiiiiiiiiiiiiiiiiito era el hecho
de la llamada misma.. pero era algo negligible.. es algo que impacta poco.

Es por eso que decíamos:
-> paravirtual=rapido,
-> full virtual=rapido el procesador, emulado el resto.

Por qué no se puede hacer una mezcla? Qué tal algo full virtual para el
procesador (que es lo que es a la final) y paravirtual el resto? Bueno,
pues "porque los sistemas operativos privativos no pueden ser
modificados" pensaban algunos.. y si no puedo incorporar las llamadas
pre-establecidas entre el invitado que corre un sistema operativo
privativo y el invitado con KVM por ejemplo.. pues no puedo hacer
paravirtualización!

Full virtualización sin embargo no requiere de modificaciones en el
SO con la finalidad de que corra como máquina virtual. Esto lo hacía 
útil para SO privativos. Pero lento por otro lado.

Ahh.. entonces full virtualización para los privativos y
paravirtualización para los que pueden ser modificados (SL)? En
principio algunos pensaron así.

Hasta que alguien sacó a la luz una idea: Pensemos que tengo windows, y
que hago un driver de red llamado digamos virt-net que ese driver, se
incorpora como todo driver de windows al kernel que corre.. y este
driver tiene las llamadas pre-establecidas para comunicarse y
enviar/recibir las peticiones de red con el hospedero en KVM por ejemplo.

Además hago un driver llamado virt-block que igual se comunicará con el
hospedero para enviar/recibir las peticiones de disco. Y hago uno
llamado virt-balloon que se ocupará de mantener las llamadas
pre-establecidas para comunicarse con el hospedero y atender las
llamadas a las operaciones con la ram (fundamentalmente reducir/ampliar
la ram en uso del invitado).

Ah bacán! Todos esos drivers serán drivers "paravirtuales" y sustituirán
la necesidad de drivers "emulados". Qué hay en tu mente?
paravirtual=rápido, emulación=lento.

Entonces qué logro? rapidez! Un sistema full virtual para acceso nativo
y directo al procesador + drivers paravirtuales de red, disco y ram que
permiten acceso casi directo a estos recursos a través del hospedero..

Esto lo hace KVM:
- Al usar un SO Linux, estos ya vienen con los drivers paravirtuales, y
funciona rapidísimo el sistema.
- Al usar un SO tipo windows por ejemplo, le indicas a Windows que por
favor use un disco de drivers (virtio-win)
http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers y
windows detectará tu tarjeta de red paravirtual, disco paravirtual y
balloon paravirtual. Para esto es necesario decirle al KVM antes de
comenzar a instalar que estos tres dispositivos serán de tipo virtio..
windows no verá disco al inicio, hasta que introduzcas el CD de drivers
y entonces ahi verá el disco PV, red PV, etc.

Rápido? rapidísimo, además de que hace latente una de las ventajas de la
virtualización que es la independencia de las máquinas virtuales del
hardware.. ellas no conocen el hardware bajo el que se ejecutan, sino
que quien sabe del hardware es elhospedero, esto facilita la migración
(cosa que también KVM hace) entre hardware, etc.

Para terminar insisto: KVM y Xen son los dos sistemas de virtualización
más importantes en nuestro mundillo de CentOS.. también puedes usar LXC,
qemu, virtuozzo y otras cosillas, pero fundamentalmente kvm y xen son
los duros. Proxmox y todos esos paneles que hablan, simplemente son
paneles que manejan y facilitan el uso de los sistemas de virtualización
KVM, Xen, LXC, virtuozzo... tal y como virt-manager o virsh lo hacen a
su forma. Pero para mi me parece importante comprender lo que hay
debajo, antes de saltar a usar un panel  y ya.

saludos
epe
bash, Linux, RadioAfición

bash script for consulting QRZ.com via XML

1 Comment

well, here is a simple shell script I use to query callsigns’ information from QRZ.com. You had to have the XML Logbook data plan from QRZ.com in order to use it.

Simply change the first two lines to use your username/password and voilá..

#!/bin/bash
username=”hc6pe”
password=”mypassword”

rm -f /tmp/login

xml2=`which xml2 2> /dev/null`
[ $? -ne 0 ] && { echo “missing xml2, please install it”; exit 1; };
wwget=`which wget 2> /dev/null
[ $? -ne 0 ] && { echo “missing wget, please install it”; exit 1; };

$wwget -q -O – “http://xmldata.qrz.com/xml/current/?username=$username&password=$password”|egrep “<Key>”|awk -F”>” ‘{print $2}’|awk -F”<” {‘print $1’} > /tmp/login

$wwget -q -O – “http://xmldata.qrz.com/xml/current/?s=`cat /tmp/login`;callsign=$1″|$xml2 > /tmp/lookup
fname=`cat /tmp/lookup|egrep “/fname” |cut -f2 -d ‘=’`
name=`cat /tmp/lookup|egrep “/name”|cut -f2 -d ‘=’`
addr1=`cat /tmp/lookup|egrep “/addr1″|cut -f2 -d ‘=’`
addr2=`cat /tmp/lookup|egrep “/addr2″|cut -f2 -d ‘=’`
zip=`cat /tmp/lookup|egrep “/zip”|cut -f2 -d ‘=’`
country=`cat /tmp/lookup|egrep “/country”|cut -f2 -d ‘=’`
state=`cat /tmp/lookup|egrep “/state”|cut -f2 -d ‘=’`

echo $fname $name
echo $addr1
[ -z “$addr2” ] || { echo $addr2; };
echo $state $zip
echo $country

I put the script under ~/bin/xmlretriever.sh (the bin under my home) and chmodded +x, then query for my own callsign here is the result:

[eperez@laptop ~]$ xmlretriever.sh hc6pe
Ernesto (EPE) Perez Estevez
Las Toronjas 02-45 y Mandarinas
Ficoa, Ambato
TU EC180102
Ecuador

Centos, Linux

software raid? no gracias!

bueno, me dieron a instalar un HP Proliant ML310e Gen8 con un array llamado b120i.

Luego de varias horas probando y recontraprobando cómo no usar el fake-raid b120i encontré cómo desactivarle, en el BIOS voy a:

System Options -> SATA Controller Options -> Embedded SATA Configuration

Y escogí “Enable SATA AHCI Support” antes estaba en Enable Dynamic HP Smart Array B210i RAID Support

Ahí pude usar software raid bien, y booteó bien.

Además intenté usar lo que decían aquí pero fallaba miserablemente, quizá porque eran drivers para centos-6.3 y yo tengo 6.5

http://h20566.www2.hp.com/portal/site/hpsc/template.PAGE/public/psi/swdDetails/?sp4ts.oid=5249571&spf_p.tpst=swdMain&spf_p.prp_swdMain=wsrp-navigationalState%3Didx%253D2%257CswItem%253DMTX_83d3c3cf4b3d47b2ae6eb71612%257CswEnvOID%253D4103%257CitemLocale%253D%257CswLang%253D%257Cmode%253D4%257Caction%253DdriverDocument&javax.portlet.begCacheTok=com.vignette.cachetoken&javax.portlet.endCacheTok=com.vignette.cachetoken

Fedora, Linux

Instalando laserjet 100 color mfp m175a en Fedora-20

Leave a comment

Bueno, un cliente adquirió una impresora HP LaserJet 100 color MFP M175a y deseaba que yo le instalara en Fedora.

Esta es una impresora Láser a Color, con escaner y lógicamente copiadora.

Primero intenté lo más trivial fotocopiar, y sí, fotocopia, luego imprimir, me fui a agregar impresoras en Fedora y le agregó, e imprimí una paginita de prueba. Todo feliz hasta el momento.

Cuando quise escanear .. ahi fue el peque problema. Para el que no escanee, todo está bien y feliz, pero si escaneas no funciona.

Probé con un programa llamado “Simple Scan” y le ve al scanner, pero cuando intentas escanear, falla, da un error diciendo que no puede acceder al escanner.

Instalé el xsane, a la final es el programa que me gusta para escanear:

sudo yum install hplip-common xsane sane-backends*

Y al arrancar el xsane, detecta el scanner, pero igualmente falla con un error raro o básico ahi.

Entonces me fui al sitio de HP y busqué bajar el driver de esta impresora, al escoger Linux me llevó al sitio de hplip (http://hplipopensource.com/node/309) y al buscar información sobre la impresora, me da la noticiota de que esta impresora requiere un driver propietario para que funcione en Linux.

A los que son puristas y no pueden usar por cuestiones morales drivers propietarios… aqui acabaría el post. A los que compraron la impresora y no la pueden devolver ya.. pueden probar esto:

Instalas hplip-gui que es el progrma que se encarga de bajar el driver propietario de HP para esta impresora:

sudo yum install hplip-gui

Luego ejecutas:

hp-setup

ahi escoges el tipo de conexión (USB, la primera) y luego escoges la impresora en la siguiente página.. entonces le dices que baje automáticamente el driver adecuado para la impresora, luego de unos segundos lo baja y te pedirá instalar la impresora. En este paso yo eliminé la impresora que había instalado anteriormente (ver más arriba al inicio) y entonces le dije que sí, que le instalara. Y listo, le instaló la impresora.

Luego de esto el xsane funcionó de una y sin ningún inconveniente. No he probado la impresora todavía pero supongo funcione bien.

 

bash, Centos, Linux, mock, rsyslog

Activando guardar históricos al syslog del bash en CentOS

Leave a comment

Ando probando una que otra cosa, pero esta me parece fundamental, hace días que vengo con la idea de que bash guarde todos los comandos que los usuarios emiten hacia syslog.

Esto con la finalidad incluso de llevar un mucho más largo history de los comandos que los usuarios escriban. Incluso poder enviarlos hacia otro servidor para almacenarlos.

Me guié por este documento, que sirven muchas cosas. Pero otras cambié por el bien de tener un ambiente aislado para pruebas y para que funcionara en CentOS-6

Comencemos:

Instalación de mock:

Instalé el paquete mock en un servidor virtual que uso para compilar paquetes de prueba en la ESPOCH.

Este servidor virtual es CentOS-6 de 64bits. Debe ser de 64bits para que pueda compilar paquetes de 64bits y de 32bits. De lo contrario no podrá compilarse paquetes de 64bits sino solamente de 32bits.

yum install mock

Creé un usuario para realizar las compilaciones:

useradd eperez

passwd eperez

Y entonces agregué el usuario eperez al grupo mock, este grupo, en el archivo /etc/group queda así:

mock:x:135:eperez

De no hacer al usuario parte del grupo mock, este usuario no podrá usar mock.

A partir de ahora todo trabajo con mock lo hago con mi usuario eperez. No se hace ningún trabajo como root, sólo mock.

su – eperez

Compilación de bash (todo esto lo haré dentro del usuario eperez):

Me bajé el último paquete de bash que existe al día de hoy (este podrá variar a futuro, hay que estar alerta de las versiones más modernas) y le instalé:

wget http://vault.centos.org/6.5/os/Source/SPackages/bash-4.1.2-15.el6_4.src.rpm

rpm -Uvh bash-4.1.2-15.el6_4.src.rpm

Ahora viene lo más duro, que es generar un diff con los cambios que se harán. Para ello abriré el tar.gz del bash, haré una copia de este directorio, cambiaré un par de archivos, y luego de esto generaré un diff entre el directorio de la copia y el directorio del original.

cd rpmbuild/SOURCES

tar zxf bash-4.1.tar.gz

cp -r bash-4.1 bash-4.1.orig

cd bash-4.1

Edito entonces el archivo config-top.h y sobre la línea 104 descomento la línea (está comentada con /* */ no quito el signo de # delante, es un .h de C, los # son parte del comando. Entonces termino dejando la línea solamente así:

#define SYSLOG_HISTORY

Y cambio las dos siguientes líneas que definen SYSLOG_FACILITY y SYSLOG_LEVEL para que tengan los valores LOG_LOCAL1 y LOG_DEBUG respectivamente, ambas líneas quedarían así (marco en negritas los dos cambios):

#  define SYSLOG_FACILITY LOG_LOCAL1
#  define SYSLOG_LEVEL LOG_DEBUG

Ahora edito bashhist.c y modifico las líneas 708 y 713 para que queden así (en negritas marco precisamente todo lo que cambié):

Línea 708

syslog (SYSLOG_FACILITY|SYSLOG_LEVEL, “HISTORY: PPID=%d PID=%d SID=%d UID=%d User=%s %s”, getppid(), getpid(), getsid(getpid()), current_user.uid, current_user.user_name, line);

Línea 713:

syslog (SYSLOG_FACILITY|SYSLOG_LEVEL, “HISTORY (TRUNCATED): PPID=%d PID=%d SID=%d UID=%d User=%s %s”, getppid(), getpid(), getsid(getpid()), current_user.uid, current_user.user_name, trunc);

Estamos listos para preparar el diff, salgamos al directorio SOURCES y creemos el diff:

cd ..

pwd

[eperez@mock bash-4.1]$ cd ..
[eperez@mock SOURCES]$ pwd
/home/eperez/rpmbuild/SOURCES

diff -Npur bash-4.1.orig bash-4.1 > bash_history_syslog.patch

 

Ahh, para esto es que habíamos hecho una copia del directorio bash, llamada bash-4.1.orig, es para que el diff pueda comparar y guardar los cambios. Al final estos cambios los guardé en bash_history_syslog.patch el puedes bajar de http://www.ecualinux.com/bash_history_syslog.patch para el que quiera ahorrarse todo el anterior proceso: este archivo debe ponerse en rpmbuild/SOURCES/ .

Ahora me cambio al directorio SPECS/ para editar el archivo bash.spec, cambiaré las siguientes líneas:

cd

cd rpmbuild/SPECS

vi bash.spec

# agrego _99 en la línea 8

Release: 15_99%{?dist}

# luego de la línea 41 agrego toda esta línea:

Patch999: bash_history_syslog.patch

# y luego de la línea 124 agrego toda esta línea:

%patch999 -p1 -b .history_syslog

Lo que hice fue cambiar la numeración del bash, ahora se llamaría -15_99.el6 (aparecerá un _99) esto es para evitar que luego un yum update me vuelva a instalar el viejo bash sin syslog.

Pero eso sí! hay que tener en mente que si mañana llega otro bash, el Release -16 por ejemplo, tendré que rehacer un nuevo rpm -16_99 por ejemplo.

Agregué además un nuevo parche, el 999 (puse un número alto para evitar que tropiece con futuros números de parches). Este parche se aplicará cada vez que compile el src.rpm, incorporando el envío de los comandos a syslog como deseo.

Ahora crearé el src.rpm del nuevo bash, lo guardaré hacia un directorio seguro (porque del directorio result/ le borra tan pronto compilo otra cosa), y le compilo al nuevo src.rpm para obtener el nuevo rpm:

cd

mock -r epel-6-x86_64 –sources=rpmbuild/SOURCES/ –spec=rpmbuild/SPECS/bash.spec –buildsrpm

mv /var/lib/mock/epel-6-x86_64/result/bash-4.1.2-15_99.el6.src.rpm .

mock -r epel-6-x86_64 bash-4.1.2-15_99.el6.src.rpm

mv /var/lib/mock/epel-6-x86_64/result/bash* .

como resultado tendré mi nuevo rpm!

[eperez@mock ~]$ ls
bash-4.1.2-15_99.el6.src.rpm
bash-4.1.2-15_99.el6.x86_64.rpm

ok, habrán más archivos, pero son los que ahora me interesan.

Si quisiera compilar el bash para 32bits, de una ejecuto:

mock -r epel-6-i386 bash-4.1.2-15_99.el6.src.rpm

mv /var/lib/mock/epel-6-i386/result/bash* .

Pues el mismo src.rpm me sirve para crear el de 32bits.

Instalando el nuevo bash (como root):

Me llevo este nuevo rpm hacia otro servidor, y le instalo:

rpm -Uvh bash-4.1.2-15_99.el6.x86_64.rpm

Entonces salgo y entro de nuevo, ya el nuevo bash estará activo.

Configurando rsyslog para recibir eventos de logs (como root):

Ahora edito /etc/rsyslog.conf y luego de una línea que comienza “local7.*”, agrego lo siguiente:

#bash
local1.debug                        /var/log/bash.log

Y reinicio rsyslog:

service rsyslog restart

Ahora disfruta, mira bash.log y verás que todo comando ahi aparecerá:

Dec 19 07:40:40 mock -bash: HISTORY: PPID=27954 PID=27955 SID=27937 UID=500 User=eperez vi bash.spec
Dec 19 07:44:54 mock -bash: HISTORY: PPID=27954 PID=27955 SID=27937 UID=500 User=eperez history |less
Dec 19 07:46:47 mock -bash: HISTORY: PPID=27954 PID=27955 SID=27937 UID=500 User=eperez cd
Dec 19 07:46:48 mock -bash: HISTORY: PPID=27954 PID=27955 SID=27937 UID=500 User=eperez mv /var/lib/mock/epel-6-x86_64/result/bash* .
Dec 19 07:46:49 mock -bash: HISTORY: PPID=27954 PID=27955 SID=27937 UID=500 User=eperez ls
Dec 19 07:48:13 mock -bash: HISTORY: PPID=27954 PID=27955 SID=27937 UID=500 User=eperez mock -r epel-6-i386 bash-4.1.2-15_99.el6.src.rpm
Dec 19 07:51:12 mock -bash: HISTORY: PPID=4187 PID=4511 SID=4511 UID=0 User=root cat /etc/rsyslog.conf
Dec 19 07:52:22 mock -bash: HISTORY: PPID=4187 PID=4511 SID=4511 UID=0 User=root tai /var/log/messages
Dec 19 07:52:25 mock -bash: HISTORY: PPID=4187 PID=4511 SID=4511 UID=0 User=root tail -f /var/log/messages
Dec 19 07:52:28 mock -bash: HISTORY: PPID=4187 PID=4511 SID=4511 UID=0 User=root tail -f /var/log/bash.log
Dec 19 08:01:13 mock -bash: HISTORY: PPID=27954 PID=27955 SID=27937 UID=500 User=eperez mv /var/lib/mock/epel-6-i386/result/bash-* .

Disfruten!

La forma fácil:

Si no tenemos tiempo para crear el rpm comento que estos rpm para CentOS-6 les he puesto  en el repo anku de EcuaLinux que es publico y que da bastante trabajo echar a andar un nuevo repo sólo por escasos paquetes, le instalo al repo:

wget -O /etc/yum.repos.d/anku.repo http://centos6.ecualinux.com/centosec.repo

Y ya luego:

yum update bash

Centos, Fedora, Firewall, Linux

Primeras impresiones sobre RHEL-7-beta1

Leave a comment

Salió hace pocos días, no había tenido tiempo de probarle, pero aquí van mis comentarios iniciales.

Le bajé el ISO que, a propósito es sólo 64bits, RHEL-7 no vendrá con soporte de 32 bits. Y la verdad es que, el que tenga 32bits, podrá seguir usando su hardware con la versión 6 de CentOS o RHEL hasta el 2020, suficiente tiempo pienso yo. No dudo tampoco que alguien se aloque y lance CentOS-7 para 32bits, pero eso habría que verle.

Por otro lado, la verdad es que ningún hardware que se vende para servidores (recordar que RHEL y CentOS son para servidores) ya viene con 32bits. No es que se ve un equipo de 32bits estos días como servidor muy fácilmente. De hecho ya CentOS-6 venía con el sistema de virtualización SOLO para 64bits, si tu instalabas CentOS-6 de 32bits, no ibas a virtualizar nada ahi.

Le instalé dentro de una máquina virtual de KVM. Este KVM está en CentOS-6.5, le puse 1GB de RAM, 2 procesadores y 30GB en disco.

La interfaz del instalador parece la de fedora-18 ó fedora-19 mejor dicho. Es de esa pantalla que te aparece todo ahi mismo, vas dando click en las entradas y escogiendo diversas cosas (disco de instalacion, tipo de instalación, etc) pero toda en la misma pantalla. Es algo que particularmente no me gustaba de fedora, pero bueno, le han adoptado y habrá que acostumbrarse.

De todas formas la idea sigue siendo la misma de toda la vida de RedHat: preguntarte todo lo que te tenga que preguntar al inicio. No hay nada más pesado que esos instaladores que instalan un buchito de cosas, y se detienen a preguntarte tu clave.. para luego seguir y luego de 2 minutos preguntarte el idioma, y luego de 2 más preguntarte el tipo de partición y así tenerte castigado durante todo el proceso de instalación pues tienes que responder preguntas.

En el idioma de instalación, está en Español, aunque cuando le escogí me falló 2 ó 3 veces luego durante la instalación, pero no sé si es que fallaba por el idioma o por el tipo de particionamiento que le escogí con LVM-thin-provisioning… en todo caso cuando instalé en Inglés y sin thin-provisioning me funcionó.

Por defecto te propone escoger instalación mínima, excelente!

Al finalizar de instalar, la consola de texto ya no viene con 80×25  el tamano, sino que viene con otro tipo de letra muy pequeño, me dió bastante dificultad leerle porque dentro de KVM aún más pequeño se veía todo.

Al entrar, lo primero que hice fue tratar de encontrar la IP para entrar inmediatamente por ssh porque el tipo de letra es bieeeen pesado de leer para mi. Así que puse ifconfig y.. pum.. no viene instalado! En serio.. quizá networkmanager tenga otra forma de ver las interfaces, pero todavía no le conozco. Oh sí.. proponen NetworkManager aún para instalaciones via línea de comando!

Bueno, mejor aún, no había red activada así que puse ifup eth0.. pero de todas formas el misterio de la IP persistía no?

yum provides */ifconfig

para averiguar dónde estaba.. me sale el yum conque el sistema no está registrado en la red de redhat.. caramba, es la falta de costumbre, con centos todo es más fácil eh?

así que ejecuté

subscription-manager register

Y usé mi cuenta, dice redhat que no es necesario haber tenido una cuenta, que con

subscription-manager register –autosubscribe

Te iba a autosuscribir de una.

De todas formas el yum ahora me decía que no había ningún canal activo. Yo entro en shock cuando no entiendo esas cosas.. qué es un canal? entrar al sitio de redhat a averiguar? En lo que lo abría tuve a bien editar /etc/yum.repos.d/rhel.repo y cambiar enabled=1 en el primer repo el de redhat.. y ahí sí! al fin así puse usar

yum provides */ifconfig

El paquete es: net-tools, entonces puse

yum install net-tools

Y ya! Al fin ifconfig!! ahi pude averiguar mi ip, 9 minutos. Bueno, tampoco es que andaba de apremio 😉

Veamos algunas características:

[root@localhost ~]# w
11:53:31 up 9 min,  1 user,  load average: 0.01, 0.08, 0.07
USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0     11:53    3.00s  0.04s  0.02s w
[root@localhost ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Everything release 7.0 Beta (Maipo)

buen consumo de ram:

[root@localhost ~]# free -m
total       used       free     shared    buffers     cached
Mem:           994        429        564          1          1        285
-/+ buffers/cache:        142        851
Swap:         2079          0       2079

Lista de procesos:

[root@localhost ~]# ps axf
PID TTY      STAT   TIME COMMAND
2 ?        S      0:00 [kthreadd]
3 ?        S      0:00  \_ [ksoftirqd/0]
4 ?        S      0:00  \_ [kworker/0:0]
5 ?        S<     0:00  \_ [kworker/0:0H]
6 ?        S      0:00  \_ [kworker/u4:0]
7 ?        S      0:00  \_ [migration/0]
8 ?        S      0:00  \_ [rcu_bh]
9 ?        S      0:00  \_ [rcuob/0]
10 ?        S      0:00  \_ [rcuob/1]
11 ?        S      0:00  \_ [rcu_sched]
12 ?        S      0:00  \_ [rcuos/0]
13 ?        S      0:00  \_ [rcuos/1]
14 ?        S      0:00  \_ [watchdog/0]
15 ?        S      0:00  \_ [watchdog/1]
16 ?        S      0:00  \_ [migration/1]
17 ?        S      0:00  \_ [ksoftirqd/1]
19 ?        S<     0:00  \_ [kworker/1:0H]
20 ?        S<     0:00  \_ [khelper]
21 ?        S      0:00  \_ [kdevtmpfs]
22 ?        S<     0:00  \_ [netns]
23 ?        S<     0:00  \_ [writeback]
24 ?        S<     0:00  \_ [kintegrityd]
25 ?        S<     0:00  \_ [bioset]
26 ?        S<     0:00  \_ [kblockd]
27 ?        S      0:00  \_ [khubd]
28 ?        S<     0:00  \_ [md]
31 ?        S      0:00  \_ [kswapd0]
32 ?        SN     0:00  \_ [ksmd]
33 ?        SN     0:00  \_ [khugepaged]
34 ?        S      0:00  \_ [fsnotify_mark]
35 ?        S<     0:00  \_ [crypto]
44 ?        S<     0:00  \_ [kthrotld]
46 ?        S<     0:00  \_ [kmpath_rdacd]
47 ?        S      0:00  \_ [kworker/1:1]
48 ?        S<     0:00  \_ [kpsmoused]
49 ?        S<     0:00  \_ [deferwq]
50 ?        S      0:00  \_ [kworker/1:2]
55 ?        S      0:00  \_ [kauditd]
214 ?        S      0:00  \_ [kworker/0:2]
215 ?        S      0:00  \_ [kworker/u4:2]
217 ?        S<     0:00  \_ [ata_sff]
220 ?        S      0:00  \_ [scsi_eh_0]
221 ?        S      0:00  \_ [scsi_eh_1]
231 ?        S<     0:00  \_ [ttm_swap]
244 ?        S<     0:00  \_ [kworker/0:1H]
307 ?        S<     0:00  \_ [kdmflush]
308 ?        S<     0:00  \_ [bioset]
310 ?        S<     0:00  \_ [kdmflush]
311 ?        S<     0:00  \_ [bioset]
329 ?        S<     0:00  \_ [xfsalloc]
330 ?        S<     0:00  \_ [xfs_mru_cache]
331 ?        S<     0:00  \_ [xfslogd]
332 ?        S<     0:00  \_ [xfs-data/dm-1]
333 ?        S<     0:00  \_ [xfs-conv/dm-1]
334 ?        S<     0:00  \_ [xfs-cil/dm-1]
335 ?        S      0:00  \_ [xfsaild/dm-1]
339 ?        S<     0:00  \_ [kworker/1:1H]
443 ?        S      0:00  \_ [vballoon]
472 ?        S<     0:00  \_ [hd-audio0]
475 ?        S<     0:00  \_ [xfs-data/vda1]
476 ?        S<     0:00  \_ [xfs-conv/vda1]
477 ?        S<     0:00  \_ [xfs-cil/vda1]
478 ?        S      0:00  \_ [xfsaild/vda1]
9143 ?        S      0:00  \_ [kworker/1:0]
1 ?        Ss     0:01 /usr/lib/systemd/systemd –switched-root –system –d
394 ?        Ss     0:00 /usr/lib/systemd/systemd-journald
406 ?        Ss     0:00 /usr/sbin/lvmetad
429 ?        Ss     0:00 /usr/lib/systemd/systemd-udevd
491 ?        S<sl   0:00 /sbin/auditd -n
508 ?        Ssl    0:01 /usr/bin/python /usr/sbin/firewalld –nofork –nopid
511 ?        Ss     0:00 avahi-daemon: running [linux.local]
535 ?        S      0:00  \_ avahi-daemon: chroot helper
512 ?        Ssl    0:00 /sbin/rsyslogd -n
513 ?        Ss     0:00 /usr/sbin/irqbalance –foreground
515 ?        Ssl    0:00 /usr/bin/python -Es /usr/sbin/tuned -l -P
516 ?        Ss     0:00 /usr/lib/systemd/systemd-logind
518 ?        Ssl    0:00 /bin/dbus-daemon –system –address=systemd: –nofork
523 ?        Ss     0:00 /usr/sbin/crond -n
565 ?        Ss     0:00 /sbin/iprinit –daemon
568 ?        Ss     0:00 /sbin/iprupdate –daemon
588 ?        Ss     0:00 /sbin/iprdump –daemon
736 ?        Ssl    0:00 /usr/sbin/NetworkManager –no-daemon
9052 ?        S      0:00  \_ /sbin/dhclient -d -sf /usr/libexec/nm-dhcp-helper
776 ?        Ssl    0:00 /usr/lib/polkit-1/polkitd –no-debug
827 ?        Ss     0:00 /usr/bin/rhsmcertd
932 ?        Ss     0:00 /usr/sbin/sshd -D
9168 ?        Ss     0:00  \_ sshd: root@pts/0
9172 pts/0    Ss     0:00      \_ -bash
9194 pts/0    R+     0:00          \_ ps axf
1402 ?        Ss     0:00 /usr/libexec/postfix/master -w
1418 ?        S      0:00  \_ pickup -l -t unix -u
1419 ?        S      0:00  \_ qmgr -l -t unix -u
9189 tty1     Ss+    0:00 /sbin/agetty –noclear tty1

networkmanager! me va a dar un ataquito.. tendré que aprenderle a usar en CLI, la herramienta de CLI anterior era horrible, espero la hayan mejorado! Aunque leí en algún lado que podías seguir usando el viejo network

firewalld, es de investigar espero sea fácil, por el sitio de fedora encontré un howto

Usan postfix.. bien! Aunque si deseas, está sendmail en la lista de paquetes, tal y como estaba en CentOS-6, pero leí que en las siguientes versiones (RHEL-8?) posiblemente saquen a sendmail de la lista de paquetes

Estilo Fedora, usan cgroup, así que parece que ahora sí en serio debemos ponernos para esto.

El Filesystem que proponen usar ya no es ext4, dicen que con XFS es mejor el desempeño así que usan xfs de filesystem.

Tienen algo nuevo: LVM-thin-provisioning, quise instalar pero fallaba, como comenté anteriormente no sé si fue el idioma o esto.

ifconfig, nada nuevo, tengo ipv6

[root@localhost ~]# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 172.30.60.146  netmask 255.255.255.0  broadcast 0.0.0.0
inet6 2800:68:a:60:5054:ff:fe7d:69fb  prefixlen 64  scopeid 0x0<global>
inet6 fe80::5054:ff:fe7d:69fb  prefixlen 64  scopeid 0x20<link>
ether 52:54:00:7d:69:fb  txqueuelen 1000  (Ethernet)
RX packets 13314  bytes 13408407 (12.7 MiB)
RX errors 0  dropped 63  overruns 0  frame 0
TX packets 3400  bytes 508908 (496.9 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10<host>
loop  txqueuelen 0  (Local Loopback)
RX packets 64  bytes 5952 (5.8 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 64  bytes 5952 (5.8 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

consumo de disco:

[root@localhost ~]# df -h
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/rhel-root   28G  828M   27G   3% /
devtmpfs               491M     0  491M   0% /dev
tmpfs                  498M     0  498M   0% /dev/shm
tmpfs                  498M  1.7M  496M   1% /run
tmpfs                  498M     0  498M   0% /sys/fs/cgroup
/dev/vda1              484M   92M  392M  20% /boot

bueno, 828M está muy bien.

servidor web? httpd-2.4.6, nada de hiawatha, ni nginx, ni lighttpd

php? 5.4.16

Usa systemd, ya no usa chkconfig (no dudo que haga el truco que fedora hace para reconocer los antiguos comandos)

iptables, puerto 22, 546 y 631 abiertos, tanto en ipv6 como en ipv4.

kernel?

uname -rv
3.10.0-54.0.1.el7.x86_64 #1 SMP Tue Nov 26 16:51:22 EST 2013

3.10.0, qué pena que no fue el 3.11 for WorkGroups! Me hubiera divertido durante tantos años!

Qué hago si no hay mysql en CentOS-7 ??? Hace tiempo vengo usando mariadb.. así que mejor que mejor ya RHEL-7 viene con MariaDB!

[root@localhost ~]# yum list mysql*
Loaded plugins: product-id, subscription-manager
This system is registered to Red Hat Subscription Management, but is not receiving updates. You can use subscription-manager to assign subscriptions.
Available Packages
MySQL-python.x86_64                       1.2.3-8.el7                  rhel-beta
mysql-connector-java.noarch               1:5.1.25-2.el7               rhel-beta
mysql-connector-odbc.x86_64               5.2.5-2.el7                  rhel-beta
[root@localhost ~]# yum list maria*
Loaded plugins: product-id, subscription-manager
This system is registered to Red Hat Subscription Management, but is not receiving updates. You can use subscription-manager to assign subscriptions.
Installed Packages
mariadb-libs.x86_64                     1:5.5.33a-3.el7            @anaconda/7.0
Available Packages
mariadb.i686                            1:5.5.33a-3.el7            rhel-beta
mariadb.x86_64                          1:5.5.33a-3.el7            rhel-beta
mariadb-bench.x86_64                    1:5.5.33a-3.el7            rhel-beta
mariadb-devel.i686                      1:5.5.33a-3.el7            rhel-beta
mariadb-devel.x86_64                    1:5.5.33a-3.el7            rhel-beta
mariadb-embedded.i686                   1:5.5.33a-3.el7            rhel-beta
mariadb-embedded.x86_64                 1:5.5.33a-3.el7            rhel-beta
mariadb-embedded-devel.i686             1:5.5.33a-3.el7            rhel-beta
mariadb-embedded-devel.x86_64           1:5.5.33a-3.el7            rhel-beta
mariadb-libs.i686                       1:5.5.33a-3.el7            rhel-beta
mariadb-server.x86_64                   1:5.5.33a-3.el7            rhel-beta
mariadb-test.x86_64                     1:5.5.33a-3.el7            rhel-beta

Eso es todo por el momento sobre RHEL-7 , te imaginarás que en 10 minutos (de los cuales la mayoría los pasé tratando de encontrar el ifconfig) no puedo ver mucho más, pero me pinta bien y fácil, ciertos cambios que son naturales y hay que asumirlos pues parece que es el camino.

Centos, Fedora, Linux

Cómo agilizar las actualizaciones de CentOS y Fedora

Leave a comment

Si usas CentOS, RHEL o Fedora, hay un plugin de yum muy bueno llamado yum-presto que lo que hace es bajar solamente las porciones de los paquetes rpm que le tocaría actualizar.

Digamos tienes un paquete X-1, y CentOS te indica que ya está la versión X-1.1… normalmente lo que hacen las distribuciones es bajar completamente X-1.1 y actualizar verdad?

Ahora, supongamos que entre X-1 y X-1.1 sólo haya cambiado no sé, digamos 10 bytes de un archivo (es un ejemplo), qué tal que  en vez de bajar TODO X-1.1, se baje simplemente la diferencia que hay entre X-1.1 y X-1

Para esto es yum-presto. yum-presto analiza las diferencias entre las dos versiones: la instalada y la actualizada; y solamente baja lo que cambió, y aplica estos cambios al sistema.

Qué ventaja obtenemos? Que se reduce el tamaño de las actualziaciones, si antes tenías que bajar 300MB por ejemplo.. ahora quizá tengas que bajar los diff, y estos diffs sean solamente el 10% de estos 300MB.. es decir 30MB.

Realiza cualquier cálculo : supón hayan 40MB de actualizaciones, pero en diffs solamente tengas que bajar digamos 8MB..

Ventajas: baja más rápido las actualizaciones. Mucho más. Por tanto ya se acaba la queja de que actualizar es lento.

Desventajas? : hay una y es que para actualizar primero tiene que hacer cierto procesamiento en tu máquina con el delta .. es decir, toma el diff, lo incorpora dentro del paquete anterior y ese es con el que actualiza. Lo que consume un poquito de tiempo de procesador. Tampoco es una cantidad absurda o lenta, pero se demorará un poco. Es decir, cambiamos la velocidad de bajada, por un breve consumo de procesador mientras le utilizamos. Es totalmente aceptable y la experiencia termina siendo positiva en efecto.

Cómo usamos yum-presto? Muy simple, le instalamos:

yum install yum-presto

Y ya, de ahora en adelante, tus actualizaciones verás que se dividen en dos partes:

  1. se bajan los deltas. Son archivos con extensión .drpm
  2. se bajan los que no tenían deltas. Porque algunos tienen tantos cambios que no es rentable tener un delta y mejor bajarlos completo.

Pruébalo:

yum update

y analiza cómo van pasando los delta.

Hiawatha, Linux

How do I create a hiawatha webserver rpm?

2 Comments

This howto will explain how to create a CentOS-5 and centOS-6 rpm for hiawatha webserver, a security-centric webserver.

Installing mock

I do all my rpm building in a separate and isolated virtual machine.. you probably will want to do this.. install a CentOS-6 x86_64 virtual machine and then install mock:

I installed mock from the EPEL repository:

yum install mock

Installing our anku repositories for mock

Now a “must”:

The creator of hiawatha requires the use of a cmake version newer, not offered, by CentOS-5 nor CentOS-6, therefore I had to build a cmake rpm for a newer version, version 2.8.4 has been uploaded to our CentOS repositories (http://anku.ecualinux.com) we call those repos: anku (anku means flexible in Quechua Language). You have to add a “new” repository to your mock installation.

To do so, please download the following files into: your /etc/mock directory (as root):

wget http://www.ecualinux.com/anku-5-i386.cfg -O /etc/mock/anku-5-i386.cfg
wget http://www.ecualinux.com/anku-6-i386.cfg -O /etc/mock/anku-6-i386.cfg
wget http://www.ecualinux.com/anku-5-x86_64.cfg -O /etc/mock/anku-5-x86_64.cfg
wget http://www.ecualinux.com/anku-6-x86_64.cfg -O /etc/mock/anku-6-x86_64.cfg
wget http://www.ecualinux.com/anku-7-x86_64.cfg -O /etc/mock/anku-7-x86_64.cfg

Doing this is a must!!! Otherwise the compilation will fail with cmake errors.

Actually all the anku-*.cfg’s files are the very same epel-*cfg ones but with a new repository added (the anku one near the end of each file)

Creating a mock user:

Then created a user to work with mock, for this user to be able to work it must be in the “mock” group.

useradd eperez
passwd eperez

I then added eperez to the mock group by editing /etc/group. Check this line at the bottom of your /etc/group file containing my username as part of the mock group:

[eperez@mock ~]$ egrep mock /etc/group
mock:x:492:eperez

Good. Then login as your mock user, in my case eperez, all the steps from now on will be made as user eperez, as my mock user

Download the latest hiawatha from there, for example, the latest hiawatha webserver package as of today is 9.12, lets download it:

wget --no-check-certificate https://www.hiawatha-webserver.org/files/hiawatha-9.12.tar.gz

(ok, versions will continue rolling after a few months or years, allways look for the latest hiawatha*tar.gz in the hiawatha webserver’s site)

Now I must get a working hiawatha.spec file, I simply take advantage of a previous hiawatha SRC.RPM from my repos. I store all of them in here: http://anku.ecualinux.com/6/SRPMS/

I then download the latest src.rpm. In this example I will:

  • Download the most up to date hiawatha src.rpm from my repo: http://anku.ecualinux.com/6/SRPMS/hiawatha-9.8-ecualinux.2.el6.src.rpm as of today
  • Open it (with rpm -Uvh)
  • Copy the newest tar.gz I downloaded previously
  • Slightly modify the resulting hiawatha.spec to look for this new version (9.12 in this example)

Here are the steps:

wget http://anku.ecualinux.com/6/SRPMS/hiawatha-9.8-ecualinux.2.el6.src.rpm
rpm -Uvh hiawatha-9.8-ecualinux.2.el6.src.rpm
mv hiawatha-9.12.tar.gz rpmbuild/SOURCES/
vi rpmbuild/SPECS/hiawatha.spec

Ok, the last line.. this is the spec file for the previous version, 9.8 in this example. You may notice it by looking into the very first lines of hiawatha.spec you will see the version (realver) as 9.8, as Im about to compile version 9.12 I change it to look like this:

%define realver  9.12

Well, well… it is time to create an src.rpm for mock to later compile it for all the CentOS versions (5 and 6 as for the moment). I will create a CentOS-5 src.rpm because CentOS-5 can not easily read CentOS-6’s rpm but the opposite is possible: CentOS-6 can open and work with CentOS-5’s rpms.

mock -r anku-5-i386 --buildsrpm --spec rpmbuild/SPECS/hiawatha.spec --sources rpmbuild/SOURCES/

Good.. after a while I have a resulting hiawatha*src.rpm inside: /var/lib/mock/epel-5-i386/result/, lets move it away from there otherwise it can be deleted the next time we invoke mock for this version and arch:

mv /var/lib/mock/epel-5-i386/result/hiawatha-9.12*.src.rpm .

Now the easiest part of all: let’s recompile this newly obtained hiawatha-9.12*.src.rpm for all current CentOS versions (5 and 6) and architectures (i386 and x86_64):

mock -r anku-6-i386 hiawatha-9.12*.src.rpm
mock -r anku-6-x86_64 hiawatha-9.12*.src.rpm
mock -r anku-5-i386 hiawatha-9.12*.src.rpm
mock -r anku-5-x86_64 hiawatha-9.12*.src.rpm

Here is the trick, anku, our repo, remember it? The files I asked you to download into /etc/mock at the beginning of this post? great!.

The results will be stored in:

/var/lib/mock/anku-6-i386/result/
/var/lib/mock/anku-6-x86_64/result/
/var/lib/mock/anku-5-i386/result/
/var/lib/mock/anku-5-x86_64/result/

That’s it! Don’t forget to move the resulting rpms away from the directories stated above as mock delete their contents the next time you try to compile anything using mock for that version and arch.

Final thoughs

What will I do the next time a new hiawatha version comes of? Easy:

  1. Login as user eperez into this server (it is a virtual server with 10GB of HD)
  2. Download the new hiawatha version, for example some day we will have hiawatha-9.13.tar.gz
  3. Move this new tar.gz file to: rpmbuild/SOURCES/
  4. Edit rpmbuild/SPECS/hiawatha.spec and change the version to 9.13
  5. Create a new src.rpm for centos-5
  6. Recompile this src.rpm for all centos versions and arch.

That’s it.

Fedora, Linux, Raspberry Pi

Reduciendo uso de recursos en raspberry pi con pidora, el Fedora para raspberry

1 Comment

Fedora tiene su distribución compilada para raspberry pi, que a la final es un procesador ARM.

Fedora instaló bien, bacán, pero hay ciertas cosas que una vez entrado al sistema te van sobrando. Yo le quiero usar solamente por CLI y por tanto networkmanager, gnome, ni nada de eso me interesa.

Cómo le quité? Pues aquí va un detalle:

primero le configuro la red para que no use NetworkManager, para ello activé el servicio network y desactivé el de NetworkManager:

chkconfig network on

chkconfig NetworkManager off

entonces edité el archivo /etc/sysconfig/network-scripts-ifcfg-eth0 y dentro le dejé configurado así, con la IP que le puse de mi red:

DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
NM_CONTROLLED=no
IPADDR=192.168.1.50
NETMASK=255.255.255.0
GATEWAY=192.168.1.1

Fíjate que está todo bien configurado y que NM_CONTROLLED=no

Aquí tocó reiniciar pues el networkmanager apaga la red, o entrar via línea de comando y arrancar la red.

Luego de reiniciado el equipo, debes tener conectividad, procedemos a apagar servicios y paquetes innecesarios:

yum erase bluez PackageKit polkit

yum grouperase “Office/Productivity” “Sound and Video” “Electronic Lab” “Administration Tools”

Y entonces apago algunos servicios que no me hacen falta:

service sendmail stop
chkconfig sendmail off
service messagebus stop
chkconfig messagebus off

luego reinicio, y el raspberry queda usando unos 18mb de ram. Mira:

Fedora tiene su distribución compilada para raspberry pi, que a la final es un procesador ARM.

Fedora instaló bien, bacán, pero hay ciertas cosas que una vez entrado al sistema te van sobrando. Yo le quiero usar solamente por CLI y por tanto networkmanager, gnome, ni nada de eso me interesa.

Cómo le quité? Pues aquí va un detalle:

primero le configuro la red para que no use NetworkManager, para ello activé el servicio network y desactivé el de NetworkManager:

chkconfig network on

chkconfig NetworkManager off

entonces edité el archivo /etc/sysconfig/network-scripts-ifcfg-eth0 y dentro le dejé configurado así, con la IP que le puse de mi red:

DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
NM_CONTROLLED=no
IPADDR=192.168.1.50
NETMASK=255.255.255.0
GATEWAY=192.168.1.1

Fíjate que está todo bien configurado y que NM_CONTROLLED=no

Aquí tocó reiniciar pues el networkmanager apaga la red, o entrar via línea de comando y arrancar la red.

Luego de reiniciado el equipo, debes tener conectividad, procedemos a apagar servicios y paquetes innecesarios:

yum erase bluez PackageKit polkit

yum grouperase “Office/Productivity” “Sound and Video” “Electronic Lab” “Administration Tools”

Y entonces apago algunos servicios que no me hacen falta:

service sendmail stop
chkconfig sendmail off
service messagebus stop
chkconfig messagebus off

luego reinicio, y el raspberry queda usando unos 18mb de ram. Mira:

 [root@raspi ~]# free -m
total       used       free     shared    buffers     cached
Mem:           436         58        377          0          8         31
-/+ buffers/cache:         18        417
Swap:            0          0          0