Problemas con DHCP corporativo

[JAP]

Estimados:

Mi red corporativa me tiene cansado.

Paso a explicarme:

Tengo un equipo con Debian "jessie" desde hace dos años, que ha corrido
sin inconvenientes en la red corporativa, con las configuraciones que
más abajo detallo.
Hace un mes cambié de lugar físico, pero mantengo computadora.
Ya he cambiado el cable que me une hasta el "switch", funciona
perfectamente.
Si conecto mi máquina con "jessie", es IMPOSIBLE obtener dirección IP.
Si conecto una máquina con WinXP/7 al cable, obtiene dirección IP sin
inconvenientes.
Si de mi máquina con"jessie", QUE NO TIENE IP, inicio un VirtualBox con
WinXP, obtiene IP sin inconvenientes.
Es imposible iniciar la red en forma manual con "ifup".
Con "ifconfig", A VECES, NO SIEMPRE, sí se inicia.

Reinstalé todos los paquetes relativos a dhcp-client.

He "tocado" el archivo /etc/dhcp/dhclient.conf, adicionándole la línea
send vendor-class-identifier "MSFT 5.0";
que en algún foro lo ví como una manera de reportarse a los equipos como
una terminal "Microsoft", y ha solucionado algún problema similar.
Fracasé con todo éxito.

¿Cuál es el problema?
Que tengo dos redes en la máquina, y luego del inicio del servicio de
"networking", /etc/network/interfaces mediante, debo utilizar una serie
de parámetros de ruteo para evitar colisiones.
Ruteo que SIEMPRE funcionó sin inconvenientes, hasta que me cambié de
escritorio (físico, el de madera, se entiende).
Como no obtiene dirección IP para eth0, no se rutea como debe, y debo
hacero "a mano" luego de iniciado el sistema, si es que he logrado
obtener dirección IP.

¿Mi miedo 1?
System-d / systemctl

¿Mi miedo 2?
Que la "ferretería" (switch, routers, etc.), tengan "algo"
Windows-dependiente.


Escucho opiniones.

Desde ya, muchas gracias.

JAP

#########################################################################
### Configuración de redes

# /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# Intranet
auto eth0
allow-hotplug eth0
iface eth0 inet dhcp
dns-nameserver 10.115.1.201

# Internet
auto eth1
allow-hotplug eth1
iface eth1 inet dhcp
dns-nameserver 190.103.220.2
dns-nameserver 8.8.8.8

# Enrutamiento
post-up ip route change default via 192.168.2.1 dev eth1
post-up route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.116.1.254 dev eth0

# Enrutamiento

post-up route add -host 10.96.1.205 gw 10.116.1.254 dev eth0
post-up route add -host 10.1.0.231 gw 10.116.1.254 dev eth0
post-up route add -host 10.1.12.201 gw 10.116.1.254 dev eth0
post-up route add -host 10.1.0.202 gw 10.116.1.254 dev eth0
post-up route add -host 10.1.0.216 gw 10.116.1.254 dev eth0
post-up route add -host 10.1.0.211 gw 10.116.1.254 dev eth0
post-up route add -host 10.1.0.215 gw 10.116.1.254 dev eth0
post-up route add -host 10.1.0.224 gw 10.116.1.254 dev eth0
post-up route add -host 10.3.10.118 gw 10.116.1.254 dev eth0


#########################################################################
### Reporte estado de redes

# ifconfig
eth0 Link encap:Ethernet HWaddr d0:50:99:21:90:8f
inet6 addr: fe80::d250:99ff:fe21:908f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:387 errors:0 dropped:0 overruns:0 frame:0
TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:32603 (31.8 KiB) TX bytes:3036 (2.9 KiB)

