Raccolta remota e condivisione

[DragoRosso]

Ciao a tutti.

Stò approcciando a una nuova tipologia di attività, una cui parte preponderante è la raccolta dati.

In pratica ho degli strumenti remoti, per adesso interfacciati per forza con dei PC Windows poi un domani si vedrà, che devono condividere dei dati. A questi dati poi potranno accedere dei terzi, in maniera però selezionata, ossia per gruppi. Un terzo in pratica potrà accedere ai dati di un gruppo di dispositivi remoti, ma non ad altri. Ovviamente questi gruppi potranno cambiare composizione, operazione gestita da un amministratore.

La connessione non è certa e costante, per cui è certo che i vari dispositivi remoti (o meglio i pc a cui i dispositivi sono collegati) dovranno trasmettere i dati presso un collettore centrale, quando possibile.

La domanda è: il collettore centrale può essere un aggregatore qualsiasi, ma in grado ovviamente di isolare i gruppi di dati e di renderli disponibili secondo la regola suddetta, qual'è la tecnologia migliore da usare secondo voi ?

Io pensavo al cloud (che và tanto di moda adesso), soluzione comunque costosa (anche se qualche servizio gratuito c'è) e sopratutto a me quasi sconosciuta nel suo funzionamento.

In alternativa un bel database remoto tramite server con protocollo REST ad esempio (anche questo però certo non economico a meno che non si faccia "in casa"), oppure ... cos'altro ?

Voi cosa ne pensate ? Sono aperto a suggerimenti.

Grazie intanto, ciao ciao

[Stilgar]

Ciao.
Cosa intendi per "protocollo REST"?


Stilgar

[tito_livio]

Ciao, io per diversi anni ho usato un server ftp al quale inviavo dei file di testo. Nel mio caso i dati provenivano da cellulari, poi c'era un pc che attingendo dal server ftp poi riversava in un dbms. Il server ftp prima era in un pc in studio poi presi un virtual server Aruba a 10 € al mese.
Il database remoto lo uso tuttora ma in applicazioni dove c'è interattività.

[DragoRosso]

Ciao.
Cosa intendi per "protocollo REST"?

Stilgar

REST o SOAP, è il protocollo basato su HTTP ed è uno standard per la comunicazione dati su rete.

[Stilgar]

REST o SOAP, è il protocollo basato su HTTP che è uno standard per la comunicazione dati su rete.

https://restfulapi.net/soap-vs-rest-apis/



Per chi non sa di cosa stiamo parlando.


Qui parlano solo dell'http come protocollo, ma in via del tutto teorica si potrebbero usare altri protocolli (STMP ad esempio).



Stilgar

[DragoRosso]

Bhè, diciamo che l'argomento non è proprio incentrato sul protocollo. Il mio era uno dei pensieri per dare una visione del tutto. Giustamente @tito_livio ha proposto una soluzione alternativa come ftp.

Diciamo che i punti cardine sono:

1) Da cliente remoto deposito (quindi solo scrittura) dati su un hub centrale (tramite internet).

2) Sull' hub centrale ci dovrà essere una elaborazione dei dati per consentirne una archiviazione organizzata.

3) Da ulteriori clienti remoti accesso (solo lettura) ai dati "ragruppati" sull'hub centrale (tramite internet).

4) Sistema di amministrazione per la gestione dei dati (manutenzione, operazioni di configurazione o altro) (tramite internet).

Per i punti 1) e 3) in questo momento si userebbero dei PC in ambiente Windows, ma solo perchè è più semplice la gestione iniziale e perchè tendenzialmente i clienti hanno sempre e comunque un PC Windows a disposizione.

Tutto ciò che ci stà in mezzo, compresi punti 2) e 4) sono da pensare.

A me, tendenzialmente sono conservatore, una soluzione classica con trasferimento ftp da punto 1) a un server virtuale con vari servizi punto 2), programma in Lazarus di gestione dei file sul punto 2) e 4) e archiviazione dei dati su un db, altro programmino in Lazarus sul punto 3) di interrogazione del db punto 2) (client / server fatti sempre in Lazarus) ..... non dispiacerebbe.

Però la sicurezza è uno di quegli aspetti che in questo caso, facendo tutto "io" mi fà un attimo pensare. Come pro è che ho tutto sotto il mio controllo e il costo è probabilmente il più contenuto.

Usare altre tecnologie come NAS, cloud o altro distoglie "parzialmente" dal pensiero sulla sicurezza ma fà aumentare i costi e il controllo e l'uso è probabilmente più complesso.

