Re: apache php e problemi nell' upload dei file

[Leonardo Boselli]

On Wed, 17 May 2023, Lorenzo Breda wrote:

Il giorno mer 17 mag 2023 alle ore 13:42 Leonardo Boselli 

 On Wed, 17 May 2023, Giuseppe Naponiello wrote:

(…)mi permette di costruire una piattaforma ben strutturata e con
interfacce fighe, magari usando Vue, ma allora devo imparare anche Vue

Le interfacce fighe sono il sistema migliore per creare sistemi
instabili, esigenti di risorse e lente.


Le interfacce fighe sono spesso un requisito, quindi al solito: dipende da
che devi fare.
Che portino a sistemi instabili non lo trovo particolarmente vero (certo,
sono una cosa  in più da gestire, ma se si deve si deve), che richiedano
maggiori risorse dipende quali risorse. Di solito i sistemi per "interfacce
fighe" riducono di molto la necessità di risorse di rete mentre aumentano
la necessità di risorse di calcolo sul client. A volte è follia,
a volte è fondamentale. Basta sapere cosa si sta facendo e perché.


ed è giusto questo: di solito i limiti sono lato client o lato rete, lato 
server solo in certi casi, se davvero molto carichi o che necessitano di 
risposta in tempo quasi reale.
Ti faccio due esempi che supportano la mia opinione: Un sito che per 
rispondere a un messaggio, dove basterebbe un form con un campo txt e un 
paio di checkbox, se non li hai nella cache ti carica circa 1.7 MB di 
script che non fanno assolutamante nulla se non abilitare un editor che ti 
crea più problemi che vantaggi: mi trovo spesso in un luogo servito da un 
ripetitore locale (perché in zona d'ombra) che al massimo offre GPRS. il 
risultato è che caricando la pagina si ottine un timeout, rendendo 
impossibile l'accesso. un altro sito che fa le stesse cose, ma ottimizzato 
per light client funziona perfettamente e senza attese.
Altro sito "fancy": quando fai una ricerca  al terzo carattere ti mostra 
una lista di tutti i valori possibili. Bello, solo che se non appare nei 
primi 20 non hai la possibilità di andare oltre e devi continuare a 
scrivere senza suggerimenti sperando di beccare quello giusto, e quello 
che è peggio non ti dice se la lista è completa o non ce ne sono altri, di 
fatto nulla più che se avessi inserito alcuni caratteri e poi premuto 
"search" (in  quel caso te ne fa vedere 20, ma esplicitamente di dice se 
ce ne sono altri, invitandoti a aggiungere altri caratteri)



--
Leonardo Boselli
Firenze, Toscana, Europa

Re: apache php e problemi nell' upload dei file

[Giuseppe Naponiello]

Ok, giusto, allora chiedo scusa e faccio un mea culpa, diciamo allora 
che in ambito web php è ancora il più usato? Ovviamente non prendo in 
considerazioni webapp ibride.


Non ho scritto che non ci sono alternative ma che non ce ne sono tante, 
sinceramente ho sempre creduto che ASP.NET fosse ormai in disuso e che 
Java fosse troppo "avida di risorse", quindi non raccomandabile per 
progetti di piccola e media grandezza/complessità (almeno così me 
l'hanno sempre raccontata).


Comunque grazie davvero, è sempre bello ascoltare pareri diversi, impari 
sempre qualcosina in più...dai fino ad ora siamo stati bravi a non far 
degenerare la discussione!!! 


Il 17/05/23 17:16, Federico Di Gregorio ha scritto:



On 17/05/23 16:54, Giuseppe Naponiello wrote:
In ogni caso, i framework php hanno zero a che fare con le questioni 
di interfaccia, php
è un linguaggio lato server (e infatti per le interfacce ti serve 
tutt'altro, come il citato Vue).
Ovviamente!!! Per questo Laravel ti "propone" un'interfaccia basic di 
vue.js, forse la libreria più leggera in circolazione...fatto sta che 
se hai bisogno di PHP non puoi prescindere da librerie javascript, a 
meno di rinunciare alla comodità delle funzioni asincrone.


Con tutti i suoi limiti e i suoi difetti penso che siamo tutti 
daccordo sul fatto che se vuoi una piattaforma web solida, complessa, 
sicura e robusta non ci sono tante alternative al nostro caro e 
vecchio php...si ok, c'è anche python ma non è fatto per quello, e 
lasciamo stare tutto ciò che ha a che fare con node ecc.


Dire che non ci sono alternative è veramente sbagliato. Diciamo che se 
parliamo di piattaforme web "solide, sicure e robuste" (e, aggiungo 
io, che supportino tutte le tecnologie moderne, dai websocket in su) 
ci sono almeno due alternative: Java (con tutte le sue varianti di 
librerie e framework) e C# (con ASP.NET Core). E ho preso solo le 2 
notissime.


federico

Re: apache php e problemi nell' upload dei file

[Lorenzo Breda]

Il mer 17 mag 2023, 17:16 Federico Di Gregorio  ha scritto:

>
> Dire che non ci sono alternative è veramente sbagliato. Diciamo che se
> parliamo di piattaforme web "solide, sicure e robuste" (e, aggiungo io,
> che supportino tutte le tecnologie moderne, dai websocket in su) ci sono
> almeno due alternative: Java (con tutte le sue varianti di librerie e
> framework) e C# (con ASP.NET Core). E ho preso solo le 2 notissime.
>

Esatto, Java soprattutto con Spring e C#, ma anche Swift non è da buttare
fatte le dovute considerazioni.

E non butterei alle ortiche Node.js, suvvia.

-- 
Lorenzo Breda

Re: apache php e problemi nell' upload dei file

[Federico Di Gregorio]

On 17/05/23 16:54, Giuseppe Naponiello wrote:
In ogni caso, i framework php hanno zero a che fare con le questioni 
di interfaccia, php
è un linguaggio lato server (e infatti per le interfacce ti serve 
tutt'altro, come il citato Vue).
Ovviamente!!! Per questo Laravel ti "propone" un'interfaccia basic di 
vue.js, forse la libreria più leggera in circolazione...fatto sta che se 
hai bisogno di PHP non puoi prescindere da librerie javascript, a meno 
di rinunciare alla comodità delle funzioni asincrone.


Con tutti i suoi limiti e i suoi difetti penso che siamo tutti daccordo 
sul fatto che se vuoi una piattaforma web solida, complessa, sicura e 
robusta non ci sono tante alternative al nostro caro e vecchio php...si 
ok, c'è anche python ma non è fatto per quello, e lasciamo stare tutto 
ciò che ha a che fare con node ecc.


Dire che non ci sono alternative è veramente sbagliato. Diciamo che se 
parliamo di piattaforme web "solide, sicure e robuste" (e, aggiungo io, 
che supportino tutte le tecnologie moderne, dai websocket in su) ci sono 
almeno due alternative: Java (con tutte le sue varianti di librerie e 
framework) e C# (con ASP.NET Core). E ho preso solo le 2 notissime.


federico

--
Federico Di Gregorio federico.digrego...@dndg.it
DNDG srl  http://dndg.it
 Il panda ha l'apparato digerente di un carnivoro (e.g., di un orso).
  Il panda ha scelto di cibarsi esclusivamente di germogli di bambù.
  Quindi, il panda è l'unico animale vegano del pianeta. Il panda
  merita di estinguersi.   -- Maria, Alice, Federico

Re: apache php e problemi nell' upload dei file

[Giuseppe Naponiello]

In ogni caso, i framework php hanno zero a che fare con le questioni 
di interfaccia, php
è un linguaggio lato server (e infatti per le interfacce ti serve 
tutt'altro, come il citato Vue).
Ovviamente!!! Per questo Laravel ti "propone" un'interfaccia basic di 
vue.js, forse la libreria più leggera in circolazione...fatto sta che se 
hai bisogno di PHP non puoi prescindere da librerie javascript, a meno 
di rinunciare alla comodità delle funzioni asincrone.


Con tutti i suoi limiti e i suoi difetti penso che siamo tutti daccordo 
sul fatto che se vuoi una piattaforma web solida, complessa, sicura e 
robusta non ci sono tante alternative al nostro caro e vecchio php...si 
ok, c'è anche python ma non è fatto per quello, e lasciamo stare tutto 
ciò che ha a che fare con node ecc.


Il 17/05/23 15:25, Lorenzo Breda ha scritto:
Il giorno mer 17 mag 2023 alle ore 13:42 Leonardo Boselli 
 ha scritto:


On Wed, 17 May 2023, Giuseppe Naponiello wrote:
> (…)mi permette di costruire una piattaforma ben strutturata e
con interfacce
> fighe, magari usando Vue, ma allora devo imparare anche Vue

Le interfacce fighe sono il sistema migliore per creare sistemi
instabili, esigenti di risorse e lente.


Le interfacce fighe sono spesso un requisito, quindi al solito: 
dipende da che devi fare.
Che portino a sistemi instabili non lo trovo particolarmente vero 
(certo, sono una cosa
in più da gestire, ma se si deve si deve), che richiedano maggiori 
risorse dipende quali
risorse. Di solito i sistemi per "interfacce fighe" riducono di molto 
la necessità di risorse
di rete mentre aumentano la necessità di risorse di calcolo sul 
client. A volte è follia,

a volte è fondamentale. Basta sapere cosa si sta facendo e perché.

In ogni caso, i framework php hanno zero a che fare con le questioni 
di interfaccia, php
è un linguaggio lato server (e infatti per le interfacce ti serve 
tutt'altro, come il citato Vue).


--
Lorenzo Breda

Re: apache php e problemi nell' upload dei file

[Piviul]

On 5/17/23 14:06, Diego Zuccato wrote:

[...]
Esattamente quello che dicevo: oltre al linguaggio, che comunque devi 
conoscere, devi studiarti anche il framework.
Tra l'altro prima stavo proprio creando un'app di esempio con Laravel 
e ha iniziato malissimo: due warning per componenti non mantenuti. Col 
primo comando di esempio! :(


questo secondo me è il problema del framework, se  fai software che deve 
durare anni, che devi manutenere, poi aggiornarlo è un bagno di sangue 
fra componenti non più mantenuti, obsoleti... poi c'è sempre il timore 
che il framework muoia... ho visto però che laravel resiste dal 2011, 12 
anni come non sentirli mi sembra, viene voglia in effetti di provarlo.


Piviul

Re: apache php e problemi nell' upload dei file

[Lorenzo Breda]

Il giorno mer 17 mag 2023 alle ore 13:42 Leonardo Boselli 
ha scritto:

> On Wed, 17 May 2023, Giuseppe Naponiello wrote:
> > (…)mi permette di costruire una piattaforma ben strutturata e con
> interfacce
> > fighe, magari usando Vue, ma allora devo imparare anche Vue
>
> Le interfacce fighe sono il sistema migliore per creare sistemi
> instabili, esigenti di risorse e lente.
>

Le interfacce fighe sono spesso un requisito, quindi al solito: dipende da
che devi fare.
Che portino a sistemi instabili non lo trovo particolarmente vero (certo,
sono una cosa
in più da gestire, ma se si deve si deve), che richiedano maggiori risorse
dipende quali
risorse. Di solito i sistemi per "interfacce fighe" riducono di molto la
necessità di risorse
di rete mentre aumentano la necessità di risorse di calcolo sul client. A
volte è follia,
a volte è fondamentale. Basta sapere cosa si sta facendo e perché.

In ogni caso, i framework php hanno zero a che fare con le questioni di
interfaccia, php
è un linguaggio lato server (e infatti per le interfacce ti serve
tutt'altro, come il citato Vue).

-- 
Lorenzo Breda

Re: apache php e problemi nell' upload dei file

[Lorenzo Breda]

Il giorno mer 17 mag 2023 alle ore 13:02 Leonardo Boselli 
ha scritto:

>
> Io sono molto old school, ho iniziato coi device driver, e lí non ti puoi
> permettere inefficienze, per cui sempre basso livello. figuriamoci un
> framework,


Se si cerca l'efficienza, php va buttato per intero :P
Un framework ne aggiunge davvero poca di inefficienza (ne toglie se
uno programma da cani, cosa non infrequente nell'ambito).


> che ho ancora da trovarne uno ben documentato.


Laravel. Questo comunque è un problema pure nel mondo dei linguaggi di
programmazione, purtroppo.


> personalmente è meno difficile intendere un programma scritto tutto con le
> funzioni standard che con un framework che uno non conosce.
> E non lo dico solo io ...
>

Su questo dissento decisamente. È meno difficile intendere un programma
scritto
in un linguaggio che conosci che uno scritto in un linguaggio che non
conosci,
ma questo non ha assolutamente nulla a che fare con i framework. Conoscendo
sia vanilla che un framework non c'è gran differenza di leggibilità, e dove
c'è è
decisamente a vantaggio del framework molto spesso (Laravel ad esempio fa
largo uso di un approccio funzionale in cui php è deficitario e che è molto
più
leggibile).

-- 
Lorenzo Breda

Re: apache php e problemi nell' upload dei file

[Diego Zuccato]

Finora mi pare siamo stati tutti civili e maturi, sarà l'influenza 
Debian (per la quale sarà meglio che non creino vaccini!) :)


Esattamente quello che dicevo: oltre al linguaggio, che comunque devi 
conoscere, devi studiarti anche il framework.
Tra l'altro prima stavo proprio creando un'app di esempio con Laravel e 
ha iniziato malissimo: due warning per componenti non mantenuti. Col 
primo comando di esempio! :(
Poi l'annoso problema di dover avere una parte al di fuori della webroot 
(già incompatibile con molti servizi di hosting) e oltretutto con 
relative path fissati! Certo, si può spesso giocare sulla config del 
server web (se lo si gestisce in casa), ma non è proprio una cosa simpatica.


Quando poi ci si inizia a mettere di mezzo JS la complessità esplode, 
soprattutto se si vogliono cose astruse come la graceful degradation 
(qualcuno vuole provare a navigare qualche sito con Arachne? O:) ).


Vabbè, mi ritiro nella mia grotta a cercare di lisciare qualche spigolo 
a questa cosa... credo la chiamerò ruota :)


Diego

Il 17/05/2023 13:12, Giuseppe Naponiello ha scritto:

È una di quelle cose che rischia di scatenare flame, spero non avvenga.
Era il mio timore iniziale, ma confido nella maturità e nell'approccio 
"scientifico" alla discussione dei membri del gruppo! 


In generale sono d'accordo con te, dipende davvero cosa ci fai. In 
questo momento mi è stato chiesto di sviluppare dei moduli per un CMS 
"semantico" (Omeka S) basato Doctrine...e ci sto ammattendo, non mi 
piace assolutamente ma questo è un altro problema! Il fatto è che la 
tecnologia sta facendo davvero passi da gigante, e spesso questo 
complica le cose (IMHO); se voglio fare una PWA devo spostarmi su un 
ambiente più javascript (e lì ti ci puoi perdere tra le mille 
possibilità!!!) e se per comodità voglio le mie API in PHP non credo mi 
convenga utilizzare Laravel...d'altra parte Laravel mi permette di 
costruire una piattaforma ben strutturata e con interfacce fighe, magari 
usando Vue, ma allora devo imparare anche Vue...insomma, l'è un gran casin!


Il 17/05/23 10:32, Lorenzo Breda ha scritto:
Il mer 17 mag 2023, 09:15 Giuseppe Naponiello  ha 
scritto:



Pur essendo io "old school" sono molto incuriosito ma ammetto la mia
ignoranza in materia, e mi piacerebbe sapere secondo voi se vale
davvero
la pena investire tempo per imparare ad usarne uno


È una di quelle cose che rischia di scatenare flame, spero non avvenga.

Da persona che ci lavora, trovo che in generale dipende da cosa ci 
fai, se tiri su qualche script per hobby probabilmente non ha molto 
senso, se invece fai applicazioni di livello professionale è 
imprescindibile. Certo, impararlo ha un costo, ma non è che fare unit 
testing and esempio sia gratis, eppure è fondamentale e si fa.


Il costo di formazione è l'unico vero svantaggio. La questione della 
sicurezza è inconsistente e trovo assurdo leggerla qui. Usare un 
framework rende un'applicazione molto più sicura, altro che meno 
sicura. C'è più gente a trovar falle, ci sono protocolli di testing 
rigidi, la risoluzione delle falle è centralizzata. Certo, le falle 
una volta trovate sono note, ma non credo di dover spiegare qui che la 
security through obscurity sia un'illusione.


Un framework moderno, persino in PHP, non offre particolari problemi 
di aggiornamento, ho portato interi applicativi, negli anni, da 5.4 a 
8.2 senza particolari sforzi. I framework semplificano anche questo, 
dato che raramente si utilizzano le funzioni "di PHP" più soggette a 
cambiamenti ma si usa la loro versione fornita dal framework, che non 
cambia facilmente API (e quando lo fa è ben documentato nella sezione 
upgrading della documentazione).


Persino sa chi fa solo script, consiglio Laravel Zero.

--
Lorenzo Breda


--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786

Re: apache php e problemi nell' upload dei file

[mauro morichi]

Il 17/05/2023 13:42, Leonardo Boselli ha scritto:
(…)mi permette di costruire una piattaforma ben strutturata e con 
interfacce

fighe, magari usando Vue, ma allora devo imparare anche Vue


Le interfacce fighe sono il sistema migliore per creare sistemi 
instabili, esigenti di risorse e lente. 



pero' hai sempre l'utonto davanti che si lamenta se l'iconcina non e' 
tre pixel piu' sopra dell'altra, con i colori fighi e le form 
perfette purtroppo.



Mauro

Re: apache php e problemi nell' upload dei file

[Leonardo Boselli]

On Wed, 17 May 2023, Giuseppe Naponiello wrote:

(…)mi permette di costruire una piattaforma ben strutturata e con interfacce
fighe, magari usando Vue, ma allora devo imparare anche Vue


Le interfacce fighe sono il sistema migliore per creare sistemi 
instabili, esigenti di risorse e lente.


--
Leonardo Boselli
Firenze, Toscana, Europa
http://i.trail.it

Re: apache php e problemi nell' upload dei file

[Leonardo Boselli]

On Wed, 17 May 2023, Giuseppe Naponiello wrote:
Pur essendo io "old school" sono molto incuriosito ma ammetto la mia 
ignoranza in materia, e mi piacerebbe sapere secondo voi se vale davvero la 
pena investire tempo per imparare ad usarne uno

(…)

Il 16 maggio 2023 12:17:23 UTC, Diego Zuccato  ha 
scritto:
Altro problema: se si adotta un framework per un progetto a lunga 
scadenza (10 anni o più), (…)
e chi viene per aiutarti (lo sbarbatello 
che "sa programmare il web") non conosce quel framework perché troppo 
vecchio e fuori moda e quindi comunque deve studiarlo da zero.


Io sono molto old school, ho iniziato coi device driver, e lí non ti puoi 
permettere inefficienze, per cui sempre basso livello. figuriamoci un 
framework, che ho ancora da trovarne uno ben documentato.
personalmente è meno difficile intendere un programma scritto tutto con le 
funzioni standard che con un framework che uno non conosce.

E non lo dico solo io ...

--
Leonardo Boselli
Firenze, Toscana, Europa
http://i.trail.it
tel:+393287329225

Re: apache php e problemi nell' upload dei file

[Giuseppe Naponiello]

È una di quelle cose che rischia di scatenare flame, spero non avvenga.
Era il mio timore iniziale, ma confido nella maturità e nell'approccio 
"scientifico" alla discussione dei membri del gruppo! 


In generale sono d'accordo con te, dipende davvero cosa ci fai. In 
questo momento mi è stato chiesto di sviluppare dei moduli per un CMS 
"semantico" (Omeka S) basato Doctrine...e ci sto ammattendo, non mi 
piace assolutamente ma questo è un altro problema! Il fatto è che la 
tecnologia sta facendo davvero passi da gigante, e spesso questo 
complica le cose (IMHO); se voglio fare una PWA devo spostarmi su un 
ambiente più javascript (e lì ti ci puoi perdere tra le mille 
possibilità!!!) e se per comodità voglio le mie API in PHP non credo mi 
convenga utilizzare Laravel...d'altra parte Laravel mi permette di 
costruire una piattaforma ben strutturata e con interfacce fighe, magari 
usando Vue, ma allora devo imparare anche Vue...insomma, l'è un gran casin!


Il 17/05/23 10:32, Lorenzo Breda ha scritto:
Il mer 17 mag 2023, 09:15 Giuseppe Naponiello  ha 
scritto:



Pur essendo io "old school" sono molto incuriosito ma ammetto la mia
ignoranza in materia, e mi piacerebbe sapere secondo voi se vale
davvero
la pena investire tempo per imparare ad usarne uno


È una di quelle cose che rischia di scatenare flame, spero non avvenga.

Da persona che ci lavora, trovo che in generale dipende da cosa ci 
fai, se tiri su qualche script per hobby probabilmente non ha molto 
senso, se invece fai applicazioni di livello professionale è 
imprescindibile. Certo, impararlo ha un costo, ma non è che fare unit 
testing and esempio sia gratis, eppure è fondamentale e si fa.


Il costo di formazione è l'unico vero svantaggio. La questione della 
sicurezza è inconsistente e trovo assurdo leggerla qui. Usare un 
framework rende un'applicazione molto più sicura, altro che meno 
sicura. C'è più gente a trovar falle, ci sono protocolli di testing 
rigidi, la risoluzione delle falle è centralizzata. Certo, le falle 
una volta trovate sono note, ma non credo di dover spiegare qui che la 
security through obscurity sia un'illusione.


Un framework moderno, persino in PHP, non offre particolari problemi 
di aggiornamento, ho portato interi applicativi, negli anni, da 5.4 a 
8.2 senza particolari sforzi. I framework semplificano anche questo, 
dato che raramente si utilizzano le funzioni "di PHP" più soggette a 
cambiamenti ma si usa la loro versione fornita dal framework, che non 
cambia facilmente API (e quando lo fa è ben documentato nella sezione 
upgrading della documentazione).


Persino sa chi fa solo script, consiglio Laravel Zero.

--
Lorenzo Breda

Re: apache php e problemi nell' upload dei file

[Diego Zuccato]

Neanche io vado matto per PHP, ma alla fine fa il suo sporco lavoro. 
Come il C, si può usare in modo pulito o lercio.
Sarà che oramai tendo all'old (non solo school :) ) ma fatico sempre più 
a capire gli assunti alla base di certi framework.


Altre soluzioni (Python e RubyOnRails, per es.) IMO hanno dalla loro una 
maggiore pulizia, ma presentano un grosso scoglio iniziale (studiare il 
linguaggio, studiare le convenzioni, studiare le librerie) e oltretutto 
si "sposano" malissimo a sistemi di shared virtual hosting (nel mio caso 
ISPConfig, ma in ogni caso è molto più difficile trovare un servizio di 
free hosting che li supporti, mentre praticamente tutti offrono PHP).


Diego

Il 17/05/2023 09:22, Federico Di Gregorio ha scritto:

On 17/05/23 09:15, Giuseppe Naponiello wrote:
Non vorrei andare off-topic ma trovo questo discorso molto 
interessante e mi piacerebbe sentire la vostra opinione.


Negli anni ho provato ad usare vari framework, sia php che javascript, 
ma c'era sempre qualcosa che non mi convinceva fino in fondo. Parlando 
con vari programmatori ho notato che c'è un grande gruppo di 
sostenitori di Laravel e affini, grazie ai quali hanno notevolmente 
velocizzato il loro lavoro, e un altrettanto grande gruppo di 
sostenitori del metodo "old school", tanto (secondo loro) un framework 
php usa comunque le funzioni di php ma è più complesso ed ha più 
vulnerabilità.


Pur essendo io "old school" sono molto incuriosito ma ammetto la mia 
ignoranza in materia, e mi piacerebbe sapere secondo voi se vale 
davvero la pena investire tempo per imparare ad usarne uno


Più che altro c'è un intero mondo al di fuori del PHP (che io 
personalmente considero uno dei più orrorifici linguaggi di 
programmazione mai inventati).


Il mi consiglio è, anche solo per cultura personale, di provare a dargli 
un'occhiata (poi puoi sempre decidere di rimanere col PHP).


federico

Federico Di Gregorio federico.digrego...@dndg.it
DNDG srl  http://dndg.it
   Qu'est ce que la folie? Juste un sentiment de liberté si
    fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra



--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786

Re: apache php e problemi nell' upload dei file

[Lorenzo Breda]

Il mer 17 mag 2023, 09:22 Federico Di Gregorio  ha scritto:

>
> Più che altro c'è un intero mondo al di fuori del PHP (che io
> personalmente considero uno dei più orrorifici linguaggi di
> programmazione mai inventati).
>

C'è sempre JavaScript.

Il mi consiglio è, anche solo per cultura personale, di provare a dargli
> un'occhiata (poi puoi sempre decidere di rimanere col PHP).
>

Da programmatore prevalentemente PHP concordo, ma dico anche che pur con i
suoi problemi residui php8 è un altro linguaggio rispetto a quello che ha
presente il grosso dei critici di PHP.

-- 
Lorenzo Breda

Re: apache php e problemi nell' upload dei file

[Lorenzo Breda]

Il mer 17 mag 2023, 09:15 Giuseppe Naponiello  ha
scritto:

>
> Pur essendo io "old school" sono molto incuriosito ma ammetto la mia
> ignoranza in materia, e mi piacerebbe sapere secondo voi se vale davvero
> la pena investire tempo per imparare ad usarne uno


È una di quelle cose che rischia di scatenare flame, spero non avvenga.

Da persona che ci lavora, trovo che in generale dipende da cosa ci fai, se
tiri su qualche script per hobby probabilmente non ha molto senso, se
invece fai applicazioni di livello professionale è imprescindibile. Certo,
impararlo ha un costo, ma non è che fare unit testing and esempio sia
gratis, eppure è fondamentale e si fa.

Il costo di formazione è l'unico vero svantaggio. La questione della
sicurezza è inconsistente e trovo assurdo leggerla qui. Usare un framework
rende un'applicazione molto più sicura, altro che meno sicura. C'è più
gente a trovar falle, ci sono protocolli di testing rigidi, la risoluzione
delle falle è centralizzata. Certo, le falle una volta trovate sono note,
ma non credo di dover spiegare qui che la security through obscurity sia
un'illusione.

Un framework moderno, persino in PHP, non offre particolari problemi di
aggiornamento, ho portato interi applicativi, negli anni, da 5.4 a 8.2
senza particolari sforzi. I framework semplificano anche questo, dato che
raramente si utilizzano le funzioni "di PHP" più soggette a cambiamenti ma
si usa la loro versione fornita dal framework, che non cambia facilmente
API (e quando lo fa è ben documentato nella sezione upgrading della
documentazione).

Persino sa chi fa solo script, consiglio Laravel Zero.

-- 
Lorenzo Breda

Re: apache php e problemi nell' upload dei file

[Federico Di Gregorio]

On 17/05/23 09:15, Giuseppe Naponiello wrote:
Non vorrei andare off-topic ma trovo questo discorso molto interessante 
e mi piacerebbe sentire la vostra opinione.


Negli anni ho provato ad usare vari framework, sia php che javascript, 
ma c'era sempre qualcosa che non mi convinceva fino in fondo. Parlando 
con vari programmatori ho notato che c'è un grande gruppo di sostenitori 
di Laravel e affini, grazie ai quali hanno notevolmente velocizzato il 
loro lavoro, e un altrettanto grande gruppo di sostenitori del metodo 
"old school", tanto (secondo loro) un framework php usa comunque le 
funzioni di php ma è più complesso ed ha più vulnerabilità.


Pur essendo io "old school" sono molto incuriosito ma ammetto la mia 
ignoranza in materia, e mi piacerebbe sapere secondo voi se vale davvero 
la pena investire tempo per imparare ad usarne uno


Più che altro c'è un intero mondo al di fuori del PHP (che io 
personalmente considero uno dei più orrorifici linguaggi di 
programmazione mai inventati).


Il mi consiglio è, anche solo per cultura personale, di provare a dargli 
un'occhiata (poi puoi sempre decidere di rimanere col PHP).


federico

Federico Di Gregorio federico.digrego...@dndg.it
DNDG srl  http://dndg.it
  Qu'est ce que la folie? Juste un sentiment de liberté si
   fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra

Re: apache php e problemi nell' upload dei file

[Giuseppe Naponiello]

Non vorrei andare off-topic ma trovo questo discorso molto interessante 
e mi piacerebbe sentire la vostra opinione.


Negli anni ho provato ad usare vari framework, sia php che javascript, 
ma c'era sempre qualcosa che non mi convinceva fino in fondo. Parlando 
con vari programmatori ho notato che c'è un grande gruppo di sostenitori 
di Laravel e affini, grazie ai quali hanno notevolmente velocizzato il 
loro lavoro, e un altrettanto grande gruppo di sostenitori del metodo 
"old school", tanto (secondo loro) un framework php usa comunque le 
funzioni di php ma è più complesso ed ha più vulnerabilità.


Pur essendo io "old school" sono molto incuriosito ma ammetto la mia 
ignoranza in materia, e mi piacerebbe sapere secondo voi se vale davvero 
la pena investire tempo per imparare ad usarne uno


-beppe-

Il 16/05/23 23:33, Paride Desimone ha scritto:

Il 16 maggio 2023 12:17:23 UTC, Diego Zuccato  ha 
scritto:

Altro problema: se si adotta un framework per un progetto a lunga scadenza (10 anni o 
più), poi regolarmente ci si scontra con incompatibilità (era per PHP5.6, con 8.1 quella 
versione non funziona più e devi mettere la nuova, che però ha un'API diversa e finisci 
per dover riscrivere tutto o peggio ti introduce dei bug subdoli), catene di dipendenze 
infinite (con relativi problemi di sicurezza), e chi viene per aiutarti (lo sbarbatello 
che "sa programmare il web") non conosce quel framework perché troppo vecchio e 
fuori moda e quindi comunque deve studiarlo da zero.

Per non parlare di un problema di sicurezza: un bug nel framework ti lascia 
esposto a molti più attacchi automatici.


Che è esattamente il perché quando programmavo in COBOL reinventavo spesso una 
nuova ruota.

/paride

Re: apache php e problemi nell' upload dei file

[Giuseppe Naponiello]

Ok, smanettando mi sono accorto che il problema era davvero "banale".

Il problema del caricamento file non era dovuto (nel mio caso) a 
qualcosa di particolarmente strano, non era legato alla direttiva 
PrivateTmp (ho provato a settarla false ma non è cambiato niente) e non 
era legato all'encoding del form...molto più semplicemente 
move_upload_file non riusciva a spostare il file dalla tmp alla cartella 
definitiva perché, ad un certo punto dello sviluppo e in seguito a 
chissà quale aggiornamento, la cartella di destinazione deve essere 
scritta con percorso assoluto e non più relativo, come avevo sempre 
fatto in passato.


Mi dispiace avervi fatto perdere tempo per una cagata simile ma la 
faccenda dei percorsi non l'ho proprio presa in considerazione visto che 
ha sempre funzionato!


-beppe-


Il 15/05/23 17:12, Federico Di Gregorio ha scritto:

On 15/05/23 17:04, Giuseppe Naponiello wrote:

vecchio problema a cui non ho trovato una soluzioni "pulite".

Con l'introduzione di systemd i browser (e tutte le altre 
applicazioni che ne usufruiscono) non scrivono più in /tmp/ ma in 
/tmp/systemd-private-xxx-apache2.service.blablabla...non vado oltre 
perché tanto lo sapete meglio di me di sicuro.


Il problema è che non trovo una soluzione per caricare un file da 
interfaccia web in una cartella del server: con fetch API e formData 
mando il file da caricare al server, che con un funzione php dovrebbe 
spostarlo da tmp alla destinazione finale con la classica funzione 
"move_upload_file", l'errore, come previsto, è che php cerca il file 
da spostare in /tmp/ e non in systemd


sys_get_temp_dir e altre funzioni simili di php mi danno come 
risultato sempre /tmp/, se però provo "new 
\SplFileObject("/tmp/tmp-test.txt", "a+");" me lo scrive 
correttamente in systemd-private.xxx..xyz/tmp/


In php.ini il parametro sys_tmp_dir è commentato perché, dice, se non 
specificato, di default punta alla cartella tmp di sistema. Non ho 
provato a modificarlo perché ho letto da qualche parte che non è la 
soluzione più corretta (ma non ricordo perché).


...ma allora, come diavolo faccio a far caricare agli utenti i loro 
file, visto che i vecchi script non funzionano più?


Sembra che php venga eseguito in un processo differente da quello di 
Apache (altrimenti vedrebbe il namespace corretto per /tmp). Puoi 
dirci se sul sistema c'è anche un service che fa partire PHP? Come 
viene gestito?


federico

Re: apache php e problemi nell' upload dei file

[Paride Desimone]

Il 16 maggio 2023 12:17:23 UTC, Diego Zuccato  ha 
scritto:
>
>Altro problema: se si adotta un framework per un progetto a lunga scadenza (10 
>anni o più), poi regolarmente ci si scontra con incompatibilità (era per 
>PHP5.6, con 8.1 quella versione non funziona più e devi mettere la nuova, che 
>però ha un'API diversa e finisci per dover riscrivere tutto o peggio ti 
>introduce dei bug subdoli), catene di dipendenze infinite (con relativi 
>problemi di sicurezza), e chi viene per aiutarti (lo sbarbatello che "sa 
>programmare il web") non conosce quel framework perché troppo vecchio e fuori 
>moda e quindi comunque deve studiarlo da zero.
>
>Per non parlare di un problema di sicurezza: un bug nel framework ti lascia 
>esposto a molti più attacchi automatici.
>

Che è esattamente il perché quando programmavo in COBOL reinventavo spesso una 
nuova ruota.

/paride


-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.

Re: apache php e problemi nell' upload dei file

[Giuseppe Sacco]

Ciao,

Il giorno lun, 15/05/2023 alle 17.04 +0200, Giuseppe Naponiello ha scritto:
[...]
> sys_get_temp_dir e altre funzioni simili di php mi danno come risultato 
> sempre /tmp/, se però provo "new \SplFileObject("/tmp/tmp-test.txt", 
> "a+");" me lo scrive correttamente in systemd-private.xxx..xyz/tmp/

Puoi confermare che lo trovi in /tmp/systemd-/tmp e non in
/tmp/systemd- (senza l'ulteriore /tmp finale)?

Ciao,
Giuseppe

Re: apache php e problemi nell' upload dei file

[Giuseppe Sacco]

Il giorno mar, 16/05/2023 alle 12.54 +0200, Giuseppe Sacco ha scritto:
> Ciao Giuseppe,
[...]
> Per come la vedo io, il sistema dovrebbe funzionare in questo modo:
> apache2
> parte con una /tmp sempre diversa perché nel file
> /lib/systemd/system/apache2.service c'è scritto PrivateTmp=true. A questo
> punto, quando systemd fa partire il processo di apache, gli imposta una
> specie di file system privato (un namespace) nel quale il path /tmp/
> corrisponde ad una directory che dal punto di vista globale è
> /tmp/systemd A quel punto, qualsiasi altro processo avviato da
> apache2
> vedrà la stessa /tmp.
[...]

Puoi anche fare la controprova disabilitando PrivateTmp per apache2 e
verificando che questo sia proprio la causa del problema. Per
disabilitarlo, crea il file
/etc/systemd/system/apache2.service.d/noprivatetmp.conf
con le due righe seguenti:
[Service]
PrivateTmp=false

e poi dai i due comandi, da root, per rileggere i file e riavviare apache2:
systemctl daemon-reload
systemctl restart apache2

Ciao,
Giuseppe

Re: apache php e problemi nell' upload dei file

[Diego Zuccato]

Beh, anche le mie classi di interfacciamento al db fanno abbastanza 
ridere, di base (p.e. le query mi ritornano comunque un array coi 
risultati, no iteratori, ho preferito la semplicità, non avendo tabelle 
enormi). Però mi è riuscita direi abbastanza bene la gestione delle join :)


Il problema è che gli applicativi o sono fire o tendono a 
crescere stratificandosi, o partono come F e dopo qualche anno te li 
fanno estendere (meno male che avevo previsto una discreta modularità in 
partenza :) ). Purtroppo i framework che avevo guardato al tempo mi 
avrebbero richiesto, per iniziare ad usarli decentemente, più tempo di 
quello che avevo a disposizione per realizzare l'applicativo...


Altro problema: se si adotta un framework per un progetto a lunga 
scadenza (10 anni o più), poi regolarmente ci si scontra con 
incompatibilità (era per PHP5.6, con 8.1 quella versione non funziona 
più e devi mettere la nuova, che però ha un'API diversa e finisci per 
dover riscrivere tutto o peggio ti introduce dei bug subdoli), catene di 
dipendenze infinite (con relativi problemi di sicurezza), e chi viene 
per aiutarti (lo sbarbatello che "sa programmare il web") non conosce 
quel framework perché troppo vecchio e fuori moda e quindi comunque deve 
studiarlo da zero.


Per non parlare di un problema di sicurezza: un bug nel framework ti 
lascia esposto a molti più attacchi automatici.


Diego

Il 16/05/2023 12:56, Giuseppe Naponiello ha scritto:

oddio che bello, non sono solo!!!

Nel mio caso, lavorando tanto con i db, ho visto (ma potrei sbagliarmi) 
che i vari framework sfruttano davvero poco le potenzialità di un db 
come postgresql o anche solo mysql...ma ripeto, sarà perché non conosco 
a fondo le potenzialità di un framework come laravel


Il 16/05/23 11:47, Diego Zuccato ha scritto:
Mah... Ogni volta che ho provato a mettermi dietro ad un framework, mi 
sono ritrovato che era insufficiente o troppo pesante per le mie 
esigenze, oppure pressoché incomprensibile (= quando fossi riuscito a 
capire come usarlo sarebbe già stato obsoleto).


Visto che lo sviluppo di applicativi web è per me molto secondario, ho 
finito per crearmi negli ultimi 15 anni il mio carrozzone di classi 
che alla fine è compatibile con tutto (da 5.6 a 8.1) :)
Sarebbe però interessante un confronto dei vari framework maturi in 
circolazione.


Diego

Il 16/05/2023 11:41, Giuseppe Naponiello ha scritto:

Ciao Lorenzo,

Sono uno sviluppatore PHP, non userò direttamente la funzione da 
decenni (lavoro con i framework)
Prima o poi dovrò decidermi anch'io! Non lo faccio solo per pigrizia, 
ho provato Laravel, i vantaggi sono evidenti ma l'abitudine è dura da 
modificare!!!


La mia esperienza è che il 99.99% degli errori "PHP/java/swift non 
mi trova il file caricato" è dovuto al fatto che il form html non ha 
correttamente settato l'enctype a "multipart/form-data", e quindi 
invece del file viene caricato il suo nome.
Passando i dati (e il file) via FormData() non mi sembrava fosse 
necessario specificare l'enctype del form, comunque molto 
interessante, approfondisco!


Grazie

Il 16/05/23 10:44, Lorenzo Breda ha scritto:
Il lun 15 mag 2023, 17:04 Giuseppe Naponiello  
ha scritto:


    Il problema è che non trovo una soluzione per caricare un file da
    interfaccia web in una cartella del server: con fetch API e 
formData
    mando il file da caricare al server, che con un funzione php 
dovrebbe

    spostarlo da tmp alla destinazione finale con la classica funzione
    "move_upload_file", l'errore, come previsto, è che php cerca il
    file da
    spostare in /tmp/ e non in systemd


Buongiorno,

Non mi risulta che move_uploaded_file abbia problemi con systemd. 
Sono uno sviluppatore PHP, non userò direttamente la funzione da 
decenni (lavoro con i framework) ma sotto quello c'è. Il fatto che 
PHP veda tmp come cartella temporanea invece di quella reale è un 
effetto ottico di systemd, in realtà legge e scrive correttamente in 
quella giusta.


La mia esperienza è che il 99.99% degli errori "PHP/java/swift non 
mi trova il file caricato" è dovuto al fatto che il form html non ha 
correttamente settato l'enctype a "multipart/form-data", e quindi 
invece del file viene caricato il suo nome.


Buona giornata!

--
Lorenzo Breda




--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786

Re: apache php e problemi nell' upload dei file

[Giuseppe Naponiello]

oddio che bello, non sono solo!!!

Nel mio caso, lavorando tanto con i db, ho visto (ma potrei sbagliarmi) 
che i vari framework sfruttano davvero poco le potenzialità di un db 
come postgresql o anche solo mysql...ma ripeto, sarà perché non conosco 
a fondo le potenzialità di un framework come laravel


Il 16/05/23 11:47, Diego Zuccato ha scritto:
Mah... Ogni volta che ho provato a mettermi dietro ad un framework, mi 
sono ritrovato che era insufficiente o troppo pesante per le mie 
esigenze, oppure pressoché incomprensibile (= quando fossi riuscito a 
capire come usarlo sarebbe già stato obsoleto).


Visto che lo sviluppo di applicativi web è per me molto secondario, ho 
finito per crearmi negli ultimi 15 anni il mio carrozzone di classi 
che alla fine è compatibile con tutto (da 5.6 a 8.1) :)
Sarebbe però interessante un confronto dei vari framework maturi in 
circolazione.