eth1 Link encap:Ethernet HWaddr a0:f3:c1:01:da:92
inet addr:192.168.2.52 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::a2f3:c1ff:fe01:da92/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9124 errors:0 dropped:0 overruns:0 frame:0
TX packets:7180 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2566359 (2.4 MiB) TX bytes:848589 (828.7 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:857 errors:0 dropped:0 overruns:0 frame:0
TX packets:857 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:90841 (88.7 KiB) TX bytes:90841 (88.7 KiB)


#########################################################################
### Ruteo luego de un arranque de sistema o /etc/init.d/networking start
### Se ve que por no levantar eth0, no rutea como debe

# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
default 192.168.2.1 0.0.0.0 UG 0 0 0 eth1
192.168.2.0 * 255.255.255.0 U 0 0 0 eth1


#########################################################################
### Intento de obtener dirección DHCP

# ifdown eth0
Killed old client process
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/d0:50:99:21:90:8f
Sending on LPF/eth0/d0:50:99:21:90:8f
Sending on Socket/fallback
DHCPRELEASE on eth0 to 10.115.1.201 port 67

# ifup eth0
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/d0:50:99:21:90:8f
Sending on LPF/eth0/d0:50:99:21:90:8f
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 18
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13
No DHCPOFFERS received.
No working leases in persistent database - sleeping.


#########################################################################
### Iniciar interfaz en forma manual con "ifconfig"

# ifconfig eth0 up

# ifconfig
eth0 Link encap:Ethernet HWaddr d0:50:99:21:90:8f
inet addr:10.116.1.187 Bcast:10.116.1.255 Mask:255.255.255.0
inet6 addr: fe80::d250:99ff:fe21:908f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16941 errors:0 dropped:0 overruns:0 frame:0
TX packets:379 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1738401 (1.6 MiB) TX bytes:101825 (99.4 KiB)


#########################################################################
### Máquina virtual WinXP dentro de "jessie" que obtiene IP por puente a
eth0

C:\>ipconfig -all

Configuración IP de Windows

Nombre del host . . . . . . . . . : WinXP-Oracle
Sufijo DNS principal . . . . . . :
Tipo de nodo. . . . . . . . . . . : híbrido
Enrutamiento habilitado. . . . . .: No
Proxy WINS habilitado. . . . . : No
Lista de búsqueda de sufijo DNS: xxxx.zzzzz

Adaptador Ethernet Conexión de área local :

Sufijo de conexión específica DNS : xxxx.zzzzz
Descripción. . . . . . . . . . . : Adaptador Ethernet PCI AMD
PCNET Fam
ily
Dirección física. . . . . . . . . : 08-00-27-44-CA-59
DHCP habilitado. . . . . . . . . : No
Autoconfiguración habilitada. . . : Sí
Dirección IP. . . . . . . . . . . : 10.116.1.180
Máscara de subred . . . . . . . . : 255.255.255.0
Puerta de enlace predeterminada : 10.116.1.254
Servidor DHCP . . . . . . . . . . : 10.115.1.201
Servidores DNS . . . . . . . . . .: 10.115.1.201
10.1.12.201
Servidor WINS principal . . . . . : 10.115.1.201
Servidor WINS secundario . . . . : 10.1.0.203
Concesión obtenida . . . . . . . : lunes, 14 de marzo de 2016
11:14:43
Concesión expira . . . . . . . . .: martes, 22 de marzo de 2016
11:14:43

[Camaleón]

Post by JAP
Tengo un equipo con Debian "jessie" desde hace dos años, que ha corrido
sin inconvenientes en la red corporativa, con las configuraciones que
más abajo detallo.
Hace un mes cambié de lugar físico, pero mantengo computadora.
Ya he cambiado el cable que me une hasta el "switch", funciona
perfectamente.
Si conecto mi máquina con "jessie", es IMPOSIBLE obtener dirección IP.
Si conecto una máquina con WinXP/7 al cable, obtiene dirección IP sin
inconvenientes.
Si de mi máquina con"jessie", QUE NO TIENE IP, inicio un VirtualBox con
WinXP, obtiene IP sin inconvenientes.
Es imposible iniciar la red en forma manual con "ifup".
Con "ifconfig", A VECES, NO SIEMPRE, sí se inicia.

(...)

Lo que veo es que eth0 (10.115.x.x ¿?) no recibe datos del servidor DHCP
(10.116.x.x ¿?) por lo que lo primero que tendrías que comprobar es si
configurando manualmente la interfaz eth0 en el mismo segmento de red en
el que está el servidor DHCP es capaz de comunicarse con él (ping) y
obtener la información que necesita para configurar dinámicamente el
adaptador eth0, así descartas cualquier problema físico (de hardware,
como cableado, separación física de redes, boca de switch, etc...).

Si esto funciona y eth0 se inicia sin errores, el problema podría estar
en la configuración de las rutas por lo que tendrías que ir revisando una
a una todas las que vas cargando, en lugar de añadirlas de golpe.

¿Están todos los equipos que entran en juego (servidor DHCP, switches y
equipos clientes) físicamente en la misma red?

Saludos,

[JAP]

Post by Camaleón
Lo que veo es que eth0 (10.115.x.x ¿?) no recibe datos del servidor DHCP
(10.116.x.x ¿?) por lo que lo primero que tendrías que comprobar es si
configurando manualmente la interfaz eth0 en el mismo segmento de red en
el que está el servidor DHCP es capaz de comunicarse con él (ping) y
obtener la información que necesita para configurar dinámicamente el
adaptador eth0, así descartas cualquier problema físico (de hardware,
como cableado, separación física de redes, boca de switch, etc...).
Si esto funciona y eth0 se inicia sin errores, el problema podría estar
en la configuración de las rutas por lo que tendrías que ir revisando una
a una todas las que vas cargando, en lugar de añadirlas de golpe.
¿Están todos los equipos que entran en juego (servidor DHCP, switches y
equipos clientes) físicamente en la misma red?
Saludos,

A mí también me llamó la atención las diferencias de segmentos, pero
como ves, las máquinas con windows levantan con esa configuración.
Y sí, todo los equipos están conectados.
El ruteo, no lo puedo tocar hasta tanto no levanta la IP.
Ya he intentado con configuraciones más reducidas de las interfaces, y
hasta he invertido los cables de placa.
El tema es la resolución de IP en esa red, no importa cómo esté
configurado ni dónde esté conectado.

Seguí dando vueltas, y hace media hora desactivé y eliminé Avahi.
El sistema levantó ambas redes.
Lo dejaré así hasta mañana, y veré si fue un golpe de suerte o se solucionó.
Otra cosa que haré, es traerme una netbook que también corre jessie, e
intentar con dicha maquinita.

JAP

[JAP]

Post by Camaleón
Lo que veo es que eth0 (10.115.x.x ¿?) no recibe datos del servidor DHCP
(10.116.x.x ¿?) por lo que lo primero que tendrías que comprobar es si
configurando manualmente la interfaz eth0 en el mismo segmento de red en
el que está el servidor DHCP es capaz de comunicarse con él (ping) y
obtener la información que necesita para configurar dinámicamente el
adaptador eth0, así descartas cualquier problema físico (de hardware,
como cableado, separación física de redes, boca de switch, etc...).
Si esto funciona y eth0 se inicia sin errores, el problema podría estar
en la configuración de las rutas por lo que tendrías que ir revisando una
a una todas las que vas cargando, en lugar de añadirlas de golpe.
¿Están todos los equipos que entran en juego (servidor DHCP, switches y
equipos clientes) físicamente en la misma red?
Saludos,

A mí también me llamó la atención las diferencias de segmentos, pero
como ves, las máquinas con windows levantan con esa configuración.
Y sí, todo los equipos están conectados.
El ruteo, no lo puedo tocar hasta tanto no levanta la IP.
Ya he intentado con configuraciones más reducidas de las interfaces, y
hasta he invertido los cables de placa.
El tema es la resolución de IP en esa red, no importa cómo esté
configurado ni dónde esté conectado.

Seguí dando vueltas, y hace media hora desactivé y eliminé Avahi.
El sistema levantó ambas redes.
Lo dejaré así hasta mañana, y veré si fue un golpe de suerte o se solucionó.
Otra cosa que haré, es traerme una netbook que también corre jessie, e
intentar con dicha maquinita.

JAP

[JAP]

Post by JAP
Tengo un equipo con Debian "jessie" desde hace dos años, que ha corrido
sin inconvenientes en la red corporativa, con las configuraciones que
más abajo detallo.
Hace un mes cambié de lugar físico, pero mantengo computadora.
Ya he cambiado el cable que me une hasta el "switch", funciona
perfectamente.
Si conecto mi máquina con "jessie", es IMPOSIBLE obtener dirección IP.
Si conecto una máquina con WinXP/7 al cable, obtiene dirección IP sin
inconvenientes.
Si de mi máquina con"jessie", QUE NO TIENE IP, inicio un VirtualBox con
WinXP, obtiene IP sin inconvenientes.
Es imposible iniciar la red en forma manual con "ifup".
Con "ifconfig", A VECES, NO SIEMPRE, sí se inicia.

Cuando uno usa la MISMA máquina durante varios años en distintos
lugares, pasan estas estupideces.

En mi lugar de trabajo anterior, por alguna razón que no recuerdo,
configuré de la siguiente manera el archivo

###########################################
### /etc/hosts

127.0.0.1 localhost
10.3.1.178 station37.red.corporativa station37

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
###########################################


La línea

10.116.1.178 station37.red.corporativa station37

es la que estaba causando TODO el problema.
"station37" es el nombre de host de mi máquina, definido en /etc/hostname
Al cambiar de lugar de trabajo, si bien la red es la misma, cambió el
segmento de red al trabajar sobre otro "switch", y la interfaz eh0 no
podía configurarse sola.

Gracias a todos.

JAP

[JAP]

Por ahora, perecería que he dado con la solución, aunque no me gusta nada.

En mi antiguo lugar de trabajo, quien administraba ese segmento de red,
tenía la muy buena costumbre de asignar por DHCP a las máquinas la misma
IP. Es decir, la terminal user25, siempre tenía la IP 10.3.20.132
Si bien el cliente usa DHCP dinámico, desde el servidor se mantenía esta
política, la cual no la veo mal, pues facilita el funcionamiento a DNS.

En el nuevo lugar de trabajo, distante unos 1.000 km del anterior, el
administrador tiene una política distinta, y es que el DHCP es dinámico
"en serio".
Desde que estoy, nunca asigna dos veces la misma IP a la terminal.

La computadora está tomando la dirección IP luego de haber:
* limpiado algunas relaciones en el archivo /etc/hosts para
identificación de alias.
* eliminado avahi, que sinceramente, no me afectaba en lo más mínimo.

Y cosa extraña: luego de eliminar avahi, el inicio del sistema se
quedaba colgado con una línea que textualmente reproduzco:

A start job is running for LSB: NFS support files common to client and
server

Dado que no tengo carpetas o archivos en la red que presten servicios
NFS, eliminé el paquete, lo cual no me agradó, pero hube de hacerlo.

Seguiré dando vueltas con el tema, pues si bien "funciona", me da tirria
el no saber por qué las cosas no son como debería ser. Amén que no tengo
muy en claro de para qué sirve, cómo se usa y qué utilidad tiene avahi.

Gracias a todos.

JAP

[Camaleón]

Post by JAP
Por ahora, perecería que he dado con la solución, aunque no me gusta nada.

(...)

Post by JAP
* limpiado algunas relaciones en el archivo /etc/hosts para
identificación de alias.
* eliminado avahi, que sinceramente, no me afectaba en lo más mínimo.
Y cosa extraña: luego de eliminar avahi, el inicio del sistema se
A start job is running for LSB: NFS support files common to client and
server
Dado que no tengo carpetas o archivos en la red que presten servicios
NFS, eliminé el paquete, lo cual no me agradó, pero hube de hacerlo.

Con desactivar el servicio NFS hubiera sido suficiente.

Post by JAP
Seguiré dando vueltas con el tema, pues si bien "funciona", me da tirria
el no saber por qué las cosas no son como debería ser. Amén que no tengo
muy en claro de para qué sirve, cómo se usa y qué utilidad tiene avahi.

Revisa los registros para ver qué es lo que hace el cliente (y qué
respuesta recibe del servidor) cuando pide una IP, si no sabes qué sucede
no podrás averiguar el origen del problema.

Avahi (zeroconf) es una aplicación de autoconfiguración del servicio de
red para cuando nadie lo reclama o configura. Viene a ser como el
botoncito mágico de los puntos de acceso wifi que se configuran solos
(WPS), es decir, un dolor de muelas.

En resumen: no verás avahi en servidores pero sí en portátiles o equipos
de escritorio porque los entornos gráficos (kde, gnome...) lo suelen
necesitar para sus "tontunas" (streaming, multicast, upnp...).

Saludos,

[JAP]

Post by Camaleón
Con desactivar el servicio NFS hubiera sido suficiente.

"...in six months you will install the automagical printer config tool
and wonder why it isn't working....you will file a bug and get jumped
because nobody can reproduce it.....you will end up reinstalling and
everything will 'just work' then.....all because you forgot that six
months ago you disabled avahi-daemon instead of uninstalling it

the crystal ball never lies!"

Post by Camaleón

Post by JAP
Seguiré dando vueltas con el tema, pues si bien "funciona", me da tirria
el no saber por qué las cosas no son como debería ser. Amén que no tengo
muy en claro de para qué sirve, cómo se usa y qué utilidad tiene avahi.

Revisa los registros para ver qué es lo que hace el cliente (y qué
respuesta recibe del servidor) cuando pide una IP, si no sabes qué sucede
no podrás averiguar el origen del problema.

Es lo que pienso hacer.

Abrazos miles.

JAP

[Camaleón]

Post by JAP

Post by Camaleón
Con desactivar el servicio NFS hubiera sido suficiente.

"...in six months you will install the automagical printer config tool
and wonder why it isn't working....you will file a bug and get jumped
because nobody can reproduce it.....you will end up reinstalling and
everything will 'just work' then.....all because you forgot that six
months ago you disabled avahi-daemon instead of uninstalling it
the crystal ball never lies!"

(...)

Yo no he dicho que desactives avahi sino NFS ;-)

