Rozwiązanie znajduje się tutaj: http://beconfused.com/2007/08/28/how-to-solve-you-do-not-have-sufficient-permissions-to-access-this-page-in-wordpress/

1. posiada poza stopami WIBOR, LIBOR (CHF, USD, EUR, JPY) i EURIBOR;
2. posiada także ostatnie kursy kupna/sprzedaży walut według NBP dla CHF, USD, EUR i JPY;
3. wylicza kredyt w walucie obcej.

Oczywiście, nie daje sobie paznokci nawet obciąć, że działa prawidłowo :-) Ale doświadczenie pokazuje, że w przypadku złotówek sprawował się znakomicie.

Wszelki feedback mile widziany. Źródeł nie udostępniam :P

Zainteresowanych przetestowaniem, zapraszam tutaj.

Pakiet BitTornado zawiera co prawda w sobie bttrack.py, niestety jest to kolejna usługa którą trzeba uruchamiać i pilnować. Sam protokół trackera podpiera się HTTP. W taki sposób powstało na przykład TBSource – który jest najpopularniej używanym zamkniętym trackerem i nie dam sobie ręki obciąć czy nie jedynym.

Powyższy jest stary jak świat i pewnie nie jest wolny od wad. W dodaktu, co tracker, to inaczej zmodyfikowany. Konkurencji na „rynku” wprowadzać nie zamierzam, ale przejżenie kodu pozwoliło mi na napisanie małego co-nieco. Co prawda nadal nie wiem czy jest sens udostępniania tego komukolwiek. Osoby które są poważniej zainteresowane tematem, napiszą po swojemu na podstawie dostępnego TBSource, a pozostali tylko zamęczą mnie pytaniami, po czym w końcu i tak zainstalują sobie wspomniane TBSource.

Jest tego sporo. Przynajmniej w PHP (fanów ROR i innych dziwnych rozwiązań proszę o powstrzymanie się od komentarzy). Ale od początku. Moje wymagania są, powiedzmy, dosyć spore. Bo ja nie chcę mieć tylko bloga. Poza wylewaniem swoich żali na cały świat chciałbym się podzielić z ludźmi także tym, że mam nowego pryszcza na nosie (galeria zdjęć), śmiesznymi filmikami które i tak każdy zna (wstawianie YT i nie tylko, najlepiej handler do FLV pełny), zrobić na swojej stronie wareza (file/download manager) i wiele, wiele innych rzeczy.

A wybór, mimo że spory, to pozostawia wiele do życzenia. Jeżeli chodzi o samo blogowanie, to jest super. WordPress wraz z softem obsługującym BloggerAPI i pochodne jest super. Ale tutaj zabolało mnie zarządzanie stronami. Dobrze by było przecież te stare teksty gdzieś umieścić żeby ktoś biedny i w potrzebie sobie zajrzał. Niestety nie ma dobrego i aktualnego spolszczenia do WordPressa. I nie chodzi mi tutaj o interfejs administracyjny, ale o szablony. Aby uruchomić to co widzisz, musiałem się trochę jednak nagrzebać w kodzie szablonów (czy developerzy WP widzieli kiedyś Smarty?) i pozmieniać teksty. Powód jest prosty – ostatnie spolszczenie obejmowało AFAIR WP w wersji 2.2, a mamy już 2.5.

Po fascynacji WordPressem zaatakowałem Drupala. Tutaj totalna porażka. Drupal jest kombajnem jakich mało. Developerzy chyba nie do końca wiedzieli co chcą osiągnąć. Tak im wyszedł soft który jest do wszystkiego a finalnie nadaje się do niczego. Zasób szablonów Drupala jest bardzo mały (ja wiem że mogę sobie zrobić sam, ale po co skoro są dostępne jakieś za darmo). Bardzo rozbudowane API do modułów pozwala na tak dużo rzeczy, że jego udokumentowanie przerosło twórców a i połapać się w tym jest dosyć ciężko. Najnowsza wersja ma w ramach bonusa zmienione API, więc modułów jak na lekarstwo.

