onjin.net » home.pl & django – pierwsza potyczka

home.pl & django – pierwsza potyczka

home.pl obsługuje pythona jako cgi (pliki .py) więc tego będziemy się trzymać. Instalację wykonamy w katalogu /py

instalacja django

hardcoded ale działa wrzucamy to do /py i ruchamiamy poprzez www (plik install.py)

#!/usr/bin/env python
import os

os.system("wget http://www.djangoproject.com/download/1.0.2/tarball/")
os.system("tar zxf Django-1.0.2-final.tar.gz")
os.system("rm Django-1.0.2-final.tar.gz")
os.system("mv Django-1.0.2-final tmp")
os.system("mv tmp/django django")

nasz projekt

Lokalnie wołamy

django-admin.py startproject pytest

i wrzucamy katalog pytest przez ftp na home do katalogu /py .

dispatch.py

#!/usr/bin/env python

import os, sys
import django.core.handlers.wsgi

def run_with_cgi(application):

    environ                      = dict(os.environ.items())
    environ['wsgi.input']        = sys.stdin
    environ['wsgi.errors']       = sys.stderr
    environ['wsgi.version']      = (1,0)
    environ['wsgi.multithread']  = False
    environ['wsgi.multiprocess'] = True
    environ['wsgi.run_once']     = True

    if environ.get('HTTPS','off') in ('on','1'):
        environ['wsgi.url_scheme'] = 'https'
    else:
        environ['wsgi.url_scheme'] = 'http'

    headers_set  = []
    headers_sent = []

    def write(data):
        if not headers_set:
             raise AssertionError("write() before start_response()")

        elif not headers_sent:
             # Before the first output, send the stored headers
             status, response_headers = headers_sent[:] = headers_set
             sys.stdout.write('Status: %s\\r\\n' % status)
             for header in response_headers:
                 sys.stdout.write('%s: %s\\r\\n' % header)
             sys.stdout.write('\\r\\n')

        sys.stdout.write(data)
        sys.stdout.flush()

    def start_response(status,response_headers,exc_info=None):
        if exc_info:
            try:
                if headers_sent:
                    # Re-raise original exception if headers sent
                    raise exc_info[0], exc_info[1], exc_info[2]
            finally:
                exc_info = None     # avoid dangling circular ref
        elif headers_set:
            raise AssertionError("Headers already set!")

        headers_set[:] = [status,response_headers]
        return write

    result = application(environ, start_response)
    try:
        for data in result:
            if data:    # don't send headers until body appears
                write(data)
        if not headers_sent:
            write('')   # send headers now if body was empty
    finally:
        if hasattr(result,'close'):
            result.close()

# Change this to the directory above your site code.
sys.path.append("/py")
# Change mysite to the name of your site package
os.environ['DJANGO_SETTINGS_MODULE'] = 'pytest.settings'

run_with_cgi(django.core.handlers.wsgi.WSGIHandler())

i odpalamy to by www na razie tyle …

Dokładam paczkę z plikami do testu:

py.zip

unzip py.zip; ftp na home.pl; open http://server.home.pl/py/dispatch.py/admin

Be Sociable, Share!

40 Comments to “home.pl & django – pierwsza potyczka”

mbw 27 marca 2009 at 23:23 #

Ciekawy wpis. Mam pytanie: udało Ci się skonfigurować następnie w Django dostęp do bazy danych? Mi cały czas rzuca błędami (mysql): nie może wywołać pwd.getpwuid(os.getuid()) – odrzuca uid.
Marek 28 marca 2009 at 17:48 #

Na razie uruchomiłem na sqlite, z mysq/postgres jeszcze niepróbowałem. Ale w najbliższych dniach będę próbował to dam znać
Szymon 21 czerwca 2009 at 11:00 #

Czy jeszcze jakies pliki sa potrzebne aby uruchomic na home.pl? Mnie sie niestety nie udalo Masz moze jakas gotowa przykladowa paczke dla testow? Z gory dzieki.
Marek 21 czerwca 2009 at 17:45 #

Mam paczkę, którą wykonywałem test:
* http://onjin.net/files/py.zip

