Newsgroup: it.comp.www.php
Titolo: Apache2 su Windows e su Debian

Salve a tutti,
ho copiato un sito perfettamente funzionante da Apache2 installato su 
windows su un server con Linux Debian. Sto chiaramente avendo tutta una 
serie di problemi.
Innanzitutto mi da un errore su "mod_deflate.c" che chiaramente su win 
non mi da. Sono andato su google ma non comprendo a cosa sia legato.
Poi ho un sacco di problemi sulle variabili. Ad. esempio se su Win 
dimentico di fare un isset($mia_variabile) e la richiamo direttamente, 
il sistema non mi da errore. Su linux invece mi genera un "error" 
dicendo che l'index non viene trovato. Ma questa è solo una delle 
differenze. Ora io non è che posso modificare tutto il sito a favore di 
quel SO o l'altro, ma suppongo che andando nelle configurazioni di uno o 
l'altro ci sia un modo per bypassare sti casini. Altrimenti ditemi dove 
conviene sviluppare e ci faccio un pensiero.
Grazie!!!

 conviene sviluppare e ci faccio un pensiero.
Probabilmente hai sviluppato con un configurazione abbastanza "lassista" 
di php.ini.
Come tampone puoi replicare sul server Debian il php.ini che hai sul 
server Windows (non copiarlo di sana pianta, perche` i path ai modulo 
sono diversi. Analizza le differenze e replicale).
Poi ti tieni in locale il php.ini che c'e` attualmente sul server Debian, 
con la config piu` stretta su warning e errors, e cerchi di sistemare il 
sito.
Questo perche` i warning di oggi saranno errori domani quando aggiornerai 
PHP a versioni piu` nuove.
Bye.

incolla queste 3 righe all'inizio del file principale del sito e
testalo sul server windows:
error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);
dovrebbe darti gli stessi errori che hai su debian.
Per quel che riguarda il modulo di apache, quoto pellizzari, ma per la
cronaca prova anche a dare solo il comando 'a2enmod' e premi invio; ti
verranno mostrati tutti i moduli disponibili su apache2, se quello che
ti serve non è presente devi scaricarlo.

[CUT]
Siete partiti entrambi prevenuti. Non è detto che chi fa queste cose sia 
cosciente di avere lavorato su configurazioni "lassiste". Il Web-Server 
su Win non l'ho configurato io. Ho preso solo 10 mb di spazio per 
programmare. Se mi generava errore lo correggevo ma poi pensavo che 
stessi sviluppando compatibilmente con gli standard. Ora che mi sono 
fatto un web-server su un PC muletto con Linux-Debian mi sono accorto 
dei problemi. Credo che potete immaginare quanto mi scoccia la 
situazione visto che passavano cose che a rivederle tempo dopo anche io 
mi stupisco. Faccio i test che mi dite Voi.
Comunque Vi ringrazio per le delucidazioni e l'aiuto!

 cosciente di avere lavorato su configurazioni "lassiste".
Infatti non ti davo la colpa di questo, ma volevo portarti a conoscenza 
che ci sono dei parametri nel php.ini che possono essere impostati in 
modo "rilassato" in in modo "stretto".
Ad ogni versione di PHP alcuni di questi parametri vengono deprecati o 
tolti, e si tende sempre piu` alla versione "stretta".
Chi ha configurato quel server Windows probabilmente li ha lasciati cosi` 
per evitarsi le rogne degli utenti "non funziona, il vostro servizio fa 
schifo", che tanto con quella versione erano solo warning.
Avra` una brutta sorpresa quando mettera` PHP 5.3 o il futuro 6.x. :)
Per lo sviluppo ti consiglio un ambiente di test (anche lo stesso PC dove 
sviluppi) dove imposterai il php.ini con i parametri che ti ha dato 
DaNieL, con l'aggiunta che l'error reporting io lo imposto a
E_ALL|E_STRICT
In questo modo vedi subito gli errori durante lo sviluppo.
Bye.

 In questo modo vedi subito gli errori durante lo sviluppo.
Su questo muletto ci lavoro solo io e posso configurare il sito al 
meglio. Metterò nel php.ini il reporting come me lo hai dato tu.
Una cosa... siccome io uso su windows collegarmi in rete alla cartella e 
uso NetBeans IDE 6.8 con estensione PHP 5.3 per programmare con linkato 
TUTTO il progetto, su linux come posso fare la medesima cosa? Mi sa che 
se non installo samba non ho chance vero? Vorrei sviluppare direttamente 
sul webserver ma non mi va di mettere la grafica, vorrei farlo da 
remoto. Per il momento ho installato proftpd che funziona bene ma è un 
FTP e a ogni modifica devo uppare la pagina che è uno stress.
Grazie!

 FTP e a ogni modifica devo uppare la pagina che è uno stress.
Ti posso dire come faccio io.
Ho in locale un webserver completo (apache, php 5.3, mysql 5.qualcosa, 
postgres 8.4). Ho configurato apache per vedere come virtualhost la 
cartella dei progetti di Eclipse (puoi farlo anche con Netbeans).
Spesso, appena finisco una micro-parte del sito in pratica, committo in 
CVS tutto il sito.
Il CVS fa un auto-update (o un deploy, se preferisci la parola) sul 
server di test, che e` una copia piu` simile possibile al server di 
produzione (che ha ancora php 5.2 e postgres 8.3).
Quando il sito e` pronto e testato sul server di test, lo pubblico in 
produzione, a rischio quasi zero (lo zero non esiste... :) )
Puo` sembrare una rogna tenere aggiornati tre server, ma con Debian lo e` 
meno di quanto si pensi, basta fare un aptitude update && aptitude upgrade 
ogni tanto. :)
E cosi` ho la possiblita` di testare in locale cose un po' stravaganti 
(per esempio ricompilare php-ffmpeg, un paio di anni fa, o fileinfo un 
paio di giorni fa) senza rischiare di rompere il server di test o quello 
di produzione.
Bye.

 programmare.
