GNU/Linux - Hilo general

B

#10139 Que penas...

#10140 Bueno, entonces revisaré yo mi comprensión lectora. Pido disculpas.
Lo único que hago de "git" fuera del terminal es resolver conflictos... que VSCode te lo pinta bien amigable (insuperable para mi gusto y hasta donde conozco).

El dia de mañana existirá la lucha "arrastrar bloque" VS "picar por teclado"

1 respuesta
B

.

2
D

Agree. Tema conflicts, comparar ficheros en PRs, mirar el log de commits, etc

En GUI me parece mas intuitivo

Saiko9

Yo para los diffs uso esto por si alguno le interesa:

https://github.com/dandavison/delta

2
B

Hola,

Estoy configurando un automount de usb en la raspberry con estas opciones (la parte que empieza con My version based on the answer above):

https://raspberrypi.stackexchange.com/questions/66169/auto-mount-usb-stick-on-plug-in-without-uuid/66324#66324

Systemd service
Put:

[Unit]
Description=Mount USB sticks
BindsTo=dev-%i.device
After=dev-%i.device

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/automount %I
ExecStop=/usr/bin/pumount /dev/%I

in /lib/systemd/system/[email protected]
Mount script

Put:

#!/bin/bash

PART=$1
FS_LABEL=`lsblk -o name,label | grep ${PART} | awk '{print $2}'`

if [ -z ${FS_LABEL} ]
then
    /usr/bin/pmount --umask 000 --noatime -w --sync /dev/${PART} /media/${PART}
else
    /usr/bin/pmount --umask 000 --noatime -w --sync /dev/${PART} /media/${FS_LABEL}_${PART}
fi

In /usr/local/bin/automount, and then:

sudo chmod +x /usr/local/bin/automount

Reboot.

The mount points/folders names will be in the format of /media/<PartitionLabel>_<sdxy>. In case a partition has no label, it will just be /media/<sdxy>.

So, I normally label my USB drives with their capacity. e.g. 8G, 16G. When I plug in multiple USB disks with the same label, I can still distinguish them as, for example:

/media/500G_sdb1
/media/500G_sdc1

HJe revisado en la anterio raspi y parece que tengo todo igual, pero no me monta el usb en el arranque. Que puede ser ? hay algun log para consultar la salida de la ejecucion del script ?

EDIT:
Si ejecuto a mano el automount:

pi@raspberrypi:/usr/local/bin $ ./automount
Usage: grep [OPTION]... PATTERNS [FILE]...
Try 'grep --help' for more information.
Error: invalid device /dev (must be in /dev/)

2 respuestas
Saiko9

#10145 Nunca he puesto un automount de esos en caliente, siempre he tirado de fstab para que se monte solo en el inicio del sistema y ya esta asi que no te puedo ayudar mucho.

De todas formas:

  • Ese script tiene pinta de que es un Hook de algo, donde lo metes? enterate bien de eso y quien lo llama.
  • Al ser un hook no puedes tirarlo tal cual como lo estas tirando, ten en cuenta que estas cogiendo en el script $1 para pasarselo al grep, si lo tiras a mano tienes que hacer lo mismo que hará el proceso que le llame.
  • para el tema de los logs pues depende de la distro suele tener alguno (no se si esta estandarizado ya):
    • /var/log/syslog
    • /var/log/messages
    • /var/log/secure
    • Puede que incluso usando journalctl
    • ....
1 respuesta
B

#10146 está todo en el enlace que pongo.

Aún tengo la instalación vieja en otra SD, voy a seguir mirando a ver que se escapa. Pero esta claro que con esas opciones solo no va.

Me mola hacerlo así porque te monta el usb que le pinches, sin tener que andar poniéndolo en fstab.

preguntitas

Habilitas el servicio y lo inicias con systemctl?

B

#10145 Necesitas la regla udev del post anterior.

1 respuesta
B

#10149 vas a tener razón, en la pi vieja lo tengo. Mañana lo compruebo. Thx

EDIT: Confirmo, funciona.

14 días después
thelegend

Buenas a todos, tengo un problema con zsh+ oh my-zsh que la verdad ya no sé cómo arreglarlo...

Cada vez que entro a la terminal, tengo que poner source .zshrc para que recargue la conf, pero ¿no hay una manera más óptima?

1 respuesta
B