Diego

Il 16/05/2023 11:41, Giuseppe Naponiello ha scritto:

Ciao Lorenzo,

Sono uno sviluppatore PHP, non userò direttamente la funzione da 
decenni (lavoro con i framework)
Prima o poi dovrò decidermi anch'io! Non lo faccio solo per pigrizia, 
ho provato Laravel, i vantaggi sono evidenti ma l'abitudine è dura da 
modificare!!!


La mia esperienza è che il 99.99% degli errori "PHP/java/swift non 
mi trova il file caricato" è dovuto al fatto che il form html non ha 
correttamente settato l'enctype a "multipart/form-data", e quindi 
invece del file viene caricato il suo nome.
Passando i dati (e il file) via FormData() non mi sembrava fosse 
necessario specificare l'enctype del form, comunque molto 
interessante, approfondisco!


Grazie

Il 16/05/23 10:44, Lorenzo Breda ha scritto:
Il lun 15 mag 2023, 17:04 Giuseppe Naponiello  
ha scritto:


    Il problema è che non trovo una soluzione per caricare un file da
    interfaccia web in una cartella del server: con fetch API e 
formData
    mando il file da caricare al server, che con un funzione php 
dovrebbe

    spostarlo da tmp alla destinazione finale con la classica funzione
    "move_upload_file", l'errore, come previsto, è che php cerca il
    file da
    spostare in /tmp/ e non in systemd


