Por último: según el nivel de control que se ejerza sobre las máquinas de los usuarios, pueden llegar a manejarse grandes masas de información. Piensa que controlarás cada sesión de usuario, cada consulta, modificación y creación de datos, cada conexión y desconexión, etc. En mi empresa llegué a manejar tablas de casi un millón de registros... y no veo a sqlite manejando tal volumen de datos y mucho menos a JSON.

Efectivamente, según el nivel de control que se ejerza. Reitero, un autónomo que mantiene actualizado los sistemas de sus clientes no necesita en absoluto manejar un millón de registros, en esencia solo necesita unos pocos datos para funcionar. Es verdad que el portátil te lo pueden robar se puede estropear etc. por eso basta una copia de seguridad en un servidor y listo.

Todo paso más allá de "soy aficionado y me divierto trasteando con mis programitas" pasa por una base de datos, o propia o contratada. ¿Es que no piensas tener una web? ¿Qué web no trabaja contra una Base de datos? Pues ahí la tienes.

No es lo que digo, de hecho me encantan las bases de datos y el lenguaje SQL. Lo que digo es que para algunas cosas no son necesarias, por ejemplo para tener listados los ordenadores y controlar su estado basta y sobra con un json.
Claro que para una web dinámica, un programa de contabilidad o un gestor de almacén es imprescindible pero para conectarse por ssh pegar un vistazo y actuar en consecuencia también por ssh, claro que mediante un front end en gambas para mas facilidad, no lo veo necesario.
Yo lo veo así, y acá me sale el treker , Tricorder es un front end que sirve para mantener actualizados los PC de nuestros clientes.
Es una interfaz hecha en gambas que guarda los datos de funcionamiento en un archivo JSON y los datos de las computadoras gestionadas en otro JSON

Saludos.

Perdonad que me inmiscuya en la discusión, pero voy a aportar mis dos céntimos.

No tengo dudas de que JSON es un formato súper útil, rápido y además legible por humanos, pero carece de mecanismos para preservar su propia integridad. Si en una "transacción" queda truncado por un problema en la red o un corte repentino de corriente, adiós sistema.

Por otra parte, las BBDD sí que tienen un sistema de transacciones real que preserva su integridad aunque se interrumpa dicha transacción, que no será efectiva hasta en último "commit". Ya no hablamos del otro tipo de integridad (referencial) y el manejo de tipos de datos y operaciones de todo tipo (matemáticas y de cadenas), filtros, etc. dentro de la propia BD.

Coincido con tincho, sin embargo, en que para unos pocos registros sencillos una BD MySQL es como matar moscas a cañonazos, pero aún así, para un proyecto profesional y si el programa va a usar bases de datos para más cosas que los logins y el control, desde luego mi preferencia sería siempre una BD seria, como MySQL o Postgres.

Saludos

Lo que digo es que para algunas cosas no son necesarias, por ejemplo para tener listados los ordenadores y controlar su estado basta y sobra con un json.

Efectivamente, pero sospecho que no estamos hablando de lo mismo y que tenemos en mente objetivos y metas distintas. El proyecto Intriga intenta hacer lo que hace: el mantenimiento del hardware y software de una empresa y el control y gestión de los usuarios sus actividades dentro del sistema. El presunto "autónomo" que no intenta controlar nada encuentra aquí cubiertas sus necesidades dejando de utilizar el 80% de las posibilidades del entorno. Es como hacer la lista de la compra con el LibreOffice Writer. ¿Para qué tanto botón y menú? Con el nano es suficiente...
 

Coincido con tincho, sin embargo, en que para unos pocos registros sencillos una BD MySQL es como matar moscas a cañonazos, pero aún así, para un proyecto profesional y si el programa va a usar bases de datos para más cosas que los logins y el control, desde luego mi preferencia sería siempre una BD seria, como MySQL o Postgres.