Faccio un esempio (non conosco in generale il cloud e le api S3): i dati nel cloud devono arrivare già aggregati e corretti immagino. Quindi si prevede che gli end point 1) e 3) inviino già i dati formattati ed organizzati in un modo X .... e questo toglie diciamo flessibilità alla soluzione ... se dovessi togliere il pc dal punto 1) (che è previste in un futuro prossimo) dubito che approcciando questa soluzione il device nudo e crudo possa adottare le api s3 al suo interno per la comunicazione dei dati sul cloud. E anche se lo fosse, ho già visto che i soli aggiornamenti del core del device provocano sconvolgimenti che non dovrebbero esserci ... và bhè ma questa è un'altra storia....

Ciao

[DragoRosso]

Ahhh, dimenticavo: per ultimo, ma non ultimo come peso, con la soluzione classica avrei una gestione completa anche sugli accessi e sugli allert come tentativi e frequenza accessi con una logica personalizzata che nessuna delle soluzioni standard come NAS e cloud possono facilmente offrire.

Ciao

[Stilgar]

Anche io sono del tipo "classico" come ha amato definirti.
Ma non mi azzardo a darti suggerimenti tecnologici.
Altrimenti al primo inghippo inizio a sentire le imprecazioni interregionali.


Stilgar

[DragoRosso]

Anche io sono del tipo "classico" come ha amato definirti.
Ma non mi azzardo a darti suggerimenti tecnologici.
Altrimenti al primo inghippo inizio a sentire le imprecazioni interregionali.

Stilgar

Ma daiiiii, i suggerimenti aiutano a crescere. Fai muovere quei pochi neuroni che ti sono rimasti ( ) e sputa il rospo.
Prometto che non me la prenderò con te.
Anche perchè la scelta finale sarà comunque mia, indipendentemente da suggerimenti, consigli o altro.

Quindi mia anche la responsabilità della adozione della soluzione o del mix di soluzioni.

Ciao

[Stilgar]

Dipende dagli scenari.

FTP è ottimo se non devi sapere in "tempo reale" lo stato dei dati importati.
Tutto in differita. Asincrono. Ottimo per batch con grandi quantità di dati. Poi dovrai pensare a qualche procedura di gestione degli scarti.

Se devi sapere lo stato di import dei dati, meglio struttura OLAP. Un servizio esposto direttamente in rete, protocollo di trasmissione http su TLS. Spari il dato e sai se è stato accettato. Eventualmente poi inviare nuovamente il dato in caso di errore.

Per la parte di sicurezza, esistono diversi tipi di soluzione.
Quella che prediligo:
1) Client Autenticazione| JWT di risposta se passa l'autenticazione
2) Ad ogni chiamata deve essere fornito il JWT.

In questo modo non usi sessioni (evitando gli attacchi alle sessioni) o altri ammennicoli strani. Il JWT deve essere cifrato.
Il server verifica ad ogni chiamata il contenuto del JWT. In modalità "paranoica" il JWT può cambiare ad ogni richiesta del client. Lo generi ad ogni risposta.

Rest di suo è ottimo (alla fine sono una serie di convenzioni, nulla vieta che i metodi http che usi siano customizzati - son soddisfazioni inventarsi i metodi di chiamata). Nel payload puoi mettere grosso modo quel che vuoi. In genere vedi json come formato dati (utilissimo con javascript), ma nessuno ti vieta di inviare un file cifrato a sua volta. Magari usi il JWT  come chiave di cifratura.
Anche il CBOR è intrigante come formato. Ed è standardizzato. (Dovrei mettermici per fare una lib per pfc, così per divertimento)


Se vuoi altri spunti per incasinarti la vita

Stilgar

[Stilgar]

PS
CBOR https://www.rfc-editor.org/rfc/rfc8949.html


JWT https://jwt.io/ https://jwt.io/libraries


Stilgar

[DragoRosso]

Grazie @Stilgar, sapevo di poter contare su di te. Quando sono in cerca di un qualcosa di diverso, di tranquillo, di già sviluppato .... sò di contare su di te  (falsoooo).

Provo a darci una occhiata e vediamo, mi stuzzica fare una lib base su CBOR ...

Intanto grazie per gli spunti, poi vi tengo aggiornati.

Ciao ciao

[DragoRosso]

Uno dei problemi che ho visto e che mi hanno raccontato sui server remoti è la principale problematica dell'interfaccia di configurazione / uso.

E' vero che i pannelli di controllo sono ormai molto sofisticati, ma è anche vero che la stragrande maggioranza di questi è "puntata" molto al web.

