vermin.eu.org

Zmusiłem się w końcu i po dłuższym czasie podniosłem wersję używanej platformy blogowej z 2.1 do 2.3. Obawiałem się tego upgradu - wersja 2.3 wymagała zmian w bazie danych, do tego część wtyczek nie działała. Niemniej wszystko odbyło się szybko i zaskakująco bezstresowo. Bardzo spodobało mi się automatyczne wykrywanie nowych wersji wtyczek przez WP. Tego mechanizmu mi brakowało mocno, kiedy wcześniej zabierałam się do aktualizacji. Niemniej i tak muszę ciut poskakać po stronach autorów wtyczek (ponieważ nie wszystkie znajdują się na WP), ale to i tak jest duże ułatwienie. Już całkiem przy okazji zmieniłem layout na lżejszy i bardziej przejrzysty. Na dodatek dwukolumnowy sidebar pozwoli łatwiej i sprawniej widzieć co się zmieniło na blogu (chociaż i tak większość czytelników czyta feed a nie wchodzi bezpośrednio na stronę).

Co ponadto? No cóż - teraz będzie trzeba otagować jakoś dotychczasową zawartość, przemyśleć istniejącą taksonomię wpisów - co powinno być tagiem a co kategorią. Właściwie z definicją tego mam pewien problem, bo niektóre kategorie równie dobrze mogłyby być tagami i vice versa. Z chęcią usłyszałbym jak to (kryteria) u siebie ustaliliście albo jakie macie pomysły? Podobnie jeśli chodzi o tagi mam mętlik w głowie co tagiem powinno być a co nie, czy są jakieś przyjęte formy tagów albo systemy (wtyczka do WP) proponujące tagi do wpisu? Coś takiego miał niesławny Ultimate Tag Warrior. Pewnie to tagowanie wyjdzie w praniu

Swego czasu, w odległej wersji wordpressa, której daleko było do tagowania, uaktywniłem wtyczkę Utlimate Tag Warrior. Kilka wpisów otagowałem, a potem w zasadzie stwierdziłem, że stosowana przeze mnie taksonomia wpisów w pełni oddaje to co robię, więc pozbawione jest sensu dodatkowe tagowanie. Jakiś czas potem, przy upgradzie wersji, wyłączyłem wtyczkę i nie włączyłem jej ponownie.
Dziś, przeglądając dokładnie bazę danych wordpressa zwróciłem uwagę na dwie duże tabele - pierwsza z nich to standardowa [wp]_postmeta, druga to zależna od wtyczki slimstats [wp]_slim_stats. O ile potrafię zrozumieć wielkość drugiej tabeli (chociaż to i tak przesada - czas przesiąść się na google analytics czy podobne darmowe urządzonko - hints anyone?), to ta pierwsza mnie moooocno zaskoczyła.
Co ciekawsze, pomimo setek tysięcy wpisów, większość z nich posiadała wartość klucza meta_key = ‘_utw_tags_0′. Chwila spędzona w wyszukiwarce zwróciła winowajcę - wspomnianego w tytule UTW. Okazuje się, że nieszczęsny UTW dla postów, które nie zostały otagowane przy każdym odświeżeniu dokonywał właśnie takiego wpisu. Cóż, DELETE FROM [wp]_metadata WHERE meta_key = ‘_utw_tags_0′ spowodowała radykalne zmniejszenie wielkości tabeli z paruset tysięcy wpisów do (po usunięciu wpisów z wtyczki WP Post Views) 5. Niemniej nigdy więcej nie wykonam OPTIMIZE TABLE ani podobnej operacji bez wcześniejszego backupu tablicy. Trochę ‘za dobrze’ działają takie operacje usuwając także potrzebne dane :/

P.S. Ewentualne informacje (które potem przerzucę jako komentarze) na temat systemów mierzenie wielkości ruchu proszę przesyłać na adres: vermin w domenie bloga.

