Definamos Normal.

El Blog personal de Rafael Rojas

Author: admin (page 3 of 10)

iproute2, la sustitución completa de ifconfig

Durante años en Arch administrábamos las interfaces de red con los comandos: ifconfig, iwconfig, netstat, route, etc.

Todo estos programas separados se encuentran dentro del meta-paquete net-tools en ArchLinux, el detalle es que desde el 2011 estas herramientas estaban depreciadas remplazadas por las utilerias iproute2.

Ahora, el comando ip ha estado ahi durante mucho tiempo, pero no era usado por usar el mas tradicional ipconfig, hasta hace poco el paquete ipconfig seguia siendo el paquete oficial para el manejo de interfaces de red, pero eso cambio y ahora es /usr/sbin/ip (sin embargo el paquete net-tools aun se encuentra disponible en los repos de ArchLinux).

Que herramientas remplaza iproute?

Estas, a grandes razgos, son las herramientas que iproute2 remplaza.

Funcion Herramienta en “net-tools” iproute2
Configuracion de red y enlace ifconfig ip addr, ip link
Tablas de ruteo route ip route
Neighbors arp ip neigh
VLAN vconfig ip link
Tuneles iptunnel ip tunnel
Multicast ipmaddr ip maddr
Estadisticas netstat ss

La intencion de iproute2 es unificar la sintaxis de varias de estas herramientas

ifconfig vs ip

Mostrar dispositivos de red y su configuración

ifconfig
ifconfig -a

ip
ip addr show
ip link show

Habilitar una interfaz de red

ifconfig
ifconfig eth0 up

ip
ip link set eth0 up

Deshabilitar una interfaz de red

ifconfig
ifconfig eth0 down

ip
ip link set eth0 down

Asignar una dirección IP

ifconfig
ifconfig eth0 192.168.0.77

ip
ip address add 192.168.0.77 dev eth0

El mismo comando con mascara de red y direccion de difusion

ifconfig
ifconfig eth0 192.168.0.77 netmask 255.255.255.0 broadcast 192.168.0.255

ip
ip addr add 192.168.0.77/24 broadcast 192.168.1.255 dev eth0

Borrar una direccion IP

Esto solo posible con ip:

ip addr del 192.168.0.77/24 dev eth0

Agregar interfaces alias

ifconfig
ifconfig eth0:1 10.0.0.1/8

ip
ip addr add 10.0.0.1/8 dev eth0 label eth0:1

Protocolo ARP

Agregar una entrada a la tabla ARP

arp -i eth0 -s 192.168.0.1 00:11:22:33:44:55

ip
ip neigh add 192.168.0.1 lladdr 00:11:22:33:44:55 nud permanent dev eth0

Apagar resolucion ARP en un dispositivo

ifconfig
ifconfig -arp eth0

ip
ip link set dev eth0 arp off

Algunas fuentes para extenderse ams en el tema:

http://en.wikipedia.org/wiki/Iproute2
https://bbs.archlinux.org/viewtopic.php?id=120872
http://whodat.be/iproute2-cheatsheet-and-reference-guide/
http://linux-ip.net/html/tools-ip-management.html
http://www.tty1.net/blog/2010-04-21-ifconfig-ip-comparison_en.html
http://linux-ip.net/html/tools-ip-management.html

Oye Systemd, devuelveme los nombres de mis interfaces de red!

Desde la edición 197 de Systemd, este se encargo de la maravillosa tarea de renombrar nuestras interfaces de red, siguiendo una clara política establecida en FreeDesktop.org que establece los siguientes parametros para nombrar interfaces de red:

With systemd 197 we have added native support for a number of different naming policies into systemd/udevd proper and made a scheme similar to biosdevname’s (but generally more powerful, and closer to kernel-internal device identification schemes) the default. The following different naming schemes for network interfaces are now supported by udev natively:

  • Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
  • Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
  • Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
  • Names incorporating the interfaces’s MAC address (example: enx78e7d1ea46da)
  • Classic, unpredictable kernel-native ethX naming (example: eth0)

Esto es que Udev (ya integrado en systemd) nombrara las interfaces de red bajo la política de:

Primero por el numero de serie establecido en el Firmware/BIOS (eno1)
De no ser posible por el numero del slot de conexión de la interfaz proveído por el Firmware/BIOS (ens1)
Si no, por la localización geográfica del conector (enp2s0)
O incorporando la MAC address al nombre de la interfaz (en mi opinión, el mas útil: enx78e7d1ea46da).
Finalmentepor el nombramiento clásico estándar del kernel (eth0)

