Cómo sortear el "bug" de Amazon basado en las AMIs de RHEL 6.4.

Las AMIs de Amazon para RHEL 6.4, traen consigo un bug, dicho bug pertenece a la aplicación cloud-init y una mala configuración del rc.local.

El bug se basa en lo siguiente, al iniciar una ami, basada en una que has creado, esta no se inicia correctamente, por que se han añadido en el fichero sshd_config, 2 líneas de forma errónea, estas líneas son:

UseDNS no

PermitRootLogin without-password

Que debido al error, aparecen almacenadas de la siguiente forma:

UseDNS no

PermitRootLogin without-passwordUseDNS no

Esto provoca que la máquina no se levante correctamente. Si te pasa esto y necesitas acceder a esa máquina, la solución es que conectes el volumen de la máquina que falla, como secundario en otra máquina que si se inicie, una vez conectado el volumen, accedes a él desde la máquina y modifica el sshd_config para eliminar las líneas extrañas.

#vi /etc/ssh/sshd_config

Una vez modificado, vuelves a adjuntar el volumen a tu máquina y se debería conectar correctamente.

Para solucionarlo definitivamente, has de eliminar las siguientes líneas del fichero /etc/rc.local :

cat <> /etc/ssh/sshd_config
UseDNS no
PermitRootLogin without-password

Por supuesto, cuando modifiquéis las líneas del sshd_config, reiniciar el servicio de ssh.

Vamos ahora al segundo bug, levantas tu ami, que sabes que tiene un usuario creado, intentas acceder a ella y te dice que “acceso denegado”, lo intentas con los certificados de Amazon y te deja perfectamente.

Tu estás completamente seguro, que antes de crear la ami, podías acceder con un usuario que has creado, ¿por qué ahora no puedes acceder?

Fácil y sencillo, simplemente por que el “cloud-init” ha modificado por ti la variable “PasswordAuthentication” y le ha puesto un no.

La solución rápida, entrar con el certificado, cambiar la opción a yes y reiniciar el servicio ssh.

La solución definitiva, editar el fichero /etc/cloud/cloud.cfg

y cambiar la variable “ssh_pwauth:” a 1, ya que por defecto está a 0.

Y esto es lo que provoca, que cuando levantas una ami basada en RHEL 6.4 no puedas acceder a ella.

Espero que os sirva chicos!!

Configurar Apache como "proxy" de Tomcat.

Actualmente, cuando instalamos un tomcat, queremos ponerle un apache como “proxy”, el apache recibe las peticiones en el puerto 80 y las redirige a tomcat.

Para ello, instalaremos un apache y un tomcat, y haremos sus configuraciones independientes para que funcionen * y como siempre utilizar las guías básicas de bastionado para que sean seguras.

Una vez hecho eso, habilitaremos los siguientes módulos en apache:

proxy_ajp.load

proxy.conf

proxy.load

Para ello, primero revisaremos que no están ya habilitados.

En la ruta /etc/apache2/ tenemos 2 directorios llamados:

mods-available

mods-enabled

En mods-enabled se encuentran los módulos ya habilitados, si no están los nuestros, iremos al directorio mods-available y los habilitaremos, el comando a utilizar es:

a2enmod [nombre_módulo]

Cada vez que lo habilitemos, nos pedirá reiniciar el apache para activarlos, por lo que cuando finalicemos con todos los módulos, reiniciaremos el apache.

Una vez reiniciado, verificamos en mods-enabled que están nuestros módulos.

Ahora pasaremos a la configuración de la “conexión” entre apache y tomcat, para ello, simplemente en el directorio /etc/apache2/sites-available crearemos el fichero del proyecto que necesitemos y le añadiremos la siguiente información:

       ServerName moni.mandarina.com

       ProxyPass /  ajp://localhost:8009/

       ProxyPassReverse / ajp://localhost:8009/

       ErrorLog ${APACHE_LOG_DIR}/monimandarina_error.log

       LogLevel warn

       CustomLog ${APACHE_LOG_DIR}/monimandarina_access.log combined

Hemos creado un vhost con la url a la que debe responder el servicio, con las líneas ProxyPass y ProxyPassReverse, le estamos indicando que “dirija” la información a tomcat.