Buongiorno,

Non mi risulta che move_uploaded_file abbia problemi con systemd. 
Sono uno sviluppatore PHP, non userò direttamente la funzione da 
decenni (lavoro con i framework) ma sotto quello c'è. Il fatto che 
PHP veda tmp come cartella temporanea invece di quella reale è un 
effetto ottico di systemd, in realtà legge e scrive correttamente in 
quella giusta.


La mia esperienza è che il 99.99% degli errori "PHP/java/swift non 
mi trova il file caricato" è dovuto al fatto che il form html non ha 
correttamente settato l'enctype a "multipart/form-data", e quindi 
invece del file viene caricato il suo nome.


Buona giornata!

--
Lorenzo Breda

Re: apache php e problemi nell' upload dei file

[Giuseppe Sacco]

Ciao Giuseppe,

Il giorno lun, 15/05/2023 alle 17.04 +0200, Giuseppe Naponiello ha scritto:
> Buongiorno,
> vecchio problema a cui non ho trovato una soluzioni "pulite".
> 
> Con l'introduzione di systemd i browser (e tutte le altre applicazioni 
> che ne usufruiscono) non scrivono più in /tmp/ ma in 
> /tmp/systemd-private-xxx-apache2.service.blablabla...non vado oltre 
> perché tanto lo sapete meglio di me di sicuro.
[...]

Per come la vedo io, il sistema dovrebbe funzionare in questo modo: apache2
parte con una /tmp sempre diversa perché nel file
/lib/systemd/system/apache2.service c'è scritto PrivateTmp=true. A questo
punto, quando systemd fa partire il processo di apache, gli imposta una
specie di file system privato (un namespace) nel quale il path /tmp/
corrisponde ad una directory che dal punto di vista globale è
/tmp/systemd A quel punto, qualsiasi altro processo avviato da apache2
vedrà la stessa /tmp.

Ora, se l'interprete php è quello della libreria di apache, vienne eseguito
dallo stesso processo (credo) e quindi vede la stessa /tmp; se invece è un
fast cgi, allora comunicano via socket. In questo caso dovresti controllare
quale servizio attiva il fast cgi e, a quel punto, hai la possibilità di
modificare la /tmp del processo fast cgi in modo che sia la stessa di
quello di apache usando il comando JoinsNamespaceOf=apache2.service nel
primo dei due.

Per capire come apache avvia il php devi controllare il sito che hai
configurato.