De hecho, ni siquiera lo tengo instalado (¡gracias XFCE!):

ii libavahi-client3:amd64 0.6.31-2 amd64 Avahi client library
ii libavahi-common-data:amd64 0.6.31-2 amd64 Avahi common data files
ii libavahi-common3:amd64 0.6.31-2 amd64 Avahi common library
ii libavahi-glib1:amd64 0.6.31-2 amd64 Avahi GLib integration library

Y no, tampoco lo eliminaría, al menos en gnome:

***@stt008:~# apt-cache rdepends avahi-daemon
avahi-daemon
Reverse Depends:
telepathy-salut
task-desktop
sugar-presence-service-0.90
sugar-presence-service-0.88
sugar-presence-service-0.84
sane-utils
libsane
rhythmbox
pulseaudio-utils
pulseaudio-module-zeroconf
libnss-mdns
lib32nss-mdns
netatalk
mpd
libmono-zeroconf1.0-cil
libapache2-mod-dnssd
gnome
mandos
gshare
gobby-0.5
gobby-0.4
gajim
forked-daapd
education-desktop-sugar
education-desktop-other
ltsp-controlaula
controlaula
banshee
avahi-utils
avahi-dnsconfd
avahi-discover
4store
hplip
gajim
cups

Saludos,

[JAP]