Haremos un link simbolico desde sites-enabled hacía el vhost que acabamos de crear.

Ahora recargaremos la información del apache

#/etc/init.d/apache2 reload

Si todo está OK y tenemos nuestras configuraciones bien hechas, deberían funcionar correctamente las aplicaciones de tomcat sobre el puerto 80 y a través de Apache.


PD: Estoy aprendiendo a usar Apache, es posible que me falte algo en la configuración, pero juraría que no.

Configurar Sudo con LDAP y PHPLdapAdmin.

Necesitamos permitir, que los usuarios que accedan por LDAP a los clientes, puedan hacer sudo su en las máquinas.

Para ello, hay 2 formas, o agregamos el usuario al fichero /etc/sudoers de cada máquina cliente o lo hacemos a través del LDAP.

Nosotros lo haremos vía LDAP para tenerlo centralizado.

En primer lugar, accederemos al servidor de LDAP y crearemos el “schema” SUDOers para LDAP en la siguiente ruta:

cd /etc/openldap/schema/

#vi sudo.schema

Agregaremos la siguiente información:

######################################################

###Se crea sudo.schema para que sea el LDAP el que ###

###permita hacer sudo en los hosts del LDAP.        ###

######################################################

attributetype ( 1.3.6.1.4.1.15953.9.1.1

 NAME 'sudoUser'

 DESC 'User(s) who may  run sudo'

 EQUALITY caseExactIA5Match

 SUBSTR caseExactIA5SubstringsMatch

 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.15953.9.1.2

 NAME 'sudoHost'

 DESC 'Host(s) who may run sudo'

 EQUALITY caseExactIA5Match

 SUBSTR caseExactIA5SubstringsMatch

 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.15953.9.1.3

 NAME 'sudoCommand'

 DESC 'Command(s) to be executed by sudo'

 EQUALITY caseExactIA5Match

 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.15953.9.1.4

 NAME 'sudoRunAs'

 DESC 'User(s) impersonated by sudo'

 EQUALITY caseExactIA5Match

 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.15953.9.1.5

 NAME 'sudoOption'

 DESC 'Options(s) followed by sudo'

 EQUALITY caseExactIA5Match

 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.15953.9.1.6

 NAME 'sudoRunAsUser'

 DESC 'User(s) impersonated by sudo'

 EQUALITY caseExactIA5Match

 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.15953.9.1.7

 NAME 'sudoRunAsGroup'

 DESC 'Group(s) impersonated by sudo'

 EQUALITY caseExactIA5Match

 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.15953.9.1.8

 NAME 'sudoNotBefore'

 DESC 'Start of time interval for which the entry is valid'

 EQUALITY generalizedTimeMatch

 ORDERING generalizedTimeOrderingMatch

 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

attributetype ( 1.3.6.1.4.1.15953.9.1.9

NAME 'sudoNotAfter'

 DESC 'End of time interval for which the entry is valid'

 EQUALITY generalizedTimeMatch

 ORDERING generalizedTimeOrderingMatch

 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

attributeTypes ( 1.3.6.1.4.1.15953.9.1.10

  NAME 'sudoOrder'

  DESC 'an integer to order the sudoRole entries'

  EQUALITY integerMatch

  ORDERING integerOrderingMatch

  SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top AUXILIARY

 DESC 'Sudoer Entries'

 MUST ( cn )

 MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $ sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAfter $ sudoOrder $ description )

      )

Esta información define el esquema del rol SUDOers, si comenzamos desde arriba, veremos todos los atributos de los que disponemos, las últimas líneas, pertenecen al Objeto SudoRole, si os fijáis he puesto AUXILIARY, si buscáis mas info sobre este esquema, encontraréis que pone ESTRUCTURAL, con ambos funciona, pero si usáis PHPLdapAdmin, os recomiendo que pongáis AUXILIARY, ya que si no, hay posibilidades de que el ROL no aparezca para elegirlo, pero si aparecerá en la estructura.

Una vez guardado el fichero, le indicaremos al LDAP su existencia:

#vi /etc/openldap/slapd.conf

include         /etc/openldap/schema/sudo.schema

Reiniciamos el servicio de LDAP:

#/etc/init.d/ldap restart

Aquí es donde si no tenéis PHPLdapAdmin, tendréis que pasaros a otra guía, ya sabéis que no me gusta subir cosas que no he probado.

Pero sólo podrán hacer “sudo su” los usuarios que se encuentren en el grupo SUDOers del LDAP.

Para ello, abriremos el PHPLdapAdmin y crearemos la OU “SUDOers”, una vez creado, agregaremos un nuevo ObjectClass, este será SudoRole, que con los cambios realizados anteriormente, debería aparecer.

Al agregarlo, nos obligará a identificar un CN, este CN sería el nombre del grupo, por decirlo de algún modo.

Ahora podremos agregar los atributos que necesitamos:

sudoCommand

sudoHost

sudoUser

sudoOption

En sudoCommand, pondremos ALL para poder ejecutar cualquier comando, se pueden poner comandos específicos o ![comando] para denegar la ejecución de un comando específico.

En sudoHost, podemos poner ALL para cualquier PC o la ip o nombre del host.

En sudoUser pondremos los nombres de los usuarios que puedan acceder.

En sudoOption podemos indicar que o hace falta password al hacer “sudo su” con un NOPASSWD.

Ya tenemos finalizada la configuración del servidor, ahora pasemos a la de los clientes.

En el cliente, editamos el siguiente fichero:

#vi /etc/ldap.conf

Y agregamos estas líneas al final:

sudoers_base ou=SUDOers,dc=dominio,dc=raíz

#sudoers_debug 2

Con esto, indicamos la ruta de búsqueda de los usuarios que pueden realizar un “sudo su”. La línea de sudoers, la descomentaremos, si tenemos algún problema al realizar el sudo y que nos muestre si la conexión se está realizando correctamente o donde puede estar el fallo.

Con esto se finaliza la configuración de Sudo desde LDAP.

Conf. cliente para usar LDAP.

***Actualmente esta guía es para toda la versión 5 de CentOS***

Necesitamos configurar nuestros equipos clientes y servidores para que el login se realice vía LDAP, ya disponemos del LDAP, por lo que simplemente realizaremos los siguientes cambios en la configuración de los equipos:

Si es posible, se recomienda instalar estos paquetes, para evitar problemas y tener siempre la versión más actualizada (en caso de que no se pudiera, revisar al final del texto las compatibilidades):

#yum install openldap  openldap-clients nss_ldap

Modificaremos los siguientes ficheros:

#vi /etc/sysconfig/autofs

LDAP_URI=”ldap://URLoIPdelServidor”

SEARCH_BASE=”dc=dominio,dc=raiz”         (p.e: “dc=google,dc=com”)

Con esto indicamos la dirección del LDAP y la ruta donde ha de buscar los grupos y usuarios.

Continuamos modificando ficheros:

#vi /etc/pam.d/sshd

session    required     pam_mkhomedir.so skel=/etc/skel/  umask=0022

#vi /etc/pam.d/login

session    required     pam_mkhomedir.so skel=/etc/skel/  umask=0022

Esta modificación en ambos ficheros, permite que al hacer login con un usuario “nuevo”, se genere su home si esta no existe.

Ahora ejecutaremos el siguiente comando, que con la información que le demos, nos configurará automáticamente los ficheros /etc/ldap.conf y /etc/openldap/ldap.conf:

#authconfig-tui

- Marcaremos:

* Utilizar LDAP

* Utilizar contraseña MD5

* Utilizar contraseñas ocultas (shadow)

* Utilizar Autenticación LDAP

- Vamos a Siguiente:

* Servidor: ldap://URLoIPdelServidor

* DN base: dc=dominio,dc=raíz

Al finalizar, si revisamos los ficheros /etc/ldap.conf y /etc/openldap/ldap.conf podremos comprobar que se han añadido estas líneas.

Para ir finalizando, agregaremos el servicio nscd al inicio:

chkconfig --add nscd

chkconfig nscd on

# chkconfig --list |grep nscd

nscd            0:desactivado 1:desactivado 2:activo 3:activo 4:activo 5:activo 6:desactivado

Y reiniciaremos los siguientes servicios:

#/etc/init.d/autofs restart

#/etc/init.d/nscd restart

Si ahora intentamos logarnos con un usuario del LDAP, deberíamos poder acceder sin problemas.

Puede ser, que en alguna máquina nos muestre el siguiente error “This account is currently not available.”

Esto puede deberse a que en el local de la máquina esté nuestro usuario y esté configurado como /sbin/nologin, para ello, cambiaremos esto por un /bin/bash:

#usermod -s /bin/bash NombreUsuario

Como comentario final, indicar que esto es una guía básica, ya que vosotros deberíais tener el LDAP en modo seguro, eso implica que a los clientes tienes que copiarles los certificados del servidor LDAP e indicarlo en los ficheros /etc/ldap.conf y /etc/openldap/ldap.conf

Sobre esta configuración si que hay 200.000 guías, así que seguidlas, por que yo he juntado diferentes guías para montar estos posts.

Descargar paquetes de Ubuntu no soportados.

Oh my Cat!! tengo un ubuntu no soportado que de momento no puedo actualizar pero tengo que instalarle algo y paso de hacerlo completamente manual....que puedo hacer?

Pues muy sencillo, fácil y para toda la familia, edita el siguiente fichero:

vi /etc/apt/sources.list

Añade delante de cada repositorio un # para comentar esas líneas, o bien, bórralas, ahora añade los siguientes repos:



deb http://old-releases.ubuntu.com/ubuntu/ maverick main
deb-src http://old-releases.ubuntu.com/ubuntu/ maverick main


deb http://old-releases.ubuntu.com/ubuntu/ maverick-updates main
deb-src http://old-releases.ubuntu.com/ubuntu/ maverick-updates main


deb http://old-releases.ubuntu.com/ubuntu/ maverick universe
deb-src http://old-releases.ubuntu.com/ubuntu/ maverick universe
deb http://old-releases.ubuntu.com/ubuntu/ maverick-updates universe
deb-src http://old-releases.ubuntu.com/ubuntu/ maverick-updates universe

Después de editarlo, haz un

apt-get update

Revisa las líneas y si todo está correcto, instala el paquete que necesites.

Un saludo a todos.

PD: Si, lo sé, es un post chorra, pero es que es una chuletilla que necesito!!

PD2: odio ubuntu XD

Time out en el envío de notificaciones de Nagios o con Centreon.

Hemos detectado, que las notificaciones de error o recuperación, no se estaban enviando correctamente. Revisando el nagios.log que se encuentra en /usr/local/nagios/var/ hemos visto las siguientes líneas y como al final daba un time out.

[1365591978] EXTERNAL COMMAND: SEND_CUSTOM_SVC_NOTIFICATION;link_que_sea/;0;nagiosadmin;Prueba de notificación.

[1365591978] SERVICE NOTIFICATION: “contacto_que_sea”;link_que_sea/;CUSTOM (OK);service-notify-by-email;HTTP OK: HTTP/1.1 200 OK - 37509 bytes in 0.522 second response time;nagiosadmin;Prue

ba de notificación.

[1365592019] Warning: Contact 'contacto_que_sea' service notification command '/usr/bin/printf "%b" "***** centreon Notification *****\n\nNotification Type: RECOVERY\n\nService: link_que_sea\nHost:

host_que_sea\nAddress: 100.100.100.100\nState: OK\n\nDate/Time: 10-04-2013 Additional Info : HTTP OK: HTTP/1.1 200 OK - 37509 bytes in 0.522 second response time" | /bin/mail -s "** RECOVERY alert - link_que_sea/ is OK **" correo_contacto' timed out after 40 seconds

He probado a enviar un mail desde la consola de Linux y funcionaba correctamente, he probado a ejecutar el mismo comando de la última línea

“ usr/bin/printf "%b" "***** centreon Notification *****\n\nNotification Type: RECOVERY\n\nService: link_que_sea\nHost:

host_que_sea\nAddress: 100.100.100.100\nState: OK\n\nDate/Time: 10-04-2013 Additional Info : HTTP OK: HTTP/1.1 200 OK - 37509 bytes in 0.522 second response time" | /bin/mail -s "** RECOVERY alert - link_que_sea/ is OK **" correo_contacto”

Y se envía correctamente, entonces, ¿cuál era el problema?

Después de revisar, buscar mas errores y buscar en la red, he encontrado un post de 2009 que me ha dado la vida y efectivamente ha funcionado.

Voy a explicar como solucionarlo para Nagios y para Centreon.

En Nagios, tendremos que modificar el fichero nagios.cfg, nos iremos a la linea de

notification_timeout=30

Y cambiaremos el 30 por un 120, después reiniciaremos Nagios y probablemente nos vuelva a funcionar correctamente el envío de notificaciones.

En Centreon, si lo habéis hecho igual y luego habéis recargado todo desde Nagios marcando “Move Export Files”, comprobaréis que el fichero ha vuelto a su origen.

Para que esto no pase, dentro de “configuration” → Nagios, en el panel izquierdo, clickaremos sobre “nagios.cfg” y después sobre el nagios.cfg que nos interese.

Iremos a la pestaña Log Options y en Notification Timeout, cambiaremos el 30 por el 120.

Reiniciamos Nagios a través de Centreon y con esto tendremos las notificaciones.

El foro del año de la polka que me ha dado la solución es:

http://forums.meulie.net/viewtopic.php?f=60&t=4324

Si tenéis mas dudas, escribidme, que me gusta!

Recuperar la contraseña de Oracle 11g en Linux.

Como siempre, libero una de msi chuletillas por si me hiciera falta recuperar o por si le sirve a otra persona.

Tengo un Oracle 11g sobre un RHEL 6.3, no tengo la contraseña.

Después de seguir varias guías y ver que no lo estaba haciendo bien, hay que tener en cuenta, que en Linux, el propietario de ficheros como Listener.ora, tnsnames.ora, etc... es el usuario oracle, que se genera por defecto durante la instalación.

Aprendiendo con Metaesploitable.

Soy una inculta en el tema de la seguridad y el autoaprendizaje es lento, así que hay que buscar formas no agresivas para aprender, vamos, que no voy a publicar si esto lo hago contra una máquina chunga o no, por que el otro día se dio la casualidad que estuve rodeada de maderos y yo pensando…anda que como haga cosas malassssssss…..me pillan fijo, que yo miento muy mal XD

Y ahora para rellenar, pensaba hacer esto escuchando el último disco de Sean Paul, pero no voy a poder por que me estoy bailando todas en la silla, y sin parar!!

Bueno, prosigo que ya sabéis que me disperso y os disperso a los demás; 

Hace relativamente poco hice un curso de seguridad y conocí Metaesploitable, una máquina virtual que ya viene preparada para probar cositas (  http://www.offensive-security.com/metasploit-unleashed/Metasploitable  ) Como veréis viene una máquina preparada para Vmware, pero funciona perfectamente en VirtualBox.

Lo bueno de esta máquina es que ya viene con muchas aplicaciones “por defecto” y por ello trae muchas vulnerabilidades.

OJO!! Si vais a hacer pruebas con esto, esta documentación tiene spoilers.

El maravilloso mundo de la instalación de GIT + GITOLITE.

Este es el tipo de aplicaciones que me hacen sentir tonta y mira no, se que no lo soy!

Tampoco soy supermegainteligente, pero vamos, que me defiendo....

Ya se que había dicho que no iba a hacer un post de la instalación de Git, pero como ninguna de las chopocientas guías que me he leído me ha funcionado bien, he decidido hacer una guía propia especificando todo, ya que parece que la instalación de Git cambia por disitribución de Linux y por versión sacada, es que ni la guía oficial.

Resulta que Git es un controlador de versiones hecha especialmente para desarrolladores y su diferencia con los demás,es que es distribuido (sigo prefiriendo subversion), supuestamente eso es mejor, además, que lo diseño y lo programó Linus Torvalds.....estoy segura de que el día que se inventó esto estaba fumando algo....

Instalar Git es muy fácil, o yum install git, apt-get git, siguiente siguiente si lo instalas en windows.... pero ojo! que esto es solo el cliente, para poder tener un servidor de git, se puede solo con git, pero lo lógico es acompañarlo de gitolite, por cierto, después de instalar esto, que sepáis que no tiene Web y que hay que liarla un poquillo mas para ponerle interfaz (menos de 4 minutos tardo en instalar Subversion XD).

Por qué he dicho que me hacía sentir tonta? por que después de no conseguir que ninguna guía me funcionara y conseguir instalarlo, resulta que con 10 comandos, está git funcionando.

Vayamos al lío:

Esta guía es para instalar Git y Gitolite en un CentOS 6.3 a día 21 de Agosto de 2012., para Gitolite3 con la versión 1.7.1 de Git; fuera de estos parámetros, no se yo que tal funcionará.

En el servidor hacemos lo siguiente:

#yum install git           (instalación de git)

#useradd git                
#passwd git                 (creamos el usuario git y le ponemos contraseña)


#su git                        (nos logamos con el usuario git)

$git clone http://github.com/sitaramc/gitolite                         (nos descargamos gitolite, comprobar esta URL si ha pasado tiempo desde que se escribió esta guía)

$gitolite/install         (instalamos gitolite, esto nos crea los repositorios testing y gitolite-admin)

$ssh-keygen              (creamos la clave de git, la guardará en $HOME/.ssh/)

$gitolite/src/gitolite setup -pk  id_rsa.pub               (generamos el acceso para la clave de git para así administrar lso repositorios).

Una vez ejecutado este último comando, en .ssh/Authorized_keys aparecrá un comando sobre esta clave, no hay que tocarlo, es sólo para que lo podáis ver.

$scp id_rsa* usuario@clientegit:[/home/usuario/.ssh]   (copiamos las claves en el .ssh de nuestro usuario)

Por último, volvemos al cliente e intentamos clonarnos un repositorio:
$git clone git@servidorgit:gitolite-admin      (descargamos el repo en la ruta que queramos)

Debería mostrar como se descarga el repositorio.

A partir de este momento, ya es conocimiento sobre los comandos y usos de Git.
De momento no se manejar correctamente el Git, pero si aprendo alguna cosilla mas que os pueda ser interesante, os lo pondré.

Ah! si desde el cliente de Git hacéis un:

$ssh git@servidorgit info

Os mostrará la versión de Gitolite, de Git y los repositorios a los que tenéis acceso con sus permisos correspondientes

Pues nada, espero que no sufráis como lo he hecho yo, si os toca instalarla!!

Un saludo.

Configurar Tarjeta de red para instalar un Linux en Hyper-V

A diferencia de instalar Windows con Hyper-V, también podemos instalar varias distribuciones de Linux, en nuestro caso, instalamos CentOS.

 A raíz de esto, hemos detectado que la tarjeta no la coge correctamente, porque Linux no lleva instaladas los servicios de instalación de Microsoft, y después de probar varias soluciones, que en algunos casos si funcionan y que en otros no, hemos detectado que la mejor configuración sería la siguiente:

Al ir a instalar la máquina virtual, antes de iniciar con el sistema operativo (también se puede hacer después de la instalación), accedemos a la configuración de la máquina virtual y le añadimos una tarjeta de red heredada, una vez añadida, podemos instalar el sistema operativo o acceder a la máquina y desde

#system-config-network-tui

Podremos ver, que el sistema ha reconocido perfectamente la tarjeta de red.

Este tipo de tarjeta, se usa normalmente para sistemas que no traen por defecto instalados los Servicios de Instalación de Microsoft.

Como ver la tarjeta de red al instalar CentOS en Hyper-v.

Por defecto, las distribuciones Linux no llevan instaladas los servicios de instalación, es por ello, al instalar una máquina Linux, no se detecte la tarjeta de red correctamente, para que esto no falle y se pueda ver dicha interfaz de red, antes de instalar la máquina, aparte de tenerle asignado una tarjeta de red “física”, le tenemos que agregar desde la configuración de la máquina, una tarjeta de red heredada, con esto, el sistema operativo reconocerá perfectamente la tarjeta de red.

 Por ejemplo si es CentOS, una vez instalado, ejecutamos el

#system-config-network-tui

Y veremos desde la herramienta que detecta perfectamente la tarjeta de red, ahora podemos configurarlo desde aquí o desde /etc/sysconfig/network-scripts.