#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"
Agree. Tema conflicts, comparar ficheros en PRs, mirar el log de commits, etc
En GUI me parece mas intuitivo
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):
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_sdc1HJe 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/)
#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:
#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.
#10149 vas a tener razón, en la pi vieja lo tengo. Mañana lo compruebo. Thx
EDIT: Confirmo, funciona.
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?
#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
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?
Siendo Linux recientes no tiene sentido que sólo ofrezcan diffie-hellman-group1-sha1.
Prueba con
ssh -vvvvy/o
nmap -sV -p 22Por otro lado, la IP del mensaje de log no parece la misma de tu red local, ¿estás lanzando conexiones desde un docker?
#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
#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
Siendo Linux recientes no tiene sentido que sólo ofrezcan diffie-hellman-group1-sha1.
Prueba conssh -vvvv
y/onmap -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
Prueba a crear una nueva "llave" en el equipo cliente:
ssh-keygenLuego la añades al servidor ejecutando desde el cliente:
ssh-copy-id usuario_remoto@direccion_remotaSi todo fué bien y tienes el agente ssh levantado y con acceso, deberias de poder hacer operaciones por ssh sin mayor problema.
#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)
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 =)
#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
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!
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.
#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.