Ciao,
Giuseppe

Re: apache php e problemi nell' upload dei file

[Diego Zuccato]

Mah... Ogni volta che ho provato a mettermi dietro ad un framework, mi 
sono ritrovato che era insufficiente o troppo pesante per le mie 
esigenze, oppure pressoché incomprensibile (= quando fossi riuscito a 
capire come usarlo sarebbe già stato obsoleto).


Visto che lo sviluppo di applicativi web è per me molto secondario, ho 
finito per crearmi negli ultimi 15 anni il mio carrozzone di classi che 
alla fine è compatibile con tutto (da 5.6 a 8.1) :)
Sarebbe però interessante un confronto dei vari framework maturi in 
circolazione.


Diego

Il 16/05/2023 11:41, Giuseppe Naponiello ha scritto:

Ciao Lorenzo,

Sono uno sviluppatore PHP, non userò direttamente la funzione da 
decenni (lavoro con i framework)
Prima o poi dovrò decidermi anch'io! Non lo faccio solo per pigrizia, ho 
provato Laravel, i vantaggi sono evidenti ma l'abitudine è dura da 
modificare!!!


La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi 
trova il file caricato" è dovuto al fatto che il form html non ha 
correttamente settato l'enctype a "multipart/form-data", e quindi 
invece del file viene caricato il suo nome.
Passando i dati (e il file) via FormData() non mi sembrava fosse 
necessario specificare l'enctype del form, comunque molto interessante, 
approfondisco!


Grazie

Il 16/05/23 10:44, Lorenzo Breda ha scritto:
Il lun 15 mag 2023, 17:04 Giuseppe Naponiello  ha 
scritto:


Il problema è che non trovo una soluzione per caricare un file da
interfaccia web in una cartella del server: con fetch API e formData
mando il file da caricare al server, che con un funzione php dovrebbe
spostarlo da tmp alla destinazione finale con la classica funzione
"move_upload_file", l'errore, come previsto, è che php cerca il
file da
spostare in /tmp/ e non in systemd


Buongiorno,

Non mi risulta che move_uploaded_file abbia problemi con systemd. Sono 
uno sviluppatore PHP, non userò direttamente la funzione da decenni 
(lavoro con i framework) ma sotto quello c'è. Il fatto che PHP veda 
tmp come cartella temporanea invece di quella reale è un effetto 
ottico di systemd, in realtà legge e scrive correttamente in quella 
giusta.


La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi 
trova il file caricato" è dovuto al fatto che il form html non ha 
correttamente settato l'enctype a "multipart/form-data", e quindi 
invece del file viene caricato il suo nome.


Buona giornata!

--
Lorenzo Breda


--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786

Re: apache php e problemi nell' upload dei file

[Lorenzo Breda]

Il mar 16 mag 2023, 11:41 Giuseppe Naponiello  ha
scritto:

> Ciao Lorenzo,
>
> Sono uno sviluppatore PHP, non userò direttamente la funzione da decenni
> (lavoro con i framework)
>
> Prima o poi dovrò decidermi anch'io! Non lo faccio solo per pigrizia, ho
> provato Laravel, i vantaggi sono evidenti ma l'abitudine è dura da
> modificare!!!
>

Un altro mondo davvero.

Passando i dati (e il file) via FormData() non mi sembrava fosse necessario
> specificare l'enctype del form, comunque molto interessante, approfondisco!
>

FormData dovrebbe usare l'encoding corretto. Comunque un'occhiata alla
request per vedere se c'è tutto dalla, se c'è dovrebbe correttamente
funzionare passando come primo parametro il nome effettivo del file:
move_uploaded_file($_FILES["nome_campo"]["tmp_name"], $destinazione)

-- 
Lorenzo Breda

>

Re: apache php e problemi nell' upload dei file

[Giuseppe Naponiello]

Ciao Lorenzo,

Sono uno sviluppatore PHP, non userò direttamente la funzione da 
decenni (lavoro con i framework)
Prima o poi dovrò decidermi anch'io! Non lo faccio solo per pigrizia, ho 
provato Laravel, i vantaggi sono evidenti ma l'abitudine è dura da 
modificare!!!


La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi 
trova il file caricato" è dovuto al fatto che il form html non ha 
correttamente settato l'enctype a "multipart/form-data", e quindi 
invece del file viene caricato il suo nome.
Passando i dati (e il file) via FormData() non mi sembrava fosse 
necessario specificare l'enctype del form, comunque molto interessante, 
approfondisco!


Grazie

Il 16/05/23 10:44, Lorenzo Breda ha scritto:
Il lun 15 mag 2023, 17:04 Giuseppe Naponiello  ha 
scritto:


Il problema è che non trovo una soluzione per caricare un file da
interfaccia web in una cartella del server: con fetch API e formData
mando il file da caricare al server, che con un funzione php dovrebbe
spostarlo da tmp alla destinazione finale con la classica funzione
"move_upload_file", l'errore, come previsto, è che php cerca il
file da
spostare in /tmp/ e non in systemd


Buongiorno,

Non mi risulta che move_uploaded_file abbia problemi con systemd. Sono 
uno sviluppatore PHP, non userò direttamente la funzione da decenni 
(lavoro con i framework) ma sotto quello c'è. Il fatto che PHP veda 
tmp come cartella temporanea invece di quella reale è un effetto 
ottico di systemd, in realtà legge e scrive correttamente in quella 
giusta.


La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi 
trova il file caricato" è dovuto al fatto che il form html non ha 
correttamente settato l'enctype a "multipart/form-data", e quindi 
invece del file viene caricato il suo nome.


Buona giornata!

--
Lorenzo Breda

Re: apache php e problemi nell' upload dei file

[Giuseppe Naponiello]

Ciao, Diego

le 2 direttive che mi indichi sono commentate anche nel mio caso.

Il 16/05/23 10:46, Diego Zuccato ha scritto:
Io uso php-fpm e non ha nessun problema a trovare la cartella dove 
apache mette gli UL...


Nel php.ini sys_temp_dir è commentata.

Magari verifica anche upload_tmp_dir (anche questa da me è commentata).

In tutta /etc/apache2 gli unici riferimenti alla stringa /tmp sono per 
DavLockDB all'interno dei vhost.


Il mio sistema è stato installato seguendo (abbastanza fedelmente) la 
guida "the perfect server" per ISPConfig3.


Diego

Il 16/05/2023 09:42, Federico Di Gregorio ha scritto:

On 15/05/23 18:53, Giuseppe Naponiello wrote:
ok, quindi in php.ini devo decommentare la sezione che gestisce la 
cartella tmp:


; Directory where the temporary files should be placed.
; Defaults to the system default (see sys_get_temp_dir)
;sys_temp_dir = "/tmp"

e invece di /tmp inserire il percorso corretto, cioè quello del 
servizio di apache? Giusto?


Temo di no. Quando Apache viene riavviato la directory usata come 
/tmp potrebbe cambiare e il PHP non la troverebbe più.


federico

Federico Di Gregorio federico.digrego...@dndg.it
DNDG srl http://dndg.it
  heisenbug /hi:'zen-buhg/ /n./ [from Heisenberg's Uncertainty Principle
   in quantum physics] A bug that disappears or alters its behavior when
   one attempts to probe or isolate it.

Re: apache php e problemi nell' upload dei file

[Giuseppe Naponiello]

Ciao Federico,

Quando Apache viene riavviato la directory usata come /tmp potrebbe 
cambiare e il PHP non la troverebbe più. 

Infatti, questo era il mio grande dubbio!

Il 16/05/23 09:42, Federico Di Gregorio ha scritto:

On 15/05/23 18:53, Giuseppe Naponiello wrote:
ok, quindi in php.ini devo decommentare la sezione che gestisce la 
cartella tmp:


; Directory where the temporary files should be placed.
; Defaults to the system default (see sys_get_temp_dir)
;sys_temp_dir = "/tmp"

e invece di /tmp inserire il percorso corretto, cioè quello del 
servizio di apache? Giusto?


Temo di no. Quando Apache viene riavviato la directory usata come /tmp 
potrebbe cambiare e il PHP non la troverebbe più.


federico

Federico Di Gregorio federico.digrego...@dndg.it
DNDG srl http://dndg.it
 heisenbug /hi:'zen-buhg/ /n./ [from Heisenberg's Uncertainty Principle
  in quantum physics] A bug that disappears or alters its behavior when
  one attempts to probe or isolate it.

Re: apache php e problemi nell' upload dei file

[Giuseppe Naponiello]

Ciao Piviul,


non sono molto pratico ma non credo tu sia sulla strada giusta

io invece sono sicuro di NON essere sulla strada giusta!!! 

cat $(ls /etc/apache2/mods-enabled/php*.load)
# Conflicts: php5
# Depends: mpm_prefork
LoadModule php7_module /usr/lib/apache2/modules/libphp7.4.so

Il 15/05/23 20:03, Piviul ha scritto:

Il 15/05/23 18:53, Giuseppe Naponiello ha scritto:
ok, quindi in php.ini devo decommentare la sezione che gestisce la 
cartella tmp:


; Directory where the temporary files should be placed.
; Defaults to the system default (see sys_get_temp_dir)
;sys_temp_dir = "/tmp"

e invece di /tmp inserire il percorso corretto, cioè quello del 
servizio di apache? Giusto?
Ciao Giuseppe, non sono molto pratico ma non credo tu sia sulla strada 
giusta. In apache2 come carichi php? In /etc/apache2/mods-enabled/ 
dove punta il .load per php? In altre parole posta l'otput di


$ cat $(ls /etc/apache2/mods-enabled/php*.load)

Piviul

Re: apache php e problemi nell' upload dei file

[Diego Zuccato]

Io uso php-fpm e non ha nessun problema a trovare la cartella dove 
apache mette gli UL...


Nel php.ini sys_temp_dir è commentata.

Magari verifica anche upload_tmp_dir (anche questa da me è commentata).

In tutta /etc/apache2 gli unici riferimenti alla stringa /tmp sono per 
DavLockDB all'interno dei vhost.


Il mio sistema è stato installato seguendo (abbastanza fedelmente) la 
guida "the perfect server" per ISPConfig3.


Diego

Il 16/05/2023 09:42, Federico Di Gregorio ha scritto:

On 15/05/23 18:53, Giuseppe Naponiello wrote:
ok, quindi in php.ini devo decommentare la sezione che gestisce la 
cartella tmp:


; Directory where the temporary files should be placed.
; Defaults to the system default (see sys_get_temp_dir)
;sys_temp_dir = "/tmp"

e invece di /tmp inserire il percorso corretto, cioè quello del 
servizio di apache? Giusto?


Temo di no. Quando Apache viene riavviato la directory usata come /tmp 
potrebbe cambiare e il PHP non la troverebbe più.


federico

Federico Di Gregorio federico.digrego...@dndg.it
DNDG srl  http://dndg.it
  heisenbug /hi:'zen-buhg/ /n./ [from Heisenberg's Uncertainty Principle
   in quantum physics] A bug that disappears or alters its behavior when
   one attempts to probe or isolate it.



--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786

Re: apache php e problemi nell' upload dei file

[Lorenzo Breda]

Il lun 15 mag 2023, 17:04 Giuseppe Naponiello  ha
scritto:

> Il problema è che non trovo una soluzione per caricare un file da
> interfaccia web in una cartella del server: con fetch API e formData
> mando il file da caricare al server, che con un funzione php dovrebbe
> spostarlo da tmp alla destinazione finale con la classica funzione
> "move_upload_file", l'errore, come previsto, è che php cerca il file da
> spostare in /tmp/ e non in systemd
>

Buongiorno,

Non mi risulta che move_uploaded_file abbia problemi con systemd. Sono uno
sviluppatore PHP, non userò direttamente la funzione da decenni (lavoro con
i framework) ma sotto quello c'è. Il fatto che PHP veda tmp come cartella
temporanea invece di quella reale è un effetto ottico di systemd, in realtà
legge e scrive correttamente in quella giusta.

La mia esperienza è che il 99.99% degli errori "PHP/java/swift non mi trova
il file caricato" è dovuto al fatto che il form html non ha correttamente
settato l'enctype a "multipart/form-data", e quindi invece del file viene
caricato il suo nome.

Buona giornata!

-- 
Lorenzo Breda

Re: apache php e problemi nell' upload dei file

[Federico Di Gregorio]

On 15/05/23 18:53, Giuseppe Naponiello wrote:
ok, quindi in php.ini devo decommentare la sezione che gestisce la 
cartella tmp:


; Directory where the temporary files should be placed.
; Defaults to the system default (see sys_get_temp_dir)
;sys_temp_dir = "/tmp"

e invece di /tmp inserire il percorso corretto, cioè quello del servizio 
di apache? Giusto?


Temo di no. Quando Apache viene riavviato la directory usata come /tmp 
potrebbe cambiare e il PHP non la troverebbe più.


federico

Federico Di Gregorio federico.digrego...@dndg.it
DNDG srl  http://dndg.it
 heisenbug /hi:'zen-buhg/ /n./ [from Heisenberg's Uncertainty Principle
  in quantum physics] A bug that disappears or alters its behavior when
  one attempts to probe or isolate it.

Re: apache php e problemi nell' upload dei file

[Piviul]

Il 15/05/23 18:53, Giuseppe Naponiello ha scritto:
ok, quindi in php.ini devo decommentare la sezione che gestisce la 
cartella tmp:


; Directory where the temporary files should be placed.
; Defaults to the system default (see sys_get_temp_dir)
;sys_temp_dir = "/tmp"

e invece di /tmp inserire il percorso corretto, cioè quello del 
servizio di apache? Giusto?
Ciao Giuseppe, non sono molto pratico ma non credo tu sia sulla strada 
giusta. In apache2 come carichi php? In /etc/apache2/mods-enabled/ dove 
punta il .load per php? In altre parole posta l'otput di


$ cat $(ls /etc/apache2/mods-enabled/php*.load)

Piviul

Re: apache php e problemi nell' upload dei file

[Giuseppe Naponiello]

ok, quindi in php.ini devo decommentare la sezione che gestisce la 
cartella tmp:


; Directory where the temporary files should be placed.
; Defaults to the system default (see sys_get_temp_dir)
;sys_temp_dir = "/tmp"

e invece di /tmp inserire il percorso corretto, cioè quello del servizio 
di apache? Giusto?


Il 15/05/23 18:36, mauro morichi ha scritto:

dipende tutto da come viene gestito php.

Se viene caricato come libreria di apache viene eseguito come apache,

se eseguito in fcgi, allora e' un servizio a parte con un suo namespace.

Il 15/05/2023 18:34, Giuseppe Naponiello ha scritto:
Ciao, non mi sembra ci siano servizi che gestiscano php, che dovrebbe 
essere legato ad Apache...nel senso che per far ripartire o 
ricaricare php devo agire sul processo che gestisce Apache. 

Re: apache php e problemi nell' upload dei file

[mauro morichi]

dipende tutto da come viene gestito php.

Se viene caricato come libreria di apache viene eseguito come apache,

se eseguito in fcgi, allora e' un servizio a parte con un suo namespace.

