To top

Tecnologie Web - A.A. 2011-2012 (istruzioni brevi)

Sotto qualche informazione utile; alcune informazioni dell'ultima ora potrebbero trovarsi solo sulla home page del server.

Uso del server

Layout dei file

La configurazione in cui gli URL degli script cgi sono "montati" sopra gli URL delle pagine senza che cgi-bin sia una sottocartella di public_html è analoga a quella che si ha in molti server.
Come i path diventano URL (configurazione di default di molti server; bisogna essere root o l'utente www-data)
  PATH (runtime degli script) URL
Contenuto statico /var/www/pagina.html http://server/pagina.html
Script /usr/lib/cgi-bin/script.cgi http://server/cgi-bin/script.cgi
Come i path degli utenti del server tecnologie-web.studenti.math.unipd.it diventano URL
  PATH (runtime degli script) URL
Contenuto statico ~nomeutente/tecweb/public_html/pagina.html http://tecnologie-web.studenti.math.unipd.it/tecweb/~nomeutente/pagina.html
Script ~nomeutente/tecweb/cgi-bin/script.cgi http://tecnologie-web.studenti.math.unipd.it/tecweb/~nomeutente/cgi-bin/script.cgi
  • il server da usare è tecnologie-web.studenti.math.unipd.it
  • dentro tale server, le cartelle da usare sono:
    • ~/tecweb/public_html/ per il contenuto statico (pagine html, fogli di stile, file js)
    • ~/tecweb/cgi-bin/ per gli script cgi (notare l'assenza di public_html)
  • il sito personale sarà raggiungibile dall'indirizzo http://tecnologie-web.studenti.math.unipd.it/tecweb/~nomeutente/ (notare tecweb)
  • fare ben attenzione alla differenza fra URL e path; due esempi in particolare:
    • quello di una pagina statica al primo livello di public_html che voglia linkare uno script al primo livello di cgi-bin; in quanto cgi-bin viene montata su public_html, il link relativo dalla pagina statica allo script è cgi-bin/script.cgi
    • quello di uno script al primo livello di cgi-bin che voglia modificare il file di una pagina statica al primo livello di public_html; in quanto lo script viene eseguito con working directory ~utente/tecweb/cgi-bin/ il path relativo verso il file della pagina statica è ../public_html/pagina.html
Esempi di percorsi e path relativi
File che linka o modifica
~utente/tecweb/public_html/a.html ~utente/tecweb/public_html/d.html
(anche se generato da
~utente/tecweb/cgi-bin/script.pl)
~utente/tecweb/cgi-bin/script.pl
(standard output)
~utente/tecweb/cgi-bin/script.pl
(funzioni che operano sui file)
File da linkare o modificare
~utente/tecweb/public_html/b.html <a href="b.html"></a> <a href="../b.html"></a> open(my $handler,">","../public_html/b.html")
~utente/tecweb/public_html/css/c.css <a href="css/c.css"></a> <a href="../css/c.css"></a> open(my $handler,">","../public_html/css/c.css")
~utente/tecweb/cgi-bi/s.cgi <a href="cgi-bin/s.cgi"></a> <a href="s.cgi"></a> open(my $handler,">","s.cgi")
~utente/tecweb/data/file.xml
(ad esempio il database delle password)
NON RAGGIUNGIBILE open(my $handler,">","../data/file.xml")

Esempi (senza tunnel)

Gli esempi sotto servono ad esplicare il layout dei file e prevedono che l'utente stia usando un computer dei laboratori o la rete Wi-Fi del Dipartimento (o altre reti da cui sia possibile collegarsi direttamente al server dei corsi).

Esempio di trasferimento dei file (senza tunnel)

Ancora, in conseguenza della separazione fra la cartella public_html e cgi-bin, dalle macchine dell'aula (nell'esempio sotto se si sono messi i propri file nella cartella xTecWeb) andranno dati due distinti comandi per il traferimento dei file:
  • scp -p -r xTecWeb/public_html nomeutente@tecnologie-web.studenti.math.unipd.it:tecweb
    scp -p -r xTecWeb/cgi-bin     nomeutente@tecnologie-web.studenti.math.unipd.it:tecweb
Come detto nelle note estese (vedi), notare l'opzione -p utile a preservare i permessi (è conveniente settarli una volta per tutte sul computer di partenza piuttosto che tutte le volte sul server di arrivo). Nella cartella degli script potrebbe inoltre essere il caso di dare il comando fromdos *

Esempio di correzione del formato dei file (senza tunnel)

  • ssh tecnologie-web fromdos ~/tecweb/cgi-bin/*

Esempio di correzione dei permessi (senza tunnel)

  • ssh tecnologie-web chmod -R 750 ~/tecweb/cgi-bin/*
    (notare la -R maiuscola)

Esempi (coi tunnel)

Agendo via tunnel bisognerà cambiare nei seguenti modi le righe di comando mostrate:

  • mettere sempre nomeutente@localhost invece di nomeutente@tecnologie-web.studenti.math.unipd.it
  • indicare la porta con sftp, ad esempio scp -P 30022 al posto di scp
  • indicare la porta con ssh, ad esempio ssh -p 30022 al posto di ssh
  • indicare la porta con rsync, ad esempio rsync -e 'ssh -p 30022' al posto di rsync

Esempio di preparazione del tunnel

  1. comandi da dare in una prima finestra locale: va dato almeno un comando dei comandi seguenti; per trovare una porta locale libera, ad esempio 30080 e 30022, tali porte non debbono apparire in elenco:
    netstat -tan | grep LISTEN | grep -v tcp6
    fuser -4 30022/tcp
    fuser -4 30080/tcp
    lsof -i :30022
    lsof -i :30080
    
  2. comandi da dare in una prima finestra locale, la vera preparazione del tunnel:
    ssh  -L30080:tecnologie-web.studenti.math.unipd.it:80 -L30022:tecnologie-web.studenti.math.unipd.it:22 nomeutente@paolotti.studenti.math.unipd.it
  3. comandi da dare in una seconda finestra, anche essi al prompt della macchina locale: quelli del paragrafo sotto
Se si hanno dubbi o problemi vedere le note estese.

Dopo il tunnel

  • In conseguenza della porta locale aperta dal tunnel, dalla macchina locale si potrà aprire la home del sito del Corso di Tecnologie Web dall'indirizzo http://localhost:30080/
  • le pagine personali dei singoli utenti, relative all'URL del sito come lo si può aprire grazie tunnel, avranno quindi la forma
    http://localhost:30080/tecweb/~nomeutente/
  • In conseguenza della porta locale aperta dal tunnel, dalla macchina locale si potrà fare scp come qui:
    scp           -P 30022   -r -p xTecWeb/public_html nomeutente@localhost:tecweb
    scp           -P 30022   -r -p xTecWeb/cgi-bin     nomeutente@localhost:tecweb
    (notare la -p minuscola di ssh e la -P maiuscola di scp)
  • In conseguenza della porta locale aperta dal tunnel, dalla macchina locale si potrà fare rsync come qui:
    rsync -e "ssh -p 30022 " -avrP xTecWeb/public_html nomeutente@localhost:tecweb
    rsync -e "ssh -p 30022 " -avrP xTecWeb/cgi-bin     nomeutente@localhost:tecweb
    (notare che la -a minuscola di rsync e preserva i permessi dei file e che non verranno cancellati file presenti solo nella cartella di origine come sarebbe con --delete)
  • In conseguenza della porta locale aperta dal tunnel, dalla macchina locale si potrà fare ssh come qui:
    ssh -p 30022 nomeutente@localhost
    (notare la -p minuscola)

XSV

Nei laboratori del Paolotti, dai pc con Windows:
  1. aprire un “Prompt dei comandi”
  2. quindi dare il comando
    C:\Programmi\XSV\xsv.exe
con i giusti parametri come da relativa pagina web

To top

Tecnologie Web - A.A. 2011-2012 (istruzioni lunghe)

Esempio di collegamento mediante OpenSSH dal terminale di una macchina Linux o MacOS X o Cygwin al server del corso tecnologie-web - A.A. 2011-12

Cercare nelle altre sezioni del sito quando il caso:
  • istruzioni sull'uso di ssh: generalità
  • istruzioni sull'uso di ssh: trasferimento file (differenza fra file locali e remoti, FileZilla, etc.)
  • istruzioni sull'uso di ssh: Linux
  • istruzioni sull'uso di ssh: esempio di collegamento da Windows (impostare ed usare i tunnel con un'iterfaccia grafica) - i percorsi sono purtroppo quelli di qualche anno fa...
Soprattutto dare la precedenza al sito del corso e al docente, in particolare per le domande che non riguardano l'attuale configurazione del server.
  1. Aprire una prima shell su una macchina raggiungibile da casa e che per le impostazioni del firewall possa raggiungere il server del corso: anche se in foreground, la prima shell ssh da al più la possibilità di collegarsi ai server interni come se si fosse in aula (vedi nota). Aggiungendo l'opzione -f ssh va addirittura in backgroud dopo aver chiesto la password, così da avere solo i tunnel ma nessun prompt dei comandi. Partire dalla shell del proprio pc (ad esempio, di casa):
    • Visto che il server sta al Paolotti, connettersi a ssh.studenti.math.unipd.it e contemporaneamente impostare i due tunnel necessari (uno per ogni opzione -L):
      ssh -L30080:tecnologie-web:80 -L30022:tecnologie-web:22 nomeutente@ssh.studenti.math.unipd.it
    • Altrimenti collegarsi a sshtorre.math.unipd.it e contemporaneamente impostare i due tunnel necessari (uno per ogni opzione -L) usando il FQDN in quanto la Torre e il Paolotti hanno sottodomini differenti:
      ssh -L30080:tecnologie-web.studenti.math.unipd.it:80 -L30022:tecnologie-web.studenti.math.unipd.it:22 nomeutente@sshtorre.math.unipd.it
    Il tunnel viene sfruttato a pieno nei passi successivi a questo.
  2. se si vuole fare direttamente l'upload sul server tecnologie-web dei file di una cartella locale (-r serve appunto per un copia ricorsiva), ad esempio xTecWeb, nel proprio computer (ad esempio quello di casa) va lanciato un ulteriore processo scp (-P MAIUSCOLA):
    scp -P 30022 -r xTecWeb/public_html/* nomeutente@localhost:tecweb/public_html
    scp -P 30022 -r xTecWeb/cgi-bin/*     nomeutente@localhost:tecweb/cgi-bin
  3. se si vogliono dare comandi direttamente dentro tecnologie-web è necessario aprire un'altra shell lanciando verso il server del corso un secondo comando ssh (-p minuscola):
    ssh -p 30022 nomeutente@localhost
  4. Si possono controllare le modifiche dal browser (anche da Firefox):
    lynx http://localhost:30080/tecweb/~nomeutente/

Note all'uso del tunnel per collegarsi al server del corso tecnologie-web

  • Da un computer dell'aula (incluso ssh.studenti.math.unipd.it) o della Torre Archimede (incluso sshtorre.math.unipd.it) o della rete Wi-Fi degli studenti non é necessario stabilire alcun tunnel: a seconda di quello che si vuole ottenere é sufficiente usare il nome del server e la porta di default cioé:
    • per trasferire i file:
      scp -r xTecWeb/public_html/* nomeutente@tecnologie-web.studenti.math.unipd.it:tecweb/public_html
      scp -r xTecWeb/cgi-bin/*     nomeutente@tecnologie-web.studenti.math.unipd.it:tecweb/cgi-bin
    • per avere una shell:
      ssh nomeutente@tecnologie-web.studenti.math.unipd.it
      Sotto alcune particolari condizioni si potrebbe usare una shell dentro tecnologie-web per trasferire i file nella direzione opposta (dal server tecnologie-web ad computer dell'aula o di casa): vedere qui se curiosi.
    • collegarsi con un browser a http://tecnologie-web.studenti.math.unipd.it/tecweb/~nomeutente/.
  • Viceversa quando collegati in ssh da casa con un tunnel:
    • per trasferire file o per dare comandi da shell é necessario rispettivamente un ulteriore comando scp e/o un secondo comando ssh (quelli dei punti 2 e 3 che vannno dati nel computer di casa). Se si é abituati ad usare un programma con interfaccia grafica per il trasferimento dei file è solo da qui che si procede come al solito (pur di scegliere come server host localhost e le porte reindirizzate, ad esempio 30022)
    • l'indirizzo da controllare é proprio http://localhost:30080/tecweb/~nomeutente/

Note alla configurazione del server del corso tecnologie-web

Configurazione delle pagine statiche
  • Tutte le pagine devono essere leggibili all'utente www-data cioè nella configurazione attuale almeno dal gruppo iniziale dell'utente; ciò implica anche che tutte le cartelle debbano avere almeno il permesso di accesso. Nel caso si siano fatte modifiche al layout del file system come preparato per il corso si può lanciare:
    find ~/tecweb/public_html/ -type f -exec chmod u=rwX,g=r,o= '{}' \;
    find ~/tecweb/public_html/ -type d -exec chmod u=rwx,g=x,o= '{}' \;
    dove il comando -exec di find chiede proprio di essere terminato dal punto e virgola che è preservato dalla shell mediante quoting come pure '{}' è il parametro che prende il nome dei file/cartelle trovate e ed è preservato dalla shell con le virgolette singole.
    Una versione più compatta che nella maggior parte dei casi da lo stesso risultato dei due find è: chmod -R u=rwX,g=rX ~/tecweb/public_html (attenzione: lettera X maiuscola, altrimenti si rendono eseguibili anche i regular file, cosa inutile o dannosa; ad accettare il rischio u=rwx,g=rx la scrittura diventa equivalmente al compattissimo chmod -R 750 ~/tecweb/public_html).
    Per la precisione i comandi del primo esempio danno tutti i permessi all'utente proprietario (quello di esecuzione solo se il file è eseguibile) e per il resto la sola lettura dei file in qualunque directory siano, solo al suo gruppo iniziale: nessun permesso agli altri. Nel secondo esempio invece una eventuale cartella in cui il proprietario non potesse entrare, rimarrebbe inaccessibile a tutti: lui incluso. Notare che non ci sono spazi prima e dopo le virgole nella stringa dei permessi di chmod.
  • ANCHE SUL SERVER DEL CORSO GLI STUDENTI HANNO UNA QUOTA DISCO LIMITATA (ATTUALMENTE 100MB). Nel caso fossero le immagini la causa dello sforamento potrebbe essere il caso di ridurne la qualità, ad esempio con ImageMagick
    for f in ../Pietra/* ; do         cmd="convert -scale 25% $f $(basename $f)" ; echo $cmd ;  $cmd ;               done
    
Configurazione degli script
  1. L'utente www-data è membro del gruppo iniziale di ogni utente (quindi non serve dare permessi di accesso o lettura a tutti); è comunque una buona prassi tenere i file di appoggio esterni al percorso accessibile agli utenti Internet (ad esempio in una cartella con un nome scelto a caso dentro ~tecweb/data); a meno di script bacati quello che è fuori da ~tecweb/public_html non è infatti scaricabile con un browser.
    (export random=$RANDOM ; mkdir -p ~/data/$random ; chmod go= ~/data/$random)
  2. Tutti i cgi (con l'eventuale eccezione dei php inline, al momento disabilitati) devono risiedere in ~/tecweb/cgi-bin o in eventuali sue sottodirectory: non a caso è impedito all'interno degli eventuali file .htaccess l'uso di Options +ExecCGI.
    Altrettanto una funzionalità voluta che non si possa controllare da web il contenuto della cartella ~/tecweb/cgi-bin e delle sue sotocartelle; se proprio si desidera mostrare il sorgente dei propri script ai navigatori provare con
    ln -s ~/tecweb/cgi-bin ~/tecweb/public_html/src
    ed assumersi la responsabilità della minor sicurezza conseguente all'esposizione dei bachi (soprattutto in assenza di una partecipazione della comunità alla correzione degli stessi potrebbe essere opportuna un po' di Security through obscurity).
  3. Al momento le uniche estensioni ammesse per essere eseguite come cgi sono .pl e .cgi (ragionevole anche per eventuali eseguibili compilati). File di altra estensione (come i .html) potrebbero venire mostrati agli eventuali utenti Internet pur se lasciati in ~/tecweb/cgi-bin/. Altrettanto link (a livello di file sytem) con diversa estensione agli script cgi-bin.
  4. Tutti i cgi (con l'eventuale eccezione dei php inline, al momento disabilitati) devono essere eseguibili dall'utente proprietario e almeno leggibili dall'utente www-data (cioè nella configurazione attuale dal gruppo iniziale dell'utente); nel caso si siano fatte modifiche al layout del file system come preparato per il corso si può lanciare:
    find ~/tecweb/cgi-bin/ ~/tecweb/public_html/ -type d -exec chmod u+x,g+X,o= '{}' \;
    find ~/tecweb/cgi-bin/ -name '*.pl' -or -name '*.cgi' -exec chmod u+x,g=r,o= '{}' \;
    dove il comando -exec di find chiede proprio di essere terminato dal punto e virgola che è preservato dalla shell mediante quoting come pure '{}' è il parametro che prende il nome dei file/cartelle trovate e ed è preservato dalla shell con le virgolette singole.
  5. I cgi del punto precedente e la cartelle che li contengono a partire da cgi-bin stessa, soprattutto se lanciati da mod_suexec come al momento avviene, debbono essere modificabili solo dal proprietario, quindi né dal gruppo iniziale dell'utente né da other; i permessi di scrittura possono essere tolti coi comandi precedenti o anche solo con:
    chmod -R g-w,o-w ~/tecweb/cgi-bin/
    Nel caso mod_suexec non fosse abilitato e gli script girassero tutti come www-data, comunque non sarebbe necessario o desiderabile che altri utenti li potessero modificare: normalmente basterebbe fossero modificabili i file di appoggio come mostrato all'inizio del punto 1: evitare di seguire istruzioni per altri server web meno sicuri ovvero niente CHMOD 777.
    Altrettanto non è normalmente desiderabile che i propri script siano setuid o segid (altri utenti potrebbero sfruttare i bachi dell'eseguibile): di conseguenza mod_suexec si rifiuta di eseguire script con permessi speciali superiori a 1000 (sticky bit) e potrebbe servire il secondo comando di questo punto per togliere i permessi 4000 (u=s) e 2000 (g=s):
    find ~/public_html/cgi-bin/ -type f -exec chmod u-s,g-s,-t '{}' \;
  6. Ci sono altri controlli fatti da mod_suexec prima di eseguire lo script: ad esempio che il file venga lanciato dalla cartella definita (nella attuale configurazione ~/tecweb/cgi-bin/) e che il cgi appartenga all'utente e al relativo gruppo iniziale sotto il quale è richiesta l'esecuzione (evitare chown/chgrp anche fra i propri gruppi).
  7. Attenzione alla differenza fra perl ./index.pl e ./index.pl: lo script deve essere eseguibile in sè e non solo come parametro del suo interprete. Testare quindi ./index.pl scrivendo solo ./index.pl e dare il comando chmod +x ./index.pl nel caso si avesse un messaggio d'errore come “bash: ./index.pl: Permission denied”; ovviamente al posto di ./index.pl ci può essere un qualsiasi script.
  8. Tutti gli script cgi-bin sono eseguiti da una shell di linux, quindi se iniziano con il tradizionale commento per indicare un interprete, il path deve essere corretto e le opzioni quelle volute. Capita che scrivendo il file di script su un altro sistema operativo (e non si dice all'editor di salvare in formato UNIX) al nome dell'interprete, apparentemente corretto, rimanga “attaccato” un carattere di fine riga scorretto (quindi l'interprete non viene trovato e apparare un messaggio come “perl^M: bad interpreter: No such file or directory” da shell, il solito “Internal Server Error” da browser): nel caso il file di testo dello script può essere pulito, ad esempio con un comando fra quelli sotto:
    for file in *.pl *.cgi ; do tr -d '\r' $file > $file.exdos ; mv $file.exdos $file ; done
    for file in *.pl *.cgi ; do fromdos $file ; done
    for file in *.pl *.cgi ; do tr '\r' '\n' $file > $file.exmac ; mv $file.exmac $file ; done
    A titolo esemplificativo come non deve e come deve apparire uno script:
    cat bad-interpreter.pl | hexdump -C 
    00000000  23 21 2f 75 73 72 2f 62  69 6e 2f 70 65 72 6c 0d  |#!/usr/bin/perl.|
    00000010  0a 0d 0a 0d 0a 23 6d 65  67 6c 69 6f 20 61 67 67  |.....#meglio agg|
    00000020  69 75 6e 67 65 72 65 20  2d 77 20 63 6f 6d 65 20  |iungere -w come |
    
    cat bad-interpreter.pl | fromdos | hexdump -C 
    00000000  23 21 2f 75 73 72 2f 62  69 6e 2f 70 65 72 6c 0a  |#!/usr/bin/perl.|
    00000010  0a 0a 23 6d 65 67 6c 69  6f 20 61 67 67 69 75 6e  |..#meglio aggiun|
    00000020  67 65 72 65 20 2d 77 20  63 6f 6d 65 20 6f 70 7a  |gere -w come opz|
    
    Nel riconoscere i caratteri di carriage return che vanno tolti l'output di od -xa potrebbe essere anche più chiaro di quello di hexdump -C (nella trascrizione dello script che da errore cercare cr anzichè 0d):
    cat bad-interpreter.pl | od -xa
    000000    2123    752f    7273    622f    6e69    702f    7265    0d6c
              #   !   /   u   s   r   /   b   i   n   /   p   e   r   l  cr
    0000020    0d0a    0d0a    230a    656d    6c67    6f69    6120    6767
             nl  cr  nl  cr  nl   #   m   e   g   l   i   o  sp   a   g   g
    0000040    7569    676e    7265    2065    772d    6320    6d6f    2065
              i   u   n   g   e   r   e  sp   -   w  sp   c   o   m   e  sp
    
    cat bad-interpreter.pl | fromdos | od -xa
    0000000    2123    752f    7273    622f    6e69    702f    7265    0a6c
              #   !   /   u   s   r   /   b   i   n   /   p   e   r   l  nl
    0000020    0a0a    6d23    6765    696c    206f    6761    6967    6e75
             nl  nl   #   m   e   g   l   i   o  sp   a   g   g   i   u   n
    0000040    6567    6572    2d20    2077    6f63    656d    6f20    7a70
              g   e   r   e  sp   -   w  sp   c   o   m   e  sp   o   p   z
    
    Nel caso dell'interprete Perl il problema con perl^M può inoltre essere aggirato mettendo un'opzione come in perl -w: il nome dell'eseguibile finirà prima dello spazio (e non fa male avere qualche warning in più).
  9. La riga dello shebang deve comunque essere la prima: non basta sia la prima non vuota. Fatto questo, col meccanismo della shebang line può essere chiamato un qualsiasi interprete, non solo bash o perl: ad esempio, /usr/bin/php.
    Ovviamente usare un intreprete diverso da quello richiesto dal docente potrebbe essere vietato dalle regole del corso. È inoltre possibile testare, almeno parzialmente, le stringhe POST preparandole a mano e fornendole allo script come in questo esempio: cat stringa_post_da_preparare.txt | ./index.pl
  10. Con le attenzioni precedenti i file dovrebbero riuscire eseguibili anche da una shell interattiva; si consiglia di fare questa prova almeno per avere informazioni dai vari interpreti su eventuali errori di sintassi. In presenza di errori di sintassi lo script potrebbe non essere eseguito e il server restituire la pagina “Internal server error”. Si badi che un test con esito positivo da shell interattiva non assicura di avere uno script eseguibile correttamente dal server web: la pagina “Internal server error” può ad esempio essere restituita dal server anche quando gli script non sono leggibili a www-data o mancano gli header http.
  11. Sembra che alcuni script eseguibili da shell presentino comunque dei problemi (Internal Server Error se fatti partire da Apache) legati al Byte Order Mark (BOM) inserito dall'editor usato. Citando Wikia:
    This BOM is the codepoint U+FEFF, which is represented on disk as follows:
    • UTF-8: EF BB BF
    • UTF-16be: FE FF
    • UTF-16le: FF FE
    • UTF-32be: 00 00 FE FF
    • UTF-32le: FF FE 00 00
    Un modo veloce per eliminarli è usare perl a riga di comando:
    cp nomescript.pl nomescript.pl.tmp;
    perl -CD -pe 'tr/\x{feff}//d'  nomescript.pl.tmp > nomescript.pl ; 
    rm  nomescript.pl.tmp
    Oppure:
    vi nomescript.pl
    :set nobomb
    :wq
    
    Vari altri editor permettono di salvare con o senza la signature utf-8 (BOM); ad esempio anche Notepad++ per Windows. Qui degli screenshot: Notepad++ - scegliere Convert to UFT withoout BOM dal menu Encoding Notepad++ -  nel menu Preferences, scheda New Document/Default Directory sceglier UNIX come Format e UTF-* whitout BOM come Encoding
  12. Lo script deve comportarsi come un script cgi ovvero produrre l'output previsto: non solo il testo in sé ma anche il corrretto header HTTP. Ciò può avvenire direttamente con un print o attraverso le funzioni dei vari package usati. Ad esempio:
    #!/usr/bin/perl -w
    use CGI qw(:standard);
    use CGI::Carp qw(warningsToBrowser fatalsToBrowser);
    use CGI;
    
    $cgi = new CGI;
    print $cgi->header();
    
    Oppure (ad esempio):
    #!/usr/bin/perl -w
    print "Content-type: text/html\r\n\r\n";
    
    Oppure (ad esempio):
    #!/usr/bin/perl -w
    print "Status: 302 Moved\r\nLocation: perltestCARP.pl\r\n\r\n";
    
  13. Nel caso di uno script Perl l'eventuale debug degli errori può essere agevoltato esportando nel codice perl l'opzione di CGI::CARP (il resto del modulo è già attivo) che stampa a browser gli errori fatali:
    use CGI::Carp qw(warningsToBrowser fatalsToBrowser);
    Attenzione: la mancata generazione da parte dello script Perl degli header http, può essere mascherata da CGI::Carp. Finché ci sono errori di sintassi il codice in CGI::Carp genera un output corretto o almeno utile (completo di header http); quando invece uno script privo di errori di sintassi e quindi pur funzionante da riga di comando non genera gli header, al server non rimane che restituire la pagina “Internal server error”.
  14. Un ulteriore problema di header http mancanti o fuori ordine può essere dovuto al buffering dello standard output, come spiegato nel paragrafo “Other Perils of Buffering”.
  15. Quello sotto è un esempio che mostra alcuni dei moduli installati; altri possono venire aggiunti su richiesta (ed approvazione del docente):
    #!/usr/bin/perl -w
    #se metto un'opzione, l'eventuale Carriage Return rimane "attaccato" solo ad essa e non rischio messaggi di bad interpreter #probalmente fanno gia`parte della configurazione di mod_perl #use CGI::Carp; use CGI::Carp qw(carpout); #use CGI::Carp qw(fatalsToBrowser); #in fase di consegna potrebbe bastare questo use CGI::Carp qw(warningsToBrowser fatalsToBrowser); use CGI qw(:standard); use CGI::Session; use Apache::Session; #da http://search.cpan.org/~gaas/libwww-perl-5.825/lib/LWP/Simple.pm #Note that if you are using both LWP::Simple and the very popular CGI.pm module, you may be importing a head function from each module, producing a warning like "Prototype mismatch: sub main::head ($) vs none". Get around this problem by just not importing LWP::Simple's head function, like so: use LWP::Simple qw(!head); #use WWW::Mechanize ;                                                                                                                                                                                                use XML::Simple; use XML::LibXML; use XML::Writer ; use XML::Handler::YAWriter; use XML::XSLT; #incompleta, meglio LibXSLT use XML::LibXSLT; use HTML::Lint; use HTML::Entities; #encode_entities($_) use URI::Escape; #uri_escape($_) use Image::Magick; #apparentemente parte del pacchetto libimage-size-perl use Image::Size; use Net::SMTP; use DateTime; use DateTime::Format::Mail; my $smtp = Net::SMTP->new('smtp.studenti.math.unipd.it' , Hello => 'studenti.math.unipd.it' , Timeout => 30 , Debug => 1, ); $smtp->mail($ENV{USER} . "\@studenti.math.unipd.it"); $smtp->to ($ENV{USER} . "\@studenti.math.unipd.it"); $smtp->data() ; my $dt = DateTime->from_epoch ( epoch => time() ) ; # DateTime->now; # same as ( epoch => time() ) $smtp->datasend("Date: " . DateTime::Format::Mail->format_datetime( $dt ) . "\n") ; #al posto di gmtime(time) $smtp->datasend("Subject: prova dello script " . $0 . " " . $$ . "\n"); $smtp->datasend("From: " . $ENV{USER} . "-noreply\@studenti.math.unipd.it\n"); $smtp->datasend("To: \"me stesso\" <" . $ENV{USER} . "\@studenti.math.unipd.it>\n"); $smtp->datasend("\n"); my $redirect=0; if ( $redirect ) { print "Status: 302 Moved\r\nLocation: perltestCARP.pl\r\n\r\n"; $smtp->datasend( "Lo script ha solo ridiretto il browser...\n" ); } else { print "Content-type: text/html\r\n\r\n"; print "Hello world!<br />\r\nThis is not really html but " . `id` . ".<br />\r\n"; for (my $i=0; $i<10; $i++) { print $i."<br />"; } $smtp->datasend("Lo script ha stampato l'output di un ciclo...\n"); } $smtp->dataend(); $smtp->quit;
  16. Durante la fase di test degli script è inoltre opportuno tenere aperta una shell  dentro il server del corso così da killare per tempo gli script che, ad esempio facendo un ciclo infinito, altrimenti  appesantirebbero il server. Comandi utili risultano ps ux; killall nomeprogramma; o anche htop (ncurses-based process viewer). 

To top

Tecnologie Web - A.A. 2011-2012 (istruzioni per il server di casa)

Sconsigliamo di copiare solo all'ultimo momento file statici e script dal server di casa sul server dei laboratori: potrebbero esserci sottili differenze nel comportamento fra le due macchine ed il docente potrebbe voler valutare il comportamento del progetto sotto esame solo su quella del laboratorio.

Differenza tra url e path

Premesso che le istruzioni e i consigli sotto non garantiscono la trasportabilità del progetto, comunque rendiamo disponibile un file di configurazione che riproduce abbastanza la differenza fra url e path che c'è nella configurazione del server dell'aula:

DocumentRoot /var/www

<Directory />
Options FollowSymLinks
AllowOverride None
<Directory>

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

#           URL (tenere per primo)    PATH
ScriptAlias /xTecWeb/cgi-bin/         /var/www/xTecWeb/cgi-bin/
<Directory "/var/www/xTecWeb/cgi-bin">
        AllowOverride None
        Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
        Order allow,deny
        Allow from all
</Directory>

#           URL (tenere per secondo)  PATH
Alias       /xTecWeb/                 /var/www/xTecWeb/public_html/ 

L'esempio viene da una distribuzione Ubuntu recente; il file è infatti /etc/apache2/sites-available/default; attenzione a non editare in sites-enabled (potrebbero venir caricati più siti).

Permessi e modifica dei file

I permessi sul server del laboratorio possono non essere quelli necessari a far funzionare la configurazione sopra; probabilmente non installerete suEXEC per cui:
  • se vorrete editare i file col vostro utente e far girare il server httpd di casa con l'uid dell'utente www-data i permessi di file e directory in /var/www/xTecWeb/ saranno facilmente 777 come consigliato in molti siti Internet
  • viceversa se farete girare il server httpd di casa con l'uid del vostro utente i permessi potranno essere addirittura 700: vedi direttiva User
  • forse meglio diventare l'utente www-data quando si editano i file, ad esempio con:
    sudo su - www-data -c emacs /var/www/xTecWeb/public_html/index.html

Ripetiamo che in laboratorio sono al più 755 (niente permesso di scrittura al gruppo e ad other).

Codifica dei file e path dell'interprete Perl

In particolare la prima riga degli script deve essere codificata per Unix e non per Windows; vedi fromdos nomefile.pl.

Moduli di Apache

Verificare che siano installati anche sulla macchina del laboratorio e che l'utilizzo possa essere concesso agli studenti; cercare piuttosto il modo per ottenere lo stesso risultato con le funzionalità del Perl.