#10151 Que resultado te da ejecutar antes de hacer el 'source ...':

echo $SHELL

??

1 respuesta
thelegend

#10152
/usr/bin/zsh

Gracias por contestar, pero al final lo solucioné, por alguna razón, el .zshrc de la home ya no es el archivo de configuración por defecto, sino .config/zsh/.zshrc

2 respuestas
-Orion-

#10153 Ahí es donde deberían estar todos jajaja

B

#10153 Vale, lo que pasó es que se te cambió la variable de entorno: $ZDOTDIR

Doest

En casa uso mi PC con Xubuntu 20.04 y otro Xubuntu pero hace su papel de server para copias de seguridad.

Ambos se ven en red y uso rsync para hacer copias de seguridad de forma incremental del home para no perder nada.

El problema es que al querer conectarme al servidor mediante ssh o hacer el backup por rsync, de forma aleatoria me aparece el error:

Unable to negotiate with 192.168.1.70 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

Y ya he probado lo que dicen por internet de que debes editar el archivo config (home/user/.ssh/config), he incluir abajo del todo

Host *
KexAlgorithms +diffie-hellman-group-exchange-sha1

O directamente habilitar la conexión X host específicos:

Host 192.168.1.70
KexAlgorithms +diffie-hellman-group-exchange-sha1

Dicha config la tengo aplicada en el cliente (192.168.1.10) y servidor (192.168.1.70) y como si nada... Me sigue apareciendo 🤦‍♂️

Como dato. Si accedo al servidor, me cargo known_host y hago un ssh al cliente. Este me manda un nuevo hash.

Pero al tiempo vuelvo de nuevo arriba del todo para tener el mismo palo de siempre

Alguien sabe del tema?

1 respuesta
neil90

Siendo Linux recientes no tiene sentido que sólo ofrezcan diffie-hellman-group1-sha1.
Prueba con

ssh -vvvv

y/o

nmap -sV -p 22

Por otro lado, la IP del mensaje de log no parece la misma de tu red local, ¿estás lanzando conexiones desde un docker?

1 respuesta
madaleno

#10156 ¿Después de los cambios has reiniciado el servicio?

1 respuesta
Doest

#10158 Si. He probado con

sudo /etc/init.d/ssh restart

sudo service ssh restart

sudo systemctl restart ssh

Por /etc/init.d me avisa de que el servicio se ha reiniciado correctamente.

Por service o systemctl no se menciona nada. Pero ejecutando «sudo service ssh status» me devuelve que está activo y en funcionamiento

1 respuesta
madaleno

#10159 Pues no debería de darte fallo. Mira si te hace lo mismo especificándolo en la conexión de ssh directamente con: -oKexAlgorithms=+diffie-hellman-group1-sha1

Ej: ssh -o KexAlgorithms=diffie-hellman-group1-sha1 [email protected]

Prueba a editar el sshd_config:

#Legacy changes
KexAlgorithms diffie-hellman-group1-sha1,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
Ciphers 3des-cbc,blowfish-cbc,aes128-cbc,aes128-ctr,aes256-ctr

1 respuesta
Doest

#10157

Siendo Linux recientes no tiene sentido que sólo ofrezcan diffie-hellman-group1-sha1.
Prueba con

ssh -vvvv
y/o

nmap -sV -p 22
Por otro lado, la IP del mensaje de log no parece la misma de tu red local, ¿estás lanzando conexiones desde un docker?

Si. Ambos son 20.04.

Sobre la red 172. Tengo montado un Vbox con esa red para hacer pruebas y se me había pasado poner la dirección del servidor real que es la 192.168.1.70.

Ya lo he corregido en ese mensaje 😅

Probaré ejecutar ssh -vvvv, que parece decirme detalladamente que pasa 👍

__
#10160 Será cuestión de probar. Porque me está tocando ya los santos coj***es de que el server se blinde el solo por dentro y tenga que meterme manualmente, y hacer el ssh hacia el cliente para que la cosa se arregle 😑

De todas maneras. Hay manera de cambiar el método de encriptacion para conectarte mediante ssh?

Porque no veo caso de estar perdiendo el tiempo en pelearme con este algoritmo que según se lee, está obsoleto y solo sirve para usarlo bajo equipos viejos que no se les puede elevar más arriba en temas de seguridad.