wrzucić na server, rozpakować i powinno zadziałać:
* http://server.home.pl/py/dispatch.cgi/admin
eXpose 2 października 2009 at 13:57 #

Prawie mi się udało tzn. działa obsługa sql tylko nie moge odpalić panelu admina. Może komuś się udało?
Marek 2 października 2009 at 14:00 #

Panel działa bez problemu. Jakie są objawy/komunikaty w Twoim przypadku?
eXpose 3 października 2009 at 08:30 #

Dostaje cały czas błąd 404. Używam django 1.1 i do pliku dispatch.py dodałem os.environ['HOME']=’/’ żeby używać mysql
Marek 4 października 2009 at 01:35 #

Spróbuj bez dodawania ‘HOME’. Paczkę do mysql’a wystarczy, że wgrasz na ścieżkę, dostępną z projektu.
czemiello 6 listopada 2009 at 01:14 #

Hej a wiesz moze jak poradzic sobie z bugiem takim ze nie akceptuje ciasteczek na serwerze home.pl
http://code.djangoproject.com/ticket/4220
tutaj link do buga
robb 2 stycznia 2010 at 10:34 #

A czy nie jest tak, że korzystając z modelu cgi tracimy najlepsze co daje django, czyli szybkość? Czy nie jest tak, że z każdym requestem cały framework przeżywa cold start?
Niech mnie ktoś poprawi jeśli się mylę.
Marek 2 stycznia 2010 at 12:19 #

Tak, przy cgi aplikacja musi wstawać za każdym razem. W przypadku home.pl nie ma innej możliwości. Czy będzie to python, perl czy php aplikacja i tak jak żołnierz, padnij powstań robi . Pozostaje więc tylko wybór ulubionego języka do pracy.
Uruchamianie projektu Django na home.pl « IT Guy VS World

[...] którzy mają problemy z uruchomieniem aplikacji django na serwerach home.pl polecam ten wpis. Tagi: django, Programming Podziel [...]
Pawel 2 marca 2010 at 13:46 #

Dzięki wielkie za ten poradnik. Natrafiłem na taki problem. .htaccess wskazuje na dispatch.py oraz ustawiłem subdomenę na katalog py/. I teraz jeżeli staram się wskazać jakikolwiek widok muszę to robić przez loginhome.home.pl/py/dispatch.py/widok jednakże nie jestem w stanie uzyskać tego wyniku przez zastosowanie subdomeny (czyli subdomena/widok). Jakaś wskazówka gdzie mogę znależć rozwiązanie?
Marek 2 marca 2010 at 14:10 #

W pliku ‘dispatch.py’ znajduje się linijka ‘sys.path.append(„/py”)’ i to jest problem.

Jak wchodzisz przez domenę trzeba by zamiast /py dać /, lub prościej: ‘sys.path.append( os.path.join(os.path.dirname(__file__) )’
Pawel 2 marca 2010 at 15:30 #

Dzięki za odpowiedź. Niestety nadal coś chrzanię
w urls.py mam takie wpisy:
(‘^$’, root_site),
(‘^test/$’, podstrona),

Zarówno ‘root_site’ jak i ‘podstrona’ wyrzucają tekst za pośrednictwem HttpResponse. ‘root_site’ łąduje się bez problemu (zarówno przez domenę jak i przez bezpośrednie odwołanie) natomiast ‘podstrona’ zostanie wyświetlona tylko przez bezpośrednie wywołanie dispatch.py.
Spróbowałem obydwu zaproponowanych przez Ciebie zmian i zero efektu.

P.S.
Sam „program” (chociaż ja bym tego tak dumnie nie nazwał) testowałem lokalnie oraz na testowym koncie na megiteam.pl – i działa
Marek 4 marca 2010 at 09:13 #

Nie jestem pewien, ale może zamień kolejność w urls.py, umieszczając ^$ na końcu
wojtas 5 maja 2010 at 00:27 #

trzeba miec serwer dedykowany u nich by odpalic django? Czy moze byc np „Hosting UNIX” ?
Marek 5 maja 2010 at 07:07 #

Ten przykład odpaliłem na zwykłym hostingu, bez dedyka. W przypadku dedyka możesz użyć fcgi lub wsgi i wszystko będzie chodzić o wiele szybciej.
YatZeck 11 maja 2010 at 18:28 #

Potiwerdzam – da się uruchomić to na „zwyczajnym” hostingu. Chciałbym się tylko zmienić 1 szczegół. Obecnie adres wygląda tak http://ladny-adres/py/dispatch.py/admin i nie hest to ladny adres. Miło by było, aby strona dostępna była jako http://ladny-adres/py/admin.
Da radę?
Marek 11 maja 2010 at 19:01 #

w .htaccess wpisujemy:

DirectoryIndex dispatch.py
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /dispatch.py/$1 [L]
YatZeck 11 maja 2010 at 19:16 #

Thx! Ciągle o tym zapominam – cóż nie jeste ze mnie dziecko www:)
Marek 11 maja 2010 at 19:53 #