Post by JAP
Por ahora, perecería que he dado con la solución, aunque no me gusta nada.
En mi antiguo lugar de trabajo, quien administraba ese segmento de red,
tenía la muy buena costumbre de asignar por DHCP a las máquinas la misma
IP. Es decir, la terminal user25, siempre tenía la IP 10.3.20.132
Si bien el cliente usa DHCP dinámico, desde el servidor se mantenía esta
política, la cual no la veo mal, pues facilita el funcionamiento a DNS.
En el nuevo lugar de trabajo, distante unos 1.000 km del anterior, el
administrador tiene una política distinta, y es que el DHCP es dinámico
"en serio".
Desde que estoy, nunca asigna dos veces la misma IP a la terminal.
* limpiado algunas relaciones en el archivo /etc/hosts para
identificación de alias.
* eliminado avahi, que sinceramente, no me afectaba en lo más mínimo.
Y cosa extraña: luego de eliminar avahi, el inicio del sistema se
A start job is running for LSB: NFS support files common to client and
server
Dado que no tengo carpetas o archivos en la red que presten servicios
NFS, eliminé el paquete, lo cual no me agradó, pero hube de hacerlo.
Seguiré dando vueltas con el tema, pues si bien "funciona", me da tirria
el no saber por qué las cosas no son como debería ser. Amén que no tengo
muy en claro de para qué sirve, cómo se usa y qué utilidad tiene avahi.
Gracias a todos.
JAP