Niestety, baza danych wykorzystywana w posiadanym przeze mnie hostingu ma tendencje do częstego krzaczenia jednej z tabel - konkretnie tabeli zawierającej komentarze. Sprowadza się to do tego, że albo komentarze znikają, albo znika plik indeksu tabeli albo zwracany jest błąd 127 mysql. Na takie bolączki zazwyczaj pomaga REPAIR TABLE, niemniej przed chwilą wykonanie tej komendy we wspaniałym stylu obcięło mi ilość wierszy tabeli do 0. Wow! Oczywiście nie muszę mówić, że nie mam backupu tej tabeli sprzed wykonania operacji, prawda? Powód braku jest prozaiczny - ponieważ dziś wieczorem miałem podnieść wersję silnika, to zostawiłem robienie backapu na wieczór właśnie.
Teraz pozostaje mi wierzyć, że mój hostingodawca ma backup dziś z nocy, względnie z wczoraj. Dodatkową lekcją jest konieczność uruchomienia zadania z crona (ciekawego czy mam tu coś takiego) co niezależnie będzie robić mi backup (ciekawe czy z tego co mam, mam dostęp do takiej funkcjonalności). I ostatnią lekcją jest konieczność wgrania jakiegoś zadania typu captcha, które zmniejszy mi ilość wpływającego do akismeta spamu - bo podejrzewam, że to właśnie gwałtowny rozrost tabeli przez spamowe komentarze powoduje niestabilność silnika mysql, który gdzieś w tym sharowanym hostingu się gubi :/
Tymczasowo, do czasu odzyskania tabeli i podniesienia wersji bloga wyłączyłem możliwość komentarzy - swoją drogą dziwne, że wordpress nie ma możliwości przełączenia komentowania inaczej. niż tylko dla zarejestrowanych użytkowników. Chyba, że z poziomu bazy danych wykona się UPDATE wp_comments SET comment_status = ‘closed’; No, ale że nie można tego zrobić per blog? Dziwne (albo ja po prostu tej opcji nie znalazłem, co też jest możliwe).

Po prostu nie mogę dojść do porozumienia z moim wordpressem. A dokładniej z kodowaniem znaków. Sytuacja wygląda następująco - baza mysql ma kodowanie utf8. Dane w tablicach są zapisane w utf8 - sprawdziłem wg kodowania phpmysqladmin (strona utf8), sprawdziłem także zakładając drugiego bloga na tej samej bazie danych (inny przedrostek tabel) i kopiując do jego tabeli posts dane z tej tabeli posts (poprzez INSERT INTO * SELECT *). Obydwa blogi pracują na jednej bazie danych, na jednym serwerze, wszystko wygląda podobnie. Jedyna różnica pomiędzy blogami to to, że w jednym jest ustawione w wordpress kodowanie iso-8859-2 a w drugim utf-8. Ustawienie w pierwszym utf-8 powoduje totalne krzaczenie.
Jest to (chyba?) absurdem - przecież jeśli dane są w utf8 to ustawienie iso8859-2 powinno powodować krzaki a nie odwrotnie :/ Wordpress ma jakieś mechanizmy rekodujące ustawienie przeglądarki na ustawienia bazy danych. Musi mieć bo piszę to w iso a zaraz obejrzę na drugim blogu w utf. Niemnie - czy ktoś ma pomysł jak to namierzyć?

Google jest jednak wielkie. Ich podejscie do swiata pokazuje bardzo mocno, ze SaaS (Software as a Service) to przyszlosc. Chociazby ta notke pisze z losowego komputera, wykorzystujac Google Docs & Spreadsheets z ktorego publikuje bezposrednio do mojego bloga dzieki API MovableType w ktore wyposazony jest Wordpress. Nie tylko, ze moja produktywnosc wzrasta, poniewaz dostep do swoich prywatnych dokumentow mam prawie zawsze i wszedzie (bo firmowych tam nie wrzuce - polityka bezpieczenstwa chociazby), ale dodatkowo mam dostep do poczty integrujacej moje stare prywatne konta na darmowych serwisach w jedna kupke, mam dostep do czytnika RSS, dzieki ktoremu jestem na biezaco w tym co mnie interesuje, mam otwarty komunikator (co prawda bez transportow do innych sieci :|). Jestem produktywny caly czas, bez umierajacej (niestety) technologii U3 czy podobnej. (Na poziomie przechowywania plikow w ogole bez noszenia pendrivow, ktore za latwo gdzie sie gubia).

Coz - na tegorocznym MSS, o ktorym napisze w koncu w nastepnej notce, Steve Ballmer wspominal, ze Microsoft intensyfikuje wysilki swojej platformy Live, ktora ma wnosic taka nowoczesna produktywnosc. Niestety, na razie to co prozentuje Google powoduje, ze hasla MS powinny brzmiec: “Where do you want to google today?” and “It’s time (to catch up on Google)”. Moze w ramach polityki SaaS MS powinno wyewoluowac z modelu dostarczania pelnego produktu, ktorego nie wiadomo kiedy sie doczekamy, do tego co robi Google, rosnac razem z potrzebami uzytkownikow?

