Python CGI sur la micro-instance Amazon AWS EC2

Comment pouvez-vous faire en sorte qu'une micro-instance EC2 serve des scripts CGI à partir de lighthttpd? Par exemple Python CGI?

Eh bien, cela a pris une demi-journée, mais j'ai fait fonctionner Python cgi sur une micro-instance gratuite Amazon AWS EC2, en utilisant le serveur lighttpd. Je pense que cela aidera mes camarades nobles à mettre toutes les étapes en un seul endroit. Armé des étapes simples ci-dessous, il ne vous faudra que 15 minutes pour configurer les choses!

Ma question pour les utilisateurs plus expérimentés lisant ceci est: Y a-t-il des failles de sécurité dans ce que j'ai fait? (Voir autorisations de fichier et de répertoire.)

Étape 1: Démarrez votre instance EC2 et ssh dedans.

[De toute évidence, vous devrez vous inscrire à Amazon EC2 et enregistrer vos paires de clés dans un fichier * .pem. Je ne reviendrai pas là-dessus, car Amazon vous explique comment le faire.]

Connectez-vous à votre compte AWS et démarrez votre instance EC2. Le Web propose des didacticiels pour ce faire. Notez que la taille d'instance par défaut qu'Amazon vous présente est "petite". Ce n'est pas "micro" et cela vous coûtera donc de l'argent. Assurez-vous de choisir manuellement "micro". (Les micro instances ne sont gratuites que la première année ...)
Recherchez le code DNS public de votre instance en cours d'exécution. Pour ce faire, cliquez sur l'instance dans le volet supérieur du tableau de bord et vous verrez finalement le champ "DNS public" rempli dans le volet inférieur. (Vous devrez peut-être jouer un peu.) Le DNS public ressemble à ceci:
ec2-174-129-110-23.compute-1.amazonaws.com
Démarrez votre programme de console Unix. (Sur Max OS X, il s'appelle Terminal et réside dans le dossier Applications -> Utilitaires.)
cd dans le répertoire de votre système de bureau contenant votre fichier * .pem contenant vos paires de clés AWS.
ssh à votre instance EC2 en utilisant une commande comme:
ssh -i <<your *.pem filename>> ec2-user@<< Public DNS address >>

Donc, pour moi, c'était:
ssh -i amzn_ec2_keypair.pem ec2-user@ec2-174-129-110-23.compute-1.amazonaws.com
Votre instance EC2 devrait vous laisser entrer.

Étape 2: téléchargez lighttpd sur votre instance EC2.

Pour installer lighttpd, vous aurez besoin d'un accès root sur votre instance EC2. Le problème est: Amazon ne vous laissera pas vous connecter en tant que root. (Pas directement, du moins.) Mais il existe une solution de contournement. Tapez cette commande:
sudo /bin/bash
Le caractère d'invite du système passera de $ à #. Nous ne quitterons pas "sudo" avant la toute dernière étape de ce processus.
Installez l'application lighttpd (version 1.4.28-1.3.amzn1 pour moi):
yum install lighttpd
Installez les bibliothèques FastCGI pour lighttpd (pas nécessaire, mais pourquoi pas?):
yum install lighttpd-fastcgi
Testez que votre serveur fonctionne:
/etc/init.d/lighttpd start

Étape 3: laissez le monde extérieur voir votre serveur.

Si vous essayez maintenant de toucher votre serveur à partir du navigateur de votre bureau, cela échouera. La raison: par défaut, Amazon AWS n'ouvre aucun port à votre instance EC2. Vous devez donc ouvrir les ports manuellement.
Accédez à votre tableau de bord EC2 dans le navigateur de votre bureau. Cliquez sur "Groupes de sécurité" dans le volet gauche. Un ou plusieurs groupes de sécurité apparaîtront dans le volet supérieur droit. Choisissez celle qui a été affectée à votre instance EC2 lorsque vous avez lancé votre instance.
Un tableau intitulé "Connexions autorisées" apparaîtra dans le volet inférieur droit. Un menu contextuel vous permettra de choisir "HTTP" comme méthode de connexion.
Les autres valeurs de cette ligne du tableau doivent être: tcp, 80, 80, 0.0.0.0/0
Frappez maintenant le serveur de votre instance EC2 depuis le bureau de votre navigateur. Utilisez l'adresse DNS publique que vous avez utilisée précédemment pour SSH. Vous devriez voir la page Web générique lighttpd. Si vous ne le faites pas, je ne peux pas vous aider car je suis vraiment un noob. :-(

Étape 4: configurer lighttpd pour servir CGI.

De retour dans le programme de la console, accédez au répertoire de configuration de lighttpd:
cd /etc/lighttpd
Pour activer CGI, vous souhaitez supprimer la mise en commentaire d'une ligne dans le fichier <modules.conf>. (J'aurais pu activer Fast CGI, mais les étapes bébé sont les meilleures!) Vous pouvez le faire avec l'éditeur "ed" comme suit:
ed modules.conf
/include "conf.d\/cgi.conf"/
s/#//
w
q
Créez le répertoire où les programmes CGI vont vivre. (Le fichier /etc/lighttpd/lighttpd.conf détermine où il se trouvera.) Nous allons créer notre répertoire à l'emplacement par défaut, nous n'avons donc pas besoin de modifier les fichiers de configuration:
cd /var/www/lighttpd
mkdir cgi-bin
chmod 755 cgi-bin
Presque là! Bien sûr, vous devez placer un programme CGI de test dans le répertoire cgi-bin. En voici un:
cd cgi-bin
ed
a
#!/usr/bin/python
print "Content-type: text/html\n\n"
print "<html><body>Hello, pyworld.</body></html>"
.
w hellopyworld.py
q
chmod 655 hellopyworld.py
Redémarrez votre serveur lighttpd:
/etc/init.d/lighttpd restart
Testez votre programme CGI. Dans le navigateur de votre bureau, cliquez sur cette URL, en remplaçant l'adresse DNS publique de votre instance EC2:
http://<<Public DNS>>/cgi-bin/hellopyworld.py