avahi no tiene nada que ver con el problema.
Lo he reinstalado y no causa inconvenientes.

El que sí se bloquea al inicio del sistema, y por esa razón debí
eliminarlo, es nfs-common.
Lo raro, es que llevé la máquina a mi casa, la conecté directamente a
Internet, sin pasar por un contrafuegos ZeroSehll
(http://www.zeroshell.org/), y allí NFS no causa problemas.

(Nota mental: averiguar cómo identificarme ante ZeroShell con un script
en el arranque en vez de un navegador, en forma similar a lo que hace
cntlm.sourceforge.net).

Sigo investigando / aprendiendo.

Saludos

JAP

[Camaleón]

Post by JAP
avahi no tiene nada que ver con el problema.
Lo he reinstalado y no causa inconvenientes.

Pues claro que no, es un buen tipo :-)

Post by JAP
El que sí se bloquea al inicio del sistema, y por esa razón debí
eliminarlo, es nfs-common.

Y repito que no era necesario, sólo con desactivarlo hubiera sido
suficiente.

Post by JAP
Lo raro, es que llevé la máquina a mi casa, la conecté directamente a
Internet, sin pasar por un contrafuegos ZeroSehll
(http://www.zeroshell.org/), y allí NFS no causa problemas.

(...)

De hecho NFS viene activado de manera predeterminada en Debian, yo pensé
el desactivarlo porque no lo uso pero como da problemas, ahí está:

***@stt008:~# service nfs-common status
all daemons running

Saludos,

[JAP]

Post by Camaleón
De hecho NFS viene activado de manera predeterminada en Debian, yo pensé

Como dije antes, prefiero eliminar un paquete a desactivarlo, pues si a
futuro instalo algo que lo necesite por dependencia, si está
desactivado, no genera mensaje de alerta al instalar y el nuevo paquete
no funciona al estar desactivado el servicio.
Prefiero que se cargue como dependencia y se reactive solo.

JAP

[Camaleón]

Post by JAP

Post by Camaleón
De hecho NFS viene activado de manera predeterminada en Debian, yo
pensé el desactivarlo porque no lo uso pero como da problemas, ahí

Como dije antes, prefiero eliminar un paquete a desactivarlo, pues si a
futuro instalo algo que lo necesite por dependencia, si está
desactivado, no genera mensaje de alerta al instalar y el nuevo paquete
no funciona al estar desactivado el servicio.
Prefiero que se cargue como dependencia y se reactive solo.

Un paquete que se instale como dependencia no tiene por qué iniciarse
automáticamente, tendrías que hacerlo manualmente por lo que estás en las
mismas ;-)