Girando "in giro" mi sono imbattuto in una offerta di Aruba (cloud vps : https://www.cloud.it/vps/configuratore-virtual-private-server.aspx) che in effetti è forse la migliore (@nomorelogic inorridirrà a ciò che dirò) sia in termini d'uso che di prezzo.
Ovvio che la potenza elaborativa è comunque limitata, ma per quello che devo fare è anche troppa ....

Ci sono 4 tagli (cambiano ram, cpu virtuali, spazio su disco e traffico mensile): € 3,40 / mese; € 8,00 / mese; € 15,25 / mese o € 30,50 / mese.

Ma il bello è che come SO hai Ubuntu 20.04 Server con VIRTUAL DESKTOP .....  in pratica un PC remotato. C'è anche la connessione SSH, ad uso degli amanti della console a riga di comando ....

Se come me non si hanno grosse esigenze per il progetto che stò affontando, ma che necessito di massima flessibilità, direi che la proposta è più che accettabile.

Inoltre puoi scalare in basso o in alto alla bisogna .... ehmmm ... anzi no per il servizio smart 

L'offerta è una offerta base (cloud vps smart) e la configurazione che attiverò (già domani probabilmente) è la terza: € 12,50 /mese (l'iva ovviamente la compenso) con 2 cpu virtuali, 4 GB Ram, 80 GB SSD, 12 TERABYTE di traffico mensile con banda teorica di 1 Gbit.

Dopo di che la prima operazione che farò sara installare un serverino fatto in Lazarus ....    con interfaccia GRAFICA .... 

Poi proseguirò con il resto CBOR ... JWT ... REST ... SOAP ... e chi più ne ha più ne metta.

Ciao

[nomorelogic]

scusate la mia assenza ma ho dei giorni complicati

innanzitutto non inorridisco affatto per un VPS, anzi! 
in azienda abbiamo già diversi server VPS su aruba +  ne abbiamo uno fisico dove ci gestiamo i nostri VPS "fatti in casa"

ora passiamo al problema
S3 è uno storage ma di file, non è un database e quindi non credo che faccia al tuo caso: penso di aver capito che devi gestire dei dati tipo RDBMS
detto questo FreeNAS/TrueNAS, nel caso serva storage di file con interfaccia verso api S3 credo sia la soluzione migliore tecnicamente e meno costosa


lo scenario che descrivi secondo me è affrontabile almeno in un paio di modi

se i dati che devono stare sul "deposito centrale" sono omogenei (= tabelle identiche) con quelli che stanno nei vari "punti di inserimento" (client) allora ti consiglio vivamente di valutare un RDBMS che abbia replicazione interna (MsSql o firebirdSql 4)
la replicazione di database è un mondo particolare ma una volta impostata vai (quasi) senza problemi
capisco che può intimorire, ma è uno strumento straordinario

se vogliamo slegarci da tutto e tutti, non vedo altra soluzione che avere un server da qualche parte dove gira un RDBMS e un server rest per pubblicare le API a fare da interfaccia
il server rest può essere di qualsiasi tipo (vedi suggerimenti Stilgar), se vuoi rimanere con lazarus si può fare sia (1) apache + cgi fpc che (2) apache + modulo apache DLL fatto con fpc che (3) apache + instantfpc che è una figata che (4) server json dedicato scritto sempre con FPC
(se vuoi dritte su una qualsiasi di queste soluzioni... le ho già studiate tutte quante)

altro strumento da valutare ETL
un ETL è uno strumento che può servire per spostare dati dai client al server anche passando per server rest json
per chi è interessato ne sto studiando/realizzando uno fatto in fpc che possa raccogliere (trasformare ovviamente) e distribuire dati in vari formati e canali
attualmente sto studiando un primo "semplice" step: trasferimento dati da foglio di calcolo a tabella su database RDBMS diretto (cross platform ovviamente = no OLE e no Activex)
(ftp, rest json, rdbms vs rdbms sono cose che arriveranno a seconda delle necessità)
quando avrò finito il primo step avrei intenzione di rendere il sorgente open source (ne sto parlando in azienda ma credo che ce la facciamo)
quindi se va liscia... puoi anche valutare il mio ETL 

[DragoRosso]

Intanto primo serverino http ... tre line di codice :

EDIT: il link non è più attivo.

Ehm .... da notare il nome del dominio     domani lo cambio giusto per dare un tono .....

Ciao

P.S.: @nomorelogic, ma sai che quasi quasi Linux mi incomincia a piacere, almeno per la parte web e richiesta di risorse. Effettivamente 2 virtual core e 4 GB sono anche tanti .....    .... però il piacere si ferma li  .