Zdaje sobie sprawe, ze Google nie jest idealne, a gromadzenie wszystkich moich informacji w jednym miejscu moze zostac wykorzystane przeciwko mnie, przez Evil Google Thingie, niemniej wyglada na to, ze dla informacji malo wrazliwych to jest jedyny rozsadny kierunek - czy to bedzie MS, Google czy ktokolwiek inny, kto wpadnie na jeszcze lepsze, prostsze i bardziej zintegrowane rozwiazanie. Zreszta w komputerach, o czym pisalem, szczegolnie dzieki wirtualizacji, tez dazymy do scentralizowanych rozwiazan - czy to filestorage, czy aplikacje 3-tier czy cokolwiek innego…

W zasadzie korzystam z feedów RSS w ten sposób, że nie odwiedzam macierzystej witryny, chyba, że chcę skomentować artykuł. Czasem chciałbym zobaczyć, czy jakieś komentarze do artykułu się pojawiły i co ludzie mają na ten temat do powiedzenia.

Niestety blogi oparte na wordpresie, w moim czytniku nie publikują komentarzy - ani ich ilości, ani samych komentarzy (rozwijalnych w RSS Bandit małym plusikiem obok tytułu wiadomości). Ponieważ nie lubię tego u innych, założyłem, że ktoś może nie lubić tego u mnie. Jakiś czas temu już dodałem do opcji feedburnera, żeby pokazywał pod wiadomością ile jest komentarzy (lub publikował odnośnik do dodania kolejnych). Jest to jednak półśrodek i dziś w końcu rozsierdziło mnie to na tyle, że znalazłem sposób na ładną współpracę czytnika ze stroną.

Wystarczyło delikatnie poprawić plik wp-rss2.php w którym powinny pojawić się linijki opisujące przestrzeń slash, bez której samo publikowanie przez WP informacji o komentarzch (btw, także z niezgodnym tagiem!) w postaci

mało daje.

Otóż polecam mały patch, autorstwa Axel Kollmorgen , dodający raptem dwie linijki - jedną do opisu przestrzeni, drugą do samych komentarzy:

Ledwo zdążyłem podnieść WP do 2.1.1 a tu okazuje się, że konieczne jest przejście o wersję wyżej, ponieważ, jak piszą w ogłoszeniu, nawaliło bezpieczeństwo i jakiś cracker podmienił pliki na zawierające exploita. nie dotyczy to wszystkich, jedynie tych, którzy ściągali nową wersję w przeciągu ostatnich czterech dni.

Co jest dobre w tej sytuacji? Cóż, podano informację o konieczności migracji, podano mniej więcej od kiedy występuje problem, podano informację jak sobie z tym poradzić. Wszystko pięknie i ładnie.

Co mi się nie podoba? Dwie rzeczy. Z informacji można wywnioskować gdzie powinno się szukać exploita (na pewno w theme.php oraz w feed.php z katalogu wp-includes), na pewno w przesyłaniu zmiennych zawierająch suffixy “ix” oraz “iz”. Trochę z tego można wywnioskować, ba, biorąc pod uwagę, że nowa wersja zmienia nazwy plików, które zostały zmodyfikowane wystarczy porównać instalację 2.1.1 oraz 2.1.2 i już mamy rzecz na taleczu. Skoro tyle zostało po dane, to czemu…

Jednocześnie update robi dwie rzeczy - wiadomo, że upgrade zajmuje trochę czasu. Wiadomo też, że przy szczególnej zmianie z 2.1.1 do 2.1.2 tylko niektóre z nich ulegną podmianie, niektóre trzebawypada skasować.

…nie można wprost podać tej informacji (jak już przy jednym sec releasie było) i wydać paczki z szybką łątką, tylko trzeba przechodzić przez dość długotrwały proces aktualizacji? Ciut to bez sensu i denerwujące. Nie wspominam już o full-disclosure bo i tak info o tej dziurze niedługo się pojawi i tak. Ale co tu narzekać - trzeba przejść aktualizację i tyle. Again.

Ciut późno postanowiłem się przesiąść na nowego wordpresa, czując, że będzie to wymagać czasu. Nawyki administratora pomogły - po pierwsze poczekać, aż młodzi, chętni zrobią wielki rush na technologię i odbiją się od niej, następnie zobaczyć jaki wygenerowali feedback i rozpocząć własne testy. Ta chwila przejścia pozwoliła mi także upewnić się, że wszystkie moje pluginy działają poprawnie, a także przyjrzeć się kilku nowym, które muszę umieścić na stronie.

Sama przesiadka odbyła się prawie bez problemów - niestety własny locale.php powodował wywrócenie instalacji, trzeba było odświeżyć kilka pluginów, ponadto hardcodowane dodatki wywracały layout (ale to dzieje się po każdym update).