Saludos,

[Juan José López]

El Martes, 5 de abril de 2016 11:09:16 JAP escribió:

Llego tarde a la conversación, así que no se de que va el resto. Solo un

Post by JAP
(Nota mental: averiguar cómo identificarme ante ZeroShell con un script
en el arranque en vez de un navegador, en forma similar a lo que hace
cntlm.sourceforge.net).

Supongo que será un 'portal cautivo' de esos; échale un vistazo a

http://www.vicente-navarro.com/blog/2013/02/28/configurando-routers-domesticos-desde-la-linea-de-comandos-con-wget/

wget y un script en /etc/network/if-up.d/ te podría servir.

[JAP]

Post by Juan José López
Llego tarde a la conversación, así que no se de que va el resto. Solo un

Post by JAP
(Nota mental: averiguar cómo identificarme ante ZeroShell con un script
en el arranque en vez de un navegador, en forma similar a lo que hace
cntlm.sourceforge.net).

Supongo que será un 'portal cautivo' de esos; échale un vistazo a
http://www.vicente-navarro.com/blog/2013/02/28/configurando-routers-domesticos-desde-la-linea-de-comandos-con-wget/
wget y un script en /etc/network/if-up.d/ te podría servir.

Antes que nada, cambio el "Asunto", dado que esto no tiene que ver con
el hilo original.

