Posts tagged "Configuraciones":
Bloqueando las llamadas de spam automáticamente en Android
Hace tiempo que no publicaba nada nuevo, no porque no tenga cosas que contar sino, más bien, porque no soy capaz de encontrar el tiempo y la calma necesaria para hacerlo. Hoy comparto un tema que he descubierto recientemente.
Seguro que has comprobado que la app del teléfono Android que tienes, cuando recibes una llamada te indica si puede considerarse spam, es decir, una llamada no deseada que suele corresponderse con la que realiza alguien desde el otro lado del teléfono para venderte algo, con la habilidad de hacerlo siempre en la hora más inoportuna. Posteriormente, estas llamadas también aparecen en el listado de llamadas recientes identificadas como spam.
Pues bien, hace poco descubrí como bloquear estas llamadas. Bloquear significa que las llamadas llegan al teléfono pero este ni te suena ni te deja aviso de llamada perdida, aunque luego, cuando miras en el historial, allí están.
Veamos cómo hacerlo (comprobado que funciona en teléfonos con versiones de Android 9 y superiores):
#1# Pulsamos sobre la app del teléfono, esta:

#2# Pulsamos sobre los tres puntitos que hay al final de la barra de búsqueda:

#3# En el menú que aparece, pulsamos sobre "Ajustes":

#4# En la pantalla a la que llegamos pulsamos sobre "Identificación de llamada y spam":

#5# Y ahora, en el último paso, activamos la opción "Filtrar llamadas de spam" así:

A partir de este momento las llamadas que "Android" ya reconozca como "spam" te llegarán al teléfono pero ni te sonará ni te dejará aviso de llamada perdida, aunque, como decíamos antes, si entras en el listado de llamadas recientes sí las verás. En la siguiente imagen puedes ver como las veo yo en mi Motorola (izquierda) y un amigo en su Samsung (derecha):

Si quieres ayudar "al sistema Android" a identificar llamadas de spam que aún no son reconocidas, haz esto: en el listado de llamadas recientes, pulsa y mantén un momentito pulsado la llamada que has recibido, cuando se despliegue el siguiente menú de opciones, pulsa sobre "Bloquear/Marcar como spam".