EDIT:
He probado meter la orden que recomiendas usar:

ssh -o KexAlgorithms=diffie-hellman-group1-sha1 [email protected]

Pero me devuelve:

Unable to negotiate with 192.168.1.70 port 22: no matching cipher found. Their offer: aes128-cbc,3des-cbc 🤷‍♂️

Ya si me meto manualmente dentro del server, hago un ssh al cliente y más tarde hago un ssh al servidor. Todo funciona correctamente.

Si lanzó el ssh -o, algo hace mal porque sale lo siguiente:

Unable to negotiate with 192.168.1.10 port 22: no matching key exchange method found. Their offer: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256

Si añado lo que recomiendas dentro de sshd_config y reinicio el servicio. systemctl me marca un bonito fail y el cliente simplemente me dice ssh: connect to host 192.168.1.70 port 22: Connection refused

Que se resuelve todo si quito lo del sshd y reinicio nuevamente el servicio
...

Si veo que se me resiste. Este fin de semana haré backup de todo y le daré cera para ponerlo todo nuevamente desde abajo 🤦‍♂️

B

Prueba a crear una nueva "llave" en el equipo cliente:

ssh-keygen

Luego la añades al servidor ejecutando desde el cliente:

ssh-copy-id usuario_remoto@direccion_remota

Si todo fué bien y tienes el agente ssh levantado y con acceso, deberias de poder hacer operaciones por ssh sin mayor problema.

1 respuesta
Doest

#10162 Gracias por el aporte. Pero ese proceso sirve simplemente para generar llaves ssh y mandarsela al equipo que nos interese y evitar las siguientes veces tener que escribir la contraseña de acceso (que para procesos de backup por rsync bajo crontab viene de fábula 👌)

Probé realizar los procesos que se describe aquí (https://alteageek.com/2019/12/15/error-en-osx-macos-no-matching-key-exchange-method-found-their-offer-diffie-hellman-group1-sha1/)

Y parece que me funciona (Toquemos madera)

imnothing

Estoy teniendo problemas para reiniciar mi portatil con Linux Mint 19.1 desde hace unos días. Lo he notado más lento, con errores, y hoy directamente no me guardaba un archivo de texto que estaba escribiendo. Al reiniciar me está dando errores en el sistema de archivos y sólo he podido entrar con opciones avanzadas.

Sospecho que esto viene de dejar la computadora toda la noche en suspensión, a raíz de ello me ha dado algún que otro cuelgue, y de ahí a reiniciar forzadamente.

Ahora lo que trato es de hacer un escaneo y reparación completa con el comando fsck desde la consola. Cuando le digo desmontar la unidad, aún siendo en el arranque, no me deja y no puedo hacer el escaneo y reparación.

He tratado también desde el SO, en la opción "discos" hacer un chequeo y no desmontar la unidad. En fin, no hay manera de programar un chequeo y reparación para el siguiente reinicio? Consejos y ayuda, bienvenidos sean =)

1 respuesta
eondev

#10164 livecd

1 respuesta
imnothing

#10165 no tengo lector cd xD Estoy mirando de montar en un memoria usb un live. De momento he programado un chequeo tras el reinicio. A ver que pasa y si no a montar un liveusb

1 respuesta
eondev

#10166 eso hombre, un usb live. Tú me entiendes xDD

imnothing

Bueno, al final lo he actualizado de 19.1 a 20.2, estoy contento con el cambio, pero lo más importante es que arranca sin problemas. Ya no vuelvo a dejar el equipo en suspensión. ¡Gracias!

nV8x

Los que usáis PLC, habéis tenido problemas en Linux?

Uso unos de Devolo y se me interrumpe la conexión cuando estoy descargando algo a maxima velocidad. Me solía ocurrir cuando descargaba por torrent, y descubrí que bajando el número de conexiones del cliente se arreglaba la cosa. Pero ahora estoy descargando un juego de Steam y se me corta cada 2 por 3 y tengo que desenchufar y enchufar de nuevo el PLC... No se si son por los drivers, por el propio PLC que está en las últimas o qué, pero me fastidia mucho.

Creo además que el problema se agrava en verano.

2 respuestas
neil90

#10169 Los PLCs usan las líneas eléctricas, cuanto más ruido haya (más aparatos consumiendo y radiando de algún modo) más errores de transmisión habrá. No es cosa del OS.