Sí, Juan José, se trata que en el trabajo tengo un portal cautivo
controlado por un ZeroShell (http://www.zeroshell.org/) que me obliga a
identificarme con una página de "log-on" mediante un navegador WEB.

Ayer se me dio una situación risible, si no fuera porque terminé con un
dolor de cabeza.
Estaba haciendo la actualización de todos los lunes a "jessie", que
dicho sea de paso esta semana estuvo bastante pesadita, y se cortó el
suministro eléctrico unos momento, quedando a medio actualizar.
Lo "gracioso" del tema es que me quedé sin consola gráfica, y no podía
identificarme en el portal cautivo ni con lynx ni con links.
Por ende, no pude continuar con el proceso.
La solución: me llevé la máquina a casa y lo arreglé.

Lo único que encontré del tema es un script en python de este sitio
http://www.zeroshell.org/forum/viewtopic.php?t=1109
Bajé los primeros, y no logro hacerlo funcionar, y no entiendo mucho de
python para arreglarlo, considerando que es "viejo".
Los más "nuevos" no puedo bajarlos, pues el sitio http://aljufry.org
parecería que está fuera de línea.

Con lo que me has pasado, lo estudiaré y veré si puedo de alguna manera
habilitar el paso por el portal cautivo en forma automática y modo
consola, para evitar otros "inconvenientes" de los que solemos trastear
con la pantalla en blanco y negro.

Muchas gracias.

JAP

[Juan José López]

Post by JAP

Post by Juan José López
Llego tarde a la conversación, así que no se de que va el resto. Solo un

Post by JAP
(Nota mental: averiguar cómo identificarme ante ZeroShell con un script
en el arranque en vez de un navegador, en forma similar a lo que hace
cntlm.sourceforge.net).

Supongo que será un 'portal cautivo' de esos; échale un vistazo a
http://www.vicente-navarro.com/blog/2013/02/28/configurando-routers-domest
icos-desde-la-linea-de-comandos-con-wget/
wget y un script en /etc/network/if-up.d/ te podría servir.

Antes que nada, cambio el "Asunto", dado que esto no tiene que ver con
el hilo original.
Sí, Juan José, se trata que en el trabajo tengo un portal cautivo
controlado por un ZeroShell (http://www.zeroshell.org/) que me obliga a
identificarme con una página de "log-on" mediante un navegador WEB.
Ayer se me dio una situación risible, si no fuera porque terminé con un
dolor de cabeza.
Estaba haciendo la actualización de todos los lunes a "jessie", que
dicho sea de paso esta semana estuvo bastante pesadita, y se cortó el
suministro eléctrico unos momento, quedando a medio actualizar.
Lo "gracioso" del tema es que me quedé sin consola gráfica, y no podía
identificarme en el portal cautivo ni con lynx ni con links.
Por ende, no pude continuar con el proceso.
La solución: me llevé la máquina a casa y lo arreglé.
Lo único que encontré del tema es un script en python de este sitio
http://www.zeroshell.org/forum/viewtopic.php?t=1109
Bajé los primeros, y no logro hacerlo funcionar, y no entiendo mucho de
python para arreglarlo, considerando que es "viejo".
Los más "nuevos" no puedo bajarlos, pues el sitio http://aljufry.org
parecería que está fuera de línea.
Con lo que me has pasado, lo estudiaré y veré si puedo de alguna manera
habilitar el paso por el portal cautivo en forma automática y modo
consola, para evitar otros "inconvenientes" de los que solemos trastear
con la pantalla en blanco y negro.
Muchas gracias.
JAP

Ok. Ya se sobre que era la conversación :-)

Si tienes problemas habituales con el suministro eléctrico, un pequeño
'trick'. No actualices de golpe; primero descarga los paquetes con 'apt-get -d
upgrade', y solo cuando termine de descargar haz la actualización real con
'apt-get upgrade'.

En caso de fallo de corriente, por lo menos tendrás todos los paquetes ya
descargados y podras continuar la actualización sin problemas. Te puedes hacer
un pequeño script que lo automatice; o incluso un alias en Bash.

Lo del portal cautivo es simple, si tienes unos conocimientos básicos de html.
Miras el código fuente de la página, y en algún lugar estará el formulario que
se usa, con la página real a la que se mandan los datos junto con las
variables.

Te montas un pequeño script en /etc/network/if-up.d/ que compruebe si estas
conectado a la red del trabajo (por la IP, o con algún comando que lo
compruebe, por ejemplo bajando la página web de autorización de ZeroShell ),
y, si estas efectivamente en el trabajo, que lance WGET con los argumentos y
el URL necesario.

Así dicho parece más complicado de lo que en realidad es ;-) ya verás que no
es para tanto. Yo tenía algo similar para obtener mi IP real desde la página
de mi router, y actualizar mi cuenta de DynDns (cuando era gratis).