Este cambio es meramente opcional si es que actualizas de una versión anterior de systemd, pero si has instalado ArchLinux en los últimos 4 meses, así sera el nombramiento de las interfaces.

Selección_007

Pero, que tal si no quiero batallar con los nombres de las interfaces de red todavia?
Simple: eliminamos la regla de udev que las nombra así, con un comando tan simple como:

ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

(o borrando directamente el archivo también).

A la hora de reiniciar el sistema el nombre canónico que el kernel le pone a las interfaces de red ha vuelto, solo falta otro ip link show para verificar:

Selección_008

En base a la depreciación de inet-tools, mucha gente no conoce muy bien el uso de ip link, mañana un post al respecto.

PD. Esto aplica para toda distro con systemd 197 o superior (Fedora, OpenSuSe, etc)

prescindir de la imagen fallback de ArchLinux

initgrub

Arch utiliza por default 2 imágenes del kernel /boot/initramfs-linux.img y /boot/initramfs-linux-fallback.img La diferencia entre estas es que la imagen fallback tiene deshabilitado el hook autodetect cuya función es agregar al initramfs la lista de módulos utilizados por el hardware del equipo a través de un escaneo con sysfs.

La imagen fallback tiene este modulo deshabilitado por si bajo alguna actualización del sistema hay algún modulo causando conflicto podamos iniciar con esta imagen, cargar los modulos manualmente y deshabilitar o reparar el modulo conflictivo  Cabe aclarar que ambas imágenes están hechas con la misma versión del kernel.

Mi cuestión es: corro arch sobre una laptop que no tiene cambios de hardware y que no le hago grandes cambios a los módulos del kernel, realmente necesito esta imagen fallback?

Y como honestamente no la necesito pues la puedo deshabilitar.

Editamos el archivo de pre configuraciones del kernel:

vi /etc/mkinitcpio.d/linux.preset

Un interesante archivo con contenido como este:

# mkinitcpio preset file for the 'linux' package
 
ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-linux-ck"
 
PRESETS=('default' 'fallback')
 
#default_config="/etc/mkinitcpio.conf"
default_image="/boot/initramfs-linux-ck.img"
#default_options=""
 
#fallback_config="/etc/mkinitcpio.conf"
fallback_image="/boot/initramfs-linux-ck-fallback.img"
fallback_options="-S autodetect"

Editamos los presets quitando ‘fallback’y comentamos las lineas fallback_image y fallback_options quedando asi:

PRESETS=('default')
 
#default_config="/etc/mkinitcpio.conf"
default_image="/boot/initramfs-linux-ck.img"
#default_options=""
 
#fallback_config="/etc/mkinitcpio.conf"
#fallback_image="/boot/initramfs-linux-ck-fallback.img"
#fallback_options="-S autodetect"

Luego recreamos la imagen del kernel:

mkinitcpio -p linux

EDIT 14-abril

Tambien ahy que eliminiar la vieja imagen fallback manualmente:

rm /boot/initramfs-linux-fallback.img

Actualizamos el grub:

grub-mkconfig -o /boot/grub/grub.cfg

Y listo, ya no hay imagen fallback, si queremos regresar los cambios devovlemos el archivo /etc/mkinitcpio.d/linux.preset a su estado original, recreamos las imagenes de arranque y actualizamos el grub, tambien es interesante que en ese archivo podemos configurar personalizaciones de la imagen de arranque con nuestros propios hooks, pero eso sera otra cosa.

Hacer que el grub recuerde el ultimo sistema operativo que inicio

Hay algunas versiones de Linux que tienen el grub configurado para que este recuerde el ultimo sistema operativo con que se inicio y lo tenga seleccionado como default. Esto es muy útil cuando usas un equipo con múltiples sistemas operativos (Windows y/o Linux) y andas reiniciando entre ellos.

Hay dos opciones que vamos a tomar de la documentación oficial del grub (no la wiki de Arch): GRUB_DEFAULT y GRUB_SAVEDEFAULT:

‘GRUB_DEFAULT’
……………..
If you set this to ‘saved’, then the default menu entry will be that saved by ‘GRUB_SAVEDEFAULT’, grub-set-default, or grub-reboot.

‘GRUB_SAVEDEFAULT’

If this option is set to ‘true’, then, when an entry is selected, save it as a new default entry for use by future runs of GRUB. This is only useful if ‘GRUB_DEFAULT=saved’; it is a separate option because ‘GRUB_DEFAULT=saved’ is useful without this option, in conjunction with grub-set-default or grub-reboot. Unset by default. This option relies on the environment block, which may not be available in all situations (see Environment block).