Intriga se compone de 37 tablas relacionadas entre sí más unas 10 vistas fijas sobre la interrelación de las mismas para facilitar la confección de consultas sql.
Aún así espero poder reducirlas, que algunas contienen cosas relativas a mi ex-empresa y eliminando esas y derivando las que no a otras tablas podría eliminar alguna que otra tabla. En ello estoy... pero JSON, ni de lejos.

Saludos

No tengo dudas de que JSON es un formato súper útil, rápido y además legible por humanos, pero carece de mecanismos para preservar su propia integridad. Si en una "transacción" queda truncado por un problema en la red o un corte repentino de corriente, adiós sistema.

Todos los sistemas pueden fallar, pero no creo que si envío un mensaje por ssh de un ordenador cliente al del autónomo se pierda algo en el camino, en ese caso si se pierde algo se pierde para la base de datos también o para cualquier medio de almacenamiento sencillamente porque no tienes el dato.

Hay que tener en cuenta que hoy en dia cualquier API actual intercambia datos por JSON, bancos incluidos, luego el mensaje va encriptado supongo, no soy experto en el tema, pero eso de a través de la red conectarse con la base de datos directamente a mi no me parece correcto.

Shordi plantea establecer una vpn para luego a través de esta tratar a los ordenadores clientes como si estuviesen en la misma red lo cual puede tener sentido en una empresa en la que los trabajadores trabajan en su casa o hay varias sedes, pero en los otros escenarios en donde los clientes son particulares que lo que desean es que le mantengas el sistema funcionando y seguro. La estructura que deben tener este tipo de programas o sistemas debería ser es la siguiente

[Cliente] "Programa de mantenimiento" <==> "Programa de gestión [WS] <###> Almacenamiento

• <==> Comunicación bidireccional por SSH a través de internet envío de ordenes y recepción de datos
  
• <###> Comunicación con el medio de almacenamiento que puede ser: un archivo JSON o alguna BD como SQLite, Postgres o MySQL. Dicho medio puede estar en la misma computadora, en otra local o externa a la red local (internet).
  
• [WS] Estación de trabajo del informático que puede estar en cualquier parte.
  

Esta forma modular permitiría que podamos desarrollar entre todos un proyecto que puede tomar diferentes escalas o implantaciones, es decir permitiría mas flexibilidad.

Saludos.

[Cliente] "Programa de mantenimiento" <==> "Programa de gestión [WS] <###> Almacenamiento

• <==> Comunicación bidireccional por SSH a través de internet envío de ordenes y recepción de datos
  
• <###> Comunicación con el medio de almacenamiento que puede ser: un archivo JSON o alguna BD como SQLite, Postgres o MySQL. Dicho medio puede estar en la misma computadora, en otra local o externa a la red local (internet).
  
• [WS] Estación de trabajo del informático que puede estar en cualquier parte.
  

Esta forma modular permitiría que podamos desarrollar entre todos un proyecto que puede tomar diferentes escalas o implantaciones, es decir permitiría mas flexibilidad.

Ok. Efectivamente no compartimos objetivos. Pero creo que no tiene sentido hablar de un proyecto que sólo he visto yo. Aparco el tema de momento y sigo "descontaminando" Intriga hasta que esté presentable. Una vez lo esté hablamos de en qué consiste esa "modularidad" que no llego a entender.

Saludos

Ok. Efectivamente no compartimos objetivos. Pero creo que no tiene sentido hablar de un proyecto que sólo he visto yo. Aparco el tema de momento y sigo "descontaminando" Intriga hasta que esté presentable. Una vez lo esté hablamos de en qué consiste esa "modularidad" que no llego a entender.

Ok. luego hablamos entonces

Saludos.

Pero continuando con el tema principal de este hilo, que es auto montar directorios remotos en el home del usuario sin que pida la clave. Dado que:
Escenario

• Usuarios dos grupos de usuarios, los usuarios pares y los impares user1, user2, user3, user4,user5, user6, user7, user8, userX, userZ donde X es un numero impar y Z es un numero par.
  