Po tych dwóch systemach zerknełem jeszcze na kilka innych, ale na dzień dobry mnie to wszystko odrzucało. Myślałem nad napisaniem czegoś swojego – w końcu jest naprawdę bardzo dużo niezłych frameworków do PHP, ale chroniczny brak czasu, reforma, itp. Tym bardziej, że jeżeli chodzi o moją stronę, to zawsze jakoś wyznawałem zasadę, że najlepszym edytorem treści jest VIM, a backendem do przechowywania contentu jest CVS lub SVN.

W przypadku baseciq.org finalne pewnie się skończy (a właściwie, już się skończyło) na rozdzieleniu bloga od starych tekstów, odpaleniu gdzieś z boku galerii (w tzw. „międzyczasie”). Zresztą, jak już napisałem, samo przetrwanie bloga stoii pod znakiem zapytania.

Protokół HTTP, którego każdy z nas używa na codzień, pozwala nam na robienie wirtualnych hostów WWW, czyli na jednym serwerze WWW i jednym adresie IP umieszczenie kilku niezależnych od siebie stron WWW. Konfiguracja czegoś takiego jest bardzo prosta. Z góry jednak przepraszam za toporność tego tekstu – nie mam nastroju na lanie wody dzisiaj ;-)… Poza tym jak zwykle opisuje on najprostszy sposób wykonania vhostów jak i tylko podstawowe możliwości apache’a w tym zakresie.

Chciałbym przypomnieć także, iż każdy vhost (domena) musi być oczywiście skonfigurowana w danej domenie. Tzn. ja dzisiaj jeszcze kawy nie piłem i nie wiem jak to napisać aby każdy zrozumiał. Poprostu jeżeli wszystko skonfigurowałeś, a niestety nowe wychuchane i wypucowane vhosty Ci nie chodzą, wykonaj komendę „host mój.nowy.kochany.vhost.pl” – jeżeli ta komenda nie zwróci jakiejś nazwy albo adresu to już masz źródło swoich błędów. Jeżeli nie wiesz o czym tutaj bredzę, poprostu idź i poczytaj o dns i spróbuj ponownie ;)

Na początek musimy odnaleźć plik httpd.conf. Najczęściej jest to plik /etc/apache/httpd.conf (Slackware 8, Mandrake i Redhat) lub /etc/httpd/httpd.conf (PLD, starsze RH i MDK). Inne możliwe lokalizacje to: /etc/httpd.conf, /etc/www/httpd.conf, /var/lib/apache/conf/httpd.conf (Slackware 7.1, 7.0), /usr/local/apache/conf/httpd.conf (Apache ze źródeł). Domyślnie, apache ma zdefiniowany główny katalog www dyrektywą DocumentRoot, np:

DocumentRoot "/var/www/htdocs"

Zasada działania.

Po zdefiniowaniu konkretnego adresu IP jako adresu do wirtualek zaczyna on inaczej funkcjonować niż pozostałe adresy. Otóż w tym momencie dla tego adresu IP nie obowiązuje globalnie zdefiniowany DocumentRoot, tylko pierwsza zdefiniowana wirtualka. Czyli, jeżeli ktoś się odwoła do tego adresu IP do nazwy nie zdefiniowanej jako wirtualka, zostanie mu wyświetlona zawartość pierwszej wirtualki. Na pozostałych adresach nadal domyślną stroną www będzie ta z katalogu podanego w dyrektywie DocumentRoot. Teraz przykład. Mój serwer posiada adres IP 217.8.186.57. Chciałbym, aby każdy odwołujący się do tego adresu IP widział moją stronę, oraz chciałbym do tego dorzucić parę wirtualnych hostów. Robię więc tak:

#
# Definuje że 217.8.186.57 jest adresem ip na którym będę robił vhosty:
#

NameVirtualHost 217.8.186.57

#
# Teraz zdefiniujemy główną wirtualkę:
# Wirtualka ta się zowie www.baseciq.org, a jej główny katalog
# jest u mnie w katalogu domowym w public_html
#

<VirtualHost 217.8.186.57>
ServerName www.baseciq.org
DocumentRoot /home/users/baseciq/public_html
ServerAdmin baseciq@baseciq.org
</VirtualHost>

