Cómo mostrar IP en la pantalla de inicio de sesión en Arch Linux

3

Pude hacerlo en Ubuntu editando el archivo:

/etc/rc.local

y añadir:

IP=$(/sbin/ifconfig eth0 | grep 'inet addr:' | cut -d: -f2 | awk '{ print $1}')

echo "IP: $IP" > /etc/issue

En Arch, este archivo no existe "/etc/rc.local" y después de algunas búsquedas descubrí que tengo que crear este archivo:

/etc/systemd/system/rc-local.service

Contenido:

[Unit]
Description=/etc/rc.local compatibility

[Service]
Type=oneshot
ExecStart=/etc/rc.local

TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99

[Install]
WantedBy=multi-user.target

Luego cree "/etc/rc.local".

Contenido:

IP=$(/sbin/ip route get 1 | awk '{print $NF;exit}')
echo "IP: $IP" > /etc/issue

exit 0

Luego hazlo ejecutable:

sudo chmod +x /etc/rc.local

Y finalmente comenzar / probar:

sudo systemctl start rc-local.service

Obteniendo el error:

Job for rc-local.service failed because the control process exited with error code.
See "systemctl status rc-local.service" and "journalctl -xe" for details.

Salida de systemctl status rc-local.service:

* rc-local.service - /etc/rc.local Compatibility
Loaded: loaded (/etc/systemd/system/rc-local.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Fri 2016-06-10 02:52:17 AST; 1min 59s ago
Process: 760 ExecStart=/etc/rc.local (code=exited, status=203/EXEC)

Jun 10 02:52:17 maro systemd[1]: Starting /etc/rc.local Compatibility...
Jun 10 02:52:17 maro systemd[1]: rc-local.service: Control process exited, code=exited status=203
Jun 10 02:52:17 maro systemd[1]: Failed to start /etc/rc.local Compatibility.
Jun 10 02:52:17 maro systemd[1]: rc-local.service: Unit entered failed state.
Jun 10 02:52:17 maro systemd[1]: rc-local.service: Failed with result 'exit-code'.

Salida de journalctl -xe:

-- Unit rc-local.service has begun starting up.
Jun 10 02:52:17 maro systemd[760]: rc-local.service: Failed at step EXEC spawning /etc/rc.local: Exec format error
-- Subject: Process /etc/rc.local could not be executed
-- Defined-By: systemd

Actualizar:

  1. Agregado #!/bin/basha/etc/rc.local
  2. sudo systemctl daemon-reload
  3. sudo systemctl start rc-local.service
  4. ¡Ahora no recibo ningún error! pero:
  5. sudo systemctl status rc-local.service Salida:

    rc-local.service - /etc/rc.local Compatibility Loaded: loaded (/etc/systemd/system/rc-local.service; enabled; vendor preset: disabled) Active: inactive (dead) since Fri 2016-06-10 13:13:04 AST; 3s ago Process: 488 ExecStart=/etc/rc.local (code=exited, status=0/SUCCESS)

    Jun 10 13:13:04 maro systemd[1]: Starting /etc/rc.local Compatibility... Jun 10 13:13:04 maro systemd[1]: Started /etc/rc.local Compatibility.

Intenté reiniciar y antes de iniciar sesión dice:

rtnetlink answers network is unreachable

En la pantalla de inicio de sesión: muestra "IP:" solo sin mostrar la IP de la máquina. Una vez que inicie sesión y haga ping en Google, por ejemplo, Internet funciona sin problemas y se puede acceder a la máquina a través de LAN.


  1. sudo env -i /etc/rc.local = Sin salida
  2. ip route get 1 | awk '{print $NF;exit}'que se usa en /etc/rc.local= 192.168.0.103

Salida de nav:

XDG_SESSION_ID=c2
TERM=xterm
SHELL=/bin/bash
SSH_CLIENT=192.168.0.100 64436 22
SSH_TTY=/dev/pts/0
USER=maro
MAIL=/var/spool/mail/maro
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
PWD=/home/maro
LANG=C
SHLVL=1
HOME=/home/maro
LOGNAME=maro
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
SSH_CONNECTION=192.168.0.100 64436 192.168.0.103 22
XDG_RUNTIME_DIR=/run/user/1000
_=/usr/bin/env

Editado /etc/systemd/system/rc-local.service: se eliminaron cuatro configuraciones después de ExecStart. También he intentado cambiar: Type=forking

El estado sigue diciendo: Active: inactive (dead)

Maro
fuente
Parece que desea mostrar la dirección IP, no la IP, como solicitó en la pregunta. Solo tiene dos IP posibles: IPv4 e IPv6.
Ron Maupin
@RonMaupin, perdón por el error, quiero mostrar la dirección IP interna. ¿Hay algún error en mis pasos o código bash?
Maro

Respuestas:

0

Estoy 99% seguro de que es porque no has llamado al intérprete en el guión.

/etc/rc.local :

#!/bin/bash

IP=$(/sbin/ip route get 1 | awk '{print $NF;exit}')
echo "IP: $IP" > /etc/issue

exit 0

Eso probablemente funcionará. Muchas personas también llaman explícitamente bash en su archivo de sistema; He modificado su archivo de servicio. Menciono esto a continuación, pero 4 de las configuraciones son innecesarias (que yo sepa) y también las eliminé aquí:

/etc/systemd/system/rc-local.service :

[Unit]
Description=/etc/rc.local compatibility

[Service]
Type=oneshot
ExecStart=/bin/bash /etc/rc.local

[Install]
WantedBy=multi-user.target

También debe usar la ruta completa a awk, pero eso sería un error diferente: aún no ha llegado tan lejos en el script.

Si eso no lo solucionó, tendrá que revisar cada pieza y ver qué funciona por sí solo. El entorno systemd es muy escaso (similar a las cosas lanzadas desde cron, pero menos de un entorno). Las cosas que siempre funcionan dejan de funcionar debido a un entorno ambiental que siempre se establece, por lo que olvidamos que incluso es necesario configurarlo. Así que intente aislar por un problema relacionado con eso. Aquí hay algunos pasos de aislamiento:

  1. Ejecutar directamente (con sudo o en un shell raíz para cada paso) /etc/rc.localdesde un terminal.

  2. Si eso funciona, intente ejecutarlo como env -i /etc/rc.local si no funciona, puede intentar pasar los valores ambientales uno a la vez, o hacer que su fuerza de fuerza bruta los establezca (muy mal visto, pero usted si estaba tan inclinado) puede volcar la salida enven un shell 'normal' env | sed 's/^/export /g' | sed 's/=/='/g' | sed -e 's/$/'/g' > env_values.shy establecer explícitamente esos valores en el script. Es necesario que friegue un poco la lista; tendrá valores de conexión ssh y otras entradas controladas por eventos que probablemente no se rompan cualquier cosa, pero definitivamente no ayudará a nada).

  3. Si no es así porque no importa cómo ejecute rc.local simplemente funciona, eliminaría su archivo de servicio systemd. Pruébalo sin ellos.

    • Los restos después de la configuración de salida no son relevantes aquí, eso está relacionado con el uso de esto para llamar a un script de una sola vez que genera demonios.
    • El ajuste tty es un caso muy especial y no es necesario.
    • El ajuste de tiempo de espera de 0 puede provocar sistemas bloqueados durante el ciclo de energía.
    • SysVStartPriority está en desuso en systemd ver> 218+; arch está en al menos la versión 229.
  4. Intente usar un @reboot cronjob . Entorno muy similar, pero lo encuentro menos 'quisquilloso'. @reboot reemplaza el método normal de sincronización de 5 asteriscos (por ejemplo, en lugar de 0 0 0 * * simplemente pone @reboot), y su secuencia de comandos se llamará cada arranque. Si necesita ayuda adicional para configurar un cronjob definitivamente puedo proporcionarle más detalles.