Il 15/05/2023 18:34, Giuseppe Naponiello ha scritto:
Ciao, non mi sembra ci siano servizi che gestiscano php, che dovrebbe 
essere legato ad Apache...nel senso che per far ripartire o ricaricare 
php devo agire sul processo che gestisce Apache. 

Re: apache php e problemi nell' upload dei file

[Giuseppe Naponiello]

Ciao, non mi sembra ci siano servizi che gestiscano php, che dovrebbe 
essere legato ad Apache...nel senso che per far ripartire o ricaricare 
php devo agire sul processo che gestisce Apache.


Credo sia l'installazione standard

Spero di averti risposto

-beppe-

Il 15/05/23 17:12, Federico Di Gregorio ha scritto:

On 15/05/23 17:04, Giuseppe Naponiello wrote:

vecchio problema a cui non ho trovato una soluzioni "pulite".

Con l'introduzione di systemd i browser (e tutte le altre 
applicazioni che ne usufruiscono) non scrivono più in /tmp/ ma in 
/tmp/systemd-private-xxx-apache2.service.blablabla...non vado oltre 
perché tanto lo sapete meglio di me di sicuro.


Il problema è che non trovo una soluzione per caricare un file da 
interfaccia web in una cartella del server: con fetch API e formData 
mando il file da caricare al server, che con un funzione php dovrebbe 
spostarlo da tmp alla destinazione finale con la classica funzione 
"move_upload_file", l'errore, come previsto, è che php cerca il file 
da spostare in /tmp/ e non in systemd


sys_get_temp_dir e altre funzioni simili di php mi danno come 
risultato sempre /tmp/, se però provo "new 
\SplFileObject("/tmp/tmp-test.txt", "a+");" me lo scrive 
correttamente in systemd-private.xxx..xyz/tmp/


In php.ini il parametro sys_tmp_dir è commentato perché, dice, se non 
specificato, di default punta alla cartella tmp di sistema. Non ho 
provato a modificarlo perché ho letto da qualche parte che non è la 
soluzione più corretta (ma non ricordo perché).


...ma allora, come diavolo faccio a far caricare agli utenti i loro 
file, visto che i vecchi script non funzionano più?


Sembra che php venga eseguito in un processo differente da quello di 
Apache (altrimenti vedrebbe il namespace corretto per /tmp). Puoi 
dirci se sul sistema c'è anche un service che fa partire PHP? Come 
viene gestito?


federico

Re: apache php e problemi nell' upload dei file

[Federico Di Gregorio]

On 15/05/23 17:04, Giuseppe Naponiello wrote:

vecchio problema a cui non ho trovato una soluzioni "pulite".

Con l'introduzione di systemd i browser (e tutte le altre applicazioni 
che ne usufruiscono) non scrivono più in /tmp/ ma in 
/tmp/systemd-private-xxx-apache2.service.blablabla...non vado oltre 
perché tanto lo sapete meglio di me di sicuro.


Il problema è che non trovo una soluzione per caricare un file da 
interfaccia web in una cartella del server: con fetch API e formData 
mando il file da caricare al server, che con un funzione php dovrebbe 
spostarlo da tmp alla destinazione finale con la classica funzione 
"move_upload_file", l'errore, come previsto, è che php cerca il file da 
spostare in /tmp/ e non in systemd


sys_get_temp_dir e altre funzioni simili di php mi danno come risultato 
sempre /tmp/, se però provo "new \SplFileObject("/tmp/tmp-test.txt", 
"a+");" me lo scrive correttamente in systemd-private.xxx..xyz/tmp/


In php.ini il parametro sys_tmp_dir è commentato perché, dice, se non 
specificato, di default punta alla cartella tmp di sistema. Non ho 
provato a modificarlo perché ho letto da qualche parte che non è la 
soluzione più corretta (ma non ricordo perché).


...ma allora, come diavolo faccio a far caricare agli utenti i loro 
file, visto che i vecchi script non funzionano più?


Sembra che php venga eseguito in un processo differente da quello di 
Apache (altrimenti vedrebbe il namespace corretto per /tmp). Puoi dirci 
se sul sistema c'è anche un service che fa partire PHP? Come viene gestito?


federico

apache php e problemi nell' upload dei file

[Giuseppe Naponiello]

Buongiorno,

vecchio problema a cui non ho trovato una soluzioni "pulite".

Con l'introduzione di systemd i browser (e tutte le altre applicazioni 
che ne usufruiscono) non scrivono più in /tmp/ ma in 
/tmp/systemd-private-xxx-apache2.service.blablabla...non vado oltre 
perché tanto lo sapete meglio di me di sicuro.


Il problema è che non trovo una soluzione per caricare un file da 
interfaccia web in una cartella del server: con fetch API e formData 
mando il file da caricare al server, che con un funzione php dovrebbe 
spostarlo da tmp alla destinazione finale con la classica funzione 
"move_upload_file", l'errore, come previsto, è che php cerca il file da 
spostare in /tmp/ e non in systemd


sys_get_temp_dir e altre funzioni simili di php mi danno come risultato 
sempre /tmp/, se però provo "new \SplFileObject("/tmp/tmp-test.txt", 
"a+");" me lo scrive correttamente in systemd-private.xxx..xyz/tmp/


In php.ini il parametro sys_tmp_dir è commentato perché, dice, se non 
specificato, di default punta alla cartella tmp di sistema. Non ho 
provato a modificarlo perché ho letto da qualche parte che non è la 
soluzione più corretta (ma non ricordo perché).


...ma allora, come diavolo faccio a far caricare agli utenti i loro 
file, visto che i vecchi script non funzionano più?



Grazie

-beppe-

Re: R: Apache, CVE-2023-25690 e Rewrite Rules...

[Marco Gaiarin]

