mount.cifs, kerberos y fichero de credenciales no predeterminado
Antes de nada, un saludo a la lista. Me he encontrado con el siguiente problema en una debian stretch: Si prueba a montar un directorio remoto compartido mediante el protocolo CIFS y autenticandome con kerberos, la cosa funciona: #v+ # kinit zicotropico@IESPJM.DOMUS Password for zicotropico@IESPJM.DOMUS: Warning: Your password will expire in 35 days on dom 19 feb 2017 15:12:11 CET # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: zicotropico@IESPJM.DOMUS [...] # mount -t cifs -o sec=krb5 //dc/home/zicotropico prueba/ #v- El directorio remoto se monta sin dar problemas. Sin embargo, si cambio el fichero de credenciales, no consigo montar el directorio porque no se encuentra: #v+ # export KRB5CCNAME=FILE:/tmp/krb5cc_0_YYY # kinit zicotropico@IESPJM.DOMUS Password for zicotropico@IESPJM.DOMUS: Warning: Your password will expire in 35 days on dom 19 feb 2017 15:12:11 CET # klist Ticket cache: FILE:/tmp/krb5cc_0_YYY Default principal: zicotropico@IESPJM.DOMUS [...] # mount -t cifs -o sec=krb5 //dc/home/zicotropico prueba/ mount error(126): Required key not available Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) #v- He buscado en internet, pero sin éxito. ¿Alguno alcanza a entender por qué no funciona? Los programas k* sí que atienden a la existencia de la variable de ambiente KRB5CCNAME y consultan el fichero. Muchas gracias de antemano. -- El amor es como los columpios, porque casi siempre empieza siendo diversión y casi siempre acaba dando náuseas. --- Enrique Jardiel Poncela ---
Re: Una de expresiones regulares
El lun, 21 de nov de 2016, a las 06:13:07 -0400, Juan Lavieri dijo: > Hola. > > > A ver si entiendo > > uno dos > 4cuatro letras es lo que necesito > abcd 1234 caja tapa > c4ja tapa esta noes > caja tapa esta vale > > Solo debería mostrar la última línea ¿Entendí bien? Lo que deben ser cuatro son las palabras, no la cantidad de letras de cada palabra. El que pueda haber números o no, es lo de menos, porque si se usa \w en vez de [[:alpha:]] también falla. -- Como todo al fin se sabe yo he sabido la verdad. --- Muñoz Seca ---
Re: Una de expresiones regulares
El lun, 21 de nov de 2016, a las 01:58:38 -0500, Carlos Zuniga dijo:
> Esto me funciona:
>
> $ cat foo
> dos tres cuatro
> uno dos tres cuatro
> uno dos tres cuatro cinco
>
> $ grep -E '^(\w+\s+){3}\w+$' foo
> uno dos tres cuatro
>
Gracias, pero no busco una solución, sino saber por qué la solución dada
no es (aparentemente) solución. Una alteranativa más aprecida a la
solución que das es esta (salvando el hecho de que como aparezcan comas
no vale):
$ grep -E '^(\b\w+\b\s*){4}$'<<<"a bc df"
a bc df
¿Por qué no desecha esa línea si no hay cuatro palabras?
--
Harto sabe, si me sabe bien.
--- Francisco de Quevedo ---
Una de expresiones regulares
Un saludo:
A ver si alguno sabe cuál es la causa de que falle lo siguiente:
Se pretende crear una regex de tipo ERE que concuerde con ilas líneas que
contengan cuatro palabras constitutidas por letras. Mi solución es esta:
^\W*(?[[:alpha:]]+\b\W*){4}$
Pero resulta que no me funciona bien:
$ grep -E '^\W*(?[[:alpha:]]+\b\W*){4}$'<<<"aff b cx"
aff b cx
Sin embargo, la expresión PCRE correspondiente sí funciona bien:
$ grep -P '^\W*(?:[[:alpha:]]+\b\W*){4}$'<<<"aff b cx"
y no devuelve salida. Por más que miro y remiro la expresión regular, me
parece que está bien. ¿A alguien se le ocurre algo, o es error que debo
achacar a grep?
--
Patrimonio es un conjunto de bienes, matrimonio es un
conjunto de males.
--- Enrique Jardiel Poncela --
Re: Locales y mayúsculas y minúsculas
El dom, 30 de oct de 2016, a las 06:55:04 +0100, fernando sainz dijo: > Creo que tr no soporta utf8. > puedes usar gawk que si lo hace. > (En mi instalación awk es un link a gawk y si me funciona bien. Hay > que instalar gawk) Pues debe de ser eso: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20114 Ni tr ni mawk (que era lo que yo estaba usando) funcionan. gawk como bien indicas, sí. Gracias. -- Los grandes hombres solemos ser modestos. --- Juan de Mairena --
Locales y mayúsculas y minúsculas
Un saludo a la lista. A ver si alguno es capaz de explicarse cómo sucede
esto en mi sistema.
Resulta que tengo estas locales:
$ locale
LANG=es_ES.UTF-8
LANGUAGE=
LC_CTYPE="es_ES.UTF-8"
LC_NUMERIC="es_ES.UTF-8"
LC_TIME="es_ES.UTF-8"
LC_COLLATE="es_ES.UTF-8"
LC_MONETARY="es_ES.UTF-8"
LC_MESSAGES="es_ES.UTF-8"
LC_PAPER="es_ES.UTF-8"
LC_NAME="es_ES.UTF-8"
LC_ADDRESS="es_ES.UTF-8"
LC_TELEPHONE="es_ES.UTF-8"
LC_MEASUREMENT="es_ES.UTF-8"
LC_IDENTIFICATION="es_ES.UTF-8"
LC_ALL=
Vamos, que mi sistema está configurado en castellano y utf-8. Todo me
marcha bien, pero he intentado lo siguiente y no he obtenido el
resultado esperado:
$ tr '[:lower:]' '[:upper:]' <<<"adiós"
ADIóS
$ awk '{print toupper($0)}' <<<"adiós"
ADIóS
O sea, el sistema no es capaz de saber que la mayúscula de la ó es la Ó.
De hecho, no es capaz de saber que "ó" es una letra:
$ tr -d '[:alpha:]' <<<"adiós"
ó
Sin embargo, tengo mi sistema (LC_CTYPE en concreto) en utf8, ¿no
debería ser capaz?
python sí funciona bien:
$ python3 -c 'print("adiós".upper())'
ADIÓS
--
e non l'arbitrio de femina lieve,
che sempre inchina a quel che men far deve.
--- Ludovico Ariosto ---
Problema con los logs de systemd
Antes de nada, un saludo a la lista después de da tanto tiempo. Tengo un problema con mi servidor jessie, pero no sé cómo narices meterle mano. Resulta que los logs quye pueden verse con journalctl han dejado de generarse. Los tradicionales siguen escribiéndose. Puedo ver el siguiente fallo: # systemctl --state failed UNIT LOAD ACTIVE SUBDESCRIPTION ● systemd-journal-flush.service loaded failed failed Trigger Flushing of Journal to Persistent Storage Curioseando he visto que este servicio depende de systemd-journald.service, que tampoco arranca: # systemctl status systemd-journald ● systemd-journald.service Loaded: error (Reason: Invalid argument) Active: inactive (dead) Creo que este a su vez necesita systemd-journald.socket: # systemctl status systemd-journald.socket ● systemd-journald.socket - Journal Socket Loaded: loaded (/lib/systemd/system/systemd-journald.socket; static) Active: inactive (dead) Docs: man:systemd-journald.service(8) man:journald.conf(5) Listen: /run/systemd/journal/stdout (Stream) /run/systemd/journal/socket (Datagram) que tampoco arranca. El problema es que si los intento arrancar a mano para ver qué ocurre: # systemctl start systemd-journald.socket Job for systemd-journald.socket failed. See 'systemctl status systemd-journald.socket' and 'journalctl -xn' for details Me sugiere que consulte los logs que, precisamente, no puedo generar. Y claro no sé por dónde tirar. He mirado a ver si había alguna modo de arrancar el servicio de modo que escupiera los erroes por pantalla, pero no he encontrado nada. ¿Se os ocurre algo? Gracias de antemano. -- Mira que la mejor parte de España, pudiendo Casta, se llamó Castilla. --- Tomé de Burguillos ---
Re: Montar unidades de memoria automáticamente en consola
El Thu, 05 de Nov de 2015, a las 09:48:07PM +0100, Rafael Cantos Villanueva
dijo:
> Buenas nuevamente
Hola.
> Bien, mi pregunta es si existe algún paquete que haga lo mismo que usbmount,
> pero montando los dispositivos con algún nombre identificativo, como la
> etiqueta de volumen que tenga asignada la unidad de memoria (por ejemplo,
> rafa16gb).
Yo uso udisks, pero te puedo decir poco porque lo configuré hace mucho
tiempo. Lo que sí ocurre es que me monta los dispositivos bajo /media
usando el nombre del volumen (p.e. /media/MIPICHOUSB).
> O si no es así, si hay alguna forma de saber que el dispositivo
> montado en /media/usb0, por ejemplo, se corresponde a la unidad en /dev/sdb
> (pues sabiendo este último dato puedo obtener con udev la información de la
> unidad).
$ mount | awk '$3 == "/media/usb0" {print $1}'
Un saludo.
--
El amor es como los columpios, porque casi siempre empieza
siendo diversión y casi siempre acaba dando náuseas.
--- Enrique Jardiel Poncela ---
Re: Problema con el logical sector size
El Wed, 21 de Oct de 2015, a las 02:12:59PM +, Camaleón dijo:
> Tú prueba a ver qué te dice. Al menos en esta guía que tienen los del
> kernel no dice nada sobre sectores, bloques y demás, simplemente que
> decidas en tipo volumen (disco completo o particiones), el tipo de raid
> (nivel 1) y lo gestiones al gusto:
>
> https://raid.wiki.kernel.org/index.php/RAID_setup
He mirado por encima y yo ahí no veo nada de utilidad que no sepa.
Imagino que puedo, simplemente, hacer que md0 esté constinuido por sda2 y
sdc (este último, así, a pelo sin particiones). Lo que ocurre es que
entonces este segundo disco no será arrancable y quiero que también lo
sea, por si el que se estropea es el disco "sda".
En cualquier caso, ya me han conectado el disco por SATA:
#v+
# blockdev --report /dev/sd{a,b}
RORA SSZ BSZ StartSecSize Device
rw 256 512 4096 0 1000204886016 /dev/sda
rw 256 512 512 0 1000203804160 /dev/sdb
#v-
Este sdb es el antiguo sdc. Ahora ambos tamaños lógicos son de 512.
Supongo que ya no habrá problemas, pero no quiero tocar nada hasta que
me confirmen que han hecho copia de seguridad de sda, porque antes de
constituir el raid tengo que cambiar el tamaño de sda2 para que ocupe
todo el disco. No debería pasar nada, pero hay que ponerse siempre en lo
peor.
Un saludo
--
-¿Quién le dice a v.m. que no se pueda hacer? Hacerse
puede, que ser imposible es otra cosa.
--- Francisco de Quevedo ---
Re: Problema con el logical sector size
El Tue, 20 de Oct de 2015, a las 08:15:55PM +0200, Manolo Díaz dijo: > Precisamente hace unos días me pasó algo similar. Se trataba de un > disco externo SATA para copias de seguridad que conecto y desconecto en > caliente. Como parte del proceso se verifica la partición antes de > montarla, y fsck retornó con un error de tamaño de sector 0. Aún así > pude montar la partición y desmontarla. Tras ello el error desapareció. > Ni idea de por qué ocurrió. El núcleo usado era Linux 4.2.1. Pero esto es que es raro y me ha parecido leer en internet que ya le ha pasado a alguien el observar diferencias entre la conexión por SATA y por USB. Además, este disco formaba parte de un RAID de dos discos y con los dos se ve exactamente igual: 4096 de tamaño de sector lógico. En cambio, el disco que está conectado por SATA (no es el mismo modelo) tien 4096 de tamaño físico, pero 512 de tamaño lógico. -- Dejemos metafísicas quimeras; vuesas mercedes garlen en chacota: que no está el mundo para hablar de veras. --- Tomé de Burguillos ---
Re: Problema con el logical sector size
El Tue, 20 de Oct de 2015, a las 05:46:01PM +, Camaleón dijo: > No clones las particiones, deja que sea mdadm quien genere > toda la estructura, metadatos, etc... ¿Esto se puede hacer? Mi disco original tiene particiones GPT: - sda1 pequeña de tipo BOOTBIOS para almacenar el stage2 de grub. - sda2 de tipo Linux RAID (fd) que es la que forma parte del RAID. Por eso clono la tabla. Para tener en el segundo disco los mismo y meter sdc2 en el RAID y ya que se encargue mdadm del resto. Obviamente, la instalación de grub en sdc aparte. Muchas gracias. -- Los grandes hombres solemos ser modestos. --- Juan de Mairena --
Problema con el logical sector size
Un saludo a la lista: Se me ha planteado el siguiente problema. Tengo un servidor con un disco que tiene preparado un RAID 1 (por software) y viendo que parece ir bien, le voy a añadir un segundo disco para que realmente el RAID haga su labor. Mi intención era copiar la tabla de particiones del primer disco en el segundo y añadirlo al RAID. Pero me ha surgido un imprevisto al intentar hacer lo primero. Al final el problema está en esto: # blockdev --report /dev/sda /dev/sdc RORA SSZ BSZ StartSecSize Device rw 256 512 4096 0 1000204886016 /dev/sda rw 256 4096 4096 0 1000204886016 /dev/sdc sda es el disco sobre el que está instalado el sistema (disco SATA) y sdc es este segundo disco (ahora mismo conectado por USB). "sdb" es un disco es un tercer disco que no pinta nada en el asunto, conectado por USB. El problema lo tengo en la columa SSZ (la que representa el tamaño lógico de los sectores): no es el mismo y cuando intento hacer la copia de la tabla de particiones falla. Además de que no sé si para que funcionaran en RAID debería ser igual el valor. No sé si está relacionado con el hecho de que sdc esté conectado por USB y no por SATA. Como no tengo acceso físico al servidor, pedí que me conectaran el disco de esta forma a fin de borrarle todo el contenido y preparar las particiones, porque este disco contenía un sistema arrancable y no quería correr el riesgo de que si me lo enchufaban directamente por SATA arrancara este sistema y no el sistema actual. Obviamente hecha esta primera fase, ordenaría que lo enchufaran dentro para completar el RAID. ¿Alguien sabe algo? Creo que voy a decirles que lo enchufen por SATA (a fin de cuentas he borrado las particiones, así que ya no arrancará), pero no sé si alguien sabrá conocerá algo al respecto. Gracias de antemano. -- La virtud, como el arte, hallarse suele cerca de lo difícil [...] --- Lope de Vega ---
Re: Limitar navegacion por IP
El Thu, 08 de Oct de 2015, a las 01:47:18PM +, Camaleón dijo: > Es decir, si el usuario quiere acceder a Google, me da lo mismos que > ponga "http://www.google.es; a que use "http://216.58.211.227;. Hay software que burla los filtros haciendo precisamente esa sustituciión, de manera que el filtro web en vez de ver: http://www.playboy.com ve: http://185.31.19.65 y deja pasar la petición. -- ¿No ha de haber un espíritu valiente? ¿Siempre se ha de sentir lo que se dice? ¿Nunca se ha de decir lo que se siente? --- Francisco de Quevedo ---
Re: Limitar navegacion por IP
El Wed, 07 de Oct de 2015, a las 05:02:32PM +, Camaleón dijo: > Hum... ¿quieres bloquear *todas* las direcciones IP que el usuario ponga > en el navegador? Yo, sinceramente no le veo ningún sentido a eso y si > squid resuelve los nombres de dominio te va a impedir la navegación, > directamente. No, lo que quiere es impedir que se pueda acceder a url en las que en vez de un nombre de dominio haya directamente una dirección ip, como: http://216.23.45.12/lo/qye/sea Yo lo he hecho, pero con squid+squidguard. -- Los grandes hombres solemos ser modestos. --- Juan de Mairena --
Re: Túnel ssh sobre proxy 8080
Si en el sitio remoto, sólo puedes salir por el 8080 (y el 80), está claro que un cliente allí sólo podrá conectar pidienso salir por el 8080. O sea: $ ssh -p 8080 yo@micasa Eso para empezar. En tu casa tienes que tener alguna forma de que al conectarte al puerto 8080 del router acabes en el puerto 22 de tu servidor interno. Esa parte creo que la tienes resuelta, redireccionando del 8080 de tu router al 22 de dicho servidor (DNAT). Sobre esto, quieres establecer un proxy para poder navegar, como si te encontraras en tu casa. en ese caso, lo que necesitas es hacer que tu servidor SSH actúe de servidor SOCKS (túnel dinámico): $ ssh -D 9000 -p 8080 yo@micasa He puesto "-D 9000" pero podrías usar cualquier otro puerto no privilegiado. Hecho esto abre firefox, por ejemplo, vete a la configuración del proxy y di que usarás un proxy socks que escucha en localhost:9000. Con chrome creo que no se puede hacer la configuración directamente y tienes que valerte de herramientas como tsocks. Un saludo. -- La virtud, como el arte, hallarse suele cerca de lo difícil [...] --- Lope de Vega ---
Re: Túnel ssh sobre proxy 8080
El Wed, 07 de Oct de 2015, a las 04:56:03PM +0200, fernando sainz dijo: > Chromium lee las variables de entorno para el proxy, con lo que puedes > usarlas si lo prefieres. > > export http_proxy=http://localhost:9000/ > export https_proxy=$http_proxy > export ftp_proxy=$http_proxy > export rsync_proxy=$http_proxy > # export no_proxy="localhost,127.0.0.1" # esta no, para este caso. Ya, pero de lo que se trata aquí es de usar un proxy socks. He mirado y sí se puede incluyendo un un parámetro: https://www.chromium.org/developers/design-documents/network-stack/socks-proxy -- Todos los hombres que no tienen nada importante que decir hablan a gritos. --- Enrique Jardiel Poncela ---
Re: Problemas de memoria
El Mon, 28 de Sep de 2015, a las 07:21:31PM +0200, Manolo Díaz dijo: >> Eso sí, insisto en que por mucho oom-killer, cuando a mí se me produjo >> la situación, no podía usar el servicio ssh, porque aunque éste estaba >> activo, no era capaz de abrir sesión. > > Si he entendido bien lo básico sobre el tema, oom-killer solo funciona > en el modo overcommit = 0. Ya, pero yo no me refiero a la situación de ayer, si no a otra que se produjo hace poco menos de un año. En esas circunstancias estaba a 0 el parámetro. -- Todo el mundo se suicidaría si después de suicidarse se pudiera seguir viviendo. --- Enrique Jardiel Poncela ---
Re: postfix (sender_bcc_maps) (recipient_bcc_maps)
El Mon, 28 de Sep de 2015, a las 10:40:48AM -0400, Ariel dijo: > usua...@midominio.com co...@midominio.com > > es decir poner uno por uno de los usuarios y declarar a su lado a que buzon > se debe hacer la copia tanto del correo entrante como el saliente. Si puede establecerse alguna regla de conversión entre los nombres de los dos buzones puedes usar expresiones regulares. Por ejemplo: (.*)@midominio.com $1-co...@micodminio.com Creo que se escribiría, si no, al menos es la idea. -- El hombre que se ríe de todo es que todo lo desprecia. La mujer que se ríe de todo es que sabe que tiene una dentadura bonita. --- Enrique Jardiel Poncela ---
Re: Problemas de memoria
Un saludo a todos ya he dejado la cosa funcionando y esperaré acontecimientos. Sobre algunas respuestas que me habéis dado: @Camaleon: Sí, normalmente la SWAP está a 0. Pero es que lo de ayer era la situación post-apocalipsis. Después de lograr entrar dejé el sistema que parecía funcionar, pero había cosas que no lo hacían perfectamente. Por ejemplo, el sistema de logs no funcionaba bien: en /var/log sí se escribían los eventos, pero si los pedía a través de journalctl (que por cierto es bastante cómodo) no se mostraban aquellos que se habían producido después de la hecatombe. Eso es fácil de solucionar, pero como no sabía si habría otros vicios ocultos, mandé reiniciar. Hoy, en una situación normal, la SWAP sí está a cero. En cuanto a la memoria cacheada, siempre me pasa: va aumentando lentamente y nunca me ha dado problemas ello. De hecho, si la mando liberar: # sync ; echo 1 > /proc/sys/vm/drop_caches Lo hace sin problemas y, casi toda, pasa otra vez a memoria libre. @Satiago y @Manolo: En cuanto a la estrategia de la memoria, no sé, sin discusiones que podría mantener sin controlar mucho. Entiendo que lo suyo es no llegar a situaciones extremas y tener siempre memoria libre. Pero en un caso extremo en que falte memoria, hay dos posibilidades: + No ejecutar nada más (que era lo que me pasaba a mí). + Sacrificar algo supuestamente poco importante, y poder ejecutar otra cosa, que quizás va encaminada a paliar la situación. QUizás es mejor lo segundo que lo primero: eyectar al pasajero para salvar el avión. Eso sí, insisto en que por mucho oom-killer, cuando a mí se me produjo la situación, no podía usar el servicio ssh, porque aunque éste estaba activo, no era capaz de abrir sesión. Un saludo. -- ¿No ha de haber un espíritu valiente? ¿Siempre se ha de sentir lo que se dice? ¿Nunca se ha de decir lo que se siente? --- Francisco de Quevedo ---
Re: Problemas de memoria
Para no escribir varios correos contentos a todos aquí: Ya he logrado meterme en el servidor y no he visto ningún programa que parezca consumir ingentes cantidades de memoria. El estado de la memoria cuando logré entrar era este: total used freeshared buffers cached Mem: 8072224 5397344 2674880223196 93108 3734372 -/+ buffers/cache:15698646502360 Swap: 209714832572 2064576 Parece que hay memoria libre, pero si por: vm.overcommit_memory = 2 no se puede ocupar más del 50%RAM+SWAP (6GB de memoria) con lo cual es plausible pensar que se llegó a ese límite cuando no podía acceder al servidor. En cuanto a las aplicaciones, la que más ocupaba era squid con un 6,8%. En su fichero de configuración tengo: cache_mem 512 lo que representa el 6,25% (1/16) de la memoria RAM. Así que el dato parece coherente. El siguiente es bind con un 3.5%. Esto sí me parece bastante, pero quizás sea debido a que tengo varias vistas y adición dinámica de nombres, de manera que unas vistas tienen que ser esclavas de otras. El caso es que he puesto a 0 el parámetro del núcleo y a funcionar un script que cada 10 minutos me comprueba las estadísticas de memoria y si se ha producido algún oom. Así tendré un historial del consumo de memoria y, si vuelve a fallar, más elementos de juicio. A ver qué pasa. > Si todos los programas piden más memoria de la que necesitan y le > dices al núcleo que nunca conceda más memoria de la que tiene > realmente, estás infrautilizando la memoria que tienes. Tiene 2GB de swap. Había leído que superar esa cantidad de swap no era muy recomendable. Aunque claro, a lo mejor es debido a que, si se da el caso, lo que el sistema está pidiendo urgentemente es una ampliación de la RAM. El caso es que en la salida de free, no parece haver mucha SWAP en uso. Me inclino a pensar que era por el valor de vm.overcommit_memory Comprobaré el consumo de swap en el historial del script que he puesto a funcionar. @ManoloDiaz > Sugiero que investigues el ajuste OOM score, se hace por procesos y > creo que systemd lo gestiona sin dificultad. Así podrías establecer > una jerarquía para ver cuáles son los últimos en ser aniquilados por > el núcleo cuando empieza a faltar memoria. Pues no tenía ni idea de esto. He ido a mirar y he visto que el SSH tiene, así sin tocarlo, el oom_score_adj a -1000. O sea, que el oom-killer no se lo cargará, cosa que me interesa. Sin embargo, tengo un servidor con wheezy más o menos como tenía antes configurado este y he comprobado que ocurre lo mismo. Sin embargo, el año pasado cuando tuve los problemas de oom, no podía acceder al servidor. Efectivamente sshd corría, pero tras autenticarme, devolvía un error de ssh_exchange_identification, creo recordar y me quedaba sin acceso. Así que ese valor, simplemente, no me ayuda mucho. Supongo que al acceder por SSH, es necesario abrir subprocesos que dada la situación no pueden abrirse. No sé si eso tendrá alguna solución. @Camaleon > Ojo, que "2719744 bytes" son ~2,5 MiB ;-) Sí, son MB, no GB... En fin, agradezco que me lo hayas dicho así como disimulando para que no se entere el resto. Gracias, de momento, a todos por las sugerencias. -- En la vida humana sólo unos pocos sueños se cumplen, la mayoría se roncan. --- Enrique Jardiel Poncela ---
Problemas de memoria
Un saludo a la lista: A ver si me podéis guiar y aconsejar para la nueva que se me avecina. Administro un servidor en la distancia (muy en la distancia), en el que tenía wheezy, y en el que hace cosa de dos semanas instalé jessie y reorganicé un poco los servicios. No fue una simple actualización, sino una instalación desde cero. El caso es que por la tarde dejó de servir convenientemente (la mayor parte de los servicios no van). He probado a conectarme por SSH y me encuentro con esto: #v+ $ ssh yo@mlejanoservidor [...] Last login: Thu Sep 24 23:56:00 2015 from X.Y.Z.T -bash: fork: No se pudo asignar memoria -bash: xmalloc: no se pueden asignar 4112 bytes (2719744 bytes asignados) Connection to milejanoservidor closed. #v- Parece claro que el servidor se ha quedado sin memoria, ¿no? Así que supongo que me toca averiguar qué programa es el culpable de esto. El servidor tiene 8GB; pero cuando tenía 4GB y corría wheezy (hace cosa de un año), empezó a darme problemas de memoria. Al final descubrí que era debido a que las aplicaciones requerían más memoria de esos 4GB en conjunto, y linux les dejaba reservar más memoria de la que existía (supongo que con la esperanza de que el conjunto nunca alcance el límite del total de memoria). Cuando realmente necesitaban más memoria que la memoria física, empezaban a cascar las aplicaciones. La solución obviamente era ampliar la memoria y así lo hice, pero también añadí, entre tanto, a sysctl,conf: vm.overcommit_memory = 2 para que el núcleo no obrara así. Ahora en el nuevo sistema, también tengo ese valor en el fichero. El caso es que durante algo menos de un año wheezy no dio ningún problema de memoria (y solía haber bastante memoria libre). El nuevo servidor tiene una configuración similar (no la misma), tiene la misma carga y corre prácticamente los mismos servicios, por lo que en condiciones normales no tendría que requerir mucha más memoria. La pregunta es, ¿qué me aconsejáis? No tengo acceso físico al servidor, así que el lunes no seré yo quien se acerque. Supongo que sería interesante poder hacer un "top" o un "ps" para obtener la memoria que ocupa cada proceso, pero no sé si ni siquiera se puede abrir una sesión de bash, quizás sea imposible. ¿Pido que me saquen una foto de la terminal? Quizás haya información interesante en ella. Por otro lado, el curso pasado me hice un script para hacer un seguimiento de la memoria, de manera que cada X tiempo obtenía la memoria libre y los cinco o diez procesos que más memoria consumían. Si me es imposible ahora mismo sacar quién ha sido el culpable, puede ser un buen aliado para tener un historial de la memoria hasta la próxima vez que casque. ¿Se os ocurre algo? Por cierto con eso de 2719744 bytes asignados, ¿a qué se refiere? ¿Asignados a quién? Porque no puede ser la memoria total, que es 8 GB. Gracias de antemano. -- La virtud, como el arte, hallarse suele cerca de lo difícil [...] --- Lope de Vega ---
Re: Problemas de memoria
El Sat, 26 de Sep de 2015, a las 02:20:00PM +, Camaleón dijo: > Lo primero sería ejecutar "free" (para ver qué cantidad de RAM hay en uso/ > disponible) y "top" (para ver qué servicios están consumiendo más RAM). Sí, eso ya lo he dejado dicho. En vez de "top" he sugerido "ps" para poder volcar a un disco. El problema es que no haya memoria para abrir una sesión bash. :( >> Por cierto con eso de 2719744 bytes asignados, ¿a qué se refiere? >> ¿Asignados a quién? Porque no puede ser la memoria total, que es 8 GB. > > Al cerrarte la sesión SSH entiendo que se referirá a eso, que no puede > ubicar la memoria necesaria para abrir una sesión de bash, asignar una > terminal, etc. No, si yo también. Lo que no sé es qué significa exactamente ese número 2719744 (~2.6 GiB). Un saludo y gracias. -- Y entonces sin embarazo, se le atiza un estacazo, se la mata y a otra cosa. --- Muñoz Seca ---
Re: Openssl
El Wed, 09 de Sep de 2015, a las 06:53:43PM +0200, Manolo Díaz dijo: > Tampoco le veo sentido a cifrar con la privada para que se pueda > descifrar con la pública, que se supone ampliamente difundida. Sería un > secreto a voces. Firmar: así todos saben que tú eres tú. Aunque lo que se hace en realidad es generar un hash del mensaje y cifrar sólo el hash. -- Todo el mundo se suicidaría si después de suicidarse se pudiera seguir viviendo. --- Enrique Jardiel Poncela ---
Problemas en jessie al montar los sistemas de ficheros
Un saludo a la lista: Tengo el siguiente problema molesto. Tengo una jessie, cuyo arranque gestiona systemd, que tiene el siguiente esquema de "particiones": NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:004G 0 disk ├─sda1 8:10 1007K 0 part └─sda2 8:204G 0 part └─md0 9:004G 0 raid1 ├─VGzipi-raiz 253:002G 0 lvm / ├─VGzipi-swap 253:10 64M 0 lvm [SWAP] ├─VGzipi-grub 253:20 32M 0 lvm /boot/grub ├─VGzipi-home 253:30 52M 0 lvm /home ├─VGzipi-srv 253:40 500M 0 lvm /srv ├─VGzipi-mysql 253:50 500M 0 lvm /var/lib/mysql └─VGzipi-lxc 253:60 500M 0 lvm /var/lib/lxc sr0 11:01 1024M 0 rom La primera partición sda1 es una partición BIOS BOOT para guardar el stage 2 de grub, ya que las particiones son GPT. El sistema en sí está en sda2 que está constituido por un RAID 1 (el segundo disco no está porque he forzado a que sólo haya un disco en el RAID, ya pondré el segundo). Dentro de ese RAID he definido un grupo de volúmenes. El caso es que el sistema suele arrancar, pero de vez en cuando NO lo hace. Se para el arranque y pide la contraseña de root para subsanar el problema. El problema es que uno de los sistemas de ficheros no ha podido montarlo. Es exactamente lo que pasa en este bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731270 pero ese bug ya está subsanado en la jessie estable. El sistema ya lo he pasado a un disco real (al principio estaba en una máquina virtual), pero sigue dando el problema: a veces, falla. Lo que aún no he hecho es sumarle el segundo disco[1]. Ahora hay instalados bastantes servicios, pero la instalación pelada de debian también presentaba este problema. [1]aclaro que el RAID está cojo conceptualmente (obviamente para un RAID 1 necesita dos discos), pero en la configuración no lo está: se puede definir un RAID 1 con un sólo disco: #v+ $ cat /proc/mdadm Personalities : [raid1] md0 : active raid1 sda2[0] 4189824 blocks super 1.2 [1/1] [U] unused devices: #v- ¿A alguien se le ocurre algo? Un saludo. -- Sabed que menda es don Mendo. --- Muñoz Seca ---
Re: cambios en el instalador debian
El Sat, 05 de Sep de 2015, a las 07:12:06PM -0300, Ricardo Delgado dijo: > efectivamente tambien realice los cambios en 70-persistent-net.rules y > al reiniciar me sucedio esto La información, en su momento, la saqué de aquí: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ Se pueden generar los nombres de las interfaces incluso incorporando la dirección MAC a ellos (aunque ciertamente son horrorosos y no hay modo de recordarlos luego). Saludos. -- -¿Quién le dice a v.m. que no se pueda hacer? Hacerse puede, que ser imposible es otra cosa. --- Francisco de Quevedo ---
Re: cambios en el instalador debian
El Fri, 04 de Sep de 2015, a las 01:20:11PM +, Camaleón dijo: > En el dmesg queda documentada la metamorfossis, es decir, que a ojos del > kernel la interfaz de red sigue siendo "eth0", llega udev y ésta > digievoluciona en... "enpisofo" :-) Pues estás de enhorabuena: has pasado de tener una vulgar tarjeta a tener un autor de tragedias griegas. :D Un saludo. -- Todos buscan quien ampare, yo quien enmiende; que más quiero ir entendido que defendido. --- Lope de Vega ---
Re: cambios en el instalador debian
El Thu, 03 de Sep de 2015, a las 02:35:12PM +, Camaleón dijo: > Curioso... en la testing que tengo instalada mantiene la nomenclatura > antigua (eth0, wlan0...), seguramente cuando no se instala desde cero > mantiene los nombres antiguos. Es debido a que ya existe /etc/udev/rules.d/70-persistent-net.rules, que se sigue leyendo y si en ese fichero dice que la tareta es "eth0", se seguirá llamando "eth0". Saludos. -- Quiere, aborrece, trata bien, maltrata, y es la mujer, al fin, como sangría, que a veces da salud y a veces mata. --- Lope de Vega ---
Re: [OT] LDAP-SAMBA autenticación para servicios
El Wed, 02 de Sep de 2015, a las 02:54:04PM +0200, Adrià dijo: > Excepto openvpn que lo desconozco (lo utilizo con otra autenticación), > los otros servicios que mencionas pueden autenticarse con un servidor > LDAP como podría ser OpenLDAP. Para la autenticación con openvpn puede usarse pam y openldap tiene módulo para pam. -- a ch'in amor s'invecchia, oltr'ogni pena si convengono i ceppi e la catena. --- Ludovico Ariosto ---
Re: [postfix] Añadir cabecera a una copia creada con recipient_bcc_maps
El Sat, 29 de Aug de 2015, a las 04:10:52PM +, Camaleón dijo: Ya, quieres que la cuenta que reciba la copia tenga un remitente erróneo pero en ese caso tendrías que modificar también el campo From: me temo, ya que los clientes de correo también lo toman como dirección de respuesta válida (en el RFC correspondiente lo tendrás mejor especificado). Más que erróneo, inexistente. Algo así como no-re...@no-where.com. MIraré a ver qué dice el RFC: mi experiencia con clientes es que si hay From: y Reply-To: los clientes usan la dirección de Reply-To preferentemente. En cuanto a Postfix, mira la documentación de header_checks¹ y address rewriting² teniendo en cuenta que sólo debe afectarle a la copia que reciba la dirección donde se duplican los mensajes manteniendo el otro correo intacto. Creo que ya he dado con la tecla: smtp_header_checks, que se usa para el correo saliente: /^To:.*@midominio.com\b/ PREPEND Reply-To: no-re...@nowhere.com Como el destinatario es una cuenta de mi propio dominio, si el correo está saliendo de mi servidor, es que sale rebotado hacia otra cuenta externa. Un saludo y gracias por el tiempo. -- Como todo al fin se sabe yo he sabido la verdad. --- Muñoz Seca ---
Re: Permitir videollamadas con imo en iptables
El Sun, 09 de Aug de 2015, a las 09:24:49AM +0200, Hospital Oftalmológico dijo: Estimados, Hola. Me pilla esto con los ojos enrojecidos y mucho sueño, así que te cuento un par de cosas de la configuración, aunque eso sí (no tengo ni idea de como funciona IMO, así que no sé cualés son los puertos que usa). En general, no sé de dónde has sacado las reglas, pero hay muchas que simplemente sobran. Por ejemplo, para qué narices haces esto: iptables -I POSTROUTING -j MASQUERADE -t nat -s 192.168.1.0/24 -p tcp \ --dport NUMPERO_DE_PUERTO -o eth0 con unos cuantos puertos, si al final haces esto: iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE Me da la sensación que estas usando un proxy web, porque el tráfico a los puertos 80,443 lo rediriges al puerto 3128 del servidor. Pero está mal hecho, porque el tráfico llega a ese puerto, pero la vuelta no está solucionada. De hecho, no tienes permitido el regreso de ningún tráfico. Además tampoco está solucionada la conexión de squid con los servidores web externos. Tienes reglas que, directamente no tienen sentido como estas: iptables -A INPUT -d 64.13.128.0/18 -j ACCEPT O las que permiten el paso al puerto 3128 por la cadena FORWARD. Tampoco hay ninguna regla que permita resolver nombres. Total que no hay por dónde pillar esa configuración. Te voy a dejar unas para que las tomes como base y luego las ajustas como te convegan Yo supongo que lo que quieres es dejar paso al tráfico hacia los puertos 5004, 5060 y 5062; y permitir la navegación con squid. Supongo que eth0 es la interfaz externa y eth1 la interna: #v+ ptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP # [1] Conexiones de loopback aceptadas iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # [2] Aceptamos conexiones a los puertos 5004, 5060 y 5062 iptables -A FORWARD -i eth1 -o eth0 -p tcp -m multiport \ iptables -A FORWARD -i eth1 -o eth0 -p udp -m multiport \ --dport 5004,5060,5062 -j ACCEPT # [3] Admitimos algunos protocolos (SMTP y POP3) iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport smtp -j ACCEPT iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport pop3 -j ACCEPT # [4] Redirección SQUID (modo transparente) iptables -A PREROUTING -i eth1 -p tcp -m multiport --dport http,https \ --redirect 3128 # [5] Permitimos las comonicaciones de SQUID con el exterior iptables -A OUTPUT -o eth0 -p tcp -m multiport --dport http,https \ -j ACCEPT # [6] Permitimos el tráfico DNS con el exterior al servidor: iptables -A OUTPUT -o eth0 -p udp --dport domain -j ACCEPT iptables -A OUTPUT -o eth0 -p tcp --dport domain -j ACCEPT # [7] Y el tráfico a los clientes con nuestro servidor DNS: iptables -A INPUT -i eth1 -p udp --dport domain -j ACCEPT iptables -A INPUT -i eth1 -p tcp --dport domain -j ACCEPT # [8] Enmascaramos a la salida de eth0 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE # [9] Permitimos las vueltas del tráfico permitido: iptables -A INPUT -m conntrack --ctstate DNAT,ESTABLISHED,RELATED \ -j ACCEPT iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT #v- QUizás haya algún gazapo. No he probado nada y estoy cansado, y además no sé muy bién qué es lo que quieres. Por supuesto, debes aceptar paquetes que no son para el propio servidor, pero es mejor que lo hagas cambiando /etc/sysctl.conf, que es un cambio persistente y no poniendo el 1, cada vezs que ejecutas el script. No he añadido la lista blanca de MACs que pueden navegar, pero puedes hacerlo cambiando la regla 4 y haciendo que sólo sufra SNAT el tráfico procedente de máquinas con esas MACs. No sé si tu intención es que sólo se pueda navegar hacia el sitio de IMO. Si así fuera, tendrías que modificar [5] para que no fuera tan permisiva (permite alcanzar cualquier distino). O, quizás mejor, hacer que sea squid el que haga ese trabajo. También tienes que tener en cuenta que SQUID debe estar bien configurado para que te funcione la cosa. A lo mejor deberías prescindir de él, para lo cual habría que sustituir la regla [4] por esta: ptables -A FORWARD -i eth1 -o eth0 -p tcp --dport http,https -j ACCEPT Y cuando, te funcione sin proxy web intentar meterlo en la ecuación. Un saludo. -- El amor es como los columpios, porque casi siempre empieza siendo diversión y casi siempre acaba dando náuseas. --- Enrique Jardiel Poncela ---
Re: [OT] Baja del servidor de RedIRIS como réplica de Debian (?)
El Tue, 02 de Jun de 2015, a las 03:38:38PM +, Camaleón dijo: Pero aún así y contando con esos escasos recursos, me pregunto si _de verdad_ no había nada mejor a eliminar que Debian en los servidores de RedIRIS... Tomémoslo siempre de la mejor forma: no podía eliminar otra cosa que no les reportara más ahorro de banda ;-) -- Vine a desembuchar y desembucho. --- Muñoz Seca --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150602165256.ga14...@cubo.casa
Re: Redireccionamiento
El Wed, 27 de May de 2015, a las 04:05:20PM -0400, l...@ida.cu dijo: Buenas a todos Cómo hacer para llevar esto a IPTALBES, lo tengo hecho en shorewall. Aquí lo que le digo es que redireccione todas las IP al puerto 3128 menos las IP declaradas en esta línea. ACCEPT loc fw tcp 3128 REDIRECT loc:!192.168.11.1-192.168.11.10,192.168.11.58-192.168.11.59 3128 tcp 80 tienes que hacer una regla por excepción (a menos que uses el módulo ipset). Por ejemplo: iptables -t nat -A PREROUTING -i iface_entrada -p tcp --dport 80 -s ip1 -j RETURN iptables -t nat -A PREROUTING -i iface_entrada -p tcp --dport 80 -s ip2 -j RETURN . . . iptables -t nat -A PREROUTING -i iface_entrada -p tcp --dport 80 -j REDIRECT --to-port 3128 -- -- Hoy he reñido a un hostelero. -- ¿Por qué? ¿Cuándo? ¿Dónde? ¿Cómo? -- Porque cuando donde como sirven mal, me desespero --- Tomás de Iriarte --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150528145701.ga7...@cubo.casa
Re: [OT] ¿Cambian los ISP el ToS?
Muchas gracias por la elocuente respuesta. Escribo rápido, porque no estaŕé delante de un ordenador hasta el lunes y no quería reputarme desconsiderado. No había caído en las pérdidas de la encapsulación PPPoE. Con lo aprendido ya puedo ir haciendo pruebas con cierto criterio. Saludos. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cajun_txjyxkpo1_htdh9nxcyvjuhur-jwhay+wpvaf4k0xu...@mail.gmail.com
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 de May de 2015, a las 04:21:50PM +0200, Raúl Alexis Betancor Santana dijo: Hola José Miguel, Hola, Raúl. Tu error está en suponer que porque tu pongas esos valores ... se van a respetar en la WAN, ningún operador los respecta, ya que ellos los sobreescriben según les convenga. En temas de QoS, solo puedes controlar lo que entra o sale de tu LAN ... no lo que viaja por la WAN. Más que error, lo que quiero saber es si esto es así o no. Me fastidia porque me impide reconocer a la entrada el tráfico ssh interactivo del que no lo es (scp). Saludos. -- Femmina è cosa mobil per natura. --- Francisco Petrarca --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513144807.ga7...@cubo.casa
Re: [OT] ¿Cambian los ISP el ToS?
Hola, Camaleón. ¿Sabe alguno algo al respecto? Si te refieres a priorizar algún tipo de tráfico, yo te diría que no, salvo lo que contratas sobre el papel (cuando hay TV de por medio). A lo que me refiero es que a un paquete que sale de mi máquina con valor 0x10 (mínimo retardo) en su segundo byte de la cabecera IP (o sea, el byte ToS), le cambien ese valor; y le pongan 0x0 (tráfico normal). Ni idea... no he tenido ningún problema con Movistar ¿Has probado a hacer lo que yo he hecho? Es por curiosidad. ni con ninguno de los routers que suministra ni cuando usaba rfc 1483 ni cuando nos han pasado a los direccionamientos pseudo-estáticos. En cuanto al cambio que notas, yo buscaría una posible causa por otro lado: https://www.google.es/webhp?q=ssh+tos+changes ¿Te refieres al bug del cliente openSSH? No es eso. He hecho lo siguiente: Máquinas A1 (Cliente) y A2 (Servidor) en la misma red local (en realidad, A2 es máquina virtual). Genero tráfico ssh interactivo y me pogno a escuchar con tcpdump en ambas máquinas. Tanto en A1 como en A2, observo que los paquetes salientes tienen el ToS a 0x10 y los entrantes también. Lo esperable, por otro lado. Ahora tomo una máquina B, que es un servidor externo y hago la misma prueba. En ambas máquinas observo que los paquetes salientes tiene el byte con valor 0x10 y los entrantes como 0x0. Como los paquetes salientes de una máquina son los entrantes de la otra, está claro que algo ha tenido que cambiarles el valor del byte durante el camino. Además, el servidor A2 y el servidor B tienen exactamente la misma configuración y el mismo software. Un saludo. -- ¿No ha de haber un espíritu valiente? ¿Siempre se ha de sentir lo que se dice? ¿Nunca se ha de decir lo que se siente? --- Francisco de Quevedo --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513142326.ga4...@cubo.casa
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 de May de 2015, a las 02:42:26PM +, Camaleón dijo: ¿Has probado a hacer lo que yo he hecho? Es por curiosidad. ¿Acceder en remoto a un equipo mediante ssh? Sí. Eso doy por su puesto que lo haces, si no todos los días, casi todos. Me refiero a abrir una sesión SSH y ver cuál es el ToS de los paquetes generados y recibidos. Un saludo. -- En la vida humana sólo unos pocos sueños se cumplen, la mayoría se roncan. --- Enrique Jardiel Poncela --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513145231.gb7...@cubo.casa
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 de May de 2015, a las 07:56:42PM +0200, Raúl Alexis Betancor Santana dijo: Es que estás cometiendo varios errores de base ... A ver. 1- En el router que te hace NAT (porque supongo que lo tienes en multipuesto y el router te hace NAT), es el propio router quien SEGÚN su politica de QoS ... cambiará los valores que envía a la WAN, esto es lo más normal del mundo. Bueno, he dicho que esa es una posibilidad y por eso pregunto. Lo que ocurre es que he hecho pruebas con cuatro sitios distintos: 1. Dos cuyos router tendría que ver si realmente modifican el byte, porque disponen de sistemas de estos de administración por web y una interfaz telnet. 2. Otro que es un VPN con IP compartida. Ahí, obviamente no controlo más allá de la propia máquina virtual. 3. Otro que es el de mi casa y tiene instalado openWRT. Aquí se fehacientemente que no hay aplicada ninguna política. El problema es que no tengo contratado con Telefónica sino con otro operador (Vodafone). Pues bien escoja el origen y el destino que sea, siempre se produce el mismo resultado. Si los ISP no hicieran ninguna modificación en el camino y todo fuera culpa de mis routers, como sé que el que lleva openwrt no hace ningún tipo de modificación, en caso de que comunicara éste con cualquiera de las máquinas que hay detrás de los otros tres, en estas máquinas vería llegar el paquete con el DSCP original. Pero eso no ocurre. 2- Los operados NO RESPETAN, los valores de QoS que tu utilices ..., no tienen porque hacerlo y de hecho, no lo hacen, ya que aplican sus propias políticas. Desde mi más completa ignorancia de los protocolos de enrutamiento que usan en sus routers. ¿Forzosamente lo tienen que hacer a través del byte ToS de la cabecera IP? Sí, ya sé que está para eso. 3- Sigue el consejo que te puse en el otro correo ... preocupate de clasificar, prioritizar y limitar LO QUE ENVIAS, lo que recibes ... no lo puedes controlar, en todo caso ... no en la eth0 ... sino en la eth1, osea ... dale la vuelta a la 'tortilla'. Eso no es cierto, lo que recibo lo puedo clasificar perfectamente, no ciertamente en la planificación ingress de eth0, sino en la salida de una interfaz virtual ifb a la que puedo redirigir los paquetes. La única limitación que hay es que no puedo hacer una clasificación stateful (pues para eso necesito netfilter) En eth1 es bastante inútil hacerlo, porque hay tráfico que se queda en el servidor y porque en mi caso hay muchas interfaces internas. Un saludo. -- Todo es vana arquitectura, porque dijo un sabio un día que a los sastres se debía la mitad de su hermosura. --- Lope de Vega -- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513183701.gb17...@cubo.casa
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 de May de 2015, a las 09:56:29PM +0200, Raúl Alexis Betancor Santana dijo: Que da igual si es tu router, o el del operador .. TU no puedes controlar por donde va a pasar ese paquete ... y entre todos los routers/switches por los que pase, UNO habrá que borrarrá los campos, es que no hay ningún RFC que diga que esos campos se tengan que respetar extremo a extremo ... y como tál NADIE los respeta. Vale. Zanjada la cuestión entonces. Paso de esos campos. TU no controlas lo que te llega a tu interfaz WAN, lo controla TU OPERADOR. Sí, lo he pillado ahora: como los paquetes me han llegado ya a la interfaz, ya no me sirve de mucho clasificarlo escrupulosamente. Es más eficiente intentar evitar que me lleguen en demasía a ella actuando sobre la salida gracias a... No lo has entendido ... los protocolos de control de flujo de TCP, De todos modos, por redundar en esto, aunque vea la eficacía de clasificar a la salida y ya está. Si a la entrada, jamás acepto más de 1Mbit/s de tráfico HTTP, precisamente por el control de flujo de TCP, el envío acabará ralentizándose también ¿no?: acepto menos, eso acabará suponiendo que reciba menos, que envíe menos paquete ACK de confirmación y, por lo tanto, que los servidore web a los que pido me acaben enviando a menor ritmo. Lo que sí puede resultar absurdo es intentar montar una planificación HTB. De hecho es el típico ejemplo de porque en la mayoría de los casos, no se puede aprovechar al 100% el ancho de banda de bajada de una ADSL/FTTH, porque sino eres capaz de enviar los ACK's de salida ... el servidor remoto irá reduciendo la tasa a la que te manda tráfico de entrada, hasta llegar a un equilibrio. Pues me interesaría poder hacer una estimación a priori de qué tráfico ACK de confirmación debo dejar salir, si quiero que me acabe llegando X tráfico de entrada. Y sobre esta estimación, pulir un poco, probado en la realidad. A ver si voy desencaminado (suponiendo que el grueso mayor del tráfico de salida es HTTP): Un paquete ACK tiene unos 60-70 bytes de longitud, creo recordar. Los paquetes de entrada, sin embargo serán bastante mayores, puesto que contienen la información que he pedido (una página, una foto, un archivo de vaya usted a saber qué. etc...). O sea, que habrá muchos que ronden los 1400 bytes y algunos que sean algo más pequeños. Estimemos que su tamaño medio es de 1300 bytes. Así pues, 65/1300 da el 5%. O sea que el tráfico de salida ACK está sobre el 5% del tráfico que recibiré. Por tanto, si tengo 10 Mb/s de ancho de banda de bajada, 500Kbit/s de tráfico ACK de confirmación podrían consumirme todo ese ancho. Así pues, tendré que asegurarme de que el tráfico de paquetes ACK sea menor para que no se llegue a ese extremo, al menos cuando haya otro tráfico que necesite hacer uso también de ese ancho de bajada. ¿Es así el cálculo, más o menos? Lás únicas reglas que tengo para el downlink .. en todo el script ... son: ## downlink # # s1ow downloads down to somewhat less than the real speed to prevent # queuing at our ISP. Tune to see how high you can set it. # ISPs tend to have *huge* queues to make sure big downloads are fast Vale, y he visto que después tienes limitado el tráfico al 70% del ancho de bajada. El hecho de que las colas de paquetes en el ISP sean grandes, ¿qué supone? ¿Mayor lantencia? ¿No acabo desaprovechando al final un 30% del ancho haciendo esto? Muchas gracias. Creo que voy aclarando conceptos.. -- La juventud es un defecto que se cura con el tiempo --- Enrique Jardiel Poncela --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513232358.ga28...@cubo.casa
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 de May de 2015, a las 03:02:21PM +, Camaleón dijo: No, no analizo los paquetes salvo que detecte algún problema. Entonces, simplemente, no puedes contestar a mi pregunta. No te lo tomes a mal: no es una respuesta desabrida. Un saludo y gracias. -- Hay dos sistemas de conseguir la felicidad: uno, hacerse el idiota; otro, serlo. --- Enrique Jardiel Poncela. -- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513154609.ga10...@cubo.casa
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 de May de 2015, a las 03:55:10PM +, Camaleón dijo: ¿Has detectado algún problema o se trata sólo de simple curiosidad? Estoy investigando la calidad de servicio y voy haciendo pruebas según voy aprendiendo. De hecho, una de las cosas para las que me interesa es para que la sesiones SSH vayan fluidas a todas horas. Cuando he ido a fijar una política para los paquetes que entran en la máquina, he pensado que sería buena idea reservar un mínimo ancho de banda de bajada para el tráfico SSH interactivo y no para el que se genera con scp (que a fin de cuentas es descargar o subir fichero y no me importa si va más o menos fluido). Pero he detectado que el tráfico, aunque sale bien del cliente, siempre llega al servidor con DSCP 0x0 cuando debería llegar con DSCP 0x4 el interactivo y con DSCP 0x2 el no interactivo. Y eso me impide distinguir uno y otro tráfico. En local todo funciona bien. Con FTP pasa lo mismo, aunque eso ya me importa menos. No, hombre, si ya te he dicho antes que no sabía si el cambio de ToS era normal o no por eso te dije que investigaras por otro lado más allá de pensar que los ISP no tienen nada mejor que hacer que alterar el tráfico SSH :-) Pero me dejaste una búsqueda en google en la que ningún enlace hablaba de lo que yo preguntaba o al menos así lo vi yo. Excepto el del foro de ubuntu que trataba de un bug del cliente ssh de openSSH que no le ponía el ToS correcto a los paquetes que generaba. Saludos. -- La virtud, como el arte, hallarse suele cerca de lo difícil [...] --- Lope de Vega --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513163424.ga12...@cubo.casa
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 de May de 2015, a las 07:52:17PM +0200, Raúl Alexis Betancor Santana dijo: Te voy a contar un truco ... PASA UN KILO de lo que te llega ... como ya te he dicho, no puedes controlar lo que te llega ... solo lo que TU mandas ... Si quieres prioritizar el tráfico interactivo ... sobre el no interactivo ... hazlo en el servidor QUE TE LO MANDA, como tráfico saliente. Eso ya pienso hacerlo, pero ¿es suficiente? (No he hecho aún pruebas reales). El caso es que ese tráfico SSH estaría compitiendo con bastantes clientes internos que están navegando y ciertas horas consumen bastante más ancho de bajada que de subida. Gracias. Un saludo. -- Todo el mundo se suicidaría si después de suicidarse se pudiera seguir viviendo. --- Enrique Jardiel Poncela --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513181749.ga17...@cubo.casa
Re: [OT] ¿Cambian los ISP el ToS?
El Wed, 13 de May de 2015, a las 04:53:26PM +, Camaleón dijo: ¿Y desde dónde/cómo has configurado esa política de los paquetes para reservar ancho de banda? ¿Router del ISP? ¿Debian (tc)? En la interfaz del servidor que lo comunica con el router de salida. En el esquema, la eth0: eth0 eth1 INTERNET ROUTER -- SERVIDOR --- RED INTERNA O sea, en una debian con tc. Con FTP pasa lo mismo, aunque eso ya me importa menos. No sé si habrás pensado en usar otro sistema para la detección de ese tipo de tráfico, porque depender del proveedor no parece muy fiable. Bueno, si el proveedor no se dedicara a tocar ese byte que es mío... No sé por qué narices tiene que tocarlo. De hecho, yo no lo toco: tiene ese valor, porque se lo asignan las aplicaciones dependiendo de la naturaleza del tráfico. Entiendo que no le preste atención y use sus propias estrategias para priorizar (de lo contrario, todos manipularíamos nuestros paquetepata asignarles la máxima prioridad). El problema es que a la entrada, el control se realiza antes de pasarle el paquete a netfilter, así que no puedo basarme en el seguimiento de la conexión (conntrack). Desgraciadamente el seguimiento no lo puedo hacer en el router (es un router de telefónica que no permite hacer muchas cosas). Tampoco voy a poner una máquina intermedia sólo para poder hacer el seguimiento, que es la alternativa que se me ocurre. Un saludo. -- Todos los hombres que no tienen nada importante que decir hablan a gritos. --- Enrique Jardiel Poncela --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513175046.ga15...@cubo.casa
[OT] ¿Cambian los ISP el ToS?
Un saludo a la lista: ¿Sabe alguno algo al respecto? Tengo un par de pequeños servidores con conexión con Telefónica (de España) y he comprobado que el tráfico SSH interactivo sale de cliente y servidor con el byte a 0x10, pero llega al destino con el byte a 0x0. Así que, o es cosa del camino o de mis router, pero a estos router no les he configurado nada en especial y me pasa entre los dos servidores entre sí, entre los servidores y mi casa y entre los servidores y un VPN virtual baratujo con IP compartida que tengo contratado para hacer pruebecillas. Muchos routers cambiando ToS me parece a mí. He dejado una pregunta en los foros de Telefónica (en el que suelen responder trabajadores de la propia compañía), pero no he obtenido respuesta. Estoy cacharreando con el QoS y si me cambian el ToS me es imposible distinguir entre la sesión de ssh y el scp, por ejemplo. -- ¿No ha de haber un espíritu valiente? ¿Siempre se ha de sentir lo que se dice? ¿Nunca se ha de decir lo que se siente? --- Francisco de Quevedo --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150512204352.ga17...@cubo.casa
Re: nombre de dominio en red interna
Ya te han respondido bien a pachas entre Camaleón (poner un DNS) y Santiago (modificar todos los ficheros /etc/hosts). Yo me decantaría por la opción de Camaleón, pero no instalando bind porque en este caso es matar moscas a cañonazos. Para esa tontería, vale con instalar dnsmasq y añadir la resolución que quieras para esa ip en el /etc/hosts de la máquina en que instales dnsmasq: 192.168.100.34 miservidorwen.lan Esa máquina la configuras para que use servidores DNS externos y los clientes para que usen tal máquina como servidor DNS: de esa forma la entrada que escribiste la compartirá con el resto; y el resto de nombres se resolverán normalmente. -- -- Hoy he reñido a un hostelero. -- ¿Por qué? ¿Cuándo? ¿Dónde? ¿Cómo? -- Porque cuando donde como sirven mal, me desespero --- Tomás de Iriarte --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505184525.ga25...@cubo.casa
Re: OT [Una de bash muy buena...]
El Sun, 26 de Apr de 2015, a las 02:43:29AM +0200, Maykel Franco dijo: Una solución con grep: $ grep -oP '(?=number:)[0-9]+(?=)'$CADENA 2705045091096 2788156539794 2748168531483 Muchas gracias a todos, me funcionó. De nada. Una sola puntualización, que se me ocurrió justamente después de mandar el mensaje. Creo que habría sido mejor solución, y un pelín más simple, esta: $ grep -oP '(?=number:)[^]*'$CADENA Así no obligamos a que el valor sean números. -- Y mis desdichas son como cerezas, que voy por una y, de una en otra asidas, vuelvo con todo un plato de tristezas. --- Tomé de Burguillos --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150426073552.ga4...@cubo.casa
Re: OT [Una de bash muy buena...]
El Sun, 26 de Apr de 2015, a las 12:26:46PM +0200, Maykel Franco dijo: Gracias José Miguel, buen apunte. Donde dices cadena le puedo meter también un fichero verdad? Sí, pero entonces la redirección se hace con un único '': $ grep 'patrón' fichero Y en el caso particular de grep, que admite que se le indique como segundo argumento el fichero del que leer: $ grep 'patrón' fichero Un saludo. -- Todo el mundo se suicidaría si después de suicidarse se pudiera seguir viviendo. --- Enrique Jardiel Poncela --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150426134207.ga19...@cubo.casa
Re: iptables SNAT,DNAT y caso extraño que no funciona
El Thu, 23 de Apr de 2015, a las 02:17:07PM +, Camaleón dijo: A eso iba... ¿te has planteado una configuración sin iptables? Si configuras los enrutados únicamente con ip podrías descartar que el problema te venga de los filtros que tienes en iptables. Digo esto porque entiendo que existen otras opciones (vlan, ip) para conseguir un entorno aislado y que M1 y M2 sólo hablen con/a través del cortafuegos. Sé que existen otras posibilidades para aislar una máquina de otra. Yo sólo estaba haciendo pruebas con este escenario y, cómo el caso C no sale, quería darle una explicación. Pura y sana curiosidad. Después de darle muchas vueltas y mirar cómo funciona también ebtables, creo que ya sé por qué falla el caso C (o al menos la explicación me parece plausible). En M1 hago un ping al cortafuegos: $ ping -c1 192.168.255.1 con el propósito de hacer en él un DNAT hacia M2. Pues bien, este es el flujo de un paquete por una máquina linux: http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg Resulta que la cadena PREROUTING de la tabla nat en la que se hace el DNAT se encuentra antes de la decisión de conmutar el paquete. Así que en el momento de tomar la decisión el paquete tiene ya la IP y la MAC de M2. Pero M2 se encuentra en el mismo puerto por el que llega el datagrama y ¿qué hace un puente cuando el destino del datagrama se encuentra en el mismo puerto por el que lo recibe? Desecharlo. Y el paquete se desecha y no hay comunicación. En el caso B, como el destino estaba en el otro puerto del puente, sí funcionaba el ping. Esta conclusión, además, concuerda con lo que observaba cuando monitorizaba eth1: el paquete llegaba de M1, pero nunca salía hacia M2. Para hacer que esto funcione hay que montar un brouter. Lo he hecho y, efectivamente, funciona. Saludos. -- Tu dulce habla, ¿en cúya oreja suena? --- Garcilaso de la Vega --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150424164205.ga15...@cubo.casa
Re: iptables SNAT,DNAT y caso extraño que no funciona
El Wed, 22 de Apr de 2015, a las 04:44:32PM +, Camaleón dijo: El Tue, 21 Apr 2015 18:31:30 +0200, José Miguel (sio2) escribió: Un saludo a la lista: He estado jugueteando con iptables y me he encontrado con un caso en el que no funciona como yo me esperaba. De hecho, me parece que no debería funcionar así, pero me gustaría que alguien opinara al respecto. (...) Es un poco lioso, pero me da la nariz que el problema está con alguna regla de iptables que además (y para el ejemplo que pones) me parece que no serían necesarias ya que si todas las máquinas están en la misma red física Las tres máquinas están en la misma red. Ahora bien, la máquina M2 sólo admite comunicaciones con el cortafuegos. Cualquier tráfico procedente de otra máquina, lo veta. De ahí que necesite las reglas de iptables, ya que la única forma que tiene M1 de acceder a los servicios de M2 es a través del cortafuegos. He usado el ping como podría haber usado cualquier servicio en M2 (incluso uno improvicado con netcat). , para asegurarte la salida por el cortafuegos con un esquema de enrutado sería suficiente (route/ip). (...) No hay enrutamiento en este supuesto: las tres máquinas están en la misma red. Pues bien si en M1 hago: $ ping -c1 192.168.255.1 Es decir, ejecutas un ping desde la máquina 1 al cortafuegos. Sí, ya he dicho que M1 no puede acceder a M2 directamente (incluso aunque estén en el mismo segmento de red), porque M2 sólo se habla con el cortafuegos: # iptables -A INPUT -p icmp ! -s 192.168.255.1 -j DROP # iptables -A OUTPUT -p icmp ! -d 192.168.255.1 -j DROP Se obtiene respuesta perfectamente en el caso A) y B), pero no en el C). En el caso C) tenemos dos interfaces de red (eth0 + eth1) configuradas como br0 ¿no? Sí... y no. En el caso A) el cortafuegos sólo tiene una interfaz de red (en la red que tratamos). Pongamos que es eth1. Funciona. En el caso B) hay interfaces de red (eth1 y eth2) en la red que son puertos de un bridge br0. La máquina M1 cae en el segmento de red con el que conecta físicamente eth1 y la máquina M2, en el segmento con el que conecta eth2. Funciona. El caso C) se configura exactamente igual que el caso B), pero en este caso, ambas máquinas (M1 y M2) caen en el mismo segmento de red: al que conecta el cortafuegos con eth1. No funciona. Dicho de otro modo B) y C) son exactamente la misma configuración en cortafuegos y máquinas, lo único que se hace es cambiar de segmento de red una de las máquinas. Como trabajo con qemu, esto consiste en apagar la máquina M2 y arrancarla con su eth0 en la misma vlan que la interfaz eth1 del cortafuegos y la interfaz eth0 de M1. De esta forma, ambas máquinas acaban cayendo en el mismo segmento de red y ambas máquinas se comunican con el cortafuegos a través del mismo puerto (eth1). Esquemáticamente: Caso B: br0(eth1,eth2) -+ M1 | eth1 | +---+ | eth2 +---+ | | -+ M2 Caso C: br0(eth1,eth2) -+ M1 M2 | eth1 | | +---+--+ | eth2 +-- A edste segmento no hay ninguna máquina conectada. | -+ ¿Tienes activado en el cortafuegos el reenvío de IP? Eso da igual: estoy conmutando, no encaminando paquetes. De todos modos, está habilitado. Hum... que el ping al cortafuegos no obtenga respuesta en la máquina 1 pero que éste (cortafuegos) sí escuche el tráfico parece indicar que los paquetes llegan pero se rechazan, quizá por alguna regla de iptables. No hay más reglas que las dos que indiqué en el anterior mensaje: # iptables -nL -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination DNAT icmp -- 0.0.0.0/00.0.0.0/0 to:192.168.255.3 Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination SNAT icmp -- 0.0.0.0/00.0.0.0/0ctstate DNAT to:192.168.255.1 Más las dos que hay en M2 para asegurarme que sólo habla con el cortafuegos. He dejado más arriba escritas cuáles son. Por supuesto, las reglas del caso B) y las del C) son exactamente las mismas. Pero, lo que más me escama, es que cuando pongo a escuchar tcpdump en la interfaz br0, el caso C), sí funciona. ¿Y eso por qué? ¿Qué más da que esté monitorizando tráfico que no lo esté haciendo? No puedo estar haciendo nada mal. De hecho, si estuviera haciendo algo mal no deberían funcionar ni B) ni C). Ni mucho menos funcionar C) cuando tcpdump minitoriza br0, pero no cuando no lo hace. Puedes añadir más verbosidad a tcpdump (-vvv) a ver si te da alguna pista. La única información que añade es el ToS de paquete y algún dato más sobre el único paquete que detecta. No parece útil en absoluto
iptables SNAT,DNAT y caso extraño que no funciona
Un saludo a la lista: He estado jugueteando con iptables y me he encontrado con un caso en el que no funciona como yo me esperaba. De hecho, me parece que no debería funcionar así, pero me gustaría que alguien opinara al respecto. El supuesto es el siguiente: Máquina 1 192.168.255.2 | Cortafuegos -+ 192.168.255.1 | Máquina 2 192.168.255.3 O sea las tres máquinas están en la misma red. La prueba consiste en enviar un ping de M1 a M2, pero pasando por el cortafuegos, de modo que M1 cree que le responde el cortafuegos y M2 que quien le hace ping es también el cortafuegos. De este supuesto he hecho tres casos distintos: Caso A) El cortafuegos escucha en la red a través de eth2. Caso B) M1 y M2 están en dos segmentos distintos de la red, que se encuentran unidos gracias al cortafuegos. En este caso, eth1 conecta con el segmento de M1 y eth2 conecta con el segmento de M2. eth1 y eth2 están dentro de una interfaz puente br0. Caso C) Como B) se monta una interfaz puente br0, pero M1 y M2 caen en el mismo segmento de RED, así que los paquetes siempre salen y entran por eth1. Para lograr que M1 y M2 crean que se está comunicando con el cortafuegos y no entre ellas, he usado SNAT y DNAT. Para el caso A): # iptables -t nat -A PREROUTING -i eth2 -p icmp \ -j DNAT --to-destination 192.168.255.3 # iptables -t nat -A POSTROUTING -o eth2 -p icmp -m conntrack --ctstate DNAT \ -j SNAT --to-source 192.168.255.1 Y para el B) y C) lo mismo pero sustituyendo eth2 por br0. Además para estar seguro de que M2 sólo es capaz de comunicarse con el cortafuegos: # iptables -A INPUT -p icmp ! -s 192.168.255.1 -j DROP # iptables -A OUTPUT -p icmp ! -d 192.168.255.1 -j DROP Pues bien si en M1 hago: $ ping -c1 192.168.255.1 Se obtiene respuesta perfectamente en el caso A) y B), pero no en el C). Pero lo más curioso del asunto, es que si en el caso C), me pongo a escuchar con tcpdump la interfaz br0 del cortafuegos a ver si saco algo en claro, śí funciona. :/ Las salidas de tcpdump en el cortafuegos son: Caso A) # tcpdump -ni eth1 icmp 18:02:24.110695 IP 192.168.255.2 192.168.255.1: ICMP echo request, etc. 18:02:24.110779 IP 192.168.255.1 192.168.255.3: ICMP echo request, etc. 18:02:24.111491 IP 192.168.255.3 192.168.255.1: ICMP echo reply, etc. 18:02:24.111510 IP 192.168.255.1 192.168.255.2: ICMP echo reply, etc. Caso B) # tcpdump -ni eth1 icmp 17:36:57.270693 IP 192.168.255.2 192.168.255.1: ICMP echo request, etc. 17:36:57.271098 IP 192.168.255.1 192.168.255.2: ICMP echo reply, etc. # tcpdump -ni eth2 icmp 17:36:40.651471 IP 192.168.255.1 192.168.255.3: ICMP echo request, etc. 17:36:40.651928 IP 192.168.255.3 192.168.255.1: ICMP echo reply, etc. Caso C) # tcpdump -ni eth1 icmp 18:27:36.902663 IP 192.168.255.2 192.168.255.1: ICMP echo request, etc. #tcpdump -ni br0 icmp 18:28:23.735113 IP 192.168.255.2 192.168.255.3: ICMP echo request, etc. 18:28:23.735171 IP 192.168.255.1 192.168.255.3: ICMP echo request, etc. 18:28:23.735536 IP 192.168.255.3 192.168.255.2: ICMP echo reply, etc. 18:28:23.735547 IP 192.168.255.1 192.168.255.2: ICMP echo reply, etc. Esta última monitorizacióm no sé cómo interpretarla. La lógica sería la del caso A. -- Harto sabe, si me sabe bien. --- Francisco de Quevedo --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150421163130.ga5...@cubo.casa
Re: OT [Una de bash muy buena...]
El Tue, 21 de Apr de 2015, a las 05:13:50PM +0200, Maykel Franco dijo:
Buenas, llevo unas 2 h intentando realizar esto pero soy incapaz...
Necesito de esta linea por ejemplo:
[{type:07,number:2705045091096},{type:01,number:2788156539794}{type:08,number:2748168531483}
Vaya por delante que eso parece json y lo podrías tratar con jshon,
que tiene paquete en debian. De todos modos:
Me gustaría sacar solo los numeros después de number: , por ejemplo, solo
sacar esto:
2705045091096
2788156539794
2748168531483
Una solución con grep:
$ grep -oP '(?=number:)[0-9]+(?=)'$CADENA
2705045091096
2788156539794
2748168531483
--
Hay dos sistemas de conseguir la felicidad: uno, hacerse
el idiota; otro, serlo.
--- Enrique Jardiel Poncela. --
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150421163813.gb5...@cubo.casa
Re: RAID para datos importantes
El Sun, 19 de Apr de 2015, a las 07:52:13PM +0200, Josu Lazkano dijo: Hola a todos, Hola. He estado leyendo un poco sobre mdadm en Debian y tengo varias dudas: 1. ¿Los discos los tengo que formatear con algun sistema de ficheros en cocncreto? ¿O simplemente creo el raid con los discos sin formatear? No, cuando crees el RAID con los dos discos tendrás a tu disposición un dispositivo de bloques (/dev/md0, posiblemente), que funciona exactamente igual que un dispositivo que representa un disco real. O sea que que puedes formatearlo exactamente igual que si se tratara de un disco. 2. ¿Como hago para que me avise si algo va mal? Nada de particular. En la configuración (/etc/mdadm/mdadm.conf) hay una directiva (MAILADDR) que indica que a qué cuenta de correo quieres que te envíe los avisos de las incidencias. Creo que su valor predeterminado es root. Así que todo se limita a que el servidor de correo sea capaz de enviar ese correo al destino que le indiques. Si ese destino es local o de la red local, no hay mucho problema. 3. Tengo opcion a reemplazar el disco de 2TB por uno de 1TB y crear un RAID5 con los 3 discos de 1TB, ¿me lo recomendais? No sé depende de qué es lo que quieras. Si lo haces tendrás 2TB en el RAID y 1TB para las películas y demás. Si no lo haces, la situación será al revés. Es la primera vez que configura un RAID por software y la verdad que me da un poco de respeto, ya que los daots que voy a guardar son importantes. Agradezco cualquier ayuda. Los datos los vas a tener que sacar a otro sitio antes (al disco de 2TB, por ejemplo) para luego montar el RAID. Así que no veo cuál es el problema, si en el proceso tendrás los datos copiados en otro sitio. Por cierto, si son realmente importantes, un RAID no sustituye a un backup almacenado físicamente en otro sitio: siempre puede producirse un percance que te escacharre a la vez los dos disco. -- Harto sabe, si me sabe bien. --- Francisco de Quevedo --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150419180636.ga27...@cubo.casa
Re: Esto esun bug del servidor DHCP, ¿no?
El Mon, 13 de Apr de 2015, a las 01:19:27PM +, Camaleón dijo: Podría ser, pero en la versión anterior de dhcpd (la que lleva Wheezy) no sucede lo mismo, es decir, que ante un mismo evento generado de la misma manera (cambio forzoso de la MAC) el servidor DHCP lo interpreta de otra forma, habría que preguntarse por qué. En realidad el fallo no tiene nada que ver con el cambio de MAC (de hecho, el comportamiento es el correcto: se envía un paquete DHCPNACK). Lo hice así, simplemente, para ahorrarme arrancar otra máquina virtual. Aunque también podría haberle borrado la memoria a dhclient para que no sugiriera nada. Si la segunda máquina no sugiere ip, también se produce el fallo: porque éste se debe únicamente a que se agota el máximo de ips que se pueden conceder a la clase (puesto con lease limit). Parece un fallo bastante gordo. Lo que no he probado es qué ocurre si la falta de disponibilidad se debe a la otra posibilidad más habitual: que se agoten las ips porque ya no queden más en el rango que se le asignó a la clase. Creo que hace cosa de un mes estuve haciendo pruebas, se me produjo esta última circunstancia y no ocurrió nada raro. De todos modos, no lo puedo asegurar y, además, de entonces ahora ha podido cambiar el paquete. Un saludo. -- ¿No ha de haber un espíritu valiente? ¿Siempre se ha de sentir lo que se dice? ¿Nunca se ha de decir lo que se siente? --- Francisco de Quevedo --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150413160312.ga3...@cubo.casa
Re: Esto esun bug del servidor DHCP, ¿no?
El Sun, 12 de Apr de 2015, a las 03:41:14PM +, Camaleón dijo: Lo que me escama es el mensaje, dice que no le puede asignar una IP determinada (192.168.255.105) no que no sea posible asignarle una cualquiera :-? Es normal por cómo hice la prueba: usando dos veces el mismo cliente, pero cambiándole entre una y otra petición la MAC. En esta circunstancias, la segunda vez el cliente sugiere al servidor que le entregue la última ip que tenía, o sea, la que recibió la primera vez. Como está ocupada (porque no se liberó), el servidor rechaza esa sugerencia (DCHPNACK) y se dispone a darle otra. Es entonces cuando actúa el lease limit 1, pero en vez de no entregar ninguna, porque ya no hay disponibles, casca. De todas formas, mira a ver si sigue en ejecución tras el segfault. El servidor muere definitivamente, no es que se quede tonto. Ya he enviado el informe de fallo. -- Parezco en mi fortuna al Manzanares, que con agua o sin ella siempre es río. --- Tomé de Burguillos --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150412181246.ga12...@cubo.casa
Re: Esto esun bug del servidor DHCP, ¿no?
El Sun, 12 de Apr de 2015, a las 01:49:35PM -0500, Frank Harbey Sanabria Florez
dijo:
El server se cuelga?,
Se muere. El proceso deja de existir.
verificaste que la MAC que duplicaste sea una
MAC Original (Establecida por la IEEE)?, la configuracion de
Seguridad ante suplantaciones del DHCP esta habilitada?
No, no lo he verificado, pero no creo que tenga mucha importancia,
porque hice varias pruebas y la misma MAC con la que casca el servidor
en la segunda petición en algunas de las pruebas, la usé como MAC en la
primera petición y el servidor le sirvió ip sin problemas.
Las MAC que me inventaba eran 00:11:22:33:44:5X. Siempre uso esas para
pruebas y nunca tengo problemas.
Además, en wheezy funciona perfectamente.
Como tienes la configuracion en el dhcpd.conf y en el defaults?,
En /etc/default/isc-dhcp-server no cambié nada y la configuración de
dhcpd.conf la escribí en el mensaje con que abrí el hilo. Hay
efectivamente un error del que luego me di cuenta, pero que no afecta:
subnet 192.168.255.0 netmask 255.255.255.0 {
^^^
[...]
option broadcast-address 192.168.1.255;
^
}
De hecho, lo modifiqué y siguió dando los problemas.
--
Hay dos sistemas de conseguir la felicidad: uno, hacerse
el idiota; otro, serlo.
--- Enrique Jardiel Poncela. --
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150412201640.ga17...@cubo.casa
Re: [OT] grub: error: cant't find command linux
El Sun, 12 de Apr de 2015, a las 03:52:45PM +, Camaleón dijo: En cualquier caso, ¿dónde instalas GRUB, en el MBR o en la partición / boot/grub? En /boot/grub se instalan los módulos, la configuración menu.cfg y demás ficheros de grub. El sector de arranque de esa partición no tiene nada de especial. El programa principal (creo que es core.img) se instala dependiendo de si estamos con particiones DOS o con particiones GPT. En el primer caso se instala entre el MBR y el comienzo de la primera partición; y en el MBR se queda el código indispensable para que vaya a leer allí. En el segundo caso se instala en una partición de tipo BOOT BIOS que hace el papel del espacio entre el MBR y la primera partición. Lo que no sé muy bien es qué ocurre cuando se elige instalar el grub en una partición DOS particular. Supongo que el código del MBR remitirá al sector de arranque de esa partición y éste al espacio entre el MBR y la primera partición. A mí no me gusta tener un único GRUB porque te arriesgas a que no sea compatible con otros sistemas linux/unix (recordemos que hay distribuciones que lo modifican) Esto no lo sé. ¿Hay distribuciones que no arrancan con un grub genérico? o sencillamente te arriesgas a que por el motivo que sea te falle y no tengas otro para arrancar los sistemas operativos que tengas. Pero en este caso da igual que tengas unos o muchos: si te falla con el que deberías arrancar también vas a tener que montar el taco. En cuanto a tenerlo en su propia partición antes era la opción predeterminada y lo recomendado debido a que en algunos sistemas de archivos (p. ej., ReiserFS) tenía problemas pero ahora me parece que no y los instaladores lo ponen bajo partición raíz (/). El problema de eso es que, inopinadamente, puedes decidir cargarte uno de los sistemas operativos y que resulte que ese sea el que contenía el grub activo. Si tienes grub por separado, es más difícil que te lo cargues o por ignorancia o por descuido. ¡La de usuarios de windows que instalan linux para probar, luego lo borran y dejan de poder arrancar el sistema porque grub necesita los ficheros de /boot/grub y se los acaba de cargar al destruir la partición del linux! Cuando hay varios sistemas operativos en un disco yo prefiero mantener cada GRUB con su distribución y el MBR limpio pero como digo, esto es como las particiones de disco duro, cada uno tiene su sistema :-) Sí, imagino que sí. Un saludo. -- -¿Quién le dice a v.m. que no se pueda hacer? Hacerse puede, que ser imposible es otra cosa. --- Francisco de Quevedo --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150412183635.gb12...@cubo.casa
Re: Esto esun bug del servidor DHCP, ¿no?
El Sat, 11 de Apr de 2015, a las 10:39:16PM +0200, Manolo Díaz dijo: Eso parece, que es un fallo en toda regla. No sé qué debería haber hecho el servidor DHCP, pero desde luego cascar no. He hecho la misma prueba con wheezy y la configuración funciona perfectamente: #v+ DHCPDISCOVER from 00:11:22:33:44:55 via eth1: no available billing: lease limit reached in all matching classes #v- El cliente se queda sin ip y el servidor sigue funcionando. Voy a ver cómo se envía un informe de fallo. Gracias. -- -¿Quién le dice a v.m. que no se pueda hacer? Hacerse puede, que ser imposible es otra cosa. --- Francisco de Quevedo --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150411213704.ga20...@cubo.casa
Esto esun bug del servidor DHCP, ¿no?
Un saludo a la lista:
Tengo una configuración de prueba muy sencilla en el servidor ISC de
jessie:
#v+
ddns-update-style none;
default-lease-time 18000;
max-lease-time 18000;
class foo {
match if 1 = 1;
lease limit 1;
}
subnet 192.168.255.0 netmask 255.255.255.0 {
option domain-name-servers 192.168.255.1;
option domain-name smr1.iescdl.es;
option routers 192.168.255.1;
option broadcast-address 192.168.1.255;
range 192.168.255.100 192.168.255.150;
}
#v-
O sea que hay una clase de máquinas que como máximo recibirán una ip.
Con esto he tomado un cliente y le he hecho que pida ip:
#v+
Apr 11 22:08:25 zipi dhcpd: DHCPREQUEST for 192.168.255.105 from
00:11:22:33:44:50 via eth1
Apr 11 22:08:25 zipi dhcpd: DHCPACK on 192.168.255.105 to 00:11:22:33:44:50
(perico) via eth1
#v-
Como es de esperar, ha recibido su ip. A continuación he cogido ese
mismo cliente, lo he desconfigurado sin que se enterara el servidor
(dhclient -x), le he cambiado la MAC y he vuelto a pedir ip. Se supone
que es la segunda ip y que el cliente no debería recibir ninguna. Lo que
ocurre es esto:
#v+
Apr 11 22:10:56 zipi dhcpd: DHCPREQUEST for 192.168.255.105 from
00:11:22:33:44:51 via eth1: lease 192.168.255.105 unavailable.
Apr 11 22:10:56 zipi dhcpd: DHCPNAK on 192.168.255.105 to 00:11:22:33:44:51 via
eth1
Apr 11 22:10:56 zipi kernel: [ 588.513633] dhcpd[1253]: segfault at 30 ip
7f2548edd333 sp 7ffc2f270110 error 4 in dhcpd[7f2548ec6000+b3000]
#v-
El servidor parece como que le intentara dar la misma ip, aunque la
máquina es otra y la ip sigue ocupada, después casca.
Gracias de antemano.
--
a ch'in amor s'invecchia, oltr'ogni pena
si convengono i ceppi e la catena.
--- Ludovico Ariosto ---
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150411202656.ga16...@cubo.casa
Re: [OT] grub: error: cant't find command linux
El Sat, 11 de Apr de 2015, a las 01:24:23PM +, Camaleón dijo: De hecho, cuando hay varios sistemas operativos en un mismo disco duro prefiero seguir uno de estos dos esquemas para el cargador de arranque: [...] Vaya por delante que no sé muy bien de qué va EFI, así que no sé si es aplicable lo que voy a decir: yo sólo he instalado arranques normales con particiones MBR ó GPT. ¿La mejor solución no es hacer una partición cómun para montar /boot/grub común a todos los sistemas linux que haya instalados? Los núcleos de los distintos linuces siguen por separado y el grub que estará en funcionamiento siempre será el último que se haya actualizado/instalado sea el linux que sea. Lo único que se me ocurre que pueda ocurrir es que una actualización de grub te dé problemas, porque el sistema detecte que los checksum de los archivos que va a reemplazar no se corresponden con los que debería haber, como consecuencia de que no esté reemplazando su grub, sino el grub de otro linux. Pero me parece que estas comprobaciones de checksum sólo se hacen al instalar y no al desinstalar. -- La virtud, como el arte, hallarse suele cerca de lo difícil [...] --- Lope de Vega --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150411175510.ga11...@cubo.casa
Re: Duda sobre policy-based routing.
El Tue, 31 de Mar de 2015, a las 01:56:29PM +, Camaleón dijo: 0: from all lookup local 10: from all lookup main 249:from 172.16.0.2 lookup TABLA1 250:from 172.17.0.2 lookup TABLA2 999:from 192.168.0.0/24 lookup TABLA1 1000: from 192.168.1.0/24 lookup TABLA2 32767: from all lookup default Esta tabla tuya no la pillo, la del documento que enlazas sí tiene lógica. Sí, al final he hecho un solución parecida a la expuesta en LARTC que toma del documento enlazado la idea de que la tabla main se revise al principio. No sé si hay algo que sobra o que dejaría de funcionar en algún caso especial (por ejemplo, cuando marcara tráfico para que saliera por una interfaz concreta). Se parte de esto (pongo otra vez el esquema): +---+ INTERNET -- 172.16.0.1 172.16.0.2 (eth0) --+ +--- 192.168.0.1 (eth2) INTERNET -- 172.17.0.1 172.17.0.2 (eth1) --+ +--- 192.168.1.1 (eth3) +---+ Y se quiere hacer que el tráfico hacia internet procedente de la red 192.168.0.1 siempre salga por eth0 y el procedente de la red 192.168.1.1 por eth1. La política de rutas es la que he puesto en el otro mensaje y en este se ve comentada. Las reglas de cada cada tabla son las siguientes: + local: Las que ponga el núcleo de linux (no toco nada) + main: Sólo las entradas de las redes directamente conectadas. O sea: #v+ $ ip route show 172.16.0.0/16 dev eth0 proto kernel scope link src 172.16.0.2 172.17.0.0/16 dev eth1 proto kernel scope link src 172.17.0.2 192.168.0.0/24 dev eth2 proto kernel scope link src 192.168.0.1 192.168.1.0/24 dev eth3 proto kernel scope link src 192.168.1.1 #v- Al no haber ninguna indicación sobre cómo se va a otras redes, se seguiría comprobando la política 249, porque throw default es una entrada implícita. + TABLA1: Hay una única entrada que dice que se sale a internet por 172.16.0.1: #v+ # ip route show table TABLA1 default via 172.16.0.1 dev eth0 #v- + TABLA2: Hay una única entrada que dice que se sale a internet por 172.17.0.1: #v+ # ip route show table TABLA2 default via 172.17.0.1 dev eth1 #v- + default: Hay una única entrada que dice por dónde se sale a internet. Al ser revisada en la última regla, sólo saldrá por aquí el tráfico que no haya sido encaminado por alguna regla anterior. Supongamos que balanceamos entre eth0 y eth1: #v+ # ip route show table default default nexthop via 172.16.0.1 dev eth0 weight 1 nexthop via 172.17.0.1 dev eth1 weight 1 #v- Visto esto entiendo que si llega tráfico procedente del exterior a la interfaz 172.16.0.2, la respuesta del servidor siempre será por esta interfaz gracias a la regla 249, ya que como ip de origen de ese paquete de respuesta, se toma la ip de destino del paquete al que se responde. Idéntico razonamiento se puede hacer con la interfaz eth1 y la regla 250. Por tanto, estas dos reglas aseguran que siempre se responde por la interfaz por la que se recibe tráfico. Obviamente, para que esto ocurra así, la ip de origen ya debe estar fijada en el paquete antes de que se empiecen a comprobar las reglas. Ahora bien, si es el servidor el que origina tráfico (p. e. hace una consulta DNS para resolver un nombre), entonces a priori no hay ip de origen: esta se establecerá dependiendo de por qué interfaz salga el paquete. Así llegamos a la última regla y la tabla default dice que se sale una vez por eth0 y la siguiente por eth1. Pero para que esto sea así, la ip de origen no debe estar fijada al comprobarse las reglas, sino fijarse como consecuencia de ellas. Querría saber si esto es así o no, es decir, si cuando se responde se establece la ip de origen antes de cualquier decisión de encaminamiento; pero, sin embargo, cuando se inicia una comunicación la ip de origen se establece como consecuencia de la decisión de encaminamiento: como debe salir por esta interfaz según las reglas de encaminamiento, le pongo la ip de esta interfaz. He hecho pruebas con el comando ping y la configuración que he puesto parece funcionar: si se entra por eth0, se sale por eth0; si se entra por eth1, se sale por eth1; y, si se hace ping desde el propio servidor, hacia afuera, una vez se sale por eth0 y otra vez por eth1. No sé si he logrado explicarlo todo bien. Un saludo. -- Hay dos sistemas de conseguir la felicidad: uno, hacerse el idiota; otro, serlo. --- Enrique Jardiel Poncela. -- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150401112843.ga12...@cubo.casa
Duda sobre policy-based routing.
Un saludo a la lista: Tengo una duda acerca de cómo establece una máquina linux la ip de origen de los paquetes que genera y cómo escoge la interfaz de salida. Obviamente me estoy refiriendo al caso de que tengamos varias interfaces. Supongamos el siguiente caso: ++ -- eth0 --+ ROUTER +--eth2-- -- eth1 --+ LINUX +--eth3-- ++ O sea, hay cuatro interfaces eth0 (172.16.0.2), eth1 (172.17.0.2). eth2 (192.168.0.1) y eth4 (192.168.1.1). Supongamos además que en 172.16.0.1 y 172.17.0.1 hay sendos routers que permiten salir a internet, y que eth2 y eth3 conectan con redes internas. La intención es que la red conectada a eth2 salga por 172.16.0.1 y la red conectada a eth1 salga por 172.17.0.1. Todo esto lo tengo más o menos estudiado y sé resolverlo, pero me asalta una duda. En vez de seguir el LARC, he tomado como guía este documento: http://www.cyber.com.au/~twb/doc/dual-uplink.txt que me parece que da una solución más limpita. De todos modos, esto no es importante, porque mi duda está en algo que hacen ambos documentos. Es la siguiente. Llego a la siguiente política de rutas: 0: from all lookup local 10: from all lookup main 249:from 172.16.0.2 lookup TABLA1 250:from 172.17.0.2 lookup TABLA2 999:from 192.168.0.0/24 lookup TABLA1 1000: from 192.168.1.0/24 lookup TABLA2 32767: from all lookup default En main sólo están las entradas correspondientes a las redes directamente conectadas, en TABLA1 una entrada que indica que la puerta predeterminada es 172.16.0.1, en TABLA2 una entrada que indica que la puerta predeterminada es 172.17.0.1 y en default una entrada que indica que la puerta predeterminada es 172.16.0.1 (o 172.17.0.1, dependiendo de por dónde quiera que salga el tráfico que origina mi máquina). La pregunta es, ¿para qué están exactamente la política 249 y 250? Sospecho que sirven para responder por la misma interfaz a comunicaciones que se han establecido por eth0 y eth1, es decir, si recibí una comunicación por eth0, respondo por eth0; y si la recibí por eth1, respondo por eth1. Y esto me lleva a pensar que, cuando una aplicación de mi máquina inicia una comunicación con el exterior, no se establece la dirección de origen (172.16.0.2 ó 172.17.0.2), hasta que no se ha decidido por qué interfaz va a salir. En el ejemplo que he puesto, esto viene determinado por la tabla default y como ahí indiqué que 172.16.0.1 era la puerta de enlace, se sale por eth0 y la ip de origen es 172.22.0.2. En cambio, cuando una aplicación responde a una comunicación externa lo que hace es copiar como ip de origen la ip de destino del paquete que recibió. De ahí que tengan utilidad las reglas 249 y 250. ¿Es esto así? Si no lo es, ¿cómo se trabaja exactamente? Gracias de antemano. -- Harto sabe, si me sabe bien. --- Francisco de Quevedo --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150330170215.ga6...@cubo.casa
Re: ifupdown en jessie, iproute2 e interfaces bridge
El Wed, 25 de Mar de 2015, a las 02:36:09PM +, Camaleón dijo: lo ejecuta ifupdown él solito, sin doparse con scripts externos, en cuanto ve que una interfaz se llama XXX.NUMERO. Es lo mismo :-) No, no es lo mismo. Bueno, no es lo mismo lo que yo digo. Lo que tú dices sí es lo mismo, pero es que *estamos hablando de aspectos totalmente diferentes*. Un script puede ser una simple línea que ejecute un comando (ip) o ser más elaborado (brtcl) pero en ambos casos se pretende la misma función: crear una interfaz puente o crear una vlan que se pueda gestionar a través de ifupdown, N-M o cualquier otro sistema encargado de la gestión de la red. Sí, pero no es a eso a lo que yo me refiero. Vuelvo otra vez a explicarlo, porque ya me he propuesto que me acabes entendiendo. Que la gestión al final se reduce a que ifupdown ejecute los comandos que yo mismo podría ejecutar a mano con iproute2, brctl, vconfig, openvpn, tunctl, dhclient o la herramienta que sea, no es algo que yo desmienta en ningún momento: lo tengo claro y lo tenía claro antes de iniciar el hilo. Eso es machaconamente en lo que tú insistes, pero es que no hace falta que insistas en ello, porque yo lo sé. La diferencia a la que yo me refiero está en el cómo lo hace ifupdown: a) Algunas configuraciones simples (normalmente las que no requieren crear ninguna interfaz) iface eth0 inet static address 192,.168.1.10 por supuesto que necesitan por debajo que ifupdown ejecute comandos (ip en este caso particular), pero no requieren que se le dicte a ifupdown cuáles son, porque él ya los sabe: la forma de gestionar esta declaración para eth0 ya está implementada en el core de la herramienta. O dicho de otro modo, si me paseo por los directorios /etc/network/if-*.d/, no veré ningún script que le diga a ifupdown cómo tiene que configurar esto. b) Otras configuraciones más complejas (normalmente las que requieren crear antes la interfaz) como: iface tun0 inet manual openvpn hostremoto Sí que requieren que se le dicte a ifupdown cómo manejar esa opción de openvpn hostremoto y, de hecho, si miro dentro de if-up.d y de if-down.d veré dos scripts llamados ambos openvpn que se instalan junto al paquete homónimo. Pues bien, si analizamos el caso de gestionar una interfaz vlan, resulta que hasta hace dos o tres años, nos encontrábamos en el caso b) e ifupdown requería de scripts externos (if-pre-up.d/vlan e if-post-down.d/vlan) que se instalaban con el paquete vlan, porque de hecho esos scripts usan el comando vconfig que se encuentra en dicho paquete. Ahora bien, eso cambió hace un tiempo y ahora ifupdown es capaz de gestionar esas interfaces sin requerir ningún script externo. Como, además, usa iproute2 que es una dependencia suya, no es necesario instalar ningún paquete adicional. Resumiendo: 1. Modo antiguo: requiere scripts externos que usan la opción vlan_raw_device (caso b) iface eth0.10 inet static address 192.168.10.1 vlan_raw_device eth0 2. Modo moderno: no requiere nada adicional y la funcionalidad está en el core de ifupdown (caso a) iface eth0.10 inet static address 192.168.10.1 Expuesto esto, mi pregunta original fue: la gestión de una interfaz bridge con ifupdown, sigue requiriendo la instalación de bridge-utils y los scripts que instala (caso b) o ya no requiere ningún script adicional y usa iproute2 (caso a) tal como pasa con las vlan? En el segundo caso, ¿cuál es su sintaxis? Motivo de la pregunta: no encuentro nada en internet, pero es que me costó mucho encontrar la solución a) para vlan y fue por casualidad. La mayor parte de la documentación que encuentro sobre debian al respecto no me parece fiable por obsoleta. Espero haberme explicado con claridad. Si no lo he hecho, no puedo hacerlo mejor y doy por cerrado el hilo. Gracias por tu tiempo. -- Parezco en mi fortuna al Manzanares, que con agua o sin ella siempre es río. --- Tomé de Burguillos --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150326072805.ga3...@cubo.casa
Re: ifupdown en jessie, iproute2 e interfaces bridge
El Tue, 24 de Mar de 2015, a las 02:25:44PM +, Camaleón dijo: No, me refiero a cómo crear puentes usando ifupdown, o sea, escribiendo la configuración en el fichero interfaces. Sobre cómo usar directamente brtcl ya sé que puedo recurrir a cualquier página que trate los bridges con linux. No puedes crear puentes usando ifupdown, puedes gestionarlos. Los puentes los generan las herramientas iproute2 o brctl. Quiero zanjar un poco esto, porque a veces acabamos discutiendo en círculos o eso me parece a mí. Por crear con ifupdown me refiero a que yo escribo esto: iface eth0.10 inet static address 192.168.10.1 Y automágicamente ifupdown llama a iproute2 y se carga de todas las entrañas del asunto: en este caso llama primero a iproute2 para crear la interfaz (que como no es física no existe en un principio) y luego otra vez a iproute2 para configurarla como si se tratara de una interfaz física trivial. No hay scripts externos adicionales, cómo si los había antiguamente cuando era necesario instalar el paquete vlan que metía esos scripts en los directorios correspondientes para que ifupdown hiciera uso de vconfig. Por tanto, al decir crear con ifupdown, me refería a manejar estas interfaces en el core y sin scripts externos adicionales. Siento haber sido poco preciso con el término. Mi pregunta en este hilo era sobre la situación de la declaración de los puentes en el fichero interfaces: si ifupdown las podía gestionar internamente con iproute2 (como ya pasa con las vlan) o si seguía requiriendo la instalación de bridge-utils y los scripts externos que con este paquete se incluyen (o bien ingeniártelas tú escribiendo scripts externos que usen iproute2). No puedo ponerme a probar a locas si se puede sin scripts externos, porque si efectivamente hay una forma, tengo que saber cuál es la sintaxis de la declaración. Ciertamente no había encontrado por internet nada al respecto ni tampoco en el manual, pero es que en el manual del fichero interfaces no pone muy claro que ya se puedan declarar ya interfaces vlan sin necesidad de scripts externos y en todos los tutoriales de internet (que pude llegar a leer) siguen explicando el método antiguo. La pista me la dio un mensaje en la lista de bugs de debian. Nada más. Espero haberme explicado claramente en esta ocasión. Saludos y gracias. -- Mira que la mejor parte de España, pudiendo Casta, se llamó Castilla. --- Tomé de Burguillos --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150324182702.ga4...@cubo.casa
Re: ifupdown en jessie, iproute2 e interfaces bridge
El Tue, 24 de Mar de 2015, a las 06:37:12PM +, Camaleón dijo: Como te he ido diciendo a lo largo del hilo, eso mágicamente no creo que funcione. Hasta bridge-utils necesita tirar de los scripts (que te genera al instalar el paquete) para detener o reiniciar los puentes que se hayan creado con brtcl. Eso lo tengo claro, Camaleón. Pero el caso es que para crear interfaces vlan no se necesita ya ningún script en if-pre-up.d. El comando necesario, previo a la configuración de la interfaz, que crea la interfaz vlan, o sea, uno parecido a este: ip link add link eth0 name eth0.10 type vlan id 10 lo ejecuta ifupdown él solito, sin doparse con scripts externos, en cuanto ve que una interfaz se llama XXX.NUMERO. Por lo tanto, si quieres hacer lo mismo con iproute2 tienes que crear manualmente esos scripts para que ifupdown pueda gestionar las interfaces puente. No veo cuál es la consecuencia lógica que te lleva a tal conclusión. Si los desarrolladores de ifupdown hubieran hecho con las interfaces puente lo que han hacho con las interfaces vlan, entonces el comando: ip link add name br0 type bridge también se podría ejecutar automáticamente antes de configurar la interfaz con que sólo hubiera algún modo de que ifupdown supiera que cuando declaras br0 en el fichero interfaces, quieres que sea una interfaz bridge. ¿Que los puentes tienen una casuística distinta que desaconseja o impide hacer esto o que simplemente no se ha implementado? Pues a lo mejor. Pero la razón no es que como hay que crear la interfaz antes, tiene que haber un script externo que la cree, que es lo que entiendo que vienes a argumentar. Y no es la razón, porque las interfaces vlan, se crean sin necesidad de script. Saludos. -- Vine a desembuchar y desembucho. --- Muñoz Seca --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150324203358.ga9...@cubo.casa
Re: ifupdown en jessie, iproute2 e interfaces bridge
El Sat, 21 de Mar de 2015, a las 09:10:14PM +, Camaleón dijo: Ya. y para crear una vlan tienes que usar vconfig o iproute2 y, sin embargo, ifupdown se las avía (a través de iproute2) desde hace un tiempo para crearlas. En este caso, no creo que esa lógica funcione. Tú lo has dicho: a través de iproute2 ;-) Bueno, algo tiene que acabar usando de forma interna, ¿no? El caso es que para tratar las vlan ifupdown no necesita instalar vconfig (se basta con iproute2), pero para tratar bridges, sí se necesita bridge-utils a pesar de que iproute2 ya los soporta. O eso parece. Mi pregunta iba dirigida a sí había alguna sintaxis nueva que yo no había logrado encontrar que prescindiera de bridge-utils y de scripts en los directorios if-up.d, etc. Simplemente eso. Y la razón de que preguntara se debía a que a veces no sé muy bien si estoy leyendo lo último sobre debian o no. ¿Que los usuarios de debian tiene parte de culpa porque no documentan tan bien como los de archlinux? Bien puede ser: no entro a valorar eso. Tan sólo he dicho que me causa envidia sana la excelente documentación de archlinux. Desgraciadamente en este caso, la información es sobre una herramienta de debian y sólo puedo recurrir a debian (o a alguna de sus derivadas). Si te refieres a las bridge-utils están disponibles en varias distribuciones. No, me refiero a cómo crear puentes usando ifupdown, o sea, escribiendo la configuración en el fichero interfaces. Sobre cómo usar directamente brtcl ya sé que puedo recurrir a cualquier página que trate los bridges con linux. Al final, me he hecho unos scripts propios que usan iproute2: así puedo crear también switches vlan (brtcl no los soporta). Saludos, Saludos y gracias. -- Femmina è cosa mobil per natura. --- Francisco Petrarca --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150323194329.ga4...@cubo.casa
Re: ifupdown en jessie, iproute2 e interfaces bridge
Así que mi pregunta es si con las interfaces bridge se ha hecho algo parecido o hay que seguir instalando forzosamente bridge-utils. Pues nada mejor que probarlo y nos cuentas si funciona :-) Ya: el problema es que si la hay, no sé cuál es. Después de mirar mucho me inclino a pensar que no, porque con iproute2 no se puede hacer cosas como habilitar el stp para el puente (o al menos así lo he entendido yo). Tampoco he leído en ningún sitio que brtcl esté obsoleto o se desaconseje. Una cosa que me pasa con debian es que a veces no sé si estoy leyendo información desactualizada o no. Me refiero a documentación del propio sitio de debian. Aquí, por ejemplo: https://wiki.debian.org/es/NetworkConfiguration Hablan del vlan-raw-device para configurar las VLAN. Es cierto que citan etch y lenny, pero es que no se habla de las más modernas. Yo me enteré de que se podía hacer sin vconfig porque me topé con un mensaje en la lista de bugs de debian. No es problema de la traducción porque la versión inglesa dice lo mismo. En cuestión de documentación, distribuciones como archlinux están inifinitamente mejor. Un saludo. -- Como todo al fin se sabe yo he sabido la verdad. --- Muñoz Seca --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150321164515.ga3...@cubo.casa
Re: ifupdown en jessie, iproute2 e interfaces bridge
El Sat, 21 de Mar de 2015, a las 05:28:28PM +, Camaleón dijo: Como te he dicho antes, creo que no es posible por la simple lógica de el archivo /etc/network/interfaces trabaja con interfaces de red que existen en el sistema y que se han generado por los drivers/módulos del kernel y para crear un puente (br0) tienes que o bien usar el paquete de utilidades (bridge-utils) o a través de iproute2 (o el antiguo route), y no hay más Ya. y para crear una vlan tienes que usar vconfig o iproute2 y, sin embargo, ifupdown se las avía (a través de iproute2) desde hace un tiempo para crearlas. En este caso, no creo que esa lógica funcione. https://wiki.debian.org/es/NetworkConfiguration Eso es la Wiki (generada por usuarios), Bueno, la documentación de archlinux (que he citado como distribución que en este aspecto es envidiable) también es una wiki. la documentación oficial está en otra parte: Chapter 5. Network setup https://www.debian.org/doc/manuals/debian-reference/ch05.en.html También la vi, pero es que en esa documentación jamás aparece la palabra bridge (o vlan), así que de poco sirve para el caso que nos ocupa. Pero eso pasa en linux en general, por desgracia la documentación es un problema endémico. Sí, pero desgraciadamente pasa más con debian que con otras distribuciones. En cuestión de documentación, distribuciones como archlinux están inifinitamente mejor. Yo no diría tanto, aunque cierto es que tiene artículos más actualizados y con ejemplos y casos prácticos que suelen venir muy bien para el día a día. Aún así, la documentación oficial de Debian es realmente buena y completa. Pues no sé cómo será, pero un gran porcentaje de las veces que busco información sobre algo, acabo en la wiki de archlinux leyendo un artículo completo y práctico. Desgraciadamente en este caso, la información es sobre una herramienta de debian y sólo puedo recurrir a debian (o a alguna de sus derivadas). Saludos, Un saludo. -- Sabed que menda es don Mendo. --- Muñoz Seca --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150321193128.ga10...@cubo.casa
Re: ifupdown en jessie, iproute2 e interfaces bridge
El Fri, 20 de Mar de 2015, a las 06:29:02PM +, Camaleón dijo: Los puentes los gestiona un módulo del kernel que obviamente debe estar cargado para que funcionen pero la gestión/configuración de los puentes se lleva a cabo a través de herramientas de usuario y bien pueden ser las dos que citas, bridge-utils e iproute2. ¿Ventajas de bridge-utils? Pues que está todo premontado, comandos, archivos de configuración, etc... es decir, no hay que hacer casi nada a mano. Al fin y al cabo, si miramos el contenido del paquete¹ vemos que contiene una serie de scripts (if-post, if-pre...) y un binario, poco más. ¿Puedes tirar de iproute2 desde /etc/network/interfaces? No directamente sino a través de los scripts. Sí, Camaleón, todo esto lo sé. Pero resulta que sin instalar vlan, ifupdown es capaz de gestionar interfaces vlan (y si se mira en if-pre-up.d, etc no hay ningún script para tal). Tampoco tienes tú que declarar los script de activación y desactivación de la interfaz. Esto: #v+ iface eth0.1 inet static address 192.168.255.1 #v- Hace que ifupdown configure una subinterfaz de eth0 en vlan 1, sin que en el sistema se haya instalado el paquete vlan (que contiene vconfig) y sin que haya ningún script en if-pre-up.d ni if-post-down.d. La única limitación es que los nombres de la interfaces vlan deben tener ese aspecto y no pueden ser vlan1 como sí pueden ser cuando ifupdown utiliza vconfig (a través de un script en if-pre-up.d) Así que mi pregunta es si con las interfaces bridge se ha hecho algo parecido o hay que seguir instalando forzosamente bridge-utils. Gracias. Un saludo. -- Los grandes hombres solemos ser modestos. --- Juan de Mairena -- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150320185048.ga8...@cubo.casa
ifupdown en jessie, iproute2 e interfaces bridge
Un saludo a la lista: Tengo una duda sobre la creación de interfaces bridge en jessie a raíz de haber estado mirando las interfaces vlan. Resulta que, dado que iproute2 es capaz de crear interfaces vlan, el paquete vlan se ha declarado obsoleto y (no sé desde cuándo) se pueden crear directamente interfaces en /etc/network/interfaces sin tener que tener instalado el comando vconfig. Ahora bien, iproute2 también es capaz de crear interfaces bridge y me asalta la duda de si hay en jessie alguna manera[1] de declarar una interfaz bridge en /etc/network/interfaces sin tener instalado bridge-utils. Miro y remiro, pero sólo veo tutoriales que piden instalar bridge-utils. Lo que ocurre es que si miro y remiro cómo se crean interfaces vlan no hago más que ver la explicación que necesita vconfig; y me asaltan las dudas. En el manual del fichero interfaces indica esto: *For compatibility with bridge-utils package*, if bridge_ports option is specified, VLAN interface configuration is not performed. Es la única referencia que veo. Y no sé si entender que sí es necesario el paquete bridge-utils. Haciendo esto: #v+ iface br0 inet static address 192.168.255.1 bridge_ports eth1 eth2 #v- Consigo esto: # if up br0 Cannot find device br0 Failed to bring up br0. [1] sé que existe, en cualquier caso, la forma un poco enrevesada de usar a pelo el comando ip en pre-up y post-down para crear y destruir la interfaz bridge. Muchas gracias. -- ¿No ha de haber un espíritu valiente? ¿Siempre se ha de sentir lo que se dice? ¿Nunca se ha de decir lo que se siente? --- Francisco de Quevedo --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150320173122.ga4...@cubo.casa
Una de regex: imprimir primera ocurrencia
Un saludo a la lista:
Supongamos que tenemos una cadena (de una sóla línea) en la que se
pueden encontrar muchas direcciones mac, pero me interesa imprimir sólo
la primera de ellas. ¿Cuál creéis es la forma más eficiente de hacerlo?
Se me ocurren varias, pero no sé muy bien cuál usar. Por ejemplo, esta
me parece poco eficiente:
$ echo $LINEA | grep -oP '(?:[\da-f]{1,2}:){5}[\da-f]{1,2}' | head -1
Porque implica revisar toda la cadena, extraer todas las MAC y luego
quedarse con la primera que se encontró. Además se llama a dos comandos
independientes: grep y head.
Esta:
$ perl -e ''$LINEA' =~ /((?:[\da-f]{1,2}:){5}[\da-f]{1,2})/ ; print $1'
usa perl, pero no sé si perl será pesado de cargar, ni tampoco sé muy
bien cómo actua: si deja de analizar la línea al encontrar la ocurrencia
o no si lo hace. Imagino que a poco que esté bien pensado parará.
Muchas gracias de antemano.
--
e non l'arbitrio de femina lieve,
che sempre inchina a quel che men far deve.
--- Ludovico Ariosto ---
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150313162001.ga8...@cubo.casa
Re: fail2ban: varias acciones en un mismo jail.
El Thu, 12 de Mar de 2015, a las 03:37:23PM +, Camaleón dijo: [...] ¿Será por el formato (indentado)? :-? No, no es por eso. Actions Each jail can be configured with only a single filter, but may have multiple actions. By default, the name of a action is the action filename, and in the case of Python actions, the .py file extension is stripped. Where multiple of the same action are to be used, the actname option can be assigned to the action to avoid duplication e.g.: [ssh-iptables-ipset] enabled = true action = smtp.py[dest=ch...@example.com, actname=smtp-chris] smtp.py[dest=sa...@example.com, actname=smtp-sally] *** No me sonaba nada eso de actname y he visto que eso que dices es para una versión posteriori: en el manual de jessie no sale. Tomando, de todos modos, esto como referencia he visto que: action = iptables[name=SSH, port=ssh, protocol=tcp, chain=INPUT] iptables[name=SSH2, port=ssh, protocol=tcp, chain=FORWARD] no funciona. Pero: action = iptables[name=SSH, port=ssh, protocol=tcp, chain=INPUT] iptables-multiport[name=SSH2, port=ssh, protocol=tcp, chain=FORWARD] Sí lo hace. Mala cosa, porque yo quería usar la misma acción. Al final me tocará hacer dos jail distintos. Muchas gracias. -- Vine a desembuchar y desembucho. --- Muñoz Seca --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150312162952.ga8...@cubo.casa
Re: fail2ban: varias acciones en un mismo jail.
El Thu, 12 de Mar de 2015, a las 04:44:10PM +, Camaleón dijo: ¿Has probado con el truco del almendruco? Es decir, si aparentemente la versión que tienes fail2ban no permite dos comandos iguales (parece que sólo acepta la última instrucción que ejecuta), podrías crear dos scripts (¿python?) con distinto nombre y cada uno llamando al mismo comando, a ver si cuela O:-) Me gusta este programa. Es muy. muy configurable. Lo que sugieres es probable que funcione. Como en realidad lo que quiero es que un mismo filtro se aplique en INPUT y FORWARD lo que he hecho al final es crear una nueva accion basada en la que me interesa que permita pasarle varias cadenas: action = iptables-multiple-chains[name=SSH, port=ssh, protocol=tcp, chain=INPUT FORWARD] Y he creado esta nueva acción iptables-multiple-chains basada en la acción iptables así: #v+ [INCLUDES] before = iptables.conf [Definition] actionstart = iptables -N fail2ban-name iptables -A fail2ban-name -j RETURN for CHAIN in chain; do iptables -I $CHAIN -p protocol --dport port -j fail2ban-name; done actionstop = for CHAIN in chain; do iptables -D $CHAIN -p protocol --dport port -j fail2ban-name; done iptables -F fail2ban-name iptables -X fail2ban-name #v- Los for me permiten hacer lo que quiero. En realidad, quiero algo más complejo, porque mi intención es filtrar las MAC que el servidor DHCP me chive que son de smartphones, así que tendré que contruir la acción por completo filtrando por mac y usando ipset (si dispongo de un núcleo en jessie que soporte hash:mac) o usando el módulo mac. Pero el poder utlizar el filtro en INPUT y FORWARD a la vez, ya lo tengo resuelto. Muchas gracias. -- El más seguro bien de la fortuna es no haber tenido vez alguna. --- Alonso de Ercilla --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150312172030.ga12...@cubo.casa
Re: Múltiples host names para un equipo
El Thu, 12 de Mar de 2015, a las 02:12:44PM -0300, Javier ArgentinaBBAR dijo: La preguntonta: ¿Es posible definir para un equipo DOS (o más) nombres distintos de host, identificándose en forma distinta (o sea, con otro nombre), según se trate de una red u otra? No me refiero al alias, donde en una red, se puede usar más de un nombre de host, siento TODOS visibles en forma indistinta. Me refiero a que desde la red intranet NO SEA VISIBLE el host internet21, y desde internet NO SEA VISIBLE intranet11. En un principio, como los dominios son distintos no veo cuál es el problema en que: intranet11.intranet.org resuelve a la ip privada. internet21.internet.com resuelve a la ip pública. Si no quieres que una u otra resolución sean vistas desde uno u otro sitio, entonces tendrías que explicar cómo tienes montados los DNS. Si la red interna resuelve sus direcciones en un servidor DNS que nada sabe de la resolución internet21.internet.com, entonces un ordenador de la intranet podrá resolver ese nombre. Cosa distinta es que tú quisieras tener un único nombre que resuelva a dos ips distintas dependiendo de quién realice la petición. Por ejemplo: Un ordenador de la intranet resuelve: intranet11.intranet.org resuelve a la ip privada. internet21.internet.com también a la ip privada. Eso se consigue definiendo vistas (views) en el servidor DNS. Muchas gracias por las futuras respuestas. De nada. -- Vine a desembuchar y desembucho. --- Muñoz Seca --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150312182340.ga16...@cubo.casa
fail2ban: varias acciones en un mismo jail.
Saludos a los listeros: Tengo instalado en jessie fail2ban (0.8.13) y he intentado ejecutar dos acciones dentro de un mismo jail. Básicamente lo que he hecho es crear un jail.local con el siguiente contenido: #v+ [ssh] action = iptables-multiport[name=SSH, port=ssh, protocol=tcp, chain=INPUT] iptables-multiport[name=SSH, port=ssh, protocol=tcp, chain=FORWARD] #v- Lo que esperaba es que se creara dos reglas, una en la cadena INPUT y otra en la cadena FORWARD, pero sólo se ha creado una en FORWARD: #v+ # iptables -vnL FORWARD Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 fail2ban-SSH tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 #v- He probado a ponerle dos nombres distintos a la cadena donde se escriben los vetos (que pasarán a ser dos cadenas distintos): #v+ action = iptables-multiport[name=SSH, port=ssh, protocol=tcp, chain=INPUT] iptables-multiport[name=SSH2, port=ssh, protocol=tcp, chain=FORWARD] #v- Pero tampoco: sigue creándose sólo la regla de la cadena FORWARD. Mirando en internet he visto que podían incluirse varias acciones, aunque no sean exactamente las mismas que las de mi prueba. ¿Se me escapa algo? -- Un bel morir tutta una vita honora. --- Francisco Petrarca --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150311212812.ga25...@cubo.casa
Re: jessie, ipset y hash:mac
El Mon, 09 de Mar de 2015, a las 02:29:30PM +, Camaleón dijo: ¿En backports (cuando haya de jessie) hay compilación de núcleos más recientes? Sí, sí, tranquilo que en breve lo tendrás disponible. Pues mejor: quiero hacer un filtro para smartphones y me conviene usar ipset. A ver si soy capaz de intregrarlo en fail2ban. Y entonces sin embarazo, se le atiza un estacazo, se la mata y a otra cosa. --- Muñoz Seca --- Caray con la frasecita :-O El ser que se intenta cazar es un ave. Saludos. -- Mira que la mejor parte de España, pudiendo Casta, se llamó Castilla. --- Tomé de Burguillos --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150309191007.ga2...@cubo.casa
Re: jessie, ipset y hash:mac
El Sun, 08 de Mar de 2015, a las 04:14:51PM +, Camaleón dijo: No he trabajado con ese módulo pero buscando por Internet sobre su uso y opciones podría ser que efectivamente te faltara habilitar en el kernel el parámetro CONFIG_IP_SET_HASH_MAC. Mira a ver, yo al menos en Wheezy no lo tengo habilitado como módulo: Sí, es eso. Justamente me había dado cuenta esta tarde, pero quería confirmarlo descargando las fuentes del núcleo y viendo con menuconfig si efectivamente existía el módulo en el kernel y no lo tenía marcardo debian. Al final resulta que no está compilado, porque en el núcleo de Jessie... no existe el módulo. Existe en kernels3.18: http://cateee.net/lkddb/web-lkddb/IP_SET_HASH_MAC.html Y jessie lleva el 3.16. :( ¿En backports (cuando haya de jessie) hay compilación de núcleos más recientes? -- Y entonces sin embarazo, se le atiza un estacazo, se la mata y a otra cosa. --- Muñoz Seca --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150308190151.ga30...@cubo.casa
jessie, ipset y hash:mac
Un saludo a la lista: En la versión 6.22 de ipset se incluyó el nuevo tipo de conjunto hash:mac que permite crear conjuntos que contienen direcciones mac. jessie trae la versión 6.23 y en la página de manual viene bien explicado e ilustrado cómo usarlo. El comando help de ipset también indica que existe ese tipo de conjunto: # ipset help | grep hash:mac hash:mac0 Initial revision Pero he hecho la prueba y no funciona: # ipset create foo hash:mac ipset v6.23: Kernel error received: set type not supported Se queja de que el tipo no está soportado, como si no existiera. Otros tipos sí que funcionan sin problemas: # ipset create foo hash:ip # ipset list Name: foo Type: hash:ip Revision: 3 Header: family inet hashsize 1024 maxelem 65536 Size in memory: 16504 References: 0 Members: ¿Alguien sabe lo que pasa? ¿Ha compilado debian ipset sin soporte para este tipo de conjunto? Gracias de antemano. -- Femmina è cosa mobil per natura. --- Francisco Petrarca --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150308081549.ga5...@cubo.casa
Re: Instalador de jessie y ext4
El Thu, 05 de Mar de 2015, a las 07:57:01PM +0100, José Miguel (sio2) dijo: Probó con la iso para instalación por red, como yo. Estoy bajándome el primer cedé a ver si da problemas; y si no miraré a ver si la iso diaria funciona. El primer cedé daba el mismo problema. La iso diaria, en cambio, no; y ya la tengo instalada en disco virtual. Además, por ahora parece que no me da los problemas que me daba el sistema de ficheros en mi antigua instalación. Veremos a ver. Por cierto, poco después de grub e imagino que tras cargar la imagen initrd (el mensaje sale en castellano y dice Cargando imagen de memoria inicial), se queda unos cinco segundos esperando con el mensaje Pulse cualquier tecla para continuar Luego continúa el arranque sin contratiempos. Si se pulsa, continue el arranque de inmediato. ¿Sabe alguien a qué se debe esto? ¿Hay forma de eliminar esa estúpida espera? Un saludo y gracias. -- La juventud es un defecto que se cura con el tiempo --- Enrique Jardiel Poncela --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150306174435.ga13...@cubo.casa
Re: Instalador de jessie y ext4
El Fri, 06 de Mar de 2015, a las 06:36:40PM +, Camaleón dijo: Por cierto, poco después de grub e imagino que tras cargar la imagen initrd (el mensaje sale en castellano y dice Cargando imagen de memoria inicial), se queda unos cinco segundos esperando con el mensaje Pulse cualquier tecla para continuar Luego continúa el arranque sin contratiempos. Si se pulsa, continue el arranque de inmediato. ¿Sabe alguien a qué se debe esto? ¿Hay forma de eliminar esa estúpida espera? Ese mensaje de pulse cualquier tecla... suele aparecer en grub cuando tiene algún problema para cargar la imagen del kernel o no encuentra una partición o una ruta (hum... ¿usas cifrado?), Pues tenías razón: era cosa de grub y de que fallaba: fallaba al intentar leer de un floppy inexistente. Resulta que para que no se produzca ese error hay que decirle a la BIOS que no le diga a grub que existe floppy. Uso qemu y encontré el modo de hacer esto con la opción: -global isa-fdc.driveA= Arrancado qemu así, no se produce el error con el floppy y grub no muestra el mensaje. -- Hay dos sistemas de conseguir la felicidad: uno, hacerse el idiota; otro, serlo. --- Enrique Jardiel Poncela. -- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150306220422.ga27...@cubo.casa
Instalador de jessie y ext4
Un saludo a la lista:
Hace unos meses bajé e instalé en una máquina virtual una imagen de
jessie para ir probando y hacer un embrión de servidor que pasar luego a
un disco real.
El caso es que me fallaba muchísimo el sistema de ficheros / (en ext4):
a veces no acababa de arrancar y entraba en modo mantenimiento; o
durante el funcionamiento, al hacer escrituras, fallaba y se montaba en
modo sólo lectura.
He querido hoy realizar una instalación limpia para lo que he bajado la
última iso (del día 2 de marzo). Pero al intentar la instalación resulta
que no hay forma de crear particiones con sistema de ficheros ext{2,3,4}
ni btrfs: sólo XFS (y FAT, pero esto como si no contara).
Como el particionado era algo complejo (LVM sobre RAID1) he probado a
empezar una instalación con particiones normalitas, pero tampoco.
¿Alguien sabe si ha pasado algo?
--
Un bel morir tutta una vita honora.
--- Francisco Petrarca ---
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150305175945.ga15...@cubo.casa
Re: Instalador de jessie y ext4
El Thu, 05 de Mar de 2015, a las 06:43:18PM +, Camaleón dijo: No he probado ninguna imagen de instalación recientemente pero podrías intentarlo con la imagen diaria: http://cdimage.debian.org/cdimage/daily-builds/ En cuanto a los cambios del instalador, los más recientes (rc1) son éstos: https://www.debian.org/devel/debian-installer/News/2015/20150126 Sí que veo algunos cambios en part-man pero no sé hasta qué punto te podrían estar afectando. En cualquier caso, se trata de una instalación sobre una VM así que es posible que haya otros factores que estén haciendo ruido. Acabo de dar con una notificación de bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779651 Probó con la iso para instalación por red, como yo. Estoy bajándome el primer cedé a ver si da problemas; y si no miraré a ver si la iso diaria funciona. Muchas gracias. -- e non l'arbitrio de femina lieve, che sempre inchina a quel che men far deve. --- Ludovico Ariosto --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150305185701.ga19...@cubo.casa
Re: Servidor de correo (postfix) y spam
El Tue, 24 de Feb de 2015, a las 03:05:49PM +, Camaleón dijo: Sí, vsftp tiene usuarios virtuales ajenos a las cuentas del sistema. Y sí, usa PAM pero ojo que PAM es súper flexible y no sólo permite autentificaciones mediante su bdd local sino contra todo tipo recursos que van desde archivos en texto plano hasta kerberos. Bueno, pues eso es lo que yo venía a decir: que todo es cosa de PAM, no de vsftp en sí. No es el caso de pureftp que creo recordar que sí soporta sus propios usuarios (sin ayudarse de módulos de PAM quiero decir). De lo que se trata es de dejar a los usuarios del sistema separados de los servicios accesibles en remoto (pop3/imap, smtp, ftp, apache...) Sí. El servidor actual lo tengo hecho un poco monstruito, porque le fui añadiendo servicios según los iba necesitando o me parecían bien sin un plan previo preestablecido. Como ahora tengo las necesidades más claras, seré más previsor al montar el nuevo servidor. Ya pediré consejo al respecto. ¡Ah! debian me acaba de resolver la duda entre denyhosts y fail2ban: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732712 Y efectivamente ya no está en jessie. Saludos, Saludos y gracias. -- La juventud es un defecto que se cura con el tiempo --- Enrique Jardiel Poncela --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150224184637.ga6...@cubo.casa
Re: Servidor de correo (postfix) y spam
El Mon, 23 de Feb de 2015, a las 02:39:36PM +, Camaleón dijo: Correcto. Cambia la contraseña del usuario pablo y se acabará el goteo. Ahora mismo está desabilitado. ¡¡Madre mía! Leo, releo y no me creo que haya podido escribir esto: deshabilitado, deshabilitado, deshabilitado... Un poco radical peor bueno, eso ya es competencia del administrador. Es que, además de la fuerza bruta, la otra posibilidad es que el usuario esté usando un filezilla troyanizado. El usuario es el mismo: tanto el servidor FTP como el servidor de correos se autentican con PAM. En realidad, no hay muchos usuarios, así que no monté ningún servicio LDAP o SAMBA para usuarios. Eso es un error tremendo, más aún tratándose de un sistema como el FTP que usa contraseñas en claro. Hay que separar siempre las cuentas y los servicios aunque resulte pesado tanto para el admin como para el usuario y también hay que forzar una política de gestión de contraseñas medianamente seguras. Sí, ya estoy escarmentando en servidor propio. Lo que he pensado es crear un /etc/pam.d/smtp (¿o es /etc/pam.d/smtpd?) que restrinja los usuarios que se pueden autenticar en el servidor de correo. Suelo usar PAM sólo para cuentas locales del sistema, pero quizá en este caso te resultaría más práctico gestionar los usuarios ftp con otro sistema de gestión de usuarios que sea sencillo (p. ej., vsftp usa archivos de texto plano para generar su bdd). ¿vsftp tiene usuarios virtuales? Creo recordar que usa PAM y ya está. Otra cosa es que personalices /etc/pam.d/vsftpd y uses algún módulo de pam para modificar la validación predeterminada. De hecho, en debian la autenticación de vsftp viene tuneá de serie. Por eso los usuarios listados en /etc/ftpusers no tienen acceso al ftp. Hay varios módulos que pueden servir para eso: pam_pwdfile, pam_fshadow, pam_userdb. O los correspondientes a samba y ldap, claro. Tengo previsto comenzar a montar un nuevo servidor sobre jessie a partir de mayo/junio. Tendré que pensarme bien cómo montar todo esto de los servidores. Posiblemente pida consejo en la lista al respecto. En principio denyhost sólo analiza accesos al SSH, pero se pueden cambiar las expresiones regulares para que analice accesos de otros servidores. Lo hice en su momento con FTP, pero no con SASL, que es lo que uso para autenticar en postfix. Fail2ban le iría mejor, creo yo, ya que tiene las plantillas de los servicios más comunes definidas (pop/imap/smtp...). Sí, he visto que es mucho más configurable. Y sobre todo, tiene la ventaja de que se puede configurar el fichero de log que se inspecciona. En denyhosts sólo se puede indicar uno, así que aparte de tener que romperme los cuernos con la expresión regular, he tenido que modificar rsyslog para que me guardara el aviso en /var/log/auth.log. La verdad es que cuando me planteé esto, no mire mucho ambas soluciones y me decanté por denyhosts, porque fail2ban usa el cortafuegos para vetar el acceso y yo tengo un complejo juego de reglas en iptables para hacer las más variopintas perrerías en las redes que atraviesan el servidor. Así que preferí no enmarañarlo más. Quizás es limpito y se crea una cadena aparte para meter sus reglas o usa ipset para apuntar las ips. Debería volver a mirármelo, cuando monté el nuevo servidor. Ahora ando parcheando. :/ Saludos, Un saludo. -- Flérida para mí dulce y sabrosa, más que la fruta de cercado ajeno. --- Garcilaso de la Vega --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150223203905.ga6...@cubo.casa
Servidor de correo (postfix) y spam
Un saludo a la lista: Hoy me he desayunado con que mi servidor de correo estaba mandado spam desde hace algunos días. Me extrañaba la circunstancia, porque el servidor lleva montado cerca de un año y no había dado problemas. Por si acaso he comprobado si tenía el relay abierto: #v+ $ telnet mail.midominio.es 25 Trying 80.32.206.136... Connected to mail.midominio.es. Escape character is '^]'. 220 smtp.midominio.es ESMTP Postfix (Debian/GNU) ehlo 501 Syntax: EHLO hostname ehlo testing 250-smtp.midominio.es 250-PIPELINING 250-SIZE 1024 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN MAIL FROM: cuentainexiste...@example.com 250 2.1.0 Ok RCPT TO: t...@example.com 554 5.7.1 t...@example.com: Relay access denied #v- Y no lo está, porque de ser así los problemas habrían aparecido mucho antes. El servidor exige validarse para enviar correo a otros servidores, excepto si la petición procede de las redes locales que están configuradas así: mynetworks = 127.0.0.0/8 O sea, sólo el propio servidor, lo cual descarta que el relay se estuviera haciendo desde algún cliente de la red local. El servidor está montado principalmente para servir de sostén a algunas aplicaciones web (moodle, por ejemplo); y solamente yo lo uso esporádicamente. Mirando las anotaciones en /var/log/mail he visto esto: #v+ # grep sasl_username= mail.log.1 [...] Feb 18 22:37:39 orrilo postfix/smtpd[7371]: 8FF261122D: client=unknown[190.107.244.151], sasl_method=LOGIN, sasl_username=pa...@smtp.midominio.es Feb 18 22:38:01 orrilo postfix/smtpd[6676]: CE9C9109F0: client=unknown[190.107.244.151], sasl_method=LOGIN, sasl_username=pa...@smtp.midominio.es Feb 18 22:38:25 orrilo postfix/smtpd[7371]: 6EBE9109F0: client=unknown[190.107.244.151], sasl_method=LOGIN, sasl_username=pa...@smtp.midominio.es Feb 18 22:38:48 orrilo postfix/smtpd[6676]: B6FE111238: client=unknown[190.107.244.151], sasl_method=LOGIN, sasl_username=pa...@smtp.midominio.es Feb 18 22:39:12 orrilo postfix/smtpd[7371]: 0FE8511224: client=unknown[190.107.244.151], sasl_method=LOGIN, sasl_username=pa...@smtp.midominio.es Feb 18 22:39:34 orrilo postfix/smtpd[6676]: 6E45911244: client=unknown[190.107.244.151], sasl_method=LOGIN, sasl_username=pa...@smtp.midominio.es Feb 20 14:13:09 orrilo postfix/smtpd[24490]: 8E78B3A22: client=unknown[83.170.119.28], sasl_method=LOGIN, sasl_username=pa...@smtp.midominio.es Feb 21 14:15:45 orrilo postfix/smtpd[5438]: ED6197F6D: client=unknown[79.172.242.83], sasl_method=LOGIN, sasl_username=pa...@smtp.midominio.es [...] #v- Las ips son de Argentina, Hungría, Reino Unido. Si observo los números 8FF261122D, CE9C9109F0, etc, que creo que los asigna postfix a cada petición que recibe, veo que están asociadas a envíos de spam. por ejemplo: #v+ [...] mail.log.1:Feb 21 14:15:55 orrilo postfix/pipe[5444]: ED6197F6D: to=therichsheci...@yahoo.com, [...] mail.log.1:Feb 21 14:15:55 orrilo postfix/pipe[5444]: ED6197F6D: to=therichsheci...@yahoo.com, [...] mail.log.1:Feb 21 14:15:55 orrilo postfix/pipe[5444]: ED6197F6D: to=therichsheci...@yahoo.com, [...] [,,,] #v- Así que este parece ser el problema: que han cazado la contraseña de un usuario del sistema, porque entiendo que estas líneas significan que alguien se ha autenticado en el servidor como pablo para después enviar spam. Efectivamente, esa cuenta existe y es de alguien al que se la di, porque de vez en cuando sube documentos a un ftp para que luego se vean a través de la web. Creo que mi diagnóstico es acertado, ¿no? Por lo pronto he deshabilitado al usuario. Supuesto esto, me gustaría saber dos cosas: a) ¿Cómo se ha producido esto? b) Si existe alguna manera sencilla de detectar esto más adelante: lo he detectado unos días después de que comenzara, porque me dio por mirar los logs por otra razón distinta. En lo relativo a lo primero, entiendo que ftp no es seguro y que quizás tendría que usar el sftp que ofrece ssh. Sin embargo, ¿es esta una causa probable de que hayan averiguado la contraseña los spammers o lo es más que tenga un malware en el ordenador de su casa que le haya obtenido la contraseña de filezilla, por ejemplo? Eso descartando que su contraseña sea 1234. Mañana se lo preguntaré. Por otro lado, por la técnica de ensayo/error no creo que haya sido, porque tengo habilitado denyhost que banea ips cuando detecta un número de terminado de intentos fallidos al servidor SSH o al FTP. Un saludo y gracias de antemano. -- Et nulla stringo, et tutto 'l mondo abraccio --- Francisco Petrarca --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150222104550.ga9...@cubo.casa
Re: Servidor de correo (postfix) y spam
El Sun, 22 de Feb de 2015, a las 03:53:36PM +, Camaleón dijo: Hoy me he desayunado con que mi servidor de correo estaba mandado spam desde hace algunos días. ¿Has verificado que eso sea realmente lo que esté pasando? Es decir, ¿cómo sabes que está enviando spam? Sí, se estaban intentado enviar correos a cuentas absurdas y además había ciento y pico mensajes en la cola del servidor de correo esperando a ser enviadas. Correcto. Cambia la contraseña del usuario pablo y se acabará el goteo. Ahora mismo está desabilitado. No, salvo que uses la misma contraseña de acceso al ftp que para el correo electrónico lo cual sería un error. El usuario es el mismo: tanto el servidor FTP como el servidor de correos se autentican con PAM. En realidad, no hay muchos usuarios, así que no monté ningún servicio LDAP o SAMBA para usuarios. Lo que he pensado es crear un /etc/pam.d/smtp (¿o es /etc/pam.d/smtpd?) que restrinja los usuarios que se pueden autenticar en el servidor de correo. No estoy segura de que denyhosts funcione más allá de prevenir ataques de fuerza bruta contra servidores ssh, es decir, para evitar ataques de fuerza bruta contra un servidor de autentificación vía smtp necesitarías otra aplicación. En realidad me refería a que lo hubieran intentado por SSH o por FTP. Pero efectivamente han podido hacerlo directamente intentándolo sobre el SMTP. En principio denyhost sólo analiza accesos al SSH, pero se pueden cambiar las expresiones regulares para que analice accesos de otros servidores. Lo hice en su momento con FTP, pero no con SASL, que es lo que uso para autenticar en postfix. Después de un poco de trabajo creo que he logrado que denyhost analice también SMTP (no lo he probado todavía): no sé por qué estúpida razón saslauthd no apunta la ip remota que intenta la autenticación; así que he tenido que hacer un cambalache. Un saludo. -- -¿Quién le dice a v.m. que no se pueda hacer? Hacerse puede, que ser imposible es otra cosa. --- Francisco de Quevedo --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150222190507.ga26...@cubo.casa
Re: Servidor de correo (postfix) y spam
El Sun, 22 de Feb de 2015, a las 01:13:21PM +0100, Manolo Díaz dijo: O que sea pablo, como el usuario. O que sea una contraseña de verdad pero la use para todo: te apuntas a una red social insegura, usas tu cuenta de correo y la misma contraseña y ya está. No cuesta mucho trabajo ver si esa contraseña es también la de la cuenta de correos que proporcionas. En realidad, ni siquiera sabe que tiene cuenta de correo. No creo que sea eso. He hecho una búsqueda rápida y tiene toda la pinta de haber sido esto otro. http://lignux.com/filezilla-ha-advertido-que-exiten-versiones-con-malware/ Este grupo de hackers ha logrado que Filezilla robe y envíe datos como el nombre de usuario, la contraseña, el servidor FTP o el puerto codificados con un algoritmo base 64 a un servidor situado en Alemania conocido por albergar actividades relacionadas con el malware y el spam. Tiene todos los número de haber sido esto. -- Lee si puedes y enmienda si sabes. --- Lope de Vega --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150222154113.ga23...@cubo.casa
Re: Pasarela SSH
El Sun, 15 de Feb de 2015, a las 01:25:08AM -0300, Jorge A. Secreto dijo: Justamente, si el servidor 1 hace un túnel desde, por ejemplo, su puerto 1022 al puerto ssh del servidor 2, lo único que cambia para el usuario 2 es el puerto al que se conecta ¿eso no te sirve? Sí, es una mejor solución que la segunda que he propuesto: sólo había pensado en establecer el túnel desde el cliente previamente, y no en tener establecido un túnel permanente desde el servidor, lo cual implicaba tener que hacer dos conexiones. Tal y como lo propones, el cliente sólo tendría que hacer una (aunque a distinto puerto). El caso es que lo que realmente me gustaría es ver si se puede resolver el primer planteamiento. La realidad es que ambos ordenadores tienen salida directa a internet con ip propia, de manera que se puede acceder a ellos directamente. Uno, sin embargo, presenta problemas en su conexión por motivos que no vienen al caso, y a veces se queda sin este acceso directo. Sin embargo, ambos tienen una forma de acceso llamémoslo interno, y ese acceso sigue funcionando. Por tanto, aunque el acceso externo al Servidor2 está caído, se puede acceder a él a través del Servidor1. En el modo normal de funcionamiento el dominio del Servidor2 lo gestiona él mismo y el Servidor1 hace de servidor esclavo. Ahora bien, cuando se produce una caída de Servidor2, el Servidor1 la detecta y cambia su rol y se pone a trabajar como servidor maestro de dicho dominio, haciendo además que el dominio resuelva a su ip y no a la de Servidor2. De esa forma todas las conexiones que originariamente iban al Servidor2 acaban en el Servidor1. Para que esto funcione aceptablemente el TTL de los registros es pequeño (5 minutos). En estas condiciones: $ ssh usuar...@servidor2.com conecta directamente con Servidor2, pero cuando la conexión está caída ese mismo comando acaba en Servidor1. La idea es que pueda encuazarlo internamente hacia Servidor2. El problema es que usuario2 no tiene (ni tiene por qué tener) cuenta en Servidor1. Si se pudieran mapear usuarios en SSH, podría hacer que cuando el dominio es servidor2.com todos los usuarios se mapearan a uno en particular creado ex-profeso y que esté fuera el que conectara con el servidor2 con un ForceCommand. Pero esto que digo no veo que se pueda hacer. Camaleón hablamente me respondió también, pero lo que he podido leer en todos los documentos propone algo parecido a mi segunda solución sólo que en vez de usando ForceCommand en el servidor, usando ProxyCommand en el cliente. Un saludo. -- Flérida para mí dulce y sabrosa, más que la fruta de cercado ajeno. --- Garcilaso de la Vega --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150215150603.ga23...@cubo.casa
Re: Pasarela SSH
El Sun, 15 de Feb de 2015, a las 04:06:03PM +0100, José Miguel (sio2) dijo: registros es pequeño (5 minutos). En estas condiciones: $ ssh usuar...@servidor2.com conecta directamente con Servidor2, pero cuando la conexión está caída ese mismo comando acaba en Servidor1. Antes de que alguien me corrija: sí, saltará el chivato de que puede haber una suplantación de identidad. -- Los grandes hombres solemos ser modestos. --- Juan de Mairena -- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150215173629.ga29...@cubo.casa
Pasarela SSH
Un saludo a la lista: Por motivos un poco prolijos de explicar quiero acceder a un servidor SSH a través de otro servidor SSH de la manera más transparente posible: Cliente - Servidor1 Servidor2 Por supuesto se qué existen túneles para poder hacer esto, pero mi intención es que el usuario notase lo menos posible. Mi idea inicial, aunque creo que es imposible de llevar a cabo es la siguiente: 1. Asigno dos nombres a la ip del Servidor1 (pongamos que servidor1.com y servidor2.com). 2. Cuando quiero acceder por SSH al servidor1 hago lo siguiente: $ ssh usuar...@servidor1.com 3. Cuando quiero acceder por SSH al servidor2 hago lo siguiente: $ ssh usuar...@servidor2.com He de aclarar que en el servidor 1 existen unos usuarios y en el servidor 2 otros usuarios independientes entre sí, así que se supone que usuario2 es un usuario que existe en Servidor2, pero no en Servidor1. Sé que esto es medianamente abordable con la directiva Match ya que puedo poner como condición el nombre de Host y forzar luego el comando de conexión ssh hacia Servidor2. El problema de todo esto está en que el servidor SSH de Servidor1, me exige que me autentifique y usuario2 no tiene por qué existir. Creo que tampoco puedo abordar esto intentando manipular la autentificación con PAM, porque en pam soy incapaz de saber cómo ha sido el acceso ssh, si a servidor1.com o a servidor2.com. Por esta vía, que es la que realmente me parece más interesante, no sé seguir y la veo totalmente irresoluble. Se me ha ocurrido otra solución, aunque me gusta bastante menos porque no es tan transparente. Consiste en crear un usuario llamado pasarela que permtia la autentificación clave de manera que nos ea necesaria contraseña. En este caso el acceso al segundo servidor sería así: $ ssh pasar...@usuario2.servidor1.com de manera que en el nombre de la máquina estaría incluido el nombre de usuario que se quiere usar en el Servidor2. A partir de ello, el script que arrancara ForceCommand se encargaría de crear el comando ssh que conectara con el segundo servidor. Lo guarro de esta segunda conexión, a parte de que el comando ya no es transparente, es que además tendría que dar a todos los usuarios que usaran esto, una clave privada cuya clave pública estuviera en el authorized_keys de pasarela. ¿Alguien tiene alguna idea para solucionar los problemas del primer método o se le ocurre algún método que sea menos engorroso que este segundo? -- Como todo al fin se sabe yo he sabido la verdad. --- Muñoz Seca --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150214174932.ga29...@cubo.casa
Re: [OT] Raid por hardware
El Sun, 25 de Jan de 2015, a las 07:12:30PM +, Camaleón dijo: Recuerda que no sólo tienes que asegurarte de la configuración que tienes en la BIOS para la controladora del disco duro sino también del módulo del kernel que usas en todo momento. Es decir, la teoría establece los siguientes parámetros óptimos: BIOS → módulo del kernel IDE → libata / mptctl SATA/AHCI → ahci RAID/INTEL → dm RAID/LSI → mptsas Todo esto parecía ir bien: cuando usaba la controladora RAID se cargaba el módulo mptsas, cuando no la usaba no lo hacía. Al final resultó que sin la controladora RAID, acabaron por producirse las demoras. Definitivamente tuve que quitar el servidor y poner el ordenador normalillo para ir tirando. Ahora vuelvo a estar en precario. Después de cerciorarme de que la cosa seguía mal, decidí deshacer el RAID otra vez, pinchar los discos directamente a la placa base; y, como novedad, quitar físicamente la controladora del servidor. Hecho esto, probé... y funciona. Ahora va como un tiro. Pero te sigues olvidando del módulo del kernel y de la configuración de la BIOS. Eso no lo cité, pero lo hice también: quité la controladora y puse la BIOS la controladora en modo IDE (o AHCI no recuerdo bien). La secuencia para comprobar el correcto (o no) funcionamiento de la controladora raid sería la siguiente (conlleva pérdida de datos): 1/ Configurar los discos en la BIOS como RAID/LSI 2/ Acceder a la BIOS de la controladora y definir el raid 1 reinicializando los discos (se borra todo) 3/ Instalar de nuevo el sistema operativo desde cero o asegurarte de que el kernel carga el módulo adecuado (mptsas). No instalé de nuevo el sistema, pero sí comprobé que se cargaba mptsas. No valía, de hecho cuando lo puse en RAID/LSI fue cuando peor fue. Peor que con RAID/IDE o RAID/AHCI. De otra forma es posible que los metadatos de los discos con la información del raid esté molestando por lo que idealmente habría que empezar desde cero. No sé si molestan o no. De hecho, no tengo muy claro que el problema sea de acceso a disco. Quizás que no se sincronicen los discos es una consecuencia y no la raíz del problema. De todas formas, también te digo que en ese equipo no creo que vayas a notar una merma en el rendimiento por usar md (software raid) en lugar del raid por harwdare. Si optas por esta opción (md) recuerda poner el modo AHCI en la BIOS. En realidad usé el raid por hardware por el hecho de tener la controladora. No es un servidor que soporte mucho tráfico, ni mucho menos. Va más que sobrado. Cuando funciona bien, claro. La actualización de la BIOS te cambió los parámetros de acceso a los discos, no sé ni cómo fue capaz de iniciar el sistema . Quizás la actualización hizo algo, pero lo cierto es que yo he probado a cambiar los parámetros de acceso a disco. Usando la controladora RAID: IDE, AHCI y LSI; y sin usar la controladora IDE y AHCI; y con todos tenía los problemas de demora. Puede ser que el problema esté en otro sitio. Ya contarás :-) Pues eso, que no se arregló. El problema es que ahora no tengo mucho tiempo para cambalaches. Me temo que voy a tener que dejar el ordenador de repuesto y esperar mejores tiempos. Saludos, Saludos. -- Flérida para mí dulce y sabrosa, más que la fruta de cercado ajeno. --- Garcilaso de la Vega --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150131102904.ga5...@cubo.casa
Re: [OT] Raid por hardware
Pues bien, traigo noticias frescas de mis tribulaciones con el servidor. Después de comprobar que el sistema funcionaba perfectamente sobre un solo disco en otro ordenador distinto, probé a volver a usar el servidor. Nada, volvían a producirse las mismas demoras. Cambié la controladora de disco en la BIOS a RAID+LSI, pero no sirvió de nada. De hecho, me da la sensación de que nunca llegó a estar así, por la información que proporciona el ordenador antes de que apareciera el grub. Después de cerciorarme de que la cosa seguía mal, decidí deshacer el RAID otra vez, pinchar los discos directamente a la placa base; y, como novedad, quitar físicamente la controladora del servidor. Hecho esto, probé... y funciona. Ahora va como un tiro. Como soy previsor y había montado un raid1 por software también, me toca limpiar el superbloque del segundo disco, enchufarlo al servidor y hacerlo participar en el raid como segundo disco. Renunciaré a hacer el RAID por hardware y ya está. Entiendo que el problema lo provoca la mera presencia de la controladora RAID en el sistema; y no el que gestione ella el RAID; puesto que ya probé hace un par de semanas a dejarla puesta sin que se encargara del acceso a disco. No sé si la actualización de la BIOS pudo introducir alguna incompatibilidad. Lo que voy a hacer antes de enchufar el segundo disco en el servidor definitivamente, es ponerlo en el otro ordenador y ver si es posible pinchar la controladora de RAID también. Si se puede, pondré a funcionar el conjunto a ver si se me producen esas demoras o no. Un saludo. -- Mira que la mejor parte de España, pudiendo Casta, se llamó Castilla. --- Tomé de Burguillos --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150124081748.ga2...@cubo.casa
Re: [OT] Raid por hardware
El Sat, 17 de Jan de 2015, a las 05:19:03PM +, Camaleón dijo: He estado consultado la BIOS del servidor desmantelado. La controladora se puede poner como: + IDE, que era como estaba. ¿Estaba en modo IDE y con RAID habilitado? O_o No, está en IDE ahora que hay un disco duro conectado directamente a la placa base y que deshice el RAID. Pero yo no toqué nada en la BIOS de la placa base: sólo deshice el RAID en la BIOS de la controladora RAID y cambié el cableado del disco para que estuviera enchufado sin pasar por dicha controladora. Puede ser que al deshacer el RAID, la controladora cambiara en la BIOS de la placa esto (no sé si es posible). Lo que me escama es que la BIOS estuviera en IDE y no en LSI: yo no he tocado nada. A lo mejor se desconfiguró cuando actualicé la BIOS (aunque tampoco sé cuál era su valor antes de la actualización). Ah, claro... es posible que al actualizar la BIOS todos los valores volvieron al estado de fábrica, de ahí que te diera tantos problemas y te fuera lentorro. Sí, prueba dejando la configuración RAID+LSI que es como debería estar y conecta los dos discos, todo debería volver a la normalidad. Eso haré. El problema que tengo ahora es que no sé cómo narices identificar uno de otro disco para que el disco que ha estado esta semana trabajando sea el disco primario del RAID. Debería haber una forma, pero soy incapaz de verla. Al menos mientras el RAID estuvo montado: a lo mejor sí se puede ver al crear el RAID. No sé si el orden de colocación de los discos duros afectará al raid 1, quizá no haya ningún problema si todos los datos siguen intactos en ambos discos. No, ambos discos son ya distintos, porque esta semana se han añadido datos al disco que ha seguido funcionando en el servidor circunstancial. Haré copia de estos datos por si las moscas y, antes de recontruir el RAID, probaré a tomar otros dos discos vacíos que contengan un único fichero distinto cada uno. Montaré el RAID con ellos y miraré cuál es el disco que se tomó como primario. En base a ello, colocaré los dos discos que me interesan: se supone que si hago exactamente lo mismo en uno y otro caso, sabré de antemano cuál será tomado como primario en el segundo caso. El problema está claro: se ha modificado el parámetro de la BIOS lo cual no sé ni cómo ha podido funcionar. Vuelve a dejarlo como estaba y verás como el problema se soluciona :-) Yo no me las prometo tan felices. Ya contaré qué pasa. Saludos, Saludos y gracias. -- ¿No ha de haber un espíritu valiente? ¿Siempre se ha de sentir lo que se dice? ¿Nunca se ha de decir lo que se siente? --- Francisco de Quevedo --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150117212915.ga29...@cubo.casa
Re: [OT] Raid por hardware
El Mon, 12 de Jan de 2015, a las 02:39:28PM +, Camaleón dijo: Mucho esperas... Me extrañaría que tuviera memoria flash con capacidad suficiente para albergar los datos más allá de los que necesita (firmware y metadatos). Salvo que la controladora sea buena (pero de las buenas de verdad que tienen un batería y todas esas gaitas) y aún así tendría mis dudas. Pues creo que llevas razón. He comprobado el driver que hay cargado en el ordenador suplente temporal, que no lleva ninguna controladora RAID, y se carga el driver mptctl. Entiendo que es este driver el que me oculta que el disco tenga metadatos del RAID y que haciendo una consulta a las particiones y demás parezca un disco normal, ¿no? Es que no tienes más que una controladora de disco sata y es la LSI. He estado consultado la BIOS del servidor desmantelado. La controladora se puede poner como: + IDE, que era como estaba. + ACHI. + RAID y dentro de esta categoría: - Intel no se qué (entiendo que será un fake-raid) - LSI, que utilizará la controladora RAID pinchada. Lo he puesto en ACHI y con el segundo disco he probado a instalar un paquete. No ha parecido demorarse como antes, pero no me fío mucho. No sé si probar a ponerlo en ACHI o en RAID-LSI y probar. Lo que me escama es que la BIOS estuviera en IDE y no en LSI: yo no he tocado nada. A lo mejor se desconfiguró cuando actualicé la BIOS (aunque tampoco sé cuál era su valor antes de la actualización). El problema que tengo ahora es que no sé cómo narices identificar uno de otro disco para que el disco que ha estado esta semana trabajando sea el disco primario del RAID. Debería haber una forma, pero soy incapaz de verla. Al menos mientras el RAID estuvo montado: a lo mejor sí se puede ver al crear el RAID. Como ya he visto que el sistema en el ordenador funciona sin problemas, lo haré la semana que viene. Con suerte ha desaparecido el problema, aunque no sé muy bien cuál podría ser. La memoria la testeé y estaba bien. :/ Saludos, Saludos. -- El amor es como los columpios, porque casi siempre empieza siendo diversión y casi siempre acaba dando náuseas. --- Enrique Jardiel Poncela --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150116193520.ga9...@cubo.casa
Re: [OT] Raid por hardware
El Sun, 11 de Jan de 2015, a las 04:29:13PM +, Camaleón dijo: Sí, era el que usaba para comprobar el estado del RAID, antes de descubrir que también existía la utilidad lsiutil. Lo único que indica es el modelo también. De hecho, ni siquiera da información del progreso de la sincronización: sólo de que los discos no están sincronizados y de que se está en proceso de sincronización. Pero del tanto por ciento, nada de nada. Pues no lo entiendo, la verdad. LSI no es precisamente un fabricante de los considerados malillos, no tiene sentido que disponga de herramientas para la gestión del raid tan pobres, la menos la suya (lsiutil) debería ser más completa pero parece que no :-? Quizás me has entendido mal: es mpt-status el que no devuelve el porcentaje de la sincronización: lsiutil, sí. Lo que fui incapaz de encontrar con lsiutil fue la identificación del disco. No, no... qué va, no vale. Recuerda que en el supuesto que estamos tratando estás deshaciendo el raid 1: pinchas un disco únicamente en una controladora de disco duro distinta. Lo normal en ese caso es que si se tratara de un volumen de inicio no pudiera arrancar. La definición del RAID en sí puede estar almacenada en memoria flash y no hay que guardar metadatos del RAID en los discos duros. ¿En qué memoria flash? En la de la propia controladora RAID, que tiene su propia BIOS actualizable por lo que debe tener memoria flash. Los datos del RAID quedan en los discos duros y la controladora RAID es la que se encarga de interpretarlos, de ahí que mientras conectes los discos a una controladora igual no haya problemas pero no sucede lo mismo si los discos se conectan a una controladora distinta (sea RAID o no). Pues he probado a conectar el otro disco a otro ordenador y arranca sin problemas. Como uno lo conecté al servidor pero no a través de la controladora y otro a otro ordenador sin ella, ambos discos han arrancado y funciona su sistema perfectamente sin la controladora. Así que los datos de definición del RAID deben de estar en la propia controladora, porque el único lugar libre que se me ocurre en los discos es el espacio que hay entre el MBR y el principio de la primera partición. Pero ese espacio ya lo usa grub, al menos en parte. Además el RAID se puede inicializar antes de tener hecha ninguna partición. He mirado con fdisk la definición de las particiones del disco (que ya no gestiona la controladora) y no hay nada raro en ellas. La primera empieza en el sector 2048. El driver no lo estoy usando para nada ahora mismo. De hecho acabo de hacer unos rmmod para eliminar todos los drivers mtp* y los he descargado sin problemas. Pues la salida que enviaste de lspci decía que estaban en uso: La salida dice que lo está usando la controladora, lo cual es normal porque sigue pinchada y no la he deshabilitado. Como es software plug and play, durante el arranque se detecta que hay una controladora y se carga su driver para usarla. Pero no estoy usando la controladora para acceder a disco porque el disco lo pinché directamente a la placa base. De hecho, he descargado los módulos mpt* y se hizo sin problemas. Si hago ahora un lspci -v no sale la línea esa que indica que ese driver está usando el módulo. En concreto esta que citas: Kernel driver in use: mptsas O incluso puedo pinchar unos de los discos en un ordenador completamente diferente y mirar a ver si en ese ordenador el sistema tiene los lapsus que tiene en el servidor. Bueno, con eso cuidado porque es posible que no inicie a la primera y que (dependiendo de cómo tengas detectados los discos duros) tengas que hacer cambios en el gestor de arranque o cargar el módulo del kernel que se encargue de la controladora de los discos duros en el nuevo equipo. Ha funcionado sin problemas. Como la placa exige tarjetas PCI de perfil bajo, no he podido pincharle tarjetas de red para que haga exactamente la labor del servidor y dejarlo un par de días, que sería lo suyo. Lo que si hice fue actualizar paquetes, que es una tarea que el servidor hace siempre anormalmente lenta, y la velocidad fue la normal. Si pudiera hacer una prueba definitiva haciendo que se tire unos días sustituyendo al servidor, podría descartar algún fallo de configuración, y buscar entre el hardware del servidor el culpable. Pero tengo el problema de la caja. Mañana por la tarde haré algunas cosillas que tengo pendientes (chequear la memoria y deshabilitar la controladora RAID en la BIOS si es posible). Saludos, Saludos. -- Et nulla stringo, et tutto 'l mondo abraccio --- Francisco Petrarca --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150112121200.ga2...@cubo.casa
Re: [OT] Raid por hardware
El Sat, 10 de Jan de 2015, a las 03:00:54PM +, Camaleón dijo: ¿Dónde yo sólo veo una numeración que es igual para ambos discos (ST3250620NS), porque esa numeración indica el modelo? Anda... pues tienes razón, es el modelo de los discos y si los tienes iguales no te sirve de nada, claro. [...] Recuerda que también tienes el driver libre para monitorizar el raid (mtp-status), nunca está de más comparar los resultados de dos aplicaciones. Sí, era el que usaba para comprobar el estado del RAID, antes de descubrir que también existía la utilidad lsiutil. Lo único que indica es el modelo también. De hecho, ni siquiera da información del progreso de la sincronización: sólo de que los discos no están sincronizados y de que se está en proceso de sincronización. Pero del tanto por ciento, nada de nada. Porque como te he dicho antes, la información de los datos del raid (metadatos) está en los discos duros y no estoy del todo segura de que el comportamiento de un disco duro que contiene información de un raid funcione correctamente sin estar conectado a la misma controladora y sin el resto de discos que forman la matriz. De hecho esa suele ser una de las pegas de los raid por hardware, que las migraciones no son sencillas. Entiendo que eso que dices sea necesario para un RAID por software, pero por que va a ser necesario en un RAID por hardware? Con que la controladora se encargue de abstraer el acceso a ambos discos, de manera que a ojos del sistema operativo sólo se vea uno vale, ¿no? La definición del RAID en sí puede estar almacenada en memoria flash y no hay que guardar metadatos del RAID en los discos duros. No parece que haya ninguna controladora integrada: Hombre, tiene que haberla, eso seguro. No puedes pinchar los discos en el aire :-) Bueno, sí, me refería a que no había ningún pseudo-RAID integrado en la placa. Ondiá. Vale, ya veo lo que pasa. Esa placa base tiene dos controladoras IDE/ATA y una controladora SAS/SATA que no es una controladora independiente (de las que puedes pinchar en cualquier placa base) sino de las tipo zero channel, son tarjetas específicas para determinadas placas y que hacen uso del puerto PCI-e/PCI-X pero también dependen de la BIOS de la placa base para gestionar el RAID (en el manual de la placa base tendrás información ampliada sobre este tipo de chipsets y también te dirá si puedes desactivarlo o no). Miraré eso a ver. No, no... el driver AHCI sólo se carga cuando tienes configurado en la BIOS una controladora SATA que permita configurarse en los modos habituales [ide/ata/legacy, achi, raid]. Al seleccionar ahci es cuando el kernel debería cagar ese módulo. Vale, entiendo. Bueno, recuerda que no las estás usando pero sigues con el mismo driver (mtpsas), y si el problema está en el driver es como si no hubieras hecho nada. El driver no lo estoy usando para nada ahora mismo. De hecho acabo de hacer unos rmmod para eliminar todos los drivers mtp* y los he descargado sin problemas. No sé muy bien qué hacer. Puedo intentar deshabilitar la controladora del RAID para descartarla definitivamente. También se me ocurre hacer un memtest a ver si tengo algún problema con la memoria O incluso puedo pinchar unos de los discos en un ordenador completamente diferente y mirar a ver si en ese ordenador el sistema tiene los lapsus que tiene en el servidor. Saludos, Saludos. -- Patrimonio es un conjunto de bienes, matrimonio es un conjunto de males. --- Enrique Jardiel Poncela -- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150110160653.ga24...@cubo.casa
Re: [OT] Raid por hardware
El Fri, 09 de Jan de 2015, a las 06:26:43PM +, Camaleón dijo: Qué raro... fíjate que en el ejemplo que ponen en la página que te pasé siguen exactamente la misma secuencia 21/2 y el resultado muestra el nº de serie de los discos: [...] PhysDisk 0 is Bus 0 Target 1 PhysDisk State: online PhysDisk Size 238418 MB, Inquiry Data: ATA ST3250620NS 3BKS PhysDisk 1 is Bus 0 Target 8 PhysDisk State: online PhysDisk Size 238418 MB, Inquiry Data: ATA ST3250620NS 3BKS *** ¿Dónde yo sólo veo una numeración que es igual para ambos discos (ST3250620NS), porque esa numeración indica el modelo? No toqué la BIOS para desactivar la controladora (miraré el lunes a ver cómo se hace). Lo que sí hice fue desconectar los discos de la controladora y conectarlos directamente a la placa base. Carallo. ¿Y te inició el sistema sin más? :-? ¿Y por qué no lo iba a hacer? La controladora se encarga de duplicar la información simplemente haciendo escrituras en ambos discos: pero la información es la información, ¿no? Bueno, el estado del RAID no era normal, y eso no es casual. La controladora estaba detectando algo que no le gustaba pero si mal no recuerdo hiciste una actualización de la BIOS de la placa base y el problema se produjo tras esa actualización. No, el problema puede que fuera anterior. Resulta que la partición raíz se me puso en modo lectura por un fallo de disco. Miré los log y además del fallo de disco, vi que los mensajes de arranque me decían que la versión de la BIOS de la placa base tenían bugs y que la actualizara. De hecho, tengo conectada una tarjeta de red PCI con cuatro bocas y cuando hacía un arranque en caliente (un reboot, por ejemplo) desaparecía de mi sistema (no aparecía en un lspci). Así que actualicé la BIOS: dejó de aparecer el mensaje y, además, desapareció el problema de la tarjeta. Hum... por curiosidad (si puedes) manda la salida de lspci -v a ver qué cosicas tiene ese equipo, quizá la controladora sas/sata integrada en la placa base también use el driver mtp :-? No parece que haya ninguna controladora integrada: #v+ 00:00.0 Host bridge: Intel Corporation 3200/3210 Chipset DRAM Controller Subsystem: Intel Corporation Device 34d0 Flags: bus master, fast devsel, latency 0 Capabilities: access denied Kernel driver in use: i3200_edac 00:06.0 PCI bridge: Intel Corporation 3210 Chipset Host-Secondary PCI Express Bridge (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=06, sec-latency=0 I/O behind bridge: 3000-6fff Memory behind bridge: e1f0-e1ff Prefetchable memory behind bridge: e190-e1cf Capabilities: access denied Kernel driver in use: pcieport 00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02) Subsystem: Intel Corporation Device 34d0 Flags: bus master, fast devsel, latency 0, IRQ 48 Memory at e200 (32-bit, non-prefetchable) [size=128K] Memory at e202 (32-bit, non-prefetchable) [size=4K] I/O ports at 70c0 [size=32] Capabilities: access denied Kernel driver in use: e1000e 00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation Device 34d0 Flags: bus master, medium devsel, latency 0, IRQ 18 I/O ports at 70a0 [size=32] Capabilities: access denied Kernel driver in use: uhci_hcd 00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation Device 34d0 Flags: bus master, medium devsel, latency 0, IRQ 21 I/O ports at 7080 [size=32] Capabilities: access denied Kernel driver in use: uhci_hcd 00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02) (prog-if 20 [EHCI]) Subsystem: Intel Corporation Device 34d0 Flags: bus master, medium devsel, latency 0, IRQ 17 Memory at e2021400 (32-bit, non-prefetchable) [size=1K] Capabilities: access denied Kernel driver in use: ehci_hcd 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=07, subordinate=07, sec-latency=0 I/O behind bridge: 2000-2fff Memory behind bridge: e1e0-e1ef Prefetchable memory behind bridge: f840-f87f Capabilities: access denied Kernel driver in use: pcieport 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0
Re: [OT] Raid por hardware
El Fri, 09 de Jan de 2015, a las 03:38:52PM +, Camaleón dijo: Sí, vi que smartctl me mostraba ese número de serie. El problema es que no vi que ese número de serie me lo proporcionara ni lsiutil ni la BIOS de la controladora. Así que por un lado podía identificar los discos, pero no cuál estaba desincronizado y, por otro, podía saber cuál está desincronizado pero no identificarlo físicamente. lsiutil debe decírtelo... espera que lo consulto desde el pdf que enviaste... vale, creo que debe ser el menú 21 / opción 2 (show physical disks) a lo que deberás pasar el número de la controladora (suele ser 1 salvo que tengas varias) para que te muestre todos los datos de los discos que tienes conectados. Es lo primero que consulté: no lo pone. Pone qué tipo de disco es WD-noséqué (WD de WesternDigital), pero ambos discos son iguales en este aspecto. Recuerdo que indica también un PhysDev (uno es el 0 y el otro un 1), pero no el número de serie que sí aparece usando smartctl. Al final, como tengo backups de los datos realmente importantes y el servidor pelado instalado en un disco virtual, decidí probar fortuna y deshice el raid por hardware. Yeeech. Con un par :-S Bueno, algo había que hacer... He comprobado que los dos discos arrancan el sistema sin errores. Si logro solucionar el problema y no es por culpa de la controladora, siempre puedo volver a ponerlos en RAID: al crearlo se respetan los datos del disco primario. Pero esto no soluciona el problema. El servidor sigue yendo anormalmente lento y creo que ese es el problema del que se derivan todos (quizás incluso el de la eterna resincronización del RAID). Pero ¿con deshacer el raid ya es suficiente? Supongo que habrás tenido que desactivar la controladora raid desde la bios, ponerlo en modo ahci y volcar los datos/particiones de nuevo ¿no? Porque de lo contrario seguirás usando el mismo módulo del kernel (mtp*) y si no quieres raid por harwdare convendría que usaras el driver abierto achi que te dará menos problemas. No toqué la BIOS para desactivar la controladora (miraré el lunes a ver cómo se hace). Lo que sí hice fue desconectar los discos de la controladora y conectarlos directamente a la placa base. Quizás mi problema no tenga nada que ver con el RAID ni la controladora. Como el sistema iba lento lo achaqué a la constante lectura y escritura en disco, y esta constante lectura y escritura a que no se sincronizaban los discos y la no sincronización a un fallo del RAID. Pero quizás el problema es justamente el contrario: el que se me trastabille el servidor de vez en cuando es lo que genera mis problemas de sincronización con el RAID. MIra a ver si sigue cargado el controlador de la tarjeta (mtp*) o estás usando el driver ahci (lsmod) El módulo se sigue cargando: lo cual es lógico porque no deshabilité la controladora. ahci no aparece, pero tampoco lo hace en el otro servidor que no tiene controladora. Quizás el núcleo de debian lo incluye integrado en el núcleo y no como módulo aparte. A mí lo que me escama es que el servidor se quede trabado alguna vez unos segundos, incluso con los comandos más insignificantes. Posiblemente todos mis problema nacen de esto. Pero no tengo ni idea de a qué se debe. Saludos, Saludos. -- Parezco en mi fortuna al Manzanares, que con agua o sin ella siempre es río. --- Tomé de Burguillos --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150109174421.ga11...@cubo.casa
Re: [OT] Raid por hardware
El Thu, 08 de Jan de 2015, a las 03:06:54PM +, Camaleón dijo: Y de la opción 21 (RAID options) no dice nada de nada. Te dice que sirve para obtener información del RAID y de las opciones que permite, que son varias, la verdad. Cierto, pero es que esas opciones... son las que ya se ven si se ejecuta el programa. [...] Le he pasado el test short y el conveyance a ambos discos. Ambos sin problemas. Puedo intentar pasarle el long a lo largo de la noche a ver sí dice algo más. Pásale el test extendido, merece la pena y así te quedas más tranquilo. Los discos parecen estar bien, Otro problema que tengo es que físicamente no sé cuál es cuál. Las controladoras RAID suelen tener una opción para identificar los discos cuando están en una cabina extraíble (a través de un comando que los ilumina), no sé si será tu caso. Vi en un manual de oracle para un servidor que tiene una controladora LSI cómo hacerlo desde su BIOS. Probé, pero no me pareció que funcionara. Si no tienes acceso externo a los discos, usa el nº de serie para identificarlos (show PD debería darte datos de los discos, tamaño, nº de serie...). Sí, vi que smartctl me mostraba ese número de serie. El problema es que no vi que ese número de serie me lo proporcionara ni lsiutil ni la BIOS de la controladora. Así que por un lado podía identificar los discos, pero no cuál estaba desincronizado y, por otro, podía saber cuál está desincronizado pero no identificarlo físicamente. Al final, como tengo backups de los datos realmente importantes y el servidor pelado instalado en un disco virtual, decidí probar fortuna y deshice el raid por hardware. Pero esto no soluciona el problema. El servidor sigue yendo anormalmente lento y creo que ese es el problema del que se derivan todos (quizás incluso el de la eterna resincronización del RAID). Ya desecho el RAID, arranqué con un disco y probé a hacer una actualización de los paquetes actualizados en wheezy. La descarga de los paquetes se hace a velocidad normal; sin embargo, el desempaquetado, sustitución y configuración de los paquetes nuevos es anormalmente lento. Tengo otro servidor en otro sitio para comparar, aunque no tienen el mismo hardware, y no hay color: el servidor que me da problemas puede tardar como 10 veces más en hacer las mismas operaciones triviales. Ambos están practicamente sin trabajo, así que no es un problema de sobrecarga. Tampoco parece un problema de lectura y escritura en disco, porque hice algunas pruebas con dd y hdparm y los resultados eran normales. No sé. En ocasiones el servidor se queda como pillado con un comando y al poco reacciona. Por ejemplo, al instalar hdparm escribí: # aptitude installq hdparm me di cuenta del error nada más pulsar Enter e instintivamente escribí ^C. Sin embargo, el programa no respondía al ^C aunque lo escribí varias veces. Así estuvo como veinte segundos, hasta que finalmente reaccionó y se abortó. :/ Saludos, Saludos y muchas gracias. -- En la vida humana sólo unos pocos sueños se cumplen, la mayoría se roncan. --- Enrique Jardiel Poncela --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150108205242.ga18...@cubo.casa
Re: [OT] Raid por hardware
El Wed, 07 de Jan de 2015, a las 02:23:41PM +, Camaleón dijo: Tienes una página bastante maja donde, además de descargar los drivers y utilidades para las controladoras más comunes, explican un poco el funcionamiento de los comandos básicos para ver el estado de las matrices y los discos, etc... http://hwraid.le-vert.net/wiki/LSI Sí, llegué a ella en mis pesquisas: por ella descubrí la existencia de lsiutil. Te recomendaría que no hicieras movimientos bruscos (me refiero a eso del reset que suena un pelín radical :-P), recuerda que simplemente con reinicializar un disco eliminas todos los datos que contiene, es decir, mucho cuidado al ejecutar cualquier comando en una controladora RAID. Conviene que leas los manuales y FAQ que encuentres para saber exactamente qué hace cada opción. El problema es que la Guía de Usuario de lsiutil: http://www.thomas-krenn.com/de/wikiDE/images/4/44/Lsi_userguide_2006_20130528.pdf apenas explica nada. Y de la opción 21 (RAID options) no dice nada de nada. Me gustaría, por ejemplo, quitar el disco desincronizado del RAID, pero no tengo muy claro si se puede hacer y cómo. Hay una opción Replace physical disk, pero no sé si será eso, porque no lo veo explicado en ningún sitio. También hay otra que es offline physical disk o incluso quiesce physical disk I/Os. También puede que valga fail physical disk, para marcarlo como erróneo. Pero vaya usted a saber. Por otra parte, es posible que no necesites pinchar el disco en una controladora distinta y que puedas pasarle el test de SMART si la tuya lo permite. Le he pasado el test short y el conveyance a ambos discos. Ambos sin problemas. Puedo intentar pasarle el long a lo largo de la noche a ver sí dice algo más. Otro problema que tengo es que físicamente no sé cuál es cuál. -- e non l'arbitrio de femina lieve, che sempre inchina a quel che men far deve. --- Ludovico Ariosto --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150107202317.ga1...@cubo.casa
Re: [OT] Raid por hardware
El Mon, 05 de Jan de 2015, a las 06:57:50PM +, Camaleón dijo: Tengo un pequeño servidor debian con una controladora para hacer RAID, la cual he usado para montar dos discos espejo. ¿Has descartado que el disco esté fallando realmente? No, pero tampoco se muy bien cómo verlo. Tengo una utilidad llamada lsiutil, pero tiene ochocientas mil opciones que no sé muy bien para qué sirven y que no me atrevo a probar ahora mismo, porque esta corriendo el servidor. Cuando pueda accedar físicamente al servidor, tengo intención de pararlo, arrancar con un USB y probar a hacer unos Reset. Si lo cosa no funciona, supongo que intentaré eliminar el disco que no se acaba por sincronizar y le haré pruebas por su cuenta. Los discos no tienen mucho tiempo: llevan funcionando desde mediados de junio y en absoluto han tenido mucha carga, Ni siquiera una carga media. Es más compré Western Digital con etiqueta roja. Te lo comento porque es raro que una actualización de la BIOS de la placa base afecte a una controladora RAID PCI-X/PCI-e (suele interferir con las controladoras integradas o las zero channel), aunque no estaría de más que buscaras alguna actualización del firmware de la BIOS de la tarjeta. Ya, es raro: la controladora va a aparte; pero es que yo no he hecho otro cambio. Un saludo y gracias. -- Tu dulce habla, ¿en cúya oreja suena? --- Garcilaso de la Vega --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150106175553.ga16...@cubo.casa
[OT] Raid por hardware
Un saludo a la lista: Tengo un pequeño servidor debian con una controladora para hacer RAID, la cual he usado para montar dos discos espejo. La controladora es una LSI SAS1064E con la que uso en linux los drivers mpt*. Hast aquí la cosa va bien y ha ido bien durante un tiempo. Hace poco actualicé la BIOS de la placa base por razones que no vienen al caso y no sé si a causa de eso, el RAID ha empezado a darme un problema: uno de los discos está perpetuamente desincronizado. Puedo comprobar que la sincronización se está llevando a cabo (incluso saber el porcentaje que falta para terminar la sincronización con la herramienta lsiutil, pero cuando la sincronización acaba, vuelve otra vez a repetirse y así ad infinitum. No tengo muy claro qué hacer y tampoco he visto mucha información en internet al respecto. Pasado mañana ya tendré acceso físico al servidor y tengo que buscarle alguna solución. A las malas siempre puedo renunciar al RAID por hardware y hacer uno por software con mda, pero es una pena no aprovechar la controladora. Tiene alguien experiencia con este tipo de RAIDs y se le ocurre qué puede estar ocurriendo y qué se puede hacer. Muchas gracias de antemano. -- Todo el mundo se suicidaría si después de suicidarse se pudiera seguir viviendo. --- Enrique Jardiel Poncela --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150105174742.ga28...@cubo.casa
