microcode: CPU0 update to revision 0xba failed

No se si os habéis fijado que este error sale de vez en cuando al actualizar servidores virtuales.

Microcode es el firmware del procesador, se puede actualizar a través de la BIOS o a través del Kernel de Linux (Yum o Dandified Yum lo hace solo). Al ser un servidor virtual este proceso obviamente falla. Y, no os preocupéis, no influye para nada la instalación de actualizaciones.
Para que no se instale Microcode del procesador, se tiene que eliminar un paquete:

su -c “yum remove -y microcode_ctl”

Sustituir yum por dnf en Fedora.

MBR

” Un registro de arranque principal, conocido también como registro de arranque maestro (por su nombre en inglés master boot record, MBR) es el primer sector (“sector cero”) de un dispositivo de almacenamiento de datos, como un disco duro. A veces, se emplea para el arranque del sistema operativo con bootstrap, otras veces es usado para almacenar una tabla de particiones y, en ocasiones, se usa sólo para identificar un dispositivo de disco individual, aunque en algunas máquinas esto último no se usa y es ignorado. […]

Definición actualizada:

Es el primer sector (“sector cero”) de un dispositivo de almacenamiento de datos, como un disco duro. En Windows y OS X se emplea siempre y en Linux y BSD por defecto para el arranque del sistema operativo con bootstrap (una parte del cargador de arranque está en el MBR y otra parte en una partición aparte, puesto que el tamaño del cargador de arranque es mas grande que el tamaño de MBR). También es usado para almacenar la tabla de particiones de dicho disco duro.

AUR en Fedora

Github Yaourt README

Lo primero es ejecutar esto, lo podéis copiar a un script (está “script ready”):

sudo dnf config-manager --add-repo=http://repo.fdzh.org/FZUG/FZUG.repo
sudo dnf install yaourt
sudo mkdir /opt/arch/
sudo cat << EOF > /etc/pacman.conf
# /etc/pacman.conf
# See the pacman.conf(5) manpage for option and repository directives

[options]
# The following paths are commented out with their default values listed.
# If you wish to use different paths, uncomment and update the paths.
RootDir     = /opt/arch/
DBPath      = /var/lib/pacman/
#CacheDir    = /var/cache/pacman/pkg/
LogFile     = /var/log/pacman.log
#GPGDir      = /etc/pacman.d/gnupg/
HoldPkg     = pacman glibc
#XferCommand = /usr/bin/curl -C - -f %u > %o
#XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u
#CleanMethod = KeepInstalled
#UseDelta    = 0.7
Architecture = auto

# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup
#IgnorePkg   =
#IgnoreGroup =

#NoUpgrade   =
#NoExtract   =

# Misc options
#UseSyslog
#Color
#TotalDownload
CheckSpace
#VerbosePkgLists

# PGP signature checking
#SigLevel = Optional
#LocalFileSigLevel = Optional
#RemoteFileSigLevel = Optional

[core]
SigLevel = Never
Include = /etc/pacman.d/mirrorlist

[community]
SigLevel = Never
Include = /etc/pacman.d/mirrorlist

[multilib]
SigLevel = Never
Include = /etc/pacman.d/mirrorlist

[extra]
SigLevel = Never
Include = /etc/pacman.d/mirrorlist
EOF 
sudo pacman-key --init

Sigue leyendo

SELinux y Fedora

Estoy en un dilema. Necesito cambiar los permisos de SELinux de una carpeta, para hacerlo necesito del comando “semanage” que es provisto por el paquete policycoreutils-python. Mi opinión es que:

“En una distribución Linux con SELinux, debería traer instalado por defecto policycoreutils-python.”

En Fedora 22 stock, sin ningún repositorio añadido, ni activado el repositorio “updates-testing” viene policycoreutils-python-2.3-16 el cual necesita de audit-libs-python >= 2.1.3-4. En el repositorio “fedora” viene la versión 2.4.2.

audit-libs-python-2.4.2 necesita audit-libs = 2.4.2-1, pero la versión que está instalada es 2.4.3.

La buena noticia es que la versión 2.4.2-1 está en el repositorio “updates-testing” (curioso como aparece una actualización que desactualiza un paquete), la mala noticia es que la versión 2.4.3 no se puede desinstalar porque audit-2.4.3 necesita de audit-libs-2.4.3.

En resumen, en Fedora 22 no se puede utiliza SELinux.

Hoy es uno de esos días en los que no me sale nada de lo que me proponga.

Cifrar Swap

Todos sabemos que la memoria Swap es un peligro para la privacidad, pues puede contener almacenadas credenciales de páginas web, contraseñas, etc. Hasta leer un artículo sobre la adición del soporte de Cifrado de Swap a DragonflyBSD, no tenía ni idea de que eso existía. Tras ponerme a investigar un poquito, descubrí que también existe en Linux.

¿Cómo cifrar nuestra partición/ archivo swap actual?

  1. Instalar “cryptsetup” si todavía no lo tenemos instalado
  2. Desactivar swap con “$ sudo swapoff -a”
  3. Abrir /etc/fstab
  4. Comprobar que el PATH de swap sea /dev/mapper/fedora-swap
  5. Sobreescribir todos los posibles datos que pueda haber en nuestra swap con “$ sudo dd if=/dev/zero bs=1024000 of=/dev/mapper/fedora-swap“. Este paso es por precaución.

Sigue leyendo

Fuck Beaglebone, fuck Odroid, fuck Raspberry Pi

¡Increíble! Un ordenador ARM a 1 GHz con 4GB de NAND Flash, 512MB de RAM, salida de audio y video, entrada de micrófono, puerto USB, microUSB host, Wifi B/G/N y Bluetooth y todo eso por sólo 9USD, y, si me he enterado bien, envío internacional gratuito. ¡Gente, que son solo 7.99€!. Brutal.


Más información en: Campaña Kickstarter

WordPress exploit en Twenty Fifteen

Se ha descubierto una vulnerabilidad en la plantilla por defecto de WordPress 4.2.1, Twenty Fifteen. Tener instalada la plantilla basta para ser vulnerable. De hecho, es una medida de seguridad recomendada desinstalar todos los plugins y plantillas que no se usen.

Las buenas noticias es que WordPress ya ha sacado un parche mediante una actualización a WordPress 4.2.2. Si por alguna extraña razón no podéis actualizar (enfatizo EXTRAÑA), podéis remover la plantilla o si la estáis utilizando, hay que remover el archivo “wp-content/themes/twentyfifteen/genericons/example.html” y listo.

¿Qué hace el exploit?

Sigue leyendo