#
# Na swojej stronie mam trochę plików, udostępnie je pod
# adresem http://ftp.baseciq.org/
#

<VirtualHost 217.8.186.57>
ServerName ftp.baseciq.org
DocumentRoot /home/users/baseciq/public_html/files
ServerAdmin baseciq@baseciq.org
</VirtualHost>

#
# O, i jeszcze jeden taki malutki vhost ;>
#

<VirtualHost 217.8.186.57>
ServerName radded.baseciq.org
DocumentRoot /home/users/baseciq/public_html/radded
ServerAdmin baseciq@baseciq.org
</VirtualHost>

Oczywiście możemy zrobić teraz wirtualki na innych adresach ip o ile je posiadamy. Poprostu dopisujemy kolejne NameVirtualHost [adresip] i pod nim na takich samych zasadach wirtualki dla następnego adresu IP. Można także zdefiniować kilka nazw wskazujących na jeden katalog, na przykład chcemy zrobić writualkę www.domena.pl i domena.pl. Wtedy zamiast robienia kiku wpisów z wirtualkami tworzymy jeden z dyrektywą ServerAlias:

<VirtualHost 213.25.209.99>
ServerName domena.pl
ServerAlias www.domena.pl
DocumentRoot /var/www/vhosts/domena.pl
ServerAdmin webmaster@domena.pl
</VirtualHost>

Dzięki temu mamy jako taki porządek w httpd.conf

Opisany powyżej wycinek httpd.conf z mojego serwera można obejrzeć w akcji:

http://www.baseciq.org/ – podstawowa wirtualka,

http://ftp.baseciq.org/ – druga wymieniona wirtualka,

http://radded.baseciq.org/ – trzecia wirtualka.

Tych wirtualek nie ma, ale po wejściu na nie zostanie wam wyświetlona podstawowa strona tego adresu ip (poniższe hosty wskazują na 217.8.186.57):

http://217.8.186.57/ – tutaj oczywiście sam adres a nie host ;)

http://baseciq.zacisze.org/ (to Arek sobie dopisał :))

http://baseciq.drzwi.org/ (a to mam od Neas’a)

Generalnie 217.8.186.57 jest dodatkowym adresem serwera. Na pozostałych adresach tej maszyny (ma ona dwie karty sieciowe i co za tym idzie dwa adresy z sieci lan) obowiązuje normalne DocumentRoot.

Do VirtualHost można dorzucić kilka ciekawych rzeczy. Praktycznie każda dyrektywa główna apache’a da się zastosować lokalnie w ramach <VirtualHost IP> – </VirtualHost>. Zresztą te 3 dyrektywy których użyłem powyżej są normalnie wykorzystywane w „głównej” części konfiguracji. I tak, można na przykład dopisać w obrębie wirtualki:

CustomLog /home/users/baseciq/logi/www.log combined

Spowoduje to iż wywołania do wirtualki będą logowane do pliku www.log w moim katalogu domowym w podkatalogu ‘logi’.

ErrorDocument 404 /index.php?error=404
ErrorDocument 403 /error403.html
ErrorDocument 401 /error404.html
ErrorDocument 500 /error500.html

Spowoduje to iż zamiast ogólnych komunikatów błędów dla tej wirtualki będą wyświetlane pliki /home/users/baseciq/public_html/error???.html (zakładając że DocumentRoot wirtualki to /home/users/baseciq/public_html).

Opcji tych jest prawie tyle samo co głównych dyrektyw apache’a (niektórych poprostu nie da się użyć). Jednak uważam iż ten art nie jest miejscem na ich szczegółowe opisywanie.

Na koniec oczywiście pozostaje nam zrestartować apache’a. Użytkownicy RedHatów, Mandrakeów i innych podobnych dystrybucji piszą: /etc/rc.d/init.d/httpd restart (lub apache restart). W Slackware jest to /var/lib/apache/bin/apachectl restart (7.0, 7.1) lub /usr/sbin/apachectl restart.

Jeszcze taka mała uwaga na koniec. Nie denerwujcie się że wam czasami nie wychodzi wirtualka mimo poprawek… Poprostu wyłączcie proxy i wyczyśćcie cache przeglądarki, co nie sebek? :)))