• Estaciones de trabajo Linux, por ejemplo station1, station2 ... stationN donde N es un numero variable.
  
• Servidor de archivos, en adelante server que comparte tres carpetas /var/music, /var/documents, /var/code.
  

Condiciones

• En cada estación tiene que poder ingresar cualquier usuario de la empresa, es decir las estaciones no están ligadas a un solo usuario
  
• Todas las estaciones de trabajo deben montar esas "carpetas de red" en el sistema de archivos local para el usuario que ingrese en la estación.
  
• No se puede usar /etc/fstab, que no me gusta porque, en la practica, esta atado a un solo usuario.
  

Configuración de una estación de trabajo

• Creación de usuario admin
  
• Instalación y configuración de openssh, openvpn, sshfs, ifconfig, vino
  
• Instalación de colector (Programa gambas que falta desarrollar)
  
• Si creo un par de claves rsa para admin ¿Luego sirven para todas las estaciones? no veo claro como demonios hacer algo general
  

Configuración del servidor

• Creación de usuario admin
  
• Instalación y configuración de openssh
  
•  
  

Si hago esto de aquí debajo, acto seguido el sistema me pide la clave del usuario admin se la paso y el recurso remoto se monta perfectamente.

Código:

[station3@user3 ~]$ sshfs -o reconnect -p #### admin@server:/var/music /home/user3/music

¿Pero como lo hago sin poner la clave?

• En la station3 por ejemplo, ingreso como admin
  
• Creo un par de claves rsa
  
• Copio la id_rsa.pub en server con ssh-copy-id -p [font][font][font]####[/font][/font] server donde #### es el puerto[/font]
  
• luego en server agrego la credencial a la lista con: cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
  

No se si esto es lo correcto o falta algún paso pero no funciona sin poner la clave.

Saludos.

¿Pero como lo hago sin poner la clave?

• En la station3 por ejemplo, ingreso como admin
  
• Creo un par de claves rsa
  
• Copio la id_rsa.pub en server con ssh-copy-id -p #### server donde #### es el puerto
  
• luego en server agrego la credencial a la lista con: cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
  

No se si esto es lo correcto o falta algún paso pero no funciona sin poner la clave.

-En la station3 no entras como admin. Sino como cada uno de los usuarios y entonces

-creas una clave con:
      ssh-genkey

y pulsas enter a todo. Luego:

     ssh-copy-id -p <puerto> admin@ipdelservidor

Te pide la clave del admin@ipservidor. Se la pones.
Y ya está. A ese usuario no se le pide más la clave.

Si ese es el uso principal de ssh y es el servidor habitual, puedes ir a /etc/ssh/ssh_config y sustituir la línea

#   Port 22

por

Port <mipuerto>  (sin la almohadilla inicial)

y ya está. A partir de ahí no tienes que especificar -p <puerto> en ningún comando ssh o sshfs.

Saludos

Si ese es el uso principal de ssh y es el servidor habitual, puedes ir a /etc/ssh/ssh_config y sustituir la línea...

Creo que la frase seria así:

Si ese es el uso principal de ssh y es el servidor habitual, puedes ir a /etc/ssh/ssh_config (en la computadora cliente) y sustituir la línea...

Hay que especificar bien todas estas instrucciones porque ambas PC, el cliente y el servidor tienen los mismos archivos pero, lógicamente, con diferente contenido.
También hay: /etc/ssh/ssh_config  y /etc/ssh/sshd_config
Yo siempre me maneje con /etc/ssh/sshd_config  y siempre que me conectaba a otra pc ponía el puerto, que por supuesto nunca era 22.
Voy a probar lo que me decís a ver si me ahorro lo del puerto.
¿Verdad?
Saludos

ssh_config es para la salida de ssh

sshd_config es el puerto para el servidor ssh (la d es de demonio)

Saludo.