Ma che preventuti, io parlo per esperienza, ho fatto prima di te lo
stesso errore di testare lavori su un server diverso da quello di
produzione e dover modificare funzioni all'ultimo.
Sul server di produzione è "normale" nascondere i warning, poi c'è chi
lo ignora proprio, chi li salva da qualche parte per il debugging.

[CUT]
Ma quindi io potrei fare una cosa... mi configuro il muletto con Windows 
così mi collego facile e su php.ini metto le regole ristrette come ci 
siamo detti.
Poi sulla macchina in produzione metto le medesime regole ma sto su linux
In questa maniera non dovrei trovarmi con sorprese varie. Giusto?


Eh no, se non vuoi trovarti sorprese (che probabilmente troverai
comunque, ma le riduci del 99%) devi lavorare e fare i test su una
macchina che sia identica a quella di produzione (sistema operativo
sopprattutto, ma anche moduli installati, configurazione del php,
configurazione di apache, versione del database, etc..)
Se il tuo server di produzione usa windows, fai i test su windows.

> Se il tuo server di produzione usa windows, fai i test su windows.
Innanzitutto la macchina che sarà in produzione è una VM su VMWare. Lo 
dico perchè la scelta del Web-Server è molto collegata a questa cosa. Se 
installassi windows dovrei, oltre ad utilizzare una licenza MS che mi 
servirebbe per altro, stanziare almeno 2 GB per una macchina che 
praticamente sfrutta 100Mhz a pieno carico e si e no 1 GB di Ram. Con 
Linux, che occupa sicuramente meno risorse per fare le stesse cose, 
questo problema del repporto prestazioni/potenza viene a ridursi. 
Inoltre, se avessi dovuto avere Apache2+PHP e il DB sullo stesso server, 
avrei potuto fare qualche pensiero a Win. Ma il DB sta altrove e solo il 
webserver mi pare proprio uno spreco.
Il problema di questa soluzione è lo sviluppo. Io in azienda non ho 
computer con Linux e neanche posso installare e lavorare su linux 
passando a scelta tra un SO e un altro. Ma anche bypassando il problema 
del doppio SO, dovrei installare il desktop sul webserver di test e, 
quando gli script funzionano, spostarle su uno in produzione.
Pertanto ammesso che io verifichi che le configurazioni di apache2 e 
php5.3 siano identiche tra linux e windows, dici che proprio rischio tanto?
Grazie ancora.

 identiche tra linux e windows, dici che proprio rischio tanto?
In generale, sì.
Poi se il tuo sito è fatto solo di if,while,for,echo magari funziona su 
entrambi.
Ma esistono diverse funzioni/classi php che su linux  funzionano e su 
windows no, e viceversa.
Per non parlare dell'accesso fisico al disco, file system diversi con 
nomenclature diverse.


Nessuno ti vieta di installarti linux in dual boot, o su una macchina
virtuale dentro il tuo pc e usarlo come macchina di sviluppo.
Le prestazioni non saranno il massimo, ma per un webserver dovrebbero
andare bene.

 andare bene.
Visto che mi sembri pratico... che desktop è "migliore" per sviluppare?

 Visto che mi sembri pratico... che desktop è "migliore" per sviluppare?