Właśnie - tamten layout mi się przejadł, znalazłem coś nowszego. Lepiej? Gorzej? Wymaga kilku poprawek (chociażby implementacji dodatków, które hardcodowałem w tamtym layu - chyba czas przejrzeć te wszystkie widgety…), ale jest (dla mnie przynajmniej) świeższy.

Ponieważ dystrybucję feeda RSS powierzyłem serwisowi feedburner, przy przeglądaniu jego możliwości zauważyłem możliwość dodania pola komentarzy do feeda - czyli jeden z FeedFlares . Nie działa ona niestety tak słodko jak w Serendipity czy też Community Server (tj. nie dodaje odpowiedzi w moim readerze od razu do feedu głównego), ale pozwala zobaczyć czy są jakieś komentarze lub zamieszcza link, żeby je szybko dodać. No i wszystko byłoby dobrze - gdyby nie fakt, że Wordpress źle taguje odpowiednie pole. Powinien je opisać jako <wfw:commentRss> a taguje jako <wfw:commentRSS>. Niby niewielka zmiana, ale przez to nie zadziałało coś (u mnie). Poprawę zachowania daje edycja pliku wp-rss2.php i zmiana złego wpisu na poprawny.

Swoją drogą muszę się zainteresować jak podpiąć komentarze do feeda w stylu innych systemów blogowych właśnie. Może jest jakaś wtyczka?

Dziś przeniosłem swój blog z jednego, niestety nie posiadającego dobrego łącze serwera na drugi. Procedura jest bardzo prosta:

1. Skopiowałem wszystkie pliki, razem z .htaccess.
2. Zrobiłem backup bazy (wtyczka WP-DB-Backup jest tu bardzo pomocna)
3. Odtworzyłem bazę
4. Zmieniłem plik wp-config.php na zawierający właściwe dane połączenia z bazą
5. Wrzuciłem pliki na nowy serwer

Blog działa, feedburner działa, wszystkie wtyczki działają (bez ich uprzedniego wyłączenia).

[problem]
Problemem są niestety polskie znaki diakrytyczne, które baza danych na nowym serwerze serwuje mi w iso-8859-2 zamiast w UTF-8.
Baza ma zapisane kodowanie UTF8_general, dane w niej (zaimportowane) są także w UTF8. Wordpress ma ustawione kodowanie UTF-8. Wszystko teoretycznie w porządku, ale character_set dla serwera ustawiony jest na latin2. W związku z tym nowe wpisy (takie jak ten) są zapisywane w bazie w UTF8, tylko innym (jeśli przeglądam podgląd danych w phpmyadmin to po ustawieniu kodowania na utf8 nowe posty mają krzaki). O co chodzi?!
Na razie, żeby działało zmieniłem kodowanie na ISO-8859-2, ale to nie jest dobre rozwiązanie

Od kawałka czasu padłem ofiarą spam botów, które śmiecą mi w logach swoimi adresami oraz wysycają moje biedne (SDI rulez!) łącze. Pokazuje to przyjemnie i slimstat, jak i kilka obrabiających logi apache demonów. Cóż - temat stary jak świat (pierwsze posty na ten temat jakie czytałem pochodziły z 2002 roku), a rozwiązanie banalne. Wystarczy w zasadzie poblokować w .htaccess słowa kluczowe (i niestety aktualizować je co jakiś czas) prostą regułą:

Dzięki temu spamerzy zostaną przekierowani do siebie samych. Minusem tego rozwiązania jest zakaz używania powyższych słów tytułach własnych postów (jeśli mamy włączone permlinki), ale to chyba nie będzie miało u mnie miejsca.

Jak sprawdzić, że blokada działa? Prosto - używamy narzędzia wget (jest także pod Windows!)

i ściągamy nie naszą-super-witrynę.com ale właśnie spamerskie dmost.

Rozszerzeniem tej idei jest blokowanie adresów IP spamera, na przykład za pomocą przekierowania na plik PHP i wywołania

, ale po pierwsze - zablokujemy jakieś tam adresy ze spam-netu, iptables wymaga niewirtualnego hostingu, i po ostatnie - jeśli ktoś może uruchomić iptables z uprawnieniami roota z konta na którym działa apache to gratuluję… odwagi? głupoty?

P.S. Chociaż może tego nie widac na podstawie tego bloga - ale ja naprawdę czytam także inne rzeczy niż logi

Nowa wersja wordpress - jak zwykle do pobrania.
Lista poprawek jest dosyć długa - chociaz ja ani jednego tych błędów nie wyłapałem. Jest tam tez kilka rozszerzeń, ale jakoś mnie nie bawią, może poza jedną, bo używam Tiger Administration.

