Device not managed by NetworkManager

Luego de haber instalado CentOS 6 (con entorno gráfico), al asignar ip estática y reiniciar el servicio de red me topaba con esto.

root@ ~]# service network restart
Error: Connection activation failed: Device not managed by NetworkManager

Googleando se puede llegar a la conclusión que.. NetworkManager sucks, asi de simple. Hacía conflicto con la configuración que hice, asi que:

root@ ~]# vim /etc/sysconfig/network-scripts/ifcfg-eth0 

y cambie el "yes" por "no", quedando así

DEVICE=eth0
BOOTPROTO=none
HWADDR=00:0d:87:51:38:dc
ONBOOT=yes
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
IPADDR=192.168.1.7
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=yes
NM_CONTROLLED="no"

Guardamos y reiniciamos el servicio de red.

root@ ~]# service network restart

Y eso es todo. Ah!, y algo más, deshabilitenlo - y haganlo si no quieren seguir odiando aún más a NetworkManager - para que no arranque con el sistema.

root@ ~]# chkconfig NetworkManager off

Suertes.

squid dead but pid file exists

Este se me presento justo el día de hoy, uso un proxy virtualizado para tener caché en la lan y luego de ver que no podía navegar y el linux si tenía salida a internet tuve que ver que pasaba - definivitamente - con el proxy.

[root@gateway run]# service squid status 


squid dead but pid file exists

[root@gateway run]# service squid restart

Stopping squid:                                            [FAILED]

Starting squid:                                            [  OK  ]

Googleando encontré alguna pista. La última vez que estuvo funcionando correctamente, había dejado descargando un archivo iso, la cual había dejado casi lleno en su totalidad el disco.

Esto es un error trivial, simple, pero afecta a squid porque no puede escribir en el cache, eliminando algunos archivos de la cache arrancó de nuevo squid. 

scp: command not found

Tratando de enviar un par de archivos de un linux a otro, cuando un mensaje salvaje apareció:


[root@host1 ~]# scp -r root@192.168.1.102:/root /usr/share/carpetita
root@192.168.1.102's password:
bash: scp: command not found

Si es que te llegas a topar con esto, básicamente después de una instalación, por cualquiera de los motivos no podrás porque te falta el siguiente paquete.


[root@host2 ~]# yum install openssh-clients

Obviamente que era en el linux de destino, una vez instalado y todo resuelto.

Unable to load SELinux Policy.

Estaba instalando un test server virtualizado - un CentOS - cuando de casualidad me topé con este error. Después de instalado, a la hora de botear, me arrojaba un kernel panic

Unable to load SELinux Policy. Machine is in enforcing mode.  Halting now.
Kernel panic - not syncing: Attempted to kill init!

Luego de googlear encontré algo que me serviría. Para solucionar esto hacemos lo siguiente.

Reiniciamos la máquina y en la consola del grub seleccionamos el kernel a arrancar - sí es que un fresh install no es tu caso -  y presionamos 'e' para editar la línea de arranque.

Al final de la línea agregamos "enforcing=0", que debería verse masomenos así :

grub edit> kernel /boot/vmlinuz-2.6.18-194.el5 ro root=LABEL=/ enforcing=0

Presionamos enter y luego 'b' para bootear con esos parámetros, y listo, linux arrancando :)

También podríamos agregar este parámetro en /boot/grub/grub.conf  - o /etc/grub.conf según tu distro - al final de la misma líneal kernel a arrancar.

PS: Para que no volvamos a presentar el mismo problema se debe setear SELinux en modo permisivo o desahabilitado.

[root@ ~]# system-config-securitylevel-tui

Seleccionamos 'security level: disabled' y 'SELinux: disabled'.