Mandi! MAURIZI Lorenzo
  In chel di` si favelave...

> Ma nelle regole che hai inserito tu non ci sono backreferences, nel tuo caso 
> le rewrite rule sono usate per rimbalzare eventuali riferimenti a vecchi path 
> su un nuovo path statico, senza backreferences, quindi credo che non ci 
> saranno problemi. Oltre al flag L c'è R=301, cioè impone al browser di fare 
> redirect con codice 301 (moved permanently), altrimenti il default del flag R 
> è 302 (moved temporarily).

Infatti. Grazie della spiegazione.


> Mi rimane il dubbio di cosa voglia dire "Some out-of-specification  
> RewriteRule directives that were previously silently accepted"
> Mi piacerebbe vederne una di queste out-of-specification RewriteRule per 
> capirne l'errore e la giusta formulazione...

Esatto... ho cercato un po' e debian era l'unica a dare qualche spiegazione,
ma a tratti resta incomprensibile... ;-)


Amen, grazie.

-- 
  Per trovare qualcosa sui siti di Ms devi usare Google :-)
(Simo Sorce, da samba-it)

R: Apache, CVE-2023-25690 e Rewrite Rules...

[MAURIZI Lorenzo]

Ciao Marco,
nelle rewriterule le backreferences dovrebbero essere i $1 $2 che corrispondono 
con i gruppi che si catturano nella prima parte della rule con le parentesi, e 
[L,NC] sono i flag che impostano il comportamento della rewrite rule tipo le 
seguenti:

RewriteRule ^/(.*) http://www.example.com/$1 [L,NC]
RewriteRule ^/sito2/(.*) http://www2.example.com/$1 [L,NC]

Forse queste due rewriterule dovrebbero essere il prototipo di quelle indicate 
dall'annuncio. 

In questo caso il flag L dice ad Apache che la regola è l'ultima e quindi se ci 
fossero sotto altre regole, non vengono elaborate. In effetti per come è fatta 
questa coppia di regole (inventate di sana pianta), la prima acchiappa tutto e 
quindi la seconda non verrà mai eseguita.
NC dice di fare il match case-insensitive.

Ma nelle regole che hai inserito tu non ci sono backreferences, nel tuo caso le 
rewrite rule sono usate per rimbalzare eventuali riferimenti a vecchi path su 
un nuovo path statico, senza backreferences, quindi credo che non ci saranno 
problemi. Oltre al flag L c'è R=301, cioè impone al browser di fare redirect 
con codice 301 (moved permanently), altrimenti il default del flag R è 302 
(moved temporarily).

Mi rimane il dubbio di cosa voglia dire "Some out-of-specification  RewriteRule 
directives that were previously silently accepted"
Mi piacerebbe vederne una di queste out-of-specification RewriteRule per 
capirne l'errore e la giusta formulazione...


Ciao
Lorenzo

-Messaggio originale-
Da: Marco Gaiarin  
Inviato: mercoledì 26 aprile 2023 22:07
A: debian-italian@lists.debian.org
Oggetto: Apache, CVE-2023-25690 e Rewrite Rules...


Beccato baco di Apache, debian pubblica:

https://lists.debian.org/debian-lts-announce/2023/04/msg00028.html

in cui inserisce la sibillina:

 Unfortunately, fixing these security vulnerabilities may require  changes to 
configuration files. Some out-of-specification  RewriteRule directives that 
were previously silently accepted,  are now rejected with error AH10409. For 
instance, some RewriteRules  that included a back-reference and the flags 
"[L,NC]" will need to  be written with extra escaping flags such as "[B= 
?,BNP,QSA]".

che o uno è un Guru delle Apache rewritre rule, o non ci capisce una sega.

Ad esempio "[L,NC]" vuol dire le rewrite rule che contengono 'L' e 'NC' o 
esattamente quelle che contengono 'L,NC'?!

Una rewritre rule come:

RewriteRule ^/\.well-known/carddav 
https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
RewriteRule ^/\.well-known/caldav 
https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
RewriteRule ^/\.well-known/webfinger 
https://%{SERVER_NAME}/index.php/.well-known/webfinger [R=301,L]

(nextcloud) è vulnerabile?!


Grazie...

--
  If SMB was an animal it would go wolf and most people would have shot it
  or put it down humanely.  (Rod Boyce)

Apache, CVE-2023-25690 e Rewrite Rules...

[Marco Gaiarin]

Beccato baco di Apache, debian pubblica:

https://lists.debian.org/debian-lts-announce/2023/04/msg00028.html

in cui inserisce la sibillina:

 Unfortunately, fixing these security vulnerabilities may require
 changes to configuration files. Some out-of-specification
 RewriteRule directives that were previously silently accepted,
 are now rejected with error AH10409. For instance, some RewriteRules
 that included a back-reference and the flags "[L,NC]" will need to
 be written with extra escaping flags such as "[B= ?,BNP,QSA]".

che o uno è un Guru delle Apache rewritre rule, o non ci capisce una sega.

Ad esempio "[L,NC]" vuol dire le rewrite rule che contengono 'L' e 'NC' o
esattamente quelle che contengono 'L,NC'?!

Una rewritre rule come:

RewriteRule ^/\.well-known/carddav 
https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
RewriteRule ^/\.well-known/caldav 
https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
RewriteRule ^/\.well-known/webfinger 
https://%{SERVER_NAME}/index.php/.well-known/webfinger [R=301,L]

(nextcloud) è vulnerabile?!


Grazie...

-- 
  If SMB was an animal it would go wolf and most people would have shot it
  or put it down humanely.  (Rod Boyce)

Re: Apache

[WinterMute]

il Fri, 17 Apr 2020 17:09:09 +0200
erind  ha scritto:

| Salve qualcuno sa se esiste una guida ufficiale approfondita di apache web
| server su debian?

buonasera,

non so se esiste qualcosa di ufficiale, sicuramente online c'è molto materiale 
al
riguardo. 
quello che posso consigliare, in attesa che qualcuno ti fornisca (se possibile)
qualcosa di più specifico, è consultare la documentazione ufficiale di apache 
[1] e
"incrociarla" con le molteplici guide/wiki realizzate per debian. come ad 
esempio
[2] - [3].

saluti.

[1] https://httpd.apache.org/docs/2.4/
[2] https://wiki.debian.org/it/Apache
[3] http://guide.debianizzati.org/index.php/Apache_HTTP_Server

***
|-> WinterMute <-| @ https://www.debian.org/ <--> [branch] bullseye/sid
[GNU  Project] > https://www.gnu.org/
[Kernel  Archives] > https://www.kernel.org/
[GPG  FingerPrint] > 38A4 5354 30C5 E86F 9AA8  B234 7227 D71D A547 39E0
***


pgpE8lBcuoGsu.pgp
Description: Firma digitale OpenPGP

Apache

[erind]

Salve qualcuno sa se esiste una guida ufficiale approfondita di apache web
server su debian?

Re: [OT] node.js e apache, consigli su come gestire più app

[Alessandro Pellizzari]

On 24/05/2019 16:20, Giuseppe Naponiello wrote:

> Kubernetes è nella lista delle robe che volevo imparare ad usare ... mi
> sa che è arrivato il momento! Consigli su come affrontarlo? 

Kubernetes ha senso solo se hai un cluster con almeno 5 macchine, e
anche lì è quasi sprecato e ci sono soluzioni più semplici.

Se hai un solo server è completamente inutile. L'overhead che aggiunge
alla gestione del server e il fatto di dover "spegnere" tutto quando
devi fare upgrade, oltre al fatto che gli upgrade sono completamente
manuali, lo rende non solo inutile, ma anche dannoso.

Se vuoi fare esperimenti installalo con minikube e prova a fare un po'
di esperimenti. È utile almeno per capire come ragiona. Poi prova a
installarlo manualmente su n (3 o 5) Virtualbox.

Se ti ricordi come era Slackware negli anni '90... ecco, Kubernetes in
questo momento è più o meno nello stesso stato. :)

> Certo, pensavo di usare "Forever" [0], mi sembra buono...no?

Penso siano più o meno tutti equivalenti. Io uso nodemon per abitudine,
più che per le feature, a dire il vero. :)

Bye.

Re: [OT] node.js e apache, consigli su come gestire più app

[Giuseppe Naponiello]

Ciao Gollum,
genropy è un po' che ce l'ho lì installato, mi ha sempre incuriosito ma non
ho mai trovato il tempo di smanettarci come avrei voluto.
Grazie anche a te per il suggerimento ;)

Buona serata

-beppe-

Il giorno ven 24 mag 2019 alle ore 12:39 Gollum1 
ha scritto:

> Il 24 maggio 2019 10:23:43 CEST, Giuseppe Naponiello 
> ha scritto:
> >Buongiorno lista,
> >vado al dunque.
> >Dopo anni di utilizzo di php ho avuto la possibilità di sviluppare una
> >Progressive Web App...e mi si è aperto un mondo!
> >Per interesse personale avevo già smanettato con qualche framework tipo
> >angular, react e vue, ed ho iniziato a studiarmi i service worker e
> >workbox.
> >Ma se volessi mettere in produzione app basate su node?
> >Ho visto che fare il deploy su server remoto (apache o nginx) è
> >possibile
> >con proxy pass, e diversi tutorial consigliano di "demonizzare" node
> >per
> >renderlo sempre attivo.
> >Ma nel caso di più app qual'è, secondo la vostra esperienza, il modo
> >migliore per gestire il tutto? Creando un demone per ogni app che
> >voglio
> >pubblicare, questa cosa come incide sulle prestazioni di apache?
> >Grazie per i consigli.
> >
> >Buona giornata
> >
> >-beppe-
>
> è un po' OT, ma visto che stai facendo nuove esperienze, prova a fare un
> occhio anche a genropy, un framework basato su Python server side e js
> client side, ti permette di fare App we che si comportano come App desktop.
> per maggiori info www.genropy.org naturalmente è open source ed è
> sviluppato da un team tutto italiano, molto disponibile in caso di problemi.
>
>
> byez
> --
> gollum1
>
> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità e
> gli errori, maledetto correttore automatico.
>
>

-- 
*Giuseppe Naponiello*

*A**rc-**T**eam srl*
piazza Navarrino, 13 - 38023Cles (TN)
C.F. e P. IVA IT-01941600221
cell. +393476846599
mail: beppen...@arc-team.com
pec: arc-t...@pec.it
101 | www.arc-team.com
110 | http://arc-team-open-research.blogspot.it/
000 | https://independent.academia.edu/GiuseppeNaponiello

Re: [OT] node.js e apache, consigli su come gestire più app

[Giuseppe Naponiello]

Ciao Alessandro,
grazie per i suggerimenti, mi saranno di molto aiuto, almeno ho le idee un
po' più chiare e so da dove partire!

Se non ti serve il server-side-rendering o l'isomorfismo puoi anche servire
> direttamente il frontend tramite apache o nginx. Non hai bisogno di node.js
>
In effetti oggi ho fatto qualche test e, facendo un po' di attenzione sulla
configurazione iniziale, ho visto che è possibile (ottimo il comando "build
--prod" di angular, ad esempio)

Noi in azienda, per esempio, dockerizziamo tutto e pubblichiamo tramite un
> load balancer (nginx) dentro kubernetes. Io, per roba personale, faccio una
> cosa simile: dockerizzo, pusho su un repo privato, deployo con ansible e ho
> traefik configirato per integrarsi con il daemon docker per "trovare" il
> pod.
>

Concentrato sui vari framework e su come farli girare su web server avevo
completamente dimenticato Docker
Ansible l'ho usato qualche volta per il deploy e per la gestione delle
repliche di postgresql, non avevo pensato di usarlo anche per
"automatizzare" le operazioni di github!
Kubernetes è nella lista delle robe che volevo imparare ad usare ... mi sa
che è arrivato il momento! Consigli su come affrontarlo? 

ti consiglio di usare qualcosa tipo nodemon che restarta node nel caso muoia
>
Certo, pensavo di usare "Forever" [0], mi sembra buono...no?

Grazie ancora per i consigli e buona giornata

-beppe-

[0] https://expressjs.com/it/advanced/pm.html#forever

Il giorno ven 24 mag 2019 alle ore 12:06 Alessandro Pellizzari <
shuri...@amiran.it> ha scritto:

> On 24/05/2019 09:30, Giuseppe Naponiello wrote:
>
> > Dopo anni di utilizzo di php ho avuto la possibilità di sviluppare una
> > Progressive Web App...e mi si è aperto un mondo!
> > Per interesse personale avevo già smanettato con qualche framework tipo
> > angular, react e vue, ed ho iniziato a studiarmi i service worker e
> workbox.
>
> Se non ti serve il server-side-rendering o l'isomorfismo puoi anche
> servire direttamente il frontend tramite apache o nginx. Non hai bisogno
> di node.js
>
> > Ma se volessi mettere in produzione app basate su node?
> > Ho visto che fare il deploy su server remoto (apache o nginx) è
> > possibile con proxy pass, e diversi tutorial consigliano di
> > "demonizzare" node per renderlo sempre attivo.
> > Ma nel caso di più app qual'è, secondo la vostra esperienza, il modo
> > migliore per gestire il tutto? Creando un demone per ogni app che voglio
> > pubblicare, questa cosa come incide sulle prestazioni di apache?
>
> Dipende cosa hai a disposizione.
>
> Noi in azienda, per esempio, dockerizziamo tutto e pubblichiamo tramite
> un load balancer (nginx) dentro kubernetes. Io, per roba personale,
> faccio una cosa simile: dockerizzo, pusho su un repo privato, deployo
> con ansible e ho traefik configirato per integrarsi con il daemon docker
> per "trovare" il pod.
>
> In alternativa puoi sempre lanciare node.js anche più volte (su porte
> interne diverse) e puntare il reverse proxy (apache, nginx, traefik,
> quello che preferisci) in base al dominio.
>
> In questo caso ti consiglio di usare qualcosa tipo nodemon che restarta
> node nel caso muoia. Di solito muore a causa di memory leak nel codice
> js o a causa di bug in qualche pacchetto npm che compila codice nativo.
>
> Tieni conto che di default node.js usa un solo core, quindi in base a
> quello che vuoi fare potrebbe anche essere utile lanciare n istanze
> (n=numero di core) e avere un load balancer davanti anche su una sola
> macchina. :)
>
> Bye.
>
>

-- 
*Giuseppe Naponiello*

*A**rc-**T**eam srl*
piazza Navarrino, 13 - 38023Cles (TN)
C.F. e P. IVA IT-01941600221
cell. +393476846599
mail: beppen...@arc-team.com
pec: arc-t...@pec.it
101 | www.arc-team.com
110 | http://arc-team-open-research.blogspot.it/
000 | https://independent.academia.edu/GiuseppeNaponiello

Re: [OT] node.js e apache, consigli su come gestire più app

[Gollum1]

Il 24 maggio 2019 10:23:43 CEST, Giuseppe Naponiello  ha 
scritto:
>Buongiorno lista,
>vado al dunque.
>Dopo anni di utilizzo di php ho avuto la possibilità di sviluppare una
>Progressive Web App...e mi si è aperto un mondo!
>Per interesse personale avevo già smanettato con qualche framework tipo
>angular, react e vue, ed ho iniziato a studiarmi i service worker e
>workbox.
>Ma se volessi mettere in produzione app basate su node?
>Ho visto che fare il deploy su server remoto (apache o nginx) è
>possibile
>con proxy pass, e diversi tutorial consigliano di "demonizzare" node
>per
>renderlo sempre attivo.
>Ma nel caso di più app qual'è, secondo la vostra esperienza, il modo
>migliore per gestire il tutto? Creando un demone per ogni app che
>voglio
>pubblicare, questa cosa come incide sulle prestazioni di apache?
>Grazie per i consigli.
>
>Buona giornata
>
>-beppe-

è un po' OT, ma visto che stai facendo nuove esperienze, prova a fare un occhio 
anche a genropy, un framework basato su Python server side e js client side, ti 
permette di fare App we che si comportano come App desktop. per maggiori info 
www.genropy.org naturalmente è open source ed è sviluppato da un team tutto 
italiano, molto disponibile in caso di problemi.


byez
-- 
gollum1

Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità e gli 
errori, maledetto correttore automatico.

Re: [OT] node.js e apache, consigli su come gestire più app

[Alessandro Pellizzari]

On 24/05/2019 09:30, Giuseppe Naponiello wrote:

Dopo anni di utilizzo di php ho avuto la possibilità di sviluppare una 
Progressive Web App...e mi si è aperto un mondo!
Per interesse personale avevo già smanettato con qualche framework tipo 
angular, react e vue, ed ho iniziato a studiarmi i service worker e workbox.


Se non ti serve il server-side-rendering o l'isomorfismo puoi anche 
servire direttamente il frontend tramite apache o nginx. Non hai bisogno 
di node.js



Ma se volessi mettere in produzione app basate su node?
Ho visto che fare il deploy su server remoto (apache o nginx) è 
possibile con proxy pass, e diversi tutorial consigliano di 
"demonizzare" node per renderlo sempre attivo.
Ma nel caso di più app qual'è, secondo la vostra esperienza, il modo 
migliore per gestire il tutto? Creando un demone per ogni app che voglio 
pubblicare, questa cosa come incide sulle prestazioni di apache?


Dipende cosa hai a disposizione.

Noi in azienda, per esempio, dockerizziamo tutto e pubblichiamo tramite 
un load balancer (nginx) dentro kubernetes. Io, per roba personale, 
faccio una cosa simile: dockerizzo, pusho su un repo privato, deployo 
con ansible e ho traefik configirato per integrarsi con il daemon docker 
per "trovare" il pod.


In alternativa puoi sempre lanciare node.js anche più volte (su porte 
interne diverse) e puntare il reverse proxy (apache, nginx, traefik, 
quello che preferisci) in base al dominio.


In questo caso ti consiglio di usare qualcosa tipo nodemon che restarta 
node nel caso muoia. Di solito muore a causa di memory leak nel codice 
js o a causa di bug in qualche pacchetto npm che compila codice nativo.


Tieni conto che di default node.js usa un solo core, quindi in base a 
quello che vuoi fare potrebbe anche essere utile lanciare n istanze 
(n=numero di core) e avere un load balancer davanti anche su una sola 
macchina. :)


Bye.

[OT] node.js e apache, consigli su come gestire più app

[Giuseppe Naponiello]

Buongiorno lista,
vado al dunque.
Dopo anni di utilizzo di php ho avuto la possibilità di sviluppare una
Progressive Web App...e mi si è aperto un mondo!
Per interesse personale avevo già smanettato con qualche framework tipo
angular, react e vue, ed ho iniziato a studiarmi i service worker e workbox.
Ma se volessi mettere in produzione app basate su node?
Ho visto che fare il deploy su server remoto (apache o nginx) è possibile
con proxy pass, e diversi tutorial consigliano di "demonizzare" node per
renderlo sempre attivo.
Ma nel caso di più app qual'è, secondo la vostra esperienza, il modo
migliore per gestire il tutto? Creando un demone per ogni app che voglio
pubblicare, questa cosa come incide sulle prestazioni di apache?
Grazie per i consigli.

Buona giornata

-beppe-

-- 
*Giuseppe Naponiello*

*A**rc-**T**eam srl*
piazza Navarrino, 13 - 38023Cles (TN)
C.F. e P. IVA IT-01941600221
cell. +393476846599
mail: beppen...@arc-team.com
pec: arc-t...@pec.it
101 | www.arc-team.com
110 | http://arc-team-open-research.blogspot.it/
000 | https://independent.academia.edu/GiuseppeNaponiello

Re: Visualizzare un file ics con apache

[Piviul]

Leandro Noferini ha scritto il 24/11/2016 alle 17:32:

Ciao a tutti,

ho un server owncloud sul quale ci sono i calendari casalinghi. Di questi
riesco ad ottenere facilmente un backup sotto forma di files ics.
bah non so se consigliartelo perché è un porgetto morto oramai... 
l'ultimo aggiornamento risale al 2012; però io lo utilizzo ancora:


https://sourceforge.net/projects/phpicalendar/

Piviul

Visualizzare un file ics con apache

[Leandro Noferini]

Ciao a tutti,

ho un server owncloud sul quale ci sono i calendari casalinghi. Di questi
riesco ad ottenere facilmente un backup sotto forma di files ics.

Vorrei poter visualizzare questi files ics di backup direttamente da
apache così da vedere gli appuntamenti dei mesi passati (che vengono
cancellati dopo un po' dai calendari): sapete se c'è un modo
"automatizzabile"? per farlo ad esempio da cron?

-- 
leandro
1A0B 125B 2E4D 2DAE 4E26  4551 88FB BBCC 7A29 640B
https://bbs.cybervalley.org/ChiaveLeandro/gpg.html
http://6xukrlqedfabdjrb.onion


signature.asc
Description: PGP signature

Re: [Stabile] Apache e autenticazione

[Leandro Noferini]

Luca De Andreis  writes:


[...]

> When this directive is set to None, .htaccess files are completely
> ignored. In this case, the server will not even attempt to read
> .htaccess files in the filesystem.

Non mi funziona :-(

In /etc/apache2/sites-available/default-ssl.conf


Options FollowSymLinks
AllowOverride AuthConfig
Options Indexes FollowSymLinks MultiViews
Order allow,deny
allow from all


in /var/www/calendari/.htaccess

AuthType Basic
AuthName "Calendari di casa"
AuthBasicProvider file
AuthUserFile "/etc/apache2/calpass"
Require valid-user

E non mi chiede la password :-(

-- 
leandro
1A0B 125B 2E4D 2DAE 4E26  4551 88FB BBCC 7A29 640B
https://bbs.cybervalley.org/ChiaveLeandro/gpg.html
http://6xukrlqedfabdjrb.onion


signature.asc
Description: PGP signature

Re: [Stabile] Apache e autenticazione

[emmanuel segura]

  
AuthType Basic
AuthName "Calendari di casa"
AuthBasicProvider file
AuthUserFile "/etc/apache2/calpass"
Require valid-user
  

Il 31 ottobre 2016 18:25, Leandro Noferini 
ha scritto:
> Leandro Noferini  writes:
>
> Dopo qualche prova ho capito che queste righe:
>
>>   
>> Options FollowSymLinks
>> AllowOverride None
>> Options Indexes FollowSymLinks MultiViews
>> Order allow,deny
>> allow from all
>>   
>
> Mi impedivano la richiesta di autenticazione per tutte le sottocartelle
> del sito: eliminandole ho risolto.
>
> Grazie a tutti lo stesso!
>
> --
> leandro
> 1A0B 125B 2E4D 2DAE 4E26  4551 88FB BBCC 7A29 640B
> https://bbs.cybervalley.org/ChiaveLeandro/gpg.html
> http://6xukrlqedfabdjrb.onion



-- 
  .~.
  /V\
 //  \\
/(   )\
^`~'^

Re: [Stabile] Apache e autenticazione

[Luca De Andreis]

Ciao,

non penso che la rimozione di tutte le direttive sia saggia, identifico 
il problema nella direttiva allowoverride:


When this directive is set to None, .htaccess files are completely 
ignored. In this case, the server will not even attempt to read 
.htaccess files in the filesystem.


Puoi pensare di non usare proprio un All, ma una più sana:

AllowOverride AuthConfig

Ciao

Luca



smime.p7s
Description: Firma crittografica S/MIME

Re: [Stabile] Apache e autenticazione

[Leandro Noferini]

Leandro Noferini  writes:

Dopo qualche prova ho capito che queste righe:

>   
> Options FollowSymLinks
> AllowOverride None
> Options Indexes FollowSymLinks MultiViews
> Order allow,deny
> allow from all
>   

Mi impedivano la richiesta di autenticazione per tutte le sottocartelle
del sito: eliminandole ho risolto.

Grazie a tutti lo stesso!

-- 
leandro
1A0B 125B 2E4D 2DAE 4E26  4551 88FB BBCC 7A29 640B
https://bbs.cybervalley.org/ChiaveLeandro/gpg.html
http://6xukrlqedfabdjrb.onion


signature.asc
Description: PGP signature

[Stabile] Apache e autenticazione

[Leandro Noferini]

Ciao a tutti,

premetto che sono un utente inconsapevole nonché un balbettante in
lingua madre apache e che quindi spesso non so quello che sto facendo.

Sto provando a proteggere una cartella del server apache con una
password ma non mi riesce perché la password non mi viene richiesta e la
cartella viene mostrata subito.

Ho provato questa configurazione:

- nel file di configurazione del sito queste mi paiono le righe
  significative

  DocumentRoot /var/www
  
Options FollowSymLinks
AllowOverride None
Options Indexes FollowSymLinks MultiViews
Order allow,deny
allow from all
  

  e poi la cartella in questione

  
AuthType Basic
AuthName "Calendari di casa"
AuthBasicProvider file
AuthUserFile "/etc/apache2/calpass"
Require valid-user
  

- il file /etc/apache2/calpass mi sembra di averlo creato così come i
  Sacri Testi insegnano

- il modulo auth_basic è abilitato

E invece niente, non viene richiesta nessuna password e nessuna
segnalazione particolare nei log.

Dove posso cercare l'errore?

-- 
leandro
1A0B 125B 2E4D 2DAE 4E26  4551 88FB BBCC 7A29 640B
https://bbs.cybervalley.org/ChiaveLeandro/gpg.html
http://6xukrlqedfabdjrb.onion



signature.asc
Description: PGP signature

utenze ftp che puntino home directory apache

[marco pirola]

Ciao a tutti. Come faccio a far si che il server ftp (vsftp) punti alle 
home directory di apache realizzate sotto var/www/

Re: utenze ftp che puntino home directory apache

[dea]

Il Thu, 17 Dec 2015 11:13:36 +0100, marco pirola scrisse
> Ciao a tutti. Come faccio a far si che il server ftp (vsftp) punti 
> alle home directory di apache realizzate sotto var/www/

Ho paura che la risposta che ti daranno sarà:

man vsftp

Comunque lo trovi in 3 secondi su un motore di ricerca: 

http://askubuntu.com/questions/575523/how-to-setup-virtual-users-for-vsftpd-with-access-to-a-specific-sub-directory

Un esempio

Re: utenze ftp che puntino home directory apache

[Mauro]

Il 17/12/15 11:13, marco pirola ha scritto:
> Ciao a tutti. Come faccio a far si che il server ftp (vsftp) punti alle
> home directory di apache realizzate sotto var/www/

non uso vsftp preferendo proftp, ma di norma, la home impostata per
l'utente che si collega e' quella che viene poi visualizzata dal server
ftp. Tradotto, se crei un utente Lillo che punta a /var/www/lillo.
vsftp ti porta la'.

Re: utenze ftp che puntino home directory apache

[Marco Pirola]

E come permessi?
Il 17/Dic/2015 11:22, "Mauro" <ma...@966.it> ha scritto:

>
>
> Il 17/12/15 11:13, marco pirola ha scritto:
> > Ciao a tutti. Come faccio a far si che il server ftp (vsftp) punti alle
> > home directory di apache realizzate sotto var/www/
>
> non uso vsftp preferendo proftp, ma di norma, la home impostata per
> l'utente che si collega e' quella che viene poi visualizzata dal server
> ftp. Tradotto, se crei un utente Lillo che punta a /var/www/lillo.
> vsftp ti porta la'.
>

Re: utenze ftp che puntino home directory apache

[Pol Hallen]

> E come permessi?

normalmente:

755 le dir
644 i file

apache 2.4

[Walter Valenti]

Devo mettere un apache 2.4 su una macchina che fa da ReverseProxy.
Il motivo è che con il 2.2 ho dei problemi con mod_proxy_html.

La macchina in questione è una Debian Stabile, che fa solo da reverse proxy,
verso un portale joomla. Insomma nulla di critico.

Mi chiedevo: conviene aggiornarla a testing (dove c'è il 2.4) o compilarsi 
l'apache manualmente ?

Walter




 
--
Per favore non inviatemi allegati in formato MS Office.
Utilizza alternativamente documenti in formato OpenDocument.


http://oinophilos.blogspot.com/


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1382349169.31468.yahoomail...@web171402.mail.ir2.yahoo.com

Re: apache 2.4

[emmanuel segura]

Ciao Walter,

Ma hai provato a installare apache da back-ports?


Il giorno 21 ottobre 2013 11:52, Walter Valenti waltervale...@yahoo.it ha
scritto:

 Devo mettere un apache 2.4 su una macchina che fa da ReverseProxy.
 Il motivo è che con il 2.2 ho dei problemi con mod_proxy_html.

 La macchina in questione è una Debian Stabile, che fa solo da reverse
 proxy,
 verso un portale joomla. Insomma nulla di critico.

 Mi chiedevo: conviene aggiornarla a testing (dove c'è il 2.4) o compilarsi
 l'apache manualmente ?

 Walter





 --
 Per favore non inviatemi allegati in formato MS Office.
 Utilizza alternativamente documenti in formato OpenDocument.


 http://oinophilos.blogspot.com/


 --
 Per REVOCARE l'iscrizione alla lista, inviare un email a
 debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
 problemi inviare un email in INGLESE a listmas...@lists.debian.org

 To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive:
 http://lists.debian.org/1382349169.31468.yahoomail...@web171402.mail.ir2.yahoo.com




-- 
esta es mi vida e me la vivo hasta que dios quiera

Re: apache 2.4

[Walter Valenti]

No, effettivamente non ci avevo pensato.
Direi che potrebbe essere la soluzione migliore.


 
--
Per favore non inviatemi allegati in formato MS Office.
Utilizza alternativamente documenti in formato OpenDocument.


http://oinophilos.blogspot.com/



Il Lunedì 21 Ottobre 2013 12:07, emmanuel segura emi2f...@gmail.com ha 
scritto:
 
Ciao Walter,

Ma hai provato a installare apache da back-ports?




Il giorno 21 ottobre 2013 11:52, Walter Valenti waltervale...@yahoo.it ha 
scritto:

Devo mettere un apache 2.4 su una macchina che fa da ReverseProxy.
Il motivo è che con il 2.2 ho dei problemi con mod_proxy_html.

La macchina in questione è una Debian Stabile, che fa solo da reverse proxy,
verso un portale joomla. Insomma nulla di critico.

Mi chiedevo: conviene aggiornarla a testing (dove c'è il 2.4) o compilarsi
l'apache manualmente ?

Walter




 
--
Per favore non inviatemi allegati in formato MS Office.
Utilizza alternativamente documenti in formato OpenDocument.


http://oinophilos.blogspot.com/


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1382349169.31468.yahoomail...@web171402.mail.ir2.yahoo.com




-- 
esta es mi vida e me la vivo hasta que dios quiera 

Re: apache 2.4

[Pol Hallen]

Nei backport ho trovato solo una versione che arriva da sid

Pol


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/526501dc.5040...@fuckaround.org

Re: apache 2.4

[Walter Valenti]

Nei backport ho trovato solo una versione che arriva da sid



Io non trovo nessuna versione di apache.
Stiamo cercando in due posti diversi ?
http://backports.debian.org/changes/wheezy-backports.html



--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1382360951.54034.yahoomail...@web171405.mail.ir2.yahoo.com

Re: apache 2.4

[Walter Valenti]

 Il Lunedì 21 Ottobre 2013 15:09, Walter Valenti waltervale...@yahoo.it ha 
 scritto:
  
 Nei backport ho trovato solo una versione che arriva da sid
 
 
 
 Io non trovo nessuna versione di apache.
 Stiamo cercando in due posti diversi ?
 http://backports.debian.org/changes/wheezy-backports.html
 

Questo, vero?

deb http://www.d7031.de/debian wheezy-experimental main



--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1382361919.25123.yahoomail...@web171401.mail.ir2.yahoo.com

Re: apache 2.4

[Pol Hallen]

 Io non trovo nessuna versione di apache.
 Stiamo cercando in due posti diversi ?
 http://backports.debian.org/changes/wheezy-backports.html

https://www.d7031.de/content/apache-24-backports-debian-squeeze-and-wheezy 

Pol

Problema Apache

[Stefano]

Ciao a tutti
su una debian 6 ho installato in un server di produzione apache,php e mysql.
Ogni tanto al giorno succede che i 4 core dei processori vanno tutti al 
100% e piano piano la macchina si pianta.

Il processo è uno dei tanti httpd che va al 200%.
Come faccio a capire cosa lo fa impazzire??


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5257ba92.4010...@stefanospagna.it

Re: Problema Apache

[Pol Hallen]

 su una debian 6 ho installato in un server di produzione apache,php e
 mysql. Ogni tanto al giorno succede che i 4 core dei processori vanno
 tutti al 100% e piano piano la macchina si pianta.
 Il processo è uno dei tanti httpd che va al 200%.
 Come faccio a capire cosa lo fa impazzire??

non ne ho idea...

mi verrebbe in mente: sei sotto DOS? :-D 
hai provato a limitare le risorse d'uso di apache rispetto al sistema?

fammi sapere

Pol


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131006.12794.debitv...@fuckaround.org

Re: Problema Apache

[Luca Costantino]

 su una debian 6 ho installato in un server di produzione apache,php e
 mysql. Ogni tanto al giorno succede che i 4 core dei processori vanno
 tutti al 100% e piano piano la macchina si pianta.
 Il processo è uno dei tanti httpd che va al 200%.
 Come faccio a capire cosa lo fa impazzire??

la macchina è esposta su internet?


-- 
Chiave pubblica http://luca.costantino.googlepages.com/luca.costantino.asc

Prima di tutto vennero a prendere gli zingari e fui contento, perché
rubacchiavano.
Poi vennero a prendere gli ebrei e stetti zitto, perché mi stavano antipatici.
Poi vennero a prendere gli omosessuali, e fui sollevato, perché mi
erano fastidiosi.
Poi vennero a prendere i comunisti, e io non dissi niente, perché non
ero comunista.
Un giorno vennero a prendere me, e non c’era rimasto nessuno a protestare.
(Martin Niemöller)


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+vfGHZFJrHdJN-1JHbxD8utWb03xxpB3aFvE9RCEpRNþx...@mail.gmail.com

Re: Problema Apache

[Gian Uberto Lauri]

Stefano writes:
  Ciao a tutti
  su una debian 6 ho installato in un server di produzione apache,php e mysql.
  Ogni tanto al giorno succede che i 4 core dei processori vanno tutti al 
  100% e piano piano la macchina si pianta.
  Il processo è uno dei tanti httpd che va al 200%.
  Come faccio a capire cosa lo fa impazzire??

Non  è che  le applicazioni  cominciano a  fare baruffe  chioggiotte
sulle risorse condivise? Ci sono query SQL perfide?

Cosa dicono i log riguardo a quello che sta succedendo?

-- 
ing. Gian Uberto Lauri
Solution Developer Senior
Direzione Ricerca e Innovazione
gianuberto.la...@eng.it

Sun Java Certified Programmer

Engineering Ingegneria Informatica spa
Corso Stati Uniti 23/C, 35127 Padova (PD)

Tel. +39-049.8283.571 | main(){printf(unix[\021%six\012\0],
Fax  +39-049.8283.569 |(unix)[have]+fun-0x60);}
http://www.eng.it |  David Korn, ATT Bell Labs
  |  ioccc best One Liner, 1987


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21079.50611.461957.285...@mail.eng.it

Re: Problema Apache

[Piviul]

Stefano scrisse in data 11/10/2013 10:45:

Ciao a tutti
su una debian 6 ho installato in un server di produzione apache,php e 
mysql.
Ogni tanto al giorno succede che i 4 core dei processori vanno tutti 
al 100% e piano piano la macchina si pianta.

Il processo è uno dei tanti httpd che va al 200%.
Come faccio a capire cosa lo fa impazzire??

il log di apache non dicono nulla?

Piviul


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5257c6a7.2020...@riminilug.it

Re: Problema Apache

[Gian Uberto Lauri]

Gian Uberto Lauri writes:
  Non  è che  le applicazioni  cominciano a  fare baruffe  chioggiotte
  sulle risorse condivise? Ci sono query SQL perfide?
  
  Cosa dicono i log riguardo a quello che sta succedendo?

Aggiungo (visto che giustamente Stefano dice che è httpd che si mangia
la CPU):

- L'ambiente di collaudo era identico a quello di produzione, anche come
  carico?

- Hai provato  a incrociare le feature  di php usate con  le liste dei
  bug aperti? La CPU al 100% potrebbe indicare loop infiniti su codice
  che non fa I/O e quindi si mangia tutto il time-slice.

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian

Warning: gnome-config-daemon considered more dangerous than GOTO


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21079.52526.560089.31...@mail.eng.it

Re: Problema Apache

[Walter Valenti]

- Messaggio originale -
 Da: Stefano stef...@stefanospagna.it
 A: debian-italian@lists.debian.org
 Cc: 
 Inviato: Venerdì 11 Ottobre 2013 10:45
 Oggetto: Problema Apache
 
 Ciao a tutti
 su una debian 6 ho installato in un server di produzione apache,php e mysql.
 Ogni tanto al giorno succede che i 4 core dei processori vanno tutti al 
 100% e piano piano la macchina si pianta.
 Il processo è uno dei tanti httpd che va al 200%.
 Come faccio a capire cosa lo fa impazzire??
 

La roba php cosa fa?
Potrebbe essere che in certe condizioni vada in loop senza riuscirne a uscire.

Walter


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1381483998.52178.yahoomail...@web171401.mail.ir2.yahoo.com

Re: Problema Apache

[Claudio Giordano]

Il giorno Fri, 11 Oct 2013 10:33:18 +0100 (BST)
Walter Valenti waltervale...@yahoo.it ha scritto:
  Ciao a tutti
  su una debian 6 ho installato in un server di produzione apache,php
  e mysql. Ogni tanto al giorno succede che i 4 core dei processori
  vanno tutti al 100% e piano piano la macchina si pianta.
  Il processo è uno dei tanti httpd che va al 200%.
  Come faccio a capire cosa lo fa impazzire??
  
 
 La roba php cosa fa?
 Potrebbe essere che in certe condizioni vada in loop senza riuscirne
 a uscire.
 
 Walter
 
 


Teoricamente questo problema non dovrebbe verificarsi grazie alla
direttiva max_execution_time = secondi ( di default a 30 ) del php.ini
e quando entra in funzione interrompendo uno script in loop troviamo
sui log delle voci simili a Maximum execution time exceeded forse
potrebbe essere colpa di qualche query e/o della configurazione di
mysql, capita che generando molti risultati all'esecuzione di una query
saturi ram e/o spazio su disco con le tabelle temporanee, dai anche
un'occhiata allo script mysqltuner che può darti utili consigli
sull'ottimizzazione di mysql.

Saluti.
-- 
Claudio Giordano


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131011141853.503f83e2@Falce

Re: Problema Apache

[Piviul]

Claudio Giordano scrisse in data 11/10/2013 14:18:
Teoricamente questo problema non dovrebbe verificarsi grazie alla 
direttiva max_execution_time = secondi ( di default a 30 ) del php.ini 
e quando entra in funzione interrompendo uno script in loop troviamo 
sui log delle voci simili a Maximum execution time exceeded forse 
potrebbe essere colpa di qualche query e/o della configurazione di 
mysql, capita che generando molti risultati all'esecuzione di una 
query saturi ram e/o spazio su disco con le tabelle temporanee, dai 
anche un'occhiata allo script mysqltuner che può darti utili consigli 
sull'ottimizzazione di mysql. 
se fosse così non dovrebbe essere un processo di mysql a tenere la cpu 
al 100%?


Piviul


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5258025c.2080...@riminilug.it

apache

[Pol Hallen]

Ciao a tutti :-)

non vorrei andare OT... stavo guardando le configurazioni di AllowOverride e 
vorrei capirci un pò di più..

Directory /var/www/
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
/Directory

in che modo posso consentire soltanto la configurazione delle pagine 
ErrorDocument in .htaccess?

Allowoverride options=ErrorDocument

ho visto che c'è una direttiva AllowoverrideList che fa proprio al mio caso... 
peccato che:

1) è nella versione 2.4 di apache (in debian7 c'è la 2.4)
2) il server è in produzione e non posso farci esperimenti

qualche idea?

grazie

Pol


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201310111636.26654.debitv...@fuckaround.org

Re: Permessi apache e ftp server

[Walter Valenti]

 
  Potresti creare un nuovo gruppo. Metti gli utenti www-data e quello di
  proftd nel gruppo. Dopo di che dai i permessi di lettura e scrittura al
  gruppo.
 
 io domando (ma prima spiego)
 
 /home/domain1.org con permessi:
 
 drwxr-xr-x  4 domain1.org domain1.org  4096 Oct  2 15:04 dir_test
 -rw-r--r--  1 domain1.org domain1.org 17816 Oct  2 15:02 file_test
 
 finchè (other) ha i permessi in lettura (come nel mio caso) il sito 
 funziona...
 
 se però un qualche cms (joomla ad esempio) installando un modulo mi setta i 
 permessi di quel modulo come:
 
 -rw---  1 domain1.org domain1.org 17816 Oct  2 15:02 file_test
 
 allora il cms inizia a funzionare male...
 
 e ora la domanda:
 
 andrebbero settati i permessi così:
 
 drwxr-xr-x  4 www-data www-data 4096 Oct  2 15:04 dir_test
 -rw-r--r--  1 www-data www-data 17816 Oct  2 15:02 file_test
 


Sicuramente così funziona.
Devi pero inseire l'utente di proftp nel gruppo www-data.
Anche percgè l'alternativa è convincere Joomla a comportarsi in maniera diversa.

Walter


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1380787006.24679.yahoomail...@web171406.mail.ir2.yahoo.com

Permessi apache e ftp server

[Stefano]

Ciao a tutti,
ho un piccolo quesito con i permessi.
Ho installato apache con virtual hosts e proftpd server.
Ho creato le mie cartelle per i siti con utenti apache.
Ho creato i miei utenti virtuali con solo 1 utente per ftp.
Come setto i permessi delle cartelle dei virtual host perchè siamo 
accessibili da apache e da proftpd?

grazie


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/524c06b0.8070...@stefanospagna.it

Re: Permessi apache e ftp server

[Walter Valenti]

- Messaggio originale -
 Da: Stefano stef...@stefanospagna.it
 A: debian-italian@lists.debian.org
 Cc: 
 Inviato: Mercoledì 2 Ottobre 2013 13:42
 Oggetto: Permessi apache e ftp server
 
 Ciao a tutti,
 ho un piccolo quesito con i permessi.
 Ho installato apache con virtual hosts e proftpd server.
 Ho creato le mie cartelle per i siti con utenti apache.
 Ho creato i miei utenti virtuali con solo 1 utente per ftp.
 Come setto i permessi delle cartelle dei virtual host perchè siamo 
 accessibili da apache e da proftpd?
 grazie
 

Potresti creare un nuovo gruppo. Metti gli utenti www-data e quello di proftd 
nel gruppo.
Dopo di che dai i permessi di lettura e scrittura al gruppo.

Walter


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1380717927.79090.yahoomail...@web171404.mail.ir2.yahoo.com

Re: Permessi apache e ftp server

[Pol Hallen]

 Potresti creare un nuovo gruppo. Metti gli utenti www-data e quello di
 proftd nel gruppo. Dopo di che dai i permessi di lettura e scrittura al
 gruppo.

io domando (ma prima spiego)

/home/domain1.org con permessi:

drwxr-xr-x  4 domain1.org domain1.org  4096 Oct  2 15:04 dir_test
-rw-r--r--  1 domain1.org domain1.org 17816 Oct  2 15:02 file_test

finchè (other) ha i permessi in lettura (come nel mio caso) il sito funziona...

se però un qualche cms (joomla ad esempio) installando un modulo mi setta i 
permessi di quel modulo come:

-rw---  1 domain1.org domain1.org 17816 Oct  2 15:02 file_test

allora il cms inizia a funzionare male...

e ora la domanda:

andrebbero settati i permessi così:

drwxr-xr-x  4 www-data www-data 4096 Oct  2 15:04 dir_test
-rw-r--r--  1 www-data www-data 17816 Oct  2 15:02 file_test

grazie per l'aiuto :-)

Pol


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201310021745.55437.debitv...@fuckaround.org

Compilazione modulo apache

[Walter Valenti]

Sto cercando di compilare un modulo apache (mod_proxy_html) su una stabile.
Eseguo:

apxs2 -c mod_proxy_html.c -I/usr/include/libxml2/

Ma continua a darmi il seguente errore:
fatal error: libxml/HTMLparser.h: No such file or directory

Ovviamente /usr/include/libxml2/libxml/HTMLparser.h esiste

Dove sbaglio ?

Walter



 
--
Per favore non inviatemi allegati in formato MS Office.
Utilizza alternativamente documenti in formato OpenDocument.


http://oinophilos.blogspot.com/


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1380531539.2354.yahoomail...@web171406.mail.ir2.yahoo.com

Re: Compilazione modulo apache

[Walter Valenti]

 
 Sto cercando di compilare un modulo apache (mod_proxy_html) su una 
 stabile.
 Eseguo:
 
 apxs2 -c mod_proxy_html.c -I/usr/include/libxml2/
 
 Ma continua a darmi il seguente errore:
 fatal error: libxml/HTMLparser.h: No such file or directory
 
 Ovviamente /usr/include/libxml2/libxml/HTMLparser.h esiste
 
 Dove sbaglio ?

Mi rispondo da solo: sono deficiente.

apxs2 -I/usr/include/libxml2 -c mod_proxy_html.c

Walter


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1380532460.72354.yahoomail...@web171404.mail.ir2.yahoo.com

[OT] Re: Compilazione modulo apache

[elio marvin]

In data lunedì 30 settembre 2013 11:14:20, Walter Valenti ha scritto:
  Sto cercando di compilare un modulo apache (mod_proxy_html) su una
  stabile.
  Eseguo:
  
  apxs2 -c mod_proxy_html.c -I/usr/include/libxml2/
  
  Ma continua a darmi il seguente errore:
  fatal error: libxml/HTMLparser.h: No such file or directory
  
  Ovviamente /usr/include/libxml2/libxml/HTMLparser.h esiste
  
  Dove sbaglio ?
 
 Mi rispondo da solo: sono deficiente.

Ma che esagerazione! . . . bastava dire è lunedì!
Se continui a lavorare, incidenti ne capiteranno ancora :D

 
 apxs2 -I/usr/include/libxml2 -c mod_proxy_html.c
 
 Walter

Ciao :)
-- 
elio


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201309301158.32999.emarvin3...@gmail.com