np. powodzenia z projektem
sjn 25 września 2010 at 08:41 #

hej,

fajny post udalo mi sie postawic witryne na home….niestety po kilku h pojawil sie problem:

Malformed header from CGI script: Traceback (most recent call last): File „/dispatch.py”, line 67, in run_with_cgi(django.core.handlers.wsgi.WSGIHandler()) File „/dispatch.py”, line 51, in run_with_cgi result = application(environ, start_response) File „/django/core/handlers/wsgi.py”, line 230, in __call__ self.load_middleware() File „/django/core/handlers/base.py”, line 42, in load_middleware raise exceptions.ImproperlyConfigured(‘Error importing middleware %s: „%s”‘ % (mw_module, e)) django.core.exceptions.ImproperlyConfigured: Error importing middleware django.middleware.common: „No module named _md5″

jakies pomysly jak to mozna naprawic? ( bez rekompilacji apache )
Marek 25 września 2010 at 10:26 #

Właśnie dziś rozpadł się site, który działał przez ok. rok na home.pl, dokładnie z tym samym komunikatem błędu.

Albo apache bez ssl’a albo brak python-hashlib, albo binarka python nieprawidłowa do biblioteki …

Generalnie pozostaje chyba napisać do home.pl z pytaniem ‘dlaczego…?’
sjn 25 września 2010 at 14:08 #

no nie pozostaje nic innego niz czekac – a serwis lezy….probwalem mu hasliba wskazywac czy cos – ale wszystko bez powodzenia…..
Marek 25 września 2010 at 14:32 #

Na hosting django mogę polecić w polsce megitem.pl,
sam hostuję na własnym dedyku.
sjn 25 września 2010 at 16:16 #

no ja tez sam sobie hostuje wszystko, ale to akurat stronka dla klienta i on chce ja miec u siebie…mozesz podac adres swojego site hostowanego na home.pl ? btw. udalo ci sie zmusic django do wspolpracy z mysql’em?
Marek 28 września 2010 at 20:20 #

http://www.maxebook.pl – napisałem do home i rozwiązali problem z pakietem md5, więc teraz już wszystko działa a mysql jeszcze nie uruchamiałem …
pma_ 5 listopada 2010 at 10:32 #

Zostawcie to bardziewie w spokoju, szkoda czasu i nerwów, ja mam parę projektów na megiteam i tam to po prostu działa.
mac 10 sierpnia 2011 at 22:12 #

Czy aktualnie się komuś udało uruchomić django na home?
Marek 10 sierpnia 2011 at 23:18 #

projekt, który uruchomiłem na home.pl + django nadal działa bez problemów działa na django 1.0.2 + sqlite
Lendzian 14 sierpnia 2011 at 14:41 #

A takie pytanie mam wynikające z faktu bycia początkującym – przy tworzeniu serwisów w Django wypada mieć dostęp do konsoli, czego dla kont współdzielonych home.pl nie oferuje. Marek, czy Ty masz wypasione konto dedykowane, czy instalacja Django bez konsoli jest możliwa? Zresztą po postawieniu serwisu od czasu do czasu też wypada mieć dostęp do konsoli – jak to wygląda u Ciebie?
Marek 14 sierpnia 2011 at 15:43 #