Mediante inteligencia colectiva, si todos lo vamos haciendo, Android irá aprendiendo qué números son los molestos y acabará identificando su llamada como spam. Y con la configuración vista arriba, nosotros estaremos protegidos de las infinitas molestias que nos ocasionan.
¡Por un mundo más humano! ¡Por un mundo con menos ruido!
Comentarios
Felicitaciones (Rogelio G (no verificado) Sáb, 14/05/2022 - 13:42)
He seguido paso a paso las indicaciones y en mi Samsung S9 con versión 10 de Android funciona perfectamente…
Un gran paso hacia la tranquilidad.
Muchas gracias.
Muchas gracias a ti, amigo (Godofredo Fdez. Sáb, 14/05/2022 - 13:44)
Muchas gracias a ti, amigo, por compartirlo ;-)
Cómo activar "tap to click" en GNU/Linux (Debian)
Obtenido de aquí (Activate tap to click on touchpad?): https://unix.stackexchange.com/questions/337008/activate-tap-to-click-on…
¿Qué es "tap to click"? Es el efecto de dar un golpecito en el "touchpad" (panel que hace de ratón en muchos portátiles, sobre todo modernos) para hacer click, pero sin llegar a hundirlo (si lo hundes sería simplemente "hacer click") ;-). Y la verdad es que cuando te acostumbras es más cómodo y más rápido.
Lee el artículo completo, hasta el final, antes de hacer nada.
Funciona si llevas a cabo los siguientes pasos (comprobado en Debian Buster):
#1# Elimina el paquete "xserver-xorg-input-synaptics". (importante)
apt remove xserver-xorg-input-synaptics
#2# Instala este otro "xserver-xorg-input-libinput":
apt install xserver-xorg-input-libinput
En muchos casos es suficiente con comprobar que tenemos instalado el paquete "xserver-xorg-input-libinput", y no este otro "xserver-xorg-input-synaptics package".
#3# Como root:
#3.1# Si no existe, crea este directorio "etc/X11/xorg.conf.d"
mkdir /etc/X11/xorg.conf.d
#3.2# Si no existe, crea este fichero "40-libinput.conf" (basta con hacer copy/paste de lo que sigue en una línea de comandos):
echo 'Section "InputClass" Identifier "libinput touchpad catchall" MatchIsTouchpad "on" MatchDevicePath "/dev/input/event*" Driver "libinput" Option "Tapping" "on" EndSection' > /etc/X11/xorg.conf.d/40-libinput.conf
#3.3# Rearranca con "Desktop Manager" (o apaga y enciende), por ejemplo:
systemctl restart lightdm
o
systemctl restart gdm3
Para más información, puedes consultar esto: Debian wiki : Enable tapping on touchpad ( https://wiki.debian.org/SynapticsTouchpad#Enable_tapping_on_touchpad ).
Salud!
Envío de email cuando hay un login por ssh
En máquinas conectadas directamente a Internet (y esto incluye el acceso a ellas vía un puerto abierto del Firewall), es recomendable estar atento a los "logins de usuario" que se producen. En entornos profesionales, además del aviso de correo que programamos aquí, es conveniente hacer uso de otras herramientas tipo SIEM o HostIDS. En mi servidor, que es pequeñito y con pocos recursos, yo utilizo lo que sigue.
He agregado esto al fichero "/etc/pam.d/sshd".
# Envío de correo cuando login session optional pam_exec.so /root/bin/send-mail-on-ssh-login.sh
El fichero completo (/etc/pam.d/sshd), como referencia y copia de seguridad, está adjunto aquí (le he agregado la extensión .txt para que sea "leible" desde el blog).
Y he creado el script correspondiente en "root/bin" con este contenido:
#!/bin/sh if [ "$PAM_TYPE" != "open_session" ] then exit 0 else { echo "User: $PAM_USER" echo "Remote Host: $PAM_RHOST" echo "Service: $PAM_SERVICE" echo "TTY: $PAM_TTY" echo "Date: `date`" echo "Server: `uname -a`" } | mail -s "$PAM_SERVICE login on `hostname -s` for account $PAM_USER" example@example.com fi exit 0
¡OJO!: has de modificar la dirección de mail "example@example.com" por la tuya propia donde quieres recibirlos.
Referencias:
1.- http://blog.th-neumeier.de/2011/02/send-email-on-ssh-login-using-pam/
3.- http://www.tiger-computing.co.uk/get-notified-with-every-ssh-login/
4.- http://www.farinspace.com/secure-login-linux-server/
5.- http://www.mydigitallife.info/how-to-get-linux-server-sends-email-alert-on-root-login/
Para avisar cuando alguien hace login como root (no permitido por ssh, sólo como "promoción interna" ;-)), añadimos al .bashrc de root lo siguiente (¡¡OJO!! No hagas copy/paste de esta línea. Es mejor que la teclees pues debe de haber -introducidos por el "parser" de coloreado de sintaxis- códigos de control extraños en algunos caracteres que no funcionan si la copias):
echo 'ALERT - Root Shell Access () on:' `date` `who` | mail -s "Alert: Root Access from `who | cut -d"(" -f2 | cut -d")" -f1`" example@example.com
Espero que te sea útil.
Si consideras alguna parte mejorable, por favor, indícamelo con un comentario. Como siempre, te estaré muy agradecido.
Cómo dejar de ver la sección "Personas" en Lineage OS (Android)
Llevaba un tiempo que, al buscar un contacto en Android, obtenía información del contacto buscado y también una sección "Personas" en la que aparecían, siempre, supuestos "contactos alemanes" que no tenían nada que ver conmigo. Mira:

Después de pelearme un rato con Google, haciendo búsquedas que me indicaran de dónde podrían venir esos "supuestos contactos" que aparecían en dicha sección, he sido capaz de encontrarlo por mí mismo, con esa extraña mezcla de intuición y suerte.
Está todo explicado en este pdf. Si a ti también te ocurre, y estás cansado de que sea así, abre dicho pdf y sigue los pasos indicados.
Yo estoy usando "Lineage OS" (sobre el que escribiré un artículo pronto), si tú estás utilizando la versión de Android que venía (o se actualiza automáticamente) en tu teléfono, por favor, déjame un comentario para que sepa que también ocurre en otros teléfonos con otras versiones del sistema operativo.
¡Gracias!
Eligiendo el sistema operativo que Grub arranca por defecto
Hola.
Este artículo es un resumen de las indicaciones "que funcionan" (lo he probado) recogidas en este hilo de la comunidad de Ubuntu: https://askubuntu.com/questions/52963/how-do-i-set-windows-to-boot-as-the-default-in-the-boot-loader
Así, procedemos de esta forma:
#1# Listamos el número y detalle de los sistemas que ha detectado Grub en nuestro equipo:
godo@TuChi:~$ fgrep menuentry /boot/grub/grub.cfg if [ x"${feature_menuentry_id}" = xy ]; then menuentry_id_option="--id" menuentry_id_option="" export menuentry_id_option menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-bb5b1d8f-283e-4ea2-905f-630da5f13971' { submenu 'Opciones avanzadas para Debian GNU/Linux' $menuentry_id_option 'gnulinux-advanced-bb5b1d8f-283e-4ea2-905f-630da5f13971' { menuentry 'Debian GNU/Linux, con Linux 4.9.0-9-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.9.0-9-amd64-advanced-bb5b1d8f-283e-4ea2-905f-630da5f13971' { menuentry 'Debian GNU/Linux, with Linux 4.9.0-9-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.9.0-9-amd64-recovery-bb5b1d8f-283e-4ea2-905f-630da5f13971' { menuentry 'Windows 10 (en /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-chain-01D317734DAEB710' { menuentry 'Windows 10 (en /dev/sdc1)' --class windows --class os $menuentry_id_option 'osprober-chain-01D163EEA0DA4380' { godo@TuChi:~$
#2# Podemos observar, después de la palabra clave "menuentry", el nombre de las "entradas del menú de arranque que muestra Grub" entre comillas simples, por ejemplo: 'Windows 10 (en /dev/sdc1)'.
#3# Editamos el fichero: /etc/default/grub, así:
root@TuChi:/etc/default# nano grub
Podemos ver cómo queda:
root@TuChi:/etc/default# more grub # If you change this file, run 'update-grub' afterwards to update # /boot/grub/grub.cfg. # For full documentation of the options in this file, see: # info -f grub -n 'Simple configuration' GRUB_DEFAULT=0 #GRUB_DEFAULT="Windows 10 (en /dev/sdc1)"
#4# La opción
"GRUB_DEFAULT=0"
controla la entrada por defecto que va a ser arrancada. Aquí, donde lo vemos igualado a "cero", significa que arrancará la primera entrada que haya en el menú de arranque, en mi caso, 'Debian GNU/Linux, con Linux 4.9.0-9-amd64'. Si queremos que arranque otra, podemos indicarle el nombre de la entrada deseada, según lo hemos visto antes aparecer tras la palabra "menuentry", pero utilizando comillas dobles. Por ejemplo, así:
GRUB_DEFAULT="Windows 10 (en /dev/sdc1)"
#5# No olvidar nunca esto para actualizar el "verdadero" cargador de arranque de nuestra máquina:
root@TuChi:/etc/default# update-grub Generando un fichero de configuración de grub... Found background image: /usr/share/images/desktop-base/desktop-grub.png Encontrada imagen de linux: /boot/vmlinuz-4.9.0-9-amd64 Encontrada imagen de memoria inicial: /boot/initrd.img-4.9.0-9-amd64 Encontrado Windows 10 en /dev/sda1 Encontrado Windows 10 en /dev/sdc1 hecho root@TuChi:/etc/default#
Y eso es todo.
Utilizando "sudo" en Debian o como jugar a ser Dios
De todos es sabido, y espero que aún más entre los lectores de esta pequeña gota de agua, insignificante, en el océano de Internet, que trabajar con privilegios de administrador (terminología Windows) o superusuario (terminología Unix) en nuestro sistema durante el día a día está totalmente desaconsejado. Como otras muchas veces, Unix se adelantó a Windows (hoy en día esta ventaja ya no es tal, Windows también lo resuelve perfectamente) en esta separación de roles y, de hecho, desde el mismo momento de la instalación de un sistema Unix se obligaba al usuario que lo estaba instalando a:
- Elegir la contraseña de root. "root" siempre es el usuario con máximos privilegios: puede instalar y desinstalar aplicaciones, puede modificar/borrar ficheros del sistema… puede ver los buzones de correo de otros usuarios, e incluso puede borrar archivos y "cuentas" completas de otros usuarios (de hecho, es él quien las crea). Por eso, en el argot de los que trasteamos con los sistemas, cuando adoptamos el rol de root solemos describirlo como "me voy a convertir en Dios", porque es omnipoderoso.
- A elegir una cuenta de usuario "normal", sin privilegios, que sólo puede utilizar las aplicaciones instaladas por root, no puede ni instalar ni desinstalar, ni modificar partes críticas, clave, del sistema, ni ver los ficheros "confidenciales" de otros usuarios (siempre que los permisos estén bien puestos), etc.
Pero es más, y este es el verdadero quid de la cuestión: desde el inicio, desde el primer "login" a la máquina, el usuario con el que se trabaja (esto es flexible según la distribución, pero hay algunas que lo obligan) es el usuario normal. Y todo el mundo que utilizamos Unix o GNU/Linux en nuestro día a día así lo hacemos.
Pero, ¿qué pasa si en un determinado momento necesitas hacer algo como root? Pues Unix también resolvió esto hace mucho tiempo. Cuando aún no había entornos gráficos los sistemas Unix ya eran multiusuario y multitarea. Habrías otra consola, como si tuvieras varias pantallas para trabajar sobre la misma pantalla física, y entrabas como root. Pero ni siquiera eso era/es necesario: puedes cambiar tu personalidad y pasar a ser root haciendo uso del comando "su", que te pide la contraseña de root y, si la sabes, te convierte en root:
[23:07:39(godo@surco)~]> su Contraseña: [23:21:41(root@surco)/home/godo]#
Y ya puedes estar trabajando un rato (no sólo un comando, sino muchos) como root. Y esto es importante para entender la principal diferencia con sudo. ¿Qué permite sudo? sudo permite ser root "sólo" para ejecutar un comando, cuando ese comando termina sigues siendo tú, ese usuario normal sin privilegios. ¿Y qué comando es el que te permite ejecutar sudo? Esta es la segunda clave del tema: sólo aquellos para los que te haya autorizado root a "echarle una mano". Imagínate que quieres montar una determinada partición de una máquina que suele estar desmontada porque en ella se albergan las copias de seguridad. El administrador de esa máquina, root, puede delegarte sólo esa tarea. Para ello en el fichero /etc/sudoers (que nunca se edita de forma directa sino haciendo uso de la utilidad "visudo") root puede escribir estas líneas:
godo ALL=(ALL) NOPASSWD: /bin/mount
(NOPASSWD es para que no te solicite password. Si no se pone, te la solicitaría).
Así, el usuario "godo" puede utilizar sudo "sólo" para ejecutar el comando "mount" como superusuario.
Si el usuario "godo" no estuviera "capacitado" para ejecutar un comando vía "sudo", y aún así lo intentara, "root" sería notificado vía mail, siendo este que sigue el "cuerpo" del correo:
surco : Jun 27 20:33:40 : godo : user NOT in sudoers ; TTY=pts/0 ; PWD=/home/godo ; USER=root ; COMMAND=/usr/bin/apt-get update
¿Qué hacen distribuciones como Ubuntu, y yo suelo configurar en mi Debian? Pues Ubuntu directamente impide que root haga "login" en la máquina, es decir, siempre has de entrar en el sistema con el usuario sin privilegios, y si necesitas utilizar "cualquier comando" (sin límites) en modo "privilegiado" recurres a "sudo". De hecho, "root" en Ubuntu no tiene contraseña y nunca puedes acceder a ser "root" de forma "total" (no funciona "su" hasta que no le pones contraseña a "root" utilizando "sudo" ¡Curioso!). Para que un usuario normal tenga acceso a todos los comandos de "root" sin llegar a "serlo", es decir, vía "sudo", basta que siendo "root" se agregue al usuario "godo", en mi caso, al grupo de usuarios de "sudo" (recuerda que Unix hay grupos de usuarios que comparten "permisos"). Así es como yo lo hago en Debian, supongo que en Ubuntu se hace algo parecido durante la instalación del sistema.
Yo, para recordar esto cuando hago una instalación nueva, conservo unas líneas explicativas en el fichero "sudoers" de mi máquina habitual, que agregué con "visudo", claro. Y desde ahora las conservo aquí también y las comparto con vosotros. Son estas:
[23:30:49(godo@surco)~]> more /etc/sudoers more: no se puede abrir /etc/sudoers: Permiso denegado [23:30:57(godo@surco)~]> sudo more /etc/sudoers [sudo] password for godo: # # This file MUST be edited with the 'visudo' command as root. # # Please consider adding local content in /etc/sudoers.d/ instead of # directly modifying this file. # # See the man page for details on how to write a sudoers file. # # ¡¡OJO!! MIRA UN POCO MAS ABAJO. BASTA CON: # 1. AÑADIR EL USUARIO godo AL GRUPO sudo. # 2. CERRAR LA SESIÓN Y VOLVER A ENTRAR. # Defaults env_reset Defaults mail_badpass Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" # Host alias specification # User alias specification # Cmnd alias specification # User privilege specification root ALL=(ALL:ALL) ALL # Allow members of group sudo to execute any command # Agregamos a Godo al grupo sudo con: # [20:32:31(root@surco)/var/log]> adduser godo sudo # Añadiendo al usuario `godo' al grupo `sudo' ... # Añadiendo al usuario godo al grupo sudo # Hecho. # Otra forma de hacerlo es: # [20:37:04(root@surco)/home/godo]> gpasswd -a godo sudo # Añadiendo al usuario godo al grupo sudo %sudo ALL=(ALL:ALL) ALL # See sudoers(5) for more information on "#include" directives: #includedir /etc/sudoers.d [23:31:12(godo@surco)~]>
Observad al principio, cuando ejecuto el comando "more", como con mi usuario no tengo permisos para ver el fichero, pero sí utilizando "sudo".
Una última cosa, antes hablé de "su", y de que la contraseña que te solicita es la de "root", es decir, te tienes que saber la contraseña de "root", por tanto, cuando utilizas "su" te conviertes en root de "manera ancha". Sin embargo "sudo" no nace para hacer lo mismo que "su", aunque puede "casi llegar a hacerlo", sino que lo que quiere conseguir es un acceso a "hacer uso de privilegios" de forma más granular. Lo que te solicita por tanto no es la contraseña de "root", esta puede seguir siendo totalmente privada para "root" (¡root/Dios sólo hay uno!), sino la tuya, con el único fin de dejar "huella" en el sistema y que "root" sepa quién ha hecho qué. ¡Una verdadera maravilla del ingenio humano!
Espero que os haya gustado y que os acostumbréis a usarlo. Pero sobre todo, que os ayude a pensar.
Y el séptimo día descansó.
Sin telnet en Windows 10
Quizá a alguno de vosotros le haya pasado lo que a mí: voy a conectarme hoy a un viejo dispositivo que sólo permite conexiones utilizando "Telnet", y no puedo. Desde el interfaz de comandos de mi Windows 10 obtengo este error:
"telnet" no se reconoce como un comando interno o externo, programa o archivo por lotes ejecutable.
Me ha extrañado por dos motivos:
- ¿Windows 10 no trae telnet instalado por defecto? La respuesta es no. Más información aquí (con solución autóctona Windows 10 incluida).
- ¿Y mi instalación de Cygwin tampoco? Pues la respuesta, obviamente, también era negativa.
Así que arranco mi "setup-x86.exe" para instalar "telnet" desde los repositorios de Cygwin, y me encuentro que no existe ningún paquete llamado "telnet". Buscando por la red descubro dos cosas:
- Para instalar "telnet" hay que seleccionar el paquete "inetutils".
- En el sitio donde encuentro lo anterior, aquí, descubro que su autor utiliza un comando muy parecido a "apt-get" (maravilloso gestor de paquetes del mundo Debian que por mi histórico, como sabéis los lectores de este blog, controlo bastante bien), en concreto: "apt-cyg", que tiene toda la pinta de funcionar de forma muy parecida a la "suite apt" original… ¡A investigar!
En los primeros resultados de esta búsqueda creo que hay material suficiente para profundizar en el uso de "apt-cyg".
Conclusión: si quieres utilizar "telnet" en Windows 10 y eres usuario habitual del "port" del mundo GNU/Linux vía "Cygwin", instala el paquete "inetutils":
[15:39:35(godo@surco)~]> telnet --version telnet (GNU inetutils) 1.9.1 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later . This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by many authors.
Obviamente, creo que no tiene sentido instalar Cygwin sólo para esto, pero si ya lo utilizas para hacer otras muchas cosas, sí que lo tiene. Sin embargo, si sólo necesitas "telnet", instálalo desde el propio Windows como comentan aquí.
¡Salud, amigos!
P.D.: ni que decir tiene que el uso de "telnet" está tremendamente desaconsejado (toda la información viaja en claro entre tu extremo y el otro) y que, siempre que se pueda, es mejor utilizar "ssh".
Comentarios
Guillermo (no verificado Lun, 05/12/2016 - 09:46)
Después del ultimo intento con telnets, sshs y demas encontre mobaxterm (http://mobaxterm.mobatek.net/) y me sorprendió. Lo primero es portable, con lo que te olvidas de instalar cosas (sabras por lo que te lo comento) y después emulaba un entorno X en le PC que es muy útil en algunos momentos. Pruebalo un día que estes aburrido, a mi me gustó.
Godofredo Fdez. (Mié, 07/12/2016 - 20:27)
Muchas gracias por dejarme esta referencia, Guillermo. Le he echado un vistazo y tiene buena pinta (aunque no he llegado a instalarlo). La verdad es que desde que instalé Cygwin en mis Windows he automatizado muchas cosas que venía automatizando ya en mis GNU/Linux, reaprovecho scripts y conocimientos. Además tengo todo lo que necesito: ssh, telnet, x-windows, etc. Como ya he dicho en el artículo, instalar Cygwin sólo para el telnet o incluso el ssh me parece un desperdicio, pero si lo utilizas para muchas más cosas del mundo Unix/Linux creo que es una inmejorable alternativa.
Seguimos compartiendo.
Gracias de nuevo por el comentario.