Re: [OT] Re: Compilazione modulo apache

[giulianc51]

Il giorno Mon, 30 Sep 2013 11:58:32 +0200
elio marvin emarvin3...@gmail.com ha scritto:

 In data lunedì 30 settembre 2013 11:14:20, Walter Valenti ha scritto:
   Sto cercando di compilare un modulo apache (mod_proxy_html) su una
   stabile.
   
   Dove sbaglio ?
  
  Mi rispondo da solo: sono deficiente.
 
 Ma che esagerazione! . . . bastava dire è lunedì!
 Se continui a lavorare, incidenti ne capiteranno ancora :D

+1
anch'io conosco un modo solo per NON fare errori :-)


  Walter
 
 Ciao :)

ciao,
giuliano


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130930121411.4f55ff28@acerCF

Re: [OT] Re: Compilazione modulo apache

[Walter Valenti]

 
 In data lunedì 30 settembre 2013 11:14:20, Walter Valenti ha scritto:
   Sto cercando di compilare un modulo apache (mod_proxy_html) su una
   stabile.
   Eseguo:
   
   apxs2 -c mod_proxy_html.c -I/usr/include/libxml2/
   
   Ma continua a darmi il seguente errore:
   fatal error: libxml/HTMLparser.h: No such file or directory
   
   Ovviamente /usr/include/libxml2/libxml/HTMLparser.h esiste
   
   Dove sbaglio ?
 
  Mi rispondo da solo: sono deficiente.
 
 Ma che esagerazione! . . . bastava dire è lunedì!
 Se continui a lavorare, incidenti ne capiteranno ancora :D

Lo so. Ho una lunga esperienza di errori.
Ma questo era proprio stupido.


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1380538355.59163.yahoomail...@web171405.mail.ir2.yahoo.com

Re: [OT] Re: Compilazione modulo apache

[emmanuel segura]

Domanda anche se non c'entra niente con la piega che ha presso la
conversazione, ma perche stai compilando mod_proxy_html? non dovrebbe
essere uno dei moduli incluso nell'installazione di default di apache2?


Il giorno 30 settembre 2013 12:52, Walter Valenti
waltervale...@yahoo.itha scritto:



 
  In data lunedì 30 settembre 2013 11:14:20, Walter Valenti ha scritto:
Sto cercando di compilare un modulo apache (mod_proxy_html) su una
stabile.
Eseguo:
   
apxs2 -c mod_proxy_html.c -I/usr/include/libxml2/
   
Ma continua a darmi il seguente errore:
fatal error: libxml/HTMLparser.h: No such file or directory
   
Ovviamente /usr/include/libxml2/libxml/HTMLparser.h esiste
   
Dove sbaglio ?
 
   Mi rispondo da solo: sono deficiente.
 
  Ma che esagerazione! . . . bastava dire è lunedì!
  Se continui a lavorare, incidenti ne capiteranno ancora :D

 Lo so. Ho una lunga esperienza di errori.
 Ma questo era proprio stupido.


 --
 Per REVOCARE l'iscrizione alla lista, inviare un email a
 debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
 problemi inviare un email in INGLESE a listmas...@lists.debian.org

 To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive:
 http://lists.debian.org/1380538355.59163.yahoomail...@web171405.mail.ir2.yahoo.com




-- 
esta es mi vida e me la vivo hasta que dios quiera

Re: [OT] Re: Compilazione modulo apache

[Walter Valenti]

Domanda anche se non c'entra niente con la piega che ha presso la 
conversazione, ma perche stai compilando mod_proxy_html? non dovrebbe essere 
uno dei moduli incluso nell'installazione di default di apache2?



Nel 2.4 sì.
Nel 2.2 no.


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1380539143.76760.yahoomail...@web171405.mail.ir2.yahoo.com

Re: [OT] Re: Compilazione modulo apache

[emmanuel segura]

@Walter Grazie 1000


Il giorno 30 settembre 2013 13:05, Walter Valenti
waltervale...@yahoo.itha scritto:



 
 
 Domanda anche se non c'entra niente con la piega che ha presso la
 conversazione, ma perche stai compilando mod_proxy_html? non dovrebbe
 essere uno dei moduli incluso nell'installazione di default di apache2?
 


 Nel 2.4 sì.
 Nel 2.2 no.


 --
 Per REVOCARE l'iscrizione alla lista, inviare un email a
 debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
 problemi inviare un email in INGLESE a listmas...@lists.debian.org

 To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive:
 http://lists.debian.org/1380539143.76760.yahoomail...@web171405.mail.ir2.yahoo.com




-- 
esta es mi vida e me la vivo hasta que dios quiera

apache

[Pol Hallen]

giorno :-)

che voi sappiate, è possibile usare suphp per eseguire gli script perl?
(se si, come?)

grazie

Pol


-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52440816.1020...@fuckaround.org

Re: apache

[dea]

Il Thu, 26 Sep 2013 12:10:30 +0200, Pol Hallen scrisse
 giorno :-)
 
 che voi sappiate, è possibile usare suphp per eseguire gli script perl?
 (se si, come?)

Uso un software PERL che deve eseguire parte di codice come root, in tal caso
uso un wrapper con setuid ... con mille più una cautela.

CIAO

Luca


-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130926130512.m23...@corep.it

Re: apache

[Pol Hallen]

 Uso un software PERL che deve eseguire parte di codice come root, in tal
 caso uso un wrapper con setuid ... con mille più una cautela.

ho provato suexec* ma comunque basta uno script perl tipo cp /etc/shadow ... e 
l'utente si copia il file shadow

a me occorre eseguire gli script cgi con le stesse inibizioni messe in php.ini 
(niente shell, etc.)

grazie

Pol


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201309261520.21185.debitv...@fuckaround.org

apache 2.4

[Walter Valenti]

Ho provato su una macchina la migrazione da apache 2.2 ad apache 2.4 (su 
testing)

A parte le varie direttive/moduli che sono cambiate, sembra non funzionare più 
a2ensite.
Risponde sempre che il sito non esiste.

Qualcuno ha provato?

Walter




 
--
Per favore non inviatemi allegati in formato MS Office.
Utilizza alternativamente documenti in formato OpenDocument.


http://oinophilos.blogspot.com/


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1375712517.97246.yahoomail...@web171401.mail.ir2.yahoo.com

Re: apache 2.4

[Walter Valenti]

 Ho provato su una macchina la migrazione da apache 2.2 ad apache 2.4 (su 
 testing)
 
 A parte le varie direttive/moduli che sono cambiate, sembra non funzionare 
 più 
 a2ensite.
 Risponde sempre che il sito non esiste.
 
 Qualcuno ha provato?
 
 Walter


Rispondo da solo.
I files di configurazione dei siti, devono essere per forza *.conf.

Walter


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1375714159.42717.yahoomail...@web171403.mail.ir2.yahoo.com

Re: apache 2.4

[Pol Hallen]

 I files di configurazione dei siti, devono essere per forza *.conf.

grazie per le info :-)

Pol


-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51ffe6ee.5060...@fuckaround.org

apache

[Pol Hallen]

'giorno a tutti :-)

ho fatto un pò di ricerche... vane :-/

se ho:

sito1.org/webmail (server1) - webmail è un redirect a sito2

site2.org/webmail (server2)

posso mascherare site2.org/webmail come se fosse site1.org/webmail?

grazie

Pol


-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51efc02e.3020...@fuckaround.org

Re: apache

[Walter Valenti]

 
 ho fatto un pò di ricerche... vane :-/
 
 se ho:
 
 sito1.org/webmail (server1) - webmail è un redirect a sito2
 
 site2.org/webmail (server2)
 
 posso mascherare site2.org/webmail come se fosse site1.org/webmail?
 
 grazie
 
 Pol


Se ho ho ben capito quello che vuoi fare:

Nel VH di sito1.org
ProxyPass /webmail http://sito2.org/webmail
ProxyPassReverse /webmail http://sito2.org/webmail

Walter


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1374667154.71534.yahoomail...@web171403.mail.ir2.yahoo.com