Ok, para hacer esto en nuestro ArchLinux, o en cualquier distro con grub2 ya que los archivos son estándar, hay que editar el archivo /etc/default/grub y

Editar esta linea asi (el default es cero):

GRUB_DEFAULT=saved

Y descomentar esta otra:

GRUB_SAVEDEFAULT=true

Por ultimo editamos el archivo /etc/grub.d/40_custom y agregamos al final la opción:

savedefault

Al final actualizamos el grub

grub-mkconfig -o /boot/grub/grub.cfg

Y listo.

Si por ejemplo tienen ArchLinux y Windows, reinician el equipo con Windows, y al reiniciar de nuevo Windows sera la opción default hasta que inicien con Arch 😀

La mejor guia de instalacion de Arch Linux que puedas encontrar!

He borrado la pagina con la guía de instalación de Arch Linux que tenia posteada en este blog. Bajo la premisa que la información en los blogs caduca, pues decidi dejar de actualizarla y de repetir la información que alguien mas ya ha documentado.

Pero honestamente con la intención de ayudar a los usuarios en sus nuevas instalaciones y configuraciones, les dejare una liga a la mejor guía de instalación de Arch Linux que puedan encontrar en la web. Solo den clic en la imagen:

Arch-Linux

Y recuerde: no acepte imitaciones!

Una pequeña reflexion.

Imagina que eres el CEO de una compañía ensambladora de PCs, puede ser HP, Dell, Acer, etc. La que sea.

Ahora imagina este escenario:

Por años le encargabas el sistema operativo al mismo fabricante, porque la gente no conocía mas y no quería conocer mas en una época en que utilizar cualquier otra opción era muy difícil o muy caro, los últimos 30 años fue así.

Pero las cosas con este fabricante de software se han amargado un poco:

  • Ahora te exige a implementar un remplazo al BIOS, no te puede forzar a tenerlo como única opción sino te pide tráelo habilitado por default.
  • El, el que te vende el sistema operativo, te dice a ti fabricante como DEBES armar tus productos, si no cumples SUS requerimientos no te va a vender su software.
  • Aprovecha de ser el fabricante del software y crea hardware en donde ese sistema corre perfecto, entra a tu mercado sin siquiera avisarte, poco antes de la fecha oficial de venta de su producto, el se puede adelantar, tu no.
  • La adpocion de su nuevo producto, un sistema operativo esta por los suelos, principalmente por que al cliente no le gusta. El fabricante de software te culpa a ti fabricante de PCs, del fracaso de su producto.

Tu como fabricante de PCs no la tienes muy fácil tampoco.

  • Tus ventas han sido las mas bajas en los últimos 5 años.
  • Analisis dicen que las ventas de PCs de todos los fabricantes irán a la baja constante, lento pero sin parar.
  • Intel avisa que ya no hará motherboards para PC, otros fabricantes se preparan para un anuncio parecido.
  • Hay un fabricante que te esta comiendo el mercado, parece que no hiciera nada mal por que todo se vente, y sus productos son 3 veces mas caros que los tuyos.

Sin embargo vez nuevos fenómenos:

  • Los usuarios ahora son mas adeptos a probar nuevas tecnologías, ya utilizan Android, iOS, Ubuntu indiferentemente. Poco queda del usuario de hace 20 años en donde si no tenia el menú de inicio de windows, poco podía hacer, ahora sus hijos dominan diferentes plataformas.
  • Tus compradores manifiestan su abiurrimiento de la PC y el sistema tradicional.
  • La mayoría de las herramientas ya son web o multi plataforma, quedan algunas herramientas corporativas, pero muchas de ellas ya están en diseño o desarrollo para plataforma web o otros sistemas operativos.
  • Hay otros proveedores de sistemas operativos, mas baratos o incluso libres, disṕuestos a trabajar contigo, a llegar a un trato beneficioso para ambos.

Tu viejo proveedor es hostil contigo, tu mercado se hunde, los usuarios son mas abiertos a probar otras plataformas, los fabricantes de programas ya están portando sus productos o están en planes de hacerlo. ¿Que te hace falta para cambiar?

¿por que dejar que Microsoft te diga como hacer las cosas? ya no es 1995!
¿por que hundirse con el “concepto tradicional de PC”? el concepto esta cambiando, si como fabricante cambias: sobrevives.
¿por que fabricar PCs que no se venden, cargadas con un sistema operativo que no muchos quieren casado con una compañía que es sinónimo de anticuado?

