Jeśli publikujemy posty na swoim blogu, to pierw musimy je gdzieś sporządzić. Możemy to robić w zwykłym notatniku lub też bezpośrednio w formularzu WordPressa dostępnego przy edycji postu. Istnieje też inna możliwość, mianowicie korzystanie ze specjalnie przeznaczonego do tego celu oprogramowania -- klientów blogowych działających w oparciu o protokół XML-RPC. Jest to mechanizm podobny tego znanego choćby z poczty internetowej, czyli mamy konto email, np. na gmailu ale do tworzenia i zarządzania wiadomościami wykorzystujemy np. Thunderbirda. Podobnie możemy postępować z treścią pojawiającą się na blogu i nawet nie musimy być w tym czasie online. Jednym z bardziej znanych klientów, przy pomocy którego możemy wrzucać posty na bloga, to Windows Live Writer (WLW). Poza tym, protokół XML-RPC wykorzystywany jest także przez część serwisów internetowych, np. Flickr , co umożliwia im zamieszczanie postów w naszej witrynie.

W chwili gdy zabierałem się za rozpracowywanie szeregu zagadnień związanych z oczyszczaniem nagłówka generowanego przez WordPress, nie miałem pojęcia, że niektóre opcje nie są dostępne w standardowej instalacji, którą każdy może sobie pobrać z ich strony i wgrać do siebie na serwer. Chodzi oczywiście o krótkie odnośniki (shortlinks). Ich głównym celem jest skracanie linków do paru znaków, tak by można je umieścić np. na Twitterze gdzie długość wiadomości jest znacznie ograniczona i raczej wklejanie tam linku, który by zjadł wszystkie dostępne znaki nie jest zbytnio pożądane.

Na necie widziałem wiele tutoriali na temat zmiany konfiguracji stylów czy motywów WordPressa i w większości z nich ludzie dokonywali poprawek w kodzie źródłowym bezpośrednio przez panel administracyjny. Ni to wygodne, ani bezpieczne. Prze wszystkim, jeśli jakiś robak uzyskałby dostęp do konta administracyjnego naszego bloga, to pierwsze co mu przyjdzie do głowy, to edycja plików właśnie za pomocą wbudowanego w WordPress edytora (Appearance => Editor). Dlatego ze względów bezpieczeństwa kluczowe jest wyłączenie tej opcji i jeśli potrzebujemy zmieniać określone pliki WordPressa, to róbmy to poza samym skryptem i najlepiej przy pomocy zwykłego notatnika co potrafi kolorować składnię, by uniknąć również ewentualnych literówek.

Jeśli piszemy dużo na swoim blogu i mamy sporo treści, którą trzeba uaktualnić, to prawdopodobnie często wprowadzamy poprawki polegające na usuwaniu starych wpisów i tworzeniu szkiców nowych artykułów. Tego typu rotacja sprawia, że sporo wiadomości ląduje w koszu, z tym, że jeśli chodzi o bazę danych, to jej jest bez różnicy czy przenieśliśmy dany post do kosza, przynajmniej do momentu gdy faktycznie on wyleci z bazy danych. Także pod względem objętości bazy nic się nie zmienia. Poza tym, WordPress potrafi opróżniać kosz co pewien czas i dla jednych ten interwał może być za krótki, a dla innych za długi. Postaramy się więc go dostosować.

Klucze SSH mogą być wykorzystane jako sposób identyfikacji danej osoby przy logowaniu się do zdalnego serwera SSH. Te klucze zawsze występują w parach -- jeden prywatny, drugi publiczny. Pierwszy z nich jest znany tylko nam i powinien być trzymany w sekrecie i pilnie strzeżony. Klucz publiczny z kolei zaś jest przesyłany na każdy serwer SSH, z którym chcemy się połączyć. Gdy serwer jest w posiadaniu naszego klucza publicznego i widzi przy tym, że próbujemy nawiązać połączenie, używa on tego klucza by wysłać do nas zapytanie (challange) -- jest ono zakodowane i musi na nie zostać udzielona odpowiednia odpowiedź, a tej może dokonać ktoś, kto jest w posiadaniu klucza prywatnego. Nie ma innej opcji by rozkodować wiadomość, dlatego też nikt inny nie może udzielić na nią prawidłowej odpowiedzi. To rozwiązanie eliminuje wrażliwość na różne formy podsłuchu -- ten kto nasłuchuje nie będzie w stanie przechwycić pakietów zawierających hasło, bo ono nie jest nigdy transmitowane prze sieć. No i oczywiście jeśli chodzi o samo hasło -- odpadają nam ataki typu Brute Force pod kątem jego złamania.

