[Tiger]

Ho aspettato per continuare la guida in quanto ho testato la release 13 rc1 di nextcloud che permette tramite app Android e iOS di chiamarsi e videochiamarsi tramite app nextcloud talk una cosa bellissima. Segnalato un bug su app Android che hanno risolto. Finirò la guida a breve.

[Tiger]

Modificata sezione installazione php sia per jessy che per stretch introducendo installazione dei moduli

php-smbclient
php-imagick
libmagickcore-dev

Il primo serve per montare unita esterne tramite samba nextcloud al nostro raspberry,

il secondo e terzo modulo ci consentono di gestire tramite imagick la modifica dei file svg per far si che al cambio del logo personalizzato di nextcloud esso possa modificare direttamente la nostra favicon del sito.

per installazione nextcloud se serve continuero la guida,

ma credo che sia di facile intuizione.

[Painbrain]

very good.

devo ristrutturare la lan di casa e volevo lasciare il nas come file server e client torrent, rimedio un disco aggiuntivo e provo.
l'interfaccia sembra molto bella (spulciato su google ovviamente), aspetto con ansia la fine.

[tiohoppio]

sera.
io continuo ad essere un assiduo sostenitore di nginx e php-fpm.
L'installazione di un nextcloud (già pesante sotto il punto di vista computazionale dentro una risorsa hw come un rpi), viene enormemente appesantita dai demoni apache2 (che se mal configurati possono rendere instabile e enormemente sotto carico la risorsa) e php (una fastcgi stand-alone servita asincronamente a livello uthread è sicuramente più leggero rispetto un modulo di un webserver pesante come apache2).
In definitiva, io rivedrei l'opzione di utilizzare una apache+php, e tendere ad utilizzare un protocollo non puro http ma https (magari utilizzando un no-ip e un Let's Encript), visto che sempre di dati personali stiamo parlando (basti vedere quanto semplice sia configurare un arp poisoning con bettercap e leggere tutte le trasmissioni con un MITM).

Quanto detto fin'ora ovviamente vuole solo essere un consiglio costruttivo. rimane il mio "chapeau" per la tua iniziativa nella guida (io non avrei pazienza, voglia e tempo di mettermi a farne una).

[Tiger]

La richiesta di https già implementato,
come  protocollo HTTP/2.0 e certificati let's Encrypt e ddns

La Guida devo ancora finirla per mancanza di tempo


Tieni presente che con http 2.0 poi la latenza scende. 

Non ho problemi con Apache.
Altra cosa importante 
Nextcloud gira bene 
i Dati oltre alla comunicazione https sono criptati lato server
nextcloud lo prevede se uno vuole criptarli,
quindi non leggibili

La velocità la reputo accettabile

Apache 2.0+ PHP fpm+http2.0+ssl lets encrypt

Vado molto bene ovviamente dipende anche dalla linea adsl.

Ngix non lo vedo bene per tanti aspetti e moduli

in privato mando url del mio lavoro su raspberry 

cosi che potrai vedere come gira bene e veloce amo apache piu di ngix per tante cose


altro appunto
dietro al raspeberry ho un firewall zeroshell
con snort e clam av e proxy attivi,
e tutte le chiamate su porta 80 sono redirette alla 443
penso di essere abbastanza sicuro

grazie per lo chapeaux...

e ti invito a testarla la guida,
mi manca poco per finirla

[tiohoppio]

La richiesta di https già implementato,
come  protocollo HTTP/2.0 e certificati let's Encrypt e ddns

Tieni presente che con http 2.0 poi la latenza scende. 

si, avevo letto impostavi http2, non avevo letto il let's encrypt (e il ddns mi pareva ovvio metterlo, dato che a meno che uno non disponga di ip statico non fa nulla se salta il modem 

Non ho problemi con Apache.
Altra cosa importante 
Nextcloud gira bene

Ci mancherebbe che non giri bene! altrimenti non avrebbe senso impostarlo! già owncloud rispetto ad altri servizi di consultazione remota son oro, immagino bene che nextcloud funzioni ancora meglio!

i Dati oltre alla comunicazione https sono criptati lato server
nextcloud lo prevede se uno vuole criptarli,
quindi non leggibili

qui parliamo di attacco attivo solo nel caso in cui si abbia accesso fisico, quindi è un'altro discorso quello.
io parlavo della comunicazione login/postlogin: se prendi la prima password, fai quel che vuoi sempre. per questo stavo rompendo l'anima per mettere un https

La velocità la reputo accettabile