Se non hai mai usato linux, credo ubuntu sia il meglio per iniziare.
Ma la risposta alla tua domanda è la stessa di un'altra domanda: La
macchina virtuale che ospiterà il server web di produzione, che distro
avrà?
Debian lenny?
Allora installati debian lenny: se metti su ubuntu (ad esempio), è
vero che la struttura è quasi identica, ma i pacchetti no.
Ubuntu di default ti installa php 5.3.2, debian lenny mi sembra sia
rimasta alla 5.2.6.
Debian fà della stabilità la sua bandiera, le ultime versioni dei
software devono passare un sacco di test prima di entrare nelal
versione stabile (lenny attualmente).
Cmq io con virtualbox ci ho messo un attimo a crearmi una macchina
virtuale con su debian per fare dei test, installare php+apache+mysql
è un comando e trovi milioni di guide a riguardo

 Visto che mi sembri pratico... che desktop è "migliore" per sviluppare?
Puoi tenere l'ambiente che preferisci per sviluppare e usare la macchina 
virtuale per il solo server HTTP.

 Debian lenny?
No veramente uso la testing perchè installa php 5.3 ... Questa versione 
di php è piuttosto importante. Tanto per ora che il sito è finito la 
testing sarà stable :D E poi, come accennavi tu, la stabilità è una 
priorità su debian, la testing è già una versione piuttosto "stabile" e 
poi i pacchetti che installo sono cmq di terze parti e già piuttosto 
testati.

 pacchetto virtuale con programmi per sviluppatori web :(
Cosa intendi per effetti? Gnome non fa nessun effetto. Al massimo ti fa 
le ombre alle finestre, ma devi attivarle in gconf.
A meno che non installi gnome-shell (che e` praticamente la beta di Gnome 
3)
 
Non ha molto senso un "meta-pacchetto per sviluppatori web", vista la 
quantita` di linguaggi, editor, DB, webserver e browser disponibili. :)
Bye.

 Bye.
Ma mi sembra che ci fosse in giro un pacchetto predisposto per il php,
che in automatico installava php, apache e mysql.. ma non vorrei dire
castronerie.
Cmq a installare e configurare l'ambiente di sviluppo 'default' per il
php ci si mette davvero 10 minuti

 php ci si mette davvero 10 minuti
aptitude install apache2 php5 mysql postgresql eclipse-pdt
Anche meno di 10 minuti, se togli i tempi di download. :)
Bye.


ti sei mica dimenticato di xdebug? ;P

 ti sei mica dimenticato di xdebug? ;P
Ma sai che non l'ho mai usato? :D
Pero` mi hai messo la pulce nell'orecchio e lo sto installando per vedere 
come funziona.
Bye.

 come funziona.
php5-xdebug 2.0.5 php net devel  php5 extension for php debugging
quasi quasi gli do un port install.


non fà miracoli, ma è molto comodo (la stack trace è molto utile in
certi casi)
Poi si integra con netbeans

 Poi si integra con netbeans
Scusate la domanda banale...questi editor si possono usare solo sui vari 
desktop. Senza desktop un editor serio per script php non c'è a parte 
nano e vim?

 nano e vim?
Qualche purista potrebbe ucciderti per aver confrontato nano e vim. :)
Dipende cosa intendi per editor serio. In console i due piu` potenti sono 
vim e emacs, e qui va a gusti.
Io in console uso joe solo per gli interventi di emergenza (cambiare una 
riga di config o correggere un punto e virgola sballato). Per qualsiasi 
cosa che prenda piu` di una riga uso un editor grafico (di solito eclipse, 
ma se sono ontheroad con l'Eee uso gedit o geany).
Bye.

 nomenclature diverse.
Questo si aggira facilmente usando le costanti e le funzioni messe a 
disposizione da PHP stesso per ricavare i path e il separatore di 
directory.
Comunque scrivendo i path col separatore Unix (/) PHP e` abbastanza 
intelligente da farlo funzionare anche su Windows (che usa \), o almeno 
lo era fino alla 4. Sulla 5 non ho mai provato. :)
Bye.

 directory.
Costanti valide solo se si opera strettamente all'interno della rootdir, 
ma se ad esempio si vuol tenere fuori il file delle pwd dall'albero 
accessibile da web, la cosa diventa un problema.
Insomma, ribadisco, magari funziona, ma in generale no.
Quindi perchè volersi del male e continuare su quella strada?
Scoraggia Pellizzari, scoraggia!

 Scoraggia Pellizzari, scoraggia!
Certo che lo scoraggio: l'ambiente di sviluppo dovrebbe essere piu` 
simile possibile a quello di produzione e a quello di test.
Pero` se non ha alcun modo di mettere Linux sui PC aziendali, non 
buttiamolo proprio giu`. :)
Deve solo fare MOLTA attenzione a come sviluppa, e possibilmente avere il 
server di test identico a quello di produzione, anche solo in una VM.
Ma se fossi in lui analizzerei con il capo o il reparto IT perche` non 
puo` avere una macchina Linux per sviluppare, se ci si trova bene.
Bye.