Ostatnio opisywałem skrypt wp-cli , który posiada ciekawe możliwości pod względem zarządzania instalacją i konfiguracją WordPressa. W tym artykule postaram się przebrnąć przez ten proces wykorzystując jedynie powyższe narzędzie. Nie mam zamiaru korzystać z przeglądarki i nie będę przy tym nawet potrzebował odwiedzać strony WordPressa w celu pobrania jakichkolwiek plików. Wszystkie poniższe kroki zostaną przeprowadzone w terminalu na serwerze i mam nadzieję, że uda mi się pobrać, zainstalować i przygotować WordPressa do pracy.

Narzędzie wp-cli to wiersz poleceń upchnięty w pliku .phar (PHP Archive), przy pomocy którego możemy zarządzać instalacją WordPress'a bez potrzeby zaprzęgania do tego przeglądarki. Przy pomocy tego skryptu będziemy w stanie instalować i aktualizować rdzenne pliki WordPress'a, jego wtyczki i motywy, a także dokonywać szeregu operacji na bazie danych. Projekt jest na licencji MIT, zaś jego źródła są dostępne na githubie.

By dokonywać jakichkolwiek zmian w WordPressie (i mowa tu nie tylko o dodawaniu treści ale także zmianie jego plików źródłowych), to musimy uzyskać dostęp do panelu administracyjnego, a tu z kolei możemy się dostać tylko za pośrednictwem formularza logowania. Panel admina możemy wywołać przez dopisanie do adresu strony wp-admin/ , z tym, że jeśli nie jesteśmy zalogowani, to automatycznie zostaniemy przekierowani na wp-login.php . Nie oznacza to bynajmniej, że nie możemy wykonać zapytania do plików znajdujących się w katalogu wp-admin/ . Obie te powyższe lokalizacje muszą być traktowane ze szczególną ostrożnością, a dostęp do nich limitowany i bardzo restrykcyjny.

Standardowo WordPress dorzuca nieco informacji na swój temat bezpośrednio do kodu wygenerowanej witryny. Jednym z bardziej niebezpiecznych takich dodatkowych wpisów jest wskazówka na temat zainstalowanej wersji skryptu. Oczywiście, że powinniśmy aktualizować WordPressa na bieżąco i możliwie od razu jak tylko zostanie wypuszczona jego nowa wersja ale nie zawsze możemy nadążyć za tymi wszystkimi zmianami i wyrobić się w terminach. Ja jestem też zdania, że kluczowe oprogramowanie (zwłaszcza w internecie) powinno posiadać wersję nie do ustalenia, albo chociaż jakiś mylący ciąg znaków, tak by automatyczne ataki opierające się o wersję danej aplikacji, nie tyle zostawiły nas w spokoju, co zaczęły popełniać błędy, które będą widoczne w logach. Przynajmniej takie jest optymistyczne założenie.

Jeśli zamierzamy kupić sprzęt, który dopiero co trafił na półki w sklepach, to prawdopodobnie zaraz po podłączeniu go do naszego komputera okaże się, że to urządzenie nie jest nawet wykrywane przez system operacyjny. W przypadku gdy jego producent zapewnia w miarę przyzwoity support, to być może problemy, których doświadczamy, zostaną rozwiązane wraz z instalacją najnowszego kernela. Co jednak w przypadku gdy nawet po aktualizacji kernela nie jesteśmy w stanie odpalić, np. nowo zakupionej karty WiFi? Jako, że te wszystkie sprzęty działają w oparciu określone moduły, wystarczy taki moduł pozyskać, skompilować i załadować w systemie. Problem w tym, że z każdą nową wersją jądra operacyjnego, która trafi do repo debiana, będziemy musieli ręcznie budować moduł na nowo i właśnie w tym artykule opiszę jak nauczyć system, by sam przeprowadzał tę mozolną czynność bez naszego udziału.