Přechod z webhostingu na VPS + instalace Plone 4 a dalších služeb

Transkript

Přechod z LAMP webhostingu na VPS
+ instalace Plone 4 a dalších sluţeb v doméně Jezisheck.cz
Jakub Kolář
srpen 2011
Seminární práce v rámci studia předmětu Masarykovy univerzity PV219: Seminář webdesignu v semestru jaro 2011
Verze č. 1 ze 4. 8. 2011
OBSAH
1. ÚVOD
1.1. Cíle práce
2. PRŮZKUM TRHU
2.1. Amazon Elastic Cloud
2.2. WEDOS VPS Hosting
2.3. Shrnutí a srovnání
2.4. Přehled
3. PŘEVOD DOMÉNOVÉHO NÁZVU
4. OBJEDNÁVKA VPS
5. INSTALACE VPS
5.1. České locale
5.2.Webmin
5.3. LAMP server
6. NASTAVOVÁNÍ VPS
6.1. Apache 2
6.2. PHP 5
6.3.Instalace phpMyAdmina
6.4. Instalace Postfixu
6.5.Podpora pro SSL
6.5.1. Nastavení Apache
6.6. Firewall
4
4
5
5
5
6
6
7
7
7
8
8
8
8
9
10
10
10
10
11
12
© Jakub Kolář 2011 – Licencováno pod licencí Creative Commons0)
7. ZMĚNA DNS SERVERŮ
8. ZMĚNA MAIL SERVERU
8.1. Zkouška e-mailu na
neexistující adresu v doméně
9. INSTALACE ZOPE & PLONE
9.1. Krátce o Zopu a Plonu 4
9.2. Stažení a UnifiedInstaller
9.2.1. ZEO cluster
nebo standalone?
9.2.2. UnifiedInstaller
9.3.Nastavení, buildout
9.4. První spuštění
10. VYTVOŘENÍ INSTANCE PLONE
10.1. Prvotní nastavení
11.SCHOVÁNÍ PLONE ZA APACHE
A ZABEZPEČENÍ POMOCÍ SSL
11.1. Příprava Apache
11.2. Přidání VirtualHostů
12
13
13
14
14
15
15
16
17
18
18
19
19
20
20
Přechod z webhostingu na VPS | 2
12. LADĚNÍ DETAILŮ
12.1. Vytvoření
certifikační autority
12.2. Zakázání subdomény www
12.3. Chybové stránky (404 aj.)
12.4. Vytvoření spouštěcího
souboru pro Plone
12.5. Umístění instance Plone
kromě domény i do složky
13.SHRNUTÍ ZÍSKANÝCH ZKUŠENOSTÍ
23
23
24
24
SLOVNÍČEK POUŽÍVANÝCH
POJMŮ A ZKRATEK
26
ODKAZY
28
INFORMACE O AUTORSTVÍ A LICENCI
29
24
25
25
1. ÚVOD
Tato seminární práce v rámci předmětu PV219: Seminář webdesignu (jaro 2011) má dokumentovat postup
při stěhování obsahu mého webového serveru jezisheck.cz s několika stránkami s PHP na soukromý virtuální server (VPS)
a dále zprovoznění systému pro správu obsahu (CMS) Plone 4.
1.1 CÍLE PRÁCE
Pojďme si nyní ujasnit, o co přesně mi vlastně jde: Projít procesem přenesení veškerého stávajícího obsahu domény
jezisheck.cz od poskytovatele hostingu, společnosti THINLine, a zároveň zrušení veškerých vazeb této společnosti jakožto
původního registrátora doménového názvu.
To by nemělo být obtížné, protože doteď jsem na serveru měl jen jednu statickou stránku s kontaktními informacemi, k ní
nějaké obrázky, šablony kaskádových stylů a jiné pomocné soubory domény. V subdoméně miranda.jezisheck.cz se
nachází jedna PHP stránka, která jen přepíná svůj obsah podle parametru v URL a poskytuje rozhraní pro stahování souborů
se záznamem přístupů. A v subdoméně w.jezisheck.cz provozuji soukromý souborový server, pro který potřebuji zprovoznit
šifrovaný přístup přes SSL. MySQL, ač k dispozici, je nepoužívané.
Pro realizaci budu potřebovat obyčejný LAMP (Linux + Apache + MySQL + PHP) server. Standardní webhosting ostatně není
nic jiného, než poměrně málo flexibilní, myšleno málo přizpůsobitelná bez příplatků, část prostředků LAMP serveru.
Hlavní výhodou VPS je ale možnost provozování ZOPE serveru. Na jeho instalaci a nastavení s vazbami na okolní služby bude
kladen i největší důraz i v této práci, zejména pak jeho schování za server Apache 2 a zabezpečení komunikace pomocí SSL.
Celkovým cílem je poté získat nové a rozvinou stávající zkušenosti z oblasti správy a instalace webového serveru,
která s oborem webdesignu úzce souvisí.
2. PRŮZKUM TRHU
1)
Mým starým poskytovatelem webhostingu byla společnost THINLine, která jej nabízí jako produkt Český hosting . Za cenu
1500,- Kč včetně DPH člověk dostane spolehlivý LAMP hosting, včetně .CZ domény. Avšak na to, že je to jen LAMP server, lze
najít cenově srovnatelné nabídky VPS, které nabídnou větší možnost nastavení a více paměti. Limit paměti pro PHP skripty
na Českém hostingu je 32 MB. To na obvyklé aplikace typu blogu nebo e-shopu stačí, ale například při práci s obrázky
se to může ukázat jako málo.
2.1 AMAZON ELASTIC CLOUD
2)
Jako zajímavá se mě jeví nabídka Amazon Web Services (AWS) s názvem AWS Free Usage Tier . Jedná se o 12-ti měsíční
období, kdy si uživatel může vyzkoušet některé se služeb z palety, které AWS poskytují. Je mezi nimi také Amazon EC2 Linux
Micro Instance, což je ve zkratce VPS provozovaný v AWS cloudu s 5 GB diskového prostoru a 613 MB paměti.
AWS mají pro mě celkem netradiční způsob účtování zpětně za spotřebované zdroje. Platí se jednotlivě za výpočetní výkon,
datová úložiště, zálohy, IP adresy, objem přenesených dat, a jiné. Dle mých výpočtů by se cena za provoz již zmíněné EC2
Micro Instance s na datové toky nepříliš náročnými aplikacemi měla pohybovat v přepočtu někde mezi 1500,- a 2000,- Kč za
rok.
2.2 WEDOS VPS HOSTING
3)
Další cenově velice dobře dostupnou nabídkou, kterou jsem zkoumal, je VPS hosting společnosti WEDOS . Hosting VPS
nabízejí po modulech za pevnou cenu 120,- Kč s DPH za měsíc, tj. 1440,- Kč ročně. Přičemž jeden tento modul zahrnuje 512 MB
paměti, 15 GB diskového prostoru a samozřejmě nějaký čas na procesoru. Za datové přenosy se neplatí.
2.3 SHRNUTÍ A SROVNÁNÍ
Protože mám radši garantovanou službu za předem známou cenu, od řešení založeného na AWS jsem nakonec upustil.
Používal jsem ho v podstatě jako zkušební, protože administrace VPS od počátku je pro mě novinkou. Některé věci jsem
si tedy nejprve zkoušel na AWS VPS a až poté na novém VPS od WEDOS. Pro WEDOS hovořilo i to, že jsou zároveň
registrátorem .CZ domén a mají je oproti THINLine téměř za poloviční cenu.
4)
Podobné parametry VPS nabízí např. i poskytovatel SAVANA ve svém tarifu SAVANA 1000 , ale z popisu služby jsem si nebyl
jist, zda se jedná skutečně o VPS s plným root přístupem a jejich technická podpora více než měsíc nereaguje na dotaz. Navíc
domény mají za cenu srovnatelnou s THINLine – plus pro WEDOS.
2.4 PŘEHLED
Přehledné srovnání srovnatelných parametrů zkoumaných nabídek:
1)
2)
3)
parametr
Český hosting
cena hostingu (s DPH/rok)
1200 Kč
cca 1500 – 2000 Kč
1440 Kč
1728 Kč
doména .CZ (s DPH/rok)
300 Kč
nenabízí
174 Kč
287 Kč
výkon procesoru
*
**
***
****
paměť
32 MB (PHP memory_limit)
613 MB
512 MB
512 MB
diskový prostor
2 GB
5 GB
15 GB
30 GB
podpora Plone CMS
ne
ano
ano
?
technická podpora v ceně
ano
ne
ne
ano
AWS (Free Tier)
WEDOS (VPS)
SAVANA 1000
4)
3. PŘEVOD DOMÉNOVÉHO NÁZVU
Jelikož jsem měl vždy pouze standardní webhostingy, byl poskytovatel zároveň mým registrátorem. Díky výběru firmy
WEDOS jsem tak mohl tuto konzistenci zachovat. Prvním krokem na mé cestě k nim tedy byla změna registrátora domény.
Zároveň se změnou jsem musel platnost domény prodloužit o rok. Vyplnil jsem tedy předobjednávkový formulář na jejich
webu a obratem mi na e-mail, jako vlastníkovi domény, přišlo ze sdružení CZ.NIC heslo pro převod k novému registrátorovi.
Po platbě prodlužovací ceny domény kartou online bylo vše hotovo. Celý proces nezabral ani 15 minut!
4. OBJEDNÁVKA VPS
Krokem druhým bylo objednání hostingu VPS. Zde už byla klíčová volba operačního systému. Vybral jsem dle osobní
preference Ubuntu, protože s ním mám zkušenosti z desktopových použití a protože na něj většinou fungují návody pro široce
rozšířený Debian. Další z možností, nad kterou jsem chvíli uvažoval, byla Fedora 14 ISP obsahující předinstalovaný Apache, PHP,
MySQL, mailserver, DNS server a jakýsi ovládací panel. To mi mohlo ze začátku ušetřit trochu námahy, ale nakonec jsem
se rozhodl, že i z hlediska získávání zkušeností bude lepší zvolit relativně obtížnější cestu OS Ubuntu 10.10.
Platbu jsem prováděl v rámci urychlení opět kartou online. Na zkoušku jsem si předplatil jen jeden měsíc (za 120,- Kč s DPH +
10% přirážka = 132,- Kč). Systém po přijetí platby hlásí zřízení služby do jednoho pracovního dne, ale realita byla taková,
že za sedm minut mi přišla e-mailem informace o vytvoření VPS s přístupovými údaji a skutečně se mi s pomocí PuTTy ihned
podařilo přihlásit na SSH.
5. INSTALACE VPS
První věc po přihlášení byla samozřejmě změna hesla pro uživatele root, ale také ověření, zda je nainstalován konzolový
správce souborů Midnight Commander (mc), aktualizace repozitáře balíků a balíku sudo a vytvoření standardního uživatele,
s oprávněními spouštět pomocí sudo příkazy jako root.
5.1 INSTALACE ČESKÉHO LOCALE
V první řadě jsem chtěl, aby na mě aplikace, které to podporují, mluvily česky, tedy jsem instaloval české locale cs_CZ.UTF-8.
To jsem nakonfiguroval tak, aby bylo pouze preferovaným a v případě, že jej aplikace nepodporuje, přešla na standardní
anglické locale en_US nebo en.
5.3 INSTALACE WEBMINA
5)
Pro usnadnění monitorování systému jsem také nainstaloval nástroj Webmin. Postupoval jsem dle návodu pro Debian
na jeho domovské stránce, konkrétně podle části nazvané Using the Webmin APT repository. Instalace byla takto rychlá
a snadná.
5.3 INSTALACE LAMP SERVERU
6)
K instalaci LAMP serveru jsem přistoupil podle návodu na stránce komunitní dokumentace Ubuntu . V podstatě stačilo jen
spustit příkaz: sudo tasksel install lamp-server Nainstaloval se tak automaticky Apache 2 server s povoleným
a nastaveným PHP 5 a MySQL 5 server – opět takřka bez práce.
6. NASTAVOVÁNÍ VPS
Nyní jsem se dostal do stavu, kdy byly nainstalovány komponenty potřebné pro rozběhnutí stránek v rozsahu, v jakém byly
na starém hostingu, jen je nastavit, aby fungovaly podle mých představ.
V této kapitole tedy nastavím Apache a PHP. Potom při instalaci phpMyAdmina vyzkouším, jestli funguje MySQL server.
A když už budu v tom nastavování různých služeb, nastavím i poštovní program Postfix, přístup přes SSL a vygeneruji první SSL
certifikáty. V neposlední řadě ještě zapnu firewall a povolím pouze ty porty a služby, které budu používat.
6.1 NASTAVENÍ APACHE 2
Protože na starém webhostingu bylo vytváření domén třetí úrovně záležitostí na 2 kliknutí, vytvořil jsem si tehdy subdomény
miranda.jezisheck.cz a w.jezisheck.cz, které chci zachovat. K realizaci tohoto na VPS jsou zapotřebí dvě věci:
1) vytvořit příslušný A (Address) záznam v DNS a 2) připravit Apache na požadavky na tuto adresu pomocí VirtualHostu.
V této testovací fázi jsem k nastavení DNS záznamů použil změny
v systémovém souboru hosts v c:\Windows\System32\drivers\etc.
Skutečné DNS budu nastavovat až později. VPS byla při vytvoření přiřazena
IPv4 adresa 31.31.73.20, tedy příslušné řádky v hosts viz vpravo.
Co se týče druhého kroku, přípravy
VirtualHostu, bude to trochu komplikovanější.
Vpravo je nástin toho, jak by měl vypadat
textový
soubor
definující
tzv.
site
v /etc/apache2/sites-available.
Klíčové jsou v této fázi direktivy ServerName
a ServerAlias, které definují, na které adresy
site slyší. První řádek určuje, že tento
VirtualHost se definuje pro jakoukoli IP adresu
serveru (*) a to na portu 80. DocumentRoot
potom určuje, kde se budou požadované
stránky hledat.
31.31.73.20
31.31.73.20
31.31.73.20
jezisheck.cz
miranda.jezisheck.cz
w.jezisheck.cz
<VirtualHost *:80>
ServerAdmin [email protected]
ServerName jezisheck.cz
ServerAlias www.jezisheck.cz
DocumentRoot /var/www/jezisheck.cz
<Directory /var/www/jezisheck.cz/>
Options FollowSymLinks
AllowOverride All
Order allow,deny
allow from all
</Directory>
CustomLog ${APACHE_LOG_DIR}/access-logs/jezisheck.cz.log combined
ErrorLog ${APACHE_LOG_DIR}/error-logs/jezisheck.cz.log
LogLevel warn
</VirtualHost>
Obdobně se nastaví i další subdomény.
6.2 NASTAVENÍ PHP 5
Díky nástroji tasksel, který za mě nainstaloval PHP do Apache téměř bez práce, jediné, co jsem musel udělat, bylo najít
soubor php.ini v /etc/php5/apache2/ a v něm pro jistotu navýšit paměťový limit PHP na 128 MB a limit pro nahrávaný soubor
na 2 GB.
6.3 INSTALACE PHPMYADMINA
Na zkoušku, zda se MySQL server správně nainstaloval a zda se při instalaci nastavilo správné heslo, které jsem zadal, jsem se
rozhodl použít phpMyAdmina, protože na serveru nemám žádné jiné aplikace využívající tuto databázi. Instalace byla
standardní, jak jsem na ni zvyklý z běžných webhostingů: stažení, rozbalení, vytvoření konfiguračního souboru a zkouška, zda je
možné se přihlásit.
Jen poznamenám, že protože jsem pro phpAdmina nechtěl vytvářet další subdoménu ani ho umisťovat za lomítko do hlavní
domény (např. jezisheck.cz/phpAdmin), nasměroval jsem na root.jezisheck.cz VirtualHosta, který bude obsluhovat
jak phpAdmina, tak případné další nástroje, které mohou časem přibýt.
6.4 INSTALACE POSTFIXU
Jelikož Plone potřebuje k nejrůznějším účelům funkční SMTP server, rozhodl jsem se s předstihem k instalaci Postfixu. Nijak
7)
zvlášť jsem nad tím nedumal, spíše precizně provedl konfiguraci podle návodu v Ubuntu Server Guide .
6.5 KONFIGURACE PODPORY PRO SSL
Pro moje účely postačí certifikáty podepsané samy sebou, ale potřebuji minimálně dva, protože se musí generovat
pro určitou adresu. Jeden certifikát, pojmenovaný jezisheck.cz.crt, potřebuji pro doménu jezisheck.cz a další
any.jezisheck.cz.crt pro subdomény www.jezisheck.cz, w.jezisheck.cz, miranda.jezisheck.cz, …
8)
Asi nemá smysl, abych zde rozepisovat proces tvorby certifikátů. Podrobný návod jsem k tomu našel v Ubuntu Server Guide .
6.5.1 NASTAVENÍ APACHE
Aby byl Apache server schopen šifrovat
stránky, je nutné povolit doplněk mod_ssl.
V Debianu (a tedy i v Ubuntu) je k tomu
pohodlný příkaz: sudo a2enmod ssl
Nyní mohu začít nastavovat Apache
VirtualHosty. Vycházel jsem z návodu na
9)
webu OnLAMP.com . Vpravo jsou
nejdůležitější části konfigurace použité pro
https://w.jezisheck.cz/.
Klíčové jsou při nastavování HTTPS
přístupu údaje na ř. 2 (port SSL – 443),
a poté povolení SSL direktivou SSLEngine
společně s určením umístění certifikátu a
jeho klíče.
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName w.jezisheck.cz
DocumentRoot /var/www/w.jezisheck.cz
<Directory /var/www/w.jezisheck.cz/>
Options FollowSymLinks
AllowOverride All
Order allow,deny
allow from all
</Directory>
CustomLog ${APACHE_LOG_DIR}/access-logs/w.jezisheck.cz_ssl.log combined
ErrorLog ${APACHE_LOG_DIR}/error-logs/w.jezisheck.cz_ssl.log
LogLevel error
SSLEngine on
SSLCertificateFile
/etc/apache2/ssl/any.jezisheck.cz.crt
SSLCertificateKeyFile /etc/apache2/ssl/any.jezisheck.cz.key
</VirtualHost>
</IfModule>
Obdobně jsem nastavil možnost
šifrované komunikace i pro ostatní subdomény i pro hlavní doménu jezisheck.cz. Rozdíly jsou v zásadě pouze v použitém
certifikátu. Jelikož jsem certifikát any.jezisheck.cz.crt generoval pro adresy *.jezisheck.cz, používám jiný pouze pro kořenovou
doménu jezisheck.cz, bez www.
6.6 NASTAVENÍ FIREWALLU
Z bezpečnostních důvodů jsem se ještě před jakýmkoli náznakem útoku rozhodl vztyčit firewall. Ze stejných důvodů nebudu
uveřejňovat konkrétní konfiguraci, jen zmíním, že konfigurace tohoto se pohodlně provádí pomocí Webmina, kterého jsem
instaloval v Oddíle 5.3 a že je klíčové již na počátku povolit komunikaci na portu 22 pro SSH a 10000 pro Webmina. Ostatní už
je volitelné, ale určitě by se nemělo zapomenout povolit porty 80 (HTTP), 443 (HTTPS) a dále služby protokolu ICMP.
7. ZMĚNA DNS SERVERŮ
V tomto místě je čas na rekapitulaci toho, co už mám hotovo. Připravil jsem na VPS HTTP rozhraní s podporou PHP a MySQL
v pohotovosti. Stejně tak je nyní připravena i služba HTTPS se stejnými možnostmi jako HTTP. K tomu slouží Apache server
naslouchající na primárním síťovém rozhraní eth0 na portech 80 a 443. Přes SSH jsem zkopíroval obsah stávajícího webu včetně
subdomén a Apache pomocí VirtualHostů nastavil, aby věděl, kde hledat obsah pro jednotlivé subdomény.
Doposud jsem ale se ale na rozhraní VPS připojoval díky explicitním definicím IP adresy každého jednoho takového serveru
(myšleno subdomény), které jsem krátce zmínil v Oddíle 6.1.
Abych ale dosáhl podobného chování globálně, tedy aby docházelo k překladu adres v doméně jezisheck.cz na IP adresu
VPS 31.31.73.20, je potřeba provést změny v DNS. DNS je systém jmenných serverů, který pro klienty, ať už lidi nebo stroje,
provádí přiřazení IP adresy k doménovému názvu a naopak. Z výkonnostních důvodů není každý dotaz na překlad doménového
názvu na IP adresu řešen se správcem dané domény, rozumějme DNS serverem, ale v systému DNS jsou tyto informace
po nějakou dobu cachovány na lokálních DNS serverech, které provozuje např. i váš poskytovatel konektivity.
Toto všechno uvádím jako zdůvodnění, proč je nejvhodnější dělat změny v DNS večer, protože aktualizace napříč Internetem
je v řádu hodin. Podle toho jsem postupoval i já. Večer jsem pomocí administračního rozhraní mého nového správce domény,
společnosti WEDOS, nastavil jeho NameServery a ráno byla doména globálně přístupná na staré adrese z nového VPS.
Pro všechny subdomény jsem přidal ještě jeden společný A (Address) DNS záznam se jménem * a adresou 31.31.73.20.
8. ZMĚNA MAIL SERVERU
Protože byl bývalý webhosting včetně e-mailů, stála přede mnou ještě nutnost vyřešit nějak doručování e-mailů v doméně
jezisheck.cz. Sice jsem měl definováno několik různých schránek, ale všechny se přeposílaly do mého primárního e-mailu
od jiného poskytovatele, stejně tak e-mailový koš, tj. schránka pro e-maily poslané na neexitující adresy v doméně.
Mohl jsem konfigurovat Postfix, aby bylo možné definovat různé e-mailové schránky s různými vlastníky, ale protože to není
nic, co bych kdy použil, rozhodl jsem se jít snadnější cestou prostého přeposílání veškerých příchozích e-mailů pomocí SMTP
serveru WEDOS. K tomu stačilo přidat do DNS MX záznam s adresou mxredir.wedos.net. Současně s adresou se definuje
i číselná priorita konkrétního záznamu oddělená mezerou (nižší číslo – vyšší priorita), tedy např.: 1 mxredir.wedos.net
8.1. ZKOUŠKA E-MAILU NA NEEXISTUJÍCÍ ADRESU DOMÉNĚ
Aktualizace DNS opět nějakou chvíli trvá,
takže jsem počkal cca dvě hodiny a poté
vyzkoušel nové nastavení odesláním mailu
na adresu v doméně jezisheck.cz nikdy
nedefinovanou, [email protected].
Zkrácený výpis hlaviček dokládající cestu
zprávy je vpravo.
/..zkráceno../
Received: from redir.wedos.net (redir.wedos.net [46.28.105.4])
by mx.google.com with ESMTP id
e13si394723fak.117.2011.08.03.04.33.07;
Wed, 03 Aug 2011 04:33:07 -0700 (PDT)
/..zkráceno../
Received: from arethusa2.fi.muni.cz (arethusa2.fi.muni.cz
[147.251.49.7])
by redir.wedos.net (Postfix) with ESMTP id 7993C2E86F
for <[email protected]>; Wed, 3 Aug 2011 13:33:07 +0200 (CEST)
Received: by arethusa2.fi.muni.cz (Postfix, from userid 115)
id 5B648221AE9; Wed, 3 Aug 2011 13:33:07 +0200 (CEST)
Received: by [email protected]
PID 8817 for [email protected]@mail.muni.cz;
Wed, 03 Aug 2011 13:33:07 +0200
/..zkráceno../
From: "Jakub =?UTF-8?Q?Kol=C3=A1=C5=99?=" <[email protected]>
To: [email protected]
Subject: =?UTF-8?Q?Zkou=C5=A1ka=20cesty=20e-mailu=203.1?=
/..zkráceno../
9. INSTALACE ZOPE & PLONE
Nyní mám server a okolní služby připraveny a mohu se začít zabývat instalací Plone CMS. Protože ale Plone obecně není příliš
známý, začnu krátkým uvedením, co to vlastně je.
9.1 KRÁTCE O ZOPU A PLONU 4
Plone CMS ve verzi 4 je systém správy obsahu, někdy se tyto systémy označují také jako redakční, mimořádně vhodný
k nasazení jako firemní intranet. Plone je však široce univerzální a s dostatkem zkušeností ho lze použít k jakémukoliv účelu,
kde je potřebná nebo výhodná práce odkudkoliv v Internetu a/nebo prostřednictvím webového prohlížeče.
Jádro Plonu tvoří CMF, Content Management Framework, což je rozšiřující doplněk aplikačního serveru ZOPE. Společně
s mnoha dalšími doplňky, které poskytují různé části funkcionality, tvoří Plone tak, jak ho ve výsledku vidí a pracuje s ním
uživatel.
ZOPE, nebo Zope, je označení pro Z Object Publishing Environment. Zope je aplikační server schopný poskytovat vzdálený
přístup k objektům pomocí různých protokolů, jmenujme například HTTP, FTP, WebDAV. Zope poskytuje například platformu
pro omezování přístupu k objektům i jejich jednotlivým vlastnostem na základě definovaných uživatelských oprávnění a jejich
dědění v rámci hierarchie objektů i uživatelských skupin. Plone pak poskytuje rozhraní pro správu těchto oprávnění
v přehlednější zjednodušené formě. Zope standardně používá objektovou databázi (ZODB) uloženou v souboru Data.fs.
Objektem je v rámci Zopu prakticky vše. Objekty jsou instance tříd definovaných ve zdrojových kódech Zopu, Plonu
a přídavných doplňků pomocí programovacího jazyka Python. Může to být stránka, obrázek, CSS soubor, aj.
Python je interpretovaný programovací jazyk vysoké úrovně, který je velmi dobře čitelný. Jeho syntaxe vychází z jazyka C
a Plone 4 používá jeho verzi 2.6, přestože jsou již delší dobu dostupné verze 2.7 a 3.2.
V souvislosti s Plonem, resp. Zopem, se můžeme setkat ještě s dalšími jazyky, které nebudu podrobně popisovat, ale uvedu
jen některé důležité: {ZPT = Zope Page Templates} je šablonovací systém Zope, využívá v sobě několik podjazyků: {TAL =
Template Attribute Language} umožňuje elementům stránky, aby byly naplňovány obsahem, nahrazovány, opakovány
nebo vynechávány; {TALES = TAL Expression Syntax} poskytující data pro zobrazení pomocí TAL a METAL; {METAL = Macro
Expansion TAL} je mechanismus umožňující sestavovat šablony z více částí, tzv. maker; i18n zkracuje slovo Internationalization
a v kontextu ZPT se jedná o mechanismus pro překládání částí obsahu dle aktuálního jazykového nastavení. Samostatně
vedle ZPT dále stojí {DTML = Document Template Markup Language}, což je alternativní šablonovací systém používaný v Plone
spíše pro generování JavaScriptů nebo CSS. Pro další informace a příklady nejen k těmto jazykům můžete nahlédnout do mé
prezentace o Zope a Plone v rámci Semináře webdesignu
10)
nebo si podrobnosti dohledat jinde na Internetu.
9.2 STAŢENÍ A UNIFIEDINSTALLER
Řekněme tedy, že máme ponětí co asi tak zhruba Plone a Zope je. Mým cílem v této kapitole je ukázat instalaci Plone 4
11)
k čemuž budu potřebovat instalační distribuci zvanou UnifiedInstaller, kterou najdeme na portále plone.org . Já jsem použil
12)
poslední stabilní vydání s číslem verze 4.0.7 . K instalaci Plonu je samozřejmě dostupných mnoho návodů. Pro konzistenci
13)
jsem také z jednoho vycházel .
13)
Protože návod na stránkách plone.org , je poměrně obsáhlý a přesný, zaměřím se spíše na doporučení, jakou konfiguraci
zvolit. Ačkoli návod uvádí, že některé knihovny, jako např. libjpeg a readline nejsou nezbytné, doporučuji je nainstalovat. Mnoho
místa nezaberou a Zope se je alespoň nebude snažit hledat při každém startu a zapisovat do logů, že k dispozici nejsou.
9.2.1 ZEO CLUSTER NEBO STANDALONE INSTANCE?
Podívejme se nyní na rozdíl mezi ZEO clusterem a tzv. standalone instancí. Standalone je jeden Zope server, který obstarává
jak objektovou databázi (ZODB), tak požadavky klientů (např. webového prohlížeče). V systému běží pouze jeden Zope proces,
který oproti variantě ZEO bude mít pravděpodobně menší paměťovou náročnost.
ZEO cluster je varianta, kterou vám už dnes každý zkušený Plonař doporučí a stejně tak i já. Zejména protože pozdější
přechod ze standalone instance na ZEO je poměrně obtížný a může se vyskytnout řada komplikací. ZEO cluster se skládá
ze zeoserveru, který obstarává pouze zápis do datového souboru Data.fs, kde se nachází ZODB při vypnutí serveru. Mimoto
tato data z databáze komunikuje s jednotlivými zeoklienty. Zeoklient je Zope server, podobný tomu v případě standalone
instance, který data neukládá nikam do souborového systému, ale odesílá je a načítá ze zeoserveru.
Tento princip má mnoho výhod a asi jen jedinou nevýhodu. Nevýhodou je, že každý z klientů a také zeoserver jsou spuštěny
ve vlastní instanci interpretu jazyka Python a tedy i paměťová náročnost je větší. Výhody ale toto vyváží:
1. Zeoserver může běžet na jiném stroji, čímž lze získat významný nárůst výkonu oproti standalone instanci. Mimoto
i na jednom stroji je citelný vyšší výkon díky multitaskingu.
2. Na jednom ze zeoklientů lze provozovat přístup pro koncové uživatele, zatímco na jiném se vyzkouší nebo vyvinou
nové funkce, které se na ostatních klientech neprojeví, dokud to nebude žádoucí.
3. Více zeoklientů umožňuje realizaci rozložení zátěže na více strojů, tzv. load balancing. K tomu jsou různá řešení
s různou náročností realizace i efektivitou, podstatné však je, že se standalone instancí toho není možné dosáhnout.
9.2.2 UNIFIEDINSTALLER
12)
My si ukážeme instalaci ZEO clusteru, která je mírně náročnější. Začal jsem tedy stažením a rozbalením UnifiedInstalleru .
Poté jsem se přesunul do rozbalené složky a spustil příkaz:
sudo ./install.sh --password=*** --target=/opt/Plone --instance=zeo01 --nobuildout zeo
Takto jsem UnifiedInstaller instruoval, že chci pro administrační účet (emergency user) použít heslo ***, Plone instalovat do
/opt/Plone a první ZEO cluster do složky /opt/Plone/zeo01. Zároveň jsem předal parametr, že nechci provádět buildout,
protože jej provedu až po konfiguraci jednotlivých parametrů clusteru.
9.3 NASTAVENÍ A SPUŠTĚNÍ BUILDOUTU
Buildout je nástroj koexistující s Plonem od verze 3 a zjednodušeně, slouží k postahování a instalaci doplňkových produktů
Plonu/Zopu a jejich nastavení a zároveň i k nastavení a instalaci zeoklientů. V mém případě jsem usiloval o jednoduchou
instalaci, která bude používat pouze jednoho zeoklienta a druhého, který je ve výchozím konfiguračním souboru buildout.cfg
definován, jsem se rozhod použít jako vývojového. Změny v buildout.cfg byly tedy následující:
 V sekci [buildout] jsem v direktivě zeo-address změnil port, na kterém bude zeoserver naslouchat. Konkrétní hodnota