El éxito de Apple no es por Steve Jobs, ni por el iPod/iPhone. Es por que siempre tomo las riendas de sus propias decisiones, no dejo que nadie le dictara que hacer ni como hacerlo, a ti como fabricante Microsoft te regaña si te atreves a hacer algo diferente.
A mi personalmente me daría vergüenza seguir ordenes de la compañía dirigida por Steve Ballmer, el geni detras de Zune, Windows Phone o Silverlight.

Si te dicen que estas condenado a la extinción, por que no arriesgarse y cambiar?

 

Nada, solo una pequeña reflexión.

Vota por tus paquetes favoritos de AUR

Hay una forma de que los paquetes del repositorio de usuarios de ArchLinux pasen al repositorio [community] y puedan ser instalados con un simple pacman -S sin necesidad de que sean compilados desde codigo fuente, esta forma simple es: votando por ellos.

Segun la wiki de Arch los requisitos para que estos paquetes pasen al repositorio [community] son:

Al menos, 10 votos para que algo se mueva al repositorio [community]. o
Que un usuario de confianza (Trusted User, TU en ingles) adopte y mantenga dicho paquete.

Si un paquete tiene suficientes votos para ser considerado para [community], se considerara tomar al usuario creador del PKGBUILD para incluirlo como usuario de confianza y se le asignara la responsabilidad de actualizar dicho paquete.

Y quien puede votar por estos PKGBUILDs?

Basicamente cualquiera que se haga de una cuenta de usuario dentro de archlinux.org

Con esa cuenta creada (que también sirve para acceder a los foros oficiales de ArchLinux y para ayudar a editar y actualizar su wiki) solo falta instalar el paquete aurvote desde AUR:

yaourt -S aurvote

Y luego corremos la configuración de aurvote:

aurvote --configure

Que nos pide información de nuestra cuenta y pregunta si queremos un login persistente y donde guardar la cookie de AUR:

kmix2

Y listo, ya podemos votar por nuestros paquetes favoritos, por ejemplo yo pienso que el paquete de fonts oxygen ya esta suficientemente maduro:

kmix3

Espero que si incluyan un paquete precompilado.

Quien dijo que ArchLinux no tomaba en cuenta a sus usuarios?

Protip: afinar el control de volumen en kmix

Kmix es la herramienta de control de audio de KDE, controla las entradas y salidas de audio y trabaja con pulseaudio para manejar perfectamente los dispositivos de audio.

kmix

Funciona bien, solo hay un detalle: cuando subía o bajaba el audio desde el teclado, kmix daba grandes saltos (del 20%) haciendo que modificar un poco el volumen fuera o muy alto o muy bajo, y eso pues es exasperante….

Pero se puede solucionar

Solo basta editar el archivo kmixrc y agregar una linea:

abrimos el archivo:

vi $HOME/.kde4/share/config/kmixrc

En algunas distros el directorio de configuración de usuario es .kde, en archlinux es .kde4

Y justo debajo de la sección [global] agregar: VolumePercentageStep= con el porcentaje de cambio de volumen, el mio quedo así:

kmix1

El cambio queda del 1.5% y no del 20% como era antes, mucho mejor para mi y mi laptop 😀

Por ultimo solo queda reiniciar kmix para que queden los cambios:

pkill kmix && kmix &

Mi volumen ya no queda como alto-medio-bajo. Saludos!

Distro vs Fork: lo que nunca debe suceder.

Esta entrada me interesa, sobre todo por que es un claro ejemplo de como una comunidad NO se debe comportar.

Allan McRae es uno de los principales developers y mantenedores de ArchLinux, para darle contexto es el que mantiene pacman, glibc, gcc, makepkg y otras herramientas del repositorio core de ArchLinux. Allan un dia en su blog personal (cabe aclarar que es su sitio personal y no un lugar oficial de ArchLinux) escribió una comparativa de los forks (o derivaciones) de ArchLinux

Para no hacer el cuento largo: a la mayoría de los forks les fue mal, con observaciones de Allan de que no entendia porque separaban los repositorios o porque manejaban de cierta forma las actualizaciones. La única que medio salio librada fue Chakra, sobre todo por que esta, a pesar de usar las herramientas de ArchLinux recompila sus paquetes y administra sus actualizaciones.

——————Hasta aqui todo bien ————————————————–

Fuera que unos días después el mismo Allan se clava/especifica en un fork en particular: manjaro.

Con el titulo: “Manjaro Linux: Ignoring Security For Stability” (Manjaro Linux: ignorando seguridad por estabilidad), señala varios puntos que no logra entenderla administración de paquetes de manjaro ya que esta actualiza sus repositorios desde core o extra a diario, pero en vez de moverlos a sus repos estables los mueve a su propio repo de testing, sin razon aparente los deja ahi una semana y luego los libera a sus repositorios, divididos en su propia organización, también sin supuesta explicación alguna: los puntos de McRae fueron:

Porque moverlos a testing, si en realidad no hacen muchas pruebas con los paquetes en base a que tienen solo 3 mantenedores para testear y mantener lo que va a su repositorio core?
El mantener tanto los paquetes puede causar problemas de seguridad por que una distro rolling release puede sacar parches al dia de un paquete, en una semana pueden haber varias revisiones de seguridad de un paquete, y estas actualizaciones no les llega a los usuarios de manjaro mas que semanalmente, de ejemplo utilizo el paquete de Firefox (algo interesante) cuyas vulnerabilidades de la ultima semana fueron abatidas al paso.

Y hasta ahi. Una critica constructiva, basada en ejemplos de aplicación reales y con los puntos bien aclarados del porque esto puede ser una mala idea, Allan McRae se descargo de manjaro, cabe aclarar como termino ese dichoso post:

In the end, I think the idea behind Manjaro – rolling release at a more relaxed pace – can be achieved. I am not entirely familiar with these distributions, but I guess that is exactly what apotsid and LMDE achieve. And they start form Debian Unstable, which is reportedly far more of a minefield than Arch Linux.

Traducción: al final de todo esto, si creo que la idea detrás de Manjaro es plausible.

Reaccionaron bien los developers oficiales de manjaro o los miembros de su comunidad? no, para nada.

Primero revisar los primeros 5 comentarios de su post en su blog personal, uno de ellos por uno de los mantenedores de manjaro 😀
Seguido de varios temas en los foros de manjaro hablando de una supuesta guerra Arch vs Manjaro (cosa que no existió).
Y por ultimo como Allan menciona: el mover paquetes intespestivamente en base a su critica.

Ahora le toco a Allan ser reactivo, al dia siguiente postea otra nota haciendo una dura critica al hecho de que manjaro haya publicado en estable un paquete de idiomas de firefox que tenia un bug reportado señalando de sobremanera que este tipo de administracion de paquetes puede traer en un futuro problemas de seguridad para los usuarios.

Allan tambien se dijo hasta amenazado por la comunidad de manjaro (post borrado) y demas lloriqueos.

La reacción de la comunidad oficial, del sitio oficial de manjaro hacia los posts del blog personal de Allan McRae fue:

I’ve deleted the thread about Allan McRae’s criticism of Manjaro.

En resumen

Fue duro McRae en sus criticas? si lo fue, pero lo hizo basado en argumentos, en vez de declararlo troll y juzgarlo como Manjaro-hater por que no debatir sus argumentos con hechos?
El señor odia a Manjaro? no creo, aclaro que la idea detras del proyecto no es mala para nada.
Se porto como un troll? hizo algo para alimentar este pleito? si lo hizo, es de admitir que lo hizo, aunque es de admitir que lo hizo en su blgo- y espacio personal, hay que decir que fue medio troll
La comunidad de Manjaro es victima? no lo es
Esta comunidad actuo como deberia? No, un par de cometarios en su blog o tal vez una aclaracion en su wiki o ducomentacion hubiera sido suficiente, no seguir el juego ni de MacRae ni de los fanboys de ambas distros.
Necesitan reparar o aclarar los errores señalados? si, cuanto antes mejor.
Deben tomar tan a pecho la opinion de MacRae? tan a pecho no, pero considerarla si, sobre todo por el hecho de que es el mantenedor de muchos de los paquetes basicos de Manjaro, es mas mantenedor de Manjaro que sus 3 administradores de core juntos.

Hay actitudes y comportamientos que destruyen mas que todas las criticas externas y patentes juntas, la comunidad se destruye de adentro hacia afuera no de afuera hacia adentro. Coincido con los puntos del primer post del Sr McRae: la administracion de paquetes es confusa pero no coincido y repruebo su forma de afrontar el problema con los de Manjaro. Coincido en que la comunida de manjaro tiene derecho a administrar su fork como se le de la gana, pero no coincido que se vuelvan tan infantiles ante una critica: criticas van a tener, y si quieren llegar a algun lado deben saber afrontarlas (eso o empezar a mantener sus propios paquetes y poder prescindir de las criticas de McRae).

Muy mal para ambas partes

Why it Sucks Being the IT Guy

Una infografia, algo de humor, pero es tan cierto que duele!


/* Infographic: Why it Sucks Being the IT Guy */



Older posts Newer posts

© 2019 Definamos Normal.

Theme by Anders NorenUp ↑