Saludos.

[JAP]

Post by Juan José López

Post by JAP
Sí, Juan José, se trata que en el trabajo tengo un portal cautivo
controlado por un ZeroShell (http://www.zeroshell.org/) que me obliga a
identificarme con una página de "log-on" mediante un navegador WEB.
Ayer se me dio una situación risible, si no fuera porque terminé con un
dolor de cabeza.
Estaba haciendo la actualización de todos los lunes a "jessie", que
dicho sea de paso esta semana estuvo bastante pesadita, y se cortó el
suministro eléctrico unos momento, quedando a medio actualizar.
Lo "gracioso" del tema es que me quedé sin consola gráfica, y no podía
identificarme en el portal cautivo ni con lynx ni con links.
Por ende, no pude continuar con el proceso.
La solución: me llevé la máquina a casa y lo arreglé.
Lo único que encontré del tema es un script en python de este sitio
http://www.zeroshell.org/forum/viewtopic.php?t=1109
Bajé los primeros, y no logro hacerlo funcionar, y no entiendo mucho de
python para arreglarlo, considerando que es "viejo".
Los más "nuevos" no puedo bajarlos, pues el sitio http://aljufry.org
parecería que está fuera de línea.
Con lo que me has pasado, lo estudiaré y veré si puedo de alguna manera
habilitar el paso por el portal cautivo en forma automática y modo
consola, para evitar otros "inconvenientes" de los que solemos trastear
con la pantalla en blanco y negro.
Muchas gracias.
JAP

Ok. Ya se sobre que era la conversación :-)
Si tienes problemas habituales con el suministro eléctrico, un pequeño
'trick'. No actualices de golpe; primero descarga los paquetes con 'apt-get -d
upgrade', y solo cuando termine de descargar haz la actualización real con
'apt-get upgrade'.
En caso de fallo de corriente, por lo menos tendrás todos los paquetes ya
descargados y podras continuar la actualización sin problemas. Te puedes hacer
un pequeño script que lo automatice; o incluso un alias en Bash.
Lo del portal cautivo es simple, si tienes unos conocimientos básicos de html.
Miras el código fuente de la página, y en algún lugar estará el formulario que
se usa, con la página real a la que se mandan los datos junto con las
variables.
Te montas un pequeño script en /etc/network/if-up.d/ que compruebe si estas
conectado a la red del trabajo (por la IP, o con algún comando que lo
compruebe, por ejemplo bajando la página web de autorización de ZeroShell ),
y, si estas efectivamente en el trabajo, que lance WGET con los argumentos y
el URL necesario.
Así dicho parece más complicado de lo que en realidad es ;-) ya verás que no
es para tanto. Yo tenía algo similar para obtener mi IP real desde la página
de mi router, y actualizar mi cuenta de DynDns (cuando era gratis).
Saludos.

Esa es la idea.
A partir de la página que me pasaste, llegué a otros lados y terminé
instalando en el navegado la extensión y app "Tamper" (son dos para que
funcione), que es similar a "HTTP Headers", pero más prolija en sus
salidas, dado que permite monitorear paso a paso las comunicaciones
entre el navegador y el servidor del portal.
Ya he extraído los datos, y tengo que ver cómo lograr con un script en
/etc/init.d, como bien dices, autenticar el equipo en el arranque.
(Tengo un script /etc/init.d/inicio de hace años para estos menesteres,
donde pongo y saco cosas a voluntad :)

Cuando tenga algo más o menos armado, aviso.

Saludos.

JAP