Update oczywiście wykonany - przez co przez parę minut strona była niedostępna… Swoją drogą to ciekawy bug - ponieważ jedna funkcja używana przez mnie w tempate strony (z pakietu WP-Stats) była niedostępna PHP przerwało pracę i nie wyświetlało zawartości strony - gdyby nie to, to upgrade przebiegłby wprost niezauważalnie

Źródło wiadomości: planeta wordpress oraz Ja, Rafi

Pojawił się nowy release dla Wordpress podnoszący wersję do 2.0.3. Warto zapoznać się ze szczegółową listą zmian z której wynika, że poprawiono kilka drobiazgów stanowiących problem zabezpieczeń (głównie regexpy) oraz kilka bugów będących w wersji 2.0.2 na które osobiście sam sie nie nadziałem…
Przeprowadzony upgrade wg standardowej instrukcji odbył się bezproblemowo

Standardowo pisane skrypty PHP nie zaczynają linii kodu od @ wyłaczającej drukowanie błędów w kodzie HTML. Standardowo za to serwery PHP konfigurowane są tak, żeby takie błędy w kodzie strony pokazywać. Standardowo aplikacje PHP, nawet te dokonujące zmian konfiguracyjnych w .htaccess też nie dopisują odpowiednich dyrektyw mogących to zmienić. Ba! Nie dają nawet takiej opcji, (sidenote: trzeba by zgłosić taki feature request).

Czym właściwie coś takiego grozi? Cóż - to już zależy od tego, co jest zaimplementowane w kodzie. W wypadku wordpressa wypluwa zapytania SQL, (swoją drogą - całe mnóstwo, ale o tym już pisałem w jednej z poprzednich notek, tag wordpress, sql) a także np. ścieżkę, gdzie znajdują się fizycznie w danej konfiguracji serwera niektóre pliki. Źle napisana aplikacja/plugin potrafi zwrócić dużo więcej informacji, (np zapytanie mające w sobie hasło albo inne wrażliwe informacje.

Jak sobie z tym radzić? W zasadzie warte uwagi jest w tym zakresie kilka dyrektyw. W php.ini możemy umieścić:

Pierwsza linia wyłączy wyświetlanie błędów. Ponieważ jednak nawet na maszynie produkcyjnej warto zauwazyć, czy coś się nie psuje, druga linia włącza logowanie na zewnątrz, zaś trzecia dokładnie określa cel, do którego zdarzenia mają się logować. Celem nie musi być plik - może to być syslog, czyli albo log systemowy Linuxa albo Event Log
Dla administratorów, którzy nie mogą niestety wyłączyć tej funkcjonalności na poziomie całego serwisu, proponuję w konfiguracji Virtual Host albo w .htaccess następujące zapisy:

Oczywiście innym problemem jest wyświetlanie użytkownikowi informacji o tym, że błąd nastapił, co zazwyczaj, szczególnie jesli kaleczy to funkcjonalność serwisu w sposób znaczący. Powinny być to jednak przypadki zdefiniowane, (nawet niezdefiniowane w wypadku dodania handlera ogólnego uznaję za zdefiniowane) i obsłużone komunikatem błędu czytelnym dla użytkownika a bezpiecznym dla systemu. Ten temat w całosci jednak pozostawię developerom

Do poczytania: Error Handling and Logging Functions.

Ponieważ moje “wspaniałe” łącze powoli się coraz bardziej wysyca, a operator internetowy jest niechętny zmianie na ine tłumacząc to brakiem możliwości technicznych, zmuszony zostałem do zaktualizowania adresu feeda i wykorzystania feedburnera. Proszę o aktualizację adresu.
Ponoć feedburner ma rozbudowane możliwości analityki ruchu na feedzie - czasem się może tego dowiem, a na razie zauważalnym minusem zmiany jest niestety struktura permalinks, która uległa przebudowie.

Nie ukrywam, że wynikło to z powodu problemów z wordpress. Nie rozumiem, dlaczego z jednej strony permalinks działały, (custom), a jednocześnie .htaccess był pusty? I to pomimo restartów apache, (sprawdzałem lsof, że apache wcale nie czyta tego pliku, ale najmniej spodziewane rzeczy czasem pomagają…). Najprawdopodobniej zawinił mechanizm cache wbudowany w wordpressa 2.x. Taaak, ciekawe co ten ambitny cache jeszcze potrafi popsuć? Niemniej struktura permalinks od dziś pozostanie bez zmian (ten index.php w adresie nigdy mi się nie podobał i nie pamiętam czemu go tam zostawiłem…).

Za wszelkie utrudnienia w odbiorze redakcja bloga przeprasza i życzy dalszej miłej lektury.