Pour moi, c'était:
http://ec2-174-129-110-23.compute-1.amazonaws.com/cgi-bin/hellopyworld.py

Étape 5: C'est tout! Nettoyez et remerciez!

Pour quitter la commande "sudo / bin / bash" donnée précédemment, tapez:
exit
Remerciements: Un grand merci à:

wiki.vpslink.com/Install_and_Configure_lighttpd

www.cyberciti.biz/tips/lighttpd-howto-setup-cgi-bin-access-for-perl-programs.html

aws.typepad.com/aws/2010/06/building-three-tier-architectures-with-security-groups.html
Bonne chance, amigos! Je m'excuse pour la nature non traditionnelle de cette "question" mais j'ai reçu tellement d'aide de Stackoverflow que j'étais impatient de donner quelque chose en retour.

— utilisateur595585
source

Je vous félicite d'avoir publié un guide, mais SO est pour poser des questions. Je recommanderais blogspot ou quelque chose de similaire pour cela. Si vous avez hâte de redonner, vous devriez répondre aux questions :)

Je soumets que tout "mode d'emploi" contient une question implicite, c'est-à-dire "comment faire X?" À l'avenir, je formulerai la question de manière explicite, même si elle ressemblait initialement à de la pédanterie. Mais, parce que cela pourrait aider les moteurs de recherche et éviter la confusion chez les lecteurs, je pense maintenant que cela en vaut la peine. Merci.

C'est très gentil de la part d'un nouveau membre de publier un tel tutoriel. Quoi qu'il en soit, il répond aux questions qui n'ont pas encore été posées. Au fait, cela me donne les informations dont j'avais besoin il y a quelques jours, maintenant je connais l'existence de ce type de service. Soit dit en passant, à une époque où l'on parle beaucoup du Cloud, ce message est susceptible d'être très utile pour beaucoup de gens. Il ne mérite donc pas d'être découragé et je vote favorablement.

@ user595585 La pratique approuvée consiste à poser une question "Comment faire" et à y répondre vous-même. Vous obtenez même plus de représentants pour vos problèmes de cette façon. Veuillez consulter la FAQ . "Il est également parfaitement bien de poser et de répondre à votre propre question, tant que vous faites semblant d'être sur Jeopardy: formulez-le sous la forme d'une question."

— C. Ross

@user Modifiez votre question pour qu'elle soit une question, puis répondez-y avec tous les détails que vous avez fournis. En outre, supprimez certaines de ces parens, vous parlez d'héberger python sur EC2, pas de lisp.

— Ripped Off

(Message étrange, donc j'espère que ce ne sera pas une réponse aussi étrange).

En ce qui concerne les failles de sécurité: il est considéré comme une mauvaise pratique générale de stocker des scripts cgi-bin dans la racine du document du serveur Web. Même le W3C y échappe sous "Les langues compilées telles que C sont-elles plus sûres ..." dans leur FAQ sur la sécurité du World Wide Web :

Considérez le scénario suivant. Par souci de commodité, vous avez décidé d'identifier les scripts CGI sur le serveur à l'aide de l'extension .cgi. Plus tard, vous devrez apporter une petite modification à un script CGI interprété. Vous l'ouvrez avec l'éditeur de texte Emacs et modifiez le script. Malheureusement, l'édition laisse une copie de sauvegarde du code source du script dans l'arborescence des documents. Bien que l'utilisateur distant ne puisse pas obtenir le code source en récupérant le script lui-même, il peut désormais obtenir la copie de sauvegarde en demandant aveuglément l'URL:
    http://your-site/a/path/your_script.cgi~
(C'est une autre bonne raison de limiter les scripts CGI à cgi-bin et de s'assurer que cgi-bin est distinct de la racine du document.)

Ce n'est pas une menace aussi importante que la possibilité d'écrire un fichier à la racine du document. Cependant, un attaquant pourrait obtenir le code source du cgi, concevoir une attaque dirigée contre celui-ci et l'utiliser comme tremplin vers le serveur.

Pour atténuer ce problème, vous pouvez ajouter les lignes suivantes au fichier lighttpd.conf (ou à une variante de celui-ci) pour diriger cgi-bin vers un répertoire distinct de la racine du document / var / www / lighttpd.

$HTTP["url"] =~ "/cgi-bin/" { cgi.assign = ( "" => "" ) }
alias.url = ( "/cgi-bin/" => "/usr/lib/cgi-bin/" )

Cela nécessite à la fois les modules cgi et alias pour lighttpd.

— Jeff Stice-Hall
source