Re: apache php e problemi nell' upload dei file
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
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
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
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
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
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
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
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
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
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
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
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
È 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Re: apache 2.4
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
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
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
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
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
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
Re: apache
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
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
Re: apache 2.4
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
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
Re: apache
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
Re: apache
Ciao a tutti, se ho capito bene la tua domanda, potresti mettere in piedi un proxy apache2 sul server1. cerca mod_proxy. A presto, Gianluca In data 24/07/2013 13:53 Pol Hallen ha scritto: '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 -- *Gianluca Francesco Signorotto* website = http://www.eritrium.org/ -- 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.4040...@eritrium.org
Re: apache
ProxyPass /webmail http://sito2.org/webmail ProxyPassReverse /webmail http://sito2.org/webmail esattamente :-) tnks! 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/51f03445.1080...@fuckaround.org
Re: apache 2.4 e pagina php con include
2013/7/2 Paolo Nicorelli p.nicore...@gmail.com sempre nella pagina generata da phpinfo() guarda che include_path indichi anche la dir corrente [ . ] la mia ad esempio è include_path .:/usr/share/php:/usr/share/pear c'è il punto .:/usr/share/php:/usr/share/pear Nel caso modificala dentro il file ini che carichi: * Loaded Configuration File * Additional .ini files parsed (le leggi sempre dal phpinfo) se non è quello, che ti dicono i files di log? niente, a parte un warning sul time zone
Re: apache 2.4 e pagina php con include
Il giorno 02 luglio 2013 09:35, Gianfranco Costamagna costamagnagianfra...@yahoo.it ha scritto: sicuramente non sarà quello il problema, ma io non amo molto l'aprire il tag php con ** secondo me è sempre meglio specificare che si tratta di codice php per evitare possibili errori di interpretazione del codice invece era proprio questo il problema aprendo con ?php le pagine funzionano (e anche nei log appare qualche avviso) grazie a tutti
Re: apache 2.4 e pagina php con include
Da: Federico Bruni fedel...@gmail.com A: costamagnagianfra...@yahoo.it Cc: debian-italian@lists debian. org debian-italian@lists.debian.org Inviato: Mercoledì 3 Luglio 2013 9:04 Oggetto: Re: apache 2.4 e pagina php con include Il giorno 02 luglio 2013 09:35, Gianfranco Costamagna costamagnagianfra...@yahoo.it ha scritto: sicuramente non sarà quello il problema, ma io non amo molto l'aprire il tag php con secondo me è sempre meglio specificare che si tratta di codice php per evitare possibili errori di interpretazione del codice invece era proprio questo il problema aprendo con ?php le pagine funzionano (e anche nei log appare qualche avviso) Bello accorgersi che il tuo MUA di android bellamente elimini i caratteri che non ama dal quoting della risposta! Sarà stata un bel po' criptica come risposta con i tag nascosti! comunque sono contento che funzioni! (sono un master nello scrivere codice python senza specificare l'interprete, poi quando lo lanci con python script.py funziona tutto, se provi con ./ escono fuori gli errori più strani ed improbabili... e questo succede in molti progetti open source purtroppo) G. grazie a tutti -- 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/1372838938.8701.yahoomail...@web172703.mail.ir2.yahoo.com
Re: apache 2.4 e pagina php con include
sempre nella pagina generata da phpinfo() guarda che include_path indichi anche la dir corrente [ . ] la mia ad esempio è include_path .:/usr/share/php:/usr/share/pear Nel caso modificala dentro il file ini che carichi: * Loaded Configuration File * Additional .ini files parsed (le leggi sempre dal phpinfo) se non è quello, che ti dicono i files di log? On 2 July 2013 08:52, Federico Bruni fedel...@gmail.com wrote: Sto provando la nuova versione di apache. Ho un sito in php che funzionava bene su apache 2.2 mentre ora non riesce a includere un file .php La pagina inizia così: ? include(functions.php); print $header; ? questi sono i moduli abilitati: /etc/apache2# ls mods-enabled/ access_compat.load authn_file.load autoindex.conf dir.conf mime.conf negotiation.conf setenvif.conf alias.confauthz_core.load autoindex.load dir.load mime.load negotiation.load setenvif.load alias.loadauthz_host.load deflate.confenv.load mpm_prefork.conf php5.conf status.conf auth_basic.load authz_user.load deflate.loadfilter.load mpm_prefork.load php5.load status.load
Re: apache 2.4 e pagina php con include
sicuramente non sarà quello il problema, ma io non amo molto l'aprire il tag php con ? secondo me è sempre meglio specificare che si tratta di codice php per evitare possibili errori di interpretazione del codice. Detto questo io proverei a mettere qualche print nel file incluso, giusto per vedere dove fallisce l'interpretazione del file ciao G. Sent from Yahoo! Mail on Android
Re: apache 2.4 e pagina php con include
ti da qualche messaggio di errore in particolare? se scrivi altro codice, ad esempio una echo, questo viene eseguito? e se cambiassi i tag in ?php bla bla ? ? -- 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/51d31cc3.1000...@infrid.com
Re: apache chroot
No! Se apache è in chroot vedi solo la root fittizia in cui si trova apache, non la root della macchina reale. quindi perchè usando www-data con user posso vedere la root? mi sembra di aver configurato correttamente il chroot. Pol Perchè è il processo di apache che gira nella gabbia chroot. Quando ti loggi esegui la bash. 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/1371456848.88135.yahoomail...@web171406.mail.ir2.yahoo.com
Re: apache chroot
Perchè è il processo di apache che gira nella gabbia chroot. Quando ti loggi esegui la bash. immaginavo si... mi sai dire come mai libapache2-mod-chroot non è più presente in wheezy? facevo i test sulla 6, ho notato che sulla 7 il modulo non è presente... 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/201306171102.03118...@fuckaround.org
Re: apache chroot
Il giorno 16/giu/2013 15:31, Pol Hallen debitv...@fuckaround.org ha scritto: Buona domenica a tutti :-) seguendo questa guida http://guide.debianizzati.org/index.php/Configurare_Apache_in_un_ambiente_Chroot ho configurato apache in chroot. La domanda č: se qualcuno dovesse bucarlo ottiene i permessi www-data quindi se mi loggo e faccio su www-data posso vedere la root del sistema e tutti i file di configurazione, anche se di fatto con www-data non potrei fare nulla (mi auguro)... No! Se apache è in chroot vedi solo la root fittizia in cui si trova apache, non la root della macchina reale. non mi sembra proprio una soluzione sicura... cosa potrei adottare in alternativa? -- Gollum1 teoro, dov'è il mio teoro...
Re: apache chroot
No! Se apache è in chroot vedi solo la root fittizia in cui si trova apache, non la root della macchina reale. quindi perchè usando www-data con user posso vedere la root? mi sembra di aver configurato correttamente il chroot. 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/51bdc97e.7080...@fuckaround.org
Ri: Re: apache chroot
cosa potrei adottare in alternativa? L'alternativa al chroot è qualcosa di più spinto (anche se l'idea dell'isolamento permane), ovvero avere una serie di macchine virtuali, ciascuna con servizi specifici (e solo quelli), sfruttando così l'isolamento che offre la macchina virtuale dalle altre. Se viene bucata una VM perchè viene sfruttata una qualche vulnerabilità di un servizio è ragionevole che il danno si limiti alla singola VM. 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/20130616141534.m81...@corep.it
Re: Ri: Re: apache chroot
era una soluzione che avevo valutato tempo fa... ma in questo caso non ho possibilità di mettere macchine virtuali :-) 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/51bdcfa1.1060...@fuckaround.org
Re: apache e virtual host (maledetti!)
Il Sat, 25 May 2013 13:15:43 +0200, Pol Hallen ha scritto: Sto cercando di fare andare i virtual host, in site-enabled ho entrambi i siti, solo che dominio2.com non c'è verso di farlo andare (punta sempre e comunque alla home del server). L'altro invece è quello default e funziona grrr... qualche idea?! Grazie per l'aiuto! Tre. 1- hai la direttiva NameVirtualHost configurata correttamente? 2- hai riavvialo (o reloadato) apache? 3- Apache ha il diritto di lettura in /home/dominio2/... Bye. -- 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/knq7ti$u83$1...@ger.gmane.org
Re: apache e virtual host (maledetti!)
1- hai la direttiva NameVirtualHost configurata correttamente? cioè? :-D 2- hai riavvialo (o reloadato) apache? certo! 3- Apache ha il diritto di lettura in /home/dominio2/... no: ma cambiando i permessi con chown -R www-data dominio2 stesso problema 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/51a0a5e7.2080...@fuckaround.org
Re: apache e virtual host (maledetti!)
Il Sat, 25 May 2013 13:52:07 +0200, Pol Hallen ha scritto: 1- hai la direttiva NameVirtualHost configurata correttamente? cioè? :-D /etc/apache2$ rgrep NameVirtualHost * ports.conf:NameVirtualHost *:80 Se non hai questa riga, i Virtualhost non vengono abilitati, e funziona solo il primo definito, con qualsiasi indirizzo contatti il server. Bye. -- 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/knq8q7$u83$2...@ger.gmane.org
Re: apache e virtual host (maledetti!)
/etc/apache2$ rgrep NameVirtualHost * ports.conf:NameVirtualHost *:80 è presente, si: NameVirtualHost *:80 Listen 80 domanda: il mio è hostname è: server1.dominio1.com e in /etc/hosts ho: 87.23.12.67 server1.fuckaround.org server1 può essere causato da un'errata configurazione di questi? Sennò in che altro modo posso risolvere? Eppoi: come faccio il dump del virtual host? 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/51a0a874.8080...@fuckaround.org
Re: apache e virtual host (maledetti!)
Il 25/05/13 13:15, Pol Hallen ha scritto: 'giorno a tutti :-) Non quanti howto abbia letto ancora non ci sono arrivato :-/ apache 2.2.16-6+squeeze11 funziona correttamente :-) ho 2 domini reali (dominio1.com, dominio2.com che dal pannello dns su internet ho fatto puntare all'IP statico del mio server) Sto cercando di fare andare i virtual host, in site-enabled ho entrambi i siti, solo che dominio2.com non c'è verso di farlo andare (punta sempre e comunque alla home del server). L'altro invece è quello default e funziona grrr... qualche idea?! Grazie per l'aiuto! cat /etc/apache2/site-enabled/001-default: VirtualHost *:80 ServerName domain1.com DocumentRoot /var/www/ Directory / Options FollowSymLinks AllowOverride None /Directory Directory /var/www/ Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all /Directory /VirtualHost cat /etc/apache2/site-enabled/domain2 VirtualHost *:80 ServerName domain2.com ServerAlias www.domain2.com # Indexes + Directory Root. #DirectoryIndex index.html DocumentRoot /home/domain2/domain2/htdocs/ /VirtualHost In caso ti possa essere utile questa è la mia configurazione per il secondo dominio: VirtualHost *:80 ServerAdmin webmaster@localhost ServerName www.altrodominio.it DocumentRoot /var/web/altrodominio/www/ Directory / Options FollowSymLinks AllowOverride None /Directory Directory /var/web/altrodominio/www/ Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all /Directory ScriptAlias /cgi-bin/ /var/web/altrodominio/cgi-bin/ Directory /var/web/altrodominio/cgi-bin AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all /Directory /VirtualHost in /etc/hosts www.altrodominio.it non risulta affatto. saluti Edoardo -- 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/51a0c092.2020...@aspix.it
Re: apache e virtual host (maledetti!)
Ciao a tutti Io ho trovato lo stesso problema su redhat, ma sempre apache, questo succede quando non c'e un virtualhost di default, comunque questo link puo essere utile http://httpd.apache.org/docs/2.2/vhosts/examples.html Il giorno 25 maggio 2013 15:45, Edoardo Panfili edoa...@aspix.it ha scritto: Il 25/05/13 13:15, Pol Hallen ha scritto: 'giorno a tutti :-) Non quanti howto abbia letto ancora non ci sono arrivato :-/ apache 2.2.16-6+squeeze11 funziona correttamente :-) ho 2 domini reali (dominio1.com, dominio2.com che dal pannello dns su internet ho fatto puntare all'IP statico del mio server) Sto cercando di fare andare i virtual host, in site-enabled ho entrambi i siti, solo che dominio2.com non c'è verso di farlo andare (punta sempre e comunque alla home del server). L'altro invece è quello default e funziona grrr... qualche idea?! Grazie per l'aiuto! cat /etc/apache2/site-enabled/001-**default: VirtualHost *:80 ServerName domain1.com DocumentRoot /var/www/ Directory / Options FollowSymLinks AllowOverride None /Directory Directory /var/www/ Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all /Directory /VirtualHost cat /etc/apache2/site-enabled/**domain2 VirtualHost *:80 ServerName domain2.com ServerAlias www.domain2.com # Indexes + Directory Root. #DirectoryIndex index.html DocumentRoot /home/domain2/domain2/htdocs/ /VirtualHost In caso ti possa essere utile questa è la mia configurazione per il secondo dominio: VirtualHost *:80 ServerAdmin webmaster@localhost ServerName www.altrodominio.it DocumentRoot /var/web/altrodominio/www/ Directory / Options FollowSymLinks AllowOverride None /Directory Directory /var/web/altrodominio/www/ Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all /Directory ScriptAlias /cgi-bin/ /var/web/altrodominio/cgi-bin/ Directory /var/web/altrodominio/cgi-**bin AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all /Directory /VirtualHost in /etc/hosts www.altrodominio.it non risulta affatto. saluti Edoardo -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-REQUEST@lists.**debian.orgdebian-italian-requ...@lists.debian.orgcon oggetto unsubscribe. Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-REQUEST@lists.**debian.orgdebian-italian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/**51a0c092.2020...@aspix.ithttp://lists.debian.org/51a0c092.2020...@aspix.it -- esta es mi vida e me la vivo hasta que dios quiera
Re: apache e virtual host (maledetti!)
Il 25/05/13 15:45, Edoardo Panfili ha scritto: Il 25/05/13 13:15, Pol Hallen ha scritto: 'giorno a tutti :-) Non quanti howto abbia letto ancora non ci sono arrivato :-/ apache 2.2.16-6+squeeze11 funziona correttamente :-) ho 2 domini reali (dominio1.com, dominio2.com che dal pannello dns su internet ho fatto puntare all'IP statico del mio server) Sto cercando di fare andare i virtual host, in site-enabled ho entrambi i siti, solo che dominio2.com non c'è verso di farlo andare (punta sempre e comunque alla home del server). L'altro invece è quello default e funziona grrr... qualche idea?! Grazie per l'aiuto! cat /etc/apache2/site-enabled/001-default: VirtualHost *:80 ServerName domain1.com DocumentRoot /var/www/ Directory / Options FollowSymLinks AllowOverride None /Directory Directory /var/www/ Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all /Directory /VirtualHost cat /etc/apache2/site-enabled/domain2 VirtualHost *:80 ServerName domain2.com ServerAlias www.domain2.com # Indexes + Directory Root. #DirectoryIndex index.html DocumentRoot /home/domain2/domain2/htdocs/ /VirtualHost In caso ti possa essere utile questa è la mia configurazione per il secondo dominio: scusate precisazione: non avevo detto che questa configurazione funziona (almeno nel mio caso). Edoardo VirtualHost *:80 ServerAdmin webmaster@localhost ServerName www.altrodominio.it DocumentRoot /var/web/altrodominio/www/ Directory / Options FollowSymLinks AllowOverride None /Directory Directory /var/web/altrodominio/www/ Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all /Directory ScriptAlias /cgi-bin/ /var/web/altrodominio/cgi-bin/ Directory /var/web/altrodominio/cgi-bin AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all /Directory /VirtualHost in /etc/hosts www.altrodominio.it non risulta affatto. saluti Edoardo -- 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/51a0da8e.3080...@aspix.it
Re: apache e virtual host (maledetti!)
grazie a tutti! ho poi scoperto di avere permessi strampalati in /etc/apache2/sites-available e non me ne ero accorto... beh... mi son fatto una bella cultura di apache :-) 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/51a0e827.6050...@fuckaround.org
Re: Apache 2 e php5 su wheezy: upgrade con crash totale
Ciao la butto li: ?php phpinfo() ; ? viene eseguito oppure mostra il testo? i moduli php per apache sono ancora installati? libapache2-mod-php5 - server-side, HTML-embedded scripting language (Apache 2 module) libapache2-mod-php5filter - server-side, HTML-embedded scripting language (apache 2 filter module) php5-cgi - server-side, HTML-embedded scripting language (CGI binary) php5-fpm - server-side, HTML-embedded scripting language (FPM-CGI binary) nel file di configurazione ci sono i link alle lib di php? e come index files: php, etc? e questo? in Application.cpp:249: File /var/www/Claroline-1.3.1/INGEOSIS/index.php is writeable by group controlla anche i permessi fammi sapere saluti 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/201305211214.08599.debitv...@fuckaround.org
Re: apache e certificato (perplessità)
On Thu, 16 May 2013, mauro wrote: non per essere rompi balle, pero' posso immaginare questo: hai un server con certificati ssl. Non so' in che contesto tu lavori, quindi cerco di ragionare sulla mia esperienza. all'interno del server un tuo cliente, collegato via https utilizza un sito bacato, oppure ha a sua volta il pc compromesso o tutt'e due. il tuo server e' gia' un pezzo in avanti per rischiare la sua integrita'. In altre parole, attento al falso senso di sicurezza. L'unico caso che mi vien in mente e potrebbe essere logico è che tu vuoi far partire quel server solo tu. ma a questo punto non lo metti più in avvio e semplicemente lo avvie quando sei pronto a mettere la password. -- Leonardo Boselli -- 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/alpine.deb.2.00.1305211138420.17...@dipolo.dicea.unifi.it
Re: Apache 2 e php5 su wheezy: upgrade con crash totale
Dopo l'upgrade da squeeze a wheezy apache2 ha smesso di fuzionare o quasi: in parole povere non funziona più php5: se richiamo qualcosa dalla documento root o daun alias del sito principale mi mostra il codica php come fosse un file html normale. se richiamo da una pagina di un utente invece: [Tue May 21 11:46:40 2013] [error] [client 150.217.9.3] SoftException in Application.cpp:221: File /home/leo/public_html/ttt/index.php is not in document root of Vhost /var/www/ [Tue May 21 11:46:40 2013] [error] [client 150.217.9.3] Premature end of script headers: index.php altre pagine (che sono sempre sotto home) danno: [Tue May 21 11:44:47 2013] [error] [client 150.217.251.53] SoftException in Application.cpp:249: File /var/www/Claroline-1.3.1/INGEOSIS/index.php is writeable by group [Tue May 21 11:44:47 2013] [error] [client 150.217.251.53] Premature end of script headers: index.php [Tue May 21 11:45:05 2013] [error] [client 157.55.35.53] SoftException in Application.cpp:350: UID of script /var/www/Claroline-1.3.1/claroline/exercice/exercice.php is smaller than min_uid [Tue May 21 11:45:05 2013] [error] [client 157.55.35.53] Premature end of script headers: exercice.php ci sono dei suggerimenti in fase di aggiornamento riguardo a delle modifiche ma non ho ben capito a che servano, soprattutto perché dicono che servono per altre cose qualcuno ha gia sperimentato il problema ? Io non ho problemi di alcun genere. Ho delle macchine wheezy con joomla. Non è che usi qualche framework, particolare? 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/1369131479.95586.yahoomail...@web171404.mail.ir2.yahoo.com
Re: Apache 2 e php5 su wheezy: upgrade con crash totale
Risolto: era da aggiungere libapache2-mod-php5filter (che non è scritto da nessuna parte) e da togliere libapache2-mod-suphp (che pare abbia qualche bachetto ) ora sembra funzionare. -- Leonardo Boselli -- 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/alpine.deb.2.00.1305211242280.26...@dipolo.dicea.unifi.it
Re: apache e certificato (perplessità)
In altre parole, attento al falso senso di sicurezza. L'unico caso che mi vien in mente e potrebbe essere logico è che tu vuoi far partire quel server solo tu. ma a questo punto non lo metti più in avvio e semplicemente lo avvie quando sei pronto a mettere la password. CIAO ! Non sono convinto che questa metodologia innalzi il fattore di sicurezza del sistema, bensì che lo startup del demone digitando una password crei una sensazione di FALSA sicurezza addizionale in root. Se i permessi del certificato sono corretti, dovrebbe bastare, se mantieni la macchina aggiornata, ecc. ecc. se non si fanno cavolate nelle configurazioni, se si ha una sana e giustificata paranoia, poi, se non basta, potresti studiarti (cosa che io non ho fatto ma sempre vorrei) SELinux. Trovo che ci siano soluzioni più efficaci per sicurizzare un sistema oltre gli standard, se davvero se ne ha necessità, ancora trovo che proteggere i certificati con un sistema simmetrico allo startup del demone dia solo una falsa sicurezza. IMHO 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/20130521161644.m65...@corep.it
Re: Apache 2 e php5 su wheezy: upgrade con crash totale
:-) 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/519ba719.7080...@fuckaround.org
Re: apache e certificato (perplessità)
La perplessità nel subject mi lascia perplesso. Credimi, non è normale. Hai mai visto un sistemista con n macchine che in seguito ad un riavvio deve digitare la password dei vari certificati SSL ? documentandomi mi sbilancio un pò ad avere una maggiore sicurezza MA più interventi fisici... Non è normale... vuol dire farsi del male, parliamone. :-D 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/201305161521.03424.polhal...@fuckaround.org
Re: apache e certificato (perplessità)
La perplessità nel subject mi lascia perplesso. Credimi, non è normale. Hai mai visto un sistemista con n macchine che in seguito ad un riavvio deve digitare la password dei vari certificati SSL ? documentandomi mi sbilancio un pò ad avere una maggiore sicurezza MA più interventi fisici... Non è normale... vuol dire farsi del male, parliamone. :-D 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/201305161527.43150.polhal...@fuckaround.org
Re: apache e certificato (perplessità)
La perplessità nel subject mi lascia perplesso. Credimi, non è normale. Hai mai visto un sistemista con n macchine che in seguito ad un riavvio deve digitare la password dei vari certificati SSL ? documentandomi mi sbilancio un pò ad avere una maggiore sicurezza MA più interventi fisici... Non è normale... vuol dire farsi del male, parliamone. :-D 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/201305161118.30950.polhal...@fuckaround.org
Re: apache e certificato (perplessità)
Il giorno 16/mag/2013, alle ore 15:21, Pol Hallen polhal...@fuckaround.org ha scritto: documentandomi mi sbilancio un pò ad avere una maggiore sicurezza MA più interventi fisici... allora possiamo argomentare a volonta'. la sicurezza non e' nel mettere o non mettere la password del certificato ssl all'avvio del server ma fare in modo che su quel server non entri nessuno ne' via rete ne via hardware. regola 1: se un server e' fisicamente accessibile, la sicurezza va a belle signore. regola 2: un certificato ssl garantisce il server e garantisce la comunicazione, ma di per se' garantisce solo una parte di tutto il discorso sicurezza. regola 3: anche non usando ssl puoi avere un server ragionevolmente sicuro. non per essere rompi balle, pero' posso immaginare questo: hai un server con certificati ssl. Non so' in che contesto tu lavori, quindi cerco di ragionare sulla mia esperienza. all'interno del server un tuo cliente, collegato via https utilizza un sito bacato, oppure ha a sua volta il pc compromesso o tutt'e due. il tuo server e' gia' un pezzo in avanti per rischiare la sua integrita'. -- 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/681187d6-c262-4491-a135-f0fed70e5...@nonsolocomputer.com
Re: apache e certificato (perplessità)
PS: è ovvio che posso mettere apache come ultimo servizio S99 o gestirmela in modo diverso... che poi: il problema si risolve solo in parte: se metto S99apache anzichè S10apache e successivamente installo un qualche daemon (che casualmente viene messo anche lui in S99) init cosa avvia per primo? S99apache o (esempio) S99uptimed? va in ordine alfabetico? mi sembra una soluzione troppo grezza per un OS debian 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/201305151310.45133.debitv...@fuckaround.org
Re: apache e certificato (perplessità)
Consapevole che al riavvio di apache devo inserire la passphrase (idem al riavvio del server). Pol... La perplessità nel subject mi lascia perplesso. Credimi, non è normale. Hai mai visto un sistemista con n macchine che in seguito ad un riavvio deve digitare la password dei vari certificati SSL ? Non è normale... vuol dire farsi del male, parliamone. :) -- 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/20130515154329.m20...@corep.it
Re: apache virtual host
ho un server (primario) con apache2 e un altro server (secondario) nella lan con apache2. Ho fatto il portforwarding della porta 80 del server della lan su una porta del primario. Da internet specifico la porta e mi collego. Il problema è che le richieste vanno sull'ip della lan e non riesco ad accedere alle pagine. Sto cercando di usare i virtual host ma ho trovato solo situazioni in cui il server è uno solo. Pol, ciao ! Il server primario ha un indirizzo pubblico ? O è nattato da un firewall ? Il server secondario è sulla LAN e viene esposto alla WAN da un firewall ? Come hai fatto il portforward ? Scusami ma non ho capito esattamente quello che hai fatto... 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/20130514185958.m53...@corep.it
Re: apache virtual host
Pol, ciao ! Ciao Luca: mail letta, ci sto ragionando sù un pò ma la risposta arriverà (e nel frattempo inizio a ringraziarti) :-) Il server primario ha un indirizzo pubblico si dunque: server1: ip pubblico su internet (76.12.67.32) e 192.168.1.1 nella lan server2: 192.168.1.2 iptables -t nat -A PREROUTING -p tcp -i eth0 -d 192.168.1.0 –dport 4080 -j DNAT –to 192.168.1.2:80 iptables -A FORWARD -p tcp -i eth1 -d 192.168.1.0 –dport 4380 -j ACCEPT PS: il server1 ha come interfaccia che va sul router 192.168.1.0 come ip Dall'esterno vorrei accedere ad apache che gira su 192.168.1.2 - ci accedo infatti, ma le richieste (link) tornano all'ip della lan interna. 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/51928c93.1000...@fuckaround.org
Re: apache virtual host
Devi fare l'equivalente di un nat! quindi non ho bisogno dei virtual host? o potrebbe essere fattibile anche tramite quelli? 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/51928d9b.80...@fuckaround.org
Re: apache virtual host
Il 14 maggio 2013 21:12, Pol Hallen debitv...@fuckaround.org ha scritto: PS: il server1 ha come interfaccia che va sul router 192.168.1.0 come ip :o ha due interfacce sulla stessa rete? 192.168.1.0 e 192.168.1.1? e poi... se la subnet mask è 255.255.255.0 gli indirizzi che finiscono per 0 sono la rete stessa, mentre quelli che finiscono per 255 sono il broadcast mi sa che hai qualche problema di indirizzi... -- Gollum1 Tesoro, dov'é il mio teoro... -- 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/cantvqs-kx1+sqrxfdc4d6ewfa1a4wwi_orrgj-kbggilwh6...@mail.gmail.com
Re: apache virtual host
.. Pol, non è bello che un server abbia un indirizzo pubblico ed uno privato sulla LAN, così metti in bypass il firewall della LAN. :( -- 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/20130514192451.m3...@corep.it
Re: apache virtual host
.. Pol, non è bello che un server abbia un indirizzo pubblico ed uno privato sulla LAN, così metti in bypass il firewall della LAN. mhmhmh... eth0 192.168.0.1 -- connessa al router eth1 192.168.1.1 -- connessa alla lan1 devo aver fatto confusione :-/ 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/51929690.8090...@fuckaround.org
Re: apache-ssl
Il giorno lun, 13/05/2013 alle 18.07 +0200, Pol Hallen ha scritto: Ho una domanda che può sembrare banale ma (ancora non ci sono arrivato) :-O ho creato un certificato key e crt e messi come file pem e dato in pasto ad apache-ssl per crittografare la connessione. Funziona tutto bene :-) anche importando il certficato dal browser risulta esserci una chiave a 2048bit (così come ho eseguito da openssl) e tutte le info del certificato. La domanda è: perchè (dal browser) se apro le info di sicurezza della connessione, leggo: connection encrypted: high-grade encryption (aes-256, 256 bit keys)? http://security.stackexchange.com/questions/25375/why-not-use-larger-cipher-keys -- 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/1368462245.2515.16.ca...@zorn.fi.trl
Re: apache-ssl
On 13/05/2013 18:07, Pol Hallen wrote: Ho una domanda che può sembrare banale ma (ancora non ci sono arrivato) :-O ho creato un certificato key e crt e messi come file pem e dato in pasto ad apache-ssl per crittografare la connessione. Funziona tutto bene :-) anche importando il certficato dal browser risulta esserci una chiave a 2048bit (così come ho eseguito da openssl) e tutte le info del certificato. La domanda è: perchè (dal browser) se apro le info di sicurezza della connessione, leggo: connection encrypted: high-grade encryption (aes-256, 256 bit keys)? La chiave del certificato, utilizzata per identificare il sito e passare in modo sicuro la chiave di sessione è a 2048 bit. Il canale fra te ed il browser usa una chiave simmetrica a 256 bit. Visto che l'algoritmo è simmetrico e la chiave usa-e-getta, 256 bit sono più che sufficenti per garantire la sicurezza senza impegnare troppa CPU. federico -- 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/51911151.7020...@dndg.it
Re: apache ssl
se hai timore di un problema di sicurezza locale, oltre apache, come suggerito nella documentazione, la cartella /etc/ssl deve essere leggibile solo e esclusivamente a root e a chi ne deve far uso. grazie per la spiegazione :-) Consiglio: è meglio creare chiavi diverse per ogni servizio (apache, postfix, courier, ecc) o una unica è sufficiente? 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/201305101428.51902.debitv...@fuckaround.org
Re: apache ssl
Il giorno 10/mag/2013, alle ore 14:28, Pol Hallen debitv...@fuckaround.org ha scritto: Consiglio: è meglio creare chiavi diverse per ogni servizio (apache, postfix, courier, ecc) o una unica è sufficiente? bella domanda: non ho una risposta valida universalmente. io ho preferito creare chiavi diverse in base ai servizi, ma e' probabile pure che ci sara' tanta gente che ha generato una sola chiave e ci ha configurato tutto. -- 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/9d72cacc-d698-4f51-9369-dd3f05c04...@majaglug.net
Re: apache ssl
- Da: mauro ma...@majaglug.net A: debian-italian debian-italian@lists.debian.org Cc: Inviato: Venerdì 10 Maggio 2013 14:33 Oggetto: Re: apache ssl Il giorno 10/mag/2013, alle ore 14:28, Pol Hallen debitv...@fuckaround.org ha scritto: Consiglio: è meglio creare chiavi diverse per ogni servizio (apache, postfix, courier, ecc) o una unica è sufficiente? bella domanda: non ho una risposta valida universalmente. io ho preferito creare chiavi diverse in base ai servizi, ma e' probabile pure che ci sara' tanta gente che ha generato una sola chiave e ci ha configurato tutto. Dico una cosa stupida e banale, ma le soluzioni di sicurezza sono SEMPRE e intendo SEMPRE un trade off tra semplicità di gestione e mille altre cose. Se ci fosse una soluzione sicura universale, e non avesse difetti le altre sarebbero già morte e sepolte da un po' :) Purtroppo ogni caso ha bisogno di una customizzazione particolare, per trovare la soluzione migliore per quel caso. Ad esempio, tutti i servizi sono gestiti da te sullo stesso server? Immaginati di dare servizi in gestione ad altre persone, non sarebbe carino dargli la chiave privata, quindi sarebbe meglio generare una chiave per servizio. Averne una sola è però un single point of failure, se la perdi o se te la rubano sei compromesso su tutto il server e tutti i servizi. Ci sono N altre considerazioni da fare, che dipendono dal tipo di sistema che hai in mente o che hai adesso. Di sicuro non c'è una risposta universale Ciao Gianfranco, che spera di non aver confuso ancora di più le cose :) -- 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/9d72cacc-d698-4f51-9369-dd3f05c04...@majaglug.net -- 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/1368189604.43932.yahoomail...@web172701.mail.ir2.yahoo.com
Re: apache ssl
Consiglio: è meglio creare chiavi diverse per ogni servizio (apache, postfix, courier, ecc) o una unica è sufficiente? Io in genere genero una coppia chiave+certificato per ogni servizio. Preferisco tenere separate le cose. 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/1368189701.31708.yahoomail...@web171403.mail.ir2.yahoo.com
Re: apache ssl
[OT] x mauro ti riferivi a questo? - These recipients of your message have been processed by the mail server: ma...@majaglug.net; Failed; 5.5.0 (other or undefined protocol status) Remote MTA net147-109.966.it: SMTP diagnostic: 554 5.7.1 Service unavailable; Client host [85.18.95.65] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?85.18.95.65 quando ho fatto il reply, l'ha fatto anche al tuo indirizzo: ma...@majaglug.net 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/518d3029.8030...@fuckaround.org
Re: apache ssl
Il giorno 10/mag/2013, alle ore 19:36, Pol Hallen debitv...@fuckaround.org ha scritto: using bl.spamcop.net; Esatto Proprio a questo -- 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/10868f47-70e5-4c8d-a0d6-980704087...@majaglug.net
Re: apache ssl
Il giorno 10/mag/2013, alle ore 19:36, Pol Hallen debitv...@fuckaround.org ha scritto: - These recipients of your message have been processed by the mail server: ma...@majaglug.net; Failed; 5.5.0 (other or undefined protocol status) Remote MTA net147-109.966.it: SMTP diagnostic: 554 5.7.1 Service unavailable; Client host [85.18.95.65] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?85.18.95.65 quando ho fatto il reply, l'ha fatto anche al tuo indirizzo: ma...@majaglug.net non e' segno buono... io tuo ip - fastweb, se non sbaglio - e segnalato su tre diverse blacklist tra cui spamcop, l'immancabile sorbs e lashback. saro' strano, ma sti' giorni troppi ip sono segnalati la cosa puzza piu' del dovuto. ennesimo worm spammatore? -- 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/c35e9029-c227-4438-80d0-15c0ede53...@majaglug.net