No hay nada que pueda ver mal con su método para obtener su IP lan. Aquí hay un método diferente para probar si causa algún problema. El tuyo es probablemente mejor. tiene menos dependencias y ciertamente más limpio, pero he estado usando este enfoque durante años sin problemas:

iprgx='(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)'
cat /etc/hostname | /usr/bin/host -4r | grep -Eo "$iprgx"

Si todo eso falla, entonces tendrá que leer la documentación del sistema ... que, como probablemente haya descubierto, es muy larga en el recuento de palabras e increíblemente baja en información específica. Hágame saber lo que descubra, incluso si estas ideas no funcionan, sin embargo, puede haber una pista en los resultados.

Actualizar

Según su actualización, los cambios en el servicio permiten que el script se ejecute correctamente. El estado que está obteniendo es normal para una única vez: los servicios de systemd se centran realmente en los procesos de daemon que se inician, y no lo está haciendo, así que (simplificando mucho) básicamente dice que está inactivo simplemente significa ese script aún no se está ejecutando, no está programado para ejecutarse y no generó ningún proceso que systemd esté rastreando, lo cual es correcto y correcto. El hecho de que muestra que recientemente se ejecutó y salió con éxito significa que está funcionando.

El segundo problema es el tiempo relativo. La breve respuesta es que necesitará cambiar su archivo de servicio agregando las siguientes dos entradas en [Unidad]. Esto podría funcionar . Si no, sigue leyendo.