Django da się zainstalować bez dostępu do konsoli. Co można wykonuje lokalnie i kopiuję przez ftp.

Gdy używamy south czy liquimigrate migracje bazy można wykonać na swoim komputerze podając tylko dostęp do bazy na home.pl

To co muszę wykonać na serwerze, wykonuję przy pomocy skryptu .py wrzuconego na serwer i uruchomionego przez przeglądarkę

Generalnie, jako hosting dla django polecam megiteam.pl, osobiście posiadam pełen serwer dedykowany w ovh.pl.

Django na home.pl instalowałem tylko dla osób, które nie zdecydowały się na zmianę hostingu, a przy okazji chciałem sprawdzić czy da się to wykonać.

Oczywiście nie jest to optymalne rozwiązanie pod większe serwisy. Brakuje obsługi memcache lub pamięci procesu. CGI wymaga uruchamiania całego stosu aplikacji przy każdym otwarciu strony, zamiast raz przy uruchomieniu procesu (fcgi, czy wsgi). W przypadku home.pl więc wskazany jest cache plikowy ustawiony na 1-x minut w zależności od potrzeb.
szajmon 21 września 2011 at 08:59 #

A czy takie zabiegi na home.pl są zgodne z regulaminem?? Nie doczepią się jeśli taki skrypt instalacyjny django zapuszcze na moim serwerze w home.pl?
szajmon 21 września 2011 at 09:06 #

Poza tym jeszcze mam pytanie, ponieważ kompletnie nie nam się na Pythonie, ,muszę tylko uruchomić zrobiony już w Pythonie serwis. Czy w jakichś ustawieniach serwera home.pl trzeba coś konfigurować, aby serwer dobrze interpretował serwisy zrobione w Pythonie?? Jakies ustawienia .httpd.conf??? Php.ini??
Marek 21 września 2011 at 11:04 #

@szajmon nie sądzę by był jakiś problem z regulaminem, za jednorazowe uruchomienie skryptu,

Co do ustawień: home.pl domyślnie obsługuje pliki z rozszerzeniem .py jako skrypty pythona (jest to opisane w pomocy). php.ini nie ma związku gdyż służy jedynie dla php.

I teraz czy da się Twój gotowy serwis uruchomić na home.pl zależy jeszcze od wymagań tego serwisu i czy można go zapakować w .cgi jak opisałem w artykule.

Pozdrawiam.
szajmon 24 września 2011 at 10:29 #

Co znaczy krok:

Lokalnie wołamy
django-admin.py startproject pytest

???
Marek 24 września 2011 at 12:28 #

czyli na swoim komputerze tworzymy nowy projekt django onazwie pytest:
* https://docs.djangoproject.com/en/1.3/ref/django-admin/
szajmon 24 września 2011 at 14:26 #

Przepraszam, że tak zawracam głowe, ale nigdy nie miałem doczynienia z Pythonem, ale chciałbym spróbować uruchomić ten serwis!
Podczas instalacji django pokazuje postęp operacji, ale na końcu wywala to:

„`index.html.2′ saved [4649433/4649433] tar (child): Django-1.0.2-final.tar.gz: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: Error is not recoverable: exiting now rm: cannot remove `Django-1.0.2-final.tar.gz’: No such file or directory mv: cannot stat `Django-1.0.2-final’: No such file or directory mv: cannot stat `tmp/django’: No such file or directory ”

Co to oznacza??? Czegoś brakuje???
Marek 24 września 2011 at 21:32 #

zdaje się że, w Twoim przypadku plik z django został nazwany ‘index.html.2′ podczas pobierania, można do dodać parametr by wymusić nazwę:
* wget http://www.djangoproject.com/download/1.0.2/tarball/-O Django-1.0.2-final.tar.gz

btw, 1.0.2 to już wersja django z 2009 roku, jeżeli Twój projekt wymaga innej wersji, to pobierz ją zamiast 1.0.2