Apache 2.0+ PHP fpm+http2.0+ssl lets encrypt

Vado molto bene ovviamente dipende anche dalla linea adsl.

Probabilmente sono io che sottovaluto la mora, me ne rendo conto, ma io penso che "fin posso aver potenza, prendiamola al massimo".  Ovviamente la latenza ed i caricamenti per una linea casalinga dipendono principalmente dalla linea stessa, ma se posso guadagnare mezzo secondo sull'interpretazione schifo non mi fà!

Ngix non lo vedo bene per tanti aspetti e moduli

Come mai?

in privato mando url del mio lavoro su raspberry 

cosi che potrai vedere come gira bene e veloce amo apache piu di ngix per tante cose

troppo gentile, prometto che non farò accessi malevoli 

altro appunto
dietro al raspeberry ho un firewall zeroshell
con snort e clam av e proxy attivi,
e tutte le chiamate su porta 80 sono redirette alla 443
penso di essere abbastanza sicuro

qui stiamo confondendo le cose però..  firewall è un conto, clam è un'altro, e snort un'altro ancora.
Diamo per certo che snort abbastanza cose le vede, ma non sempre riesce a vedere tutto. specie con bug a livello di codice del sw stesso, se la richiesta è lecita, snort la cosa non la vede (a meno che snort non sia più informato dell'applicazione stessa a riguardo dei bug, ma allora parliamo di applicazioni non aggiornate a livello globale, ed è un'altro discorso). l'unica maniera sarebbe avere una macchina a stati finiti (ad esempio una petri, se vogliamo parlare a livello matematico del nostro amico Alan e Alonzo, diremo una epsilon-nfa) che monitora le azioni standard e quelle non standard, e da qui per ogni azione non standard fa cadere lo snort. Ma a questo punto parliamo anche di machine learning se vogliamo che snort applichi azioni arbitrarie di gestione (cosa che non fà, dato che non avrebbe abbastanza esempi per apprendere).

grazie per lo chapeaux...

e ti invito a testarla la guida,
mi manca poco per finirla

Doveroso, pochi hanno lo sbatti di farle, molti copiano e basta.

Per ulteriori continuiamo in mp, altrimenti finiamo eccessivamente in ot.

[Tiger]

Si continueremo in pvt certo,

Per i dati criptati mi riferivo al fatto che bisognerebbe avere accesso fisico. Se uno da remoto ha accesso nn leggerebbe nulla

prometto che non farò accessi malevoli ,
Ti invito a farli se hai intuizioni così possiamo testare i bug se vi sono e porvi rimedio.

Per macchine lineari, Petri e vari non conosco oggetto dell' argomento ma penso esuli da un web server casalingo.

Per Snort ripeto penso sia più che sufficiente per protezione ambito home. E il firewall con DPI posso gestire le chiamate non corrispondenti al vero traffico https. A meno che nn si usi stunnel

Ti ringrazio per tutto il resto.

[tiohoppio]

Per macchine lineari, Petri e vari non conosco oggetto dell' argomento ma penso esuli da un web server casalingo. 

scusami, ma è deviazione "professionale", seguendo un corso di studi di informatica teorica la situazione è questa 

comunque si, esula totalmente dal server casalingo, era più un volo pindarico in merito a strategie adottate, ovvero che se uno non vede un comportamento lecito conosciuto, allora quasi sempre si tratta di un comportamento malevolo, lel (più o meno come fanno gli av tradizionali, mettono in sandbox, ne studiano le possibili dipendenze da chiamate kernel, se sono tutte ad aree lecite allora quasi sicuramente non è una cosa che lide alla macchina, in caso contrario la stroncano sul nascere e chiedono cosa fare.. ma qui stiamo semplificando troppo la cosa...).

[DeltaFoX]

Ottima Discussione..

personalmente penso che :

1) nginx non supporta nativamente  .htaccess se non erro..., e vanno usati convertitori appositi o lavorare sul file nginx.conf

2) leggo che sulle pagine statiche nginx vada meglio mentre non rende al meglio quando si tratta di gestire i file dinamici

3) Ideale sarebbe usarlo insieme ad apache 2 come cache o reverse proxy così  i contenuti statici vengono gestiti da Nginx, mentre quelli dinamici sono gestiti da Apache unendo la velocità di Nginx alla stabilità di Apache.

Alla fine comunque le differenze non sono cosi eccessive...

Saluti

[Tiger]

Grazie a tutti per l'incitamento vedrò cmq di finire la guida e vedere con ngix se avrò tempo...

see you