[Unit]
Wants=network-online.target
After=network-online.target

Hay una excelente redacción sobre este tema específico en stackexchange. Parecen haber cubierto todas las formas en que puede salir mal y las formas en que puede salir mal de una manera incorrecta ... No me molestaré en tratar de retransmitirlo, solo aclararlo de un aparente gurú.

Enfoque alternativo que tiene el beneficio de hacer enojar a los fanáticos de systemd

Si ese enfoque se vuelve difícil o imposible por cualquier razón, aquí hay un método de fuerza bruta mucho menos elegante al que generalmente recurro cuando se agota la paciencia de mi sistema:

Puede modificar su secuencia de comandos para esperar a que la dirección IP esté disponible en sí misma en lugar de enredarse en los problemas anteriores o posteriores. Es un truco porque está reimplementando intencionalmente la capacidad que está integrada en systemd, pero esto es lo que probablemente haría.

Actualicé este script (intenté ejecutarlo y encontré un par de problemas). Este funciona bien en mi sistema. Había usado la sintaxis de la función C en la llamada de suspensión, y me olvido de devolver cualquier cosa desde getIP; Ambos arreglados.

/etc/rc.local

#!/bin/bash   

iprgx='(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)'

# I put this into a function since you will be looping on it.
# the error you are seeing is from the ip call - I pipe the error to
# /dev/null to get rid of that annoyance.
getIP() {
  echo "IP=$(/sbin/ip route get 1 2>/dev/null | awk '{print $NF;exit}' | grep -Eo "$iprgx")"
}

# watchdog timer - bail if it doesn't resolve after some delta-T
wdTimer=1
IP=$(getIP)
#echo "($wdTimer) IP: $IP"
while [ "$IP" == "" ]; do
  # There's nothing special about .5 seconds - just seemed reasonable
  sleep 0.5
  IP=$(getIP)
  #echo "($wdTimer) IP: $IP"
  ((wdTimer++))
  # Arbitrarily chosen timeout of 20 * 0.5 = 10 seconds
  # You can have it wait as long as you want. I suggest not
  # setting the sleep time too low as you'll be hammering on the
  # ip utility fairly hardly in that case; not a huge deal regardless
  # I also had it log something to the syslog - your mileage may vary
  # with logger - there are alternative ways to do that.
  if [ "$wdTimer" -gt "20" ]; then
    # timeout
    logger -s "Timed out attempting to acquire LAN IP in rc.local"
    exit 1
  fi
done
#echo "IP: $IP" #> /etc/issue
exit 0

Y sí, uso esa expresión regular $ iprgx todo el tiempo, muy útil.

Argonautas
fuente
Realmente aprecio su gran respuesta, lo he intentado y publicado los resultados en mi pregunta para un mejor formato.
Maro
Pensé que habría problemas ocultos detrás del primero. Entonces el script se está ejecutando ahora; simplemente se está ejecutando demasiado temprano en el arranque. Estoy poniendo más información en mi respuesta
Argonautas
No hay ningún error ahora, pero cuando verifico el estado dice: Activo: inactivo (muerto) hace 3 segundos, ¿podría permanecer activo / en funcionamiento durante algunos minutos, por ejemplo? entonces resuelve el problema?
Maro
Hiciste esta pregunta antes de actualizar la respuesta, donde traté de aclararlo un poco. Básicamente, se espera el estado que está viendo (inactivo (muerto), comportamiento normal para un servicio de un solo disparo. Ya está hecho, no ha demonizado, no tiene capacidades de reinicio, detención, etc., por lo que se llama exactamente muerto. llevar es que funcionó con éxito - para este tipo de uno-tiro que 'éxito' es la información más relevante.
argonautas
Muchas gracias por cada segundo que tomó para escribir su respuesta, me ayudó mucho. las dos lineas despues la [Unit]resolvieron! Muchas gracias
Maro
3

En CentOS 7 y Debian 8 (y quizás también en otros), solo agregue la siguiente línea a/etc/issue

My IP address: \4

y eso se resolverá en la dirección IPv4 de la máquina. Si tiene varias interfaces de red y desea elegir una específica, puede especificarla con

My IP address: \4{eth0}
PaoloC
fuente