není podstatná. Není jej potřeba povolovat ve firewallu, protože klienti poběží na stejném stroji.
 Ve stejné sekci jsem změnil porty zeoklientů (direktivy http-address a client2-address) na 8081 a 8082.
 Protože standardní buildout nepředpokládá různé nastavení direktiv debug-mode napříč klienty, zavedl jsem nové
client2-debug-mode, client2-deprecation-warnings, client2-verbose-security a všechny nastavil na on.
Protože jsem zavedl nové direktivy v buildout.cfg, musel jsem upravit i soubor base.cfg, konkrétně sekci [client2],
kde jsem změnil následující:
Šlo jen o to, aby se vývojový režim dal nastavovat
pro každého zeoklienta zvlášť.
debug-mode = ${buildout:client2-debug-mode}
verbose-security = ${buildout:client2-verbose-security}
deprecation-warnings = ${buildout:client2-deprecation-warnings}
Nastaveno tedy mám a přichází na řadu spuštění buildoutu. To mi vytvoří zeoklienty dle nastavení, nastaví zeoserver,
nainstaluje Plone, popřípadě by to stáhlo nějaké doplňkové produkty, ale v tuto chvíli si vystačím s holým Plonem.
Příkaz je sudo ./bin/buildout. Je velmi důležité, aby pracovní byl adresář instance, v mém případě /opt/Plone/zeo01.
Buildout proběhne a něco vypíše. Dokud ale úspěšně skončí, nejsou případné vypsané chyby problémem.
9.4 PRVNÍ SPUŠTĚNÍ
Přestože buildout a UnifiedInstaller jsou navržené tak, aby instalaci co nejvíce usnadnily, téměř pokaždé něco chybí. Ve verzi
Plone 4.0.7 konkrétně chybí nastavení vlastníka na uživatele plone, pod kterým démony ZEO běží, pro složku a soubory
/opt/Plone/zeo01/var. V této složce se nachází soubor se ZODB, takže tam zmíněný uživatel potřebuje práva zápisu. Také jsou
tam logy a vůbec je to jediná složka, kam ZEO zapisuje.
Po úpravě práv už je možné spustit ZEO sudo ./bin/zeoserver start a poté prvního klienta, napoprvé raději
na popředí příkazem sudo ./bin/client1 fg. Na popředí, abych viděl případné problémy vypsané v konzoli a nemusel je
hledat v logu. Pokud se objeví INFO Zope Ready to handle requests, je všechno v pořádku. Ctrl + C zeoklienta vypne a pomocí
sudo ./bin/client1 start už server spustím normálně, na pozadí.
Nyní mám zeoklienta č. 1 poslouchajícího na adrese http://31.31.73.20:8081. Na tento port mě ale firewall v současné
době nepustí. Buď bych mohl nastavit Apache, aby provoz určité subdomény směrovat on na tento port a v tom případě
bych firewall mohl nechat být, ale protože nechci přeskakovat z jedné věci na druhou, udělám to později. Nyní jsem tedy
dočasně povolil port 8081 pro TCP spojení. Dočasně, protože tímto způsobem nelze komunikaci šifrovat pomocí SSL.
10. VYTVOŘENÍ INSTANCE PLONE
Od Plone 4 je instalace natolik přívětivá, že po přechodu na adresu http://31.31.73.20:8081 se nezobrazuje informační
stránka ZMI (Zope Management Interface), ale jednoduchá stránka s logem Plonu a tlačítkem pro vytvoření prvního portálu.
Portálem myslí objekt typu Plone Site, což je vlastně jedna instance Plonu. Doteď jsem hovořil pouze o instancích Zope.
Po kliknutí na tlačítko a zadání loginu (admin) a hesla (to je to heslo předané jako parametr UnifiedInstalleru) se zobrazí
formulář vyžadující pouze id portálu. Bude to identifikátor portálu v rámci instance Zope. Já jsem zvolil id plone (s malým
počátečním písmenem, aby toto jméno později mohlo korespondovat s doménou třetí úrovně, plone.jezisheck.cz).
Pak už jsem jen vyplnil volitelné políčko jména portálu.
10.1 PRVOTNÍ NASTAVENÍ
Instance Plone 4 je po vytvoření dobře zabezpečena ve srovnání s dřívějšími verzemi, kde byla standardně umožněna
registrace nových uživatelů a každému z nich se vytvořila domovská složka, kam mohl okamžitě umisťovat obsah. Toho někdy
využívali různí útočníci. V Plone 4 je ale tato samostatná registrace standardně zakázána, stejně jako domovské složky.
Jako nezbytné po vytvoření portálu vidím nastavení SMTP serveru (adresa/@@mail-controlpanel) a vytvoření
správcovského účtu, abychom se nepřihlašovali jako emergency user admin (adresa/@@new-user). Ve formuláři je důležité
zaškrtnout políčko pro přidání uživatele do skupiny Administrators.
Mám tedy vytvořen ukázkový portál s id plone. Obdobně jsem si vytvořil ještě další portál s id blog, kde hodlám provozovat
osobní fotoblog.
11. SCHOVÁNÍ PLONE ZA APACHE A ZABEZPEČENÍ KOMUNIKACE POMOCÍ SSL
Protože Zope server sám o sobě nepodporuje šifrování komunikace přes SSL a také protože nechci uvádět v adresách na
Plone číslo portu, na kterém Zope poslouchá, a v neposlední řadě protože standardní port HTTP 80 je používán pro statické
HTML a PHP stránky, je výhodné postavit Zope za Apache. Ten bude působit jako proxy server předávající HTTP požadavky
na určitou podmnožinu adres na Zope server a zároveň může komunikaci šifrovat přes SSL. Volitelně je možné Apache použít
například i pro kompresi a cachování obsahu.
14)
Jako obvykle, na Internetu je k dispozici řada návodů, jak toho docílit. Já jsem vybral návod hostovaný na plone.org .
Proces má dvě části. Nejprve povolíme potřebné moduly Apache a poté už jen nadefinujeme příslušné VirtualHosty.
11.1 PŘÍPRAVA APACHE
Návod mluví sám za sebe, uvedu tedy, které moduly Apache jsem povolil: mod_headers, mod_mime_magic, mod_proxy,
mod_proxy_http a mod_rewrite. Dále jsem jen vypnul cachování v konfiguračním souboru proxy.conf, protože nemám rád,
když se mi při vývoji, který mám v plánu, cokoli cachuje. Podporu pro SSL jsem nastavil v Oddíle 6.5, přeskočil jsem tedy
i tu část návodu věnující se konfiguraci SSL.
11.2 PŘIDÁNÍ VIRTUALHOSTŮ
Ukažme si konfiguraci VirtualHostu za účelem šifrování přístupu do ZMI, protože to je jedno z nejcitlivějších míst.
Zde se přihlašuje pomocí hesla emergency uživatele a pokud by mě někdo odposlechnul toto heslo, může si s takovou instancí
Zope dělat téměř co chce.
Abych tedy zakázal nešifrovaný přístup ke
kořeni ZMI, vytvořil jsem ve složce pro sites
/etc/apache2/sites-available konfigurační
soubor pro subdoménu zmi.jezisheck.cz
se stejným názvem, přidal do něj kód vpravo,
tuto site povolil a nechal Apache načíst
konfiguraci.
Významné části kódu jsou zvýrazněny
tučně. Jde prakticky jen o přesměrování
veškeré komunikace na protokol HTTPS.
Na https://zmi.jezisheck.cz/ však
ještě nemám definovaný VirtualHost.
<VirtualHost *:80>
ServerName zmi.jezisheck.cz
CustomLog ${APACHE_LOG_DIR}/access-logs/zmi.jezisheck.cz.log combined
ErrorLog ${APACHE_LOG_DIR}/error-logs/zmi.jezisheck.cz.log
LogLevel warn
Redirect /
https://zmi.jezisheck.cz/
<IfModule mod_proxy.c>
ProxyVia On
# prevent the webserver from beeing used as proxy
<LocationMatch "^[^/]">
Deny from all
</LocationMatch>
</IfModule>
</VirtualHost>
Pro HTTPS jsem tedy
musel přidat zvláštní
VirtualHost:
Kromě určení SSL
certifikátu je zde důležité definovat přepisovací pravidlo, které zajistí vnitřní přesměrování HTTP požadavků
na Zope.
Povšimněte si také,
že komunikace v rámci
localhostu je nešifrovaná a Zope se doménu,
na kterou byl požadavek zaslán, dozví díky
%{SERVER_NAME}.
Nyní jsem také zakázal komunikaci na portu 8081, povolenou
v Oddíle 9.4.
<VirtualHost *:443>
ServerName zmi.jezisheck.cz
CustomLog ${APACHE_LOG_DIR}/access-logs/zmi.jezisheck.cz_ssl.log combined
ErrorLog ${APACHE_LOG_DIR}/error-logs/zmi.jezisheck.cz_ssl.log
LogLevel error
SSLEngine on
SSLCertificateFile
/etc/apache2/ssl/any.jezisheck.cz.crt
SSLCertificateKeyFile /etc/apache2/ssl/any.jezisheck.cz.key
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^/(.*) \
http://localhost:8081/VirtualHostBase/https/%{SERVER_NAME}:443/VirtualHostRoot/$1 [L,P]
</IfModule>
<IfModule mod_proxy.c>
ProxyVia On
# prevent the webserver from beeing used as proxy
<LocationMatch "^[^/]">
Deny from all
</LocationMatch>
</IfModule>
BrowserMatch "MSIE [2-6]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
# MSIE 7 and newer should be able to use keepalive
BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
</VirtualHost>
</IfModule>
Ukažme si ještě, jak vypadá zkrácená konfigurace domény plone.jezisheck.cz pro portál s id plone, kde chci povolit
provoz jak přes HTTP tak i HTTPS, ale pro přihlašování chci vynutit použití HTTPS. Důležité části jsou zvýrazněny tučně.
Přihlašovací formulář Plonu je na adrese ./login_form a stejně tak se objevuje i těsně po odhlášení na ./logged_out.
Protože tentokrát požadavky nesměřujeme na kořen Zope serveru jako v případě zabezpečení ZMI, přibyl za číslo portu
a adresu domény
<VirtualHost *:80>
i identifikátor da/...zkráceno.../
ného portálu.
RewriteEngine On
Obdobně jsem
provedl nastavení i pro další portál s id blog.
# Vynuceni prihlaseni pres SSL
RewriteRule ^/login_form(.*) \
https://%{SERVER_NAME}/login_form$1 [L,R]
RewriteRule ^/logged_out(.*) \
https://%{SERVER_NAME}/logged_out$1 [L,R]
http://localhost:8081/VirtualHostBase/http/%{SERVER_NAME}:80/plone/VirtualHostRoot/$1 [L,P]
</IfModule>
/...zkráceno.../
</VirtualHost>
<VirtualHost *:443>
/...zkráceno.../
RewriteEngine On
http://localhost:8081/VirtualHostBase/https/%{SERVER_NAME}:443/plone/VirtualHostRoot/$1 [L,P]
</IfModule>
/...zkráceno.../
</VirtualHost>
</IfModule>
12. LADĚNÍ DETAILŮ
Myslím, že je opět čas na malou rekapitulaci. Kromě funkčního LAMP serveru už mám připravenu i instanci ZEO clusteru
se dvěma portály Plone. Tuto instanci mám chráněnou proti odposlechu hesel díky vynucení šifrované komunikace
pro přihlášení do obou portálů a pro práci v ZMI. Nyní ukážu ještě několik drobných vylepšení, které jsem provedl.
Nejdříve vytvořím svou vlastní certifikační autoritu pro podepisování SSL certifikátů, poté vynutím přístup na doménu
jezisheck.cz vždy bez subdomény www, nastavím vlastní chybové stránky pro běžné chybové stavy HTTP (404, 500, aj.),
nastavím automatické spouštění ZEO clusteru při startu operačního systému a nakonec nastavím možnost přístupu na portály
Plone kromě vlastní subdomény také přes podsložku v doméně jezisheck.cz.
12.1 VYTVOŘENÍ CERTIFIKAČNÍ AUTORITY
SSL certifikát podepsaný sám sebou je sice snadné vytvořit i používat, ale prohlížeče se uživatele budou neustále snažit
varovat o tom, že je neplatný. Ve Firefoxu lze udělit bezpečnostní výjimku, ale například Chrome nic takového neumožňuje.
Vzhledem k tomu, že ale budu k administračním rozhraním přistupovat obvykle ze svého počítače, mohu tento problém vyřešit
vytvořením vlastní certifikační autority (CA), její certifikát nainstalovat do systému a do Firefoxu a SSL certifikáty podepsané
touto certifikační autoritou poté budou považovány za důvěryhodné.
8)
Pro vytvoření CA jsem využil již jednou zmiňovaný návod v Ubuntu Server Guide . Poté jsem musel oba používané SSL
certifikáty, pro jezisheck.cz a *.jezisheck.cz, znovu vytvořit. Nejprve tedy vytvořit tzv. Certificate Signing Request
(CSR) a poté je podepsat ještě klíčem CA.
12.2 ZAKÁZÁNÍ SUBDOMÉNY WWW
Jelikož se mi líbí používání adres bez výchozí subdomény www (adresy jsou pak o něco kratší), pomocí
mod_rewrite jsem vynutil používání těchto kratších adres
pomocí direktiv vpravo.
Aby toto přesměrování fungovalo i pro protokol HTTPS,
musel jsem pro tento případ vytvořit zvláštní VirtualHost
obsluhující pouze www.jezisheck.cz:443. Zde mi
k přesměrování postačil jednoduchý Redirect vpravo
RewriteEngine On
RewriteCond %{HTTP_HOST}
RewriteCond %{HTTP_HOST}
RewriteRule ^/(.*)
</IfModule>
Redirect /
!^jezisheck\.cz [NC]
!^$
http://jezisheck.cz/$1 [L,R]
https://jezisheck.cz/
12.3 CHYBOVÉ STRÁNKY (404, 500, AJ.)
Pro hlavní doménu jezisheck.cz jsem vždy používal vlastní chybové stránky pro obvyklé chybové kódy HTTP 401 (chyba
autentizace), 403 (zakázaný přístup), 404 (nenalezeno) a 500 (vnitřní chyba serveru).
HTML kód a pomocné soubory jsem zkopíroval při přenášení dat ze starého
webhostingu a jejich použití dosáhl uvedením direktiv vpravo v rámci VirtualHostů
pro jezisheck.cz:80 a jezisheck.cz:443.
ErrorDocument
ErrorDocument
ErrorDocument
ErrorDocument
401
403
404
500
/401.html
/403.html
/404.html
/500.html
12.4 VYTVOŘENÍ SPOUŠTĚCÍHO SOUBORU PRO PLONE
Jelikož Zope servery jsou programy jako každé jiné, ale je vhodné, aby se spouštěly po startu systému, systém se potřebuje
nějak dozvědět, jakým způsobem je spustit a vypnout. K tomu slouží skripty v /etc/init.d. Detailní postup včetně vzorového
15)
spouštěcího souboru lze najít na plone.org . Ačkoli je určen pro Plone 3, do verze 4 se ve způsobu spouštění nic nezměnilo.
12.5 UMÍSTĚNÍ INSTANCE PLONE KROMĚ DOMÉNY I DO SLOŢKY
V rámci usnadnění své paměti jsem zřídil i přesměrování adres začínajících jezisheck.cz/plone a jezisheck.cz/blog
na příslušné subdomény plone.jezisheck.cz a blog.jezisheck.cz. Postačily k tomu jednoduché direktivy Redirect.
Také přesměrovávám jezisheck.cz/+
Redirect /+
https://plus.google.com/u/0/108877585913487837654
Redirect /plone
http://plone.jezisheck.cz
na svůj profil v sociální síti Google+.
Redirect /blog
http://blog.jezisheck.cz
To vše jak pro HTTP, tak i HTTPS.
Tímto považuji konfiguraci za dokončenou a VPS připravený k použití.
13. SHRNUTÍ ZÍSKANÝCH ZKUŠENOSTÍ
V průběhu vypracování této práce jsem měl příležitost přijít do kontaktu s velkým množstvím technologií. S některými
jsem měl větší nebo menší zkušenosti již z dřívějška, ať už jako uživatel nebo vývojář webových aplikací. Za obzvlášť přínosné
osobně považuji rozšíření zkušenosti s generováním SSL certifikátů. Úplnou novinkou pro mě byla tvorba a použití certifikační
autority. S instalací a použitím mod_rewrite jsem taktéž neměl téměř žádné zkušenosti, stejně tak celá instalace LAMP serveru
v prostředí Linuxu. Na druhou stranu jsem měl zkušenosti s LAMP serverem z prostředí Windows, protože ten jsem často
používal, když jsem se učil PHP.
Co se týká instalace Plone, ta již pro mě byla z velké části rutinní záležitostí. Naopak konfigurace Apache, aby fungoval jako
front-end Zopu byla pro mě věcí zcela novou, ale v podstatě jsem si potvrdil svůj předpoklad, že to není nic složitého.
Novinkou pro mě byla také práce s DNS záznamy a s ní úzce související definice VirtualHostů serveru Apache.
SLOVNÍČEK POUŢÍVANÝCH POJMŮ A ZKRATEK
Abecedně řazený seznam pojmů. (Pro přesné definice použijte Wikipedii)
o Apache = HTTP server (ve verzi 2)
o IP = Internet Protocol (verze 4)
o AWS = Amazon Web Services
o JavaScript = skriptovací jazyk pro prostředí
o Buildout = nástroj instalace a nastavení Zope/Plone
webového prohlížeče
o CA = Certification Authority
o LAMP = Linux + Apache + MySQL + PHP
o CMS = Content Management System
o Locale = soubor pravidel pro formátování dat,
o Cloud – viz Cloud computing (na wiki)
měny, čísel a jiných podle jazykových zvyklostí
o CSS = Cascading Style Sheets
o MySQL = databázový server (ve verzi 5)
o Debian = jedna z distribucí systému Linux
o NameServer = primární DNS server spravující
o DNS = Domain Name System
o Firewall = software systému Linux pro omezení
dostupných síťových rozhraní
o HTTP = Hypertext Transport Protocol
o HTTPS = HTTP-over-SSL
o ICMP = Internet Control Message Protocol
záznamy dané domény
o OS = operační systém
o PHP = Hypertext Preprocesor (ve verzi 5)
o phpMyAdmin = webový nástroj napsaný v PHP
pro správu MySQL databází
o Plone může vyjadřovat jak CMS aplikaci, tak i jednu
o Internet s velkým I je myšlen jako konkrétní
její instanci neboli portál.
celosvětová síť počítačů, ne jako typ sítě.
o Postfix = Mail Transfer Agent
o Produkt Plone představuje balíček softwaru, který
rozšiřuje nebo upravuje funkce Plone CMS, které
obvykle nelze upravit jinak než zásahem do
zdrojového kódu funkce
o Ubuntu = jedna z distribucí Linuxu vycházející
z Debianu
o VirtualHost = autonomní jednotka Apache serveru,
obvykle pro jednotlivé domény
o SMTP = Simple Mail Transfer Protocol
o VPS = Virtual Private Server
o Souborový server = služba poskytující možnost
o Webmin = webový nástroj pro pohodlnější ovládání
vzdáleného nahrávání a stahování souborů
o SSH = Secure Shell
některých vlastností systému Linux
o ZEO cluster je soustava jednoho a více zeoklientů
o SSL = Socket Secure Layer
(Zope) připojujících se k jednomu zeoserveru,
o Standardní webhosting = webhostingu typu LAMP
který poskytuje a přijímá pouze data k uložení
o Subdoména = doména 3. řádu
do databáze.
o sudo = softwarový balík umožňující spustit jeden
příkaz s oprávněním superuživatele
o PuTTy = program pro Windows umožňující mimo
jiné emulovat terminál systému UNIX po SSH
o ZMI = Zope Management Interface
o ZODB = Zope Object DataBase
o ZOPE = Z Object Publishing Environment
(webový aplikační server)
o Python = programovací jazyk (verze 2.6)
ODKAZY
0) http://creativecommons.org/licenses/by-nd/3.0/cz/
(Creative Commons Uveďte autora-Nezasahujte do díla 3.0 Česko)
1) http://www.cesky-hosting.cz/
2) http://aws.amazon.com/free/
3) http://hosting.wedos.com/cs/virtualni-servery.html
4) http://www.savana.cz/webhosting/popis-webhostingu/
5) http://www.webmin.com/deb.html
6) https://help.ubuntu.com/community/ApacheMySQLPHP
7) https://help.ubuntu.com/10.10/serverguide/C/postfix.html
8) https://help.ubuntu.com/10.10/serverguide/C/certificates-and-security.html
9) http://onlamp.com/onlamp/2008/03/04/step-by-step-configuring-ssl-under-apache.html
10) http://www.fi.muni.cz/~xobsivac/PV219/prezentace11/zope+plone.pdf
11) http://plone.org/products/plone/releases
12) http://launchpad.net/plone/4.0/4.0.7/+download/Plone-4.0.7-UnifiedInstaller-Hotfix20110622.tgz
13) http://plone.org/documentation/manual/installing-plone
14) http://plone.org/documentation/kb/plone-apache
15) http://plone.org/documentation/kb/startup-script-for-debian
INFORMACE O AUTORSTVÍ A LICENCI
Tato seminární práce vznikla v rámci studia předmětu Masarykovy univerzity PV219: Seminář webdesignu v semestru jaro 2011.
Název: Přechod z LAMP webhostingu na VPS + instalace Plone 4 a dalších služeb v doméně Jezisheck.cz
Autor: Jakub Kolář, e-mail: [email protected], e-mail: [email protected], web: jezisheck.cz
Verze: č. 1 ze 4. 8. 2011
Tato práce je licencována pod licencí Creative Commons Uveďte autora-Nezasahujte do díla 3.0 Česko (CC BY-ND 3.0),
která vás, zjednodušeně řečeno, opravňuje k šíření díla (kopírování, distribuci a uveřejňování) a také ke komerčnímu využití
za podmínky, že uvedete autora (resp. neodstraníte informace i autorovi) a do díla nebudete nijak zasahovat. Zároveň
nesmíte toto dílo nebo jeho část použít v jiném díle.
Pro bližší informace o licenci navštivte následující stránku: http://creativecommons.org/licenses/by-nd/3.0/cz/
a/nebo si prostudujte plné znění této licence zde: http://creativecommons.org/licenses/by-nd/3.0/cz/legalcode

Přechod z webhostingu na VPS + instalace Plone 4 a dalších služeb

Transkript

Podobné dokumenty

taháci - Vrstevnice

PDF verze

strana - Ostravice

Prezentace aplikace PowerPoint

Cloudové technologie a jejich využití - Česko

Webový server - Hroch

02 - Konfigurace httpd Apache, testování Image: y36aws-apache